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.

[janoc]

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

Have you actually tried it? Because if you did, you wouldn't write this.

Common green LED has Vf around 2V. Even blue LEDs work just fine from 3.3V supply.

This video hopefully proves that you can certainly drive a blue (and thus likely white LED too as they have the same Vf) and green LEDs from a 3.3V micro:


Heck, many white and blue LEDs work from 3V lithium coin cells.
https://youtu.be/YgHmks7PoQo?t=17

And you can always make the I/O pin sink current and connect the anode of the LED to a higher voltage if the voltage of the logic one on the pin is not enough for the LED to turn on. But that's really a very basic thing.

Of course, I am not going to claim that all LEDs are made equal, but you can certainly find enough LED types that will work.

[rolycat]

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.

'Archaic' means antiquated or primitive, not just of a certain age.

In any case, the first ARM processor was created in 1985, not 1981 - almost ten years after the first PIC.

[rstofer]

You can get a feel for the variety of boards that work using the 'mbed' concept of an online toolchain by looking here:
https://developer.mbed.org/platforms/

To use the toolchain, you have to actually buy a board and use the .htm file on the board to register the device.  No cost but still there is a registration hoop to jump through.

8 bit PICs like the 16F family are often a good solution but they have a truly ugly architecture.  They are a PITA to program with assembly language and C compilers spend most of the code creation dealing with banking and paging.  Until recently, there simply weren't any decent compilers because the chips were too limited to handle the language.  An 8 level (fixed) stack is not encouraging.  I don't know what compilers are doing for this family at the moment, I walked away years ago.

On the subject of AVR, if you want to use AVRs, you might as well use Arduinos and there is a ton of example code and libraries available.  Everything that can possibly be done with an Arduino has been done and the program is out there for downloading.  In my  view, it is absolutely the fastest way to get started with microcontrollers.  The Mega 2560 is a pretty powerful board but the standard Arduino Uno is quite capable and pretty much the benchmark device.  You can also design an ATmega 328p project using the Arduino board as a programming platform and then plugging the DIP chip into some other board.

ARM is where all the new work is being done.  There are several flavors with advancing capabilities but the more modern Cortex Mx devices are easy to program (in the sense that assembly code is no longer required) but can quickly get to be overwhelming with their peripherals or the provided HAL libraries.  I have a hard time getting up the enthusiasm to use these libraries because instead of writing the code I want, I wind up having to understand the code I got (including interactions with everything else on the chip).  I'm just not a fan of the abstractions.

That said, I am happy enough to use the mbed library (adding my own interrupt handlers) and the provided TCP/IP stack.  I certainly don't want to recreate those but for a somewhat smaller project, I would prefer to start at the iron and work up with my own code.  Like I used to do with the LPC2106 and LPC2148.  Writing code right down in the dirt.

Alas, the more modern chips are probably sufficiently complex that it doesn't make sense to work at that level.

Summary:  I would start microcontrollers with Arduino projects.  I would progress to the LPC1768 mbed and if I needed more, I would look at some of the STM offerings.  One way or the other, you have to start somewhere.

[Fungus]

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.

FWIW I used to program ARM in assembly language back in the 1980s. 

[Fungus]

I have a hard time getting up the enthusiasm to use ARM libraries because instead of writing the code I want, I wind up having to understand the code I got (including interactions with everything else on the chip).  I'm just not a fan of the abstractions.

Yep. I also have a lack of enthusiasm for them. They don't fit anything I do.

For basic uC work I already have something that gets the job done at a throwaway price (ATMega328 chips on $2 boards).

I know how to optimize code, I've written arcade-perfect Space-Invaders (with sampled sounds) on a Mega328, I've written Tiny85 raytracers for fun. If I need more than a Mega328 I always need a LOT more, eg. video output or WiFi or something like that, things those little ARM modules don't offer.

[Elf]

Teaching Grandma to suck eggs?

I used to program ARM in assembly language back in the 1980s. 

Good for you? I was trying to support your point, and was addressing the people who seem to think that ARM (PSoC, whatever) is the only legitimate solution to any problem. I assumed that this would be clear from the context of my previous posts.

