Finally, we are at the end of this series, where I am going to give an overview of the software behind all the menu system and of course, all the handling of user inputs and sending of MIDI messages. We’ve spent so much time configuring the various peripherals and writing driver code to abstract away the nitty-gritty implementation stuff, this is where it all comes together! For the project files, do check out the Github repo....
The problem with the simple approach In part 1A, I presented a simple approach that did the job quite well. However, since the program has to wait for the slow I2C bus to send more than 30 bytes of data every single time the LCD is fully updated, it simply wouldn’t cut it for a MIDI controller which not only has to send keypresses with as low a latency as possible, but also has to do a whole bunch of timing critical stuff like bit angle modulation, polling five rotary encoders, and multiplexing an LED matrix....
This was one hands down the most challenging and frustrating part of the entire project, involving hours of staring at the reference manual for the STM32F103 microcontroller series trying to figure out why the I2C peripheral kept locking up. Maybe its just me, but the diagrams and explanations in the reference manual for the I2C peripheral were not exactly intuitive, especially since they throw in a whole bunch of concurrent events that occur throughout the process of sending/receiving data packets, and the registers you have to read/write to placate the peripheral changes in a kinda confusing way depending on the number of data packets, the speed at which the slaves respond, etc, etc, etc…....