A newbie exploring MCU's

[casper.bang]

After gradually finding my way back into electronics (hobby) since my teen years, I've noticed many differences; TTL levels are now down to 1.8V, SMT is now within the realm of hobbyists and not the least discrete and TTL/CMOS gate schematics are being replaced by cheap micro-controllers.

Being a software guy, I'm not so scared off by the compiler element as I am by the complete process part (are there open source compilers?, which architecture/platform?, how many times can they be reprogrammed?, which programming adaptor to use? what are the prerequisites?).

Could a kind soul perhaps guide me in some direction such as best starter kit and/or resources which could help a noob like me get a feel for this new MCU world? I don't really have any specific requirements, apart from cheap/small/easy and A/D would be nice too. I kind of like the simplicity of some of the low-pin 8bit stuff I find, such as the PIC10F204T and PIC12CE67X.

[Kremmen]

As you no doubt have noticed - or are about to - there is no one answer.  On a high level, there is the division into "high end" 32 bit MCUs, typically ARMs but there are others, and the "low end" 8 bit ones where PIC and AVR rule. You will get all kinds of recommendations - mine is AVR if only because that is what i have "standardized" for myself. Some reasons why AVR (and they may be applicable to other choices as well):
- Good free/open toolchain based on the GNU compiler collection.
- The internal architecture of AVRs is a good match to the logic of C compilers.
- Really easy to install free uncrippled IDE available from Atmel (Studio 6) covering practically all Atmel MCUs. I lose patience with the open source tools where you need to make it a separate tinkering project to get a line of source compiled and debugged. With Studio it all works out of the box as nature intended. Actually i am typing this on a laptop where i just installed Studio 6 and started compiling as quickly as the machine was able to install the package. Zero tweaking and tinkering. Big plus to Atmel.
- AVR MCUs are very well documented with proper datasheets and numerous appnotes.
- Cheap programmers and other tools are available from multiple sources.
- The AVRFreaks forum is a big help in practical questions of all kinds.

Being a software guy, I'm not exactly scared off by the compiler element as much as I find it daunting to figure out how the programming is carried out (are there open source compilers?, which architecture/platform?, how many times can they be reprogrammed?, which programming adaptor to use? what are the prerequisites?).

For AVRs:
-Studio 6 for all development tasks; source editing, build, simulate, program, debug.
-there are many adapters depending what you need. Things like Atmel's AVRISP or the open source AVRdude + parallel port let you program chips but for in-circuit debugging you need something like a JTAGICE mk II or 3, either a genuine one from Atmel, or a copy.

I don't know if there is any other chip family where you get up to speed as easily and with as easy to use toolchain. But opinions may vary.

[Bloch]

(are there open source compilers?, which architecture/platform?, how many times can they be reprogrammed?, which programming adaptor to use? what are the prerequisites?).

• There are free compilers for Microchip  (not sure about the open source compilers)
• 10000 erase/write cycles
• Pickit2 for programming

I kind of like the simplicity of some of the low-pin 8bit stuff I find, such as the PIC10F204T and PIC12CE67X.

http://www.microchip.com/pickit2 will do great for you then. Later you can upgrade to other tools.


Also take a look here http://dangerousprototypes.com/docs/PIC_12F/16F/18F_quick_start

[Paul Price]

There is a lot of people that have been playing around with the 16F876A because it relatively simple and you can download the HTC pro ver. 9.83 C-compiler for the PICC 10/12/16 series of chips. free from MIcrochip.com that does a fine job compiling. The 16F886 replaces the 16F876A and is a very close replacement that costs about half as much,  about $3.50 US. This chip has comparators, UART, 8-bit timers, 16-bit timer, two PWM outputs, 10-bit A2D with 5 A2D inputs. It is amazing what can be done with <400 bytes of RAM and 8K of program memory.

The 16F1786 is a very new chip that has a built-in 1% accurate 32MHz osc, more RAM and program space, and both 12 bit A2D and D2A converters, a built in op-amp, comparators,  8-bit timers, a 16-bit timer, PWM outputs,  UART and plenty of pins for Iinput/Output. Problem with this very new chip is that you have to purchase a PRO version of the XC8 compiler for the compiler to work well with any chip and that means $!00's of bucks.

The are many projects downloadable from the web using the 16F876A, even some good ones from YouTube.

Because this chip is available in a DIP 28 or skinny 40pin  DIP package it is very easy to just plug into a breadboard, add 5V power supply wires and a 20-MHz crystal a resistor on the reset pin and you have a working MCU.  Cheap programmers are available on the net on ebay that use USB interface. I made my own programmer that is lightening fast using the parallel port of my Windows PC and that works from DOS. I wrote the software to program this chip and a few others. I downloaded the programming guide from Microchip for the 16F886, 16F887, 16F876A, 16F1786 chips and used that info to write my own program to program chips.

You can write your source code in DOS with Edit  and then feed this to the compiler and you get a hex file out  to program the MCU

Although I use DOS tools to compose, compile and debug some of my projects, there are Windows IDE's free from Microhip and other Windows IDE's as well as many USB programmers/debuggers that some might find cheap and easy to use.

For example, Mikro-C has a compiler/IDE, 2-K program code limitationwith the free version of their compiler and free IDE, works with their USB programmer.

I monitor the operation and debug my MCU projects by using just one pin of the MCU for serial transmission and use the antique but very usable DOS QBasic programmed to display var values that are sent  to my PC for debugging and monitoring.  A subroutine in my source code transmits every var. value I am interested in using the serial port at 19200 baud at a refresh interval I select.

