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

Amen, brother!

--
Randy Yates 
Digital Signal Labs 
http://www.digitalsignallabs.com

like a SSD

to

SSD on

e fast enough.

e some activity around the "pru" on BBB.

ins.

veloper, and

. I C

e

o

type

C via

e the

y.

using

ed. Until then, I can't play tinker-toys and plug the parts together. (whic h is

. It

l

ntly

outines massage the image data to make the image pretty.

BBB is

get

oser

would

C and

for

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

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

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

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:

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.

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

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.

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

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?

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.

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.

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

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.

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.

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 
    PC Services 
  Raspberry Pi Add-ons 
 Timing Diagram Font 
 For those web sites you hate

Actually, that is not a problem. It is not uncommon to spend millions of dollars on a fully custom design which then is mass produced amortizing that NRE over millions of units adding very little to the product cost. In the end the majority of the costs are the actual manufacturing costs which can be make very small. So there is no reason to build crap systems.

However... what is the reason to build quality systems? What is built is driven by the market. If people respond to the glitz and hype and buy new systems because they are new, then the makers won't have a reason to offer better products. Most product manufacturing figured out a long time ago that people don't scratch the surface on what they buy, even for high dollar items. So they give us surface glitz and what lies beneath will be secondary.

--

Rick