Hi, I am working on a report for a competition, and I should compare SD card and Teensy 4.1 Emulated EEPROM for storing a small data set. But I couldn't find enough information for Emulated EEPROM. You can see my comparison table and missing values. Is there anyone who can help me with these values?
Teensy 4.1 Integrated Emulated EEPROM Specs
- Thread starter emirtnrvr
- Start date
PaulStoffregen
Well-known member
The emulated EEPROM uses a portion of the flash memory chip to store its data. You can find the W25Q64JV-DTR Datasheet on the Teensy 4.1 page tech info section. For the raw speed specs comparable to those raw SD specs, turn to pages 89-90.
Those SD specs say "SPI, SDIO", but they can't possibly be true for SPI. In SPI mode the maximum clock speed is 25 MHz. I believe in recent software we're using a default of 16 MHz for better compatibility with "long" breadboard wires and lower quality 3rd party adaptor boards, though the SPI clock can be set differently using a special SdFat begin function. Even at 25 MHz, the best case scenario without any overhead would be only 3.125 MB/s, since SPI uses 1 wire for data.
In SDIO (4 bit) mode, we use either 25 or 50 MHz clock depending on what the card says it supports. We don't support any higher clock speeds, because run the card at 3.3V and higher SD speeds require lower voltage. So on Teensy 4.1 with SDIO, the best case scenario would be 25 MB/s speed. You simply can't get 30 or 80 MB/s with a SD card powered by fixed 3.3V.
However, none of these specs paint a clear picture of the actual performance you can expect in practice. Especially with SD cards, the controller inside the card can have quite high latency for reads or writes, though it is usually pretty quick. The performance also varies massively depending on the transfer size (because of the internal controller's command latency), and if you're using it for a small data set you would presumbly not be using large transfers! Some time ago Bill (author of SdFat) posted the results of a lot of performance tests with actual cards and many transfer sizes. Maybe you can find that messabe by search?
The emulated EEPROM speed can also vary quite a lot, depending on prior written data. For reading, it does a simple linear search through as much as a 4K sector to ignore prior writes and find the latest written data. For writing, normally you will observe a fraction of the Page Program Time documented on page 90. But once the 4K page is filled, it will read all the prior values into RAM (which is relatively quick) and then perform the slow Sector Erase Time (4KB), and after it will do more Page Program Time writes to put the latest data back onto the start of that 4K page.
Those SD specs say "SPI, SDIO", but they can't possibly be true for SPI. In SPI mode the maximum clock speed is 25 MHz. I believe in recent software we're using a default of 16 MHz for better compatibility with "long" breadboard wires and lower quality 3rd party adaptor boards, though the SPI clock can be set differently using a special SdFat begin function. Even at 25 MHz, the best case scenario without any overhead would be only 3.125 MB/s, since SPI uses 1 wire for data.
In SDIO (4 bit) mode, we use either 25 or 50 MHz clock depending on what the card says it supports. We don't support any higher clock speeds, because run the card at 3.3V and higher SD speeds require lower voltage. So on Teensy 4.1 with SDIO, the best case scenario would be 25 MB/s speed. You simply can't get 30 or 80 MB/s with a SD card powered by fixed 3.3V.
However, none of these specs paint a clear picture of the actual performance you can expect in practice. Especially with SD cards, the controller inside the card can have quite high latency for reads or writes, though it is usually pretty quick. The performance also varies massively depending on the transfer size (because of the internal controller's command latency), and if you're using it for a small data set you would presumbly not be using large transfers! Some time ago Bill (author of SdFat) posted the results of a lot of performance tests with actual cards and many transfer sizes. Maybe you can find that messabe by search?
The emulated EEPROM speed can also vary quite a lot, depending on prior written data. For reading, it does a simple linear search through as much as a 4K sector to ignore prior writes and find the latest written data. For writing, normally you will observe a fraction of the Page Program Time documented on page 90. But once the 4K page is filled, it will read all the prior values into RAM (which is relatively quick) and then perform the slow Sector Erase Time (4KB), and after it will do more Page Program Time writes to put the latest data back onto the start of that 4K page.
defragster
Senior Member+
EEPROM write versus SDHC is an odd comparison?
As noted the EEPROM writes are done with the focus on minimizing wear with overhead in each byte written to do that and then when needed and on the fly block format will happen to restart the data stored for that subsection. It is effective and efficiently uses a small amount of flash area to present the 4K of usable space.
A more apt comparison might be LittleFSC and an example like this for PROG memory. It also has a fair amount of overhead for reliability and interrupt-ability while also working to minimize wear on Flash with extra writes. It will also see on the fly block formatting when data has no unformatted blocks for storage.
As noted the EEPROM writes are done with the focus on minimizing wear with overhead in each byte written to do that and then when needed and on the fly block format will happen to restart the data stored for that subsection. It is effective and efficiently uses a small amount of flash area to present the 4K of usable space.
A more apt comparison might be LittleFSC and an example like this for PROG memory. It also has a fair amount of overhead for reliability and interrupt-ability while also working to minimize wear on Flash with extra writes. It will also see on the fly block formatting when data has no unformatted blocks for storage.
As I understand, flash is not integrated into Teensy's MCU, so its interface is not DMA. I researched W25Q64JV. I believe it is using Quad SPI. If I am true about the Quad SPI thing, can you provide the average SD card(4bit SDIO) and W25Q64JV(QSPI) read and write speed values for Teensy 4.1?
Last edited:
Thanks for your comment. But my data set is small and I should reach the .csv file, that I saved during the mission, after the mission immediately. With the SD card, I can access my data faster. Am I wrong?
Last edited:
PaulStoffregen
Well-known member
Before I pour more time into another detailed message, I'd like to ask you a couple questions.
Can you tell us about your project? This is such an unusual question, and maybe I'm reading too much into the question, but it seems you're pretty focused on meaningless bandwidth metrics which have little or no impact on the actual performance in applications using such small data.
Do you actually have a Teensy 4.1? Usually the simplest way to answer these questions is to just write a small test program and measure the elapsed time with the ARM cycle counter or elapsedMicros. Crafting a good test can be tricky because the compiler is so good at propagating const data, but it can be done if the inputs come from reading Serial or volatile variable. Many times we've had conversations on this forum about test programs and their results, so if you share the code and results we can help you make sure they are really measuring correctly. The big advantage is you can actually benchmark a specific usage, which is a lot better than just taking raw bandwidth numbers that don't capture the overhead and SD card command latency, which are the dominant effects for performance in manipulating such small size data.
Can you tell us about your project? This is such an unusual question, and maybe I'm reading too much into the question, but it seems you're pretty focused on meaningless bandwidth metrics which have little or no impact on the actual performance in applications using such small data.
Do you actually have a Teensy 4.1? Usually the simplest way to answer these questions is to just write a small test program and measure the elapsed time with the ARM cycle counter or elapsedMicros. Crafting a good test can be tricky because the compiler is so good at propagating const data, but it can be done if the inputs come from reading Serial or volatile variable. Many times we've had conversations on this forum about test programs and their results, so if you share the code and results we can help you make sure they are really measuring correctly. The big advantage is you can actually benchmark a specific usage, which is a lot better than just taking raw bandwidth numbers that don't capture the overhead and SD card command latency, which are the dominant effects for performance in manipulating such small size data.