There are plenty of USB dirt-cheap programmers for the PICC chips on ebay: http://www.ebay.co.uk/sch/i.html?_sop=15&_sacat=0&_from=R40&_nkw=pic+programmer&LH_PrefLoc=2&_nkwusc=picc+programmer&_rdc=1

http://www.ebay.com/sch/i.html?_from=R40&_sacat=0&_nkw=pic+programmer&_nkwusc=picc+programmer&_rdc=1


The MCU's I like working with are available in 28 and 40 pin DIP packages, this means all I need is a solderless bread board to very quickly wire together some MCU idea. And this also means the same chips can be used over and over again.



The open source compilers are rather difficult to use, have limited repertoire of chips, difficult to debug your source code with.

[Dave]

Another vote for the AVR. The software is free, reliable and simple to use, programmers are dirt cheap on eBay and the AVRs themselves aren't expensive either. They offer quite a lot of bang per buck, you have lots of useful peripherals inside, extensive set of processor instructions (most of them executing in a single clock cycle) and they don't require much external circuitry. The datasheets are very well written, too.
But most of all, they are very simple and straightforward to use. As mentioned above, if you get stuck, you always have the excellent avrfreaks community there to help.

[casper.bang]

@Bloch:
Those are very clear and direct answers, making me 99% ready to press the order button for a KIT and some PIC's. Also, the quick start you refer to makes it look very digestible, my main scare now is how great the Linux support is.

@Kremmen, @Dave:
AVR (had to Google what that actually stands for) seems a little bit more niche, only because I don't know which ATtiny would match the 8bit low-pin PIC's I have my eyes on. However, the software tool chain argument weighs heavily so perhaps I need to give the AVR another look.

@Paul Price: Those PIC's sure look fun and capable, but perhaps a bit much for me to cut my teeth on. And wow, it's not often you find people referencing DOS and QBasic in this day and age; personally I miss neither one I must say.

I think I'll let people chime in a day or two on this topic, before committing to an architecture.   

PS: Interesting comparison: http://www.ladyada.net/library/picvsavr.html

[Dave]

If you want an absolutely tiny (SOT23-6) microcontroller, go for ATtiny4, 5, 9, or 10 (basically the same, slightly different specs and functionality). But bear in mind, that these four are not programmed by ISP (In-circuit Serial Programmer), but rather by TPI (Tiny Programming Interface), so not every cheapie programmer from eBay supports them. You can, however, get another programmer which supports ISP, TPI and PDI (Program and Debug Interface - this one is used for programming ATxmega chips). I have it, very satisfied with it.

Another replacement for the smaller PICs would be ATtiny13 (8-pin device), or if you need a bit more kick ATtiny25, 45 or 85 (essentially the same chips, just different flash sizes).
If you need more pins, ATtiny2313 would be appropriate.
These chips (13, 25, 45, 85 and 2313) all support ISP, so any cheap AVR programmer will do.

If you need anything bigger, you can go for the Mega family (ATmega8 is a very popular choice - you will find lots of tutorials for this chip online).

One major advantage of AVRs over PICs is that AVR offers 1 instruction cycle per clock cycle, as opposed to 1 instruction cycle for 4 clock cycles on the PIC. The AVR is essentially works 4 times faster than a PIC with the same quartz crystal.

______
On an unrelated note, this is my 100th post on this forum.

[Kremmen]

Oh AVRs are anything but niche, one of the most common MCUs out there. You can find them inside practically anything.
I don't know about matching PICs, that has never been an issue for me, but there are AVRs from the microscopic ATtiny10 in 6 pin SOT23-6 package to the popular ATMega328 (powering Arduino among other things) to larger Mega's and after that the semi 16 bit XMega series and finally the 32 bit UC32 series, with same toolchain for them all and Atmel SW Framework for most.

All your original questions and more are answered at http://www.atmel.com/products/microcontrollers/avr/default.aspx and http://www.atmel.com/tools/ATMELSTUDIO.aspx

[Bloch]

@Dave


There are the simple / easy to start / cheap ? in AVR ?


The Pickit is a 1 step and you are ready to code !

• Unpack the Pickit
• install the software on the cd
• plug the Pickit into the included demo board
• Download demo code to demo board it cant been easier....

With AVR why do he have to buy a cheap cheap programmer and it seams there are different types ...... not easy for a beginner.


<Rant> "The AVR is essentially works 4 times faster than a PIC with the same quartz crystal. "  Why do i use time on this  </Rant>


@casper.bang why did you not mentioned LINUX in the first post    But then you are in the 0.001% of the crowd it don't get easy-er. I have no idear how it is to program MCU´s on a Linux PC 

[casper.bang]

@casper.bang why did you not mentioned LINUX in the first post    But then you are in the 0.001% of the crowd it don't get easy-er. I have no idear how it is to program MCU´s on a Linux PC 

Yeah I probably should have, but I figured I could get far with Wine or VirtualBox if it came to that. However, native support from my OS in the form of IDE etc. is obviously a bonus.

I start to understand this is yet another religious debate with no one right answer. PIC really does feel more KISS (keep it simply stupid) to me, but toolchain and community matters as well.

Just found out Dave Jones also has a thing or two to say about this topic:

[Kremmen]

@Dave


There are the simple / easy to start / cheap ? in AVR ?


The Pickit is a 1 step and you are ready to code !

• Unpack the Pickit
• install the software on the cd
• plug the Pickit into the included demo board
• Download demo code to demo board it cant been easier....

With AVR why do he have to buy a cheap cheap programmer and it seams there are different types ...... not easy for a beginner.


<Rant> "The AVR is essentially works 4 times faster than a PIC with the same quartz crystal. "  Why do i use time on this  </Rant>


@casper.bang why did you not mentioned LINUX in the first post    But then you are in the 0.001% of the crowd it don't get easy-er. I have no idear how it is to program MCU´s on a Linux PC 

