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

haiticare2011@gmail.com wrote:
> Is that PCIe on the Intel board fully functional?
> JB

I don't know of any reason why not, but I haven't used it.  Though the usual
way with these things is you only discover the gotcha on page 879 of the
datasheet when you're too deep down the design process to back out :(

Theo

PS: Please trim your quoting, your quotes are coming out double-spaced which
is even more painful to read than normal excessive quoting

Theo Markettos <theom+news@chiark.greenend.org.uk> writes:

> haiticare2011@gmail.com wrote:
>> Is that PCIe on the Intel board fully functional?
>> JB
>
> I don't know of any reason why not, but I haven't used it.  Though the usual
> way with these things is you only discover the gotcha on page 879 of the
> datasheet when you're too deep down the design process to back out :(

Amen, brother!
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com

On Monday, May 26, 2014 8:33:16 AM UTC-5, haitic...@gmail.com wrote:
> On Sunday, May 25, 2014 3:27:55 PM UTC-4, rickman wrote:
> 
> > On 5/22/2014 5:47 PM, khaitiscare2011@gmail.com wrote:
> 
> > 
> 
> > > 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.
> 
> > 
> 
> > 
> 
> > 
> 
> > 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

maybe more horsepower than you need, but a board or board stack to eval from WinSystems might be worth a look. I know they have some boards in medical equipment too (blood analyzers, culture growing, etc.) and they (JUST recently) have an ARM board but, most of their stuff is x86 still. Not cheap, but US based support.

On Thursday, May 22, 2014 5:47:31 PM UTC-4, haitic...@gmail.com wrote:
> Greetings,
> 
> I am trying to get a reasonably fast ADC capability to a PC. I have
> 
 I want to thank everyone for the comments. I have gotten some very good leads 
and ideas. Some of the 'ready made' boards look promising, but I am always wary 
of what is lurking in the software API.

And what's lurking in their analog design - They have analog circuits sitting 
next to noisy digital circuits. Is the analog signal polluted by noise? Do the 
LSB's bounce around on multiple measurements? 

I am reminded of Jim William's article, "ADC - How to get all the bits you paid for."

And I must address the "open ended" aspect of my quest. I am trying to design 
an AI system for which I don't know the data input BW. But I suspect faster is 
better. 

Before you throw up your hands, consider that when you write a computer app, 
say it's a program to do pattern recognition on X-rays (or a computer game.)
Your HW designer says to you "How much main memory do you need?" You scratch
your head and say, "4 gB should do it now." Then he says, "let's put in 16 gB 
as insurance." "And a TB SSD." 

However, when it comes to I/O, there is a different story. 

A final word is that the PC architecture seems to me like a blind animal. 
(tangent alert! :)  If you dissect a human brain, you will see that a large optic nerve is connected directly into the brain. It forms a bus to deliver 
a constant stream of optical image information. As much as low speed neurons 
can, many in parallel. 

Again, thanks everyone for all the help.
jb

On 5/31/14, 10:04 AM, haiticare2011@gmail.com wrote:
> 
> And I must address the "open ended" aspect of my quest. I am trying
> to design an AI system for which I don't know the data input BW. But
> I suspect faster is better.
> 
> Before you throw up your hands, consider that when you write a
> computer app, say it's a program to do pattern recognition on X-rays
> (or a computer game.) Your HW designer says to you "How much main
> memory do you need?" You scratch your head and say, "4 gB should do
> it now." Then he says, "let's put in 16 gB as insurance." "And a TB
> SSD."
> 
> However, when it comes to I/O, there is a different story.
> 
> A final word is that the PC architecture seems to me like a blind
> animal. (tangent alert! :)  If you dissect a human brain, you will
> see that a large optic nerve is connected directly into the brain. It
> forms a bus to deliver a constant stream of optical image
> information. As much as low speed neurons can, many in parallel.
> 
> Again, thanks everyone for all the help. jb
> 

