microcontroller advice? how to go about this...

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hey everyone,

I have a challenging project ahead for a large university and I was
wondering if someone could give some advice on what the best way to go
about this is...

Essentially what we need done is to read in about 32 ->64 (or more,
eventually, if possible) analog samples every millisecond - preferably
about 12-bit accuracy or better (my advisor said that, I'm not convinced
that 8 isn't fine too, but we'll see). Storing about 1/4 -> 1/2 a
second's worth of data to run algorithms on and look for patterns. Also,
it'd be nice (but not vital) to be able to transmit all that information
to a computer, which would probably require USB (alternately, we could
probably hook up the connection to some hardware in parallel, so the
data doesn't *need* to be fed through the controller).

Issue #1-
So, 64 analog samples/millisec - coming from 64 different probes - any
advice on some kind of an 'analog multiplexer'? Can such a mux switch
fast enough to support that kind of data reading? I see ADCs tend to get
to 100-200 ksbs, so that part should be alright. What's the best way to
go about being able to read all this data from different sources?

Issue #2-
Second, enough memory to hold 250 or 500 sets of data, that's also fast
enough to keep up with this rate of reading/writing. Worst case: 16 bits
-> 2 bytes * 64 samples * 500 ms = 64 k of RAM just for this. Can get
down to 32 K or sure with 1 byte data, or 250 ms, or some reasonable

Issue #3-
Preferable, but optional: To transmit all that data to a comp we're
talking 128 K/sec = 1 mbps - so we'd need USB, probably USB 2.0 - what
does USB 1.1 get realistically?

Issue #4-
Would I need a separate interface through the normal I/O pins be able to
send a signal back to those original location (to stimulate the tissue
there). Is there any other way to do that?

Any advice on a chip that can handle all of that? Not to mention that it
still needs to be fast enough to do computation on top of it, with all
the data in memory. Would it be wise to have dedicated ADC chip that
I've seen to do the gathering and a separate ucontroller for the rest?
Cost is a minimal concern as this is for a large research university.

Thanks guys!


Re: microcontroller advice? how to go about this...
I look at it a bit differently. Instead of ONE micro doing all, I'd use 8
micros, each handling the tasks for 8 analog inputs,data collection,and
transmitting to the host.
Reliability.If one of the micro 'hangs', the other 7 still send data.
Cost. Cheaper in the long run to have 8 smaller micros than one big one,esp.
since they are all identical.
Speed. Less to do per micro ,now the 'bottleneck' will be the PC
interface(USD or ???)

Re: microcontroller advice? how to go about this...

Quoted text here. Click to load it

Let's see:  64 analog samplese/millisec = 64,000 samples/sec X 64 probes =
4,096,000 probe-samples/second.  That's a lot of data for one
micrcontroller.  If you wanted to do this with one ADC and a mux, you would
need to perform each conversion in 1/4,096,000 seconds or 244 nanoseconds.
Not gonna happen.

I think you need to plan on more that one ADC.  Maybe plan on 64 ADCs in
your system.

Quoted text here. Click to load it

What?!  You want to sample 64 probes 64,000 times per second, at
12-bits/sample but you only want to hold 500 sets of data?  Let's say we get
extravagant and plan for 1 second of data, that would be 4,096,000 samples X
1.5 Bytes/sample =  6,144,000 Bytes or 6000Kbytes.  I think you memory
requirement estimates are off by 10X (at least).

Quoted text here. Click to load it

Forget USB, you are going to want 100Mbit/second Ethernet for this
application.  Maybe Gigabit Ethernet!  You'll also need more memory, wait I
already said that.

Quoted text here. Click to load it

What in the hell are you talking about?  Oh don't mind, we (usenet)  really
don't care anyways.

Quoted text here. Click to load it

No single "chip" can handle all of this.  You are describing a data
aquisition system the kind of which exists at Los Alamos or maybe a national
air-traffic control system.  You can't do this with an '8051 or even an
'8051 derivative!

Quoted text here. Click to load it

Good, because you should be planning on a long, arduous, and expensive
development effort if you are planning on building this system from scratch!
Why don't you visit the web sites of some companies like HP, Tektronix, and
others and see about purchasing this equipment?

Quoted text here. Click to load it

Re: microcontroller advice? how to go about this...
Bob F. schrieb:

Quoted text here. Click to load it

I think you completely misunderstood this.

As far as I understand, he was referring to 64 samples per ms,
not 64*64. The information that the 64 samples are data coming
from 64 different probes would not have been necessary (and
seemingly confused you).

I think though it would be possible with a single uC system,
the approach mentioned by j.b. miller is probably more efficient:
let a bunch of small and cheap 8-bit uCs process portions of
the data, independently. Eventually add a dedicated uC for
communication with the PC to reduce the number of interfaces.

Dipl.-Ing. Tilmann Reh
Autometer GmbH Siegen - Elektronik nach Maß.
We've slightly trimmed the long signature. Click to see the full one.
Re: microcontroller advice? how to go about this...
Quoted text here. Click to load it
I'd consider distributed uc system with 100Mbit/s Ethernet connection
to the computer. You will get good and well defined bidirectional I/O
channel and necessary modularity. Besides, you will be able to
simulate all the troughput on several standard computers.

Re: microcontroller advice? how to go about this...
Do you need to build many such devices or is it one off.
If it is a one off, then I 'd go with multiple 12 bit ADCs with an SPI
Then you connect that to a nice high end CPU with Ethernet. (AT91RM9200 :-)
More expensive than the multiple 8 bitters, but probably higher quality on
the ADC.
USB is not so easy to work with.
TCP/IP is supported in a much better way by the industry.

Best Regards,
Ulf Samuelsson   ulf@a-t-m-e-l.com
We've slightly trimmed the long signature. Click to see the full one.
Re: microcontroller advice? how to go about this...
Quoted text here. Click to load it

Go for 12 bit, or more. This sounds like a large snap-shot logger, and
it is poor design to scrimp on the front end specification.

Quoted text here. Click to load it

Ulf Samuelsson wrote:

Quoted text here. Click to load it

  The 91RM9200 would be a good choice for Host, esp as you way the PC
connection is 'nice, but not vital'.
  A higher end uP like the 9200 would also remove the
the real-time aspect from the PC, but the PC can still be
used for spread sheets :)

  For the 'Spread 12 bit ADC' fabric, look also at small uC with 12 bit
ADCs, as they can cascade and syncronise better/easier than a sea of
SPI ADC devices.
  eg look at

  they do High performance Analog+SPI+uC, with ADC specs of 12/16/24 bits

SPI uC can be set up to all sample/trigger their ADCs on a single edge,
and then cascade-shift all data in frames.
Think of them as smart-ADCs, not as uC.
  Eval Boards are available for all these above devices.

Re: microcontroller advice? how to go about this...
Hi Fred,

I suggest you check the Zilog z8 encore CPU which contains up to 12
channel 10-bit A/D converters with continues conversion mode and DMA
mode operation.
The chip contains up to 64K Flash for the program and 4K ram .
I propose that it would be easier to handle to create some kind of a
modular expandable systme rather a single system .
Multiple z8 could communicate throught SPI interface.

Another way you could address this problem is to use auto(free)
running converters, one per channel and to use a FIFO like the
averlogic AL422b or AL440B. Then use any microcontroler you like to
scan the FIFO devices .

The second method requires more hardware components, pcb size and cost
but very litle programming while the first one minimizes size of
board, is more cost effective but requires considerable more
programming effort.

Viron Papadopoulos.

Quoted text here. Click to load it

Site Timeline