Looking for high speed USB memory stick or SDHC reading solution

[mikeselectricstuff]

Just curious. You are using monochrome LEDs or RGB ones?

Alexander.

Usually monochrome. RGB often looks nasty due to colour balance issues. Mono (usualy white) is a lot more power efficient and usually looks nicer.
If you're doing interesting shapes and forms with LEDs, then colour is often only a small incremental improvement over the impact of the basic form, but adds a lot of complexity, cost and power draw. 
For example This and This (colour tint via filters), This (yellow LED) and This

[bingo600]

How about Xmos (the old INMOS xputer design .. renewed)
http://www.xmos.com/discover/products/xkits/reference

/Bingo

[mikeselectricstuff]

How about Xmos (the old INMOS xputer design .. renewed)
http://www.xmos.com/discover/products/xkits/reference

/Bingo

XMOS is something I've been meaning to look at - I even have an eval board somewhere. However it doesn't like they have any host stuff (yet)

[JVR]

Another idea.

Take a Cortex M3/M4, add a few MB of SDRAM on its EBI port, let it run a basic USB host.

You then plug the flash drive into the unit, cortex copies files from USB to SDRAM, and voila, deterministic clocking at any speed you want.

Hell of a lot less dev time / expense than an FPGA.  A decent 160Mhz+ M4 will probably do 20 SW UARTS without bitching to much.

[firewalker]

There will be about 10k pixels (leds) with 1 byte per pixel (?) @ 50 fps. So 10000*1*50 = 500.000 bytes per second. Does that sound correct?

Alexander.

[ptricks]

There is USB full speed (12Mbps) and very common on chipsets, then there is USB(480Mbps) high speed much harder to find on chips that do not contain processors and lots of pins .
I would copy the data to flash memeory from the sd card or usb drive and then use that as the source for the main processor. The cost would be lower and you don't need to use anything expensive to perform the task. You can use any 12Mbps capable micro ,  once it is in flash you can easily read it at high speed.  You wouldn't even have to change chips, you could still use the Pic24 chip to read the data , shift the bits out to flash and the pic24 could power off.

[bingo600]

I think i read that the $16 STM43F4-Discovery board will do HS-USB if you add an external USB-Phy
http://www.st.com/stm32f4-discovery
It can run up to 160Mhz

https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Discovery/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2FSTM32Discovery%2FSTM32F4discovery%20hight%20speed%20USB%203216&FolderCTID=0x01200200770978C69A1141439FE559EB459D75800084C20D8867EAD444A5987D47BE638E0F&currentviews=250

ULPI IF
http://www.ebay.com/itm/USB3300-USB-HS-Board-Host-OTG-PHY-Low-Pin-ULPI-Evaluation-Development-Module-Kit-/251069458682?pt=LH_DefaultDomain_0&hash=item3a74e7e8fa#ht_1299wt_1168

STM Doc (Search ULPI)
http://armvn-repo.googlecode.com/files/STM32F4-Technical-Training.pdf

STM ULPI Bug (Check the ULPI DS before using a specific one)
https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2FSTM32F2F4%20problems%20with%20various%20ULPI%20USB%20PHYs&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=524


/Bingo

[bingo600]

Seems like the STM is a but buggy unless you use their ULPI chip

This is a NXP with 32M Ram & USB-HS with onboard Phy (a bit pricey)
http://www.ebay.com/itm/Olimex-LPC-H3131-nxp-LPC3131-arm9-high-speed-USB-interface-SDRAM-FLASH-AUDIO-/280948717610?pt=UK_BOI_Electrical_Components_Supplies_ET&hash=item4169d9382a

Another 99€ + vat + ship
http://www.embeddedartists.com/products/oem/lpc3152_oem.php

With board 179€ (outch)
http://www.embeddedartists.com/products/kits/lpc3152_kit.php


The big lpc1830/50 sems capable also (Note the quad spi flash lanes)
http://www.digikey.com/us/en/ph/nxp/lpc1830-cortex-m3-mcu.html

But as with every ARM , check the erata before buy ...
The feature yo need might be buggy

Olimex claims this one has a USB HS port (nice price) , but sw ??
https://www.olimex.com/Products/OLinuXino/iMX233/iMX233-OLinuXino-MICRO/

More olimex (check if PHY is onboard/onchip)
https://www.olimex.com/Products/OLinuXino/iMX233/


Cypess new USB3 chip - EZ-USB® FX3
http://www.cypress.com/?id=3526&tabID=1
http://www.cypress.com/?docID=39055
http://www.cypress.com/?docID=41315
http://www.silica.com/product/cyusb3014-bzxi-ez-usb-fx3-usb-30-peripheral-con.html
http://uk.farnell.com/cypress-semiconductor/cyusb3kit-001/ez-usb-fx3-usb-3-0-jtag-dev-kit/dp/2082746

Cheaper board (But check if host)
http://agile-sdr-solutions.com/USB-3-0-Dongle-DVK
http://agile-sdr-solutions.com/USB-3-0-DVK

