Hispanopedia Wiki
Articulo de referencia

Motorola S-record

.s19 , .s28 , .s37 , .s , .s1 , .s2 , .s3 , .sx , .srec , .exo , .mot , .mxt "},"mime":{"wt":""},"developer":{"wt":"Motorola"},"type":{"wt":""},"url":{"wt":""}},"i":0}}]}"> Moto...

Hispanopedia WikiContenido en espanolLectura gratuita

Motorola S-record es un formato de archivo, creado por Motorola a mediados de la década de 1970, que transmite información binaria como valores hexadecimales en formato de texto ASCII . Este formato de archivo también se conoce como SRECORD , SREC , S19 , S28 y S37 . Se utiliza comúnmente para programar memoria flash en microcontroladores, EPROM , EEPROM y otros tipos de dispositivos lógicos programables. En una aplicación típica, un compilador o ensamblador convierte el código fuente de un programa (como C o lenguaje ensamblador) a código máquina y lo guarda en un archivo HEX. Posteriormente, un programador importa el archivo HEX para escribir el código máquina en la memoria no volátil o lo transfiere al sistema de destino para su carga y ejecución.

Descripción general

Historia

El formato S-record se creó a mediados de la década de 1970 para el procesador Motorola 6800. Las herramientas de desarrollo de software para este y otros procesadores embebidos generaban código y datos ejecutables en formato S-record. Los programadores de PROM leían este formato y grababan los datos en las PROM o EPROM utilizadas en el sistema embebido. Posteriormente, el formato S-record básico se amplió para admitir direcciones de 24 y 32 bits, garantizando así la compatibilidad con la serie de microprocesadores MC68000 .

Otros formatos hexadecimales

Existen otros formatos de codificación ASCII con un propósito similar. BPNF , BHLF y B10F fueron formatos binarios primitivos, pero no son ni compactos ni flexibles. Los formatos hexadecimales son más compactos porque representan 4 bits en lugar de 1 bit por carácter. Muchos, como el registro S, son más flexibles porque incluyen información de dirección, lo que permite especificar solo una parte de una PROM. El formato Intel HEX se usaba frecuentemente con procesadores Intel. TekHex es otro formato hexadecimal que puede incluir una tabla de símbolos para la depuración.

Formato

Estructura del registro

Un archivo en formato SREC consta de una serie de registros de texto ASCII . Los registros tienen la siguiente estructura de izquierda a derecha:

  1. Inicio del registro : cada registro comienza con la letra mayúscula "S" (ASCII 0x53), que significa "Inicio del registro". [ 2 ]
  2. Tipo de registro : un único dígito numérico del "0" al "9" (ASCII 0x30 a 0x39) que define el tipo de registro. Véase la tabla a continuación.
  3. Recuento de bytes : dos dígitos hexadecimales ("00" a "FF") que indican la cantidad de bytes (pares de dígitos hexadecimales) que siguen en el resto del registro (dirección + datos + suma de verificación). Este campo tiene un valor mínimo de 3 (2 para un campo de dirección de 16 bits más 1 byte de suma de verificación) y un valor máximo de 255 (0xFF). Los valores "00", "01" y "02" no son válidos.
  4. Dirección : cuatro, seis u ocho dígitos hexadecimales, según el tipo de registro. Los bytes de la dirección están organizados en formato big-endian .
  5. Datos : una secuencia de 2n dígitos hexadecimales, para n bytes de datos. Para los registros S1/S2/S3, un máximo de 32 bytes por registro es lo habitual, ya que cabe en una pantalla de terminal de 80 caracteres de ancho, aunque 16 bytes facilitarían la decodificación visual de cada byte en una dirección específica.
  6. Suma de verificación : dos dígitos hexadecimales, el byte menos significativo del complemento a uno de la suma de los valores representados por los dos pares de dígitos hexadecimales para los campos Recuento de bytes, Dirección y Datos. En el lenguaje de programación C , la suma se convierte en la suma de verificación mediante:0xFF - (sum & 0xFF)

Terminadores de línea de texto

Los registros SREC están separados por uno o más caracteres de terminación de línea ASCII, de modo que cada registro aparece solo en una línea de texto. Esto mejora la legibilidad al delimitar visualmente los registros y, además, proporciona espacio entre ellos que puede utilizarse para mejorar la eficiencia del análisis sintáctico automático .

Los programas que crean registros HEX suelen usar caracteres de terminación de línea que se ajustan a las convenciones de sus sistemas operativos . Por ejemplo, los programas de Linux usan un solo carácter LF ( salto de línea , valor ASCII 0x0A) para terminar las líneas, mientras que los programas de Windows usan un carácter CR ( retorno de carro , valor ASCII 0x0D) seguido de un carácter LF.

Tipos de registro

La siguiente tabla describe los 10 tipos posibles de registros S.

Orden de registro