[Fungus]

I was trying to support your point, and was addressing the people who seem to think that ARM (PSoC, whatever) is the only legitimate solution to any problem.

I know, but you also implied I only have AVR in my toolkit.

(or maybe you meant the world in general and I misunderstood)

[Elf]

I know, but you also implied I only have AVR in my toolkit.

(or maybe you meant the world in general and I misunderstood)

No, just that for a beginner I would recommend that they also learn ARM, and not just AVR if that is their main choice. Really, whatever your personal preference is (as in, anyone, not you specifically), I think it is good to learn and regularly use at least a few different types of platforms.

[colorado.rob]

happened here??

No one cares what your favorite microcontroller is.

The question is what meets the OP's needs.

BTW, there are other forums better suited for this sort of question than the "Test Equipment" forum.  We've got a forum dedicated to microcontroller questions.

[nctnico]

and was addressing the people who seem to think that ARM (PSoC, whatever) is the only legitimate solution to any problem.

Nobody is claiming that but with ARM you have the widest choice in vendors, microcontroller complexity, lots of speed, low power if you want, it is a 32 bit architecture, it is fast, etc, etc so it is a very good choice to use ARM especially if you start. Almost any other choice will you hold you back in some way.

[Elf]

No one cares what your favorite microcontroller is.

The question is what meets the OP's needs.

Unfortunately I think when you have <Product A> vs. <Product B> anywhere in the title it sort of degenerates to this; Ford vs. Chevy, etc.

As far as the original question goes, I think AVR has a good toolchain available under Linux:

• Eclipse IDE, and the AVR plugin for Eclipse IDE
• C library
• GCC cross-compilers, assembler, and linker from Atmel
• AVRDUDE programming software
• In Circuit Programmer from 3rd parties

While there are tools for PIC available, I wouldn't call the 8-bit PIC lineup very C friendly.

[alm]

You conveniently left out debugging . I think debugging is the weak point for AVR, both hardware and software. For hardware you can get the bare board for $50 or the more usable one with case for $100. Both PIC and STM32 have more affordable tools (especially STM32 with a $10 bare board and $20 with case and proper buffers). As for software, avarice works but development does not seem very active (last commit > 1 year ago, never mind the last release). Also support for currently available debuggers seems limited.

[rstofer]

No one cares what your favorite microcontroller is.

The question is what meets the OP's needs.

Unfortunately I think when you have <Product A> vs. <Product B> anywhere in the title it sort of degenerates to this; Ford vs. Chevy, etc.

As far as the original question goes, I think AVR has a good toolchain available under Linux:

• Eclipse IDE, and the AVR plugin for Eclipse IDE
• C library
• GCC cross-compilers, assembler, and linker from Atmel
• AVRDUDE programming software
• In Circuit Programmer from 3rd parties

While there are tools for PIC available, I wouldn't call the 8-bit PIC lineup very C friendly.

The ATmega128 used to be one of my favorite chips.  I used exactly the toolchain above on Linux.  I really LIKED writing code for that chip.  It's an old chip by today's standards but it is fun to work with.

It does require makefiles and 'make' but even that is fairly easy.  Once you have one Makefile, you pretty much have them all for a given architecture.

I didn't find that Eclipse brought all that much to the dance and would often just use 'gedit' and 'make'.  I don't mind messing around at the command line.  It's important to remember that this was more than 10 years ago and Eclipse has improved greatly.  For my PC Fortran coding, it even creates the makefiles.  It may do that for C projects as well but I haven't done a lot of that in recent years.

No, I didn't use 'vi' or 'emacs'...

[NorthGuy]

'Archaic' means antiquated or primitive, not just of a certain age.

How PICs can be antiquated when new models are released almost every month?

[rolycat]

'Archaic' means antiquated or primitive, not just of a certain age.

How PICs can be antiquated when new models are released almost every month?

In the message to which you responded, nctnico stated that 8 bit PIC was an archaic architecture.

Putting lipstick on a pig does not make it less of a pig.

[NorthGuy]

'Archaic' means antiquated or primitive, not just of a certain age.

