File Formats
Most development systems transfer the freshly generated code via some communication link to the evaluation board or programming device.
This link can be anything, like the serial COM port, parallel printer port, USB, any dedicated link, or even the internet/intranet.
Several file formats are designed to ensure reliable transmission of the data through those links.
An error during transfer would result in unpredictable behaviour of the programmed device, therefore reliability is very important here.
The problem with normal binary transfers is that there is no checksum involved.
Files on a disk have the disk's CRC system to protect their integrity.
But as soon as you transfer the data to an other system this integrity may be lost.
Therefore the binary file format is not the most suitable format to use.
An other problem with binary files is that they don't include an addressing mechanism, so the 1st destination address must be assumed by the system.
And flexibility of skipping unused address space is completely missing.
In the past there was also an other important reason to encode the files into a particular format because paper tape and punch cards used only 5 or 7 bits of data.
The normal 8 bit bytes could not be represented by those systems.
Therefore files had to be converted to ASCII or Baudot anyway.
The problem with normal binary transfers is that there is no checksum involved.
Files on a disk have the disk's CRC system to protect their integrity.
But as soon as you transfer the data to an other system this integrity may be lost.
Therefore the binary file format is not the most suitable format to use.
Almost every manufacturer of programmable devices used to design their own file formats. New manufacturers however often use one of the already existing formats, so they won't have to re-invent the wheel all over again.
Use the navigation keys above to browse through the different file formats.
