Re: Wich 16-bit MCU?
- From: "rickman" <spamgoeshere4@xxxxxxxxx>
- Date: 29 Jun 2006 05:10:21 -0700
Robert Latest wrote:
Hello,
I'm now at the point where I'll have to dive into building an embedded
data acquisition system. Last time I did that was about 15 years ago --
burn-and-crash with an 68008 and an EPROM, much along the lines of
Chapter 11 in AoE (just to illustrate the point at which my uC knowledge
froze over).
What I need to do, in real-time, is this -- just to estimate the
workload the CPU has to cope with:
1. Read out one 16-bit ADC at 60 kHz rate, do a bit with the numbers and
write back out to an ADC at the same rate. This is a PI servo loop that
also could be done in analog hardware if the CPU isn't up to it.
2. Read out three 16-bit ADCs at 20kHz rate and store results in RAM
3. Update two 16-bit DACs at 20kHz (numbers come from a couple of
Bresenham's algorithms).
4. simple link to host Computer, 800kB/sec (SCSI?)
Task 1. must run continuously. Tasks 2 and 3 run simultaneously but
alternatingly with 4.
Based on what I've done I'm partial towards the 68k assembler, so I
looked at Freescale's website and found the aged, but pretty attractive
MC68332 MCU. Then there's their Coldfire product line which seems to be
a bunch of faster/cheaper variants of the same theme.
My problem is getting started with all this. I don't want to drag the
old EPROM burner out of the basement; I think the latest fad (late as of
probably 15 years ago) is in-circuit programmability and -debugging.
I'm just wondering into which architecture should I invest time and
money in terms of a development system, and how much. Unfortunately the
app notes I found on many MCU vendors mainly cover embedded networking
applications and not the more down-to-earth stuff I'm interested in.
Like I said, I like m68k assembler but I've heard good things about ARM,
too.
I think you are looking at needing a DSP rather than a CPU. Task 1 has
to "do a bit with the numbers" at 60kHz which is also known as having
16 uS to "do a bit" with each number you collect. You may be able to
get this done, but many CPUs will struggle at this rate depending on
what "do a bit" constitutes.
You might want to download some tools for an ARM or pretty much any CPU
that you can get free tools for and try writing your core code to see
how many instructions it ends up being to get an idea of the processing
time. I can't say I have seen a simulator for an ARM but that would
give you a real cycle count. Or you can get a $50 eval board to run
your code. Then you can make some informed estimates of what your "do
a bit" requires from the CPU and whether you need a DSP or not.
Item 4 might be best done with USB. I don't know that USB qualifies as
"simple", but I don't think you will find SCSI to be simple either.
Many MCUs these days have USB ports built in. The hard part is getting
the software, but I expect this is available from various sources. Is
your need 800 kB or 800 kb per second? 800 kBytes/sec may be pushing
USB full speed and USB high speed is not so common on MCUs. I think
there may be one of the new ARM9 CPUs that includes USB high speed.
Try Philips and Atmel.
I almost forgot. Philips concentrates on making the CPU fast while
Atmel has provided DMA for the peripherals to facilitate the IO. I
can't say which one is more important in your app, but the DMA may be
very handy for doing IO on blocks of data if that works for you.
.
- Follow-Ups:
- Re: Wich 16-bit MCU?
- From: Steve at fivetrees
- Re: Wich 16-bit MCU?
- References:
- Wich 16-bit MCU?
- From: Robert Latest
- Wich 16-bit MCU?
- Prev by Date: Re: Wich 16-bit MCU?
- Next by Date: Re: Wich 16-bit MCU?
- Previous by thread: Re: Wich 16-bit MCU?
- Next by thread: Re: Wich 16-bit MCU?
- Index(es):
Relevant Pages
|