The big part of the difference is that for the memory, you came up with
a "nominal" value that was in the range of mainstream. If your first
estimate for memory requirements had been 100GB, the results would have
been very different (doable, but not so trivially). If your request for
memory had been, I want absolutely as much memory as I possibly can get,
the question first needs to come back, what is the budget, are we
talking spending Billions of dollars on a memory system (that could be a
very impressive system), or do we merely have thousands of dollars for
memory, or is it hundreds.

I/O bandwidth works the same way, some levels are easy to do, you can
push a bit with a bit more effort/cost, and go past that with radically
more expensive costs.

Hopefully, you have some idea of what your currently available sensors
can provide in a data bandwidth. This provides your equivalent of the 4
GB). You can then also estimate things are apt to increase, and what
might be relatively simply expanded to (that is your 16GB, what you can
easily expand to in the realm of normal systems). For I/O this might be
that if the first said USB 2 would work, maybe you put in USB 3 for head
room. Your TB SSD in the example is a hook to allow you to implement
larger solution with other costs (the SSD is much larger but much slower
than main ram, perhaps the equivalent would be an external device that
gathers bursts of data on multiple high speed changes, perhaps crunch it
down a bit, and then send to the main processor at a slower speed.

Without some sort of first estimate it is impossible to get any sort of
reasonable "solution".

"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."

Yes, I fired myself recently. :) I see a continuing involvement with this aspect.
I must admit, there seems a big gap between reality and specs when it comes to IO on microprocessor systems. 

If I want storage memory on a PC, and the year is 1972, then engineers would want to question me about how much exactly? 2 mb? 12 mb hard drive? What exactly am I trying to do? Process punch cards faster? 

Then long term economic forces took over, and no one asks these questions today. 

But for IO, there doesn't seem to be any standard for low latency, high-speed transfer. I think circuit designers can do it, there is no violation of the laws
of physics required here - I just don't think the economic forces demand it.

jb

On 2014-06-03, haiticare2011@gmail.com <haiticare2011@gmail.com> wrote:
>
> "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."
>
> Yes, I fired myself recently. :) I see a continuing involvement with this
> aspect.
> I must admit, there seems a big gap between reality and specs when it comes
> to IO on microprocessor systems. 
>

As you have been told several times, including by me, don't confuse what
the operating system is capable of with what the underlying hardware is
capable of. Also, please look at the dedicated RTOS options; a couple of
open source ones are RTEMS and eCos:

http://www.rtems.org/
http://ecos.sourceware.org/

> If I want storage memory on a PC, and the year is 1972, then engineers would
> want to question me about how much exactly? 2 mb? 12 mb hard drive? What
> exactly am I trying to do? Process punch cards faster? 
>
> Then long term economic forces took over, and no one asks these questions
> today. 
>

Oh yes we do, at least when it comes to servers.

[My embedded work is a hobby, but working with commercial systems is my
day job.]

The reasons are the same as well.

How much memory do the workloads need ?
How much disk space ?
How much expansion and growth in the future do we design for ?
How many potential transactions per second do we need to spec for ?
How complicated are those transactions ?
How much uptime do we need to be able to try to guarantee ?
Etc, etc.

> But for IO, there doesn't seem to be any standard for low latency, high-speed
> transfer. I think circuit designers can do it, there is no violation of the
> laws
> of physics required here - I just don't think the economic forces demand it.
>

That's because, just as with my server example above, there is no one
correct answer. You need to decide _what_ you need to achieve, _then_
you can decide what technology options exist given those constraints.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

On 6/3/2014 9:26 AM, haiticare2011@gmail.com wrote:
>
> "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."
>
> Yes, I fired myself recently. :) I see a continuing involvement with this aspect.
> I must admit, there seems a big gap between reality and specs when it comes to IO on microprocessor systems.

That is because you are using the wrong tool for the job.  You can use 
embedded, real time hardware and software to do what you want.  You need 
to not focus on a PC as being the end all, be all solution to every 
problem.


