MSP430 vs. PIC and AVR - Page 1
Forum section: electronics / general

author: mcovington
author_rank: Regular Contributor
timestamp: December 07, 2019, 11:06:57 pm
content: At risk of starting a religious war... for a small-scale experimenter, how does working the MSP430 compare to the PIC and AVR families, particularly the quality of the free or low-cost development tools? And are there features PICs have that are missing from the MSP430 family that we would miss?

author: brucehoult
author_rank: Super Contributor
timestamp: December 07, 2019, 11:38:47 pm
content: Quote from: mcovington on December 07, 2019, 11:06:57 pmProgramming-wise, the MSP430 is the best of them. 16 registers of 16 bits each, decent addressing modes, good support from gcc. It's definitely the best of them to compile C code to.AVR is decent too. Perhaps better than MSP430 if you're dealing with mostly 8 bit data, and not much with pointers. 32 8 bit registers is the same total size as the MSP430. Loading or storing or doing arithmetic on 16 bit data takes two instructions compared to one on MSP430, but is not too painful. avr-gcc exists and work fairly well, but it's not a mainstream ISA for gcc.PIC is simply awful to program, assuming you don't mean PIC32. The only reason you'd use PIC now is if a chip has exactly the peripherals you want, and your code will be simple.AVR probably has the largest set of available software libraries and examples, because of the enormous Arduino community.Others will no doubt address the hardware considerations :-)

author: wilfred
author_rank: Super Contributor
timestamp: December 07, 2019, 11:48:25 pm
content: There's no chance of starting a religious war on the EEVblog forum when purely technical issues are involved.Unfortunately choice of microcontroller isn't such a topic.I'd say it would be unusual for someone to have tried all 3 in great detail. My gut feel is the PIC is least well served of the three for free tools. The AVR is widely used as a consequence of the Arduino platform. The MSP430 has free compilers from TI available and launchpad boards available fairly cheaply with a built in debugger/programmer.The PIC is a broad range of devices and they vary quite a lot so you need to be a bit specific.I reckon most hobby level people pick one based on what someone else has done that interests them and start from there. Once you've learned one and strike some limitation then you'll be better placed to change. And you'll also have some protection from the zealots who want to promote their personal choice as correct.

author: RoGeorge
author_rank: Super Contributor
timestamp: December 07, 2019, 11:51:47 pm
content: If you look for easy/productive libraries, there is "Arduino" for AVR and "Energia" for MSP430.I don't know about PIC, I left them long time ago because of their messy page swapping, limited stack, limited flash and almost no RAM. Been very happy since then using only AVR and MSP.

author: nctnico
author_rank: Super Contributor
timestamp: December 07, 2019, 11:58:04 pm
content: I'd go for the MSP430. Solid performance, lots of free tools and good documentation. Still if power usage isn't a problem then I'd look at the LPC ARM series from NXP. I find the documentation for these even simpler than for the MSP430 and having 32bit ARM processors running at 10's of MHz you don't run out of speed quickly. In one of my current projects I'm using software floating point just to make things easier to program.

author: NorthGuy
author_rank: Super Contributor
timestamp: December 08, 2019, 12:10:48 am
content: Quote from: brucehoult on December 07, 2019, 11:38:47 pmThis is a viewpoint of a compiler writer which reflects how easy it is to write a C compiler for the CPU.If you don't write a compiler, but write C programs instead, the CPU makes no difference whatsoever. Pick what you like and use it. If you take all these groups together, it is probably 2 to 3 thousand of different part numbers to chose from. They all have different periphery, package, speed, price etc. How can anyone possibly tell what you need.

author: brucehoult
author_rank: Super Contributor
timestamp: December 08, 2019, 12:16:49 am
content: Quote from: nctnico on December 07, 2019, 11:58:04 pmEven on a 16 MHz 8 bit AVR, the software floating point runs at around 100,000 adds, subtracts, or multiplies per second, which is ample for most control purposes. I'd say the very limited RAM bites you more quickly.

author: RoGeorge
author_rank: Super Contributor
timestamp: December 08, 2019, 12:21:05 am
content: MSP430 also has some new gimmick technology, FRAM, it's a RAM that can remember its state without power, like a flash but with the read/write speed of a normal RAM. Didn't used this feature in any of my projects, couldn't find a good use of it yet.The downside is the FRAM will wear out, much slower than the write cycles wears a flash, except FRAM wears for read cycles, too, so FRAM would not have the virtually infinite lifetime of normal RAM.

author: nctnico
author_rank: Super Contributor
timestamp: December 08, 2019, 01:13:07 am
content: Quote from: NorthGuy on December 08, 2019, 12:10:48 amI guess you never wrote C for a processor like a PIC or 8051 where you have to use pragmas to make the compiler put the memory where you want it. The compiler won't be able to figure that out by itself at some point. Also processors without a stack and/or which have seperate memories don't work well with C because you basically have no pointers.

author: mcovington
author_rank: Regular Contributor
timestamp: December 08, 2019, 01:45:48 am
content: Tell us more about the wearout of FRAM. Do all MSP430s use FRAM?

