I2C

One of the (many) weird quirks of studying in the University of Cambridge is that our terms only last 8 weeks. Yes, the number of days we are officially “studying” is less than the number of days we are ostensibly on “holiday”. Of course, it never works that way, and Cambridge is probably one of the only places where going to uni feels exactly like going to secondary school. Over these long break, we are told that our rooms are going to be used for conference purposes, and that we would have to move all our stuff out to a tiny, cramped storage container....

As part of the Winter Logger project, I got myself some DIP EEPROMs from eBay which were ostensibly AT24C256’s, mostly because I didn’t feel like buying yet more stuff that I probably would never use just to pad out Mouser’s £33 for free shipping minimum order. This is what I got: Suspicious… With all the counterfeit semiconductors floating out there, I wanted to verify if I at least had functional EEPROM that wasn’t literally just plastic with some legs tacked onto it - I wanted to test if all the memory cells actually worked....

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

First off, there are already a whole bunch of tutorials on how to use this particular I2C EEPROM with an Arduino. If you want to understand how such an EEPROM works, this post is not for you. I just wanted to share this bit of code with anyone who doesn’t feel like writing their own. It basically allows you to select an EEPROM address and specify a payload to be written to that particular address....