> If I want storage memory on a PC, and the year is 1972, then engineers would want to question me about how much exactly? 2 mb? 12 mb hard drive? What exactly am I trying to do? Process punch cards faster?
>
> Then long term economic forces took over, and no one asks these questions today.
>
> But for IO, there doesn't seem to be any standard for low latency, high-speed transfer. I think circuit designers can do it, there is no violation of the laws
> of physics required here - I just don't think the economic forces demand it.

I'm sure you could do what you want with a PC if you have people with 
the right background.  Or you can do it with embedded hardware, either 
stand alone or in conjunction with a PC.  The details of doing anything 
close to the hardware with a PC is very complex and requires a lot of 
specific experience... nearly all of it relating to how to work with the 
OS.

-- 

Rick

On 03/06/14 15:26, haiticare2011@gmail.com wrote:
> 
> "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."
> 
> Yes, I fired myself recently. :) I see a continuing involvement with
> this aspect. I must admit, there seems a big gap between reality and
> specs when it comes to IO on microprocessor systems.
> 

And what do /your/ tests show you?

You've read a little about problems some people have had, long ago, on
some systems that are doing something vaguely similar to what you think
you might want to do.  And from that, you feel qualified to make blanket
statements?

> If I want storage memory on a PC, and the year is 1972, then
> engineers would want to question me about how much exactly? 2 mb? 12
> mb hard drive? What exactly am I trying to do? Process punch cards
> faster?
> 
> Then long term economic forces took over, and no one asks these
> questions today.

People in this newsgroup (and sci.electronics.design before it) have
been asking /you/ these questions repeatedly.  And you have continually
failed to answer them, or even acknowledge that they are worth considering.

Back here in the real world, where people make embedded systems that
work, PC systems that do their job, and server systems that get the
right balance between cost and performance, we /do/ ask these questions,
and we /answer/ them.

> 
> But for IO, there doesn't seem to be any standard for low latency,
> high-speed transfer. I think circuit designers can do it, there is no
> violation of the laws of physics required here - I just don't think
> the economic forces demand it.
> 

It is certainly true that we are more limited by the laws of economics
than the laws of physics.  The popularity of an IO standard is often
more important than the technical aspects, at least when determining
price and availability.  But there is enough choice available for most
purposes - as long as you know what you need.

In article <a2f7d5e9-3289-4561-be53-7782c4626c25@googlegroups.com>, 
haiticare2011@gmail.com says...
> 
> "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."
> 
> Yes, I fired myself recently. :) I see a continuing involvement with 
> this aspect. I must admit, there seems a big gap between reality and 
> specs when it comes to IO on microprocessor systems. 

The gap appears to be between reality and your expectations and any form 
of testing.

> If I want storage memory on a PC, and the year is 1972, then engineers 
> would want to question me about how much exactly? 2 mb? 12 mb hard 
> drive? What exactly am I trying to do? Process punch cards faster? 

I REGULARLY see home users who went to some TV advertised place and
bougth a PC/laptop from the smarmy salesperson based on system looks
and bullshit about the 'free' software, oh and be CHEAP. Then they find 
their system is slow just starting up and trying to browse internet as 
they have something like Windows 7 and just 1GB of RAM.

> Then long term economic forces took over, and no one asks these 
> questions today. 

People STILL get it wrong today.

The prime economic force is too many people wanting to get things for 
next to nothing or free but expect it to work as if it was multi-million
dollar custom built solution.

> But for IO, there doesn't seem to be any standard for low latency, 
> high-speed transfer. I think circuit designers can do it, there is no 
> violation of the laws of physics required here - I just don't think
> the economic forces demand it.

Mainly because those requesting don't know what they want and expect all
IO (digital and analog) to be capable of doing anything in ANY 
configurtaion on any size system.

In another place someone asked about where to find an addon that could 
do

   "32 digital input
    32 digital output
    8 Analog in
    8 Analog out"

Was surprised when asked what data rates, bit depth and sampling rates
were required.

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.pcserviceselectronics.co.uk/pi/>  Raspberry Pi Add-ons
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.badweb.org.uk/> For those web sites you hate