SparkFun Forums 

Where electronics enthusiasts find answers.

By ralphnev
#185764
does anyone know of a Single Board Computer (SBC) with an accessible External Bus Interface (EBI)
and to put further constraints
1 gig of sdram on board (or more)
EBI runs at >10Mbytes/sec (dma'able)
---
my current project(s) work (barely) at ~1Megabyte/sec on a Due
but i need to "up the game" to collect ~360megabytes in <90sec

bottle necks are mostly in data movement & storage

RPI's are crippled (lack of documentation )
BB are nearly there (EBI is partial buggered & not enough sdram)
UDOO lack of external bus ...
(yes .. they are scattered across the workbench)

currently working with a Altera Cyclone V (DE0-Nano-soc) but my head is sore from the brick walls ive been running into ...
User avatar
By phalanx
#185814
While I've used bus interfaces on microcontrollers before, I've never had to push the amount of data that you are looking to do so I'm not well versed in the max performance you can achieve with commodity development boards and lower end microcontrollers.

The most I can add is to take a look at the Zynq based boards. Zynq is Xilinx product that consists of an ARM core surrounded by FPGA fabric that can easily support your data transfer needs. If you don't have a history with logic design using HDLs, this may be a bit of a reach for you since you will have to design the bus interface yourself unless you can find some usable IP that already solves the problem.

Some possible boards are the PicoZed and MicroZed from AVnet which can be found here: http://zedboard.org/

There a free (if downloaded electronically) book that goes into great detail about the Zynq infrastructure and it includes practical examples on readily available demo boards. http://www.zynqbook.com/

-Bill
By ralphnev
#185815
i'm currently using Cyclone V which is nearly the same as Zynq
just Altera instead of Xilinx ... dual arm lots of fpga cells / yada yada yada

just that is the problem i want to get away from the heavy lifting of complex OS's & designing the bus arch. etc
i don't need USB // don't need gui //don't need 99% of HID // don't need a CLI & the 10meg of tools that go with it

something with a defined external bus & well documented DMA
with a few pins left over to run a touch screen

IF i can get my data all into ram, a slow dump to sdcard would be fine

sigh...
User avatar
By phalanx
#185822
You're in a tough spot with your requirements. Higher end microcontrollers with EBIs can meet your 10MB/sec acquisition rate but will be hard pressed to efficiently interface with the amount of memory you require. As you transition into the world of microprocessors which have the bandwidth and resources to work with memory other than SRAM, you start being burdened by the potential need for an OS of some sort.

What exactly are you trying to do and are you sure there isn't a more efficient way of handling your data instead of buffering your entire capture and writing it afterward?

I know you don't want to do logic design but a sub $100 FPGA board could acquire your data and simultaneously write it to an SD card without having a huge amount of onboard memory.

-Bill
By ralphnev
#185844
I build my own cameras using linear sensor arrays / to get a specific effect called slitscan
see https://www.facebook.com/RalphNevinsPhotography/ for examples

the problem with simultaneously writing is : sdcards can have up to 300ms lag times ...
& without a LARGE buffer data goes missing

// and with a increase of data ((moving to colour & higher line rates)) this issues only gets more problematic
quick calc-> 300*16kbytes/line = 4.8 MB buffer in 1/3 of a sec (~15MBytes/sec)
-- if i can get things up to full speed for the proposed next vers

and if the sdcard hiccups more than once that memory req just gets bigger

current design is running 4kbytes every 7ms (.5MByts/sec) in ~60kbuffer on the Due
// with a very tightly coupled PWM/DMA/ADC
and buffer overruns at the initializations of nearly every run
but it is tolerable since the remaining writes are correct for the next 10min

bottom line // I thought it would be just easier to capture that image /
then write .. rather than try to stream to files ...
though the sw issues seem to be bogging me down