Microcontroller recommendations

[joellark]

I'm in the planning stages for a 3D inertial sensor system. The system I'm creating is going to be custom, and I'll be using 3 analog devices gyros, 3 analog devices accelerometers, and possibly a three-axis magnetometer (recommendations welcome). I plan on having compact flash, 1 serial port, one usb port, bluetooth, a graphic LCD, and an unscented (square root implementation) kalman filter to fuse the sensor data. The update rate for this IMU will be about 100Hz. So, with all these things, what would you recommend as a suitable microcontroller to center my design around? I am familiar with the 8-bit PIC controllers (pic18's), if that helps any.

Thanks, in advance.

[hugo_vincent]

I'd suggest you choose a micro with floating-point hardware. There aren't a whole lot of easy-to-use micros on the market with hardware floating point, maybe you can look at the Philips LPC3180 (ARM9), or the Motorola/Freescale MPC555 (PowerPC). The UKF will be quite CPU-hungry, and if you use a micro that has no hardware floating point, emulating floating-point in software will slow things down even further. I suspect you don't really need 100 Hz update rate (even if you're trying to stabilise something fancy like a quad-rotor). 50 Hz should be enough. But be sure to include proper analog filtering of the IMU sensor outputs before they are sampled by the ADC, or otherwise oversample and use a digital filter.

Do you want a USB host (master) or device (slave) port i.e. do you want to plug in a peripheral, or plug it into your PC (_as_ a peripheral).

Almost any micro will have serial ports (and most Bluetooth modules connect via serial). Most can drive both CompactFlash and a simple graphic LCD (although possibly slowly). (What is the LCD for anyway??).

I strongly suggest you add at least a GPS receiver and preferably a data radio (for a downlink to a ground station) to your design. If you were planning to use Bluetooth for the downlink, it almost certainly isn't suitable.

Hope this helps, and I look forward to hearing about any progess you make with your UKF!

[joellark]

Wow, what a great response hugo_vincent..

I was planning on using the usb to connect the device to the computer to get data, or to program the chip. I'm not sure if that makes the device a master or other..

Yea, 50Hz is enough.

I was planning on using the bluetooth for wireless communication, maybe I will reconsider. This INU will help operate a ground vehicle (indoors), and the vehicle won't be more than 50-60 feet from the receiver. Is bluetooth still a go, in your opinion?

