Extra SRAM

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

Hi All,

 

Is it possible to add extra external SRAM to a MegaAVR?

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

Please ignore. Found the answers.

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

windoze_killa wrote:
Found the answers

So how about sharing them?

 

And marking the solution?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Mon. Jun 1, 2020 - 11:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sounds like you need to choose a more suitable processor.

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

Some AVRs support external RAM, which becomes somewhat of a pain to use because the compiler has to be told that it exists.
It will require more than a 40pin chip, and use up quite few pins.   For example, there are external RAM Shields for the Arduino Mega, and the XMEGA A1U Xplained Pro has 512kbytes of external RAM.

It is "not easy" to add RAM to an existing design, the way you can just pop bigger DIMMs into a desktop.

 

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

awneil wrote:

windoze_killa wrote:
Found the answers

So how about sharing them?

 

And marking the solution?

 

https://www.avrfreaks.net/forum/external-memory-interfacing-avrs

https://www.avrfreaks.net/forum/8-megabyte-spi-ram-8-pins

 

Not marking as solved as people are posing some interesting comments that may unsolve it.

Last Edited: Mon. Jun 1, 2020 - 11:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:

Sounds like you need to choose a more suitable processor.

 

Any suggestions? Remembering PCB is only going to be 40mm x40mm

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

westfw wrote:

Some AVRs support external RAM, which becomes somewhat of a pain to use because the compiler has to be told that it exists.
It will require more than a 40pin chip, and use up quite few pins.   For example, there are external RAM Shields for the Arduino Mega, and the XMEGA A1U Xplained Pro has 512kbytes of external RAM.

It is "not easy" to add RAM to an existing design, the way you can just pop bigger DIMMs into a desktop.

 

 

I am not using an Arduino except for testing so I will need a single chip probably wit SPI interface. 

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

How much ram do you need? I've got a single chip micro in front of me with a dual core RISC-V 64 bit and 8megabytes of ram running at 400MHz that will easily fit onto a 40mmsq pcb. That might be overkill for your application though. 

If you want a suggestion, then I need some specs. 

 

Are you still working on your motorbike gear indicator?

 

 

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

I think it might be a bit of overkill.

 

Yes I am. I have "nearly" got the monochorme version working on my Arduino 2560. It works beautifully without scrolling but is do odd things when I try to scroll. It is probably the way I am trying to do it.

 

Once I get it scrolling I will then try and get some colour into it on a full colour OLED display and this is where I think I am going to need some more RAM.

 

I have had a heap of help across a couple of forums but I have done a lot of the problem solving myself which has been a great learning experience. I doubt it will be anytime soon that i will be able to program from scratch.

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

after I posted-

>full colour OLED display

 

yes, that will change things a little

Last Edited: Tue. Jun 2, 2020 - 12:46 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just a little ;-)

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

I will need a single chip probably wit SPI interface. 

There are no AVRs with a transparent SPI RAM capability.  You can, of course, stick a regular SPI RAM on the SPI bus and access it manually.

 

Don't some displays have (essentially) SPI RAM on the display?

 

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

Seeing I need UPDI programming what would be the biggest chip memory wise that would have that? The best I can find is the 4808.

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

westfw wrote:

I will need a single chip probably wit SPI interface. 

There are no AVRs with a transparent SPI RAM capability.  You can, of course, stick a regular SPI RAM on the SPI bus and access it manually.

 

Don't some displays have (essentially) SPI RAM on the display?

 

 

Yes. The one I am looking at has  integrated 240x320x18-bit graphic type static RAM. Would this do the data manipulation? I am trying to get my head around all this new stuff....new to me at least.

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

With regards to the scrolling - I gather you just want to scroll the gear numbers when the gear is changed? If your bitmap is fixed, then that can exist in flash, thus using next to no ram. Scrolling then just becomes copying the required window of pixels from the flash table to the display. 

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

At the moment I have created a single bitmap 128 x 448 and as the gear changes I select the starting "y" point (display turned portrait) and then scroll along the bitmap either up or down. I have it sort of working. But this is covered in another thread.  https://www.avrfreaks.net/forum/scrolling-bitmaps

