Maybe its me but occasionally questions pop into my head that no one else seems to ask. This happened recently when we were talking about map lights found in cars. My car is five years old now and the map light switch is the classical push-to-make/push-to-break switch. The latching action is accomplished with a combination of plastic and springs inside the switch. In more recent or maybe just more expensive cars (note to myself: check the bosses car) the push-button is a very delicate push-button. The latching action has probably been accomplished by a small micro. The implication is that we all want delicate push-buttons with electronic control to replace the firmer push-buttons. This is when that question filtered into my conscious – do I have weak fingers?
Putting that complex question aside for another time I soon realized that F-RAM could be part of a rather neat solution for the weak-fingered applications. The problem with the electronic control is that connecting the vehicle battery after servicing could power up the light in the on state and that could drain the vehicle battery. In the schematic below a Ramtron F-RAM State Saver is used to remember the status. This is a simple D-type latch where the output uses F-RAM to recall the previous state. This means that if the lamp was off before the vehicle battery was removed it will be off after the vehicle battery is reconnected. It doesn’t get much simpler than that. Now, I wonder how to measure finger strength?

Most engineers are aware of design for test and design for manufacture. The goal is to design products that are easy to test and manufacture. If you achieve this, you’ll have lots of friends in the production department.
I once heard that if you consider all the systems a typical car needs, you will need about four hours for programming and configuration. Although I’ve never been able to verify this, I was reminded of this figure when I recently came across another programming problem.
The problem was programming a data table during production. The look-up table (LUT) contains data to control an engine and maps all of the engine parameters under various operating conditions. The table was about 256Kbits. That’s no not unusually large so why the problem? The problem was that the LUT had to be measured and calculated during production. To compound the problem further, the table is arrived at iteratively and needs to be re-written many times.
Let’s just run through the calculations if you stored the LUT in an EEPROM:
| Programming time of EEPROM (assumes 32 byte write page and 10ms per page) |
10.24s
|
| Cost of Programming 256Kbits (assume €30 per hour) |
8.5c
|
| Cost of Programming 10 iterations of the LUT |
€0.85
|
| Time taken for 10 iterations of the LUT |
1min 44s
|
Now I don’t know about you but I was surprised to calculate that the cost of programming a 32Kbyte 256Kbit) EEPROM is 8.5c. This of course assumes that you can only program one device at time.
Compare this to using an F-RAM. The programming time is basically the bus speed.
| Programming time of F-RAM (assumes 8MHz SPI clock – no write time required) |
0.262s
|
| Cost of Programming 256Kbits (assume €30 per hour) |
0.22c
|
| Cost of Programming 10 iterations of the LUT |
€2.2c
|
| Time taken for 10 iterations of the LUT |
2.62s
|
Now if you go the production department and tell them that you could save them 1min 41s of production time and will save €0.82 (at €30 per hour) you will make lots of people happy!