author: RoGeorge
author_rank: Super Contributor
timestamp: December 08, 2019, 01:53:28 am
content: Not all, only the MSP430FRxx line has FRAM technology.TI estimates typical FRAM endurance as 1015cycles, see chapter 2.3 fromhttp://www.ti.com/lit/an/slaa526a/slaa526a.pdf

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 08, 2019, 03:06:48 am
content: FRAM has many orders of magnitude more endurance than EEPROM, and even more orders more than Flash. It's still kinda expensive (compared to the two others), but I've used it (as stand-alone chips) in a couple projects where I needed NV memory lasting over 20 years with frequent writes. In my case, the additional speed was not required, but just makes writing the driver routines a bit easier!

author: NorthGuy
author_rank: Super Contributor
timestamp: December 08, 2019, 03:08:10 am
content: Quote from: nctnico on December 08, 2019, 01:13:07 amMyth. XC8 compiler for PICs implements C99, complete C syntax. Which probably doesn't matter as most people use may be a third of it. I actually tried myself recently, used quite complex data structures with lots of pointers, and it all worked quite well on PIC16, and didn't even take too much resources. And I didn't have to write any extra pragmas.

author: jhpadjustable
author_rank: Frequent Contributor
timestamp: December 08, 2019, 04:21:04 am
content: Quote from: brucehoult on December 07, 2019, 11:38:47 pm8-bit PICs seemed to be one of the first 8-bit MCUs to pick up on the whole self-driving peripheral thing. I don't believe that's a coincidence.4T machines in 2019? Bin it, I say.

author: mcovington
author_rank: Regular Contributor
timestamp: December 08, 2019, 04:28:29 am
content: Having browsed through some literature I must admit I like the simplicity and consistency of the MSP430. There don't seem to be nearly as many registers or devices that require pages to explain their quirks.Dumb question: In the examples I've found, crystals are connected to two pins of the '430 without capacitors to ground. Is that correct?

author: westfw
author_rank: Super Contributor
timestamp: December 08, 2019, 05:04:54 am
content: MSP430 chips tend to be a bit short on RAM compared to similarly sized AVR chips and PICs, especially if you want/need to stick to hobbyist-friendly packages. I'm not sure to what extent FRAM fixes that (well, no FRAM in friendly packages, anyway.)

author: I wanted a rude username
author_rank: Frequent Contributor
timestamp: December 08, 2019, 06:24:30 am
content: Quote from: mcovington on December 08, 2019, 04:28:29 amIt depends on the model, but many MSP430s have programmable load capacitors and are designed not to need external ones. The models that don't may still be able to drive 6 pf crystals without needing external capacitors ... same as a lot of ATmegas.There's a TI application note about it.

author: brucehoult
author_rank: Super Contributor
timestamp: December 08, 2019, 06:59:46 am
content: Quote from: westfw on December 08, 2019, 05:04:54 amOh wow yeah. The best I could quickly find on Digikey is 32k flash, 4k RAM, 16 MHZ for $2.80 qty 1https://www.digikey.com/product-detail/en/texas-instruments/MSP430G2755IDA38/296-41583-5-ND/4090933

author: andersm
author_rank: Super Contributor
timestamp: December 08, 2019, 10:47:17 am
content: Quote from: SiliconWizard on December 08, 2019, 03:06:48 amYes, but as mentioned above, justreadingFRAM counts as a cycle. If your code lives in FRAM, you probably don't want to build it around a polling busy loop.Personally I think AVRs are the easiest to get started with. Free toolchains are available for all operating systems, and programmers are very cheap and simple too. There is also a community that is both active and helpful.

author: Yansi
author_rank: Super Contributor
timestamp: December 08, 2019, 11:51:15 am
content: I can say about the same about STM8, STM32 or any other microcontroller.There is no such universal suggestion, "which one is the best".There may be just a suggestion which one of them is best suited for X. (And even this might be a bit not that definitive).

author: fchk
author_rank: Frequent Contributor
timestamp: December 08, 2019, 12:01:51 pm
content: Quote from: mcovington on December 07, 2019, 11:06:57 pmMSP430 is a nice architecture on paper, but the actual products do have limitations:- RAM: 8k max, with some exceptions.- Peripherials:- No built-in CAN (PIC has, AVR has)- No built-in Ethernet (PIC has)- max 25 MHz (PIC24/dsPIC up to 100 MHz, PIC32 up to 200 or 300 MHz)Microchip offers a lot more cohice of peritherial units, with some very clever ones like CLB (Configurable Logic Blocks).From the performance/$$$ aspect, TIVA TM4C has MUCH more performance for the same price.fchk

author: snarkysparky
author_rank: Frequent Contributor
timestamp: December 08, 2019, 01:58:49 pm
content: I like PIC's. Many don't because of the poor architecture in their 8 bit products. But I cannot understand why anyone would use an 8 bit pic now that PIC24 is present. They are cheaper and come without most of the problems I see mentioned regarding PIC's.

author: andersm
author_rank: Super Contributor
timestamp: December 08, 2019, 02:11:58 pm
content: Quote from: snarkysparky on December 08, 2019, 01:58:49 pmThe 16-bit PICs have their own issues. The Harvard architecture combined with the 3-byte flash word means you have to jump through all kinds of hoops for constant data. And like all 16-bit MCUs they run out of address space, requiring more kludges for memory access.

