SREC (filformat)

Ej att förväxla med Motorola hexadecimal notation .

S-rekord
Motorola SREC Chart.png
Ett snabbt referensdiagram för Motorola SREC-formatet. (Observera att i postexempelbilden används ordet "bytes" alternativt för att ange tecken.)
Filnamnstillägg
.s19 , .s28 , .s37 , .s , .s1 , .s2 , .s3 , .sx , .srec , .exo , .mot , .mxt
Utvecklad av Motorola

Motorola S-record är ett filformat, skapat av Motorola i mitten av 1970-talet, som förmedlar binär information som hexadecimala värden i ASCII -textform. Detta filformat kan också vara känt som SRECORD , SREC , S19 , S28 , S37 . Det används ofta för att programmera flashminne i mikrokontroller, EPROM , EEPROM och andra typer av programmerbara logiska enheter. I en typisk applikation konverterar en kompilator eller assembler ett programs källkod (som C eller assemblerspråk) till maskinkod och matar ut den till en HEX-fil. HEX-filen importeras sedan av en programmerare för att "bränna" maskinkoden till ett icke-flyktigt minne , eller överförs till målsystemet för laddning och exekvering.

Översikt

Historia

S-record-formatet skapades i mitten av 1970-talet för Motorola 6800- processorn. Mjukvaruutvecklingsverktyg för den och andra inbäddade processorer skulle göra körbar kod och data i S-record-formatet. PROM-programmerare skulle sedan läsa S-record-formatet och "bränna" data till de PROM eller EPROM som används i det inbyggda systemet.

Andra hex-format

Det finns andra ASCII-kodningar med liknande syfte. BPNF, BHLF och B10F var tidiga binära format, men de är varken kompakta eller flexibla. Hexadecimala format är mer kompakta eftersom de representerar 4 bitar snarare än 1 bit per tecken. Många, till exempel S-record, är mer flexibla eftersom de inkluderar adressinformation så att de bara kan ange en del av en PROM. Intel HEX- format användes ofta med Intel-processorer. TekHex är ett annat hex-format som kan inkludera en symboltabell för felsökning.

Formatera

Rekordstruktur

S Typ Antal byte Adress Data Kontrollsumma

En fil i SREC-format består av en serie ASCII-textposter. Posterna har följande struktur från vänster till höger:

  1. Record start - varje post börjar med en stor bokstav "S" (ASCII 0x53) som står för "Start-of-Record".
  2. Posttyp - ensiffrig siffra "0" till "9", som definierar typen av post.
  3. Antal byte - två hexadecimala siffror, som indikerar antalet byte (hexadecimala siffrorspar) som följer i resten av posten (adress + data + kontrollsumma). Detta fält har ett lägsta värde på 3 för 16-bitars adressfält plus 1 kontrollsummabyte och ett maximalt värde på 255 (0xFF).
  4. Adress - fyra / sex / åtta hexadecimala siffror som bestäms av posttypen. Adressbyten är ordnade i big-endian- format.
  5. Data - en sekvens av 2 n hexadecimala siffror, för n byte av datan. För S1/S2/S3-poster är maximalt 32 byte per post typiskt eftersom det får plats på en 80 tecken bred terminalskärm, även om 16 byte skulle vara lättare att visuellt avkoda varje byte på en specifik adress.
  6. Kontrollsumma - två hexadecimala siffror, den minst signifikanta byten av ens komplement av summan av värdena som representeras av de två hexadecimala siffrorna för byteantal, adress och datafält. Se exempelavsnittet för ett detaljerat exempel på kontrollsumma.

Textradsavslutningar

SREC-poster separeras av ett eller flera ASCII-radavslutningstecken så att varje post visas ensam på en textrad. Detta förbättrar läsbarheten genom att visuellt avgränsa posterna och det ger också utfyllnad mellan poster som kan användas för att förbättra maskinanalyseffektiviteten .

Program som skapar HEX-poster använder vanligtvis radavslutningstecken som överensstämmer med konventionerna för deras operativsystem . Till exempel använder Linux-program ett enda LF-tecken ( radmatning , 0x0A som ASCII-teckenvärde) för att avsluta rader, medan Windows-program använder ett CR-tecken ( vagnretur , 0x0D som ASCII-teckenvärde) följt av ett LF-tecken.

Rekordtyper

Följande tabell beskriver 10 möjliga S-rekord. S4 är reserverad och för närvarande inte definierad. S6 var ursprungligen reserverad men omdefinierades senare.


