by Jon Wilder

Most PIC microcontrollers have some form of non-volatile EEPROM on chip. However, the largest I’ve seen is 1KB available on the 18F series. There are many applications in which we may need a great deal more than this.

The Storage You Don’t Have
For instance, what if we have a MIDI device with an LCD that allows the user to create and name presets? A preset name could allow for a 16-character name, but we must consider that each character takes up to 1 byte of memory for a total of 16-byte name space per preset. Considering that most MIDI devices allow the user up to 128 preset locations, this would amount to a total name space requirement of 128 presets x 16 bytes per preset = 2048, or 2KB of memory space just for the preset names.

Now consider that each preset has a given number of user programmable parameters. Each parameter setting occupies 1 byte of space as well. If we follow the same rule, assuming 16-user programmable parameters per preset, this would occupy another 2048 memory locations or 2KB of memory space.

So now we’re up to a non-volatile memory requirement of 4096 locations, or 4KB of required NV-RAM. This far exceeds the available max of 1KB of  EEPROM on the PIC. How do we get around this?
With serial EEPROM.

The Speed You Need
Microchip has serial EEPROM available in both SPI and I2C flavors with its 25LCxxx and 24LCxxx series. It just so happens that most PIC microcontrollers also have a Master Synchronous Serial Port, or MSSP, to handle the SPI and I2C communications on chip. It’s a perfect match.

SPI devices are a bit faster than I2C devices for a couple of reasons. The first is that a SPI is a full duplex protocol as there are separate bus lines for data in and out. This allows for simultaneous read & write. Secondly, they can operate with up to a 10MHz clock, whereas I2C devices max out around 400kHz. If you’re just using a single EEPROM, SPI is a great choice.

I2C is a bit slower than SPI, offering a max speed of 400kHz and a half-duplex interface. This is because data travels bidirectionally on the same bus line and, due to the use of open drain driver devices, a pull-up resistor is required. This makes I2C sensitive to bus capacitance which limits your available rise time and, therefore, your speed.

I2C does, however, have its advantages. Since I2C uses software addressing, no Chip Select lines are used. This is unlike SPI which uses a Chip Select pin on each device. I2C also uses only two bus lines for communication both ways. Due to the open drain design of the SCL and SDA driver, multiple master devices can reside on the same I2C bus without shorting each other out in the event of a dual master bus assertion.

At a speed of 400kHz, this translates to 50K bytes per second. If you’re only loading 32 bytes on a preset recall, a preset can be recalled and fully loaded in about 640 μsec. If you don’t need to load any faster than that, I2C EEPROM will suit your needs just fine.

The Perfect Match
Using serial EEPROM to expand your available non-volatile storage opens doors to all sorts of microcontroller project ideas. Even driving graphic LCD and TFT displays becomes possible as you now have storage space for your graphic bitmaps. And best of all, serial EEPROMs are dirt cheap and super easy to write driver code for via the use of the PIC’s MSSP hardware.

 

About the Author
Jon Wilder is a freelance electronics engineer and has been an electronics enthusiast for over 20 years. He spent four years in the US Navy as an aviation electronics technician. Jon has also been playing the guitar since age 13 and started integrating electronics and music from age 15. Jon built his first vacuum tube amp at age 17. “Musical electronics”, says Jon, is his love and passion.  

Jon is also a frequent contributor and passionate member of Electro-Tech-Online, an electrical engineering membership community. On Electro-Tech-Online, you can ask questions and get answers from your fellow engineers on everything from microcontrollers, renewable energy, and automotive electronics, to circuit simulation and design. Additionally, there are MCU-specific forums for 8051/8951, AVR, ARM, Arduino, Oshonsoft Project, as well as a Code Repository where members share snippets of code. 

Follow Jon on Twitter at @PICmcuguy.