Wich 16-bit MCU?

I reckon an ARM7 such as the Sharp 79524 I'm using would be plenty quick enough. Don't use this one specifically as it had loads of peripherals you won't need but the Phillips LPC range should cater for your needs.

There is also a roadmap that takes you up to ARM9 and onwards if you find you want more power.

You don't say how much RAM, but a good starting system, could be the C8051F064EK from Silabs. Just ~$25, and you get Debug, 16 bit 1 MSPS ADC, 12 bit DAC, 128K RAM, and USB. The PC link sounds close to a USB, which is much smaller/cheaper than SCSI.

Or use 10/100 Ethernet, and choose the AX11015, with external ADC/DAC.

Since uC+ADC are about the same price as ADC alone these days, you could also consider a 2 chip solution : one to handle the PC link, and one to handle 'smart' ADC/DAC ?

Why would you need an 800kb/sec link when you only collect data at

200kb/sec? Are you producing extra data internaly?

On 29 Jun 2006 04:24:22 -0700, snipped-for-privacy@aol.com wrote in Msg.

The way I'm planning this at the moment is to separate the data acquisition from the transfer (I tried to convey this idea by using the wording "alternatingly"). I.e. the main loop of the program would work like this:

1. Acquire a fixed amount of data into RAM
2. Transfer data to host system
3. Receive commands from host
4. Go to 1.

There's nothing wrong with doing the data transfer synchronously with the acquisition. It's just not necessary.

robert

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.

On Thu, 29 Jun 2006 11:23:01 +0100, Tom Lucas wrote in Msg.

The LPC line indeed looks attractive bacuse there are many pre-assembled testing modules available (like the stuff offered by Olimex), and I think Linux is by now pretty well-suited as a development system.

Another question, maybe really stupid: Skimming over some of these datasheets I've noticed the absence of any externally available, "classical" address and data bus. Everything seems to be general-purpose I/O. Does that mean that I have to implement my own protocol for addressing external devices on a bus, or can the I/O pins be somehow switched into "von Neumann" mode?

I'm sure all this will be readily answered by documentation available on the 'Web. I'm looking.

Thanks, robert

There are plenty of tools for developing under linux but there is more support for windows. If you're thinking about running Linux on your target then I'd think twice. You probably don't need an OS at all but if you must then something smaller and easier - like FreeRTOS - would be better suited.

Off the top of my head I believe that usually pins are normally multi-purpose and could be GPIO if you wanted or, if part of a memory controller, defined as being address/data lines.

Yes, I have 32bit data/address and the lower 16 address bits and 8 data bits have dedicated pins. The rest are multiplexed with GPIO.

With modern devices you would not normally be working in assembler (unless you are using a very small device). However, if you like assembler (either for programming, or just to view the generate assembly), then few ISAs are nicer than the m68k. It's certainly nicer than the ARM (which is otherwise not a bad core), or the 8051 (suggested by another poster), which would be a big step backwards from the 68008.

If you can see a ColdFire development kit or evaluation kit that matches your requirements, it's probably your best bet. There are a number of nice small integrated ColdFires that should work well.

Given your m68k experience, Coldfire would be your architechture. Consider Coldfire a kind of RISC'ed m68k minus some addressing modes and instructions. Have a look at the Coldfire instruction set, and you'll recognize the mnemonics, thre A0-A7 and D0-D7 registers and much more.

Mit freundlichen Grüßen

Frank-Christian Krügel

For your application, I suggest you to take a look at "a road less traveled" -- DSP.

If you are not familiar with DSP, do not worry. A DSP is very much like a MCU with additional features helpful in processing analog signals digitally. Specifically, in addition to the usual registers, there is a special very wide (large number of bits) accumulator. The instruction set includes a "strange" one called MAC. MAC uses index to access two words from two arrays, multiply the two words, add the result to the special accumulator, and auto-increment the index. A good DSP does MAC in one CPU cycle. Other than MAC, the instruction set looks just like any MCU.

TI has a well-established line of DSPs called TMS320. It is mature and yet still growing. Analog Devices has a DSP too.

On Thu, 29 Jun 2006 13:43:17 +0100, Tom Lucas wrote in Msg.

No! I don't want any OS on the target. I was just talking about the development system.

robert

The ARM instruction set also includes MAC instructions there's even a

64bit+=32bit*32bit. Indexes can auto-inc if you want. This instruction was invaluable when I had to implement multiple FIR filters on a slowish ARM7. But alas, the ARM does not have the automatic buffer handling most DSP's have.

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

Also check out the AT91SAM7S parts. They are well supported and have some significant advantages over the LPC parts.

You can get a free, memory limited toolset from IAR or you can go to

and use the GNU tools for the ARM. provides them precompiled for Windows, Linux and MAC OS.

No, they don't typically have a memory bus option. Many of these chips only have 32 digital IOs; making a bus from them would burn all the IOs. But there are typically versions in much larger packages that provide an external bus. Go to

and click to the resources page and scroll down to the ARM Device Comparison Chart under ARM Chips. This lists a lot of features about a lot of ARM chips.

As an example, the m32c chip is split into two halves with separate Vcc for each half. One half can be GPIO or a classical CPU bus, the other half is GPIO or peripheral I/O (A/D, serial, I2C, etc)

So you can have a 3.3v CPU side with ethernet and SRAM (or SDRAM on the m32c/83), and a 5V side for peripherals and serial ports. Or you can have a bazillion 5V GPIO ports. It pretty much allows you pin-by-pin configuration of what that pin does, with some pins handling up to ten different functions.

No, stick to domestic. Those bazillian ones speak a funny language and are too good at football ;-)

Considered a Freescale S12X ?

16-bit mcu with additional 16-bit RISC co-processor designed for I/O intensive tasks. Allows interrupts to be shared between cores.

Take a look at:

There's an open source 1-wire debug interface available, costs < $10 to build, or can buy I think.

--
Steve

I'd agree with that. How clean is the input signal? If you need filtering too (and I'd bet you do), that takes cycles.

I recently did a PID loop with an H8 (3048F variant). Input signal was noisy, filtering was necessary. My CPU maxed out at under 1k loops/second, which was more than good enough for me, but a couple of orders of magnitude too little for you.

Or indeed consider the analogue PI alternative. But as Rickman says, 60kHz is a fair old whack.

Steve

On Fri, 30 Jun 2006 01:12:44 +0100, Steve at fivetrees wrote in Msg.

I want to do that on the analog side. That's where I come from, anyway.

Well, I was talking about 60kHz sampling frequency. Signal bandwidth is about 25kHz.

robert

Sample rate is what determines how much processing you need to do. You need to look at whether you can buffer a block of data and process in one big hunk, or if you have to process each incoming sample. Either way, you need an idea of what processing you need to do to be able to say a regular MCU can do it or if you need something faster. Before you can pick a processor, you need to know your processing requirements better.