el . ¿El archivo hexadecimal que grabamos va a la memoria flash o RAM o EEPROM de Atmega8?

La memoria flash de atmega8 es de 8Kb.

¿Es este el tamaño máximo para el archivo .hex, o es la memoria máxima que puedo asignar a las variables en mi código?

Si nada de lo anterior es cierto, ¿cuál es la estructura de asignación de memoria de Atmega8? ¿A qué memoria va el archivo .hex?

Respuestas (3)

En el uso estándar, su código va a los 8 Kbytes de memoria Flash y las variables van a los 1 Kbyte de SRAM. Tenga en cuenta que debido a que un archivo hexadecimal representa un solo byte como un par de caracteres hexadecimales y contiene otra información, tendrá más del doble del tamaño del código real que se cargará, por lo que debería cargarse un archivo hexadecimal de un poco más de 16K.

El lugar más confiable para encontrar mucho Flash y SRAM que usa su código es desde el compilador. Si está utilizando Atmel Studio 6 en el área de salida de compilación, si se desplaza hacia arriba, debería ver algo como:

Uso de memoria de programa: 540 bytes 0,8 % completo

Uso de memoria de datos: 0 bytes 0,0 % lleno

Entonces, el uso de la memoria del programa muestra la cantidad de Flash que se usará y el uso de la memoria de datos muestra la cantidad de SRAM que se usará.

¿Y la EEPROM? ¿Se puede incluir en el maleficio?
@CamilStaps, a menos que haya cambiado recientemente, la mayoría de los compiladores de Atmel lo mantienen en un archivo separado.
muy, muy gracias a usted @peterj. En realidad, esta es la estructura que quiero saber. Por cierto, estoy codificando en cvAVR. Por favor, dígame dónde verificar esto. Además, ¿qué sucederá si el tamaño de mi código excede la memoria flash?
@shafeeq, ha pasado mucho tiempo desde que usé cvAVR, pero creo que necesita encontrar dónde activar las opciones de archivo de lista o de mapa en el proyecto y luego obtendrá un archivo .map o .lst que lo contiene Cuando se agote, obtendrá un error del compilador, no dañará nada, simplemente no podrá cargarlo.
entonces @PeterJ no sucederá nada como esto, ya que solo esa parte del código se carga hasta que se llena la memoria y luego el código restante se omite y cuando ejecutamos MCU se comporta de manera anormal.
@shafeeq, tal vez cvAVR no realiza un seguimiento del tamaño del chip de destino como las herramientas Atmel, en ese caso, lo que ha dicho sería correcto y perdería el final del código. Puede valer la pena probar Atmel Studio: puede generar un código más pequeño (no estoy seguro de que deba probarlo).
sí, @PeterJ, también lo intenté, pero después de cvavr, pero el código de cvavr que se compila perfectamente en cv da un error de compilación en Atmel Studio, así que lo dejé.

La memoria flash es su memoria de programa. Ahí sería donde se almacena su archivo hexadecimal. Puede forzar los datos en flash si tiene poca RAM, pero no es tan rápido de leer/escribir como la RAM.

La RAM es la memoria utilizada en tiempo de ejecución, para variables y cualquier otra cosa a la que se deba acceder sobre la marcha.

EEPROM es una memoria no volátil para almacenar cosas como datos de calibración, números de serie, etc. Rara vez se usa para cualquier cosa que deba escribirse con regularidad.

entonces @matt .hex va a flash y durante la ejecución las variables se crean en la RAM, se usan y luego se descomponen. El uso de EEPROM es para almacenar datos de variables globales o constantes del programa. ¿Es la estructura completa? si esto no es así, por favor dígame la interpretación correcta del conocimiento anterior.
Si bien cualquier programa depende de Flash (código) y SRAM (montón/pila variable) para ejecutarse, el uso de la EEPROM es completamente opcional. EEPROM se usa comúnmente para almacenar datos de configuración, por ejemplo.

Para conocer el uso real de la memoria, consulte el archivo de mapa. En el caso de la cadena de herramientas GCC que lo hace por enlazador como:

avr-ld -Map=app.map

o a través gccdel conductor:

avr-gcc -Wl,-Map,app.map
el . ¿El archivo hexadecimal que grabamos va a la memoria flash o RAM o EEPROM de Atmega8?
RespuestasAquíPolítica de privacidad1y, 1v