Javítson ki, ha tévedek, de mivel az SREC a bináris adatok ASCII reprezentációja, a megfelelő bináris fájl nem "szivárogtat" ki 0x00 / 0xFF-vel párnázott adatrészeket? p> Ezzel azt mondtam, hogy igen, azt hiszem, hogy az SREC bizonyos esetekben hasznos információkat tárhat fel a firmware-ről, amelyeket bináris képpel egyébként nem kaphatna meg, feltéve, hogy az eladó megfelelően használja az SREC rekordtípusait. Az SREC fájl minden szövegrésze rekordkóddal kezdődik (S0, S1, S2 stb.). Néhány példa rekordtípusokról a Wikipedia SREC oldaláról:

Az S0 rekordadatsor a gyártó adatai helyett a gyártó adatait tartalmazza. Karakterlánc fájlnévvel és esetleg verzióadatokkal.

Adatsor a szükséges cím méretétől függően. A 16 bites / 64K rendszer S1, a 24 bites S2, a teljes 32 bites S3.

Az S7, S8 vagy S9 rekordok címmezete tartalmazhat egy kezdő címet a program.

Nyilvánvaló, hogy egy SREC fájl információt nyújt az egyes rekordok adatairól - olyan információkról, amelyek általában nem lennének bináris fájlokban. Ha például egy S7 / 8/9 rekordot lát, akkor feltételezheti, hogy a firmware belépési pontja ott található. Hasonlóképpen, az S2 vs S3 használata megmondhatja, hogy az adatok 24 vagy 32 bites címeket tartalmaznak-e.

Mennyire általános ezeket a különböző SREC rekordtípusokat a gyakorlatban használni, nem tudtam megmondani. Egy szállító valószínűleg mindent csak ugyanazzal a rekordtípussal jelölhet meg (például S1), ami valójában nem adna több információt az adatokról, mint egy bináris fájl.

Általában csak címeket és nyers bájtokat kap, de egyes eszközök / fordítók egyéni rekordtípusokat használhatnak, vagy további információkat adhatnak hozzá. Például a Tricore számára a Tasking VX eszköztár S0 rekordot használ az azonosításhoz:

S0-rekord

  'S' 0 '<length_byte> <2 bájt 0> <comment> <checksum_byte>   
:  ellenőrző összeg: 0xB6 
 
  lt cS00600006C7463B6  
 
 Az S0 rekord megjegyzésrekord, és nem tartalmaz a program végrehajtásához szükséges információkat .