PIC16F1783 - great chip for PSU makers

[nctnico]

For ARM controllers you use GCC and Eclipse. Both available for free and excellent.

With Freescale you should watch out for availability of affordable programming tools. I've been down the Freescale road before with a Coldfire controller and got stuck on having to spend major $$$ on a programmer for any serious work. With the NXP parts you can use a simple circuit and program from an RS232 port or just hook up about any USB to serial converter chip. Newer parts with a USB bootloader can act as a USB stick so you can drag & drop new firmware using Windows explorer. No need to mess around with JTAG dongles and complicated software even if you choose not to use the vendor provided IDE (which usually is crap compared to Eclipse).

[poorchava]

It is true, that ARM controllers are dirt cheap for their computing power and availability of software development tools.

But you simply cannot do some things without stuff like hardware deadtime generators, synchronized PWMs and the like. Sometimes you simply cannot beat a dedicated solution with an all-round cheap and powerful solution.

On the other hand given the Microchip's reputation I wouldn't be surprised if half of the dedicated SMPS stuff didn't actually work.

And for high reliability solutions: I'm working in automotive industry, I have taken part in development of hefty number of control units and also disassembled many of competitors' devices and never saw a single ARM controller . We tend to use Freescale or Fujitsu when 32-bit processor is needed, and those are PowerPC .

A can see another 'which MCU is best' flamewar coming

[nctnico]

But you simply cannot do some things without stuff like hardware deadtime generators, synchronized PWMs and the like. Sometimes you simply cannot beat a dedicated solution with an all-round cheap and powerful solution.

Actually lots of (ARM) microcontrollers can be used to create a 3 or 4 phase PWM (motor) controller. Dead time is just a matter of software. But then again if no further intelligence is needed a dedicated PWM chip is cheaper.

And for high reliability solutions: I'm working in automotive industry, I have taken part in development of hefty number of control units and also disassembled many of competitors' devices and never saw a single ARM controller . We tend to use Freescale or Fujitsu when 32-bit processor is needed, and those are PowerPC .

My guess is that that has more to do with the automotive world being conservative or the vendors have a succesfull lock-in with their tools. The whole world already buried the PPC architecture years ago. OTOH there are not many automotive ARM devices because the market for consumer and industrial devices is big enough. ST which has a strong automotive background offers several ARM based microcontrollers in the automotive temperature range though.

[jerry507]

nctnico has quite a long track record of evangelism for his brand. Meanwhile there are far more people using Keil and IAR for programming arm than using Eclipse and GCC straight up. Not to mention that most of the free vendor tools are Eclipse now.......

Working on ARM projects right now, I'm not really sold on their awesomeness over any other solution. They tend to be significantly more powerful which makes them great for many more applications now. But it's a PSU, don't need an arm. Choosing an arm comes with trade offs and they're not a panacea.

Picking an arm vendor is personal preference. They all have pro's and con's. Some people just can't see that though.

[nctnico]

nctnico has quite a long track record of evangelism for his brand.

Now you make it sound like I never used anything else than ARM but that is very far from the truth. Over the past decades I have tried and used many microcontrollers. The processing power an ARM offers opened many new possibilities for me like audio processing without tedious DSP assembly. And not to mention there is enough processing power to do stuff in software that was traditionally done in hardware. That has allowed me to come up with several very neat solutions.

Meanwhile there are far more people using Keil and IAR for programming arm than using Eclipse and GCC straight up.

I have used Keil's and IAR's IDEs in the past but I didn't find them very usefull. The editor is minimalistic and things like subversion support are missing. Maybe they have improved in the meanwhile. Anyway, the people and companies ( http://www.eclipse.org/membership/showAllMembers.php ) behind Eclipse have put their heads together to make the best universal IDE with as many usefull features as possible for developing software so programmers only need to learn one IDE. There is a learning curve but the reward is that you (almost) never need to learn another IDE and never miss out on a feature. I have been using Eclipse exclusively for all the software I write for about 8 years now.

[jerry507]