Rekordfält _
Rekord syfte
Adressfält _
Datafält _
Rekordbeskrivning _
S0 Rubrik
16-bitars "0000" 		No Denna post innehåller leverantörsspecifik ASCII-textkommentar representerad som en serie hexadecimala siffror. Det är vanligt att se data för denna post i formatet av en noll-terminerad sträng . Textdata kan vara vad som helst inklusive en blandning av följande information: fil-/modulnamn, versions-/revisionsnummer, datum/tid, produktnamn, leverantörsnamn, minnesbeteckning på PCB, copyrightmeddelande, logga in. Det är vanligt att se: 48 44 52 som är ASCII H, D och R - "HDR".
S1 Data
16-bitars adress 		Yes Denna post innehåller data som börjar vid 16-bitars adressfältet. Denna post används vanligtvis för 8-bitars mikrokontroller, såsom AVR, PIC, 8051, 68xx, 6502, 80xx, Z80. Antalet byte data som finns i denna post är "Byte Count Field" minus 3 (det vill säga 2 byte för "16-bitars adressfält" och 1 byte för "Checksum Field").
S2 Data
24-bitars adress 		Yes Denna post innehåller data som börjar på en 24-bitars adress. Antalet byte med data som finns i denna post är "Byte Count Field" minus 4 (det vill säga 3 byte för "24-bitars adressfält" och 1 byte för "Checksum Field").
S3 Data
32-bitars adress 		Yes Denna post innehåller data som börjar på en 32-bitars adress. Denna post används vanligtvis för 32-bitars mikrokontroller, som ARM och 680x0. Antalet byte med data som finns i denna post är "Byte Count Field" minus 5 (det vill säga 4 byte för "32-bitars adressfält" och 1 byte för "Checksum Field").
S4 Reserverad — — Denna post är reserverad.
S5 Räkna
16-bitars antal 		No Denna valfria post innehåller ett 16-bitars antal S1/S2/S3-poster. Denna post används om postantalet är mindre än eller lika med 65 535 (0xFFFF), annars skulle S6-posten användas.
S6 Räkna
24-bitars räkning 		No Denna valfria post innehåller ett 24-bitars antal S1/S2/S3-poster. Denna post används om postantalet är mindre än eller lika med 16 777 215 (0xFFFFFF). Om mindre än 65 536 (0x10 000) skulle S5-posten användas. OBS: Detta nyare rekord är den senaste ändringen (det kanske inte är officiellt).
S7
Startadress (uppsägning)
32-bitars adress 		No Denna post innehåller startexekveringsplatsen vid en 32-bitars adress. Detta används för att avsluta en serie S3-poster. Om en SREC-fil endast används för att programmera en minnesenhet och exekveringsplatsen ignoreras, kan en adress på noll användas.
S8
Startadress (uppsägning)
24-bitars adress 		No Denna post innehåller startexekveringsplatsen vid en 24-bitars adress. Detta används för att avsluta en serie S2-poster. Om en SREC-fil endast används för att programmera en minnesenhet och exekveringsplatsen ignoreras, kan en adress på noll användas.
S9
Startadress (uppsägning)
16-bitars adress 		No Denna post innehåller startexekveringsplatsen vid en 16-bitars adress. Detta används för att avsluta en serie S1-poster. Om en SREC-fil endast används för att programmera en minnesenhet och exekveringsplatsen ignoreras, kan en adress på noll användas.

Rekordordning

Även om viss Unix-dokumentation säger att "ordningen för S-poster i en fil är av ingen betydelse och ingen speciell ordning kan antas", har i praktiken de flesta program beställt SREC-posterna. Den typiska postordningen börjar med en (ibland valfri) S0-huvudpost, fortsätter med en sekvens av en eller flera S1/S2/S3-dataposter, kan ha en valfri S5/S6-räknepost och slutar med en lämplig S7/S8/ S9 uppsägningsrekord.

S19-stil 16-bitars adressposter
  1. S0
  2. S1 (en eller flera poster)
  3. S5 (valfritt rekord)
  4. S9
S28-stil 24-bitars adressposter
  1. S0
  2. S2 (en eller flera poster)
  3. S5 (valfritt rekord)
  4. S8
S37-stil 32-bitars adressposter
  1. S0
  2. S3 (en eller flera poster)
  3. S5 (valfritt rekord)
  4. S7

Begränsningar

