1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

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

Discussion in 'Embedded' started by haiticare2011, May 22, 2014.

  1. Greetings,
    I am trying to get a reasonably fast ADC capability to a PC. I have
    been told that using the USB bus on a PC has latency, preventing the
    data from being gathered RT.
    So I am wondering if an embedded dev board somewhere has fast storage like a SSD
    that can accumulate data at say, 5-10 mB / s. I will also need a way to
    continually store the data. The only thing I can think of is to put a SSD on
    the USB port on something like a Pi, but I don't know if this would be fast enough.
    The camera which uses the GPU evidently records at 30 fps. Also, I see some activity around the "pru" on BBB.

    I need to control the ADC with SPI, which could be through the GPIO pins.

    Now you have to take the above with a grain of salt, since I am SW developer, and
    just looking for the magic combo of several features:
    -RT data storage on an SSD or equiv.
    -SPI control of an ADC
    -ability to send data to a PC periodically.

    Anybody ideas appreciated.

    jb
     
    haiticare2011, May 22, 2014
    #1
    1. Advertisements

  2. haiticare2011

    Paul Rubin Guest

    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:

    http://www.minnowboard.org/meet-minnowboard-max/
     
    Paul Rubin, May 22, 2014
    #2
    1. Advertisements

  3. Hi jb,

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

    <http://www.element14.com/community/community/knode/single-
    board_computers/next-gen_beaglebone/blog/2013/08/04/bbb--high-speed-data-
    acquisition-and-web-based-ui>

    Perhaps you could use the ADC of the BBB itself.
    Here you find some specs of it.
    <http://beaglebone.cameon.net/home/reading-the-analog-inputs-adc>

    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
     
    Reinhardt Behm, May 22, 2014
    #3
  4. haiticare2011

    Tim Wescott Guest

    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, May 22, 2014
    #4
  5. 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 <thing> 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
     
    Theo Markettos, May 23, 2014
    #5
  6. haiticare2011

    Paul Rubin Guest

    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.
     
    Paul Rubin, May 23, 2014
    #6
  7. haiticare2011

    David Brown Guest

    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 Brown, May 23, 2014
    #7
  8. 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.
     
    haiticare2011, May 23, 2014
    #8
  9. haiticare2011

    David Brown Guest

    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.)
     
    David Brown, May 23, 2014
    #9
  10. 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
     
    Theo Markettos, May 23, 2014
    #10
  11. Well, yes and no. No, you can't run standard distros. Yes, it's still binary compatible so you can run natively compiled programs. Assuming that most people are running development system on x86 Linux (aka PC/laptops), youdon't need to cross-compile as in the case for ARM.
     
    edward.ming.lee, May 23, 2014
    #11
  12. I have a Galileo board, which is the previous Intel idea to the Minnowboard.
    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.

    http://www.minnowboard.org/technical-features/
     
    edward.ming.lee, May 23, 2014
    #12
  13. 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?
     
    haiticare2011, May 25, 2014
    #13
  14. Is that PCIe on the Intel board fully functional?
    JB
     
    haiticare2011, May 25, 2014
    #14
  15. When is this minnow going to surface?
    jb
     
    haiticare2011, May 25, 2014
    #15
  16. haiticare2011

    rickman Guest

    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. :)
     
    rickman, May 25, 2014
    #16
  17. 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
     
    haiticare2011, May 26, 2014
    #17
  18. haiticare2011

    Stef Guest

    In comp.arch.embedded,
    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:
    http://sine.ni.com/np/app/main/p/bo.../sn/n1:7690,n25:device/sb/-maxsamplingrate_d/
     
    Stef, May 26, 2014
    #18
  19. haiticare2011

    rickman Guest

    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.
     
    rickman, May 26, 2014
    #19
  20. 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
    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.
     
    edward.ming.lee, May 26, 2014
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.