The LCD was put into the spec to plan for the future. The plan was to use it as an interface to the INU (I was visualizing an iPod-looking thing that's about the size of a 2.5" hard drive enclosure). I'm still not sure the details of what would be on the LCD, but I figure I would find many uses for it, so might as well add it in.

The CompactFlash will serve various purposes.

[joellark]

Anymore suggestions?

[XJet]

Another option for the FPU operations is a co-processor such as the Micromega unit (http://www.micromegacorp.com/)

These will talk to your microcontroller through the I2C or SPI interface (so will work with the 18 series PICs you're used to) and are quite smart bits of silicon.

I'm not sure whether any of the standard PIC development tools have libraries to transparently support this chip but they wouldn't be too hard to write (I assume you're going to use a HLL such as C/C++ rather than assembler for a project of this scale).

[joellark]

I've looked into the LPC3180, and I just can't find any information on it. Where would I buy a reasonably priced board with the LPC3180 on it? I notice the LPC doesn't have that many A/D ports, and seems cumbersome to program.

Maybe I'm getting in over my head here.

[brianhomer]

Well recently i got a amazing microcontroller ARMmite. all necessary I2C, SPI, UARt,....etc only need a very simple so called ARMbasic to operate. the speed is pretty fast and it is using ARM7 core at 50MHz. even it is faster than most PIC.
However, I am suffering how to interfacing this with VC++ language (it seems does not support captioned issue yet). But try to read more from http://www.coridiumcorp.com/ProgramminHW.phtml or www.sparkfun.com
Hope this can help

[poynting]

I have used ARM7s from various vendors (philips, STmicro, Atmel) with good luck. The ones from STmicro seem to have the most peripheral options (including one version with USB client, Buffered SPI, UARTs, & I2C, 12-bit ADC, ... ), and ST has a library that will help to get you going on them, but all of the ARM7s are a lot more complicated than your average PIC to get set up and working right. It's a whole other league, and the documentation doesn't hold your hand like the PICs do, but the extra processing power is well worth it once you get things going.

You can compile code for the ARM7 for free with gcc (even on windows), or use any of a number of rather expensive dev tools from various vendors. There are a number of 'getting started' tutorials out there, but most assume some knowledge of microcontrollers, and, for the brave willing to

Sparkfun has a great deal of dev boards for various flavors of ARM7.

[hugo_vincent]

I agree with Poynting... all the ARMs (and pretty much any 32-bit processor) are more complicated than your average PIC (or AVR) for development, mostly due to the much more complex and confusing toolchain (compiler, assembler etc) options and less integrated GUI IDEs.

And of course, the LPC3180 ARM9 is much more complicated again, and as a system it probably has more in common with a PC than a PIC (i.e. it needs off-chip RAM and flash, needs a "BIOS" i.e. bootloader, probably needs a OS i.e. Linux etc.).

I can't point you to any cheap dev/eval boards for the LPC3180, but the chip itself is fairly cheap (US$11.25 @q1 at Digikey.com). (But as a system, it is much more expensive than a PIC/AVR/etc, as you also have RAM and flash chips, extra power supply regulators, a 4-6 layer PCB etc.)

Buuuuuuuttttttt... if you need more performance, particularly floating point performance, than a PIC, AVR or ARM7 can offer, then it seems like a superb option.

[lagroute]

Hello,

I'm also currently thinking on a gyro-accelero-magneto based AHRS.

AVR adc is quite slow so I'm thinking on making the AD conversion by a dedicated Analog Devices chip, then running the kalman filter on a 20Mhz AVR like ATMEGA 88 or other.

What do you think of this ?

Will the AVR have enough processing power ?

thanks ...

[joellark]

I agree with Poynting... all the ARMs (and pretty much any 32-bit processor) are more complicated than your average PIC (or AVR) for development, mostly due to the much more complex and confusing toolchain (compiler, assembler etc) options and less integrated GUI IDEs.

And of course, the LPC3180 ARM9 is much more complicated again, and as a system it probably has more in common with a PC than a PIC (i.e. it needs off-chip RAM and flash, needs a "BIOS" i.e. bootloader, probably needs a OS i.e. Linux etc.).

I can't point you to any cheap dev/eval boards for the LPC3180, but the chip itself is fairly cheap (US$11.25 @q1 at Digikey.com). (But as a system, it is much more expensive than a PIC/AVR/etc, as you also have RAM and flash chips, extra power supply regulators, a 4-6 layer PCB etc.)

Buuuuuuuttttttt... if you need more performance, particularly floating point performance, than a PIC, AVR or ARM7 can offer, then it seems like a superb option.The LPC3180 was recommended here, I don't have my heart set on it.

Do you know how much processing power I would need to run the quaternion based square root unscented kalman filter (with gyro, accel, and wheel encoders) at 50-100Hz? I'd need to do some sort of SPI to transmit the data the filter generates, maybe some graphic LCD stuff, and maybe some SD card reader/writer stuff? Would the new 16 bit PIC processor do the job? The kalman filter is the most important thing, so if I can get a simple chip that will run it at the stated speed, but would have to make my life more complicated to add in the extra features, then I'd probably just drop the extras (I need to send out the filtered data over SPI, though).

Thanks, everyone, for your suggestions.

[areilly]

I plan on having compact flash, 1 serial port, one usb port, bluetooth, a graphic LCD, and an unscented (square root implementation) kalman filter to fuse the sensor data.

Something I have been considering lately is using a PocketPC - used ones are all over ebay. You get an ARM running 200-500MHz, 32-128Mb ram, LCD, and often bluetooth and SD/CF slots. Most (maybe not some newer ones) have a port that uses a proprietary connector that is a USB and RS232 serial. the case and battery is usually most of the bulk and weight, and those can be removed. A PIC would still be needed to provide a serial interface to the sensors... The .NET comapct framework (C#) for windows mobile /CE is easy tp pick up for anyone familiar with C/C++, and the command-line compiler is free.

[ADI]

edit
Cheers ADI

[kbosak]

Something I have been considering lately is using a PocketPC - used ones are all over ebay. You get an ARM running 200-500MHz, 32-128Mb ram, LCD, and often bluetooth and SD/CF slots. Most (maybe not some newer ones) have a port that uses a proprietary connector that is a USB and RS232 serial. the case and battery is usually most of the bulk and weight, and those can be removed. A PIC would still be needed to provide a serial interface to the sensors... The .NET comapct framework (C#) for windows mobile /CE is easy tp pick up for anyone familiar with C/C++, and the command-line compiler is free.
Wrong way. This is completely non-realtime operating system plus completely non-realtime language (garbage collection kicks in in the worst moments).
You can expect task switching times between 10ms min to 200ms max and you will be battling to disable all stupid sleep-down/wake-up/display info on battery low/display-off issues. at the end only one serial port.
Try using some PC/104 say using AMD Elan 133MHz or AMD geode 400MHz with pre-installed DOS and you will arrive much faster on target. 4-8W to power it are well spent.

[octane-link]

If you want a radio link, consider Digi's XBee radios.

They are USART peripherals, and really easy to work with. Fairly cheap too ($32 for the Pro module). You will want to pro module too, over 1 mile range. The regular module is only 300 feet or so, too risky for my taste, I prefer a robust signal.

About the size of a quarter, so no problem with integration.

[zlite]

The Parallax Propeller (http://parallax.com/Default.aspx?tabid=407) is a new and inexpensive ($13) chip with 8 cores for real multitasking/multithreading. You can combine it with a floating point co-processor, or use its internal floating point software routines.

The real selling point for me is that it has built-in video circuitry so it's easy to put telemetry info into your video stream.

The new AttoPilot autopilot (http://diydrones.com/video/video/show?id=705844%3AVideo%3A9588) is based on this chip.

[kbosak]

I have the following options for central processing unit of the autopilot (it will be supplemented with several PICs and ATMEGAs):
The most advanced chips around 30USD I have found are ARM7 class LPC2148 at 60MHz, around 50MIPS (this is the price of a single board with RTC, battery backup, LDO and quartz, www.kamami.pl).

This is much stronger than ATMEGA128 (16MHz, around 14 MIPS?).

I can even run realtime operating system like eCos on LPC2148.
The problem is it lacks strong floating point unit, and a few megs of memory would be nice.

Another approach would be to use DIMM-PC from www.kontron.de that has AMD 133MHz microcontroller and DOS preinstalled (could be reflashed to Linux I guess, but installing RTOS on it might be tricky).
The problem is 3.5W Power consumption.

My best choice would be ARM9 with hardware floating point unit.
However this is very complicated setup and I may have problems putting RTOS on it. The trick is, the cheapest board I found is phyCORE-ARM9/LPC3180 Rapid Development Kit Basic (naked! no opsystem!)for 350USD, what kills me instantly. Worse, phyCORE-ARM9/LPC3180 Rapid Development Kit for Linux- $499.00
270mW power consumption is very welcome, but the price kills me.
take a look:
http://www.phytec.com/products/sbc/ARM-XScale/phyCORE-ARM9-LPC3180.html
250USD per single unit!

Gumstix Verdex XL6P looks cool with its size and MHz, almost worth its 166USD with Linux preinstalled, but it has no floating point in hardware, and the worst thing is that it goes down to -25C only, what makes it unsuitable for high altitude balloon flight (-25C is what you get in february at ground level in my country when you go to the mountains, not to mention about -50C at altitude).

[zik]

If you like the LPC2148 also take a look at the Atmel AT91SAM7 series. They have similar features and pricing. I'm using them in my "Flying Fox" autopilot.

[kbosak]

If you like the LPC2148 also take a look at the Atmel AT91SAM7 series. They have similar features and pricing. I'm using them in my "Flying Fox" autopilot.
What I like most of LPC2148 is that I have it on my table and that any next I order will be in 4 days at worst. I agree Atmel AT91SAM7 has more peripherals desired by me (PWM or something as I remember). Otherwise they are equal.

The real problem is that I am lacking serious floating point power, capable of -40C operation, in reasonnable price (i.e 100USD board full of connectors, MAX232, with big gold-pins, voltage regs, TTL buffers if necessary etc).
Adding floating point DSP to ARM7 is not very funny - I will be running RTOS on arm7 and I don't want to complicate things by using external co-processor.

[sectrix]

I've been thinking of using the Parallax micros. The Propeller (multi-core) or Javelin (Java based) caught my attention. They have development kits and OEM modules for sale as well as a large selection of other micros and educational materials. I don't know any technical details, but perhaps it may suit your purpose.

And I second the XBee. Digi seems to have a great line of radios going there. Mind you, in the US I believe you need an amateur radio license to control things over the radio.

[kbosak]

....