How to find devices that can use external RAM

Go To Last Post
18 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are there a way to find all the 8bit AVR's that can run with external RAM ?

(the atmel chip selector don't pick them up with external buss).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can grep the .h files in the C file for a control register/bit that's commonly found in Extmem devices (if there is a common register/bit ??)

 

EDIT: Something like this perhaps:

/usr/lib/avr/include/avr$ grep -w SRE iom*.h
iom103.h:#define    SRE          7
iom128.h:#define    SRE          7
iom161.h:#define SRE	7
iom162.h:#define SRE	7
iom32u6.h:#define SRE 7
iom64.h:#define    SRE          7
iom8515.h:#define    SRE          7
iomxx0_1.h:#define SRE     7

Then again perhaps "SRE" is not the best symbol to search for? Perhaps other devices have an "enable" bit with a different name?

Last Edited: Wed. May 20, 2015 - 11:44 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I noticed that the selector only found xmegas with external memory bus. I sent a message to atmel, and got an email from a fellow asking what filters I was using, which seemed like one of those questions that didnt have to be asked. Weeks later, I am reassured to see that I was not the only person in the world fighting with the atmel device selector. It hasnt been changed yet.

 

 

Imagecraft compiler user

Last Edited: Wed. May 20, 2015 - 06:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No Atmel's "help" are really bad :(

 

It must cost them a lot, but I guess that somewhere there are one at Atmel that say: see what we have saved this quarter by closing the service department.

 

And I remember in the past, when Atmel.com linked to avrfreaks for help!

Last Edited: Wed. May 20, 2015 - 12:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

EDIT: Something like this perhaps:...

 Hmmm--did that filter miss the Mega640 family?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just checked 640 family for external memory and had a hard time finding it, it's placed on the main page under – "Programming Lock for Software Security" !!! 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just checked 640 family for external memory and had a hard time finding it, it's placed on the main page under – "Programming Lock for Software Security" !!! 

???

 

...

...and so on.  Is it in block diagrams?  Dunno; not an AVR8 external memory person.  I'd suspect most of the information in the '640 family datasheet is identical or nearly so to the venerable '103 and '128.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

:)

Front page of datasheet:

 

Nobody have checked what the schoolkid pasted !!!

And that is why it's missing in the selector aswell I guess

Last Edited: Wed. May 20, 2015 - 02:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Indeed, '128 is better formatted

But if you put "external memory" into your PDF reader's Find box, won't it find the front-page note as well as the chapter?

 

(and/or Cliff's "SRE"?)

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes because it's the original 103 format. (and last time I used external RAM was for a 8515 and there it's written the same way)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 Hmmm--did that filter miss the Mega640 family?

Umm no....

/usr/lib/avr/include/avr$ grep -w SRE iom*.h
iom103.h:#define    SRE          7
iom128.h:#define    SRE          7
iom161.h:#define SRE	7
iom162.h:#define SRE	7
iom32u6.h:#define SRE 7
iom64.h:#define    SRE          7
iom8515.h:#define    SRE          7
iomxx0_1.h:#define SRE     7

further highlighted by:

/usr/lib/avr/include/avr$ grep "iomxx0_1.h" iom*.h
iom1280.h:#include <avr/iomxx0_1.h>
iom1281.h:#include <avr/iomxx0_1.h>
iom2560.h:#include <avr/iomxx0_1.h>
iom2561.h:#include <avr/iomxx0_1.h>
iom640.h:#include <avr/iomxx0_1.h>
iomxx0_1.h:/* $Id: iomxx0_1.h 2102 2010-03-16 22:52:39Z joerg_wunsch $ */
iomxx0_1.h:/* avr/iomxx0_1.h - definitions for ATmega640, Atmega1280, ATmega1281,
iomxx0_1.h:#  define _AVR_IOXXX_H_ "iomxx0_1.h"

Apologies - I sort of assumed people might know/realise that iomxx0_1 was a collective header for 640/1280/1281/2560/2561

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just to be sure, can the stack pointer point to external RAM?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

On this page:

 

http://www.nongnu.org/avr-libc/u...

 

In the section about "Internal vs. external RAM" it says this:

 

If external RAM is available, it is strongly recommended to move the heap into the external RAM, regardless of whether or not the variables from the .data and .bss sections are also going to be located there. The stack should always be kept in internal RAM. Some devices even require this, and in general, internal RAM can be accessed faster since no extra wait states are required. When using dynamic memory allocation and stack and heap are separated in distinct memory areas, this is the safest way to avoid a stack-heap collision.

I have no idea what motivated the author to make that state though?! Perhaps he's simply worried about wait state efficiency? Or maybe there really is some technical reason SP should always be internal? It does say "some devices even require this" - wonder which ones and why?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I keep a text copy of each of the pdf datasheets (and pdf summaries) from the Techlib DVD on hand (generated with pdftotext) for easy command line searching.  A grep -ril "external *memory" . | sort yields:

./128RFA1_D0712.pdf.txt
./90CAN32_64_128_E0707.pdf.txt
./90USB128x_64x_L1208.pdf.txt
./90USB128x_64x_m32U6_J0309.pdf.txt
./Auto_90CAN32_64_128_A0107.pdf.txt
./Auto_m164P_324P_644P_B0208.pdf.txt
./m1284P_D1109.pdf.txt
./m128A_H0211.pdf.txt
./m128RFA1_C0811.pdf.txt
./m128_X0611.pdf.txt
./m162_K0709.pdf.txt
./m164P_324P_644P_O0710.pdf.txt
./m16U4_32U4_F1110.pdf.txt
./m640_1281_1280_2561_2560_P1012.pdf.txt
./m644_O0212.pdf.txt
./m64A_C0709.pdf.txt
./m64_Q0610.pdf.txt
./m8515_J1006.pdf.txt
./xmega_256A3B_I0910.pdf.txt
./xmega_384C3_C0412.pdf.txt
./xmega_A1_M0910.pdf.txt
./xmega_A1U_E102012.pdf.txt
./xmega_A3_T1210.pdf.txt
./xmega_A3U_C112012.pdf.txt
./xmega_A4_Q1210.pdf.txt
./xmega_A4U_D112012.pdf.txt
./xmega_C3_D112012.pdf.txt
./xmega_C4_C112012.pdf.txt
./xmega_D3_J112012.pdf.txt
./xmega_D4_M112012.pdf.txt

 

... excluding XMEGA manuals, and device summaries.  Note that some devices are represented in more than one matching datasheet (single-device datasheets, and a 'family' datasheet).

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have no idea what motivated the author to make that state though?!

I'd think that in any real AVR app of this complexity would be banging SP quite a bit, so IMO avoiding wait states would be important to system throughput.  Consider a fairly skinny ISR that stacks and unstacks a handful of registers.  Along with the return address pushing and popping that would virtually double ISR time, right?

 

Also, if you have some kind of glitch on the external memory chip -- missing; busted; fingertip press -- your AVR8 app would end up in La-La Land.  Startup (and perhaps periodic) checks of external memory mortality would at least let the app limp home, if the stack is kept internal.

 

But required?  Dunno.  Gotta look at all of those datasheets, then. ;)

 

[edit]  perhaps this threw off the writer?

 

The initial value of the stack pointer is the last address of the internal
SRAM.

 

New-fangled AVR8 devices have an initial value for stack pointer; devices from the last millennium did not.   If I read between the lines above, it sure doesn't sound like this particular datasheet would enforce stack pointer in low memory.

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Wed. May 20, 2015 - 04:09 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It does say "some devices even require this" - wonder which ones and why?

Aha!  Google to the rescue:

http://www.nongnu.org/avr-libc/u...

It is best to leave __stack at its default value (end of internal SRAM – faster, and required on some devices like ATmega161 because of errata),...

So I pulled up the AT90CAN datasheet and indeed some early chip revisions of that family:

 

ewline"> 3. Miss-functioning when code stack is in XRAM
If the stack pointer (SP) targets the XRAM and if the execution of an instruction is split to
serve a rising interrupt, the last operation of this instruction, executed after pushing out the
return address from XRAM, may be disturbed providing wrong data to the system.
Example: - the “OUT” instruction can be executed twice
- the “MOV” instruction can update a register with un-predictable data.
Problem fix / workaround
Map the code stack in internal SRAM.

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Wed. May 20, 2015 - 04:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I got an email from Atmel. They fixed the selector to include megas in the external memory bus filter.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You must have a good connection at Atmel, the tiny841 still only have 256byte of RAM in the selector, and I gave that info about a year ago (perhaps only 1/2 year)

Last Edited: Thu. May 21, 2015 - 10:31 AM