How PICs can be antiquated when new models are released almost every month?

In the message to which you responded, nctnico stated that 8 bit PIC was an archaic architecture.

I'm sure he meant "old", not "antiquated". Microchip still makes and sells lots of PIC16s. They're still the best for the tasks they're designed for - low cost, power, space. And new models are substantially better than what they had 10 years ago.

Of course, there are lots of people who prefer blinking their LEDs with ARM rather than with PIC, but this has nothing to do with architecture.

[igendel]

Putting lipstick on a pig does not make it less of a pig.

Core Independent lipstick, please! 

Seriously though, these trash-throwing discussions on MCUs are getting tiresome. Can't we all just... get along? 

[stj]

the stuff is so cheap, just buy it all!

a USBasp is about $2
an atmega328 on a pcb is about the same,

an stm32f103 on a pcb is about $2,
a chinese stlink is about $2

just get it all and have enough change from your 10-bill to get a bottle of beer! 

[JPortici]

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.

I disagree on XC16.

No optimization is crap, granted, but O1 is so much better, and included in free version.

To get the most out of the chip one should read the compiler manual...

for example, if you want to use the hardware divider you have to use the __builtin functions (or ASM)
This is because the hardware divider is 32/16 bit and cannot detect 16 bit overflows so the compiler will always use a software algorythm. If you are sure you will have a 16 bit result just use __builtin

Same for DSP instructions, and other things you would otherwise write in assembly

[JPortici]

Re: 8 bit is archaic, that's mostly true. I have to re-do a wireless remote that used a 16f... and this time i'm going to use the lowest power arm chip i can get (or a pic24/pic32mm)

Oh, the headaches...

[Karel]

Some people seem to believe that the "free" version of the Microchip C-compiler doesn't support all optimizations.
This is not necessarily true. It's what Microchip wants you to believe.
The C-compiler "from Microchip" is actually a copy of GCC (GNU C compiler). Because GCC is opensource (GPL) and
because Microchip can not claim any rights on GCC, it's very easy to disactivate the artificial limitations built-in in GCC
by Microchip. It takes just 5 minutes of your time. No need to reverse engineer any proprietary code or to break any law.
Ofcourse, Microchip will never tell you this...

Edit: Here's the link to a post how to do it: https://www.eevblog.com/forum/microcontrollers/pic32-evolution/msg1007099/#msg1007099

[alm]

That only applies to the 16-bit and 32-bit compiler. The 8-bit compiler shipped by Microchip (XC8) is proprietary, and as far as I know there is no legal version that is free and includes full optimization support.

[JPortici]

The most you can optimize is avoiding continous bank switching... unfortunstely there isn't much you can do with the compiler. The best tricks are done manually (see the piclist.com code archive... tons of goodies and tricks)

But at least the core independent lipstick makes it so you can offload most of the workload (and they seems to be making a great effort to cripple the peripherals with MCC)

This applies to pic12/16. XC8 for pic18 has its strangeness (like weird macro to put data in eeprom, builtin functions commented OUT. Not even a warning, but in the source code you see the goddamn comments that says function was deprecated, have the very same one with MCC plus the additional bloat )
But generated code is ok, i guess. I never have to use assembly on a pic18

[Karel]

That only applies to the 16-bit and 32-bit compiler. The 8-bit compiler shipped by Microchip (XC8) is proprietary, and as far as I know there is no legal version that is free and includes full optimization support.

You are right. I tend to forget that because we don't use 8-bit mcu's and only very occasionally 16-bit.

For hobby use, what is the reason to stick with 8-bit mcu's?

[NorthGuy]

For hobby use, what is the reason to stick with 8-bit mcu's?

It depends a great deal what you want to get from your hobby.

[igendel]

For hobby use, what is the reason to stick with 8-bit mcu's?

Kind of like asking, why do woodwork as a hobby if you can build with metal? Metal is stronger, lighter, usually more resilient, not to mention shiny!

[Fungus]

For hobby use, what is the reason to stick with 8-bit mcu's?

Why would you even care how many bits it has?

The only question is: Does it do the job? 

