perjantai 8. maaliskuuta 2019

Remember to store your data


When you are designing your small electronics project from ground up, starting with Arduino or Raspberry Pi is tempting option. Processor board does all the hard stuff and all you have to put on custom board is your application-specific electronics.

There's nothing wrong with this, of course, and for some projects is is absolutely great way to go. I have one project myself where I should have gone this route, but feature creep crept up on me.

However, if you want to mass-produce these things cheaply, this path may not be great, especially if the design is doing only something small that doesn't require processing power or included peripherals that something like RPi might offer, so designing the board around small microcontroller starts making sense.

Not to say you couldn't build a quick prototype around RPi first and then, when you find the concept feasible, designing custom board for that. That is actually a great way to do such things.

Microcontrollers offer lots of things, but memory for volatile data isn't one of them. With RPi you might use the SD card, but a simple microcontroller needs something else. While you could use internal program flash area for data, the storage isn't designed for this and you will wear out flash quickly, especially if data changes often. Most microcontrollers don't even offer EEPROM area for such data, and while some have battery-backed SRAM, the amount of data you can store there is tiny - often just tens of bytes.

So you will need external storage.

I have written about this topic few times before (here, here and here), but this time with other focus.

I like my memory chips small and easy to use. For that purpose an I2C-memory in small SO8 package is great and very simple to use. I2C memories have two huge drawbacks however; speed and size. The memory access time is limited by maximum I2C bitrate, typically around 400kHz (although higher speed devices do exist), and it is very difficult to find I2C memories with memory size larger than 256kbit (32kbytes). Possible, yes, but your options very quickly turn out very limited.

Again, for a small project this might not be a problem. Do the math as soon as you have any idea what and how much of it you will need to store, then proceed from there.

Lately, data size has become an issue for me, so I have moved mainly to SPI memories, still on SO8 (or similar) packaging. SPI is much, much faster than I2C (80MHz capable chips are common) and come in larger sizes. But they also are more difficult to use - especially if you want to use them to the max.

For example, writing to I2C is simple; send address, write indication and data. Done. There are some gotchas, like paging limitations with EEPROMs and so on but protocol-wise it's just that simple.

With SPI, you first have to first unlock pages first, send "write enable" command and only then you can write data in. And then you lock the pages again and disable writes - or at least you should. So simple write turns quickly into half a dozen separate commands, including polling write completion status and such.

Some time ago I ran onto this issue. I had tested previous versions of a board with a specific 64Mbit flash chip (sorry, exact details withheld) and it was working fine. I found out however that this specific chip was obsolete, so I had to look for replacement. And there was a new chip available, so I of course ordered few to test it.

And I couldn't write onto it. Everything else worked perfectly, but writes did nothing.

Did I mention that datasheet of this one memory chip has around 150 pages? Yes, this simple flash chip is very, very complex beast if you want to dig in, offering massive amount of features (of which I wanted to just the simplest writes and reads.)  Mass of these features turns into massive headache when you are trying to figure out why it isn't working for you, as previous chip offered no similar troubles.

Eventually I figured out the issue; the previous chip was a bit lax with Write Enable Latch bit (which enables write to chip, and is affected by abovementioned "write enable/disable" commands, but new one was more strict, disabling it automatically after every single operation. So by the time I was trying to write the actual data to the chip, Write Enable command sent a bit earlier had expired. Reordering commands a bit fixed the issue, but figuring this out cost me way too many hours of work.

This kind of behavior is exactly the reason I like those simple I2C chips so much. They, for the most part, function as dumb memory arrays, offering no such issues. But, as is common, these days I just need larger memory space and faster memory, so - for now - SPI is way to go. Despite the troubles they sometimes give.




Ei kommentteja:

Lähetä kommentti