How to pick a micro controller?

[Krzysztof]

Hi!
It is still a matter of simplicity and the speed of the same micro-design changes.
New 8 bit machines also have clocks with prescalers and easy approach by e.g. Arduino.
Using ASM in the necessary moments, I have easy access to everything. I dont have the ADC, the internal timers pulses counted cheater 16B;
I count multiple overflows in short interrupts (INT), which extend the measurement range (less noise). Do I use floating point arithmetic.
Effective use of ARM requires a lot more work and skills (it's much more than a hobby).
Best regards Chris.

[Pete the Builder]

G'day Brucester!

Just my $0.02.. Last week I bought my first ever Arduino after 12+ years with PIC products! We're swapping over!

The only Arduino that even comes close is the Due, it uses an ARM3 at 78MHz, plus it's a 32-bit processor. It has 512k FLASH and 96k of RAM - much, much more than the PIC products I'm aware of (but I am out of date by 3-4 months - maybe they've made a breakthrough???? PLUS : it has 12-bit ADCs (10 bits if you sample at 1MHz!!) AND they've got 2x12-bit DAC channels. Just amazing. There's nothing else out there that comes close, at least not with ALL the bits in one place. You can get the same speed ADC, but bugger-all memory, or lots of memory but no DACs, stuff-all PWMs, etc, etc. You kinda know what it's like already with all the Arduinos. I think the Due is going to be a killer module. (I'm not related in any way to Arduino, BTW). Personally I can't tell you much more, I just murdered my Due a day or so ago (my fault, flying lead, too many electrons in the wrong spot = let the smoke out )

The biggest problem with bare ARM or dsPIC is the lack of libraries and software support. You're gonna hate that, I think, after Arduino community. To take advantage of the best parts of the signal processing capabilities of the Microchip and ARM, you're gonna have to fork out a LOT of money. In the case of the ARM, count on around AUD$2k-5k, depending on the libraries you need to buy. You can get demo versions of the compilers (C or C++ only, although there's a hugely expensive C# compiler for ARM Cortex M7), but these are pretty savagely limited.

If you're good with C or C++, you should be fine. If not, I'd seriously recommend having a look at the Due.

The next biggest problem, even with fast CPU execution, is data storage/retrieval. ARM beats the living daylights out of Microchip (PIC), no two ways about it. Lots and lots of fast flash and reasonable amounts (~512k) of fast SRAM. The dsPIC range are optimised for small bursts of medium-resolution data needing massive manipulation. That limits your buffering abilities. Even having huge gobs of flash won't help - by the time you've completed a single row flash write (which has to be coded in assembler), you've just missed the next dozen pulses' worth of data from your front end!

I believe the dsPIC handles floating point exceptionally well, that's a bonus there, whereas the ARM architecture needs to convert back and forth. Some ARM cores have dedicated floating-point pipelines, but I've never really gotten in to that side of things (until now, ha!).

I don't know enough about Atmel, except early on they had this bizarre split-data-memory thing going where you had to keep swapping data pointers to get both bytes of 16-bit data! So I gave up on them as a bad joke.

If you've tried the Due, and it's not fast enough, then your best bet is probably ARM. There are a few different architectures out there, and plenty of manufacturers, so check out Philips as well.

If you want a cheap & cheerful intro to ARM, get on over to Futurlec Electronics. They have sensationally priced ARM dev kits (like, AUD$40 for an 80MHz ARM7 with 512k/512k, plus a motherboard you can plug it into for AUD$30 extra), they're extremely reliable, and they have an Aussie outlet (I'm assuming you're a boy from Oz, my apologies if not).

Hope this is helpful and not at all confusing. Glad to clarify if it'd help.

Cheers,
Pete

P.S. None of this negates any of the other commenters, I agree with most of them wholeheartedly, especially about the PIC toolchain. I just had a hard time getting up to speed with the dsPIC line, probably due to my crappy maths. And I kept running out of memory, especially with big matrices. Again, that might've been just me...
P.P.S. MikroElectronica in Europe has some brilliant dev boards for the dsPIC (and older PICs, too), plus they offer C, BASIC, and PASCAL compilers for all the chips. So that might be a good choice for jumping into the PIC pool! (Sorry for mentioning pascal, I'm a pascal programmer since 1981!)

[brucester]

Cheers Pete,

I actually considered the DUE but decided against arduino altogether. If i had of got something working with UNO, i would have ended up buying empty ATMEL chips and doing away with the arduino overhead in the end. Its better to program the chips natively because arduino slows reads and writes down by factors of 50 and 100 in some cases.

I was actually a programmer by trade, majored in comp sci but have never work with electronics and uCs, just boring desktops and servers and workstations.

Thanks for the tips and i wont rule out ARM. I will check out futurlec. Cheers

[ODM]

Various architectures can seem bass ackward at first glance after years of experience with another architecture, of course.

The choice, in practice, boils down to having enough processing power and the support, in compilers and experienced people, to make use of it.

In my personal opinion, Arduinos are doing a bit more harm than good to AVR mcus - the slap-on "language" which mostly comprises of C defines and macros, and the generally over-universal resource wasting libraries available for it, together with the programming practices of fan projects which get transferred into other projects through the social network - tend to give a poor show of the core's abilities. The on-chip programmer on the duino boards is ok, but not a low enough fraction of the official USB-ISP's cost. And the poor choice of on and off .1" raster for the pins makes slapping on a standard protoboard slightly awkward.

With people generally doing a fair bit of soldering for a metal detector project and the actual mcu's cost a small fraction of a project's expenses, there's not really a point in using an arduino.

[joop]

Cheers Pete,

I actually considered the DUE but decided against arduino altogether. If i had of got something working with UNO, i would have ended up buying empty ATMEL chips and doing away with the arduino overhead in the end. Its better to program the chips natively because arduino slows reads and writes down by factors of 50 and 100 in some cases.

Check out this thread: http://www.geotech1.com/forums/showt...ted-to-arduino

[brucester]

Thanks Joop.

That is some interesting code. I played with arduino, found it useful as a timer for pulsing the coil and outputing audio but not much else. Although, i am trying to use the analog comparator to measure decay time to make a simple pi without ADC processing.

[target]

i have a sneaking suspicion that the Deus using a PIC 32 chip in the control box, but cant be sure as the ID of the chips has been ground off to keep it secret !!

[Pete the Builder]

From what I've seen, watching the development of the Harvard architecture MCUs by Microchip and Atmel (arguably the two biggest players now), the drive has been to maintain a compiler-friendly instruction set - for C compilers, of course! The upside is that adding in new features means minimal compiler rewrites, whereas for anyone coding "bare metal" (which is how I cut my teeth decades ago) it gets more and more tedious to have so many deprecated methods every few dozen chip revisions, etc.

But it's still the most fun you can have with your clothes on, I think!

I developed for ~24 years in Turbo Pascal (CP/M, early MS-DOS), then Delphi, until it got almost as expensive to buy Delphi as it cost for Altium Designer. Then I stayed with what worked, and damn the new features! I do wish I'd learned C earlier, though...