[JPortici]

That only applies to the 16-bit and 32-bit compiler. The 8-bit compiler shipped by Microchip (XC8) is proprietary, and as far as I know there is no legal version that is free and includes full optimization support.

You are right. I tend to forget that because we don't use 8-bit mcu's and only very occasionally 16-bit.

For hobby use, what is the reason to stick with 8-bit mcu's?

price, voltage levels, being able to do simple things with simple components...

Fun fact, the new pic18f25k42 is a beast. 12 bit adc (at least 11 enob), dma and vectored interrupt. Can do a lot of work even on commercial products.

Still, we get asked the 'bit' of our processors from time to time. We stir around the question because of course this is either a forum guy that doesn't understand shit and will smear us on forums... or more plausible, one of our competitors which claims 64 bit processing! That will smear us on forums

[rstofer]

For hobby use, what is the reason to stick with 8-bit mcu's?

Kind of like asking, why do woodwork as a hobby if you can build with metal? Metal is stronger, lighter, usually more resilient, not to mention shiny!

Because it is hard to get a decent Mission Oak finish.

[jiro]

I see that the microcontroller world have the same discussions as the programing "which languaje is the best" and it seems the answer is basically the same I say "depends on your needs or preferences". So I guess that is better to have options to decide which one suits better for a particular problem.

When I was looking in google for some additional information about what you posted here I found some guy's post who repaired a washing machine using a pic12XXX, the program was in assembly but it basically was "if this button is pushed do this, if that button is pushed do thar for this period of time, then this" . Why would you need a very complex micro for that?

In the other hand I love to see that there are toolchains that allows me to use stuff that I'm very familiar with (gcc, gdb...). I'm goint to play with Arduino (since it have a very nice support) and a few ARM based boads.

In the long run I'd like to get into IoT stuff , jut to play with..you know, turn on a led from the cloud 

[rstofer]

When I was looking in google for some additional information about what you posted here I found some guy's post who repaired a washing machine using a pic12XXX, the program was in assembly but it basically was "if this button is pushed do this, if that button is pushed do thar for this period of time, then this" . Why would you need a very complex micro for that?

You don't and a manufacturer wouldn't.  But that's an entirely different question than "which device should I play with?".  For one thing, the washing machine application, throughout the manufacturing life of the particular machine, isn't likely to change.  There won't be any 'feature creep'!

For a play toy, the answers will be different because there is no way of telling where a new user might want to go.  Sure they can play with a 6 pin PIC but they're going to run out of pins very quick.  If they want to write code in C, they probably don't want to use a PIC 16F.  If they want speed, they want to move to ARM.  If they want a bunch of canned projects, ready to go, they probably want to think about Arduino.

So, the right choice is difficult, if not impossible and, over time, all devices will get their turn.

[NorthGuy]

So, the right choice is difficult, if not impossible and, over time, all devices will get their turn.

I don't think the choices of things for hobby is difficult. Actually, the process of choosing is already part of the hobby, and a very interesting one. However, choices are different for different people. Therefore, it is impossible to give (or receive) a useful advice which would fit anyone. Everyone is different and is entitled to his own choices. But people trying to give advise try to suggest things which they would have chosen for themselves. This makes the whole conversation look incredibly complicated, but it's really very simple.

[nctnico]

So, the right choice is difficult, if not impossible and, over time, all devices will get their turn.

I don't think the choices of things for hobby is difficult. Actually, the process of choosing is already part of the hobby, and a very interesting one. However, choices are different for different people. Therefore, it is impossible to give (or receive) a useful advice which would fit anyone. Everyone is different and is entitled to his own choices. But people trying to give advise try to suggest things which they would have chosen for themselves.

Or not. One of the mistakes I made was messing with 8051s for way too long and spending more time on getting around the limitations of the architecture than getting my gadget going. Also if I would have access to microcontrollers with an ARM core at that time I would have been completely over the moon.

[jiro]

Hi guys,

I guess that as my small contribution I should explain my process to decide what yo use and why so if anyone is up to a similar situation this could help, first at all most of the decition are based in personal convenience rather than the technical.

