Adding more memory

[FFMan]

My gps project requires 10hz logging which is currently attempted to a byvac sd card module. This module is a serial interface pic based module that writes to FAT formatted sd cards. All very handy but I'm having some issues with it and am considering alternatives.

How easy is it to add ram to my 128a1, and how easy is this to write to. Are there any inbuilt routines to assist ?

If i wanted to use persisent memory, would I get the speed I need (only about 600 chrs/sec) and not stall the main task with flow control etc

I could then once the logging phase is complete write to the sd, or provide a download sub-routine to download to a PC.

Does anyone have any recommendaitons/experience of similar ?

[dkinzer]

How easy is it to add ram to my 128a1, and how easy is this to write to. Are there any inbuilt routines to assist ?

The xmega A1 devices have a versatile External Memory Interface, capable of supporting either dynamic or static RAM chips, and several methods of providing the required address and data lines. I find the "three port" mode using static RAM a good compromise of complexity and ports used. Our xmega128A1 Development Board uses this mode with the CY7C1019D static RAM and a 74HC573 for the address latch. This mode uses ports J and K for the address and data lines and a few pins from port H for control lines. See the schematics for the xmegaA1 dev board for the details.

Once you have the RAM attached (and you tell the compiler how much RAM is present and how to configure the External Memory Interface) the external RAM is indistinguishable from internal RAM except that it takes an extra CPU cycle for each external access.

ZBasic only supports RAM addresses up to &Hffff. The CY7C1019D RAM chip is a 128K byte chip so half of the chip is unused. If you wanted to use the other half of the chip you'd have to write a set of routines to read/write from/to it.

If i wanted to use persisent memory, would I get the speed I need (only about 600 chrs/sec) and not stall the main task with flow control etc.

The "typical" specification for writing a byte to Persistent memory is 12mS. That would yield a best case storage rate of only 83 bytes/sec.

[FFMan]

thanks i'll take a look into the EMI but I suspect that I might be going down the road of using persistent but i note your comments regards speed.

Is the throughput rating you mention applicable to flash i.e. is flash what i mean by persistent or is there a difference ? It seems that SD cards can write much quicker than this ?

My only concern with ram is that this device is in a race car and having to write from ram to sd after the race might not always be possible. Writing on the fly to permanent storage is preferred if possible.

[dkinzer]

Is the throughput rating you mention applicable to flash i.e. is flash what i mean by persistent or is there a difference ?

The AVR devices have three primary memory spaces: RAM, Flash and EEPROM; the latter two being non-volatile. The ZBasic Persistent data types are stored in EEPROM. ZBasic code and the ProgMem data types are stored in Flash memory (for native mode devices).

[FFMan]

i understand.

If i add flash memory using SPI, do you think it likely i will get 500 chrs/sec throughput ?

In reality I could probably halve the required throughput by dropping some fixed information and compressing (BCD etc) other bits of it. the data could be reassembled as part of the download process.

[dkinzer]

If i add flash memory using SPI, do you think it likely i will get 500 chrs/sec throughput ?

That depends entirely on the particular device that you select. I was just looking at the Ramtron FM25256B, the datasheet for which suggests that it can be written at full speed - 20MHz max. Of course, there is some overhead with commands, serializing the data, etc. Also, the fastest SPI clock available is half the speed of the AVR chip. So, on a 29Mhz xmega the fastest SPI clock rate would be a bit more than 14MHz.

[DocJC]

FFMan,

With your current external SD card module, are you writing data in real time, or are you buffering your data?

When SD cards write their 512 Byte Sectors it takes some time. How much time depends upon the speed of the card, i.e. its internal controller.

If you can spare TWO, 512 byte arrays, then the uC can be streaming real time data to one array while it is sending the other array to the external SD module.

When the real time data buffer is full you flip buffers and start streaming your real time data to the other buffer, and write the just filled buffer to the external SD card module.

JC

[FFMan]

yes i may need to consider some data buffering.

I was also thinking of a circular table to iron out some of the delays that may occur when a physical write is performed.

I need to do some more testing TBH before i drop the SD module. Earlier tests indicated it could keep up.

[spamiam]

FFMan,

You said you had issues with the SD interface your are currently using. Can you be more specific? You need 500 bytes/sec plus control characters? How much total data? Does it need to be retained across power down/loss?

I have used Ramtron FRAM chips and they worked very well. I used the I2C version and it kept up with the full speed writes easily. FRAM is sort of like EEPROM, but lasts longer and is probably more expensive. Faster too, I think. And limit tot he # of writes to an individual cell.

-Tony

[FFMan]

i think i cracked the sd issue for now. There was an option to up the freq between controller and card. As default it shipped at 1mhz as this is the slowest most compatible. I've upped it to 7mhz without issue and this gives the controller enough time to complete the write.

I think i will still get an fram chip and have a play - might be useful for later.