Flash Memory RAM VS SDCard

[wrickert]

Good afternoon all,

I am designing a widget that will use an STM32H7 to control a laser to scan over a surface and record detail. This detail will be stored in a picture format.

The picture will be larger than what I can easily store in the STM32's memory so I was planning on including some RAM as temporary storage till it can be sent to an SD Card.

The question is this: is that setup redundant? Most of the RAM I'm seeing on digikey is Flash Memory biased. Should I skip the middle man and just write to an SD Card?

Thanks!

[ataradov]

Most of the RAM I'm seeing on digikey is Flash Memory biased.

This makes no sense. RAM is RAM, flash is flash. There is no flash-based RAM.

Should I skip the middle man and just write to an SD Card?

Depends on the throughput you need to get. If it is something SD Card can support in real time, then yes, use SD Card directly.

[wrickert]

This is probably part of my misunderstanding. With this Digikey search
https://www.digikey.com/en/products/filter/memory/memory/774?s=N4IgjCBcpgbFoDGUBmBDANgZwKYBoQB7KAbRACYBOAFkvIA4QCraBmapiygVgAZL4zHrwDsgrtzC8OQyb3FVuVRrNZ1Oi6vI09q3Vju58Z4XvVhUQAXQIAHAC5QQAZXsAnAJYA7AOYgAvgRg1OQIIMiQ6Nj4RKQgIuS8rPQinAlJ9NxpicmU2dJgBgTp1MH5pQqwcLAq8YkhRXVJ7PmsrFnFOazi6W2pnc21vW2tIa0143kDrCK84-1NM6HTIibpmY3r3Gv1IwPUrBD7M61Kp5s526c9lwu93EOXR4vkF0nkN0lirSJ3OSKPL5TRYiDpNehaVqUP5JSiAtTAkq8Ob7XjPJHLRY8cpgQFaPHaVF3VjI-icWBaZJvNqIxIQzEUjI7JKwT4QxqM5Jg3qUak0cpqcmU8zlcjc%2BpgdFdZ6clKjakU1r0TE8lFNEK06TJUXM7pq3pi1oktIk7i8k28M26%2BhS2G2kJ48joklouY2EAOJyuTy%2BAJBOF5aDhVCYXAEYiQMhuwIgAC0oSDEXcAFcYhGyFkrP4Y-Agx4ACZOWNSZ6eyAgTj2ACethwTjQWGQ2aAA
When I filter for available parts and packages that are easy to hand solder, all of the cheapest parts are memory format "Flash"

[ataradov]

This is just serial Flash, it is not RAM. This is not much faster than SD Card, especially if MCU has SDHC controller (STM32H7 has it) and you can use the card in an actual SD Card mode instead of a generic SPI mode.

[wrickert]

Aah. That would explain what I'm missing. Thanks for the info!

[SiliconWizard]

Temporary RAM would be required, rather than optional, in the following cases:
- Non-volatile storage not being fast enough to handle direct writing of data,
- If a lot of data is going to be written frequently, and not all of it is meant to be stored permanently - in this case, writing everything to flash memory may lead to premature failure.

In fact the first case is almost always true, at least in form of a cache to buffer transfers to the non-volatile memory. The size of this cache will vary with your requirements. You usually can use the embedded RAM of a MCU for that, unless you'd need a huge cache.

Note that if you want some kind of external RAM rather than flash, with a similar interface (QSPI), you can resort to PSRAM. The amount of memory available is always restricted (a few MBytes), but certainly much higher than the embedded RAM of most MCUs.

[ataradov]

I would not worry about premature wear. I have multiple cameras that write video on a loop 24/7 for years. The cards are fine.

If bandwidth allows, high capacity cards are a good way to store even temporary data. And if it is a piece of equipment that is expected to be maintained, then card replacements may be mandated depending on use.

[Smokey]

One thing to be heads up on is that the external RAM interfaces are pretty high speed, so make sure your layout is dialed in.

[DavidAlfa]

You can make use of the FSMC peripheral to natively interface external sdram, mapping will be transparent, just access the proper address, was something like 0xC0000000 (Check datasheet)
You can get 8MByte IS42S16400E-7TL for about $1.4 at Digikey.
But if the system can handle chunks and delays, it wont be required.

[ArdWar]

I would not worry about premature wear. I have multiple cameras that write video on a loop 24/7 for years. The cards are fine.

Most (if not all) SD cards and eMMC nowdays do their own wear levelling internally, so they should be fine if all you do is writing files. However "raw" addressable serial flash memory, especially NOR FLASH based, often not. You need to factor in your own wear levelling if you use it raw. Fortunately most embedded filesystem implementation like FATFS should already have wear leveling built in or at least configurable.

If you need your storage to be robust too you should use journaling FS instead of raw addressing or simple FS like FAT. Maybe even something specifically designed for embedded usage like LittleFS if you're resource constrained (its theory is sound, but I yet to actually try it).

[hans]

What STM32(H7) do you use?
The U5xx H72x H73x H7Ax H7Bx now have an OctoSPI peripheral. It can be used with PSRAM modules (DRAM in a SPI/serial protocol) like the APS6404L. 1-1.4euro for 8MB of RAM. The OctoSPI module can be set to handle read/writes to memory (instead of only read with the older QuadSPI peripheral), and can also handle the maximum transaction length of these PSRAM chips (IIRC 4 or 8us max chip select time, to be in-spec over all temperature/voltage corners).

I think this is one  the easiest way to expand memory on the STM32. The FSMC can also be used, but it requires a large address and data bus to be routed. HyperRAM is also an option if you need more bandwidth, but its 8-bit wide, DDR and can be a bit more fiddly to just throw onto a PCB.

[betocool]

+1 on SD card.

We had a project not too long ago where we were writing data to an NOR Flash and an SD Card. SD card was faster and more reliable, so now when I need to store data, SD card is the way to go for me. In a pinch you can even use SPI if you don't have an SDMMC interface, but I'm sure the H7 does have one.

My additional 2c, use an OS like FreeRTOS and FatFS. I create a streambuffer on FreeRTOS that receives the data on one end and another task reads the data from the other end to write to the SD. If possible, use multiple of 512bytes or 1024bytes, I find in micros and using FatFS that seems to be the sweet spot.

Cheers,

Alberto

[amyk]

Unless you have some other requirements, it shouldn't be necessary to have the whole image in memory at once; just stream it from the sensor to the card with a suitable small buffer, e.g. sector-sized.