PIC or AVR - which religion is better?

[hilgert]

I have spent the past several days researching PIC and AVR technologies, and as would be expected there is no clear-cut choice. Mostly this seems to be a "whatever you learned on or are comfortable with" issue, along with "use the best tool for the job." However, I have observed a few differences that do seem relevant, and I would like some opinions. I am not looking for the "give me PIC or give me death" opinions; rather, I'd like a more balanced set of opinions and thoughts. Certainly there is a place for both technologies, but if an experienced person HAD to start all over and pick ONE, which would it be and why?

PIC assembly programming, from what I can tell, is a bit less obvious than AVR (but it's been *years* since I have done any assembly - years and years - and years). Also, the PIC seems to have a data bank issue that seems like it could be irritating at times on all but the newest units, but then the PICs have been around for awhile and that would be expected (ie - some historical artifacts of older, mature designs are still hanging around - not necessarily bad, as it does indicate a stable platform).
The PICs seem to run slower per clock cycle than the AVRs. Many posts on various threads/forums/sites seem to indicate that one PIC instruction takes four clock cycles, so 8MHz is really 2MIPs, etc. AVRs seem to run one instruction per clock cycle (or so).
From looking at the C code, the AVR projects seem a bit more readable, but no enough to make a difference to me at this point (having used neither).
PICs have a ton of chips available, and have been around for years. AVR is much newer, and they seemed to go through a period of time years ago where they blew through a lot of chips and designs, leaving some people in the dust (only seen a few references to this, however). At this point AVR *seems* "caught up" to PIC.
PICs have WAY more support in terms of knowledgeable users, but there also seems to be more PIC-to-AVR converts than AVR-to-PIC converts (actually, I have not yet come across an AVR-to-PIC convert - are there any?). Many "go both ways" as they see fit.
The PIC tools seem to cost more than the equivalent AVR tools. In C, for example, the C compliler is the open-source C comiler adapted for AVR. And, there is a cool simulator for AVR (VMLAB) that is free; I have seen nothing that gets close to that in MPLAB (unless I am missing something?). To me tool cost is not an obsticle (within reason). If I have to spend a few bucks on CCS C for PIC programming that's fine with me.
So, any thoughts on this? I have reviewed the forums and I know this question has been addressed before, but technology does change rapidly. I am sure this will be an *easy* choice, right? :D

"Looking for microcontroller religion..."

-Hilgert-

[Mr.RC-CAM]

PIC assembly, from what I can tell, is a bit less obvious than AVR... I agree. I was raised on Intel and Motorola. When I went to PIC's (>10 years ago), everything looked greek to me.

Also, the PIC seems to have a data bank issue that seems like it could be irritating at timesIt is somewhat of a burden. It is the fallout of having only a 12-bit or 14-bit architecture. If you are using a high level language compiler then the paging is done for you by the compiler.

The PICs seem to run slower per clock cycle than the AVRs.It is true. But, what are you designing? Does your app need the higher MIPS. I doubt it.

From looking at the C code, the AVR projects seem a bit more readable, but no enough to make a difference to me at this point (having used neither).C code's readability is up to the person who wrote the code. It's all style. And, if you really want to open up a firestorm, try to claim that BSD/Allman indent style is better than K&R, or Wordsmith's, or whatever. Of course K&R is best. :)

PICs have a ton of chips available, and have been around for years. They sure do. The list is very extensive. AVR has plenty too, just not as many flavors. For commercial design situations, the variety is crucial. For hobby apps, I think this more vs. less choice thing is of no concern at all.

PICs have WAY more support in terms of knowledgeable users, but there also seems to be more PIC-to-AVR converts than AVR-to-PIC converts.This a result of Microchips generous sampling policy and introduction of truly low cost development tools. They started this effort a decade ago. Nowadays the landscape is decently leveled by all the MCU makers. Now nearly all have cheap development kits and strong user-to-user support. As far as AVR's go, there are good support groups, so there is no real advantage vs. the PIC camp.

The PIC tools seem to cost more than the equivalent AVR tools. In C, for example, the C compiler is the open-source C compiler adapted for AVR. And, there is a cool simulator for AVR (VMLAB) that is free; I have seen nothing that gets close to that in MPLAB (unless I am missing something?). The free GCC WinAVR compiler is definitely a good deal. As far as simulators go, I stopped using them years ago. It is far easier {for me} to just use real hardware. I do respect that many folks love simulators and so my opinion is just one of many.


I'll throw in a wrench into the fray. Have you looked at the Cypress PSOC? Their MCU's have some very cool analog features that would be ideal for many hobby projects. And TI's MSP430 series has just started to really kick Azz. Their $20 demo dongle includes a decent IDE and C compiler. FWIW, I just went to a MSP430 class and was very impressed with the feature set.

In the end, none of this matters. All the major chip makers offer good tools and decent product features. If your choice is between PIC and AVR, then there is really no risk in either direction. So pick one. Just don't become one of those fellows that claims that their CPU family is the best and the other sux. Those claims are just so 1999.

[Comatose]

I'm polytheistic in this matter. We actively develop and sell products based on both families. Our general guideline is PICs on the low end, especially the PIC12f6XX families, and AVRs on the higher end, especially the Mega48/88/168 line. But thats just a function of the feature sets and price points that exist right now. Here are a few thoughts on both, and microcontroller development in general.

Absolutely, positively, don't use any more assembler than necessary. In 99% of all projects, that would mean "none." if you're not working with the assembler, you care significantly less about the particular microarchetecture. Developing in assembler is the best way imaginable to get yourself wedded to a family and unable to move if the tide shifts.

No, you actually can't code it to run faster in assembler. Modern optimizing compilers are very good, and processor power is extremely cheap these days. Really fast assembler code tends to be unreadable and unmaintainable.

The specifics of any architecture are less important than having good microcontroller programming fundamentals and getting the most out of your hardware. For example, interrupts are your friends. They're also pretty universal to microcontrollers. Gaining skill in using interrupts efficiently is much more valuable than becoming the best at efficient bank switching, because you can take interrupts with you when you switch families.

I agree with Mr. RC-CAM that simulators are of limited value, especially as both PIC and AVR have in-circuit debugging tools that aren't all that expensive. Unless you're doing very number-crunching heavy work, its easier to work with real hardware.


With PIC assuming a PWM , a UART and an ADC, all between 12 and 20 IO you'd have:
One part with ADC and UART but not PWM (pic16f688),
One with ADC and PWM but no UART (PIC16f684)
One with PWM and UART but no ADC (pic16F628A)
One with ADC but no UART or PWM (pic16f676)
one with ADC, UART and PWM (pic16f690)

That doesn't even get into more permutations if you throw in more options like an SPI port and varying amounts of program space. All the above PICs are between $1 and $1.60 in quantity hundreds.

AVR is easier to keep track of. There are a handful of chip families, all of which have all the options. There are versions with larger and smaller amounts of RAM, but not the thousands of devices to churn through looking for the one with exactly what you need. The AVR might cost a few cents more than the most stripped-down PIC, but it'll be less than the one with all options. Neither of these are necessarily a "pro or con" but the perception that "There are a lot more PICs" has a lot more to do with Microchip's approach to make every permutation of every feature set than an indication that you can do more with PICs. Unusual stuff like op amps and shunt regulators aside.



PIC:

Pros:
Great development support. Free sample policy is wonderful as a student/hobbyist.

Good feature sets on very small parts. The small pin count pics are just easier to work with than the attinys.
Lots of useful and semi-useful hardware bits.
Good ultra-low power features.
Chips with unusual levels of integration. For example, pic16hv785 has two op amps multiplexed with input pins and a built in shunt regulator. that saves two external chips.

There are inexpensive pics with very fast ADCs

Cons:

One register. This is far and away the biggest weakness of the PIC design. It makes for much larger code, and has really horrible effects on interrupt latency and function passing.

4 cycles/clock limits even the fastest pics to 10 mips. The cheapest AVRs run at 10 mips, and most run at 16 or 20 mips.

The high pin count/functionality chips are just too expensive for what you get, IMHO.

The hardware peripherals on PIC tends to be a little bit more limited. For example, many PICs have one bank of external pin-change interrupts, so four or so pins. AVRs have every pin as a possible pin-change interrupt. Pullups are the same way.


AVR:

Pros:
Lots of registers. Enough even that you can dedicate some to only certain functions and values (and tell the compiler not to use them.) This can make interrupt processing 10x faster on a ATMEGA than a PIC18F, both assuming a C compiler.

More (and cheaper) chips have a hardware multiply.

Prices used to be better than PICs, but microchip is quickly catching up in this regard. I think microchip recently retooled their fab.

The pin functions are more complete. If you decide halfway through that a pullup on a pin would help, its already built into the chip.

One cycle per clock. Thats especially useful when you're running off an internal oscillator.

Programmers are cheap.

Free C compiler can be handy if you're cash-strapped.

Cons:

The smallest AVRs IMHO aren't as compelling as the small PICs for most hobby-related tasks.

Availiability is sometimes a problem. Free samples are nonexistant.

Less development support. AVRfreaks.com is sometimes useful, though.

The inexpensive programming hardware like AVRISP can be flaky.


If I had to pick just one, I'd probably pick AVR. But if you develop everything in C and really get into the right mindset for microcontroller development, switching families later isn't a big deal.

[Unterhausen]

what about the texas instrument mps430? Much lower energy consumption.

[hilgert]

Comatose, that's probably the best, most balanced comparison I have seen anywhere on the web (and I've done a lot of lookin' over the past few days).

Thanks,

-Hilgert-

[meteor]

If you are looking for both programming and interfacing tutorials, you simply cannot beat PIC chips.

The amount of support for PIC on the 'web is staggering, and a lot of it assumes you know pretty much zero, rather than jumping right in at far too high a level.


Personally, for hobby/robot uses I use the PIC 16F87x series and the JAL language, which is a bit like Pascal, and free!

This is a great tutorial series: http://members.home.nl/b.vandam/lonely/index.html


There are a lot of others, but that's good starting point.


Good luck!

[xorcise]

And then there is USB....there PIC's are changing the scenery of the PC to microcontroller interface with an internal USB hardware module and 1K byte buffer in about 6 different 18F's capable of runnng 12 MIPS.

dsPIC's are capable of 30 MIPS but not USB.... :mad:

[jeffs555]

The others have given very good comparisons. I probably have a different perspective since I program mostly in assembly language, and my applications tend to push the speed limit. For support purposes, I know it would be better to do only the speed critical routines in assembler, but I am too old to change. I learned assembly language before "C" was even invented and can do assembler in my sleep, where I have to think harder when using "C".

Anyway, the main problem I have with the PIC is its single accumulator architecture. Comatose has already mentioned how this can make for larger code size and more latency for interrupts. You usually spend a lot of time and code space swapping values into and out of the accumulator. Even when the MIPS are the same, the AVR will out perform the PIC in most speed critical applications. For low volume, non speed critical applications in a higher level language, this is probably not even a consideration, but for me it is a killer. The multiple register micros like the AVR and MPS430 make for a lot faster and smaller code. I also use the Cypress PSOC which has a single accumulator, and it is much harder to write tight code for it than it is for the AVR. The only reason I use the PSOC is because of its highly configurable analog and digital blocks which can do a lot of things that would require external hardware with other processors.

[JimDrew]

I have been an assembly language programmer for more than 30 years, coming the MOS technology days and using virtually every CPU ever made up through the PPC G4s. I like the PIC chips because they are simple and effective. I recommend using only assembly language with micros, and these are the best for those that want to learn assembly. One register (w) is an advantage to someone starting out. Realistically, nobody is porting their microcontroller code from one brand CPU to another, so the argument of using 'C' for portability really doesn't hold any water. ALL of the newer PICs have the ability to have individual port pull-ups and pin change ints. The 18 series families extend the instruction set and add speed. There are also DSP specific type versions of the family available. The selection to fit your application is huge, and you will likely find something that you can taylor to your exact design needs, and if you should need to expand to a larger memory CPU (say like a 2K to a 4K version), you can always get one. Being able to buy directly from Microchip in volume is a HUGE plus if you are a developer. We have purchased more than 1 million PICs from Microchip, and cutting out the middle-man, even if it was just a few cents difference (and it's not - it's usually 25%) means a substantial savings. You can also call up the guys at Microchip or go to their direct developer support online and get information immediately about a design question. These guys go out of their way to help you figure out problems, determine the best PIC to use for your application, and even help design basic glue logic for interfacing their parts. Atmel's support is not as good, and I got the run around the few times that I did use their micros... which is what lead me to the PICs.

If you are blinking LED's and making piezos play tones, virtually any micro is going to work for you. With the PIC family, you have numerous choices to help reduce design costs. If you need blistering speed, then either use the latest high-end PICs (which are expensive), or use the Atmel parts which are a better bargain.

[hilgert]

Realistically, nobody is porting their microcontroller code from one brand CPU to another, so the argument of using 'C' for portability really doesn't hold any water.
Actually, I have found the opposite to be true when reviewing posts from the PIC-to-AVR converts. Not totally clean ports to be sure, but not total re-writes either. And, many seem to write in C and go back-and-forth between PIC and AVR, sharing common rourtines between the two, etc.

I would think there would be more in common between C on an PIC and C on an AVR then there would be between assembly on each (having done neither this is just an assumption on my part).

[tomp]

AVR: http://www.avrfreaks.net/
PIC: http://www.piclist.org/techref/piclist/index.htm

I haven't used an AVR (yet). I'm presently designing (for work) with an rfPIC12F675. Nice part, but we're too cheap to spring for a C compiler, so I'm strictly assembler. The minimal instruction set makes you think and the lonely W register makes you think harder.

I totally agree with the comments made by Mr.RC-CAM & Comatose and echo that the MPS430 could be a very attractive micro (both for work and my hobbies). I'd also like to try a project using one of the ARM7-based chips (Philips LPC2xxx series, et. al)

When picking a new micro to work with, don't underestimate the value of good tools.

tom

[westfw]

Note that many of the commercial C/Basic/etc compilers for PIC (and probably for AVR as well)
have free-to-use versions that are limited only in the amount of code that they can produce.
For hobby projects on small PICs, you might not need to shell out any $$$.

Beware spec-sheet values; PICs and AVRs have been used to direct-drive actuators
and such; they have 20mA+ drive current. ARMs and MSP430s and some motorola
chips have much lower drive currents. (I recall seeing one chip where the "high power
LED direct drive output" was only 5mA.

See also
http://www.eet.com/news/semi/showArticle.jhtml;?articleID=191800862

[hilgert]

See also
http://www.eet.com/news/semi/showArticle.jhtml;?articleID=191800862
Eesh - THAT makes one think a bit. I was just about to order a Butterfly evaluation kit too. Seems like they have a cool set of technologies run by a couple of ENRON-type executives...

[Mr.RC-CAM]

The AVR Butterfly is a nice board to help teach embedded C. It will expose you to a sophisticated callback OS system, low power techniques, PWM sound generation, LCD handling, interrupts and more. All for only $20.

Ignore the scandal for now. They are not going anywhere and you'll get plenty of support from sources like AVRfreaks.

[Cheesehead]

The AVR has a C assembler for free under linux.

I like linux.

That said, if I really need some serious CPU power, I'd just use a Gumstix or the like instead.

[Unterhausen]

I'd really like to stick with ARMs. I don't know if it's really practical. Some of the ones that Analog Devices makes look really nice.

[jeffs555]

I had looked before at the Atmel and Philips ARM7 microcontrollers, but didn't even know that Analog made one. It seems to be a very attractive part, especially with the high performance ADC and DAC.

If you need a lot of number crunching, the ARM7's are very attractive. I just looked on Digikey, and you can get the Philips LPC2101 in a 48 pin package for a single piece price of $3.15. That is a 32 bit 70mhz ARM7 with 8k flash and 2k RAM, at a price lower than many PIC's.

http://www.standardics.philips.com/products/lpc2000/pdf/lpc2101.lpc2102.lpc2103.pdf

PS The GCC compiler has active support for ARM7, so you have a free open source compiler for them also. http://gnuarm.org/resources.html

[westfw]

I'd really like to stick with ARMs. I don't know if it's really practical.

The nice thing about a $3 PIC or AVR is that you get a usable THING for
about $3. I've seen a lot of people advertise cheap ($3) ARM chips, but by the
time you add the dual voltage regulators and the professionally made PCB
needed to deal with the LQFP packaging, you're looking at a $40 module instead.
Sigh. Luminarymicro put an ARM in a 28pin SOIC that had some promise of
being hobbyist friendly, but it was rather slow and their developement systems
were outrageously priced (they've apparently recently been reducted in price
to "only" $250. Wow.)

If you're leaning toward ARM, AVR will probably win out over PIC. Like someone
else said, the PICs seem to win at the low end, whereas the AVRs look better at
the high end (large memory PICs post-dating atMEGA AVRs, while many of the
low end AVRs look like none-too-subtle copies of existing PICs.

The AVR Butterfly is an incredibly good value as a development system...

[jeffs555]

I agree that if you are only used to using DIP parts, or if you only do quick one of breadboarded projects, then the ARM7's are going to cost a bit more and take more effort. However, a lot of people on this forum are doing PCB's using Eagle, with fab by SparkFun or Olimex or other inexpensive board houses, so ARM7's are worth investigating if you need the processing power. Sparkfun has a $29.95 LPC2103 board with onboard clock and regulators, and all the I/O pins brought out to headers. Add their $19.95 JTAG cable, and you have a cheap way to investigate the ARM7's.

http://www.sparkfun.com/commerce/product_info.php?products_id=667#
http://www.sparkfun.com/commerce/product_info.php?products_id=275

[Unterhausen]

The ARM is definitely dominant in high end embedded stuff. I even saw an article about how it is cheaper to use an ARM than an AVR in a lot of applications. But for sheer I/O flexibility, it's hard to beat an AVR/PIC/MSP. For what I do, the MSP is probably my choice. Performance and low power is hard to beat. Right now, if you sign up for their design contest, you can get a thumb drive sized development system. Its pretty tempting.

To me, the PIC, AVR and MSP chip families are pretty much interchangable. You can buy cheap development tools and work with any of them.

[FlyingDan]

Hi all,

Regarding the limitations in size of free PIC C compilers, the page http://simplepic.atspace.com adresses the issue of modular programming in PICs and proposes some make scripts that may be of interest.

Regards,

Dan

[Trevor_G]

I am interested in where I go when the AVR doesnt have the capacity. For most applications I expect to use the AVR for a number of years.

The ARM chip does look like the way forward. The cost of the chips looks reasonable and producing a board does not seem too difficult. The problem appears to be development software. While there are plenty of expensive looking commercial systems. There seems to be nothing in the way of freeware development systems. As I am loking for a TCP/IP stack this is even more difficult. Is there anything available ?

Alternatively, is 16/32bit chip from a single manufacturer going to be a better option for a freeware development system?

[jeffs555]

There are free ARM development tools. The open source GCC tools have been ported for ARM. WinARM is similar to the WinAVR the GCC port for AVR.
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/#winarm

There are at least two open source TCP stacks.
UIP is mainly targeted at smaller 8 and 16 bit microcontrollers, but has been used on ARM's.
http://www.sics.se/~adam/uip/

LWIP is more robust.
http://savannah.nongnu.org/projects/lwip/

[Trevor_G]

Thanks jeffs555. I knew about WinAVR but have never used it as a result I am starting from scratch with WinArm.

This would appear to make the ARM chips a logical stepup from the 8-bit environment.

[MX]

Thanks jeffs555. I knew about WinAVR but have never used it as a result I am starting from scratch with WinArm.

This would appear to make the ARM chips a logical stepup from the 8-bit environment.

I second the use of ARM chips. I've been using ARM7 for a while now and really like them. The ARM is so cheap, I'm using it many places I might have used an 8-bit chip. The Philips LPC parts have a nice mix of peripherals.

MX

[hilgert]

Does Atmel not have a 32-bit line as well? I have not researched that yet.

I have been finally working with the AVR chips. Not sure how much easier/harder the PICs would be, but with a 400% speed difference and the fact that the code works with minimal changes across almost the entire AVR 8-bit line it seems hard to pick a PIC (no pun intended) over an AVR if one was starting from total scratch (like me). The CodeVisionAVR C IDE is very simple and easy-to-use; since I have lots of Java experience the C stuff is not that hard. Looking forward to getting down onto the silicon and doing some assembly at some point.

I even programmed for one AVR (a smaller end one) and loaded on a higher-end AVR with no changes - as long as the chip has "at least" the same stuff seems to work fine. Amazing.

[Trevor_G]

Does Atmel not have a 32-bit line as well? I have not researched that yet.

Yes the Atmel AVR32 line has just been introduced the http://www.avrfreaks.net (http://www.avrfreaks.net/) website has a separate forum for this.

At present there is only one device and it is still on limited distribution (Digikey list it but they don't have any). It is also a 256 ball encapsulation making it virtually unusable to the amateur.

I did consider this before deciding on the ARM but came to the conclusion that it would be 3->5 years before it became suitable for my use. I also have some doubts about wether it will survive that long given the entrenched position of ARM. If you look at the AVR32 forum you will see this is a common view.

[MX]

Does Atmel not have a 32-bit line as well? I have not researched that yet....

Atmel has the AT91 series which is based on the ARM7 and ARM9 cores. I haven't tried one of those yet since they didn't have the right mix of peripherals and memory I needed at the time.

MX

[deh6]

At present there is only one device and it is still on limited distribution (Digikey list it but they don't have any). It is also a 256 ball encapsulation making it virtually unusable to the amateur.
Sometime back there was a thread on a Freescale list (HC12 as I remember) talking about diy for BG array parts. One post said that it was actually less of a problem that the TQFP parts. He used a toaster oven. They only gotcha was to be careful of vias under a ball as it could suck down the solder from the ball. I was tempted to try it, but at the moment I using the Freescale MC9S12E128 part (which appears to be quite similar in I/O features to the LPC2138 ARM).

One item not mentioned in the earlier posts is that there is a substantial amount of time invested in learning the details of any micro used. One can buy an evaluation board and get "Hello world" up quickly, but to use the part in some project takes a lot of learning & time. I've been working with this stuff for many decades and I've decided that even after a year of working with a new micro some small detail will surface that causes problem, usually stemming from documentation that is missing, logically incomplete, ambiguous, or simply incorrect, or worse some obscure problem from a mask error. It looks so easy and straightforward at the beginning.

Even moving to another part within a series seems to turn up a surprising number of small details that are different, but nevertheless can be critical.

Consequently, for r/c hobby purposes, my view is to select a part that is more than adequate for all the possible projects (therefore pick a high end part) and stick with it. Cost is secondary. A cost of $1 or $20 per unit is not a major difference when the number of projects is in the order of a dozen or so, especially when compared to the knowledge and infrastructor that must be acquired to do projects. Obviously for consumer, commercial application even a few cents can be important, but here the quantities are too small to matter.

[westfw]

talking about diy for BG array parts. One post said that it was actually less of a problem that the TQFP parts. He used a toaster oven.
Maybe, if you already have the professional multi-layer PCB. I don't think posters like
whoever said the above quite realize the huge gap between a PCB that one has to have
professionally fabricated, and one that you can make at home. (or maybe I just
imagine that that gap exists.)
I think standard BGA mounting assumes at least 4-layer boards, for instance.
Some parts might work on double-layer boards, but I think it would be pretty
hopeless without plated through holes.

[Trevor_G]

Sometime back there was a thread on a Freescale list (HC12 as I remember) talking about diy for BG array parts. One post said that it was actually less of a problem that the TQFP parts.


My point is that it is that the AT32AP7000 is 256 CABGA i.e. 16x16 rows on a 1mm matrix. This requires a multilayer board (4+) with solder mask and plated thru holes for the vias.:eek: I doubt if many amateurs have the equipment to tackle this.

On the other hand the device that I am now looking at the AT91SAM7X128 (ARM chip) is 100 LQFP and from experience I know that this will be straight forward.

One item not mentioned in the earlier posts is that there is a substantial amount of time invested in learning the details of any micro used.


A very good point. Indeed it is another reason for choosing the ARM chip which will undoubtedly be around for along time. The multivendor aspect means that even changing manufacturer should not be to painful.

[arocholl]

Even moving to another part within a series seems to turn up a surprising number of small details that are different, but nevertheless can be critical.

Consequently, for r/c hobby purposes, my view is to select a part that is more than adequate for all the possible projects (therefore pick a high end part) and stick with it.

From a hobby perspective, I fully agree with this. All the MCU products, all the MCU the families, and sometimes even between models in the same family, have enough tricks that are apparent only when you start using the MCU at max speed, or in a noisy environment, or with low power consumption, or... or... All this takes a lot of hours to master. That is very different than flashing leds or doing a bitbang RS232 link with your PC.
If you do care about getting things done and not in the started-but-never-ended approach, you will get a lot of more productivity if you concentrate in a vendor, and from that vendor select only a subset from the low-mid-high range of products so you master them. When you get the real knowledge of the product, you will not need to move to another product to get it done, just use all the caveats you already know to workaround any limitation of the product. In other words all the products have bugs, limitations, undocumented behavior that will you take precious time. If you move from one product to another as soon as you find a limitation, you will not master any of them.

If you are a professional or have all the time to dedicate to this, then it is worthwhile (and a lot of fun) to try to master them all.

[flieslikeabeagle]

I found a link to an interesting product today: the Make magazine microcontroller kit. It's based on an "Atmel SAM7X processor, ARM7, 32-bit, 256K Flash, 64K SRAM, up to 55MHz and 48 MIPS" according to the text on the website. The ad also says application software is cross-platform (Linux is supported, which makes me happy). Can be programmed in several languages, from Java to C++, and can run FreeRTOS operating system to simplify interrupt handling, etc.

The price is $149 for the kit, which includes a small plug-in carrier board for the microcontroller, and a heftier application board with high-current outputs, etc. I'm not sure what the cost of individual parts are. Details here: http://makezine.com/controller/

-Flieslikeabeagle

[Arthur P.]

I am completely new to the microcontroler field although I did start building microcomputers from single chips in 1979, and have programmed in assembly, Basic, C, and Pascal. I-m looking for a microcontroler with significant number crunching capacity, sufficient memory, and sufficient interfaces (AD conversion, I2C, serial, and possibly up to 8 servo output channels). Intent is to use the controler for interfacing with anywhere from 3 to 8 speed controlers (yes, a multicopter), 3 gyros, 3 axis linear axceleration sensor, air pressure sensor, magnetic compas or 3 axis magnetometer, gps module, possibly bluetooth module, and maybe some sort of proximity sensors. Although two current quadrocopter projects use either ATmel or PIC processors and seem to do fine, I found at least one research paper which considered even the AVR Atmel128 underpowered for accurately working out the permutations of control input, sensor input, and GPS data for accurate positional determination and navigation. Looking at wat alternatives there are for reasonable prices I came accross these three implementations of the ARM microcontrolers:

http://www.futurlec.com/ARM7024_Controller.shtml
http://www.futurlec.com/ARM2103_Controller.shtml
http://www.futurlec.com/ET-ARM_Stamp.shtml

Anybody have any experience with these?
Would they be useable as avionics controler in a VTOL aircraft to allow GPS + sensor controled position hold and possibly in future expanstion to UAV capabilities ?
If so, which would be the best combination of price / cabalities?
Are the prices reasonable?

[jeffs555]

The ARM7 based microcontrollers will give you a lot more number crunching capability for not that much more money than PIC's and AVR's. They can even be cheaper than some of the high end AVR's and PIC's. If you are designing your own PCB, they do take more care than the 8 bit processors because they generally have higher clock speeds generated by an internal phase lock loop.

If this is a "one of" or a proto, the prices on those boards are extremely reasonable. I think the Philips LPC parts have been around the longest and have the most hobbyist support on the web. For $25, you can hardly go wrong. Just order one, download the winArm tools(http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/#winarm) and give it a try.

PS You might also look at http://www.olimex.com/dev/index.html They have a lot of ARM proto boards in the same price range.

[deh6]

significant number crunching capacity, sufficient memory, and sufficient interfaces I like the Freescale HCS12E128 processor. 12 pins with input/output capture, 2 DACs, 16 10bit ADCs, 6 PWMs, and good math instructions (16x16 multiply, and 32/16 divide, and MAC with auto index that really speeds up filters). About $10. Now that one can get a few directly from Freescale it overcomes those minimum one tray minimum quantities. I use gnu C with some asm routines for I/O. It does require a "pod" for the BDM (I use a Future Electronics HSC12 BADGE; free with the $50 seminar some years ago). AVR seems to be more popular with the hobby folk, but each time I do a comparison I come away satisfied that the 'E128 has more capability for this sort of stuff.

Repeating the earlier posts. Pick a high-end processor, so that either mid-project, or for the next/follow-in project you don't have to upgrade with all the attendant new learning, upgraded infra-structure, etc.

[AndyKunz]

Per Jeff's comments, he's got some good answers there. I am using the Atmel ARM7 (AT91SAM7X series) in some commercial equipment and it is very good. The WinARM tools are good (I'm using GCC under CygWin myself, same codegen) and the non-Atmel support folks are great. We were burned pretty badly by them with the 512K parts and will probably end up running the thing on a PIC, but technically I really like the SAM7X.

I am actually working on a multi-copter control board right now that will hopefully be available in a couple months. I think the project will end up being open source as well, so it might be worth the wait if you aren't needing something yesterday.

Andy

[Arthur P.]

Also also posted in the Quadrocopter thread in the Aerial Photography forum (http://www.rcgroups.com/forums/showthread.php?t=685547&page=13):

I have used my time waiting for the UAVP kits to do a lot of reading, including some thesis papers on quadrocopters and GPS integration. Some of those are very clear: the AVR128 and PIC clas 8-16 bit processors are stretched to the limit with keeping these aicraft stable and just tracking GPS. For full GPS integration a microprocessor with more oomph is needed. So I-ve decided to "roll my own" and have ordered these:

ARM7 processor header board: http://www.futurlec.com/ET-ARM_Stamp.shtml USD 24.90.

Alternative could of course be this one: http://www.futurlec.com/ARM7024_Controller.shtml USD 44.90. Note that it only has one RS232 interface.

Eventually I-ll migrate to this one for the heavy GPS integration with also flightdata logging: http://www.sparkfun.com/commerce/pr...products_id=267 USD 93.95.

As gyros I-m going to try these as they also have an I2C interface:
http://www.sparkfun.com/commerce/pr...roducts_id=8372 USD 59.95. (I actually ordered them without header boards as those were out of stock and not expected in until August, but surprisingly there are now 11 in stock).

Accelerometer MMA7260Q: http://www.sparkfun.com/commerce/pr...products_id=252 USD 39.95.

Compass HMC6352: http://www.sparkfun.com/commerce/pr...roducts_id=7915 USD 59.95.

I-m also planning to test the 3axis magento: http://www.sparkfun.com/commerce/pr...products_id=244 USD 59.95.

I-ve ordered the SCD1000 air pressure sensor: http://www.sparkfun.com/commerce/pr...roducts_id=8161 USD 54.95

However this HP03D might have been a cheaper alternative and with I2C as well: http://www.futurlec.com/Pressure_Sensors.shtml USD 9.90.

For the GPS: http://www.sparkfun.com/commerce/pr...roducts_id=8266 USD 99.95, which is a bit pricey but it has a 5Hz update rate and 3.3 meter accuracy.

As "bling-bling" extra I-ve added a nice little colour LCD screen: http://www.sparkfun.com/commerce/pr...products_id=569 and http://www.sparkfun.com/commerce/pr...products_id=600

And finally for some sound (and considering the Tune of "Close encounters of the 3rd kind" as an option ?;=)): http://www.futurlec.com/Mini_Audio.shtml USD 5.90.

As an alternative for in flight data logging this seems like a cool options but I have held off on that for now as both processor boards will have enough memory to start with: http://www.sparkfun.com/commerce/pr...products_id=752 USD 59.95.

There are at least two other guys going down the ARM7 road, and assuming most of the software will be open source this might be an alternative to monitor:
http://forum.xufo.net/bb/viewtopic.php?t=6031 and
http://www.ulrichradig.de/home/inde...kte/mikrokopter

All three of us seem to be going down the "let's use available off the shelf components" road, moving away from these highly proprietary flight controlers with variable availability.

I-ve ordered some other bits and pieces from 2 other suppliers, one in Canada (e.g. sockets for the gyros), and one in Germany (EPP1045 props, motors, YGE30 ESCs).

So far all these 4 suppliers have indicated within 2-6 hours of receiving the order that they had filled and mailed it. So I should be getting the four packages either tomorrow or sometime coming week.

Weekend isn't expected to be too good, so I hope to be able to start writing the software based on the technical documents for the different parts.

It's going to be interesting to see how long this is going to take me. When I started building computers in 1978/1979 from single chips, without the benefit of Internet and prefab breakout boards, it took me about 3 months to get a PC cobbled together, write the BIOS and an 8K Basic interpreter in assembly, and get the whole thing to put out a couple of lines of text on a BW tele. Shouldn't take that long for this project ;=))

[Arthur P.]

Development of an ARM7 avionics based Quadrocopter AP platform (Q4Arm7)

I-ve just started a thread on the above in the Aerial Photography Forum here: http://www.rcgroups.com/forums/showthread.php?t=706878#post7719491. Reason to post it in that forum is the currently still limited interest in this flying craft and the fact that the main intent for it is RC Aerial Photography / Video. However, as it is also a VTOL, involves significant Electronics development, and will also certainly evolve some UAV characteristics for specific types of AP, I'm cross-linking from here.

[XJet]

Arthur, we've got a UAV controller here that I've built around a PIC 18F4550 with an internal clock rate of 48MHz.

It handles GPS guidance (5Hz update), attitude stabilization, barometric altitude processing, servo interfacing, and a bit of telemetry processing -- with cycles to spare.

What's more, all the code is written in C18, I haven't even had to hand-optimize any of the code.

The PIC is quite a capable processor if you keep your floating point ops to a minumum and make very heavy use of its interrupts, timers and other nice bits of hardare.

I did make provision for an external FP unit but in the end I found that it wasn't necessary (although I could still add it if needs be later)

The best thing is that the whole processor board has a component cost of under $15.

[jeffs555]

Xjet,
There could be many good reasons for choosing a PIC 18F4550 over an ARM7, but component cost at least in the US would not be one of them. Might be different where you are, but in the US the 8-bit 48mHz PIC 18F4550 is around $11 in single piece quantities and around $6 in medium quantities. The LPC2141 is a 60mhz 32 bit ARM7 with peripheral features similar to the PIC 18F4550. Here you can get an LPC2141 in single piece for less than $7 and in medium quantities a little over $4.

Jeff

[xorcise]

jeff,

ARM packs a lot into their MCU for the price, but other than the price of hardware these processors cost an ARM & LEG (pun intended) to get a decent IDE and Debugger. Keil has some of the best development packages available for ARM but check the price tag to start serious programming/development.

I also noticed that noone has mentioned PIC24 and dsPIC30/dsPIC33. These 16-bit processors are fast and are specifically designed for complex high-level projects.
And you can get a fabulous structured IDE/ICD/Soft Debugger for $99 to $175 in Basic, Pascal, and C. MPLAB is free if one likes assembly.

[jeffs555]

It doesn't have to cost an "ARM & LEG" to get into ARM programming. One of the nice things about the ARM7 is that there are a lot of open source(ie FREE) tools available.

Here is one description of how to setup a free Compile/Debug/IDE environment http://www.yagarto.de/index.html

There is also a comercial development environment that has a $149 personal license for hobbyists. http://www.rowley.co.uk/arm/

[xorcise]

I downloaded the Yagarto files. These look interesting. I knew about Crossfire, but I needed a commercial license for my work ($1000). I have Kiel presently. Yagarto looks promising.

[jeffs555]

For the hobbyist or garage business with more time than money, the open source tools can be great. Here is another good tutorial on ARM development using open source tools. http://www.sparkfun.com/tutorial/ARM/ARM_Cross_Development_with_Eclipse.pdf

For commercial development where time is money, the open source stuff often doesn't make sense. The open source tools keep getting better, but you can sometimes spend a lot of time trying to get the tools working and dealing with bugs. The high priced commercial packages can often pay for themselves many times over in ease of installation and support.

[Arthur P.]

Arthur, we've got a UAV controller here that I've built around a PIC 18F4550 with an internal clock rate of 48MHz.

It handles GPS guidance (5Hz update), attitude stabilization, barometric altitude processing, servo interfacing, and a bit of telemetry processing -- with cycles to spare.

What's more, all the code is written in C18, I haven't even had to hand-optimize any of the code.

The PIC is quite a capable processor if you keep your floating point ops to a minumum and make very heavy use of its interrupts, timers and other nice bits of hardare.

I did make provision for an external FP unit but in the end I found that it wasn't necessary (although I could still add it if needs be later)

The best thing is that the whole processor board has a component cost of under $15.

What you aren't mentioning is the type of platform. For an inherently rather stable airplane the ammount of flight control changes needed are much more limited than for a helicopter or a quadrocopter. For a heli with good tailrotor gyro the swashplate and throttle controls need to be reasonably fast. For a quadrokopter the motor speed controls need to be very fast to stabilise it properly. Add to that the more complex vector calculations as these things do not have a front or rear end flightwise so that you are really working in 4 dimensions, you are really putting quite some strain on the processor. And then I do want to eventually get some quite complex waypoint based flight modes integrated into the system, e.g. early, gradual, or late jaw and altitude correction between waypoints and automated panorama series in position hold mode, while at the same time logging flightpath and photo datetime-stamps. I expect this to really tax even the ARM7 to its limits before I-m through. One of the reasons for going for I2C based sensors, and even I2C based servo controllers, where-ever possible. The more peripheral intelligence, the more processor time is hopefully available to handle the true co-ordination of all needed activities.

One of the things I-m also trying to get info on, is whether the 2.4GHz DSS transceviers used by Spektrum could be mated to the flight controler at the receiver end using its I2C bus, and expanded with a microcontroler at the Tx end, allowing insertion of a few additonal bytes into the digital I2C datastream and forgoing the PPM stream at both ends. That would allow e.g. inserting 3 bytes of which two could consist of 1x 2 position switch and 1x 128 step resolution sliders, and the third 2x 4 position switches and 4x 2 postion switches assuming 8 bits / channel. If each channel uses 16 bit wordlength, then of course even more additional controls could be crammed into separate bytes. That is of course assuming that the transeivers don't really care whether you throw in a small number of bytes extra.

Thinking further it would be even better if the transeivers essentially just operate as modems. In that case it might be possible to use them in setup mode to program the Q4Arm7 using e.g. a PDA as entry terminal linked to the transmitter over s simple USB port.....

Somehow I have the feeling that switching completely from PPM based front ends on both the Rx and Tx really opens up uncharted waters in channels of control and ease of configuration ;=)

[XJet]

Yes, we're only flying fixed-wing so the stability requirements are somewhat lower. We've also modularized the system as much as possible and prefer offloading much of the raw data processing (ie: barometric input, etc) to their own processors which are then hooked to the main CPU via an SPI interface.

We've been very satisfied with the Microchip IDE/compiler and ICD2 debugger support. We also like that the PIC family have a large area of compatibility which means it's easy to swap between small processors such as the 16 series and the more capable 18 series as/when required.

But hey, others may have their own preferences and PIC stuff isn't without its headaches. There are quite a few silicon errors to deal with and their documentation isn't always 100% accurate.