Does this exist - dev board with GPIO and fast storage to a SSD or equiv.

You mean you have to react to adc events almost instantaneously? USB has an isochronous mode used for stuff like video streaming. It does have some latency, it might be low enough depending on your requirements.

The Pi and BBB have SD/microSD card slots as alternative to the USB, though sustained i/o at that speed might be pushing it.

There is a new Intel board in the same space, though I think not yet shipping. It has USB3 and SATA:

Hi jb,

have a look at this. They have at least done fast the data acquisition.

Perhaps you could use the ADC of the BBB itself. Here you find some specs of it.

I am not sure if the SD-card interface and the card itself can support the sustained writing speed you want. But you use a PC connected thru Ethernet for this.

Since the BBB has a 100MBit/s Ethernet it should be possible to just push the data over to some storage or PC.

Cheers Reinhardt

If you're storing it off to disk you're not using it real time.

What's your real concern? A decent data acquisition system, with or without USB, should be able to capture everything coming in.

--

Tim Wescott 
Wescott Design Services 
http://www.wescottdesign.com

I'd be tempted to use a SATA SSD. They're bigger, cheaper (per GB), more robust, and less prone to performance variability if you buy the wrong one (you don't go from 1000 IOPS to 10 IOPS like you do if you buy the wrong SD card). If you buy a USB it's not doing USB natively, it'll have a bridge chip the other side of the USB interface, which adds more latency. While SATA makes no guarantees about latency, it's much less work from a CPU perspective than USB.

I haven't been keeping up with all the new boards, but some of the ARM boards that run Linux have SATA ports and GPIO.

Theo

I have no personal experience in this area but a hardware guy warned me recently that complex ARM boards tend to be full of software bugs in the Linux drivers due to corner cases in the specific hardware, etc. He said the Raspberry Pi is pretty reliable because so many were in use that the bugs have mostly been found and fixed by now, and the Beaglebone Black was #2 in number of units deployed, but for the others you should expect to spend some of your development time on Linux kernel debugging. I don't know if this applies to the Minnowboard that I mentioned, which is an x86 board rather than an ARM, and I think it is designed by Intel rather than by hobbyists.

No, you have not been told that. In all your posts in sci.electronics.design, you have been told that USB can have significant latency depending on how it is used - but you have also been told how it can work fine for the job you describe. USB latency can be an issue if you need fast turnaround (read something, then write something new depending on what you read) - for continuous reads of an ADC, there is no problem. You have also been warned not to connect other devices to the same USB bus.

You have also regularly banded around the term "RT", without showing any understanding of what "real time" actually means. It does not mean "as fast as possible", or "as fast as I can imagine", or "as fast as randomly picked numbers that may or may not apply to some parts of the system". It /really/ means "within a guaranteed pre-determined time limit".

Getting back to reality, you have been thinking of using one or more ADS8344 ADCs. These have a maximum rate of 100 KSps, at 16-bit. A

2Mbps (Mb is "Mega bit" - mB is "milli byte") SPI bus will saturate the device (even allowing for some overhead). But even if you have 4 of these devices on a common SPI bus, an FTDI USB-to-SPI module will handle them all. The USB latency will mean a slight delay between starting and receiving the first input, but if you do your PC-side software correctly then you should be able to get continuous sampling, with data coming in at 800 KB/s.

Why do you think you need an SSD to get 10 MB/s? (I assume you mean 10 MB/s, i.e., 10 Megabyte per second, rather than 10 millibytes per second.) Even a decent USB memory stick will cope with that - it is certainly not a challenge for a hard disk, an good network, embedded NAND, etc. And of course it is 10 times the rate of the ADC (guessing 4 chips in parallel).

And this is all pointless unless you can say how much data you need in total.

You really need to start figuring out what data you actually want to collect, and what sampling rates you have there. Once you have realistic values there, you can start to work out what you need in order to collect and process that data. Randomly picking parts of the chain with throughput rates differing by several orders of magnitude will not help.

You don't know if it will be fast enough, because you don't know what "fast enough" is. An SSD on USB 2.0 will peak a bit lower than 60 MBps, since that is the limit for USB 2.0. It is the same rate as you will get with a hard disk on USB 2.0.

What camera? What GPU? And so what?

You think you need SSD speeds to store the data, but GPIO bit-banging is good enough for your SPI bus?

Here's the best idea - find yourself a systems designer who can specify the system and get a realistic picture of how the parts will fit together. You've asked repeatedly about this in s.e.d., and leapt between a USB module, PCI express cards, microcontroller boards, and high-spec PCs, with corresponding leaps in the data throughput you think you need - without ever giving useful concrete information about your requirements. And now you have jumped back to the beginning again in c.a.e.

So find someone who knows about hardware, and knows about the task you want. Talk it over with them, draw pictures on a whiteboard, and get the requirements clear. Once you have that in place, come here and ask again - then you can get useful help.

David, Actually, I am getting useful help. And you have been a purveyor of some of that. As I was at pains to point out, and did, the speed of acquisition is open-ended - the spec is "as much as is practical for my situation." IOW, I'd like to do this for less than 1k$ right now.

Alhough your manner is one of constant exasperation, you have given me useful leads. :) I have downloaded all the datasheets for the FT4232 dev board - and the MSSE docs.

