Changes by last author:
Added:
|
For developers
Quintessence continued on http://wiki.x-dsl.hu/cgi-bin/w/telemetry.cgi?UartPacketComm. Datalogger discussion/specs Simple HW device with * internal flash (preferrably but not necessarily MMC/SD) ** soldered or swappable * RS232 to interface with VEMS and megasquirt (and maybe other ECU) * USB (important!)
Software specs: * configurable query commands; also the frequency for each command (like runtime vars 100msec; config, tables and ECU serialnr every 60 secs) ** usually the main runtime-query command is A, but R for some MS-xx *** possibly autodetect based on the result ? whichever answers >= 22 bytes ? ** other (probably rarely issued) query commands, like *** mci (serialnr of logged device) *** mdv *** mdV *** mcd (could be useful) *** mct (could be useful) * formatter running on PC (not inside the embedded. This is important! embedded codesize would restrict future options; having in the PC it can be prepared for many types, no space limit there) * binary "files" in flash, with simple framing around the stored results. If the received bytes are less than expected, less bytes logged, nothing we can do. Header content: ** magic-byte (to notice framestart; escaping with byte-stuffing is nice (only takes 8 lines of code, much less than framelength-field inside the header that might not be known in advance ), or (discouraged) the PC can guess frame-start quite well even without escaping; alternatively each block starts with a frameheader but that wastes a few % and getting much more complex than the good old byte-stuffing ** timestamp ** flag in the frame-header which query-command /only index is stored/ this frame belongs to ** result of query, or user-configured constant "metadata" (mostly user-specified), examples: *** serialnr of logger; *** notes on log-version (usually the framesize tells all, but, just in case) *** other notes by the customer rally/street/whatever; note on engine mods Discussion below is history ---- 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 * GenBoard/BinaryProtocol (obsoletes some of this information) |
