I’ve been looking a lot at controllers and microprocessor families lately. I really like the ARM. It has a well-developed cross-platform (and free!) toolset (gnuarm), and the processors tend to be beefier than AVRs.
Combine those great features with Pololu’s engineering skill and style, and you’d have a real winner!
Best,
— Joe
Hey, Joe,
Thanks for the suggestion. Ben and I just went to an ST seminar today where they were pitching their ARM offerings, so we have been thinking about it.
By the way, what kind of thing do you want to do on a 32-bit MCU that you can’t do on the mega644? Is running Linux or some other big OS on your robot appealing to you?
- Jan
It’s appealing, but I don’t actually expect that. The main attraction of the ARM chips is that they seem to have a pretty good toolchain for Linux and Mac OS X. AVR chips can apparently be programmed from these environments too, but I haven’t been able to find a clear explanation of how to do it, and it appears to require that you first compile your tool chain from source. That’s a bit silly.
If you guys provided a nice clean development environment for your AVR boards for OS X, then I’d probably jump on them and never look back. But you’re hardware engineers — I figure it’s probably easier to get you to make an ARM board than to get you to package up a nice portable toolchain for your AVR ones. 
Also, in the boards I’ve been comparing (all in the sub-$50 range), the ARM chips all seem to outperform the AVR ones. But none of those use the mega644, so I really don’t know anything about that one. Beyond the toolchain, my needs are fairly modest, but 32-bit and floating-point math would sure be nice.
Best,
— Joe
I’ve also looked at ARMs, but only for a couple of projects. Here’s one I hope to be able to get to some day soon (like in the next four years, which for me really is about as close to soon as I get):
A Slocum or SPRAY glider is an autonomous underwater vehicle that can cross hundreds to thousands of miles of open ocean while using almost no power. It really is a glider in that once the buoyancy is set, it angles onto a glide path and as it sinks or rises, it moves forward. A typical setup has a glider starting a dive by taking on ballast and going into a shallow dive. Once it reaches depth it blows its tanks and starts to surface. Once it surfaces, it sits long enough to recharge the onboard batteries, pick up a GPS location, place a satellite call to dump its location, status, data from the dive, pick up any changes in task or programming, etc. Then it begins the next dive. They’ve been in use for a number of years, and are a pretty mature technology.
So here’s where someone like me comes in: I’m in a local robot club. We’ve got a number of builders who might be interested in taking a look at something deep in the ocean, say 500m down and a few hundred miles away. I don’t own a boat and couldn’t afford one. But I COULD build something that would take itself out there, collect data, come back, and tell me all about it.
An 8-bit AVR wouldn’t entirely do the job. There’s just too much going on. But they’d do a good job of managing discrete parts of the task. For example, have an 8-bit AVR handling data collection and have it put itself into a low power sleep mode as much as possible. Have another one handling vehicle control, and likewise put itself to sleep once it’s on a good glide path. Have another one handle the GPS receiver and turn it off when the glider’s underwater, sleep when it’s not active, etc. And have an ARM to handle the phone conversations when it surfaces. The ARM would spend most of its time asleep or powered off, but when the craft surfaced it would more or less drive the show.
And yeah, having Linux running on it has some appeal. Here’s why: Being able to re-flash the 8-bit processors in-situ and in operation would be a huge huge boon. I can’t count how many times this has been done to space probes, and at times that’s been the thing that saved a mission. Not to say it couldn’t be done otherwise, but with a Linux host sitting there with hard-wired cables to each of the 8-bit processors, it’s a matter of running avrdude and flashing the 8-bit. Those tools exist. It wouldn’t require developing new ones. Lots of appeal there.
Why not develop my own? Joe already mentioned something that explains why: I’m not a hardware guy. I’m not much of a software guy, either. So if I can get something off the shelf that does what I want, I’m all over it.
Tom
Hi Guys,
I know this is an old thread but I thought it’d be better to comment here than start a new one. I’m starting to see a few of these STM32 boards crop up now (Leaflabs Maple, Netduino etc.) and they are looking pretty attractive. I think this is mainly due to a fairly similar price point to the Atmels, although they do tend to be a bit more expensive, and a significant increase in speed and memory.
I’m sure that for many projects an 8-bit is more than enough but it is nice to have the capability to do path planning (extra RAM is great here), kalman filtering and more on the one MCU with plenty of overhead to spare. The extra UARTs also seem to be very handy with Pololu products like the serial servo and motor controllers, GPS, XBee and more. I can never seem to have enough anyway 
Might be something to think about again now that it seems to be gaining some ground. My concern is that a lot of the free ARM toolchains don’t seem to be as polished as something like WinAVR/AVR Studio which is quite nice on Windows. So I suppose that’s one limitation but there is certainly a lot of choice out there in terms of compilers and IDEs. I would really love to see a 32-bit MCU with similar built-in peripherals to the Orangutan SVPs.
We have committed to the STM32 family, and we should be releasing some new motor controller products soon that are based on them. We want to get very familiar with these parts before making general-purpose controller boards, but we are definitely planning on making them. I am happy to hear that you like the Orangutan SVP; is there anything in particular that you really want to see on an STM32 robot controller board?
- Jan
Thanks for the reply Jan, glad to hear you’re working on it!
As far as features go:
Those above are all pretty standard in your current controllers. One feature that would be great would be to make it easy to take advantage of your accelerometers / gyros. The placement of connectors that allow your existing sensors to be connected easily, along with accompanying libraries for usage would take a lot of the guesswork of using those kind of sensors - which can often be tricky to get right with the scaling, calibration and filtering involved. Alternatively you could even build an accelerometer and/or gyro into the board itself but there’s obviously the cost involved in that. Another option there is including headers for a device such as an XBee which could be changed out for other peripherals with a similar layout.
Ultimately I think the SVP has a great feature set which captures more or less everything you need to get a robot moving and the only real improvements I can think of are in terms of simplifying connectivity and usage of other relatively common peripherals.
Anyway if I have any bright ideas I’ll be sure to let you know. Looking forward to seeing the new products!