Aunque algunos documentos de Unix afirman que "el orden de los registros S dentro de un archivo no tiene importancia y no se puede asumir ningún orden en particular" [ 4 ] , en la práctica la mayoría del software ha ordenado los registros SREC. El orden típico de los registros comienza con un registro de encabezado S0 (a veces opcional), continúa con una secuencia de uno o más registros de datos S1/S2/S3, puede tener un registro de conteo S5/S6 opcional y termina con un registro de terminación S7/S8/S9 apropiado.

Registros de direcciones de 16 bits estilo S19
  1. S0
  2. S1 (uno o más registros)
  3. S5 (registro opcional)
  4. S9
Registros de direcciones de 24 bits estilo S28
  1. S0
  2. S2 (uno o más registros)
  3. S5 (registro opcional)
  4. S8
Registros de direcciones de 32 bits estilo S37
  1. S0
  2. S3 (uno o más registros)
  3. S5 (registro opcional)
  4. S7

Limitaciones

Duración récord

Una página del manual de la documentación histórica del sistema operativo Unix indica: «Un archivo de registro S consiste en una secuencia de cadenas de caracteres ASCII con formato especial . Un registro S tendrá una longitud menor o igual a 78 bytes». La página del manual limita además el número de caracteres en el campo Datos a 64 (o 32 bytes de datos). [ 4 ] Un registro con una dirección de 8 caracteres hexadecimales y 64 caracteres de datos tendría una longitud de 78 (2 + 2 + 8 + 64 + 2) caracteres (este recuento ignora los posibles caracteres de fin de línea o de terminación de cadena) y cabe en un teletipo de 80 caracteres de ancho . Una nota al pie de la página del manual indica: «Esta página del manual es el único lugar donde se documenta un límite de 78 bytes para la longitud total del registro o un límite de 64 bytes para la longitud de los datos. No se debe confiar en estos valores para el caso general». [ 4 ]

Si se ignora el límite histórico de 78 bytes, la longitud máxima de un registro S sería de 514 caracteres. Suponiendo un recuento de bytes de 0xFF (255), sería 2 para el campo Tipo de registro + 2 para el campo Recuento de bytes + (2 * 255) para los campos Dirección / Datos / Suma de verificación. Puede ser necesario espacio de búfer adicional para almacenar hasta dos caracteres de control ( retorno de carro y/o salto de línea ) y/o un terminador de cadena NUL (0x00) para los lenguajes de programación C/C++. El uso de longitudes de línea largas presenta problemas: "La definición del formato de registro S de Motorola permite hasta 255 bytes de carga útil, o líneas de 514 caracteres, más la terminación de línea. Todos los programadores de EPROM deberían tener búferes de línea suficientemente grandes para manejar registros de este tamaño. Pocos lo hacen." [ 6 ]

Campo de datos

La cantidad mínima de datos para los registros S0/S1/S2/S3 es cero.

Algunos documentos históricos recomiendan un máximo de 32 bytes de datos (64 caracteres hexadecimales) en este campo [ 4 ] (quizás porque 32 es la mayor potencia de 2 de datos que cabría en una teleimpresora / terminal de computadora / tarjeta perforada de 80 columnas de ancho ).

Si se ignora el límite histórico de 32 bytes, la cantidad máxima de datos varía según el tamaño del campo de dirección (4 / 6 / 8). El número máximo de bytes de datos se calcula restando (1 byte para el campo de suma de verificación) al número de bytes en el campo de dirección (255), por lo que la cantidad máxima de datos para cada tipo de registro es: 252 bytes de datos (504 caracteres hexadecimales) para los registros S0 y S1, 251 bytes de datos (502 caracteres hexadecimales) para los registros S2 y 250 bytes de datos (500 caracteres hexadecimales) para los registros S3.

Comentarios

Other than ASCII-to-hex converted comments in S0 header records, the SREC file format doesn't officially support human-readable ASCII comments, though some software ignores all lines that don't start with "S" and/or ignores all text after the Checksum field (thus trailing text is sometimes used (incompatibly) for comments). For example, the CCS PIC compiler supports placing a ";" comment line at the top or bottom of an Intel HEX file, and its manuals states "some programmers (MPLAB in particular) do not like comments at the top of the hex file", which is why the compiler has the option of placing the comment at the bottom of the hex file.[7]

Examples

Color legend

  Record type  Byte count  Address  Data  Checksum

Checksum calculation

The following example record:

S1137AF00A0A0D0000000000000000000000000061

is decoded to show how the checksum value is calculated. The following example uses a dollar sign ($) to indicate a hexadecimal value (a Motorola convention):

  1. Add: Add each byte $13 + $7A + $F0 + $0A + $0A + $0D + $00 + ... + $00 = $019E sum.
  2. Mask: Discard the most significant byte ($01) of the sum and retain the least significant byte (LSB), which is $9E.
  3. Complement: Compute the ones' complement of the LSB, which is $61.

In the C programming language, the sum is converted into the checksum by: 0xFF-(sum&0xFF)

16-bit memory address

