NetBurner Community Forum

SD bottleneck...USB...hmmm....

When you think about USB- think about the following:
1. If you buy somebody's USB solution, you will need the host stack, the mass storage and the targeted device drivers. 3 items. ~7k cost.
2. forget rolling your own USB code- too much work
3. The flash drive will work with the host stack and drivers, but nothing else will- no serial dongles, no wireless dongles, no hid devices - you would need to either buy or build drivers for those
4. hubs won't work. You would need to buy an extra component for the host stack that would support hubs
5. the resources necessary for the host stack and it's drivers are the precious SDRAM you are already short on, interrupts you don't have firing now, tasks you don't have running now, and more flash space.
6. I don't have any real numbers, but in my opinion, it is not possible for all of this new stuff to move faster than a simple SD card. Plus you wouldn't have the low-level control over the file system that you have now.

I am thinking that USB won't buy you anything for your design issues. It sorta sounds like you need a co-processor to offload some of the work to...or maybe a bigger system..or..

Chris

My opinion in short: when you need performance - use binary data format.

Chris: Thanks for your thoughts... very helpful. And, I agree with all of your points:
-- USB takes lots of complicated add'l software, and some add'l hardware off the board (hubs).
-- Sound like I need more RAM, and
-- more CPU oomph than the 5234 I use now.

That's why the mention of linux on the MOD54415 was so compelling and why it's too bad the USB pins are not brought out:
-- linux provides most of the software to support USB stacks, drivers, serial, hid, cameras, etc
-- the MOD54415 has >2X the CPU throughput compared to the 5234 (141 vs 358 Dhrystones)
-- the MOD54415 has lots more memory: 64K/16Mb/64Mb vs 64K/8Mb/2Mb on the 5234 = Internal SRAM/RAM/Flash
-- more native serial ports (although on '34 we use plenty of eTPU ports, particularly for slower baud channels)
-- faster SD throughput, and multiple SPI channels (although '34 supports add'l SPI through eTPU too)

Finally, I know that if NB offered linux on any platform, that it would be well-integrated into a really solid IDE, probably eclipse. There are lots of ARM9 linux embedded bards out now w/ high throughput and lots of IO, but getting linux and an IDE up, let alone keeping current are steep hills to climb!

Maybe the 54415 features, w/o linux and USB will be enough -- we'll certainly try! Our existing code would probably run w/o lots of rewrites. Certainly not true for a linux port!

Keep us posted Paul! Sounds good.

If you have 7 serial ports, you may have several via etpu. We found the etpu uarts interrupt once per byte. That can be a significant demand on the CPU depending on data rates. Using the port with the highest data rates on the hardware uarts helps, but even those only have a 4 byte FIFO. They also require frequent interrupts to manage, but what's cool is the DMA integration with the hardware UARTs nearly eliminates CPU interrupts if you exploit the DMA hardware in your serial driver. If you have additional hw uarts, you are still limited by 4 DMA channels on the 5234 module. Unfortunately freescale never tied the etpu uarts to DMA. The new module has many more hardware serial ports (8) and DMA channels (64) which is promising.

8SD Card speed....
Having multiple files open and having multiple different tasks access these files all at once will slow the SD card down by at least one order of magnitide.

I would really think about having a single file open and having a single task writing to that file.
With my UAVs
(helicopter and hovering rocket you can see both at the 8 min point of the discovery channel show here:
http://watch.discoverychannel.ca/daily- ... clip231152
)

I had each sensor log its raw data in a specific binary record type.
all of the different tasks wrote these raw records into a big 2Mbyte circular buffer and the file task just pumped stuff from this buffer to the file system.

I eventually ditched the file system complexly because after several hard crashes the buffering in the files system prevented me from logging the crash cause.
I changed to just writing to the raw SD card sectors and added a utility on the PC that read this raw data and reconstructed all of the different sensor log data from the raw binary records.
That way I never lost more than 1500 bytes of log ever.... (The S/W and hardware also improved to the point that I did not crash as often)



Paul

Paul: Really cool blue ball! Bravo!

That was a great bit of video. Congratulations Paul. Thanks for posting the link.