To embed or not to embed?

A one-off or a production unit?

FWIW, I have something similar in my order book. For low volume, we're going with COTS ADC/DAC boards on an i386 platform (possibly PC/104 - tbd), probably running OpenBSD (or similar). The areas I was leery of included: - PC link: we went for Ethernet. We needed a (much) higher bandwidth than your spec; kinda easier to do well with a BSD stack. (YMMV.) - High-resolution ADC/DAC: while I've done plenty of these at low-bandwidth, I was a bit concerned at the mixture of high-resolution and high speed... - Time to market & development costs, of course ;).

HTH,

Steve

Everyone dimly remembers the Nyquist theorem, and forgets that the Nyquist rate is the minimum theoretical rate. If your maximum signal frequency _component_ is 30kHz, then you should probably be sampling at around 100kHz to have reasonable anti-aliasing filters. If your signal is a 30kHz carrier with stuff impressed on it, you'll need to go much higher yet.

If you can stream the data into great big buffers and process it as the PC gets around to it then you're probably OK -- possibly even without the real time extensions. It's not so much the speed of the data that's a concern, it's the response time you need from some external event (like data commencing to flow into a buffer) until the OS responds.

Without knowing what sort of processing you need to do on the embedded side, and how tight any real-time requirements are it's hard to comment on this. If you're just streaming data into the PC and there are no hard timing requirements to get the data back to the DACs then you could do this with an embedded 'helper' processor quite easily. If you're doing something really complex then the embedded development will reflect that. Keep in mind that if you do have something really complex with tight real-time requirements by the time you get it working on a PC you won't really have a general-purpose PC any more -- you'll have a PC running as an embedded device.

You mentioned programming language, which is a good way to start a flame war on this group. Unless you're really a hot-shot assembly language programmer, or you have a very small application (which doesn't quite match up with using a 32-bit processor) I strongly suggest that you consider a higher level language like C, C++, Ada, perhaps Java. C is probably the safest pick if you want to have the largest pool of potential programming talent to draw from.

On Tue, 18 Apr 2006 15:37:01 +0100, Steve at fivetrees wrote in Msg.

More like a five-off ;-) for university-internal use.

--robert

On Tue, 18 Apr 2006 08:02:15 -0700, Tim Wescott wrote in Msg.

Let me put it like this: Experience in this application has shown that

The ADC data is a constant flow, but there must be a fixed relationship between the values the DAC puts out to the experiment and the data the ADCs read into the PC.

A PI regulator, currently implemented with analog circuitry. No real necessity to go digital on this except to save some knobs.

I know. I did some Z80 and 6502 assembler 20 years ago and I figured since my app doesn't really so much complicated stuff I could do it all in a single loop done in assembly. By far the most complex component will be the host link; I was hoping to find some building blocks to do this.

My own, particularly.

Thanks for the input! As I said, this is all very preliminary and I don't know yet if this project will be realized at all, and if so, in which form.

robert

agreed, if you don't need to reconstruct the continuous signal, otherwise it's impossible because you can not create the optimal filter.

btw Nyquist stated it even totally different: you need twice the bandwidth not twice the highest frequency.

Stef Mientki

Hi Robert,

My $0.02:

Given the target market size, I would describe it as a slam-dunk decision for COTS hardware as far as possible. The cost of buying platinum-dipped equipment is going to be nothing compared with the cost of developing, debugging and characterizing a fully custom design.

That's good enough for me.

Take a look at my web site for handy articles. One in specific is

Yea verily. If you _do_ want a separate system from your user's PC, consider a second PC, perhaps in the form of a PC-104 stack. This allows you to push all the real-time restrictions onto the embedded machine, without leaving the familiar PC architecture.

Forget a PC. It isn't that fast. Forget a PCI card. I'd vote for embedded. Linked to the PC with a decent link, USB, ethernet.

Rene