XMega can access data memory above 64KB, up to 16MB

[happylex]

In order to access program memory or data memory above 64KB, the address pointer must be larger than 16 bits. This is
done by concatenating one register to one of the X-, Y-, or Z-registers. This register then holds the most-significant byte
(MSB) in a 24-bit address or address pointer (Ref 1).

When I try to access this memory using a normal pointer it doesn't work. However, I think I can use a uint32_t as pointer:

Code: [Select]


uint32_t address = 0x00010000; // > 0xFFFF
uint8_t value = 5;
*(uint8_t *)adres = value;

uint_t read_value = 0;
read_value = *(uint8_t *)adres  // And indeed if I print read_value it shows 5.

For PROGMEM this seems to be done well by the compiler, but when I use this pointer in functions it messes up. Probably because it is converted to a 16-bit pointer. Who can help me to put variables above 64kB? And access these variables via normal functions?

I think it is a bit ridiculous to make products with 24-bit pointer hardware (Ref 1) and provide a compiler with 16-bit pointers (Ref 2). Probably the best solution is redesigning the board with an AVR32. 

References:
1. http://www.atmel.com/images/atmel-8331-8-and-16-bit-avr-microcontroller-xmega-au_manual.pdf
2. http://gcc.gnu.org/gcc-4.8/changes.html

[andyturk]

Probably the best solution is redesigning the board with an ARM Cortex mcu.

Fixed it for 'ya. :-)

[TerminalJack505]

You might look into named address spaces and see if they help. 