Ah but you are talking about kits - the others are talking about MCUs.
If a kit is all you want then grab an Arduino - won't get easier than that.
However, once you have designed an original circuit and included an MCU, you then do need a way to program and debug it. All of that you can do with AVRs and never leave the Studio.

[Dave]

Haha, I knew I would offend at least one PIC fanboy by pointing out that it's 4 times slower than an AVR.

With AVR why do he have to buy a cheap cheap programmer and it seams there are different types ...... not easy for a beginner.

What's so difficult about picking up the cheapest programmer on eBay that's advertised for AVRs? If that's difficult for you, I'd really hate to see you struggle with blinking an LED.

[madires]

@Bloch:
Those are very clear and direct answers, making me 99% ready to press the order button for a KIT and some PIC's. Also, the quick start you refer to makes it look very digestible, my main scare now is how great the Linux support is.

I'm happily AVRing with Linux, avr-gcc and avrdude for the software side and BusPirate as ISP programmer. There are tons of other inexpensive programmers supported by avrdude. IIRC the AVR Dragon also does HV parallel programming (required if you mess up the buse bits :-).

[mariush]

I went with PIC simply because I wanted a bigger "challenge" (to learn architecture and write asm or c closer to chip) and didn't want to get lazy and end up with arduino and sketches (basically an atmega with firmware in it, and you write some stupidified c that gets compiled into c or asm and uploaded into arduino)

Yeah, in theory it takes 4 cycles to do an instruction on a pic but it's not so cut and dry as the expression says - the attiny and whatever don't do one instruction per cycle, it varies, so they don't get 4 time the speed. Also you often get chips capable of running at higher clock speeds while the atmels are limited, so you can sort of make up in speed by raising clock (and waste a few more mWatts).

From what I noticed, PICs especially on the cheaper end or on the low pin count are more versatile (pack more hardware options) and often have integrated 20-24-32 mhz oscillator with reasonably good accuracy, while a lot of people say the built in oscillators on the atmel chips are junk and that you basically need external oscillator to do anything. I haven't tested it personally so I couldn't say, I found the internal oscillator in pic16's to be good enough for me.

With PICs you have a bigger initial investment - you kinda have to buy either pickit2 or pickit3 but then the programmer (pickit3) will work with any chip. pickit2 can't do some of the newest chips. There are clones on the market but I'm not sure how reliable they are.

[Paul Price]

Mariush:  The newest chips, like the PICC 1786 have a built in 32MHz clock, so they are 1 1/2 faster than the 16F886 type, for example, and the clock is accurate to 1% and also low power use at all clock speeds.

[Dave]

I went with PIC simply because I wanted a bigger "challenge" (to learn architecture and write asm or c closer to chip) and didn't want to get lazy and end up with arduino and sketches (basically an atmega with firmware in it, and you write some stupidified c that gets compiled into c or asm and uploaded into arduino)

You do realize, that we are talking about pure AVR C code here, not stupified arduino crap?
I have also programmed AVRs in assembly (in fact, my latest project uses asm only) and guess what, you can do that, too. Amazing, isn't it?

Yeah, in theory it takes 4 cycles to do an instruction on a pic but it's not so cut and dry as the expression says - the attiny and whatever don't do one instruction per cycle, it varies, so they don't get 4 time the speed. Also you often get chips capable of running at higher clock speeds while the atmels are limited, so you can sort of make up in speed by raising clock (and waste a few more mWatts).

Take a look at ATmega8 datasheet, page 302. You can see most instructions take 1 or 2 cycles, very few take up to 3, and only 2 branch instruction go up to 4. Now let's have a look at PIC16F1786 datasheet, page 379. Most instructions take 1 instruction cycle (4 clock cycles), all the control intructions (branch would be Atmel's equivalent) take 2 cycles (8 clock cyc.). Now compare the two.
So, top PICs go up to 32MHz (8MIPS), top AVRs go to 20MHz(20MIPS). AVR still wins.

From what I noticed, PICs especially on the cheaper end or on the low pin count are more versatile (pack more hardware options) and often have integrated 20-24-32 mhz oscillator with reasonably good accuracy, while a lot of people say the built in oscillators on the atmel chips are junk and that you basically need external oscillator to do anything. I haven't tested it personally so I couldn't say, I found the internal oscillator in pic16's to be good enough for me.

The internal oscillator directly from the factory are supposed to be accurate to 3% and you can calibrate the oscillator to 1%. As Paul Price states, this spec matches the one of the PIC. Of course, if your timing is critical (communication for example), you should use an external crystal or oscillator, but for other things, the internal oscillator is good enough.

[jucole]

One of the great things about Microcontrollers is there is a workflow to suit everybody.  I'm only a hobbyist, but I went with PIC; the main reason was because I felt Arduino wasn't as challenging as taking a single PIC chip and then building something completely from scratch.  It doesn't get more fun than creating your very own bit-bashing UART and I2C and debugging libraries etc.    At the moment I've moved to FPGA's and verilog,  but all that hard work with the PIC is really helping me with my big new project.   I'd like to try Arduino at some point but I just haven't got to it yet.

[mariush]

You do realize, that we are talking about pure AVR C code here, not stupified arduino crap?
I have also programmed AVRs in assembly (in fact, my latest project uses asm only) and guess what, you can do that, too. Amazing, isn't it?

What I mean is that by going the PIC route, I'm forcing myself to actually learn stuff better. I tend to find workarounds and shortcuts and that's what I mean by becoming lazy and going the arduino route. I want to code the libraries myself, to learn about the hardware, not just write a one liner in an arduino sketch, even though it's tempting because it's easy and fast.
Besides, pic is different and seems more interesting compared to avr, i could have gone with 8051 mcus just as well as avrs and it wouldn't have made any difference.

