Intro

#

So i started on writing the MCU firmware for the 309-MusicBox project. This week i have 2 exams (electrical engineering and mathematics) and after that i have some free time. I Started writing the MCU firmware because i wanted to do it and it may sound weird, but i truly relax/chill by working on projects. Even after a busy day of studying, in the evening i often finish projects. The MCU as i said in previous post about my 309-MusicBox project, is going to be an ESP32C3.

PlatformIO + Structure of the firmware

#

I decided to write it in Visual Studio code (VSCode) and using the platformIO integration. I could probably also do it in the regular Arduino IDE but i chose platformIO as its also what we use in programming class. And also it can also be integrated with GIT and i like VSCode as its one of the few microsoft products that i actually like and thats not yet ruined by microsoft. I will split the codebase into multiple files. I wont put everything into 1 big main Main.cpp file. Instead I will split it in different files. I will make it so its very flexible as i can and i wont hardcode in important bits. In my head and with a bit of Claude AI planning, i came up with a hopefully good structure.

Project files

#

tweakable files

#

Board.h

#

I will create a file called: Board.h that will define the GPIO (General purpose Input/Output) pins of the ESP, so i can always change them on the fly. As in developmental stages i will experiment on breadboard and on a regular esp32c3 devboard and later move to PCB design and embedding the raw ESP32C3 module on the custom PCb, which then could have different I/O asignments.

Config.h

#

I will also create a file called: Config.h. This config file will not only hold the firmware version string and date, it also will have some options you can enable for expanding the project.

I still do not know if i wil embed an amplifier chip on the PCB, but i will implement that feature into the code. You can disable/enable it by simply (un)commenting a line. Further i might add a rotary encoder instead of the buttons, or to add more control options but i also have that as an optional function that can be enabled and disabled. I also have the option for a i2c connected OLED-Display but thats also optional. And i might put in some more configuration options in that file along the way.

Hardware function files

#

So i will also split up the different hardware sections i have to implement into their own header file and cpp file. This makes it so i can seperate each functional component (eg: the statusled) into its own set of functions and its own code section.

StatusLed.h

#

This will be the header file that will make it so i can import the code section that controls the StatusLed into the Main.cpp main code. This also holds all the possible LedStates that the statusled can be in and also all colours it can be. So it contains imports for the functional logic from StatusLed.cpp but also defines the states and colours of the statusled.

StatusLed.cpp

#

So this file contains the code/logic functions that will drive the statusled. I can import the functions from it using the Statusled.h file into the main code. This defines that logic and makes it so i have a neat StatusLed object i can work with and can use in the Main Main.cpp logic.

UartHandler.cpp

#

This file contains the actual logic/functions of the UartHandler, which is what receives and processes the incoming requests from the SBC and it also handles sending button states or other info to the SBC. It exposes some functions that make it so the MCU can receive and proces the specific command syntax and makes it so the MCU can talk to the SBC in the specific command syntax. The syntax will be like this for the MCU side sending data to the SBC side: "MCU:{MSG}". For the Receiving side of the MCU (SO the SBC talkin to the MCU) it will look like this: "SBC:{MSG}". I will make it so when the SBC sends stuff like: “SBC:STATE:IDLE”, the MCU will respond with: "MCU:ACK". This “ACK” message will be short for “Acknowledged”. And the SBC will also respond with it when it receives a command from the MCU.

UartHandler.h

#

This will be the header file that will be for the UartHandler. This again exposes the functions and logic defined in UartHandler.cpp. other than that it does not do much on its own.

StatusLed codes

#

So i also already came up with a StatusLed code table. The status led will be used to indicate system status. I added a wide variety of states that makes it easy for the user to identify what the system is doing. Other than different error patterns i also added some boot phase patterns so you know what bootup phase the system is in currently. Also the update phases have different led states so you know when its bets to not unplug the device (if you ever plan to do so. Please DONT!)

SO i embedded these into the StatusLed.h file. I am not sure if i will keep this or modify it or even add more but this is the list for now.

Ending + Final thoughts

#

And for now thats it! I made a basic Main.cpp to test the Uart command processing and it seems to work. To emulate the SBC i simply hooked up the 2nd UART on the esp (defined in Board.h with the designated pins) to the 2nd channel on my FT4232H. Its handy as this FT4232H board has 4 UART channels and thus i can hook up to UART0 (Debug UART and also the UART used to flash the esp firmware) and see the debug messages and hook up to UART1 (The one i assigned to the channel between MCU and SBC) to send messages to the MCU and also check if the MCU sends back the correct data which i want. I will implement logic for the buttons and the rest and tie it together but i already have a start.

I did use claude AI to code the basic templates and then modified them by hand and tweaked them myself. The reasons are that i wanted to get these basic things done, but because i already spent the whole day studying for examns already, my brain is tired in the evening so i used AI to come up with the very basic templates and build-up from there and modify and fix things myself. If i did not have to study, i would have gone full self dedication on the project but i am very busy so getting stuff worked out/finsihed in the end is nice. I am still heavily against Vibe-coding though and will always use AI as a tool to assist in the process and not replace me and i can easily go without AI. Also i am not the best in C++ so i use AI to build the basic UartHandler and StatusLed template and then basically learn in the process of modifying and trial and error as that is what works for me. I have to see someone do it first before i can do it myself or know how to do it and i dont have time to spend hours watching youtube tutorials because of the exam week.

I am not only proud of myself for until now surviving the massive amount of studying and surviving these final days before the exam(s) but also proud of myself on what i already completed for the 309-MusicBox project as it has been an idea that was brewing in my head for like 2 years already and i finally decided to execute the idea and work it out.

Below is a short video (Served from my CDN :>) of the Statusled functionality. Enjoy! Just dont mind the messy desk and the mathematics stuff :).