STM32

Finishing this project was a huge relief, to say the least. It is truly my first project in which I designed everything from the ground up instead of just building up schematics from the internet. Thus, it was also my longest running project yet, and the amount of work that has gone into it just blows my previous endeavours out of the water. It is also my first ever project build log/writeup, so I apologize for any mistakes or shortcomings throughout this series....

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....

Yes, this MIDI controller has a 4×4 grid that you have undoubtedly seen way too many times. No, it doesn’t have RGB Will it actually get used? Probably not. But hey, its a great opportunity to learn some electronics! And implementing key matrices is not as trivial as you might think. Schematic First off, if you haven’t already, check out this excellent post by Dave Dribin to learn about ghosting and masking....

I really like rotary encoders as user input devices, they’re free of analog noise shenanigans, have no fixed positions, can be augmented with velocity control… Just a really nice way for the user to navigate around in menus or adjust parameters. That said, they do take up at least one extra pin per encoder compared to potentiometers, and of course, they require either polling or pin change interrupts to react to changes in the states of their pins....

While PWM certainly is a mighty fine option to add dimming control to LEDs in your projects, there may be certain cases where it simply isn’t the best option. Maybe you don’t have enough PWM capable IO pins on your microcontroller? Or maybe manually bit-banging PWM control takes up too much CPU time? And you certainly aren’t about to fork out a bunch of cash for something like a TLC5940, and cheaper chips either are out of stock, are only stocked in pain-in-the-neck QFN packages, or are hopelessly backordered....

Staying on the topic of ways to use the I2C peripheral of the STM32F103 microcontroller, today, I’m going to discuss how I implemented a basic bi-color LED matrix based on the MCP23017 I2C I/O expander. This is not a full blown, colorful RGB LED matrix – its literally “monochrome”, but with the massive RAM of these STM32 microcontrollers, a full color LED matrix certainly seems doable with some tweaking, although at that point, I don’t see why wouldn’t you go for WS2812 or its alternatives instead....

Early on in the conceptualization phase of this project, I wanted something that had good customisability on board. That meant that I would need some sort of non-volatile memory to store all user changeable parameters, so I wouldn’t have to set everything up all over again every time I unplugged the thing. Out of all possible solutions, EEPROM would probably be the easiest to implement. The STM32F103 does not have internal EEPROM (unlike some AVR micros) however, and I really didn’t want to go to all the trouble to decipher ST’s emulated EEPROM library....

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…....

If you do orchestral programming, you know that MIDI faders are absolutely essential to achieve a sound that wouldn’t be passed of as “MIDI-like”. What happens when you really, really want a MIDI controller with a bunch of faders, but don’t feel like spending *that much* money on one? Well, you build one. In this series of posts, I will present my take on the DIY MIDI controller, which has 4 faders, 4 rotary encoders, and a 4×4 key matrix, all of which are fully programmable via an onboard LCD....