Take a look at ATmega8 datasheet, page 302. You can see most instructions take 1 or 2 cycles,

I never said at* are slower than pics, i agree they have more processing power but in real world the difference is not quite that big. 

The observation was more about the lower end, like I wrote.  atmega8 is a 2-3.5$, not a 0.5-1$ one.

Anyway, it doesn't really matter, no point to start a fight here about mcus. Pick one, you can always try the other if you want to later on.

[madires]

What I mean is that by going the PIC route, I'm forcing myself to actually learn stuff better. I tend to find workarounds and shortcuts and that's what I mean by becoming lazy and going the arduino route. I want to code the libraries myself, to learn about the hardware, not just write a one liner in an arduino sketch, even though it's tempting because it's easy and fast.

If you take the arduino just as a hardware platform you can do everything youself, doesn't matter if it's assember, C or C++. With the arduino IDE and the included libs a beginner is able to start the esay way. He'll have success quite fast and don't need to become frustrated over debugging for days. If he managed a few sketches he can proceed with avr-gcc directly and become a guru :-)

[Dave]

Anyway, it doesn't really matter, no point to start a fight here about mcus. Pick one, you can always try the other if you want to later on.

I didn't mean to start a fight, either. I apologize if it appeared so.
To be honest, if you are going to do anything more complex with a microcontroller, you are probably going to switch to ARM, since they offer far superior processing power, more peripherals and are generally cheaper than comparable AVRs and PICs.

[stev.dk]

As a beginner in MCU's, but with experience in programming, i started by getting a cheap-ass e-bay ISP programmer, and an AVR (Atmega32)... It might be a two step process, cause i got the programmer and chip separately (one step if theres a seller providing both). I dont count downloading the free software as a step really, cause you should really always download the newest version, no matter if its free or not.

I've been very happy with it. I like the AVR software, and it is as good as any programming texteditor i've worked with. Im not fanboy or expert in the capabilitys of the avr or pic mcu's, but comming from a programmer background, i can recommend this 

[casper.bang]

Fanboy talk aside and more practical concerns in context; I'm disappointed that Atmel Studio is a (giant) Windows-only application. Also, ATtiny10 does not seem easy to program i.e. not possible with even the popular Dragon and also not listed as supported by AVRISP mkII. Meanwhile, it was a snap to download and Install cross-platform toolchain and IDE (MPLAB-X, clearly based on Java and the NetBeans IDE) for PIC. So unless I am wrong about this or discover anything groundbreaking, I think I'm just gonna get the PicKit2.

[madires]

Fanboy talk aside and more practical concerns in context; I'm disappointed that Atmel Studio is a (giant) Windows-only application. Also, ATtiny10 does not seem easy to program i.e. not possible with even the popular Dragon and also not listed as supported by AVRISP mkII. Meanwhile, it was a snap to download and Install cross-platform toolchain and IDE (MPLAB-X, clearly based on Java and the NetBeans IDE) for PIC. So unless I am wrong about this or discover anything groundbreaking, I think I'm just gonna get the PicKit2.

The ATtiny10 is not programmed via the ISP as most other ATtiny or ATmega MCUs. It uses TPI which is some kind of stripped down SPI. TPI is supported by the buspirate.

[stev.dk]

Fanboy talk aside and more practical concerns in context; I'm disappointed that Atmel Studio is a (giant) Windows-only application. Also, ATtiny10 does not seem easy to program i.e. not possible with even the popular Dragon and also not listed as supported by AVRISP mkII. Meanwhile, it was a snap to download and Install cross-platform toolchain and IDE (MPLAB-X, clearly based on Java and the NetBeans IDE) for PIC. So unless I am wrong about this or discover anything groundbreaking, I think I'm just gonna get the PicKit2.

Im running AVR Studio on my macbook pro, and a friend of mine is running it in ubuntu.

I gave about 10$ for a ISP programmer, that programs all the ATtiny and ATmegas. I followed along some of these tutorials, just to get a basic understanding, not to brick my first mcu.

https://www.youtube.com/playlist?list=PLE72E4CFE73BD1DE1

[casper.bang]

According to what I can dig up, the attiny10 are program med via TPI.

[stev.dk]

According to what I can dig up, the attiny10 are program med via TPI.

http://minisystem.blogspot.dk/2012/01/programming-attiny10-with-avrisp-mkii.html#attiny10tutorial

[C]

just starting you might want to think on what kind of things you create.
Coming from the software side may change things also. You may have a lot easer time dealing with software and more problems dealing with limited hardware.

This may be wrong and is in some cases, but from my looking.
AVR is a line of chips that add instructions as mpu power increases. 
PIC  is a family of chips so you have a lot of changes both in instructions sets and built in hardware when you shift lines(pic16, pic18, picXX) with in the family.

With an ARM chip you may have a large number of the same type of interface and a lot of different types at a low cost. If you can find a chip the same in AVR, PIC it will most times cost more.

For some projects, if you look at total Hardware costs it could be cheaper to start with one of the many ARM chips. With other MPU's you may be adding chips to do a job while with ARM what you need is in the chip.
Very few ARM chips are in dip packages, so with ARM it would be better forget DIP packages. ARM chips also can have a lot of pins.   

On the very low end you have a mpu being something like smart logic. If an ARM chip can do the needed task, you still have more pins and chip cost does not go as low as AVR, PIC or MSP430.
 