Last Edited: Tue. Jun 2, 2020 - 02:35 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why the extra ram then?

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

I am thinking ahead for when it goes colour. I have a ,000 things going on in my head at the moment.

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

Kartman wrote:
Sounds like you need to choose a more suitable processor.

+1

windoze_killa wrote:
Any suggestions? 

Some ARM Cortex-M ?

 

windoze_killa wrote:
I need (sic?) UPDI programming

Eh?

 

Why do you "need" that?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
Some ARM Cortex-M ?
+1

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

windoze_killa wrote:

Seeing I need UPDI programming what would be the biggest chip memory wise that would have that? The best I can find is the 4808.

 

You can use the rather new AVR128DA32. It has 128KB flash, and 16KB SRAM. The price is just a few cents above the 4808, and it has the same pinout.

 

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

windoze_killa wrote:
I am thinking ahead

So why the lock-in to UPDI ?

 

Surely, "thinking ahead" + "lots of RAM" = Cortex-M ?

 

"lots of RAM" is really not where any 8-bitters shine.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
So why the lock-in to UPDI ?
I think he was looking for a "one wire programming" interface. I haven't studied them in detail but doesn't "PDI" on other AVR also offer this? Oh and if you venture in the direction of ARM is SWD a single wire?

 

EDIT: OK, so no, SWD uses more wires.

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

debugWIRE also gives a 1-wire programming & debug interface on the AVRs which have it.

 

Yes, SWD on ARMs is a 2-wire[1] interface:  https://developer.arm.com/architectures/cpu-architecture/debug-visibility-and-trace/coresight-architecture/serial-wire-debug

 

(it also helps to have access to RESET)

 

[1] ie, it has 2 wires - nothing to do with I2C!

 

EDIT

 

But, having freed-up at least 2 pins for an external memory interface, surely this shouldn't be an issue ... ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Tue. Jun 2, 2020 - 10:54 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

 

But, having freed-up at least 2 pins for an external memory interface, surely this shouldn't be an issue ... ?

Not sure if it was this thread or elsewhere but I think OP said he wanted to seal whatever this was into a cabinet with only a very limited number of external connections so I don't think the programming interface thing was about saving pins on the AVR but about keeping the number of protruding connections as small as possible.

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

