ONE_CSUM(3) Library Functions Manual ONE_CSUM(3)NAME
oneC_sum - One's complement internet checksum
SYNOPSIS
#define _MINIX_SOURCE 1
#include <stddef.h>
#include <sys/types.h>
#include <net/gen/oneCsum.h>
u16_t oneC_sum(u16_t prev, u16_t *data, size_t size)
DESCRIPTION
OneC_sum is used to calculate the one's complement checksum needed for IP network packets. A good document about the Internet Checksum is
RFC-1071 (Computing the Internet checksum).
One_Csum expects three parameters:
prev The checksum of previous blocks of data that are to be included in the checksum. The value of prev in first call to oneC_sum
should be 0.
data A pointer to the block of data. The data is interpreted as a series of 16 bit numbers in network byte order, but an odd number
of bytes is also allowed.
size The size of the data in bytes.
SEE ALSO ip(4).
RFC-1071
AUTHOR
Philip Homburg (philip@cs.vu.nl)
ONE_CSUM(3)
Check Out this Related Man Page
srec_signetics(5) File Formats Manual srec_signetics(5)NAME
srec_signetics - Signetics file format
DESCRIPTION
The Signetics file format is not often used. The major disadvantage in modern applications is that the addressing range is limited to only
64kb.
Records
All data lines are called records, and each record contains the following 5 fields:
+--+------+----+----+----+----+
|: | aaaa | cc | as | dd | ss |
The field are defined as follows: +--+------+----+----+----+----+
: Every record starts with this identifier.
aaaa The address field. A four digit (2 byte) number representing the first address to be used by this record.
cc The byte-count. A two digit value (1 byte), counting the actual data bytes in the record.
as Address checksum. Covers 2 address bytes and the byte count.
dd The actual data of this record. There can be 1 to 255 data bytes per record (see cc)
ss Data Checksum. Covers only all the data bytes of this record.
Record Begin
Every record begins with a colon ":[rq] character. Records contain only ASCII characters. No spaces or tabs are allowed in a record. In
fact, apart from the 1st colon, no other characters than 0..9 and A..F are allowed in a record. Interpretation of a record should be case
less, it does not matter if you use a..f or A..F.
Unfortunately the colon was chosen for the Signetics file format, similar to the Intel format (see srec_intel(5) for more information).
However, SRecord is able to automatically detect the dofference between the two format, when you use the -Guess format specifier.
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. The order of addresses in the records of a file is not important. The file may also
contain address gaps, to skip a portion of unused memory.
Byte Count
The byte count cc counts the actual data bytes in the current record. Usually records have 32 data bytes, but any number between 1 and 255
is possible.
A value of 0x00 for cc indicates the end of the file. In this case not even the address checksum will follow! The record (and file) are
terminated immediately.
It is not recommended to send too many data bytes in a record for that may increase the transmission time in case of errors. Also avoid
sending only a few data bytes per record, because the address overhead will be too heavy in comparison to the payload.
Address Checksum
This is not really a checksum anymore, it looks more like a CRC. The checksum can not only detect errors in the values of the bytes, but
also bytes out of order can be detected.
The checksum is calculated by this algorithm:
checksum = 0
for i = 1 to 3
checksum = checkum XOR byte
ROL checksum
next i
For the Address Checksum we only need 2 Address bytes and 1 Byte Count byte to be added. That's why we count to 3 in the loop. Every byte
is XORed with the previous result. Then the intermediate result is rolled left (carry rolls back into b0).
This results in a very reliable checksum, and that for only 3 bytes!
The last record of the file does not contain any checksums! So the file ends right after the Byte Count of 0.
Data Field
The payload of the record is formed by the Data field. The number of data bytes expected is given by the Byte Count field. The last
record of the file may not contain a Data field.
Data Checksum
This checksum uses the same algorithm as used for the Address Checksum. This time we calculate the checksum with only the data bytes of
this record.
checksum = 0
for i = 1 to cc
checksum = checksum XOR byte
ROL checksum
next i
Note that we count to the Byte Count cc this time.
Size Multiplier
In general, binary data will expand in sized by approximately 2.4 times when represented with this format.
EXAMPLE
Here is an example Signetics file
:B00010A5576F77212044696420796F75207265617B
:B01010E56C6C7920676F207468726F756768206136
:B02010256C6C20746861742074726F75626C652068
:B0300D5F746F207265616420746869733FD1
:B03D00
In the example above you can see a piece of code in Signetics format. The first 3 lines have 16 bytes of data each, which can be seen by
the byte count. The 4th line has only 13 bytes, because the program is at it's end there.
Notice that the last record of the file contains no data bytes, and not even an Address Checksum.
SEE ALSO
http://sbprojects.fol.nl/knowledge/fileformats/signetics.htm
AUTHOR
This man page was taken from the above Web page. It was written by San Bergmans <sanmail@bigfoot.com>
Reference Manual SRecord srec_signetics(5)