If your project is connecting to a PC then your best choice I think would be a USB connection. You could use a MPU with out a USB interface and add a chip to get a USB serial port or a USB parallel port or you could use a MPU with USB interface built in and have the option for both and more. With an internal USB interface you have more options but more to do in software to get it to work. With internal USB you can have higher speeds an move to more packet based communications. As the need for speed increases the deck shifts more to a ARM based choice and at some point is the better choice.

If you want a graphics based screen for display, the deck is shifting to ARM.
If you want faster floating point or bigger integers the deck is shifting to ARM.
The reverse is also true, for some tasks/projects the deck is stacked against the ARM.
     
So ARM gives a huge range of options in cpu hardware chips and has more computing power. This means a bigger learning curve up front and I see less ARM specific examples to work from. If you want easy plug together hardware this is not it and you would probably do better with arduino, but that is not a good statement as there are now ARM based boards for arduino platform that limit some capabilities of the ARM chip.

You could build a clock with any of them. If you want to add graphics or sound the deck starts shifting to ARM.

For an expensive ARM start
STM32 discover boards are the lowest and include a programmer & debugger. You could use the programmer & debugger for some other projects using ST's line of STM32 ARM chips (<$16). Most of the STM32 discovery boards have some added chips to play with to get you started.
 

NXP's lpcxpresso boards NXP site states "The platform is comprised of a simplified Eclipse-based IDE and low-cost target boards which include an attached JTAG debugger". NXP's mbed is the high end

I would suggest If you are leaning to higher end projects ARM might be good in long run, but may have a higher learning curve at the start.

[smashIt]

my 3 reasons why I went PIC:
- PICkit
- 32bit PICs are available in dip-packages
- free samples, even for hobbyists 

Take a look at ATmega8 datasheet, page 302. You can see most instructions take 1 or 2 cycles, very few take up to 3, and only 2 branch instruction go up to 4. Now let's have a look at PIC16F1786 datasheet, page 379. Most instructions take 1 instruction cycle (4 clock cycles), all the control intructions (branch would be Atmel's equivalent) take 2 cycles (8 clock cyc.). Now compare the two.
So, top PICs go up to 32MHz (8MIPS), top AVRs go to 20MHz(20MIPS). AVR still wins.

top 8 bit pics go up to 64mhz (pic18 series)
according to the rest of your data (4 cycles / instruction for pic, and ~1,5 cycles for atmel) that would put pics at ~16MIPS and atmega at ~ 14MIPS
sounds like a tie to me

[Corporate666]

I'll throw a wrench into the mix and recommend PSoC from Cypress, especially the PSoC 3, 4 and 5. 

It's not really possible to define the "best" chip unless you have also defined the application.  If it's just to learn, then learning ARM would probably be the most useful in one's career, IMO.  If it's just to have fun, Cypress has a ton of dev kits and sample kits that show off a lot of cool functionality with PSoC.  The built-in peripherals make things like USB and SPI easy, and interfacing with LCD, LED and I2C very easy as well.  And one of the biggest benefits is that when you get more advanced, you can write your own Verilog - so you're getting into FPGA land all in a very easy to use very simple chip and toolchain.

We used to use all Atmel in our designs, now we use all PSoC.  Atmel chips are not bad, but I don't like the company.  Their support sucks and IMO their treatment of the small guys suck too.  And honestly, there are way more d-bags in the Atmel community who will talk your ear off about how the AVR chips are better than everything else.  It's like listening to Apple fanbois sometimes!

[Dave]

top 8 bit pics go up to 64mhz (pic18 series)
according to the rest of your data (4 cycles / instruction for pic, and ~1,5 cycles for atmel) that would put pics at ~16MIPS and atmega at ~ 14MIPS
sounds like a tie to me

Weeeeeell... It's the Mega family that goes to 20MHz max, the XMega family (also 8-bit) goes up to 32MHz.

[smashIt]

Weeeeeell... It's the Mega family that goes to 20MHz max, the XMega family (also 8-bit) goes up to 32MHz.

weeeeeell... that would result in approximately 16 vs 20 MIPS
still far away from your x4 performance-difference

BUT! 
atmel is advertising them for 16bit tasks
do you realy want to compare them to a dsPIC or PIC24?

but the whole argument is moot anyways

[mark5009]

Casper,

Originally, you said "Could a kind soul perhaps guide me in some direction such as best starter kit and/or resources which could help a noob like me get a feel for this new MCU world? I don't really have any specific requirements, apart from cheap/small/easy and A/D would be nice too."

Get onto the Microchip website and order a Pickit2.  Then send them an email and ask for a few chips that you like the look of (samples).  This will set you back $50 or so.  It includes a C compiler, etc..

If you prefer open-source and something other than C, there is JAL which runs under windows and Linux.  You can find more info about it here
 
  http://justanotherlanguage.org/

 .. mark.

[MacAttak]

Arguing over which is better is pointless unless you folks are just looking to blow off some steam?

Just look at the toolchains and make a decision based on your own preferences about IDE platform and features. If you like Windows and the Visual Studio environment, then maybe AVR is the right path (Atmel Studio runs inside the Visual Studio 2010 shell). If you have reason to dislike that, then perhaps PIC is a better choice. Or as someone else mentioned, you could set up a custom toolchain using gcc and avrdude to get an AVR environment running minus the IDE features.

Personally, I like the AVR tools and Atmel Studio. I have a JTAGICE3 and an assortment of AVR's - from tiny13's up to mega's. The IDE works well, and the DebugWire functionality has come in handy a few times.

I'm sure PIC are great devices too. But I hate Basic, and have no desire to use ASM unless absolutely necessary. And since I'm already comfortable with AVR, I see no need to worry about PIC for the time being.

But you might have entirely different preferences.


