Emmc

Status
Not open for further replies.

brtaylor

Well-known member
Apologize in advance for a more rambling post than usual. Just finished one project and thinking about options for the next. I need to do some more research and hoping to jump start my lack of knowledge from the minds here. Lately, I find that for a lot of my projects involving Teensy that I am using a Linux SBC only for logging data and nothing else. In other words, I typically have a Teensy collecting sensor data and doing estimation / math and then sending data to an SBC just to log to its EMMC storage. Seems like overkill for what I am using it for and the SBC takes up a lot of space on my boards. I could log data to an SD card, but a lot of these projects are meant to be high reliability in high vibration and temperature environments and, maybe my opinion is unfounded, but I don't trust SD cards for those scenarios. Flash is easy, but I need more storage than I could feasibly do with it.

What would be the easiest / fastest path to large storage options that are permanent on a PCB? Is it possible to use the MK66FX1M0 SDIO lines (PTE0 through PTE5)to interface with EMMC? I notice the i.MXRT1050 chip has NAND and EMMC support, but my assumption is that this would take a lot of work to bring up. Are there controllers to interface with NAND or EMMC that simplify connecting to a microcontroller?

Thanks!
Brian
 
How much is too much for Flash to hold? Wondering about that with T4 where data creation is even faster and easier - and USB out is fast as Device or Host at 10 MB/s to start. A HDD on USB HOST showed 11MB/s - didn't compare on T_3.6 yet - but perhaps an SSD since HDD would not be good here? I just ordered a new 2.5" HDD to test - wasn't sure how reliable an SSD would be for abusive testing at this early stage given their 'special' behaviors {trim and such from OS?}. The first old one I plugged in stopped responding with early connect test.

Brian: USBHost and MSC and uSDFS on that thread on T_3.6 @256MHz with 32KB buffer can do 6MB/s and bumping to 64KB write buffer goes to 10.39 MB/s. This is 'some old USB<>SATA drive box' I have that wasn't used in 6 years or so - not sure what drive is in it. Will have a new USB3 adapter box and 2.5" HDD with 128 MB cache to a 5400 RPM drive next week. Ideally that RAM cache for streaming write should do better if the USB<>SATA interface is good … and in the end an SSD would do even better?

Here is the timing writing 1,000 blocks of 64 KB:
Code:
(6329964 - 10.353297 MB/s)
 (open: 164960 us; close: 44999 us; write: min,max: 5705 11741 us)

I think that says 6.329 seconds for the group with block write max/min details.

Dropping to 32KB RAM buffer to write results in:
Code:
(5363964 - 6.108915 MB/s)
 (open: 29964 us; close: 17999 us; write: min,max: 4833 17869 us)

Open/Close and Min/Max values not ideal with re-running same test on the ROOT directory and FAT maintenance probably factoring in.
 
Last edited:
I could log data to an SD card, but a lot of these projects are meant to be high reliability in high vibration and temperature environments and, maybe my opinion is unfounded, but I don't trust SD cards for those scenarios. Flash is easy, but I need more storage than I could feasibly do with it.
So concern is the mechanical connection of uSD card holders? If so, consider soldering directly some wires between T3.6 uSD Card holder and standard uSD Adapter. You cab easily fix the uSD Card in uSD adapter, say with a tape.

What would be the easiest / fastest path to large storage options that are permanent on a PCB? Is it possible to use the MK66FX1M0 SDIO lines (PTE0 through PTE5)to interface with EMMC? I notice the i.MXRT1050 chip has NAND and EMMC support, but my assumption is that this would take a lot of work to bring up. Are there controllers to interface with NAND or EMMC that simplify connecting to a microcontroller?

AFAIK, (E)MMC and uSD software is pretty similar (may only need some checking).
 
Here is the timing writing 1,000 blocks of 64 KB:
Code:
(6329964 - 10.353297 MB/s)
 (open: 164960 us; close: 44999 us; write: min,max: 5705 11741 us)

I think that says 6.329 seconds for the group with block write max/min details.
correct
the max value should be used for estimating the minimum Teensy buffer size required for (drop-free) RealTime logging
 
My assumption was the laggy fitful nature of the SD card writes being the problem? … assuming indeed the SD card could be made secure. Though adding an SSD is about the same size as an SBC- plus the SATA<>USB adapter … but as noted … I was wondering about data storage too and SD just seems too finicky - though much more compact if it can work.
 
I'm using several GB; although, right now that's being compressed and I'm being selective about data because I'm limited to a 1 MBaud connection between the SBC and Teensy. Certainly with a higher bandwidth connection, I would be recording more data.

Yes, I'm concerned about the physical connection with the SD card. I've had an okay time using a good quality SD card and a buffer to log high rate data.
 
