EMON52 file format
This format is used by the monitor EMON52, developed by the European electronics magazine Elektor. Elektor wouldn't be Elektor if they didn't try to re-invent the wheel againg. It's a mystery to me why they didn't use any of the existing formats for this project. Only the Elektor Assembler will produce this file format, reducing the choice of development tools dramatically. I've added the EMON52 file format to my own SB-Assembler for a friend who owns a system with this EMON52 monitor. If you look at the formatting you should agree with me that they did a wonderful job at Elektor ;-)
This format is used by the monitor EMON52, developed by the European electronics magazine Elektor.
Elektor wouldn't be Elektor if they didn't try to re-invent the wheel againg.
It's a mystery to me why they didn't use any of the existing formats for this project.
Only the Elektor Assembler will produce this file format, reducing the choice of development tools dramatically.
I've added the EMON52 file format to my own Records
All data lines are called records and each record contains the following 4 fields:
cc aaaa:dd ssss
cc
The byte count. A 2 digit value (1 byte), counting the actual data bytes in the record. The byte count cc is separated from the next field by a space.
aaaa
The address field. A 4 digit (2 byte) number representing the first address to be used by this record.
:
The address field and the data field are separated by a colon.
dd
The actual data of this record. There can be 1 to 255 data bytes per record (see cc) All bytes in the record are separated from each other by a space.
ssss
Data Checksum, adding all bytes of the data line together, forming a 16 bit checksum. Covers only all the data bytes of this record.
I don't know if the EMON52 accepts both upper and lower case characters. Therefore I suggest to use only upper case.
Please note that there is no End Of File record defined.
Byte Count
The byte count cc counts the actual data bytes in the current record. Usually records have 16 data bytes. I don't know what the maximum number of data bytes is. It depends on the size of the data buffer in the EMON52.
Address Field
This is the address where the first data byte of the record should be stored.
After storing that data byte the address is incremented by 1 to point to the address for the next data byte of the record.
And so on, until all data bytes are stored.
The address is represented by a 4 digit hex number (2 bytes), with the MSD first.
Data Field
This is the actual payload of the record, the Data field. The number of data bytes expected is given by the Byte Count field.
Checksum
The checksum is a 16 bit result from adding all data bytes of the record together.
Example
10 0000:57 6F 77 21 20 44 69 64 20 79 6F 75 20 72 65 61 0564 10 0010:6C 6C 79 20 67 6F 20 74 68 72 6F 75 67 68 20 61 05E9 10 0020:6C 6C 20 74 68 69 73 20 74 72 6F 75 62 6C 65 20 05ED 10 0030:74 6F 20 72 65 61 64 20 74 68 69 73 20 73 74 72 05F0 04 0040:69 6E 67 21 015F
In the example above you can see a piece of code in EMON52 format.
It is fairly obvious why I don't approve of this format very much.
The lines are very long because each byte is separated by a space.
This makes it easier for us humans to read it, but I don't think that's the intention of these files.
An End Of File record is also missing, which is normal for this format though.