Also, in the tear-downs here (as well as my own limited repair work), it seems like Atmel parts show up far more often than PIC. I'm not sure what that means, if anything.

[madires]

Just look at the toolchains and make a decision based on your own preferences about IDE platform and features. If you like Windows and the Visual Studio environment, then maybe AVR is the right path (Atmel Studio runs inside the Visual Studio 2010 shell). If you have reason to dislike that, then perhaps PIC is a better choice. Or as someone else mentioned, you could set up a custom toolchain using gcc and avrdude to get an AVR environment running minus the IDE features.

You can also have an IDE with your custom tool chain. Eclipse with the AVR plugin runs fine on Windows and Linux PCs. Eclipse also supports tons of other stuff (even PICs), so you got one IDE for several targets. I like consoles and simply use make :-)

[casper.bang]

Casper,t

Originally, you said "Could a kind soul perhaps guide me in some direction such as best starter kit and/or resources which could help a noob like me get a feel for this new MCU world? I don't really have any specific requirements, apart from cheap/small/easy and A/D would be nice too."

Get onto the Microchip website and order a Pickit2.  Then send them an email and ask for a few chips that you like the look of (samples).  This will set you back $50 or so.  It includes a C compiler, etc..

I talked to some EE's at work (I'm a SE not an EE) and I was offered all kinds of (to me) overkill dev boards. Thankfully they also had a Microchip Pickit1 with a 12F675 and mini USB connection, which looks fine for me to try. I was very close to ordering AVR AVRISP mkII and some 8-bit ATtiny MCU's and I might still after I check out the PIC stuff. It's not really about the $30 - $60 investment cost (you reach a point in life where you value time more than your money), but free and available is hard to beat! Thanks for the feedback guys, I definitely learned a lot from the comments.

[C]

casper,

with the great offer from the guys at work, you might have missed something.
I would say that a lot of the " overkill dev boards"  might have been created to save the EE time to test out an idea. I would expect that some of the  "overkill dev boards" as you call them were created for some area specific area of mpu use, while some might be more general an have some hardware for a lot of areas.
The Idea is build or use an example that came with the board. Then slowly replacing/modifing hardware/software parts of the " overkill dev boards" with your own circuits until you are no longer  using the " overkill dev boards" hardware.  Instead of a software & hardware problem at the same time, you fix a hardware problem then update and improve the software. 

If you are going with PIC you might want to look see if any are based on PIC.
As most also come with schematic(s) and part lists, you also have hardware design that works with a specific chip. Some very good reference material in that offer.

C

[casper.bang]

with the great offer from the guys at work, you might have missed something.
I would say that a lot of the " overkill dev boards"  might have been created to save the EE time to test out an idea. I would expect that some of the  "overkill dev boards" as you call them were created for some area specific area of mpu use, while some might be more general an have some hardware for a lot of areas.
The Idea is build or use an example that came with the board. Then slowly replacing/modifing hardware/software parts of the " overkill dev boards" with your own circuits until you are no longer  using the " overkill dev boards" hardware.  Instead of a software & hardware problem at the same time, you fix a hardware problem then update and improve the software. 

I hear what you are saying. The thing is, I'm interested in miniaturizing rudimentary legacy designs revolving around such components as a 555 timer, 339 comparator, ADC's, discrete logic gates and the like. I really have no interest in developing full blown miniature computers, which these development boards really are about. For that kind of performance (in fact, much higher performance than any comparable dev board I have seen), I'm using my cheap 50$ Android stick with a USB-Serial adaptor and GPIO adaptor, since it allows me to use proper high-level GC'ed languages like Java and Mono (which is what I use every day) while still staying within a conservative power envelope.

If you are going with PIC you might want to look see if any are based on PIC.
As most also come with schematic(s) and part lists, you also have hardware design that works with a specific chip. Some very good reference material in that offer.

PIC really does seem like the easiest step forward, the toolchain and IDE works on Linux and feels a bit less confusing than the AVR stuff. Since the PicKit1 that I have proved to be somewhat outdated (unsupported in MPLABX, and open-source GCC compiler won't compile), I'm back to square one. I guess I should just order both kits and write a blog entry about my findings.

[mark5009]

casper,

Just to add to the confusion :-) I would suggest a form follows function approach.  It is not considered usual these days, but, if you are in learning mode and don't have commercial requirements, then it can be a lot of fun.

For example, I am doing much as you are (EE, turned SE, turned architect, now getting back into the EE side of things non-professionally).  I have a PICkit 2 Dev Ket (it comes with a board), a stack of 8-bit PICs that I play with.  I like to use CAL with them.  It works.

I also have an Cortex-M3 board (the Olimex LPC-2103) that can use either the GNU toolchain or, my preference, Frank Sergant's Riscy Pygness Forth system.  And I run both against Win or Linux as needed.

Most of what I do can be done with an 8-bit micro, so I use the PICs.  Otherwise, it is the ARM.  And given that it is just for me, I can avoid the curse that is C (ducks ;-) )

 .. mark.

[mariush]

Casper, you can still download MPLAB IDE 8.91 from Microchip's website (see bottom of the page) :

http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en019469&part=SW007002

It's not based on netbeans but it should still work reasonably well.

The old version should work with Pickit 1 just fine and you should have the hi-tech c compiler (the free version that doesn't optimize that well but has no code size limitations) and mpasm and others included in the zip file. If not I can send them to you somehow. 

and you have here an archive of various compilers... http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en023073


later edit: and in case it helps you out, here's all the software and code for that pickit 1 board you probably have  :  http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010053

[poorchava]

Leave alone the AVR & PIC, go for ARM.

[casper.bang]

Just to add to the confusion :-) I would suggest a form follows function approach.  It is not considered usual these days, but, if you are in learning mode and don't have commercial requirements, then it can be a lot of fun.

