Atmel vs Pic in Linux environment

[jiro]

Hi guys,

I'm getting into the electronics (again, I studied a litte some years ago) but also into microcontrollers, but now I face the decition of which one to start with but based on the linux support (not which one is the best).

So let me tell a little about me, I'm on devops (programmer, sysadmin and all that funny stuff) in my work I have a Linux only box, in my home a laptop only with Linux and my desktop that have dual boot but windows is only used to play, all my stuff is on linux (just as a note I don't hate Windows, just love Linux  ).

That being said, I'm trying to decice between Pic and Atmel (I know they are both from Microchip) but based on the toolset available for linux.

I found that Atmel have a toolchain with debugger, compiler and stuff, but basically works only from the command line (which I don't really care) and can be integratied with any IDE that suports GDB and external compiler, but also noticed that the Atmel ICE is not very compatible with the Linux tools.

Microchip has the MPLabX (I don't like that they use netbeams, that java stuff sometimes is a little memory consuming) I read that the C compiler is not very optimized and if you want the better one you have to pay.

So, based on your experience, which one have the better toolset/suppoert for Linux?

I'm asking because if I'm going to sped some money in the programmer and stuff I'd like to have at least a nice toolset to play with, also I've done a little with Arduino and I want to go deeper into Micros.

PD.: Excuse my bad english, I'm not a native english speaker. 

[igendel]

For an easy start on Linux, I believe PIC is the better option. Despite the disadvantages, the MPLAB X IDE is still more comfortable than messing with command line, the free compiler is not bad for everyday uses, and you can get clone programmers that are much cheaper than Atmel ICE.

For playing around with PICs, there's also MPLAB Xpress, the online IDE. It generates the HEX file that you can burn directly to the MCU, or drag-and-drop if you have an MPLAB Xpress dev board.

[colorado.rob]

What are your goals?  Why did you choose these two options?

If you are just starting out with embedded stuff, the Arduino boards using Atmel Atmega chips are cheap, the IDE is easy to use, there is a ton of help online. You don't really need a programmer as the dev boards have bootloaders.  And if you do, you just use a second Arduino board as the programmer.  For prototyping on a breadboard, the Arduino Nano is a great little device.  Really, for support, nothing beats the Arduino/Atmel.

If you want a bigger challenge an d need more than 8 bits, go with an ARM-based board.  The Nucleo boards from ST are really inexpensive and the Nucleo64 boards have a programmer/debugger built in to them.  The toolchain is a little bit more involved, but you can start out with their online mbed.org environment and then move to Eclipse with GCC.  The Nucleo32 boards are about the same size as the Arduino Nano.

A good progression is: Arduino, mbed.org then GCC/Eclipse.

You are not going to get away from Java-based tools once you start moving up to more powerful microcontrollers unless you are a glutton for punishment.  Virtually all of the toolchains are Java based (mostly using Eclipse).

[NorthGuy]

MPLAB X works on Linux.

8-bit compiler (XC8) is Ok. The paid version is slightly better.

16-bit compiler (XC16) is mediocre. PIC24/dsPIC33s have very reach instruction set and the compiler doesn't take full advantage of it. But it's fine if you don't need to push these PICs to the limit.

32-bit compiler (XC32) is good - the MIPS processor is a RISC processor optimized for C.

[jiro]

Thanks every body for your answers.

What are your goals?  Why did you choose these two options?

Basically play with embedded stuff and see what can I do mixing what my current knoledge and the elctronics. I choose those 2 because are the most popular at the moment (ok, not the most technical answer)

If you want a bigger challenge an d need more than 8 bits, go with an ARM-based board.  The Nucleo boards from ST are really inexpensive and the Nucleo64 boards have a programmer/debugger built in to them.  The toolchain is a little bit more involved, but you can start out with their online mbed.org environment and then move to Eclipse with GCC.  The Nucleo32 boards are about the same size as the Arduino Nano.

I didn't know they even exists, but I was researching in Google and looks good, actually they seems to have a pretty  nice variety of devices. They resemble the Chip project https://nextthing.co/ but with much more options

Since I'm not in a rush I'll take my time to research a little more and go thru the comments. I already have an arduino and a couple of raspberrys.

Thanks again for all the answers, I'll be posting any progress or decision I make in my way

[nctnico]

Thanks every body for your answers.

What are your goals?  Why did you choose these two options?

Basically play with embedded stuff and see what can I do mixing what my current knoledge and the elctronics. I choose those 2 because are the most popular at the moment (ok, not the most technical answer)

That was true a decade ago. Nowadays people go for ARM based processors and for good reasons: PIC (8 bit) and AVR are archaic architectures and will run out of memory and processing power real quick.

[alm]

Agreed that you should take a hard look at starting with one of the ARM platforms (NXP and ST seem to be the most popular with hobbyists, followed by TI) through mbed and then move on to whatever IDE you prefer. If you don't mind rolling your own with gcc, gdb, Eclipse/Code::Blocks/whatever, you should do well with any ARM. Otherwise you might want to look at Atollic (supports most vendors) and NXP MCUXpresso (only NXP parts).

As for AVR vs PIC, PIC is the only one with a complete IDE package, but AVR has the better open source support and better free C compilers for low-end parts. Debugging with the ICE is theoretically supported by avarice, but I am not sure how stable that is. Support for the AVR Dragon might be better. If you want an IDE without Java, then you are free to use any IDE (e.g. Code::Blocks) with the open-source AVR tools. So I think it is kind of a toss up depending on your preferences.

[Fungus]

That was true a decade ago. Nowadays people go for ARM based processors and for good reasons: PIC (8 bit) and AVR are archaic architectures and will run out of memory and processing power real quick.

There's also very good reasons for wanting 5V lines, a bit of current available from the pins, low power usage and a certain degree of electrical robustness.

Not everything needs 1MB of RAM and a 1GHz processor.

[nctnico]

That was true a decade ago. Nowadays people go for ARM based processors and for good reasons: PIC (8 bit) and AVR are archaic architectures and will run out of memory and processing power real quick.

There's also very good reasons for wanting 5V lines, a bit of current available from the pins, low power usage and a certain degree of electrical robustness.

Not everything needs 1MB of RAM and a 1GHz processor.

Most (say 99%) of NXP's ARM microcontrollers are 5V tolerant, can drive LEDs (optocoupler) and have low power modes which are at least equal if not better than 8 bit PICs. BTW 5V is so 1980's. Modern designs use 3.3V or less and 5V chips are getting rare.

[Fungus]

Most (say 99%) of NXP's ARM microcontrollers are 5V tolerant

What about outputting 5V? Can they do that?

Current? Can you drive an LED directly from an ARM pin? It's the sort of thing most hobbyists want to do.

5V is so 1980's.

Oh I see, it's a fashion thing. I guess you need all that RAM/CPU to run a modern language like Python, too.

[nctnico]

It is not a fashion thing. If you had some hands-on experience yourself you'd know that writing software for an 8 bit PIC is a major pain in the ass compared to writing software for an ARM. For starters on an 8 bit PIC you can't use pointers without slowing a program down to crawl speed. And then there are several memory banks to deal with which you have to assign manually once the compiler gets confused. The list is endless.

[Fungus]

It is not a fashion thing. If you had some hands-on experience yourself you'd know that writing software for an 8 bit PIC is a major pain in the ass compared to writing software for an ARM. For starters on an 8 bit PIC you can't use pointers without slowing a program down to crawl speed. And then there are several memory banks to deal with which you have to assign manually once the compiler gets confused. The list is endless.

I don't use PIC for that very reason. AVR all the way... 

[janoc]

What about outputting 5V? Can they do that?

No, but their outputs tend to be 5V TTL/CMOS compatible, so interfacing to 5V peripherals is no problem even without level conversion. And if you really must have 5V somewhere, then it is a matter of a adding a single transistor.

Current? Can you drive an LED directly from an ARM pin? It's the sort of thing most hobbyists want to do.

Absolutely. E.g. STM32F103 series that has boards going for peanuts on eBay or AliExpress:

"The GPIOs (general-purpose inputs/outputs) can sink or source up to ±8 mA, and sink or
source up to ±20 mA (with a relaxed VOL/VOH) except PC13, PC14 and PC15 which can
sink or source up to +/-3mA."

(http://www.st.com/content/ccc/resource/technical/document/datasheet/33/d4/6f/1d/df/0b/4c/6d/CD00161566.pdf/files/CD00161566.pdf/jcr:content/translations/en.CD00161566.pdf
 )

20mA is plenty for any LED, even 8mA is enough for most.

Other STM32 chips are similar.

[Fungus]

20mA is plenty for any LED, even 8mA is enough for most.

True, but you can't actually get 20mA with 3.3V on many LEDs.

I'll bear them in mind but an AVR Mega328 is slightly cheaper (currently about $1.60 for a "Pro Mini" on eBay) more versatile, electrically speaking, and has a much bigger ecosystem. If you don't need 72MHz then use the right chip for the job.

[nctnico]

20mA is plenty for any LED, even 8mA is enough for most.

True, but you can't actually get 20mA with 3.3V on many LEDs.

Who needs 20mA for a LED nowadays? A few mA gets most LEDs to full brightness.

[Fungus]

Who needs 20mA for a LED nowadays? A few mA gets most LEDs to full brightness.

I don't want to close any doors.

(and that's only one application, what about driving MOSFETS with PWM - every mA counts!)

PS: This is pointless and it doesn't belong in "Test Gear".

[nctnico]

Who needs 20mA for a LED nowadays? A few mA gets most LEDs to full brightness.

I don't want to close any doors.

(and that's only one application, what about driving MOSFETS with PWM - every mA counts!)

5V and a few mA of drive strength isn't enough for MOSFETs driving any serious load with high efficiency. Just look at the graphs which show RDSon versus Vgs (especially at operating junction temperatures and not 25 degrees).

BTW I expect the moderators will move this thread to the relevant section shortly.

[janoc]

20mA is plenty for any LED, even 8mA is enough for most.

True, but you can't actually get 20mA with 3.3V on many LEDs.

I'll bear them in mind but an AVR Mega328 is slightly cheaper (currently about $1.60 for a "Pro Mini" on eBay) more versatile, electrically speaking, and has a much bigger ecosystem. If you don't need 72MHz then use the right chip for the job.

Jeeze, and what sort of LED are you trying to drive that it needs 20mA and won't be able to get it from a 3.3V source? Are you trying to drive one of those Cree LEDs directly from the micro?

Um, Mega328 "slightly cheaper"? You have to be kidding. I am not talking about overpriced boards. Octopart shows Mega328 for $1.70 in 1-10 unit quantity.

STM32f030 which is more comparable to the 8bit AVRs like the Mega328 costs a ~$1, depending on variant. And devboards with the much more powerful STM32F103 are for $2 on AliExpress. So saving 40 cents and buying an 8bit micro is really "a win". The right chip for the job is the one that fulfills your requirements and gives you the best value for buck, especially with the outlook of possible future updates/extensions, not the slowest one you can just cram your application into, with no chance for any future expansion.

Also that stuff about the MOSFETs - if you are driving a MOSFET with PWM, you will want to use a driver anyway, unless you are driving logic level MOSFETs. Even then the switching losses are going to be terrible, regardless of whether you drive from a 3.3V micro or 5V one - the chips simply aren't able to deliver sufficient current to charge/discharge the gate capacitance fast enough and the FET will be spending a lot of time in the linear region, producing heat.

These are all really terrible reasons why to pick a 5V AVR over a 3.3V ARM micro.

And the bigger ecosystem applies only if you are speaking about "makers" & Arduino, otherwise AVRs are pretty much dead end and you would be hard pressed to find them in new products. Of course for a beginner this is a valid reason - probably the only valid argument for going with an AVR from the ones you have put forward.

[jiro]

Agreed that you should take a hard look at starting with one of the ARM platforms (NXP and ST seem to be the most popular with hobbyists, followed by TI) through mbed and then move on to whatever IDE you prefer. If you don't mind rolling your own with gcc, gdb, Eclipse/Code::Blocks/whatever, you should do well with any ARM. Otherwise you might want to look at Atollic (supports most vendors) and NXP MCUXpresso (only NXP parts).

As for AVR vs PIC, PIC is the only one with a complete IDE package, but AVR has the better open source support and better free C compilers for low-end parts. Debugging with the ICE is theoretically supported by avarice, but I am not sure how stable that is. Support for the AVR Dragon might be better. If you want an IDE without Java, then you are free to use any IDE (e.g. Code::Blocks) with the open-source AVR tools. So I think it is kind of a toss up depending on your preferences.

I don't mind doing a little manual work to get the stuff working, back in the day I used Code::Blocks to develop a few stuff in my work, but if the environment that provide me with the most rich set of tools is Java, well Java will be.

Actually I'm exited to see that all of the suggested tools supports C, is just a personal matter because it was the first languaje that I used for "real" projects but have been a few years since I used it because now I'm working with python

And the bigger ecosystem applies only if you are speaking about "makers" & Arduino, otherwise AVRs are pretty much dead end and you would be hard pressed to find them in new products. Of course for a beginner this is a valid reason - probably the only valid argument for going with an AVR from the ones you have put forward.

So, what would be a good alternative?

[NorthGuy]

That was true a decade ago. Nowadays people go for ARM based processors and for good reasons: PIC (8 bit) and AVR are archaic architectures and will run out of memory and processing power real quick.

They both are about equally archaic. First PIC appeared in 1976, first ARM in 1981.

[Elf]

So saving 40 cents and buying an 8bit micro is really "a win". The right chip for the job is the one that fulfills your requirements and gives you the best value for buck, especially with the outlook of possible future updates/extensions, not the slowest one you can just cram your application into, with no chance for any future expansion.

Honestly, though, especially for an embedded device, how much future expansion is going to be necessary? Oversize the flash and RAM a bit and, most of the time, the limitation will be the design of the rest of the board. To hear all the anecdotes, one wonders how we ever made electronic products without modern 32-bit ARM chips.

I think that intentionally limiting yourself to a resource constrained platform can be a good way of learning. Having been programming for more than 20 years, I have seen the progression of code developed for chips like the Z80 and 6502 through to the multi-core powerhouses of today. The quality of code that you find and the ingenuity displayed by people has seriously declined, to be replaced by brute force lego-block approaches, executed by programmers who lack even basic fundamentals. There is a time and a place for that when trying to use low skilled people to bring a product to market quickly, but it can be crippling as scale increases. As an example from my day job, when developing SaaS applications, code that runs fast once on your desktop for one user may not be so great when it is being executed concurrently by thousands of users, hundreds of thousands of times a minute.

I am not saying everyone needs to go back to 8 bit chips and assembly, but if you start from a position of free and infinite resources, you will have no practice knowing what to do when you inevitably run out, and no practice knowing how to size your application. Starting with less teaches you how to do more when you have more.

Interestingly I gave my wife an old PIC book I had that is only for assembly, some 16F series chips, and an Olimex PICKIT3 clone. She is an artist that has never written a line of code before in her life, but she is absolutely loving poking bytes around the CPU one at a time, and building little gadgets. When she wants something more and moves on to a bigger microcontroller and C, I will be very confident that she understands what her code is doing.

[Fungus]

So saving 40 cents and buying an 8bit micro is really "a win".

It certainly isn't "a loss", as everybody seems to be implying.

What exactly is the problem with a hobbyist using an AVR chip to create a simple embedded device? I'm not seeing it. 

[Fungus]

Jeeze, and what sort of LED are you trying to drive that it needs 20mA and won't be able to get it from a 3.3V source? Are you trying to drive one of those Cree LEDs directly from the micro?

That'd be one of the colors that needs more than 3.3V, eg. blue, white, green.

[Elf]

What exactly is the problem with a hobbyist using an AVR chip to create a simple embedded device? I'm not seeing it. 

No issue; most hobbyist projects I see would fit very comfortably in an AVR of some sort. Most consumer devices (excluding cellphones / tablets / etc.) would as well. Especially things without USB OTG hosts, IP network connectivity, or large LCD GUI displays, and even those things are possible if you are careful.

I think it is good to be aware of, and to learn ARM and not to be so insular as to only have AVR in your toolkit. But there is nothing wrong with AVR for many applications.

[rstofer]

So, what would be a good alternative?

I like the original LPC1768 based mbed board:
https://developer.mbed.org/platforms/mbed-LPC1768/

If I use the online toolchain, I don't have to install anything.  I use any browser, on any PC, anywhere in the world, to write my code and the toolchain will download the executable to my PC (under Linux, it will probably wind up in the user's Downloads directory).  I can then copy the file to the mbed device which shows up as a mass storage device.  Reboot the board and the new code is up and running.  Simple!

I had never done it with Linux so I just tried it using IceWeasel and Debian.  Works well!

There are some pretty nice libraries, a lot of examples and nothing to install.  The downside is not having realtime debugging.  I use a lot of printf() statements.

This whole JTAG debugging thing is overblown.  If you don't put bugs in your code, you won't have to root them out!

If I wish, I can download my source plus the source for the libraries and use any other compatible toolchain.  I believe I did a 'proof of concept' using Rowley Crossworks but it has been a few years.