Right, I actually agree 100% with you. If I had the time to learn and set all this up, it'd be well worth the effort. The advantages of Keil and IAR is that they just work, which is what you're paying for. The vendor IDEs are free and should just work, but they're piles of crap. Eclipse/GCC are free, very powerful but require work to start up. Those are the basic tradeoffs of money and time.

Just fyi, Keil and IAR work just fine with revision control, because you just use Tortoise or whatnot Works just fine.

ARM is fine, but you can't blind yourself to the very high barriers to entry. They're easy to forget once you're past them. They're also not the worlds lowest power either, and often are lacking more analog-y peripherals. Bottom line is there are still many valid reasons to use something else in place of an ARM.

We agree far more than we disagree on this, and it's just how we're conveying our positions that leads to the apparent gap.

[Christe4nM]

Personally I don't think that the specifications mentioned in the first post are too special. When looking at Farnell, I can easily find a cheaper ARM Cortex-M MCU with at least similar specs. If you would take the time to investigate I'm positive there is one that has very similar peripherals as the PIC mentioned by the OP + a whole lot of extra's (Quick search example: STM32F1xx)

Right now if I needed to choose a generic MCU for a project I would hardly look any further than ARM Cortex-M. The range is so very wide now that there is always one that fits your bill, and prices can be just as low, or even lower than a 16b equivalent one. With NXP getting into very cheap 8 pin MCU's they are even becoming 'glue logic'. The only headache is to find the right one in a maze of many many Cortex-M MCU's that seem almost similar, but can be very different under the hood, even within a single family.

I'm relatively new to MCU's, and have no history with the 8b or 16b generations. Even though I read some saying that a 32b is killing a bug with a platoon of tanks, that platoon of tanks nowadays is cheaper than the good old slingshot. Moreover, from what I'm taught, the Cortex-M cannot be thought about in the classical way of 16b or 32b. The way it handles instructions is actually a combination of both 16b and 32b instructions in an efficiently managed way. Add the many power modes and energy management becomes more efficient too. Think of it as running instructions for a much shorter time and thus sleeping longer in an application where a 16b would take more time to process instructions and thus sleep shorter.

Just my 2 (Euro)cents.

[ptricks]

Personally I don't think that the specifications mentioned in the first post are too special. When looking at Farnell, I can easily find a cheaper ARM Cortex-M MCU with at least similar specs. If you would take the time to investigate I'm positive there is one that has very similar peripherals as the PIC mentioned by the OP + a whole lot of extra's (Quick search example: STM32F1xx)

They are not the same chips. The ARM listed above is what I call a kitchen sink processor because they throw everything they can into it in the hopes that more will be better, but it actually can hurt a project designed around the part. Notice it includes things like HDMI CEC, something a PSU designer is not going to be interested in using. A user might choose to  ignore that feature and use the part anyway  but they can't ignore the limitations that having that hardware available on the die causes, and there are always limitations imposed when you add features.  Both ARM and PIC make the mistake often of trying to include too many peripherals .  That is what I found refreshing about the PIC16f1783 , it was clearly designed with power control in mind .  There are parts included that are needed when doing a smps, like op amps, comparators, that normally require extra chips. The PSMC is another thing that is different .  Nothing here is anything exclusive to microchip but they have added features that work together and left out the stuff that wouldn't be needed all while keeping the pin count much lower than an ARM design and pin count matters a lot when you are figuring out the total cost.

I'm relatively new to MCU's, and have no history with the 8b or 16b generations. Even though I read some saying that a 32b is killing a bug with a platoon of tanks, that platoon of tanks nowadays is cheaper than the good old slingshot. Moreover, from what I'm taught, the Cortex-M cannot be thought about in the classical way of 16b or 32b.