S00F000068656C6C6F202020202000003CS11F00007C0802A6900100049421FFF07C6C1B787C8C23783C6000003863000026S11F001C4BFFFFE5398000007D83637880010014382100107C0803A64E800020E9S111003848656C6C6F20776F726C642E0A0042S5030003F9S9030000FC

See also

References

  1. ↑"AR#476 PROMGen - Description of PROM/EEPROM file formats: MCS, EXO, HEX, and others". Xilinx. 2010-03-08. Motorola EXORmacs - File Format Code 87. Archived from the original on 2020-03-03. Retrieved 2020-03-03.
  2. ↑ Wiles, Mike; Felix, Andre (21-10-2000) [1975]. Holley, Michael (ed.). MCM6830L7 MIKBUG / MINIBUG ROM (PDF) (Nota de ingeniería). Motorola Semiconductor Products, Inc. Nota 100. Archivado del original (PDF) el 16-06-2019 . Recuperado el 16-06-2019 .(23 páginas)
  3. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 "Apéndice C" . Manual de referencia del programador de la familia M68000 . Revisión 1. Motorola . 1992. págs. C-1 – C-5 . ISBN  978-0-13723289-5.
  4. 1 2 3 4 5 6 7 8 9 10 11 12 13 "Registros S de Motorola (página man de UNIX y comentarios)" . Programador en sistema Uisp AVR . Archivado del original el 3 de julio de 2002.
  5. ↑ Hennig-Roleff, Werner (1993-02-01) [1988]. "HEX.DOC: Motorola - HEX Format" . SIM51 . 1.04 (en alemán). Archivado del original el 11 de agosto de 2017. Recuperado el 8 de diciembre de 2021 .(Nota: Esta es una versión anterior de SIM51; el software y la documentación se mantuvieron actualizados hasta 1996).
  6. ↑ "srec_examples y srec_cat" . SourceForge . Archivado del original el 27 de enero de 2013.
  7. ↑ Manual de referencia del compilador CCS PCB/PCM/PCH (PDF) , Custom Computer Services, Inc. , mayo de 2014, pág. 142 , consultado el 8 de febrero de 2015. 

Lecturas adicionales

  • "2.8. Formatos de microprocesador 2.8.1. Requisitos de entrada: formato Motorola Exorciser. Seleccione el código 82". Guía del operador para las capacidades de E/S serie de los programadores de E/S de datos - Paquete de formato de traducción (PDF) . Revisión C. Data I/O Corporation . Octubre de 1980. págs. 2–9 . 055-1901. Archivado (PDF) del original el 1 de marzo de 2020. Recuperado el 1 de marzo de 2020 . 
  • Manual del usuario del módulo de evaluación M1468705EVM (1.ª ed.). Motorola Inc. Diciembre de 1983. M1468705EVM/Dl . Consultado el 1 de marzo de 2020 .
  • Formatos de archivos de traducción . Data I/O Corporation . 3 de septiembre de 1987. Archivado del original el 1 de marzo de 2020. Consultado el 1 de marzo de 2020 .(56 páginas)
  • Feichtinger, Herwig (1987). "1.8.5. Lochstreifen-Datenformate: Das Motorola-S-Format" [ 1.8.5. Formatos de datos de cinta de papel ] . Arbeitsbuch Mikrocomputer [ Libro de trabajo sobre microcomputadoras ] (en alemán) (2  ed.). Múnich, Alemania: Franzis-Verlag GmbH . págs.  240-243 [242]. ISBN 3-7723-8022-0.
  • «Apéndice A. Información del registro S». Manual del usuario del módulo de evaluación M68HC05EVM (PDF) (4.ª  ed.). Motorola . 1990. pág.  A-1. […] Para garantizar la compatibilidad con los teletipos, algunos programas pueden limitar el número de bytes [de datos] a tan solo 28 (56 caracteres imprimibles en el registro S). […]
  • ¿Cómo interpreto los datos con formato HEX de Motorola S e Intel? Registros S de Motorola . Inicio > Hardware > … > Sistemas de prueba en circuito > Equipos de prueba automatizados [Descontinuado] > Detalles . Keysight Technologies . Archivado del original el 1 de marzo de 2020. Consultado el 1 de marzo de 2020 .
  • Beard, Brian (2016) [2007]. "Formato de grabación Motorola S" . Lucid Technologies . Archivado del original el 28 de febrero de 2020. Recuperado el 28 de febrero de 2020 .
  • Strombergson, Joachim; Walleij, Linus; Faltstrom, Patrik (octubre de 2005). "El formato S Hexdump" . IETF . RFC 4194. Archivado del original el 1 de marzo de 2020. Recuperado el 1 de marzo de 2020 . 
  • SRecord es un conjunto de herramientas para manipular archivos en formato SREC.
  • BIN2MOT , utilidad convertidora de archivos binarios a archivos Motorola S-Record.
  • SRecordizer es una herramienta para visualizar, editar y comprobar errores en archivos con formato S19.
  • bincopy es un paquete de Python para manipular archivos en formato SREC.
  • kk_srec es una biblioteca y un programa en C para leer el formato SREC.