But you must realize, opinion onions have various layers, and I have received much good info here, though most of it is partial and not due to my lack of precsion, IMO.

The situation is like SETI - Those guys don't know what BW the signal has they are searching for. In my case, we are going to be sensing medical diagnostic situations, and I can't a priori specify what the data through-put will be, except that the process will reveal it. (See the quote below.)

That you stick to your guns about USB latency is a good sign for your FTDI solution, BUT I'm still concerned about the OS handling the data and storing it quickly.

John

"If you are not confused at the start of a project, you are doing something wrong." - Jim Williams, quoting R Feynman.

Pick a speed you like, buy a pre-made data acquisition system, and try it out. Once you have sample data there, you can decide whether that speed was fast enough, or too slow. /Then/ you can start specifying what you want in a /real/ system, and start putting together something that will be more cost-effective in quantity and better tuned to the final usage.

At the moment, you are guessing a ADCs with a total data rate of 1 MBps, an SSD that can handle 300 MBps connected to a USB interface at about 50 MBps - you are all over the place.

There is a reason this stuff is called "Research and Development". Do the research, then you can start of the development.

And don't guess about OS data handling being "a concern" - either listen to people who have told you what they know, or try experiments yourself. And note that /you/ are the person who has been insisting on using a PC because it has high throughput, high processing speed, and high quality OS's and development tools. A $2 microcontroller can handle the speeds you have at your current bottleneck - a PC should not have a problem storing this data.

(Yes, I am in constant exasperation here. I am trying to help, but this is /not/ how you should be developing any sort of project.)