For example, I am doing much as you are (EE, turned SE, turned architect, now getting back into the EE side of things non-professionally).  I have a PICkit 2 Dev Ket (it comes with a board), a stack of 8-bit PICs that I play with.  I like to use CAL with them.  It works.

I also have an Cortex-M3 board (the Olimex LPC-2103) that can use either the GNU toolchain or, my preference, Frank Sergant's Riscy Pygness Forth system.  And I run both against Win or Linux as needed.

Most of what I do can be done with an 8-bit micro, so I use the PICs.  Otherwise, it is the ARM.  And given that it is just for me, I can avoid the curse that is C (ducks ;-) )

Hehe yeah C isn't exactly a modern development experience, although it has remained true to its heritage unlike C++. A modern systems programming language would of course be something like Google's Go. Like you, I also expect to be satisfied with what can be done with an 8-bit micro, there's enough hobby challenges for me in that. For one thing, how on earth is my PicKit1 board with a tiny 8-pin 12F765 PIC able to control the 8 red LED's individually - with VCC/GND tying up two pins, I'm missing at least two outputs?! 

Casper, you can still download MPLAB IDE 8.91 from Microchip's website (see bottom of the page) :

http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en019469&part=SW007002

It's not based on netbeans but it should still work reasonably well.

The old version should work with Pickit 1 just fine and you should have the hi-tech c compiler (the free version that doesn't optimize that well but has no code size limitations) and mpasm and others included in the zip file. If not I can send them to you somehow. 

and you have here an archive of various compilers... http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en023073


later edit: and in case it helps you out, here's all the software and code for that pickit 1 board you probably have  :  http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010053

Thanks for all those great resources. I have had little luck getting it to work on Linux (though MPLAB IDE 8.91 and utilities actually starts up fine via CrossOver) so I will have to boot up a real Windows if I can find one somewhere. I actually went ahead and ordered an AVR programmer and a bunch of tiny AVR micros, but that doesn't mean I won't dig into PIC's as well - at least until I receive the parts.

Thanks again for the great feedback to all participants chiming in.

PS: I'm used to answering ridiculous "No I am not a terrorist" questions when traveling to the US, but it was news to me, that US export laws require Digi-Key to ask me what I am using the parts for! I reckon answering "Not for military, nuclear or strong encryption stuff" either expedited my order, or landed me on some silly watch list. Really fail to see the logic in these kind of questions, as if real terrorists answer truthfully to these?!

[Kremmen]

[...]
For one thing, how on earth is my PicKit1 board with a tiny 8-pin 12F765 PIC able to control the 8 red LED's individually - with VCC/GND tying up two pins, I'm missing at least two outputs?! 

Not knowing the PICs and their capabilites in detail, this may not apply to your particular chip but as a general practice: use SPI and 74xxx595 serial in-parallel out shift registers. Provided your MCU has the MOSI signal available that makes life semi easy; you can chain the 595s and push the data in at one end. I do this all the time to drive 7 segment displays, relay outputs, LED arrays and whatnot. You need 1 signal for the data, 1 for the clock and 1 or 2 for chip select/enable and thats it. Replacing 8 to (say) 32 outputs this waý is almost trivial and the upper limit is defined in practice only by the required update rate vs the cycle time you can achieve from the MCU. But a HW SPI can be real fast so i never found that limit yet.
And lacking a HW SPI, you can always bit bang the serial data.

[casper.bang]

Not knowing the PICs and their capabilites in detail, this may not apply to your particular chip but as a general practice: use SPI and 74xxx595 serial in-parallel out shift registers. Provided your MCU has the MOSI signal available that makes life semi easy; you can chain the 595s and push the data in at one end. I do this all the time to drive 7 segment displays, relay outputs, LED arrays and whatnot. You need 1 signal for the data, 1 for the clock and 1 or 2 for chip select/enable and thats it. Replacing 8 to (say) 32 outputs this waý is almost trivial and the upper limit is defined in practice only by the required update rate vs the cycle time you can achieve from the MCU. But a HW SPI can be real fast so i never found that limit yet.
And lacking a HW SPI, you can always bit bang the serial data.

From a base 2, logically you are able to drive 2^4 states across the 4 output pins, but not control 12 individual LED's. However, the truth table reveals a third output state (Z) and the circuit diagram hints at a clever bi-directional setup. I guess there's a name for the technique, akin to multiplexing.

[C]

hink like a serial port
pin 1 data out
pin 2 data in
pin 3 clock to shift data
pin 4 signal to capture data on input / latch the output data of shift regester

what goes out pin 1 could be ___ bits delayed coming back to pin 2

Serial memory with IO
split function of pin 4 to
pin 4 latch input data
pin 5 latch output data

just 5 pins and you could do almost any thing just not very fast.

[ptricks]

Since you went with PIC I am going to recommend you either get via samples or buy some of the 16f1823 and here is why.
One of the most frustrating things when starting out is hard to follow data sheets. The sheets for the 16f1823 are so well done that I even wrote microchip commending whoever wrote them because it is how all data sheets should be written. Everything is covered in detail with code examples. The chips are also pretty cheap and very capable without confusing you with a ton of peripherals .

[Kremmen]

From a base 2, logically you are able to drive 2^4 states across the 4 output pins, but not control 12 individual LED's. However, the truth table reveals a third output state (Z) and the circuit diagram hints at a clever bi-directional setup. I guess there's a name for the technique, akin to multiplexing.

Yep, also for AVRs, just define the pin as input and drive it to '0' and it is 3-stated. Standard stuff.
But my point with the shift register was something else. It is not just a clever trick, it is a genuinely useful technique widely applied when one is short on pins or they are better applied elsewhere.

[casper.bang]

Yep, also for AVRs, just define the pin as input and drive it to '0' and it is 3-stated. Standard stuff.

But my point with the shift register was something else. It is not just a clever trick, it is a genuinely useful technique widely applied when one is short on pins or they are better applied elsewhere.

No doubt, there are all sorts of useful serial multiplexing techniques hooking up latches and shifters, I was just puzzled by the elegant no-cost 4 output to 12 LED solution... feels like Fundamental Friday material. 

[selkathguy]

Goodness this thread blew up. 

I had a feeling when someone was asking about what micros to try out that this might happen.   I'm very new to the whole thing, but for the specific project I'm working on, I chose an AVR 32bit micro because it has a DSP instruction set and everything else I need in one go.  (Doing FFT instructions in a couple cycles is awesome).  But that's what it's about, OP.  It's about looking at the feature sets of all kinds of micros and figuring out what works best for your application.  After wrapping my head around various source library code for an AT32UC3B, I'm starting to understand it and all the witchcraft actually makes sense and works well in their programming environment.   Honestly, for the cost I would try out both PICs and AVRs if you can.  To make an insanely gross overgeneralization:  PICs to me seem great if you want to lash up something quickly because it's very straight-forward and requires very very little C code to do something simple.  AVRs tend to require a bit more reading of datasheets to avoid 'gotchyas', but are quite powerful in what you can accomplish on such a small device.  PICs can be powerful too, you'll just have to get a feel for which is better for your application.  Execution speed isn't always the only metric; it's often the feature sets like Direct Memory Access and (for example), the Digital Signal Processing instrucions that I needed in my project.

I know that's vague but I hope it helps give some insight.

[MacAttak]

From a base 2, logically you are able to drive 2^4 states across the 4 output pins, but not control 12 individual LED's. However, the truth table reveals a third output state (Z) and the circuit diagram hints at a clever bi-directional setup. I guess there's a name for the technique, akin to multiplexing.

That name is "Charlieplexing".

http://en.wikipedia.org/wiki/Charlieplexing

[mariush]

There are also some other neat tricks explained by microchip in their app notes and guides.

See the following:

http://savedonthe.net/a/Tips_n_Tricks_01146b.pdf
http://savedonthe.net/a/Tips_n_Tricks_40040C.pdf

Lots of neat tricks for low pin count, keyboards, multiplexing etc explained pretty good.

[Dave]

Charlieplexing is a nice way to light lots of LEDs with just few uC pins, but it has one major setback: If one of your LEDs has a bad connection, several other will light up instead. It can be a real pain to figure out which LED is faulty, if something goes bad. 

[casper.bang]

Those tips-n-tricks docs are virtual goldmines. Although they go far beyond MCU's/PIC's, they should almost be a sticky in the dedicated micro-controller forum.

[casper.bang]

I feel I should wrap up my thread by describing my findings as a practicing MCU noob.

First of all, I did start with a PIC and a PicKit1 proto-board, but I never had much success with this. In all fairness, the PicKit1 is reasonably old (although USB based) and so had all kinds of trouble getting software to work, not made easier by the fact that I'm a Linux guy. A newbie with the PicKit2/3 on Windows might very well form a very different opinion.

Then I got a hold of the official Atmel avrisp mkii programmer with various ATtiny's and quickly wired up a programming board and installed the software with an apt-get onliner command. Within a few hours, I was writing C samples, compiling to hex, transferring to MCU and running the program on a breadboard. Amazing, as a software guy used to high-level abstractions and abundant hardware resources, to see the other end of the scale with an IC the size of a the head of a match, consuming just 7uA when sleeping.

So anyway, it may not apply to everyone, but for those used to standard open source tool-chains without a need of an IDE, I have to say the AVR experience with the tiny is very KISS and a hell of lot of fun. If/when I feel the need to move on to more advanced chips, the path seems paved and clear. 

[madires]

Just as a side note, I bought a Diamex ALL-AVR programmer for €31 because the buspirate is testing my patience :-) The ALL-AVR runs fine with avrdude (avrispmkII compatible) under Linux and is about 10 times faster than the buspirate. It supports ISP (3.3V or 5V), TPI (12V for reset too) and PDI. It also provides a 500kHz clock in case you messed up the clock fuse bits.

