AVR SRAM limitation

Question

I'm just an enthusiast looking for some advice.

I'd like to use a microcontroller to read frames from a camera and write those frames to a small LCD screen. The camera and screen are on the same SPI bus. I've been prototyping with an Arduino but I'd like to move to an AVR eventually.

Problem is, an image frame is 9600 bytes and the Arduino SRAM is 2.5KB. I can't buffer a whole frame. I tried reading from camera and writing to the screen a few lines at a time, but because they are on the same SPI bus, I need to de-assert the camera, assert the screen, and then re-assert the camera. If you de-assert the camera mid-frame you lose sync.

I need to figure out a way to get 9600 bytes from camera to screen without de-asserting the camera. Seems like I have 2 options: Increase SRAM to buffer a frame or separate SPI busses.

Increase SRAM:

• Change AVRs - The only ATmega with enough SRAM is ATmega1284 and it's got 44 pins.
• External SRAM? Never worked with it.

Separate SPI busses:

• Move screen from hardware SPI to regular pins and write software SPI. (I doubt this would be fast enough.
• Looks like there are several ATtinys and ATmegas with 2 or more SPI busses. Some as small as 20 pins. This would still delay the reading of single frames, but hopefully not too much.

Something... else?

• FPGA? Never worked with them...
• Some other type of microcontroller?

Thanks!

Answer 1

Something else (sort of):

Several of the ATmega devices can reconfigure their USART(s) to act as a SPI master. Simply connect one of the devices to one of these reconfigured peripherals. Look for "USART in SPI Mode" or "MSPIM" in the datasheet.

Answer 2

Try an STM32F4Discovery board; US$15-25. The MCU is an STM32F407VG: 168MHz ARM Cortex-M4, 1MB flash, 192kB RAM, 3 SPI ports and DMA that would, for example, allow you to stream from one SPI port to another with minimal processor involvement. The Discovery has a built in SWD programmer/debugger so no extra hardware is required; try CooCox for a free and unlimited IDE.

Answer 3

Most external RAM is SPI, which suffers from the same dual-bus problem you have already. That's not to say it's impossible to use.

A clever way would be to connect the camera's data output to the data input of an SPI SRAM chip and use the SRAM chip to directly capture the frame data. You could then access whatever part of the last frame received at your leisure. However, it would take a certain amount of cunning external circuitry to share the data input between the camera and your MCU, as they won't be able to be both connected at once, and you may also need to directly receive from the camera to set it up and check statuses etc (depending on the camera of course).

A simpler method would be to just use a bigger MCU.

PIC32 based boards would be a good alternative for the Arduino boards in this situation. Something like a chipKIT uC32 would give you 32KB of RAM, and multiple SPI ports, so you can both buffer a whole frame and use separate SPI ports. Also it's 32-bit and 80MHz so you can do processing of your data much much faster.

Also there are PIC32 boards which use 28-pin DIP chips (such as the DP32 which uses a PIC32MX150 chip) which is better for prototyping.

The IDE (MPIDE) and language are almost identical to Arduino, no nothing (much) new to learn.