My first requirement was that the linux availavility of the toolchain, because as I mentioned in the original post most of my computers have Linux installed (Arch and Manjaro if you are curious), my first mistake was limit to Pic and Atmel because they are the most pospular (as pointed by ... here)

Then my second requirement was the language, since I basically don't have any experience with microcontrollers I wanted at least a known languaje (I could do some assembly code, but I'd rather not to) I use python in a daily basis along with bash and yaml (Ansible for automating stuff)  but uC for MifroPython seems to be a little expensive at the moment I'd rather to use C or some C based language (just because I already knew C), but then when I read a little more it was obvious to me that C is one of the stardard.

As you can imagine by now, none of those "filters" woth anything, because all mayor microcontrollers in the industry have (at least) nice support for linux. So, the next I couls think of was the price, but the difference are not that much at least not for hobby/start/messing around, jujst check the pirces in Ebay, Amazon or Ali Express. So I choose the wrong criteria  .

Also I got some other recommendations (as mentioned here) there are a lot of ARM based solutions that can do the job, they are a little more expensive, but you get more processing power . I'm waiting for my STM32F103 to arrive (thanks janoc for the suggestion) .

At the end I decided based on the calculation power (ARM) because I want to play with some AI and IoT, but I'm goint to start with arduino because of the community, documentation available and it have a lot of prebuilt modules (since I'm a beginner in electronics), at the long run I plan to do some of my own modules and go deeper, hopefully be able to design some simple gadgets/toys for me. That's my starting point from there I'll see what else I need in the future like lower power consumption, more calculation power or less if no need.

Well, that's my little contribution, not that much, but I hope somebody can benefit from this.

[thermistor-guy]

"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'm a big fan of Linux, but on most of my Linux PCs, I also run Win7 as a guest OS under Virtualbox. That allows me to run development tools on the host OS (Linux) or on the guest OS, as needed.

On machines that are Windows-native, I usually install Cygwin, to get access to GNU tools. Of course, you can also install Virtualbox on a Windows host, and run Linux as a guest OS, but I haven't needed to do that.

My point: even though you prefer Linux, you can still use Windows-based toolsets.

[jiro]

My point: even though you prefer Linux, you can still use Windows-based toolsets.

Yes, I know, but I'd rather to use native tools as much as I can even when that implies a little more work (I already have a VM with Win7 to do some testing of other stuff)

[stj]

i do stuff with both in Linux - and not using wine.

for pic, use MPLAB-X,

for AVR use GCC and AVRdude.
if you cant be bothered setting up the avr toolchain manually, just install the Arduino-IDE.
that contains all the bits in one archive - as a bonus it can also handle ARM chips.

[MattSR]

One thing I have struggled with is finding instructions to set up the AVR-GCC toolchain - can you describe it or point me in the direction of a good tutorial?

[rstofer]

For Windows - Google WinAVR

For Linux - most distros have AVR-GCC as a package

If you want to build from source: http://www.nongnu.org/avr-libc/user-manual/install_tools.html

I don't know how current that process is but I used it years ago.

I haven't looked but I suspect the Arduino toolchain contains most of what you can get with AVR-GCC except perhaps OpenOCD or some other JTAG support for debugging

Or you can install Atmel's toolchain.

[jiro]

One thing I have struggled with is finding instructions to set up the AVR-GCC toolchain - can you describe it or point me in the direction of a good tutorial?

I don't know what distro you are using, but in Arch/Manjaro there are a few packages for AVR:



The coimpiler, debugger, Avrdude (to copy the compiled files to the uC) since those are in the official repositories they must be available in any .deb based distro (Debian, *buntu, mint...)

[stj]

exactly, if you download GCC for your chip, the package manager should select the rest of the toolchain.

[jaromir]

For 8-bitters from Microchip I use SDCC/GPutils + my own programmer https://github.com/jaromir-sukuba/a-p-prog (actually it's derivative of this programmer running on PIC MCU, I recreated it on Arduino to be more accessible for other people). All components are open sourced.

SDCC is actually useful compiler, I use it for STM8 and 68HC08 chips too.