Brian: USBHost and MSC and uSDFS on that thread on T_3.6 @256MHz with 32KB buffer can do 6MB/s and bumping to 64KB write buffer goes to 10.39 MB/s. This is 'some old USB<>SATA drive box' I have that wasn't used in 6 years or so - not sure what drive is in it. Will have a new USB3 adapter box and 2.5" HDD with 128 MB cache to a 5400 RPM drive next week. Ideally that RAM cache for streaming write should do better if the USB<>SATA interface is good … and in the end an SSD would do even better?

Here is the timing writing 1,000 blocks of 64 KB:
Code:
(6329964 - 10.353297 MB/s)
 (open: 164960 us; close: 44999 us; write: min,max: 5705 11741 us)

I think that says 6.329 seconds for the group with block write max/min details.

Dropping to 32KB RAM buffer to write results in:
Code:
(5363964 - 6.108915 MB/s)
 (open: 29964 us; close: 17999 us; write: min,max: 4833 17869 us)

Open/Close and Min/Max values not ideal with re-running same test on the ROOT directory and FAT maintenance probably factoring in.

That's pretty cool! I'll have to play around with the library. I see some PCI to USB interface controllers on DigiKey, seems like I may be able to put a PCI slot on my boards and then use a M.2 2242 type of an SSD. Could be worth it if the performance is much better than SD.
 
PCI sounds like work … how about this:

QNINE NVME to USB Adapter, M.2 SSD to Type-A Card (No Cable Need), High Performance 10 Gbps USB 3.1 Gen 2 Bridge Chip, Use as Portable SSD, USB to M2 SSD Key M

There are multiple models like that it seems - USB already adapted to M.2 SSD!

I started looking for small SSD's when I saw that - but would still be USB<>SATA - though drive size is down to :: 1.96 x 1.18 x 0.14 in - but you get at least 120 to 500 GB - here is one 'Kingston 120G SSDNOW UV500 MSATA ' item - look at the compare list
 
Brian: USBHost and MSC and uSDFS on that thread on T_3.6 @256MHz with 32KB buffer can do 6MB/s and bumping to 64KB write buffer goes to 10.39 MB/s.

The SDHC clock divisor is limited so for best performance you need to carefully select the main clock. At 256MHz divide by six is the best you can do which means that the SD clock is slower than it could be. 200MHz would be best but that of course depends on the support in the libraries. Unless you do it yourself.

Which you might need to do. The Teensy 3.6 sources that I have looked at all have a "TODO" for the switch from <25MHz clock to <50MHz clock.

As for mechanical robustness, it worked for me.(Vibration and shock data is there as well.)
 
The SDHC clock divisor is limited so for best performance you need to carefully select the main clock. At 256MHz divide by six is the best you can do which means that the SD clock is slower than it could be. 200MHz would be best but that of course depends on the support in the libraries. Unless you do it yourself.

Which you might need to do. The Teensy 3.6 sources that I have looked at all have a "TODO" for the switch from <25MHz clock to <50MHz clock.

As for mechanical robustness, it worked for me.(Vibration and shock data is there as well.)

That 6 to 10+ MB/sec speed note was using USB to connect to USB to SATA controller - that library combo is prepped to work to USB, SDHC or SPI - not sure where it stands as far as maturity and perf
 
Got a little test setup - an EMMC breakout to a micro-sd card adapter. Tested on windows via a micro-sd to USB converter I have and it shows up as a USB drive and formats correctly.

Plugged into the Teensy 3.6 micro-SD slot and doesn't start up. Going to have to dig into what's going on.

IMG_3054.jpg
 
MMC cards (and presumably eMMC) are a bit different and will require changes to the SD card drivers.

I still have a 64MB MMC card gathering dust around here somewhere. I can't recall if I ever got one of my embedded systems to work with that. Looking at some of my old code, it appears that they will respond to CMD8 with illegal command just like a V1.0 SD card. Maximum clock speed is also lower.
 
EMMC breakout to a micro-sd card adapterView attachment 16682

From what I gather, you may have better luck with USB Host Mass Storage library https://forum.pjrc.com/threads/55821-USBHost_t36-USB-Mass-Storage-Driver-Experiments
and a USB to eMMC adapter.
Depending on the eMMC you have, this one
https://www.hardkernel.com/shop/usb3-0-emmc-module-writer/
or this
https://www.aliexpress.com/item/328..._expid=4960e892-46f0-48fd-a72f-df85667cddb7-1

Did not test myself, though.
 
Ok, May have to try with our testing uSDFS as I have a few of these ODroid emmc chips/adapters...
 
That would be great, Kurt.
The new mass storage driver (and a proper USB device) may solve all the age-old problems about low-latency logging; we could forget uSD-related occasional long delays!
 
Right now, it is not showing up at all... on my T4 board running the test programs. Almost like it is not showing up at all hardware wise.

I have not debugged it yet as I am more used to doing the stuff on USB... Have not tried much on SDCards yet.
 
Status
Not open for further replies.
Back
Top