author: mcovington
author_rank: Regular Contributor
timestamp: December 08, 2019, 02:24:01 pm
content: Quote from: andersm on December 08, 2019, 02:11:58 pmThe bottom line seems to be that there are several different things out there called PIC.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 08, 2019, 04:59:20 pm
content: Quote from: andersm on December 08, 2019, 02:11:58 pmIt's pretty easy to deal with using C (xc16). You just need to know about how flash is accessed (through specifically-qualified pointers). Really not that hard. Sure it makes your code a bit less portable though, but it's really not hard to do.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 08, 2019, 05:03:15 pm
content: Quote from: snarkysparky on December 08, 2019, 01:58:49 pmIt was a bit tricky to use with the banks, but I wouldn't call it poor. The 8-bit PICs were still simple enough that it was possible to write entire firmware in assembly (I sure did), whereas I dare you to do this on more complex architectures, at least in reasonable time. It was thus possible to write code accurate, execution-wise, down to the CPU clock cycle very easily. I would probably not use them these days, but they certainly were very useful at their time and very usable.

author: Kleinstein
author_rank: Super Contributor
timestamp: December 08, 2019, 05:54:09 pm
content: AFAIK there are no MSP430 in a DIP package and with 5 V supply. This may be a difficulty for the very beginning and some low end projects. When using a C compiler one does not see much of the architecture behind it, though there are a few exceptions. Early versions for the small PICs had problems with larger data structures and may still be slow with such. On the AVRs pointers tend to be separate for RAM and Flash with GCC.All three have slightly different periphery with good and bad points in all 3 systems. MSP430 has different ADC available, including higher resolution for a few models.For most small tasks one can use any of the 3 as well as others (e.g. 8051 and STM8). So there is usually not much need to know several of those systems and one tends to favor the one one is familiar with. With the PICs, the PIC10...PIC18 are still somewhat similar, but PIC24 and PIC32 are different things, though some similarity in the periphery.

author: nctnico
author_rank: Super Contributor
timestamp: December 08, 2019, 06:07:14 pm
content: Quote from: NorthGuy on December 08, 2019, 03:08:10 amNow you are hopping from 8 bit to 16 bit which is a entirely different architecture.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 08, 2019, 06:24:27 pm
content: Quote from: nctnico on December 08, 2019, 06:07:14 pmNot at all. He's talking about XC8 and the PIC16 line, which are 8-bit MCUs (I think the very famous and almost first? PIC was the 16C84, which was a "PIC16".)There are a couple "oddities" with the PIC16 line, like the banks, access to code memory (for constants like arrays/strings) and the fact they had a dedicated return stack (which I think is actually a wise design), but most of these oddities are taken care of by the decent C compilers. I used mcc8 (I think it was called that?) back in the day on the 16F452 and a couple others and except for the access to string constants and such, there was really nothing to write home about.)

author: mcovington
author_rank: Regular Contributor
timestamp: December 08, 2019, 06:29:43 pm
content: Quote from: Kleinstein on December 08, 2019, 05:54:09 pmPlenty are in DIP packages (none smaller than 14 pins) but all take a 3-volt supply, not 5-volt.

author: NorthGuy
author_rank: Super Contributor
timestamp: December 08, 2019, 06:56:05 pm
content: Quote from: nctnico on December 08, 2019, 06:07:14 pmPIC16 are 8-bit.dsPIC and PIC24 are 16-bit. Microchip uses GCC for their 16-bit PICs and calls it XC16. They're actually quite advanced. For some reason, 16-bit MCUs (Microchip's and MSP430 alike) didn't get much love from the public.

author: I wanted a rude username
author_rank: Frequent Contributor
timestamp: December 08, 2019, 08:02:20 pm
content: Quote from: NorthGuy on December 08, 2019, 06:56:05 pmPrice may have played a role in that. They were premium parts compared to 8-bitters ... and when the ARM ecosystem arose to eat everyone's lunch, the manufacturers did not repositioning the 16-bitters as mid-range parts with mid-range prices.

author: mcovington
author_rank: Regular Contributor
timestamp: December 08, 2019, 08:24:04 pm
content: I think you're onto something. The main reason I would move from 8-bit to 16-bit is to make it easier to visualize what the C programs are doing. I don't really need the increase in computational power. So they need to be close together in price in order for me to use 16-bit. They're fairly close now, but I don't think that's how they were positioned for a long time.

author: nctnico
author_rank: Super Contributor
timestamp: December 08, 2019, 08:38:19 pm
content: Quote from: mcovington on December 08, 2019, 08:24:04 pmBut you have to be careful with what is 8 bit or not. There are loads of microcontroller out there which have 8 bit registers but 16 bit address registers so all of the memory fits in a singular address space and can have a normal stack. These are fine to program using C. However if you are working with processors which have banked memory then the C compiler will need to work hard to emulate stack and pointers. If you are not careful you can get a serious performance hit. In general you need to write C in a different (ugly) way on processors with banked/seperate memories. This sucks pretty bad if you need to share code between (larger) projects which use normal processor with a singular address space. You need to write the same twice.

