There are several types of data handled by GenBoard ECM
Mostly developer information. GenBoard/BinaryProtocol obsoletes some of this information.
Types of data
- configuration
- hardware table (h-table)
- reference tables (ignadv, VE-ref, lambda, learn-windows ...)
- learnt tables (learnt VE, learnt ign-adjust)
- detailed runtime logs
- diagnostics, brief runtime logs
Storage locations
- EEPROM
- some of the data must be copied to SRAM (config and h-table)
- send via network (eg. RS232 to PC, TakeCareBoard)
- MMC
- internal FLASH
Data format
The data should be effectively addressed by type, and metadata, not by location (currently the EEPROM has the structures exactly in the same layout as in SRAM). This can be solved by frame-descriptors that help format and interpret the frames (in the PC and in the ECM)
This allows servicing dynamic demands. Some want huuuge tables while others want more learnt values or runtime logs.
This associates with some kind of filesystem.
Lightweigth filesystem - this is obsolete, see the frame-based thingy in GenBoard/BinaryProtocol
I thought of small blocks of binary data:
- 256 byte blocks with metainfo: 16 fits into 4kbyte EEPROM
- 256 byte block + (8..17 bytes) metainfo: 15 fits into 4kbyte EEPROM
- maybe 128 byte block + metainfo
Something similar is needed when sending data over the network to other GenBoard, PC or friendly unit. The frame also has to identify
- source (where it comes from)
- more precise timestamp
- more checksum (at least 2 bytes, but rather 4) per block
However some of these can be in a secondary header (only over the network, not in storage), somewhat similar as TCP and IP headers.
16..17 bytes metadata would allow more flexibility than 8 bytes.
We should leave some room for future expansion (the units later will allow much higher bandwidth, and more memory and cycles), and at least we want to detect communication incompatibility (with future products).
Please take a few minutes googling around. I used keywords
lightweight frame data protocol microcontroller
but only found TinyOs that could be usable: implemented on AVR - from 8513 having only 512 bytes RAM - and actually very similar to our EventQueue and userspace mainloop system, but TinyOs supports advanced communications.
Metainfo fields
- infotype (see above, 1 byte can be OK, see private below for extensions)
- timestamp: 4 bytes is OK for 1 sec precision
- private: 3 or 11 bytes. The interpretation depends on infotype
- more precise time
- revision (eg. different revisions of the same data. The last one can be used, that has correct checksum, unless the user instructs otherwise - eg. by selecting wife's configuration with lower redline
- checksum - for data integrity
That way it's easy to move around stuff, cause it's not addressed by location.
Something like this is essential for MMC, where several type of info can be stored. You will later want to evaluate with the PC, and the PC must know what type of data it reads. We don't want to restrict just to one infotype (eg. logs or learnt data), it's better to allow storing any type that's necessary.
- anyone knows the overhead of a FAT12 file ? Probably prohibitive, and little benefit. Except for using a preformatted FAT12 with a preallocated file to store data into (so the same MMC can still be used in the camera).
Learnt data
Learnt data is a bit special, because it's best to store it in EEPROM the latest possible time, just before powerdown (writing it all the time wears EEPROM a bit).
See GenBoard/BackupPower for some discussion on solutions, some including hardware.
An acceptable software-only solution can be to start saving randomly or equal-time (table-elements that are differ from saved value above a threshold) after 25 minutes of running if the learning is enabled.
If the VE learned data moves around in EEPROM in time, saving a byte every 10 second should get a long EEPROM life:
- 35000 hours if the learning table location is fixed in the EEPROM.
- 350000 hours if it is allowed to move
See also