Here are a couple of threads (#1, #2) on AVRFreaks that discuss them.

A 32-bit MCU will probably be the simplest solution, however.

[dannyf]

I think it is a bit ridiculous to make products with 24-bit pointer hardware (Ref 1) and provide a compiler with 16-bit pointers (Ref 2).

To be fair to Atmel, they didn't exactly produce that compiler.

On the flip side, you can always use IAR-AVR.

[westfw]

gcc has a "model" of a CPU that it supports, and it pretty much requires any target support that model.  The model wants a "flat" address space with fixed size pointers and does NOT include "paged" memory architectures, which is why you'll never see gcc for an 8bit PIC.  The AVR is sort-of "barely" supported - one of the few 8bit micros that works at all.  Their implementation of more than 64k program space is kludgey, and their implementation of more than 64k of program space is essentially non-existent (as you noticed.)

I suppose that you could create an avr-gcc "variant" with 24 or 32bit pointers that handled the extended address space, but it would be using 24/32bit pointers and addresses everywhere, which would be unlikely to make anyone happy.

(This is essentially my decision path for 32-bit micros.  "Am I using enough memory that the address space issues become painful due to banking, paging, and etc?")

[dannyf]

How's this different from making DOS go over 640K?

I don't know the exact addressing framework on xmega but if it is done on x/y/z registers, could you just set the msb register to the right value (think of it as "paging") and use a 16-bit pointer as the offset within that page?

[Rick Law]

How's this different from making DOS go over 640K?

I don't know the exact addressing framework on xmega but if it is done on x/y/z registers, could you just set the msb register to the right value (think of it as "paging") and use a 16-bit pointer as the offset within that page?

DOS is ran in the 1Meg mode and is not capable of 24bit addressing.  For DOS to get extra memory, a part of memory below 1Meg is assigned for for EMM - typically 16K to 64K.  That part of memory would be divided into pages.  When EMM is used, a call is first made to map a selected page of the extra memory into the below-1M (visible) block.  So, for the duration of that mapping, the extra memory is in an address below 1M.

For 8088 and up, that mapping could be done within the CPU since 8088 and up has 24 bit addressing.  Prior to that with 8080/8085/z80 (16bits address), the add-on hardware in the EMM memory board does the mapping.  The number of pages will vary depending on your total extra memory available.

[westfw]

For 8088 and up, that mapping could be done within the CPU since 8088 and up has 24 bit addressing.

You are mistaken, and probably mean 80386.
The 8088 was the same cpu (and timeframe) as the original 8086, and had a 1M address space (in fact, it was the 8088 that was used in the original IBM PC.)
The 80286 had 24bit (physical) addresses, but it had a really awful MMU organization that made it hard to use.  (IIRC, "segment numbers" were put IN THE MIDDLE of an address, right about the time that everyone was agreeing that segments were dead and pages were the future.)

[miguelvp]

For 8088 and up, that mapping could be done within the CPU since 8088 and up has 24 bit addressing.

You are mistaken, and probably mean 80386.
The 8088 was the same cpu (and timeframe) as the original 8086, and had a 1M address space (in fact, it was the 8088 that was used in the original IBM PC.)
The 80286 had 24bit (physical) addresses, but it had a really awful MMU organization that made it hard to use.  (IIRC, "segment numbers" were put IN THE MIDDLE of an address, right about the time that everyone was agreeing that segments were dead and pages were the future.)

You are right on the 1MB address space (2^20), the nightmares!!! It was all segmented in 64KB linear address spaces and it was a real PITA.

But even so, the 640KB limit could be changed to 704KB if there was memory present between the video card and the ram. I still have the code to switch it (not my code might be borlands or masm sample)

Code: [Select]

PAGE ,132
TITLE 704K - set memory to 704K bytes
COMMENT *
Increase memory to 704K bytes by changing
BIOS data word at 40:13 hex
Set new memory to zero
April 14,1987
*
INCLUDE mylib.equ
IF1
INCLUDE mylib.mac
ENDIF

old_siz EQU 640 ;old mem size
new_siz EQU 704 ;new mem size
new_seg EQU 0A000h ;704K segment

; BIOS data area
bios_d SEGMENT AT 40h
ORG 13h
mem_siz LABEL WORD ;memory size
bios_d ENDS

code SEGMENT
ASSUME CS:code, DS:code, ES:bios_d
ORG 100h
strt:
@head ' MEM704,04.14.87 '
; point to memory size in BIOS data area
MOV AX,bios_d ;zero
MOV ES,AX
MOV SI,OFFSET mem_siz
; check if already run
CMP WORD PTR ES:[SI],new_siz
JNE ok
@go_dos ;quit
; check for memory at A000 hex
ok:
MOV BX,ES ;save ES
MOV AX,new_seg
MOV ES,AX ;ES=A000
XOR DI,DI ;offset
MOV ES:[DI],AH ;55 hex
CMP AH,ES:[DI] ;ok?
JNZ no_mem ;no
MOV ES:[DI],AL ;AA hex
CMP AL,ES:[DI] ;ok?
JNZ no_mem ;no
; set memory size for 704K bytes
MOV CX,ES ;save ES
MOV ES,BX ;ES=40
MOV WORD PTR ES:[SI],new_siz
MOV ES,CX ;ES=A000
; fill new memory with zeros
XOR AX,AX ;zero word
MOV DI,AX ;zero location
MOV CX,8000h ;32K words
REP STOSW ;do it
@write <' Memory now 704K bytes',cr,lf>
INT 19h ;reboot system
; no memoty at A000 hex, terminate without change
no_mem:
@write 'no memory at A000 hex, aborting'
@go_dos

code ENDS
END strt

Edit: but that was IBM's implementation not sure if you could change the memory architecture to increase the number of segments, will have to look it up if the segments could be changed to go from 20 bit address space to 24 bits, but the PC used 20 bits total after segmentation.

Edit answer: after a short research, it couldn't go past 20 bits address space so 1MB was the limit with the rom living on the higher area. (and yes, I have the complete disassemble of the original IBM Rom in some binder in my office)

Edit2: apparently that code came from Byte Magazine but it mentions 1986 mine says 1987.
https://archive.org/stream/198610ByteMagazineVol1111InsideTheIBMPC/198610%20Byte%20Magazine%20Vol%2011-11%20Inside%20the%20IBM%20PC_djvu.txt#BYTE 1 986 Extra Edition • Inside the IBM PCs

Isn't google wonderful that you can look for code that is older than the internet?


But back to topic, unless you don't have physical address pins that you can segment and combine with the standard address spaces using multiplexers to get to the right banks you can't go over the limit.

And that doesn't take into account code and data prefetching because the fabric of the processor might not allow you to use some io pins to multiplex external chip selects to increase memory but I have not look at the datasheet to see if the XMega has prefetching built in and what the implications are for the toolchain etc.

[miguelvp]

Took a quick look at the xmega manual linked above and it seems it does support up to 16MB external SRAM, SDRAM and Peripheral and other memory mapped devices via an External Bus Interface. Look in section:

27. EBI – External Bus Interface

Edit: there is also reference to the RAMPD register for accessing data with a 24 bit address, not sure if related to the EBI.

[westfw]

xmega ... does support up to 16MB external SRAM

Yes.  But it's only accessible via a banking scheme, and the avr-gcc C compiler doesn't support it and only has 16bit pointers, so it's not much good.  I thought that's what this conversation was about?!

[dannyf]

Looks like the limitless gcc-avr finally met its limits. Maybe you can try a real compiler, like iar?

seriously, RAMPx is the way to go.

[dannyf]

Aside from iar, cvavr also supports 16bit or more pointers. They are considerably more affordable, however.

not sure about iccavr. Also worth checking our mikroe or Rowley ...

no need to hang yourself in gcc.

[dannyf]

ICCAVR doesnot handle 24-bit pointers directly. However, it offers an approach to page through those RAMPx registers (similar to what I suggested earlier) and offers a set of routines that read from / write to the space.

Both ICCAVR and CVAVR are fairly inexpensive (vs. IAR).

[Rick Law]

For 8088 and up, that mapping could be done within the CPU since 8088 and up has 24 bit addressing.

You are mistaken, and probably mean 80386.
The 8088 was the same cpu (and timeframe) as the original 8086, and had a 1M address space (in fact, it was the 8088 that was used in the original IBM PC.)
The 80286 had 24bit (physical) addresses, but it had a really awful MMU organization that made it hard to use.  (IIRC, "segment numbers" were put IN THE MIDDLE of an address, right about the time that everyone was agreeing that segments were dead and pages were the future.)

You are absolutely right.  Finger faster than brain problem here.

The 8088 is the 8086 with 8 bit lines rather than 16 lines and both are 20-bit addressing.  I hated that segment registers so much I just can't get it out of my head.  I would have preferred the "segment" to be just the most-significant-bits of the second word.

The 80286 has another problem I recall : to switch mode, you have to reset (reboot the CPU).  The 386 was when it really begin to grow up.