You can't compare architectures based on bits because they all are different . I use ARM for things that require high level processing not things like a power supply or a remote control and that is the reason 8bit and 16bit will be around for a long time the reason isn't because a 32 bit processor is too powerful, the reason is because a 32 bit processor brings other baggage along with it I don't need for smaller projects.  In your tank example , sure the tank can kill easier, but then you need fuel, maintenance, men to run it, if I want to kill a bird I could use either but the slingshot takes a lot less effort and preparation .  Don't restrict yourself into one platform  or number of bits used, use whatever fits the job best.  I learned from years of being an engineer that those who get caught up in platform loyalty are usually the engineers that end up moving from company to company looking for one that caters to their interest , instead check out every manufacturer , even ones you think don't have anything to offer. I will probably never use a renesas cpu but that doesn't mean I don't keep up with what they make and read their data sheets.  In the 20+ years I have been doing this I have never been without someone wanting me to work for them and it has been because I don't fixate on one platform.

You can tell the engineers who have locked themselves into one brand when they list themselves as being an Freescale developer or ARM or PIC developer, I still use the title embedded hardware engineer because that is what I do , design hardware based on whatever fits and the client wants, I don't sell myself as being a specific platform developer as I need to fill their needs not have them fill mine.

[jeroen74]

On a side note... a while back when I worked at Philips I attended a presentation by a chip designer about a new generation of a fluorescent ballast control IC. Interestingly, the only feasible package was SO-14, which was a bit problematic because they really needed 16. But with 16 pins, even with many, many, many millions units produced annually, the IC would not be viable. In this sector, every tenth of a cent counts. So with a bit of some serious clever work they managed to combine the function of three pins into one.

In the high end eHid ballast sector, where only each cent counts, they use 8 bit controllers from ST, custom versions that are augmented with some clever power control hardware (I can't share the details unfortunately as it is propriety). Still no 32 bits as it probably serves no purpose other then increase cost.

[Christe4nM]

Thanks jeroen, seems my limited experience with MCU's led me into a bit of a tunnel vision. Your reply was educating. I'll try to keep my mind open. Thanks again.

[nctnico]

On a side note... a while back when I worked at Philips I attended a presentation by a chip designer about a new generation of a fluorescent ballast control IC. Interestingly, the only feasible package was SO-14, which was a bit problematic because they really needed 16. But with 16 pins, even with many, many, many millions units produced annually, the IC would not be viable. In this sector, every tenth of a cent counts. So with a bit of some serious clever work they managed to combine the function of three pins into one.

In the high end eHid ballast sector, where only each cent counts, they use 8 bit controllers from ST, custom versions that are augmented with some clever power control hardware (I can't share the details unfortunately as it is propriety). Still no 32 bits as it probably serves no purpose other then increase cost.

The key hint to take from the above is the part 'many million units'. The problem is that many people start to look at the costs of components after hearing/reading these kind of stories. They waste time and come up with obfusticated solutions which require complicated software. Even when the product you design sells 1000 pieces per year (which is a more realistic number for most professionals on this forum) it really doesn't matter if the microcontroller costs $2 or $5. The other costs involved are much higher. If you specialise on one or two microcontroller families you can easely make up for the price difference by cutting down the development time / cost.

[jeroen74]

I investigated a bit what MCUs they used in all the different products they have, and they were definitely not married to a single family or brand of MCUs. I have seen stuff from Microchip, Atmel, ST, NXP and TI. Other parts of Philips like Consumer Electronics might use Holtek too (some versions of the Senseo coffeemaker for example) or even weird Chinese brands that only have one product (a Philips alarm clock I have).

Of course, for such big company, the cost of tools and compilers is quite insignificant on the total budget for a project. That is naturally completely different for an hobbyist,a one-man shop or a shop specializing in low volume stuff.

So, I also agree with Nico. For that matter, I also don't understand why some people insist on an absolutely minimal number of external components for (usually) a switching PS. Those extra components are usually a few resistors and/or caps that cost almost nothing.

[nctnico]

About the external components... wait until you have to put a prototype together 
More serious: less components make it easier to route a PCB. Also the number of resistors, capacitors, etc can grow very large and each of them needs to be placed which takes time and thus costs money. I recall creating an alternative design which cut the BOM cost in half but because the client used an expensive assembly house it was more expensive to make than the existing design.