AVR Freaks

Von Neuman architecture compilers (including gcc) generally just put all "const" data (inc literal strings) into ROM/Flash, or have an option to do so.  Perhaps whatever hack avr-gcc uses to put const data in RAM can simply be turned off?

 

Edit:  Oh wait - perhaps not.   Addresses in .text are zero-based, but when accessed as data, they appear at a different offset...

Followup.  Apparently I was worried about an issues that has been solved for a long time.

Avr-gcc already has an "architecture" defined for AVRs like the ATmega4809

"const" data, including literal strings, goes off into the .rodata section, with symbols appropriately offset and accessible via "ld" instructions.

If you're using one of the chips with a unified 64k address space, you shouldn't need PROGMEM or __flash...

-mmcu=atxmega3

avrxmega3

“XMEGA” devices with up to 64 KiB of combined program memory and RAM, and with program memory visible in the RAM address space.

This does indeed appear to do the desirable thing with data that is merely "const" (including literal strings), and subsequent tools also behave as desired.

#include <avr/io.h>
#include <avr/pgmspace.h>
#include <stdio.h>

const char s[] = "this is a const string";
const char PROGMEM p[] = "this is a progmem string";
const char __attribute__((section(".text"))) t[] = "this is a .text string";
const char __flash f[] = "this is a __flash string";

int main() {
    printf("%s\n", s);
    printf("%s\n", p);
    printf("%s\n", t);
    printf("this is a constant literal string.");
}

Compile with "avr-gcc -mmcu=atmega4809 -g -Os foo.c", copy to .hex with "avr-objcopy -O ihex -R .eeprom a.out a.hex"

(edited) "avr-nm -S -n" output:

000000a0 T __trampolines_end
000000a0 T __trampolines_start
  :
000000a0 00000019 T f          *** __flash string ***
000000b9 00000019 T p          *** progmem string ***
000000d2 T __ctors_end
000000d2 W __init
000000de 00000010 T __do_clear_bss
000000f6 T __bad_interrupt
000000f6 W __vector_1
  :
000000f6 W __vector_9
000000fa 00000017 T t
00000112 0000002e T main
  :
00000752 t __stop_program
00000754 T _etext
  :
00004000 A __RODATA_PM_OFFSET__
00004754 00000017 R s       *** const string *** (note == _etext!) ***

Edited Output from "avr-objdump -s a.out":

Contents of section .text:
   :
 0090 0c947b00 0c947b00 0c947b00 0c947b00  ..{...{...{...{.
 00a0 74686973 20697320 61205f5f 666c6173  this is a __flas
 00b0 68207374 72696e67 00746869 73206973  h string.this is
 00c0 20612070 726f676d 656d2073 7472696e   a progmem strin
 00d0 67001124 1fbecfef cdbfdfe3 debf28e2  g..$..........(.
 00e0 a0e0b8e2 01c01d92 a630b207 e1f70e94  .........0......
 00f0 89000c94 a8030c94 00007468 69732069  ..........this i
 0100 73206120 2e746578 74207374 72696e67  s a .text string
 0110 000084e5 97e40e94 b60089eb 90e00e94  ................
   :

Contents of section .rodata:
 4754 74686973 20697320 6120636f 6e737420  this is a const 
 4764 73747269 6e670074 68697320 69732061  string.this is a
 4774 20636f6e 7374616e 74206c69 74657261   constant litera
 4784 6c207374 72696e67 2e00               l string..        *** Where we want it! ***

edited output from "avr-objdump -s a.hex"

Contents of section .sec1:
 0000 0c946900 0c947b00 0c947b00 0c947b00  ..i...{...{...{.
   :
 00a0 74686973 20697320 61205f5f 666c6173  this is a __flas
 00b0 68207374 72696e67 00746869 73206973  h string.this is
 00c0 20612070 726f676d 656d2073 7472696e   a progmem strin
 00d0 67001124 1fbecfef cdbfdfe3 debf28e2  g..$..........(.
 00e0 a0e0b8e2 01c01d92 a630b207 e1f70e94  .........0......
 00f0 89000c94 a8030c94 00007468 69732069  ..........this i
 0100 73206120 2e746578 74207374 72696e67  s a .text string
   :
 0740 aa81b981 ce0fd11d cdbfdebf ed010895  ................
 0750 f894ffcf 74686973 20697320 6120636f  ....this is a co   *** Where we want
 0760 6e737420 73747269 6e670074 68697320  nst string.this    ***  this in flash
 0770 69732061 20636f6e 7374616e 74206c69  is a constant li
 0780 74657261 6c207374 72696e67 2e00      teral string..  

one could hope that there would come a new version of AT94K chips, they are so far the only AVR's that run code from RAM

why would you run code from RAM in most cases a simple interpreter would do a fine job (about the speed of C code).

No. Take a look at the memory map for the Mega4809 for example, the program memory is placed at the top of the memory space. Since the program counter can only address the code space, it can't see the other memory types that are at lower addresses.

However, to address 48k of flash (24k words) the PC must be 15 bit. So we can place values addressing 48k-64k there. I wonder how that is handled...

It's actually surprise me that a 4809 is 14% faster than a XMEGA (at same clk speed)

add:

But since they use the IAR compiler it's not relevant for many of us.

Cool, that guy figured out a way of combining my jtag2updi UPDI programmer with the Arduino Uno WiFi R2 software package, that supports Mega4809.

I suspected it could be done in theory, but never actually decided to do it, my knowledge of the intricacies of Arduino IDE configuration files is not that good.

I'll link to his method: https://hackaday.io/project/1348...

So what's the story with this "AT90SCR400"? This is an AVR, but not made by Microchip. It's from some small company called Wisekey.

They even have a dual-core AVR 

Ok; That's nice!  I was wondering whether Microchip would bring in more DIP packages, seeing as they still do a fair number of DIP PICs...

DIP is clearly not highest volume package, but once a product range is release to the largest customers (aka in SMD), it makes sense to look around for lower run size users.

There are likely enough numbers in the education and smaller run sizes to do selective DIP, especially if marketing also get on board and can see the benefits.

IIRC years ago we asked a large semi company, what volumes they needed to release a new package, and it was around 50k

Found on Microchip's  ATMEGA4809 page  http://www.microchip.com/wwwproducts/en/ATMEGA4809

Under the Documents tab:   40-pin-Data-Sheet-megaAVR-0-series-DS40002104A.pdf   77 pages.

http://ww1.microchip.com/downloads/en/DeviceDoc/40-pin-Data-Sheet-megaAVR-0-series-DS40002104A.pdf

This has not yet appeared on the Product Change Notifications page.

This is interesting:

Important:  The 40-pin version of the ATmega4809 is using the die of the 48-pin ATmega4809 but offers fewer connected pads. For this reason, the pins PB[5:0] and PC[7:6] must be disabled (INPUT_DISABLE) or enable pull-ups (PULLUPEN).

PORTB is used by USART3. So this means USART3 is on the die, but not connected. In other words, the DIP version of the mega4809 has 4 USARTS, but only 3 are usable.

It might still be possible to redirect the output of TX3 to an event output or CCL output, But RX3 will be mostly unusable.