That is a risk. I'm especially wary of the chips with non-complete public datasheets (eg NVIDIA, Allwinner) because you can't just dive in and fix things. The kernel engineering of some of the SoCs is patchy too (vendor releases sources for 2.6.29 or something, it's a big effort to port to modern 3.1x, maybe some of the drivers like graphics or wifi are binary-only).

I have a Galileo board, which is the previous Intel idea to the Minnowboard. It's utterly utterly terrible for IO. There are 2 (yes two) high speed GPIO lines - the rest are all via I2C expanders, max speed 240Hz. If that's not your cup of tea you have USB or PCIe - which are fine, but then they dress it up in an Arduino formfactor and pretend it's a microcontroller.

Plus they don't run standard i386 Linux distros, so you can't just boot Debian on the thing like you can with most of the ARM boards. So the primary reason for picking Intel (binary compatibility and the large x86 ecosystem) is gone.

IMO Intel have completely lost the plot as far as embedded goes - if it isn't PC architecture they don't know how to handle it. They're currently making plans for IoT but they haven't a hope. IMHO anyway.

Theo

Well, yes and no. No, you can't run standard distros. Yes, it's still bin ary compatible so you can run natively compiled programs. Assuming that mo st people are running development system on x86 Linux (aka PC/laptops), you don't need to cross-compile as in the case for ARM.

If you look at the block diagram, the 8 GPIOs come out of the controller hub, rather than SPI. So, hopefully it would be high speed, but remains to be verified.

Thanks David. I have been surveying a plethora of different ways to bet high data througput with solutions that are PC-centric, SBC-centric, and MCU-centric. I can say there is little consensus about how to do this. What kind of latency do you have for USB data transfers?

Is that PCIe on the Intel board fully functional? JB

When is this minnow going to surface? jb

I would design this system by hanging a small SBC on a USB port of a PC. I still have not seen any numbers for the sample rate of the ADC, so I will have to assume your number of 5 MB/s is valid. Certainly you should be able to get that on USB 2.0 which has a max rate of 60 MB/s.

If I understand your needs correctly, the SBC can either include the ADC or control the ADC over an SPI interface quite easily. The data can be provided to the PC as a virtual disk drive or as a COM port negating the need for any special drivers. The PC can write the data to any storage device you wish. As part of the protocol for talking to the PC you can include whatever control info you have in mind.

Once the data is captured by the SBC handling it no longer needs to be "real time" in that you can use a buffer to provide storage during any delays in communications. As long as the average rate is high enough no data will be lost.

The required program on the SBC should be fairly easy to write if the vendor provides adequate examples for USB and I/O. The SBC does not require PC like hardware or even any sort of operating system. It just needs USB and the I/O you want. I would recommend that you look at the chip maker's eval boards. NXP, ST and Atmel are popular ARM manufacturers with a wide variety of eval boards to choose from. A Cortex M3 or M4 should do this job very well. You might also consider the advantages of Ethernet over USB as well. There are plenty of such boards with Ethernet support. :)

--

Rick

Thanks. OK - That seems reasonable to break up the architecture in a "bare metal" type board which is data-facing plus a PC which is storage-centric.

SO I guess what you are saying is that the SBC can send the data to the PC via ethernet or USB, and accumulate it RT in a buffer on the SBC.

One problem is that, if you dig into some of the popular SBC systems, like the ARM335x, the actual ability to communicate with the world is pretty crappy. One fellow (shabaz) tried to use USB-ftdi and abandoned it. Next he tried using the PRUSS, a co-processor on the BBB, and eventually got 1-2 mHz speeds.

What is lacking is actual solutions by hackers/companies that are published. Until then, I can't play tinker-toys and plug the parts together. (which is what I want of course. Like to avoid 6 month development detours.)

As an example, look at the Raspberry Pi camera, a 5 mp Omniview cmos chip. It communicates with the Pi via a coprocessor section and high speed paralell cable. This is the PRU idea, a dedicated coprocessor which runs independently of the SBC mcu. Hijacking this data line is not feasible since internal routines massage the image data to make the image pretty.

That's the type of solution which would work on a SBC, and it's what the BBB is "supposed" to do in the PRU. But actual working code is scarce. This will get better over time, prolly.

Another solution along this line of thinking is choose a board that is closer to bare metal, yet one that can input, store, and pass on data. No OS. It would need to be able to store data in local RAM and pass it on.

The loop I get into with that solution is you are asking a lot of that SBC and wanting it to address memory, etc. without an OS. We worked on a DSP card for the PC that did part of this.

So thanks for your input. The "missing link" remains elusive.

jb

I've been following this thread loosley but still have little idea what it is you actually require. Is this for instance for a one off system or do you need to mass produce this?

If this is a one off, there are manufacturers that sell aquisition cards for PCs that may do what you want. But these are usually not cheap. National Instruments is one example:

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail) 

 "Someone's been mean to you! Tell me who it is, so I can punch him tastefully." 
-- Ralph Bakshi's Mighty Mouse

If this is a one-off design, then you are going to need to do some work I think. If any part of this becomes a 6 month detour then you are not the right person for the job.

Of course. The reason to get away from programming the PC in real time is the OS. So why pick a SBC with an OS??? That's not bare metal.

??? Addressing memory is hard? I'm not sure what you mean by this but I think you are showing your lack of familiarity of lower level programming. That is not intended to be offensive, just a statement of fact. On a SBC with no OS, the only difficult part is programming the interface to the host PC. You should choose one that has plenty of example code for doing this.

Like I mentioned before you can let the SBC emulate a storage device in the eyes of the PC. If you need a separate I/O channel for control it can add a serial port emulation or perhaps an HMI. Mostly likely you can add a protocol to the storage interface to support both data and control.

Again, not trying to be offensive, but you keep looking right at the solution and passing it over. You seem not to be asking questions to learn what others have already learned, but to find a quick and easy solution to your problem that requires no learning. If that was available I think you would have received it already.

To be honest, I expect there are data loggers available that will do exactly what you need. You might want to look for a COTS solution which is the truly easy path.

--

Rick

First of all, you need to help us understand what you really want.

You talked a lot about A2D, but then this:

Do you want data acquisition or imaging, or even video? I think you said something about 30fps before.

Can't suggest the solution without knowing the requirements.