Lets say I only need to read a pot and control some LEDs and/or a relay.
Cheapest PIC32 right now on mouser, 100 lot. $1.73
Cheapest AVR right now on mouser, 100 lot. $0.576
That's $120 in your pocket if you choose to go the smart route. Also, more PCB space.
I can't believe this thread even made it past 2 pages.
32bits for that?!?
You could do that task with a handful of discretes for the cost of your decoupling caps alone
Lets say I only need to read a pot and control some LEDs and/or a relay.
Cheapest PIC32 right now on mouser, 100 lot. $1.73
Cheapest AVR right now on mouser, 100 lot. $0.576
That's $120 in your pocket if you choose to go the smart route. Also, more PCB space.
I can't believe this thread even made it past 2 pages.
32bits for that?!?
You could do that task with a handful of discretes for the cost of your decoupling caps alone
Yea but a 64bit uC would be stilly.
Lets say I only need to read a pot and control some LEDs and/or a relay.
Cheapest PIC32 right now on mouser, 100 lot. $1.73
Cheapest AVR right now on mouser, 100 lot. $0.576
That's $120 in your pocket if you choose to go the smart route. Also, more PCB space.
I can't believe this thread even made it past 2 pages.
Why the hell would you use a pic32 for that ?! A PIC10 or a PIC16 should be available for under $0.5 and do the job.
I think because of quantity of tutorials
most of 8bit users are beginners. I also started with atmega, then moved to arm. But still i have loads of atmega8 and they are cheap as hell
Because a lot of those are overkill for smaller projects. There's no point to using something that powerful unless you actually need it. Just because it's 8 bit doesn't mean it's useless.
Lets say I only need to read a pot and control some LEDs and/or a relay.
Cheapest PIC32 right now on mouser, 100 lot. $1.73
Cheapest AVR right now on mouser, 100 lot. $0.576
That's $120 in your pocket if you choose to go the smart route. Also, more PCB space.
I can't believe this thread even made it past 2 pages.
Cheapest Kinetis (ARM Cortex M0+) part on Mouser, qty 100,
$0.87Not quite such a big gap in price now! Also the ARM device is in a 24 pin package, so you're getting a lot more I/O which you'd have to pay for even with an 8 bit core.
Try comparing like-for-like in terms of I/O count and peripherals, and I reckon you'll be surprised just how little difference there is between 8-bit and 32-bit these days. Unless you're buying untested, near-junk grade chips, of course!
The best use of a PIC32 microcontroller:
- Maximite BASIC Interpreter (with Maximite Color board);
- PIC32Lua Lua Interpreter (with ChipKit MAX32 board);
- RetroBSD UNIX;
Writing tons of BASIC and LUA programs stored on SD-Card without wearing the microcontroller and still having a faster microcontroller for home automation, logging and whatever...
- StickOS (but with this, the uC is wearable);
For anything else, an 8bit AVR is more than enough (It can act as a 5V, hardware interface between sensors/actuators and the PIC32 board with one of the above systems installed).
The best use of a PIC32 microcontroller:
- Maximite BASIC Interpreter (with Maximite Color board);
- PIC32Lua Lua Interpreter (with ChipKit MAX32 board);
- RetroBSD UNIX;
Writing tons of BASIC and LUA programs stored on SD-Card without wearing the microcontroller and still having a faster microcontroller for home automation, logging and whatever...
- StickOS (but with this, the uC is wearable);
For anything else, an 8bit AVR is more than enough (It can act as a 5V, hardware interface between sensors/actuators and the PIC32 board with one of the above systems installed).
I agree with you on running interpreters - they can be a ton of fun! Problem is, running an interpreter is going to handicap your fancy 32 bit micro and increase your power consumption.
What I'd like to see is a benchmark of embedded interpreters by speed & power.
I use them mainly because of the packaging. Simpler achitecture and because I grew with them.
I still use 8 bit mpu for price, power consumption and package size.
Most thing I use 8 bit for are very simple applications that only need a tiny amount of computing power.
Often times I use an 8 bit MPU as a remote I/O handler for a 16 or 32 bit MPU.
It's a case of using the right part for the right application, that's why they still make and sell millions of 8 bit MCU every year.
It hardly needs a 32bit processor to raise and lower a garage door with 2 relays controlling the motor.
It would be wasteful to put a 32 bit processor into a clock/radio.
I will keep on using 8 bit when it suits and 32 bit when it fits best.
Brenden
Recently I took a freescale FRDM-KL25z devel.board launch event and for God Sake , what was that ? The IDE sucks, unstable , not free at all (just for small projects), heavy as a mamute, tons of register options to be set. A simple blink program was amazingly complex. So , want something simple , free and efficient ? use 8 bits. Want to teach
uc ? use 8 bits. And people still ask why the vast majority of mere mortal use 8 bits. Because nobody has to take a Phd in CS to develop a simple motor control ! Arduino surpassed that a long time ago. We need to go further.Not to go backwards. KISS is the best philosophy to be taken. By the way, for those who love ARM , I didn't see any mention anywhere regarding the ARM Accredited Engineer program (AAE). Has anybody already took a look at that ? Gosh , how many years you are supposed to study all that ?
what was that ? The IDE sucks, unstable , not free at all (just for small projects), heavy as a mamute, tons of register options to be set. A simple blink program was amazingly complex.
Their tools are expensive, their chips expensive (and hard to source), their support is practically non-existent, and their software sucks.
Yet, Freescale + Renesas absolutely dominate the global mcu markets.
Why? Because they don't want people who are interested in blinking leds.
I heard that excuse couple of times, and I think it's a quite a lame excuse...
How do you define "overkill"? What do you get when you use 8 bit instead of 32 bit? Many 8 bit CPUs are actually more expensive than 32bit, so cost is not the issue (and even if it costs 2-3$ more, it's hardly an issue for hobby projects)... So, what is?
When you write software, there is no such thing as "too fast" CPU
I define overkill as having more processing power than is required for the specified task. Another factor is future availability as well as platform maturity. If I design a system based on a z80 I can reasonably assume that it will be easy for others to service and develop for. As far as I'm concerned, cost is always an issue. If I can get an 8 bit chip for a project that is cheaper than a 16 bit chip and provides the same functionality, I would rather put the extra money towards a different project.
Lets say I only need to read a pot and control some LEDs and/or a relay.
Cheapest PIC32 right now on mouser, 100 lot. $1.73
Cheapest AVR right now on mouser, 100 lot. $0.576
That's $120 in your pocket if you choose to go the smart route. Also, more PCB space.
I can't believe this thread even made it past 2 pages.
Why the hell would you use a pic32 for that ?! A PIC10 or a PIC16 should be available for under $0.5 and do the job.
That was exactly my point! You save $120 if you go the smart route at choose the $0.5 8bit micro!
Lets say I only need to read a pot and control some LEDs and/or a relay.
Cheapest PIC32 right now on mouser, 100 lot. $1.73
Cheapest AVR right now on mouser, 100 lot. $0.576
That's $120 in your pocket if you choose to go the smart route. Also, more PCB space.
I can't believe this thread even made it past 2 pages.
Cheapest Kinetis (ARM Cortex M0+) part on Mouser, qty 100, $0.87
Not quite such a big gap in price now! Also the ARM device is in a 24 pin package, so you're getting a lot more I/O which you'd have to pay for even with an 8 bit core.
Try comparing like-for-like in terms of I/O count and peripherals, and I reckon you'll be surprised just how little difference there is between 8-bit and 32-bit these days. Unless you're buying untested, near-junk grade chips, of course!
Fair-enough, price wise, I hadn't looked into ARM.
But still, I don't even know how to use ARM. And a year ago didn't know how to use 32bit micros at all. There's still a learning curve for architecture you're not familiar with. Why bother spend weeks and money learning new architecture when your 8bit micro can read a pot just fine!
Different hardware for different needs.
Even today, knowing how to use a PIC32, I still wouldn't use it for everything. The smallest PIC32 is 28-pins, so I spend a lot more board realestate. Your point about getting a lot more IO is true, of course, but what if I don't need more IO? For some of my projects, all I really need is literally 2 or 3 IO. I'm not going to use a 28pin PIC32 nor am I going to learn ARM just for a simple task. Eventually, I will, but not now if I can use an 8pin AVR and get it doing what I want in an hour.
Fair comment - I use 8 bit PICs a lot, but increasingly the only reason to do so is familiarity. I know I can chuck a PIC on a schematic and have it programmed to do something simple in a matter of hours, whereas programming the more complex peripherals in a 32 bit processor is likely to take longer.
However, I'm also very conscious that if I need a few more pins, an ARM based micro is not only a great deal faster, but it actually costs less than an 8-bit PIC with the same number of pins and similar peripherals. Commercially speaking - which I often am, as I do this stuff for a living - there is no reason to use the PIC at all unless development time is the critical factor.
Still using 8-bit PICs here too. Cheap and easy/quick for me to implement. I dont think they are going anywhere anytime soon.
It could be the need for 5v tolerating devices, one attiny85 can work at 5v, can those arm's output 5v at 30-40mA in each pin?
Recently I took a freescale FRDM-KL25z devel.board launch event and for God Sake , what was that ? The IDE sucks, unstable , not free at all (just for small projects), heavy as a mamute, tons of register options to be set. A simple blink program was amazingly complex.
YMMV. Recently I bought some "Teensy3" boards that use a freescale ARM CM4. The Arduino "Blink" sketch ran fine with essentially no modification. The Teensy3 has 4 times the flash, 8 times the RAM, is about 3x faster, and has more IO than it's 8-bit brother the Teensy2. It costs about 20% more.
(That said, I'm a firm believer that "the death of 8-bit processors" is not coming anytime soon.)
(you WOULD think that the vendors who are offering small (4k flash) CM0 "8bit replacements" would be spending more time producing small libraries and init code not based on bloated "frameworks", wouldn't you? Sigh. Arduino is potentially a reasonable example, except that their ARM code runs on top of Atmel Bloatware...)
Fair comment - I use 8 bit PICs a lot, but increasingly the only reason to do so is familiarity. I know I can chuck a PIC on a schematic and have it programmed to do something simple in a matter of hours, whereas programming the more complex peripherals in a 32 bit processor is likely to take longer.
However, I'm also very conscious that if I need a few more pins, an ARM based micro is not only a great deal faster, but it actually costs less than an 8-bit PIC with the same number of pins and similar peripherals. Commercially speaking - which I often am, as I do this stuff for a living - there is no reason to use the PIC at all unless development time is the critical factor.
Speed cost power, extra power equals extra power used. Yes I know most EEs don't care. And I don't mind because it supplied me with a revenue streams for many years.
That's a discussion I had with a Freescale rep the other day. The actual power used per instruction executed on an M0+ core is, apparently, comparable to or even better than many 8 bit devices.
If you make use of sleep modes or slow down the clock during idle periods, the power consumption of the 32 bit processor to do an equal amount of work can actually be less than an 8 bit - and, of course, you have the extra performance available to you if you need it.
I was surprised too.
That's a discussion I had with a Freescale rep the other day. The actual power used per instruction executed on an M0+ core is, apparently, comparable to or even better than many 8 bit devices.
If you make use of sleep modes or slow down the clock during idle periods, the power consumption of the 32 bit processor to do an equal amount of work can actually be less than an 8 bit - and, of course, you have the extra performance available to you if you need it.
I was surprised too.
Not what I read in the white papers a data sheets.
Or maybe they are comparing deep sleep on a Freescale to a non XLP 8 bit processors. Ignoring that 8bit and 16bit uC designed for micro power also have clock switching, doze, idle, sleep and deep sleep. Of course the function names change between makers. In no way am I saying that Freescale doesn't have great power saving methods. I am saying that the power saving methods that are made more important on a power hungry processor has also been applied to the lower power chips. Besides last Ike I looked Freescale had some very small chips also. I remember reading one data-sheet of a real slow chip with a low pin count a few year ago. So Freescale to me is a varied chip description.
If it cost over $30,000.00 to get to a devices location the user wants it to last as long as possible. Yes there is tidal, wind, solar, motion, etc energy to be had in some circumstances but they can only be relied upon to a certain point. These are the type of conditions I was referring to with my low power response. In my opinion anything that uses a battery should have a very low power budget. A lot lower than what is common. But that is my opinion, and few share it.
Yeah, what they don't tell you is how many instructions you need to perform a specific task. In actual applications they still can't touch 8 bit MCUs.
Eh? Unless *all* you're doing is accessing I/O peripherals, in which case I'd agree the 32 bit parts take a few more cycles because their peripherals tend to be more complex, a 32 bit core inherently takes fewer instructions than an 8 bit. That's why the extra bits are there at all! Just consider for a moment what the CPU has to do to in order to implement, say, a 16 bit add, or an 8x8 multiply, or to copy 128 bytes of data from one area of memory to another.
8 bit will remain popular because it's easy. The tools are mature, it's well understood and easy to fully understand every aspect of the chip. It's cheap, low power
All agreed - though the price difference (for comparable peripherals and I/O count) is much smaller than you might expect, and actually favours the ARM device in many cases. Compare some PIC18 vs STM32 parts in 100+ and see.
, and actually faster than ARM in many applications (see how fast you can toggle a pin with a 1mA power budget on say XMEGA vs. any ARM micro you care to mention).
If that's what your application requires, an XMEGA might be a better choice. Nobody's arguing about that.
ARM also needs licencing fees, which is why some manufacturers have gone in a different direction. For example Microchip's 32 bit PICs are MIPS based.
Have you actually compared prices like-for-like for similar devices? This is a completely bogus argument, ARM based devices are generally cheaper than PIC32.
PIC32 doesn't use MIPS because it's cheaper, it uses MIPS because it's older.
Finally, 32 bit is almost always going to cost more simply because you need more memory to store larger instruction words and data types, and more transistors to handle manipulating them. That's another reason I'm extremely sceptical about Freescale's claims - all things being equal if you need to do an add instruction on 32 bits instead of 8 it's going to require more energy.
All other things aren't equal, though. Which devices are you going to make on your latest fab process?
In actual applications they still can't touch 8 bit MCUs.
I am curious as to what those applications are.
I think it is fair to say that for many applications, 32-bit mcus don't offer significant advantages, on an apple-to-apple basis. On the flip side, 8-bit mcus don't offer significant advantages over 32-bit mcus too. For example, 32-bit mcus typically consume 30ma run current, vs. 10ma or so for (most) 8-bit mcus. But that's due to the 32-bit mcus running at much faster clock speed. If you control clock speed, most ARM mcus consume less than 8-bit mcus on a current/Mhz basis - due to the use of newer processes.
To me, 32-bit mcus' advantage is mostly in its peripherals and software - which is to say that if you were to put those peripherals on an 8-bit mcu, I wouldn't hesitate using them as well.
you WOULD think that the vendors who are offering small (4k flash) CM0 "8bit replacements" would be spending more time producing small libraries and init code
Agreed. This is where the chip oems are missing the boat. The 32-bit chips are considerably more complex than the 8-bit chips hardware-wise (they don't need to be), and they oems aren't making the software guys' jobs any easier to help facilitate the transition.
If 32-bit chips are to be successful in displacing the 8-bit chips, someone has to dumb-down the 32-bit chips to the level of an 8-bit chip programmer, via hardware and software.