[andersm]

This is a NXP with 32M Ram & USB-HS with onboard Phy (a bit pricey)

Both the LPC3xxx and the Freescale i.MX2xx are ARM9-based applications processors, usually used with Linux and the like, I think Mike was looking for something more like a microcontroller.

[tesla500]

If you have an FPGA, why not use the Opencores SD card controller along with the open source FATFS stack, and read an SD/SDHC card directly? I have this working in one of my applications, getting about 1.4MB/s read with no optimization (only single block read, bursts of multiple blocks would be much faster).

[Psi]

You can get some pretty fast CF cards. (They're used in the high end DSLRs where speed is needed for high burst speed with RAW images)
They also make "rugged" CF versions with large operating ranges for temp and humidity (if that's useful)

The disadvantage is SD is slowly taking over CF, but it will sill be around for a while to come.

[mikeselectricstuff]

I noticed a cheap LPC1830 board at Farnell when I was looking for something to make up a minimum order,
http://uk.farnell.com/nxp/om13028-598/eval-cortex-m3-lpc1830-xplorer/dp/2217599?in_merch=New%20Products
This has SDHC and USB HS. The other thing I like about this range is that it has a huge 200K of RAM, which is often the first thing I run out of.

[bingo600]

This is a NXP with 32M Ram & USB-HS with onboard Phy (a bit pricey)

Both the LPC3xxx and the Freescale i.MX2xx are ARM9-based applications processors, usually used with Linux and the like, I think Mike was looking for something more like a microcontroller.

I do agree , but USB-HS with an installed (here onboard phy) isn't easy to get.
Maybe the 1830 is in the mcu class.

I just saw this lpc3131 board at a reasonable price
http://shop.embedded-projects.net/index.php?module=artikel&action=artikel&id=1296
http://gnublin.embedded-projects.net/

While i agree it's mostly used for linux , it's just an arm9 , and this ona also have 32M Ram

/Bingo

[mikeselectricstuff]

Onboard Phy & lowest cost is way down the list compared to something I can get working easily.
Thinking about it some more, I think SD(HC) is the way to go, as at least I'd stand a chance of debugging a "compiled it all but it's not working" situation - with USB there are so many things that could be wrong it would be a total nightmare to track down.
Also with SD it will be much easier to scope the pins to work out exactly where any performance bottlenecks are.

[mikeselectricstuff]

Just had a quick look at FatFS & looks very nice  & well documented. Also doesn't suffer from being split into gazillions of different source and header files, - something I hate about some C examples you find as it makes it very hard to follow.

The cheap NGX LPC1830 board I bought comes with some sample code for SD sector reads/writes in IAR so I'll have a go at welding the two together...

An interesting possibility with the LPC1830 is that as it has a nice fast clock and plenty of RAM to run code from (or put lookup tables in) , I may be able to implement a fairly large number of bit-bashed fast TX UARTs in software. Twenty 250kbaud ports at 150MHz is 30 instructions per bit per port, which should be doable.
I've done some hairy FIQ assembler on ARMs in the past so could be fun - pity they took out FIQ mode from the M3 as its dedicated register bank was very handy when doing very high rate interrupts.
 

[talsit]

This looked promising but speed is limited by the slow interface to the host, and the 4MBytes/sec speeds claimed turn out to only be useful for card-card copying.
http://www.ghielectronics.com/catalog/product/340
I think this is based on a ST ARM Cortex M3 chip.
If they had a way to, for example read USB and spit it out of the 4-bit SPI interface, under control of the UART port that could be ideal.

I'm using this for a project of mine. I'm doing basically fast writes to an SD, I never really read data off it, so I never looked at the read part, but after looking through it again, it's kinda lame. They support direct DMA writes, so in theory you can get quite fast throughput, but reading is done through their standard interface, which needs 4us delay between bytes. That's incredibly silly, especially since they have everything else.

[talsit]

I'm using this for a project of mine. I'm doing basically fast writes to an SD, I never really read data off it, so I never looked at the read part, but after looking through it again, it's kinda lame. They support direct DMA writes, so in theory you can get quite fast throughput, but reading is done through their standard interface, which needs 4us delay between bytes. That's incredibly silly, especially since they have everything else.

Not anymore!! I've abandoned the ALFAT, since it's an incredible load of utter crap. I was doing tests with it, trying to get the "Fast SPI Write" command running, and I noticed that between issuing the command and ALFAT telling it was ready for me to send the first 8KB block, it would take around 100ms. Then, at the end of that command, it would take a further 50ms. You could do multiple 8KB transfers per "Fast SPI Write", but if you're streaming data to disk, this 150ms total wait just kills you. The worse thing is that nowhere in the datasheet does it say that this is normal. I asked the manufacturer and they very calmly responded that this is normal, and sorry that it wasn't in the datasheet. So, effective throughput for streaming on a device with less than 128KB free is around 50KB/s, not the advertised 1.4MB/s.

So, I recall my recommendation....