Hello folks,

I'm thinking about embarking on a scientific measurement equipment
development sometime in the future. It's going to be a mixed-signal
control and data acquisition system with the following specs (just the
mixed-signal part; there's a lot more analog stuff involved).

--------

8 DACs >= 12-bit (six out of which are multiplying DACs which are
updated only infrequently)

1 DAC >= 20-bit

5 16-bit ADCs

Link to PC

Maximum signal frequency is about 30kHz, so I'd run the whole thing at
60kHz sample rate. The PC link continuously transfers data from four
ADCs which amounts to ~4MBit/s. The system will include some (simple)
DSP functionality with one of the ADCs and the 20-bit DAC.

------

The first and obvious idea is to use commercially AD/DA PCI boards and
realize the whole thing on the PC side. Even with a hard real-time OS
like RTLinux I'm not quite sure about timing issues. I'm sure it's
possible though.

I also want to look into the possibility of realizing the functionality
with one or more embedded processors which would fit into the same box
as the analog signal conditioning parts. My requirements are probably a
piece of cake for any half-experienced embedded designer, which I am
not. I've done a lot of electronics, both analog and digital, and a fair
share of software development, and for a long time I've wanted to marry
the two and go into the embedded world. I'm just not sure if this
project isn't too much for a starter.

What I'm doing right now is evaluating the possibilities and trying to
estimate how much time and people the whole thing will require, no
matter how it is realized, and if it will be worth the effort. And for
the case we so go embedded of course I would like opinions. The
architectures I'm considering are ARM and ColdFire. For the PC link I'd
like to use IEEE-1394 (but that's not fixed. It's just that I have
written software for it in another context and quite like it). The data
acquisition PC will be running Linux, so a toolchain running on that
system would be nice but not a must. Programming of the embedded part
will probably in assembly language.

Thanks,
robert

"Robert Latest" <boblatest@yahoo.com> wrote in message
news:4ak6n7Ftk5evU1@individual.net...
<snip>

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
http://www.fivetrees.com

Robert Latest wrote:

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.

--

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

Posting from Google? See http://cfaj.freeshell.org/google/

On 18 Apr, in article <4ak6n7Ftk5evU1@individual.net>
boblatest@yahoo.com "Robert Latest" wrote:

I assume this is a ONE off for lab use.
For a product the problems mainly relate around how long do you want to
make and support the product for.

It is amazing how many commercial cards only support Windows with these
cards, I know from my time working for a company in that field.

Depending on how long you want to support the product, changes in operating
system can happen a lot quicker than updates to drivers. Changes to
platform can be a pain as well, as in all slots changed to PCIexpress or
whatever and find out your cards no longer work in new systems for
hardware reasons and then the added driver issues.

If you are doing it as your own one off project, bear in mind your total
requirements, but consider building it up in parts. If using a commercial OS
check what drivers already exist as you could be spending a lot of time
writing and testing drivers. As an embedded system you could do your own
version of PC104, with having stackable modules added for each type of
instrumentation interface you get working next. The modules need not
stack on top of each other but could be ones addded to another board.
With the cost of some ARMs you may well consider having an ARM on each
daughterboard controlling that instrumentation interface to a base
board with comms and supervisory roles.

Either should be able to do what is required, but also consider the
ARM + DSP vendors as doing some preprocssing on the DSP could reduce your
link requirements.

Suitably fast transfer method, and if your familiar with it that is a good
point to start from. That is building upon what you already know in
increments.

Well the GNU toolchain (assembly and other languages) would be a good
place to start as they work under Linux for lots of processors, ARM
already supported. see http://www.gnu.org/

--
Paul Carpenter | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.gnuh8.org.uk/> GNU H8 & mailing list info
<http://www.badweb.org.uk/> For those web sites you hate

On Tue, 18 Apr 2006 15:37:01 +0100,
Steve at fivetrees <steve@NOSPAMTAfivetrees.com> wrote
in Msg. <GtKdnTbqJpMTZNnZRVnyvA@pipex.net>

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

--robert

On Tue, 18 Apr 2006 08:02:15 -0700,
Tim Wescott <tim@seemywebsite.com> wrote
in Msg. <zdGdnQGeSvXsYtnZnZ2dnUVZ_vOdnZ2d@web-ster.com>

Let me put it like this: Experience in this application has shown that
60kHz sample rate is enough.

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

Robert Latest wrote:
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.

Robert Latest wrote:

http://www.wescottdesign.com/articles/pidwophd.html. You may also be
interested in my book:
http://www.elsevier.com/wps/find/boo...on#description,
although if you're just looking for a non-critical PI loop it's more
than you need.

--

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

Posting from Google? See http://cfaj.freeshell.org/google/

larwe wrote:

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.

--

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

Posting from Google? See http://cfaj.freeshell.org/google/

Robert Latest wrote:


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
--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net