author: andersm
author_rank: Super Contributor
timestamp: December 08, 2019, 08:43:26 pm
content: These days, I see little reason why 16-bit general-purpose MCUs even exist. Their niche has been squashed by more capable 8-bit devices on the low end, and cheaper 32-bit devices on the high end. They filled a role before 32-bit microcontrollers became ubiquitous, but today, not so much.

author: nctnico
author_rank: Super Contributor
timestamp: December 08, 2019, 08:46:57 pm
content: AFAIK the MSP430 is still king (or at least one of the better choices) when it comes to low power.

author: josip
author_rank: Regular Contributor
timestamp: December 08, 2019, 08:52:26 pm
content: Quote from: Kleinstein on December 08, 2019, 05:54:09 pmThere is LP for entry level DIP devices (G2 series)...https://www.ti.com/tool/MSP-EXP430G2ETThere are some with 3.3V and optional 5V for port IO, MSP430F5172 for example.Just to note that all devices with CPUvX2 (5xx / 6xx flash family and complete FRAM family) have 20-bit registers and can do 20-bit numeric operations in one CPU cycle. I used this for some 20-bit integer calculations in assembler instead of float.

author: Yansi
author_rank: Super Contributor
timestamp: December 08, 2019, 08:54:53 pm
content: Quote from: nctnico on December 08, 2019, 08:46:57 pmLol, not by any means. I think they are long overcome by a Cortex M0+Took random 430G2 device: 230uA/MHz. Took random low power CM0+ STM32, got 76uA/MHz. With even better sleep modes.Not to mention the increased computational grunt, which may further lead to decrease in consumption.

author: NorthGuy
author_rank: Super Contributor
timestamp: December 08, 2019, 08:57:15 pm
content: Quote from: nctnico on December 08, 2019, 08:38:19 pmMyth again. PIC16s are as 8-bit as it gets. Yet you can use C normally. The compiler takes care of banks and such. Aside of hardware-specific registers and ISRs, you could move the code to any platform, and it would work. When I write in C, I always write to the standard (C99), not to the architecture, and never had any problems with that.

author: Yansi
author_rank: Super Contributor
timestamp: December 08, 2019, 08:59:31 pm
content: Takes care, sure... by inserting dummy (or dumb?) instructions.//yes, that is a rant directed at XC8//

author: nctnico
author_rank: Super Contributor
timestamp: December 08, 2019, 09:16:35 pm
content: Quote from: NorthGuy on December 08, 2019, 08:57:15 pmWell then you have been doing tiny projects. If you would have done larger projects then you'd run into problems with needing to guide banking, slow stacks, slow access to memory. Been there, done that. C isn't designed to work on processors with split memories so the compilers need to pull all sorts of tricks to make it work -somewhat-. Try to use a standard function like strcpy on an 8 bit PIC or an 8051 and look under the hood what kind of mess the compiler needs to create. If it even gets compiled into working code. It gets even more 'fun' if the pointer can be a constant (from rom) or buffer in memory.

author: nctnico
author_rank: Super Contributor
timestamp: December 08, 2019, 09:19:57 pm
content: Quote from: Yansi on December 08, 2019, 08:54:53 pmAre these actual numbers measure by you or just quoted from the datasheet? In case of the latter I'm 100% sure these cannot be achieved in a real scenario. It is ST! Another important factor is wake-up time and power consumed during that.

author: Yansi
author_rank: Super Contributor
timestamp: December 08, 2019, 09:34:36 pm
content: Sorry for you, but the current consumption figures in ST datasheets are pretty accurate and the devices well characterized (likely even better), than those old MSP430. I haven't noticed TI would characterize consumption of peripherals in different modes and voltages separately in MSP430 datasheets, have they?

author: Peabody
author_rank: Super Contributor
timestamp: December 08, 2019, 09:39:43 pm
content: In the modern era (not counting the 6502) I started with MSP430, in assembler no less, and only recently started using AVRs via Arduinos. I really like the MSP430. It's 16-bit, which is a nice middle ground, and vonNeumann architecture, which gives you direct access to everything from anywhere (but not in one clock cycle). But I have to say, as much as I find Harvard AVRs difficult to deal with directly, the Arduino IDE shields you from all of that, so you don't really have to deal with it, or even understand how it actually works. And there's very little fiddling with registers. There is an enormous amount of shared Arduino libraries available to all. I don't think any other processor comes even close to that. On a given day, the Arduino forums will have hundreds of new posts, while the Energia forum has two or three. There are hundreds of modules and development boards available for AVRs at very low cost - lower than the cost of the individual components.As I said, I really like the MSP430. But the Arduino world just overshadows everything else, at least for a hobbiest like me, in terms of what I can get done at very low cost, and in relatively little time.

author: andersm
author_rank: Super Contributor
timestamp: December 08, 2019, 09:41:44 pm
content: Quote from: nctnico on December 08, 2019, 08:46:57 pmLast time I compared data sheet figures, the MSP430 devices were average at best. That was a few years ago, and I haven't heard that TI has managed to dramatically improve their performance since. IIRC SiLabs' EFM32 series posted the best numbers back then, dunno what the situation looks like now.It shouldn't come as a surprise that the competition managed to catch up to, and even surpass TI. There's nothing uniquely power-saving about the MSP430 core, and sleep modes and clock gating features can be implemented by anyone.