Postlängd - Unix manualsidas dokumentation säger, "En S-record-fil består av en sekvens av speciellt formaterade ASCII-teckensträngar. En S-post kommer att vara mindre än eller lika med 78 byte lång". Manualsidan begränsar ytterligare antalet tecken i datafältet till 64 (eller 32 databyte). En post med en adress med 8 hexadecken och 64 datatecken skulle vara 78 (2 + 2 + 8 + 64 + 2) tecken lång (denna räkning ignorerar möjliga radslut- eller strängavslutningstecken). Filen kunde skrivas ut på en 80 tecken bred teleprinter. En notering längst ner på manualsidan säger: "Denna [manual sida] är det enda stället som en 78-byte-gräns för total postlängd eller 64-byte-gräns för datalängd dokumenteras. Dessa värden bör inte litas på för det allmänna fallet". Om den begränsningen ignoreras, är den maximala längden på en S-post 514 tecken, och om man antar ett byteantal på 0xFF (255), skulle det vara 2 för posttypfält + 2 för byteantalfält + (2 * 255) för Adress / Data / Kontrollsumma fält. Ytterligare buffertutrymme kan krävas för linje- och strängterminatorerna. Att använda långa radlängder har problem: "Motorolas S-record-formatdefinition tillåter upp till 255 byte nyttolast, eller rader med 514 tecken, plus radavslutningen. Alla EPROM-programmerare bör ha tillräckligt stora radbuffertar för att klara av så stora poster. Få gör det."

Datafält - Viss dokumentation rekommenderar maximalt 32 byte data (64 hexadecken) i detta fält. Minsta mängd data för S0/S1/S2/S3-poster är noll. Den maximala mängden data varierar beroende på storleken på adressfältet. Eftersom fältet Byte Count inte kan vara högre än 255 (0xFF), beräknas det maximala antalet byte med data med 255 minus (1 byte för kontrollsummafält) minus (antal byte i adressfältet). S0/S1-poster stöder upp till 252 byte data. S2-posten stöder upp till 251 byte data. S3-posten stöder upp till 250 byte data.

Kommentarer - SREC-filformatet stöder inte kommentarer. Vissa program ignorerar alla textrader som inte börjar med "S" och ignorerar all text efter kontrollsummafältet; att extra text ibland används (okompatibelt) för kommentarer. Till exempel stöder CCS PIC-kompilatorn att placera en ";" kommentarsraden längst upp eller längst ned i en Intel HEX- fil, och dess manualer säger "vissa programmerare (i synnerhet MPLAB) gillar inte kommentarer överst i hex-filen", vilket är anledningen till att kompilatorn har möjlighet att placera kommentaren längst ner i hex-filen.

Exempel

Färg legend

  Posttyp   Byteantal   Adress   Data   Kontrollsumma

Checksumma beräkning

Följande exempelpost:

 S1  13  7AF0  0A0A0D0000000000000000000000000000  61

avkodas för att visa hur kontrollsumman beräknas. I följande exempel används ett dollartecken ( $ ) för att indikera ett hexadecimalt värde (en Motorola-konvention):

  1. Lägg till: Lägg till varje byte $13 + $7A + $F0 + $0A + $0A + $0D + $00 + ... + $00 = $019E .
  2. Mask: Släng den mest signifikanta byten ( $01 ) av summan och behåll den minst signifikanta byten (LSB), som är $9E .
  3. Komplement: Beräkna ettornas komplement till LSB, vilket är $61 . Vanligtvis görs detta på Motorola 6800-mikroprocessorn med COM -instruktionen eller genom att exklusivt ELLER använda ackumulatorn med $FF .

16-bitars minnesadress 





 S0  0F  0000  68656C6C6F20202020200000  3C  S1  1F  0000  7C0802A6900100049421FFF07C6C1B787C8C23783C6000001  SC  8  600001  SC  8  600001  0B  FE5398000007D83637880010014382100107C0803A64E800020  E9  S1  11  0038  48656C6C6F20776F726C642E0A00  3  09  S00  309  S00  _

Se även

Vidare läsning

externa länkar

  • SRecord är en samling verktyg för att manipulera filer i SREC-format.
  • BIN2MOT , BINÄRT till Motorola S-Record filkonverteringsverktyg.
  • SRecordizer är ett verktyg för att visa, redigera och felkontrollera filer i S19-format.
  • bincopy är ett Python-paket för att manipulera filer i SREC-format.
  • kk_srec är ett C-bibliotek och program för att läsa SREC-formatet.
Hämtad från " https://en.wikipedia.org/w/index.php?title=SREC_(file_format)&oldid=1104715911 "