stupid question, can you read from the display or only write ? (a quick look show that some don't seem to have two data wires).

 

But if you can read from the display you have a nice big RAM, where not all of it is used for the picture showed.

 

 

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


There is only a memory problem if you need pixels to have individual colours. Some old computers like ZX Spectrum stored pictures as 1 bit per pixel images + 8x8 cells of colour (bg + fg colours), this takes much less memory than individual pixel colour and is ok for some simple applications.

You can get this amazing graphic quality cheeky

 

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

I’d be looking at no wires...as in ‘wireless’. Cheap n easy to do these days.

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


I found this old photo, that show a prototype of a display board I made. (6 years old and yes I would do it different today.)

 

I'm running it from a mega324, because I use it elsewhere. The total code is about 11KB, it receives numbers over rs232 and display them, and it has a recessive touch (a film glued on top of the glass), that go to the ADC on the AVR.

 

The display is from newhaven. 

It's a ST7789V controller, but about 4 years ago it had an other name (they replaced it, only code change was two init bits, but a pain to have two versions )   

 

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

awneil wrote:

windoze_killa wrote:
I am thinking ahead

So why the lock-in to UPDI ?

 

Surely, "thinking ahead" + "lots of RAM" = Cortex-M ?

 

"lots of RAM" is really not where any 8-bitters shine.

 

Why UPDI? I have only 4 wires to work with. +12, GND, Analog in and Digital out. Alnalog in will be the UPDI pin.

 

The colour display (240 x240) and the custom board needs to fit into a 40mm x 40mm x 15mm ABS box. Size it the big driver here.

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

El Tangas wrote:

There is only a memory problem if you need pixels to have individual colours. Some old computers like ZX Spectrum stored pictures as 1 bit per pixel images + 8x8 cells of colour (bg + fg colours), this takes much less memory than individual pixel colour and is ok for some simple applications.

You can get this amazing graphic quality cheeky

 

 

The graphics I want to use is way simpler than that. At any one time there will probably be only 4 colours on the screen.

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

windoze_killa wrote:

https://www.avrfreaks.net/forum/external-memory-interfacing-avrs

https://www.avrfreaks.net/forum/8-megabyte-spi-ram-8-pins

 

Not marking as solved as people are posing some interesting comments that may unsolve it.

 

For simple displays, Serial Static SRAM is likely to be 'good enough'

OnSemi and Microchip have SerialsRAM to 1MBit, and ISSI has larger and faster choices, still in SRAM to 45MHz / 4MBit

http://www.issi.com/US/product-asynchronous-sram.shtml#jump5

 

 

More work, but larger again are the PSRAMs, in Quad and Octal sizes, but they have refresh rules.

 

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

But why do you need more RAM for colour ?

You need more flash/eeprom, but the not RAM.(perhaps 10-20 byte)

 

Get a picture on the screen should be mostly like a DMA function.

And scroll (at least for the chip I used) was just a pointer change in the display.

or a redraw of the picture where edges are made so the picture clear itself (clear and then redraw will flicker because the update is to slow over SPI).

 

I think the SW for the picture in #30 used less than 100 byte of RAM, but font's etc. was about 8K (absolutely the most is the true type font used for "Flame 4" there I can write char 32-127 about 6K) 

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

Unless I am missing something - I agree with Sparrow2.

 

If you are just scrolling a big single digit number on an LCD screen you probably need about 2 bytes of RAM to hold some state information.

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

Obviously I am getting fed different info from various places. Some are telling me I need stuff all RAM others are saying I need heaps so the image can be changed and then sent to the display. In my other thread mentioned above I have acheived scrolling but with problems.

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

You've given very little information - that's why you're getting mixed messages. I picked up on what you 'might' be wanting to do as I had some prior knowlege. The basic thing is if you want to do graphics, then you need ram, however, if your images are fixed and all you are doing is scrolling them, then ram is less of an issue. Only you can determine what ram you really need based on your code.

 

If you do need more ram, then chose a chip with the required ram - adding external ram is viable, but is going to cost more and take more board space as well as being less flexible. With most designs I do, rarely is there an optimal solution - cost, availability, tools, voltage etc are all considerations.

 

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

As Kartman pointed out, it depends upon what you want to do. 

 

If you want to calculate a lot of complex images then flip through them quickly, you'll need a lot of (fast) RAM.  If you want to store lots of complicated pictures but don't mind them appearing relatively slowly, you need a lot of EEPROM (or Flash).  If you want to just scroll around in one fixed image, you need neither, just pointer math (and enough RAM for the image itself, I suppose).

 

SPI RAM isn't going to be any faster than SPI EEPROM.  Only use SPI RAM if you're going to be doing lots and lots of write-backs of modified images.

 

Looking back at the old gaming consoles' code will show you some sheer genius in packing a lot of video information into not much space.  May not be entirely useful in an AVR context, let alone an ARM.  You may be amused by the concepts of 'sprites', and possibly a 'blitter'.

 

As a cheerful aside, if you do want to use parallel RAM, and you don't mind accessing it sequentially*, you can save a lot of AVR pins by putting a counter chip on the address pins, say a 74HCT4060 or something.  14 bits of address for two AVR pins - count, and clear.  Not a bad deal, that.  And the little ones you can stick on the back of the PCB, underneath the RAM itself on top.

 

S.

 

* I know, I know, that sorta puts the boot into the 'R'andom 'A'ccess part of the memory, but hey.

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

Scroungre wrote:

* I know, I know, that sorta puts the boot into the 'R'andom 'A'ccess part of the memory, but hey.

Hey, it was good enough for the Kenbak-1 ;-)

"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]