[ptricks]

The bus pirate is a great tool to have but I think in cramming in all the functions it became the ' jack of all trades, master of none'

[madires]

The bus pirate is a great tool to have but I think in cramming in all the functions it became the ' jack of all trades, master of none'

The V4 has more horsepower and an integrated USB. The USB speed of the old 3.x is limited to 115kbit/s by the FTDI chip. That also limits the programming speed. As soon as I see the V4 in a local store I'll get one and compare the programming speed with the V3.

[alm]

The bus pirate (v3) was not designed for fast data IO, but for interactive communication with relatively slow parts like sensors. I never considered the PIC/JTAG/AVR programming features anything but a clever hack, although I've used it once when I didn't have anything better available. For serious programming, I would definitely recommend a dedicated PIC/AVR/JTAG programmer.

[madires]

The bus pirate (v3) was not designed for fast data IO, but for interactive communication with relatively slow parts like sensors. I never considered the PIC/JTAG/AVR programming features anything but a clever hack, although I've used it once when I didn't have anything better available. For serious programming, I would definitely recommend a dedicated PIC/AVR/JTAG programmer.

That's exactly what I bought the ALL-AVR for :-) The puspirate is like ncat in the Unix world, it's a quite useful tool with tons of features. And it's supported by several software tool boxes (under Linux). So it's a good starting point, but if I dwell into a specific area I'll get the right tool.