author: Howardlong
author_rank: Super Contributor
timestamp: December 08, 2019, 09:43:14 pm
content: Quote from: andersm on December 08, 2019, 02:11:58 pmFor many of the 16 bit PIC24 devices, flash is simply mapped into the upper half of the RAM linear address range. Sure, if you go for more memory, then I agree it's probably a good time to consider 32 bit architectures. I don’t think I’ve ever been in that situation, it’s usually pretty clear up front from a number of design facets.

author: Howardlong
author_rank: Super Contributor
timestamp: December 08, 2019, 09:48:24 pm
content: Quote from: andersm on December 08, 2019, 09:41:44 pmRegarding low power, the answer is almost always “it depends”, it’s a very nuanced thing, and veey application specific. I’ve been pretty disappointed with the EFM32 compared to PIC16 for example in always on LCD applications, in fact I’ve been unable to find anything better than PIC16 for low segment static LCDs. But the tables will be turned in other applications.

author: andersm
author_rank: Super Contributor
timestamp: December 08, 2019, 10:05:15 pm
content: Quote from: Howardlong on December 08, 2019, 09:43:14 pmUsing the PSV area will waste 1/3 of the available flash space, however.

author: coppice
author_rank: Super Contributor
timestamp: December 08, 2019, 10:08:00 pm
content: Quote from: andersm on December 08, 2019, 09:41:44 pmHave you actually implemented a full project with the EFM32? They have a habit of seriously disappointing people deep into their project, when they find a gotcha. Like any other ultra low power platform, whether you are happy will depend a lot on exactly what you are doing.... and perhaps how thoroughly you test.

author: I wanted a rude username
author_rank: Frequent Contributor
timestamp: December 08, 2019, 10:25:48 pm
content: Quote from: Howardlong on December 08, 2019, 09:48:24 pmFunny that this is an application Silicon Labs brag about the EFM32 being good at:5 µAtotalcurrent consumption when running a Sharp memory LCD at 1 Hz.(Normal LCDs obviously draw far more power. The application note didn't make me want to use their microcontroller, but it does contain some good optimisation tricks.)

author: andersm
author_rank: Super Contributor
timestamp: December 08, 2019, 10:30:28 pm
content: Quote from: coppice on December 08, 2019, 10:08:00 pmNo, as I wrote it was only a datasheet survey. But the point was that several manufacturers claimed numbers that were as good as, or better, than what TI claimed for the MSP430 devices.

author: NorthGuy
author_rank: Super Contributor
timestamp: December 08, 2019, 10:34:09 pm
content: Quote from: nctnico on December 08, 2019, 09:16:35 pmNo kidding. There's no way to fit hundred thousand lines of code into a PIC with 4096 words of program memory. What do you think they're designed for?Quote from: nctnico on December 08, 2019, 09:16:35 pmAgain. It is all get compiled into a working code and works, strcpy() including. Compiler takes care of the implementation, so you don't have to.Performance is a different question. As long as it fits and works fast enough to meet your requirements, it's fine. There's no reason to optimize it further.

author: coppice
author_rank: Super Contributor
timestamp: December 09, 2019, 01:16:42 am
content: Quote from: andersm on December 08, 2019, 10:30:28 pmThat might depend on which parameters are important to you, and what is and is not specified. Most of the times I've heard of people not being able to get the EFM32 to perform well in their ULP application they have been caught out by unspecified or poorly specified figures. Various leakages when warm was a big issue early on, although they've probably tamed that by now.Have you looked at the Renesas RL78 family? I've seen people genuinely achieve some pretty impressive real world low energy consumption figures with those, in the sorts of applications where the MSP430 does very well.

author: Howardlong
author_rank: Super Contributor
timestamp: December 09, 2019, 04:36:34 am
content: Quote from: andersm on December 08, 2019, 10:05:15 pmIn a lot of projects IME that isn’t a problem. The complaint was around const arrays, and the alleged difficulty in accessing the data. If your project is already in the 16 bit world anyway, having outgrown the 8 bit world, this is a very worthy and valid solution.There are a lot of solutions that fit in the 4KB-32KB range. I may be an old fart, but people wrote entire floating point Basic interpreters in under 8KB on 8 bitters, back in the days when programmers gave a sh!t ;-)

