Which storage would be better for speed?

Hello, I’m running into that age old question. Sending images from the pc to the arduino. My question is what storage would be better for faster transfer. I have right now an sd card module. https://a.co/d/f7V4hFP I was thinking of changing it to either a winbond or maybe Sram.

The processor I’m using is the samd21 that is on the arduino zero board.

I need to rapid keep sending updated images from my pc to be stored onto ether a sd card, winbond or Sram. It will override the previous image on there with the new image. I know there is a whole set of problems. One being the total time to transfer takes a total of 4 seconds. I’m trying to get it down to 1 to 2 seconds and might be impossible to do.

Just trying to eliminate some of the transfer time and saving. Any ideals will be great. Thank you

Joseph

You can transmit the data serially over Ethernet, WiFi, Bluetooth, or similar methods. Instead of using an SD card, consider using FRAM (Ferroelectric RAM) memory. I use 32Kx8 FRAM chips in place of the standard EEPROM on my RTC modules.

FRAM operates instantly—there are no delays due to sectors, blocks, or write cycles like with SD cards or flash memory. These chips are available in parallel, SPI, and I2C interfaces. I recommend using the SPI variants for better speed and ease of integration.

Here’s a helpful link for more information:

@gilshultz I can not do eithernet, wifi, bluetooth. This is straight usb to native usb on the Samd21 that is the arduino zero board. I'm not logging any data. I'm transferring an image from the pc to the arduino.

Lots of information missing. How big are the files, what PC app is sending the data, what baud rate is being used, are you using flow control?

Hello @mikb55 you are correct. With a help from a friend of mine we made a desktop application. The bias rate is 115200. the file size is 1MB. Looking to compress that hopefully down to 700kb or 800kb.

I hat do you mean flow control?

For an Arduino Zero the baud rate should not matter, it uses native USB so it will do the speed that is dictated by USB. See a post by westfw in your other topic about it.

Just send the difference between images, that will be much faster.

SRAM would be the fastest

Sorry I assumed a UNO as you did not specify. Others are also asking for more information, remember we cannot see what you have. Good luck!

@gilshultz My fault there. I corrected my original post to includes.

@jim-p that is also what I was thinking.

@sonofcy Only have space for one image. And the new image needs to override the old image and old image needs to delete.

How does your program know when a message is the beginning of a new image? How does your program know when a message is the end of a the current image? Is the picture data contained in each message always the same length?

All of the above needs to be part of your communications design.

@Paul_KD7HB That is what I’m figuring out soon. This right here is just hardware not software time. I’m just trying to eliminate some bottle neck for speeds in hardware when it’s time for software then I’ll be doing the same thing in software later on.

Why not display each image segment as it arrives? Whatever software used for display will need to display it in pieces, anyway.

@Paul_KD7HB I’m not to that point yet. Still trying to figure out hardware.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.