author: jklasdf
author_rank: Regular Contributor
timestamp: December 09, 2019, 05:39:02 am
content: Quote from: NorthGuy on December 08, 2019, 10:34:09 pmI think the fact that you can program classic 8-bit PICs in standard C99 is more of a testament to the ingenuity of the compiler writers than anything else. C itself has no concept of banked or separate memories, and also the C standard assumes a more advanced stack for function calls than the classic PIC return stack. The fact that people who program classic PICs or the 8051 in C regularly think about whether a function should be reentrant or not, or what address space a variable should be placed in, or whether local variables in functions should actually be automatically allocated or if they can just be statically allocated if non-reentrant functions are ok, all tend to make programming in C more difficult. Now sure if you don't care about performance at all, you can just not use the built-in hardware return stack at all (and make the compiler try to emulate a stack in software), and also rely on the compiler to do bank switching badly and inefficiently, but inherently the classic 8-bit PICs and the 8051 just don't support portable C code at all. As nctnico says, it's definitely not uncommon on large projects -- or projects where you're near the limits of available ram/flash (e.g. NorthGuy's 4096 words of program memory example) -- to have to "guide" the compiler with pragmas about what to do.These are things you would basically never do on a more modern AVR or MSP430 or ARM. I think it's fairly well accepted that architectures like the classic 8-bit PIC and the 8051 were developed to be programmed directly in assembly (for which they're fairly efficient), with little thought given to how C compilers could be implemented, although they do exist. The first reply by bruce hoult I think gives a fairly accurate answer to the original poster's question about development tools, with the MSP 430 having the advantage with the most up-to-date GCC and being a 16-bit architecture (so e.g. you don't have to worry about int promotion when working with uint8_t or int8_t's). The AVR is not far behind with its own, older version of GCC (EDIT: AVR support is present in the latest mainline GCC, although the vendor-provided tools are slightly older) and the disadvantage of being 8 bit. Finally, XC8 for the PIC is arguably by far the worst (sure you *can* program them using standard C, I won't deny that, but most people's expectations about what makes a good C programming environment are higher than just being able to program in standard C at all) and also has a fairly expensive paid version. The IDEs provided with all 3 (the MSP430, PIC, and AVR) all have their detractors (there were a lot of complaints when the PIC and AVR official development tools moved to more "bloated" IDEs), but I wouldn't say that any has a clear advantage over the other.Both the AVR and MSP430 can be programmed in embedded C++ (e.g. no standard library), although it's a whole separate religious debate whether or not you should. The classic PIC can't using XC8. In terms of tools, I would tend to also to also take into account pre-written code/examples and libraries and the existing community (i.e. how likely you are to find an answer to a question just from googling), and the AVR does tend to have the advantage there. Back in the day, the PIC had a lot more mindshare with the PIC16x84 series, since they were some of the first reprogrammable microcontrollers available to hobbyists, but the AVR has become a lot more popular recently with the Arduino.On the 16-bit side of things for the PIC, there's the PIC18/24/dsPIC. The PIC18 is more similar to the classic PICs with banked memory and a return address stack in hardware. The PIC24 and dsPIC are a more modern architecture and supported by XC16, which although also based on GCC, is much older and less free (in both terms of the word free). Whether or not the paid version is low-cost or not depends on your definition of low cost. On the plus side for the PIC24F and dsPIC, they do tend to be available in DIP packages like the MSP 430 if that's important to you. I think the MSP 430 is more popular (probably helped by the more open, free, and modern toolchain, and also the extensive TI marketing about low-power and with their $4.30 development board back in the day). I personally still think of the classic 8-bit PICs when I hear the word PIC, and also when I first read the thread title, although the 16-bit PICs have been around for a while now.On the very high-end, there's the PIC32, which has mostly been killed off by ARM (although it's not as dead as say the AVR32). These do have the advantage of being more-available than ARM microcontrollers in DIP packages, and generally have slightly simpler peripherals (although generally still more complicated than 8 and 16-bit microcontrollers). These were fairly notorious for the very large number of serious silicon bugs at launch (which took a couple of mask revisions to fix), although the newer versions are suppposedly better. The toolchain for the PIC32 is probably the best out of all the PIC toolchains, since it uses an MIPS core. Still, by the time you start considering the PIC32, I think it makes more sense to go directly for ARM microcontrollers if you need the performance or the more-advanced (but difficult to setup) peripherals.

author: andersm
author_rank: Super Contributor
timestamp: December 09, 2019, 06:03:16 am
content: Quote from: coppice on December 09, 2019, 01:16:42 amNo. Also, the one product it's used in at work happens to be a relatively beefy power supply, so low power optimizations weren't really a consideration.There's unfortunately not a lot of scores posted on theEEMBC ULPMarksite, but the MSP430 results fall pretty much smack dab in the middle of the list.

author: andersm
author_rank: Super Contributor
timestamp: December 09, 2019, 06:07:31 am
content: Quote from: Howardlong on December 09, 2019, 04:36:34 amMy experience with PIC24s is limited to trying to optimize string storage and code size for the Bus Pirate, so I freely admit I may have a skewed view on this particular point.

author: andersm
author_rank: Super Contributor
timestamp: December 09, 2019, 06:09:46 am
content: Quote from: jklasdf on December 09, 2019, 05:39:02 amJust to be clear, you're talking about vendor-provided tools here. The avr-gcc I have installed is quite up to date.

author: brucehoult
author_rank: Super Contributor
timestamp: December 09, 2019, 06:50:06 am
content: Quote from: andersm on December 09, 2019, 06:09:46 amOk, where do I get gcc 9 for avr?Not that I care enough to do much work for it. gcc 5.4 is only three years old and hasn't changed all that much. Perhaps the avr support has.

author: george.b
author_rank: Frequent Contributor
timestamp: December 09, 2019, 07:15:15 am
content: Quote from: Peabody on December 08, 2019, 09:39:43 pmI might get some flak for this, but that's what I dislike about the Arduino ecosystem: you don't actually have to understand much of anything, just get this library that someone wrote and you have no idea what it's actually doing. When stuff goes wrong, hit the forums and cry for help, because you can't read datasheets and debug code.I don't think that's very conducive to improving one's skills, and it seems to me that beginners tend to get stuck in need of the Arduino crutch, which might be fine for a hobbyist who just wants to get some project done, but when it starts creeping into professional work/academia, that's when it bothers me.I cut my teeth on PIC, and I like the MSP430.

author: andersm
author_rank: Super Contributor
timestamp: December 09, 2019, 07:16:00 am
content: Quote from: brucehoult on December 09, 2019, 06:50:06 amI installed itvia MacPorts.

author: jklasdf
author_rank: Regular Contributor
timestamp: December 09, 2019, 07:39:10 am
content: Hmm I have to admit I haven't been following AVR-GCC that closely and wasn't aware that AVR made it into mainline GCC. The latest version I've used is 5.4, which at least for my purposes is modern enough, but I'll edit my post.I guess that's another disadvantage of the tools for the 16-bit PICs...in addition to already having to pay quite a bit of money for the "pro" version with optimizations enabled on the official compiler (yes, I'm aware that you can fairly easily modify it to not check for the license). Last I heard, it was extremely unlikely Microchip would ever update XC16 to a newer version of GCC targeted to the PIC.

author: westfw
author_rank: Super Contributor
timestamp: December 09, 2019, 08:42:52 am
content: QuoteYeah, those chips that cost more than $1 are just too rich for my tastes!Arguably, you should forget all about those 8 and 16 bit CPUs, and focus on ARM vs RISC-V.QuoteYou might not want it. People have commented that performance "peaked" in v8, and that may have only been the improved ISR prologue capabilities.https://www.avrfreaks.net/forum/avr-gcc-and-avr-g-are-deprecated-now

author: westfw
author_rank: Super Contributor
timestamp: December 09, 2019, 08:47:50 am
content: (Hmm. You know what one of the best things that "Arduino" did? They realized that beginners would do better with a vastly overpowered chip. 32k, 16MIPs, and C++ libraries written like there were space and cycles to just throw away.(I remember my first order of "assorted AVR chips", which included a couple of ATmega48 chips. You know, in case I needed "a lot" of program space.))

author: andersm
author_rank: Super Contributor
timestamp: December 09, 2019, 09:09:23 am
content: Quote from: jklasdf on December 09, 2019, 07:39:10 amAVR support has been in mainline GCC since the year 2000. I thinkGCC 3.0was the first released version.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: December 09, 2019, 11:24:39 am
content: Quote from: Howardlong on December 08, 2019, 09:43:14 pmI've had the misfortune of working on a few projects driven by a PIC24E -- not coding them personally, just working on the hardware; but I understand from the SW lead, their errata sheets are about as long as the datasheet...They were using C in MPLAB, and I think had resolved most of the low-level issues by the time I saw some code over their shoulders.I suppose it should be no surprise that 24-bit machines are few and far between, and the ones that do exist are quirky bastards like the "PIC16 plus" of this case.I think 16-bit machines are more of an historical anachronism; 8-bit too, to a lesser extent. All the applications that were filled by them in former years, have been more than displaced by 32-bit and higher. Consider the 80s PC or 90s game console sporting a 8086 or 68k; those quickly evolved to 32-bit machines, i386, MIPS, PPC and so on; which evolved further to AMD64, ARM64 and so on. No one "uses" a 16-bit PC anymore, there's just no point (kudos to you few dedicated retrocompers that force your old PCs to access the internet, and other such abominations).The simplest embedded applications remain with 8051 and such (and for huge quantity, even some 4-bit machines), with PIC, STM8 and AVR (in that order?) being common. AVR I don't think is very popular commercially due to its cost, but its usability and support make it popular at lower quantities (where its cost isn't as big of an issue). I've seen AVR a few times myself, which makes sense as I've mostly worked on smaller quantity products (~1k/yr).The next tier up for embedded, is simply 32-bit. ARM is so cheap, there's hardly any point in using anything else. STM32 is very popular indeed for low and high quantity production.Worth noting that AVR is powerful enough that it can do most tasks that would've otherwise used 16-bit machines. There isn't much advantage there. And if you need more power, you're likely to be very limited by a 16-bit machine, and need the greater width as well as speed that a 32-bit machine offers. Sure, you could spend weeks, years optimizing your code, but the 32-bit chip is probably cheaper besides.Probably, most places that use others, do so for historical reasons, i.e. they've been using them since before ARM got popular? I know a house that use MSP430, it's not at all rare, just less common.And then the next step up from that, you have DSPs, application processors, GPUs and related stuff. Differentiated by purpose, of course, with DSP being more towards the hardware embedded side, and app and GPU being towards the software and user side. Cellphones being the best example, and being dominated by ARM and ARM64. Honorable mention to TMS320 (again, more historical?), Blackfin, PPC and so on.RISC-V is interesting in its rising popularity; I will be surprised if it competes with ARM, but it may prove to be a contender for the mid tier markets.Tim

author: brucehoult
author_rank: Super Contributor
timestamp: December 09, 2019, 12:34:04 pm
content: Quote from: T3sl4co1l on December 09, 2019, 11:24:39 amI don't think ARM is in any immediate danger :-) They and their partners make good stuff and it's very entrenched. I was astounded by their mid-2018 short lived FUD site against RISC-V.MIPS, Extensa, ARC, and anything a company developed in-house on the other hand ...I was interested to note in the program for day 2 of the RISC-V Summit on Wednesday there will be a panel discussion including Tim Whitfield "VP Strategy Embedded and Automotive at ARM".

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 09, 2019, 02:44:19 pm
content: Quote from: andersm on December 08, 2019, 08:43:26 pmWell, that may be true today, but a decade ago or so, that wasn't, so they had a place. At that time, 8-bitters were often still underpowered for some tasks, and the 32-bitters, either too expensive, too quirky, or would draw too much power for some applications. Admittedly this has completely changed, and whereas I've used Microchip 16-bit MCUs a lot in the past decade, I haven't in like over two years now. But I'm not saying I'm dead sure I won't use a 16-bitter anymore.Performance and power consumption aside, there can still be reasons to go for a 16-bit MCU: they are often much simpler, architecture-wise, than the 32-bit ones, which in itself can be a design choice, and they can still be more powerful than the 8-bitters, even modern ones.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 09, 2019, 02:56:09 pm
content: Quote from: nctnico on December 08, 2019, 08:46:57 pmIt's still good all in all for that, but certainly not "king" anymore. It used to be a pretty good, if even sometimes the only sensible choice for very low-power designs, but we've been having ARM Cortex-based MCUs that do better, sometimes by a large margin, for a few years now.The STM32L4 line comes to mind; I've used it quite a bit. Some even allow the use of an external buck converter for Vcore, and you can get as low as ~35µA/MHz. Deep sleep current is also pretty good.There are quite a few others. Some ATSAM do well also. The RF SOCs from TI such as the CC2640(I think?). The RSL10 from On-semi. Ambiq Apollo MCUs that are quite impressive too (I mentioned them earlier). Absolutely not exhaustive...Of course, other considerations than pure performance are also to be taken into account depending on your application. AFAIK, TI is relatively easy to work with (and allows!) for using their parts in medical devices (some vendors clearly position themselves against it). ST is interested in this market, but they are still not as easy to work with for this if you need related docs from them. On-Semi, they are, I think, the best to work with for this IME. They have very good dedicated support teams. OTOH, Linear/AD is a lot more difficult regarding this.

author: coppice
author_rank: Super Contributor
timestamp: December 09, 2019, 04:27:28 pm
content: Quote from: brucehoult on December 09, 2019, 12:34:04 pmI wonder if RISC/V has started to have any impact on those conversations with potential customers that go something like"We've got a part with exactly the features you need, great power numbers, and ease of use, all at a really good price.""Is it ARM based?""No, but it uses a very well supported core with free tools.""Nice talking to you, bye."

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 09, 2019, 04:57:44 pm
content: Quote from: coppice on December 09, 2019, 04:27:28 pmWell, the typical discussion you describe probably happens with the big companies, and will for the foreseeable future. But for the smaller ones, I'm not sure. I guess it would really depend on the end-application and market.For a very "niche" or at least very custom SOC, I for one would definitely consider a RISC-V core these days instead of blindly going to ARM.One thing I would still be concerned about is validation. But if the company selling RISC-V cores can give me all documents/tools I need for the validation part, then I'd definitely consider it.

author: NorthGuy
author_rank: Super Contributor
timestamp: December 09, 2019, 05:10:31 pm
content: Quote from: brucehoult on December 09, 2019, 12:34:04 pmIf Huawei moves to develop a RISC-V based chip for their phones, it will be a huge blow for ARM.

author: jklasdf
author_rank: Regular Contributor
timestamp: December 09, 2019, 05:43:02 pm
content: I do generally agree...might as well go ARM nowadays, especially for commercial projects (or really any long-lived project where requirements change, new features are added/demanded, and complexity starts to grow), but the original question was about the MSP430 vs PIC vs AVR for "small-scale" experimenters. There is definitely more of a learning curve when using ARM parts (which even after the initial learning curve, that you pay for with every new part/peripheral/function you end up using), although the extra complexity is often worth it.Hobbyists do generally care more about simplicity. Just see for example the popularity of the Arduino or the thread on the eevblog video about just setting up the usupply dev tools (which to be fair isn't the simplest setup compared to just using the vendor tools). Hobbyists doing simple things tend to care more about how difficult it is to use the peripherals without a HAL, 5V compatibility (and not just 5V tolerance...although for new designs, might as well just use 3.3V or lower for everything), and DIP packages. There are a ton of breakout boards and small dev boards, though, including those that are the size of a standard DIP-40 package. Also larger pin-pitch parts down to around 0.8mm are fairly hand-solderable with the right footprint -- even without reflow soldering.But still, everything combined does add up for hobbyist use. Things that you can do on say a 32K AVR (assuming you aren't running into peripheral/memory/processing limitations), will generally be much easier than on any ARM part.