Advantages of 32bit micros - Page 1
Forum section: electronics / general

author: Aodhan145
author_rank: Frequent Contributor
timestamp: January 12, 2016, 06:43:14 pm
content: I really only use a couple of arduinos and like a pic so I probably wont avail of the advantages. I recently bought a ti tiva c TM4C123GXL launch pad as they are so cheap. Its great I use it a lot. I understand the differences in speed, RAM etc but what about practical advantages things you can do on a 32bit micro that you cant do on an 8bit?

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: January 12, 2016, 06:56:35 pm
content: Well, "can't do" is a bit black and white. But modern 32bit CPUs like Cortex M3 and M4 have quite a lot about them to like.Cortex M3 has hardware division, a lot of nice opcodes e.g. for counting leading zeroes, reservation (for atomic read/modify access) and stuff like this.Cortex M4 adds DSP extension and an optional FPU.Debugging posibilities (JTAG or SWD) are usually pretty good. Often it's possible to read/write to variables and registers while the CPU is running.Some CPUs even have a micro trace buffer.Depending on the actual CPU, there's also usually a lot of complex peripherals like 32bit timers, DMA and stuff like this that's typically missing on 8bit CPUs.

author: rsjsouza
author_rank: Super Contributor
timestamp: January 12, 2016, 07:26:10 pm
content: 0xdeadbeef is right; 8-bit processor cores are able to do most of what 32-bit cores do, unless the architecture is unable to access large memory ranges (in general 8-bit architectures are more limited on that aspect). Between the two, the main difference in this case usually relies on performance - as mentioned before, math operations with large or floating-point numbers have extra bits or dedicated hardware to be computed faster on a 32-bit architecture.As a general statement the processor core datapath size does not influence the functionality of code written in C language. If you are performing code migration, other factors must be taken into consideration such as inlined assembly instructions, compiler implementation (vendor or architecture extensions that create ties to the core), and differences in peripherals, among others.All in all, simpler operations and systems benefit from an 8-bit architecture given not only its lower cost (for large volume manufacturing this makes a huge difference) but also possibly lower power (although with more modern architectures this can be highly debatable). For regular hobbyists and low-volume manufacturing runs, the price difference is smaller and the benefits of using the same architecture in a broader range of products tends to tip the scale towards 32-bits.Disclaimer:I have used large VLIW DSPs in the past and currently I am a big fan of MSP430 (16-bit) and TM4C (32-bit) devices.

author: AlxDroidDev
author_rank: Frequent Contributor
timestamp: January 12, 2016, 07:50:51 pm
content: Quote from: rsjsouza on January 12, 2016, 07:26:10 pm8-bit Atmega328 : about US$ 1.70, in large quantities > 100032-bit STM32F301K6U6: US$ 0.986, in multiples of 10kSo, the 8-bit uCs loses in that aspect. Also, the faster the CPU runs a routine, the faster it can go into sleep mode and stay there longer until there is something else to be executed. That saves a lot of power, because they are executing things for a much shorter time. So they are more power-friendly than the 8-bit.In short: 8-bit uCs are more expensive and use more power.Their price advantage, however, is not on the chip itself, but on the supporting circuitry that is required to make them run. An AVR, for instance, can be run with nothing but a bypass cap... and on a breadboard! You don't even need a xtal if you use the internal oscillator. Most 32-bit CPUs need more external circuitry, which makes the project a little more expensive and take more PCB real estate. Try breadboarding a Cortex M3...The part where 8-bit uCs really shine - at least in my experience - is the easiness to code them. Take the Arduino or PIC ecosystems: there are lots of examples for everything, and it all works even on slightly different chips. Even if you use Atmel Studio, code is simple enough and most times you don't have to worry if you have an Atmega8, Atmega2560, Atmega328 or Atmega1284: the code is very much the same most of the time. When it comes to 32-bit Cortex chips however, you have to code for the specific uC you have, and that is a pain the ass.Neverthless, I still use mostly AVRs. Why?First, I have about 30 chips at home, of several models (M8, M328, M1284), because I got them for cheap from Amazon the last time I went to the US. Second: I save tons of time in development. Like I wrote, easiness of coding is what makes 8-bit shine at the moment, but hopefully this will change.

author: rsjsouza
author_rank: Super Contributor
timestamp: January 12, 2016, 08:58:46 pm
content: Quote from: AlxDroidDev on January 12, 2016, 07:50:51 pmAnecdotal evidence. A single example taken from specific part numbers is not a true benchmark. If 32-bit was more expensive in all scenarios, TV remote controls wouldn't be using 4 or 8-bit microcontrollers from Holtek, for example.To take ST as an example, their lowest-cost 8-bit is US$0.391 in 10k quantities.

author: rich
author_rank: Frequent Contributor
timestamp: January 12, 2016, 09:08:15 pm
content: Quote from: AlxDroidDev on January 12, 2016, 07:50:51 pmI'm struggling to parse the above. Did you mean to type8-bit uCs?Maybe when you get to M3, M4 levels then you need to crystals and supporting components, but there are several M0+ level devices with internal oscillators, not many DIP packages suitable for breadboarding though.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: January 12, 2016, 09:39:11 pm
content: Actually most NXP Cortex M3s have an internal oscillator. Typically 12MHz. Then again, adding an Xtal and two capacitors is not rocket science and allows higher clocks and more precise timing.It's not so difficult to create a small PCB with the µC+XTAL+caps and debug/supply pin that can be used for breadboarding during development or even as CPU board for a project.Did that forLPC1347 and LPC1549.

author: AlxDroidDev
author_rank: Frequent Contributor
timestamp: January 12, 2016, 09:43:58 pm
content: Post corrected.

author: nctnico
author_rank: Super Contributor
timestamp: January 12, 2016, 09:55:45 pm
content: Quote from: 0xdeadbeef on January 12, 2016, 09:39:11 pmNot quite right. The internal RC oscillator (1%) in the NXP devices can be used to run the core at maximum frequency using the PLL. Needing to use a crystal is rare for my typical projects.

author: Brutte
author_rank: Frequent Contributor
timestamp: January 12, 2016, 10:48:24 pm
content: Advantages of 32-bit over 8-bit for low volume and hobby projects..Less constrains.Typically 8-bitters end up in 128k words program size while 32-bitters with 1M words are not uncommon. Additionally I have never heard about an off-the-shelf 8-bitter with TFT display controller, USB HS, BLDC controller, 5 UARTS, 3 SPIs etc.What can be made with 100h/100$ using 8-bitter, can be made on 32-bitter with half of that budget. Things change with higher volume but for low volume it does not matter if a uC is $2 or $12 a pop when it saves you time and gives flexibility.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: January 12, 2016, 10:49:27 pm
content: Quote from: nctnico on January 12, 2016, 09:55:45 pmIndeed you can use the IRC oscillator as source for the main PLL (not for the USB PLL as far as I recall) in most LPC devices. I wouldn't be so bold to say that it's possible in all devices or that it's always possible to reach the maximum frequency since the IRC oscillator frequency is sometimes quite a bit lower than 12MHz (like 4MHz for the LPC178x). Also keep in mind that the 1% deviation means you also exceed the maximum frequency by 1% which might be OK for hobby use, but is nothing you would usually do in a commercial environment. Letting aside that some asynchronous protocols like CAN require better accuracy than 1% (e.g. 0.3% accuracy for 500kbit/s CAN).Also e.g. the LPC176x manual clearly states that you should not use the main PLL for the USB peripheral if the main PLL is driven by the IRC oscillator and the USB PLL can only use the XTAL as source.So if you want to use USB, you need the crystal anyway.

author: dannyf
author_rank: Super Contributor
timestamp: January 12, 2016, 11:10:25 pm
content: For most projects, the difference between an 8 bit mcu and a 32 bit mcu is practically no.Generally speaking, 32 bit mcus can run faster, have more space, and have more and better peripherals. So if your application is math intensive, go with a 32 bit mcu.On the flip side, A 32 bit mcu is much more complex to learn and to code, consumes more current, and are more expensive.I would suggest that you pick a mcu based on its peripherals, OEM aupport, software investment, and not on its core.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: January 12, 2016, 11:18:57 pm
content: For hobby projects cost isn't a consideration. A $1 8-bit MCU versus a $10 32-bit MCU would matter in a commercial product, but for the one-off projects that I do it's lost in the noise.Commercial products tend to squeeze the cheapest, smallest MCU into the design the designers think they can get away with. This makes financial sense, but it often causes problems later when additional features need to be implemented or fixes made and the developers are right up against a flash or RAM capacity wall. When I do a project, on the other hand, I tend towards massive overkill with respect to the MCU, with much much more flash and RAM than I really need, just because I can and because an extra $5 for a hobby project that I do perhaps 4-5 of a year means the additional cost is just peanuts.

author: dannyf
author_rank: Super Contributor
timestamp: January 12, 2016, 11:35:46 pm
content: "Commercial products tend to squeeze the cheapest, smallest MCU into the design the designers think they can get away with."There are commercial products and then there are commercial products.Of the ones I have worked over the last few years, the mcu choices were driven largely by software availability, certification, and corporate sourcing decisions, as performance was a non factor. In those cases, software costs far outweighed hardware costs.I think it greatly depends on where your mkt niche is. I tend to think that if you are penny pinching that much, you should consider if that's the right place to deploy your resources.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: January 12, 2016, 11:39:31 pm
content: Quote from: dannyf on January 12, 2016, 11:35:46 pmI was referring primarily to mass market consumer products like TV remotes, toys, toothbrushes, that sort of thing, although even expensive items are often are looked at through a cost reduction microscope.

author: andyturk
author_rank: Frequent Contributor
timestamp: January 13, 2016, 01:05:59 am
content: Quote from: Aodhan145 on January 12, 2016, 06:43:14 pmARM Cortex-M isn't synonymous with "32bit micro" but comes pretty close... And a big advantage of Cortex-M is the availability of a world-class toolchain for free. That's GCC, of course, and it sits inside most of the OEM development environments even if the UIs are vendor specific.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: January 13, 2016, 01:32:15 am
content: PIC32 also has GCC support, along with an IDE based on NetBeans, which, IMHO, is better than Eclipse.

author: nctnico
author_rank: Super Contributor
timestamp: January 13, 2016, 07:04:17 am
content: Quote from: dannyf on January 12, 2016, 11:10:25 pmwrong wrong and wrong.1) 32 bit MCUs have a flat memory space where 8 bit microcontrollers like 8051 and PIC have convoluted memory layouts not even allowing to use pointers properly and need pragmas to place variables into certain memory areas manually.2) Cortex M0 devices are very power efficient. Recently I had to choose between MSP430 (king of low power) and an NXP Cortex M0 device... The M0 device turned out to consume just as much power3) The NXP Cortex M0 device under point 2 was cheaper than the MSP430 device which fitted the design.

author: Gribo
author_rank: Frequent Contributor
timestamp: January 13, 2016, 07:43:54 am
content: One critical advantage of the 32-bit MCUs is an MMU. yes, not all of them have it, but it makes your life so much easier in larger projects.

author: hamdi.tn
author_rank: Frequent Contributor
timestamp: January 13, 2016, 08:20:46 am
content: i used PIC 8-bit MCU a lot , but since i start using STM32 2 or 3 years ago, i didn't design any product with PIC mcu again.price is good and i can say even if i don't need most of it's functionality for some project, i prefer to use a STM32 than a 8-bit PIC cause most of the time a PIC18F is the same price if not more expensive than a STM32F.The only problem with them is as some ppl said here, learning how to use that take much more time but as any new thing it take time to learn how to use it, so no excuse there.

author: Brutte
author_rank: Frequent Contributor
timestamp: January 13, 2016, 08:47:54 am
content: Quote from: Gribo on January 13, 2016, 07:43:54 amI have never heard about a microcontroller with MMU. Reference, please.

author: Codemonkey
author_rank: Regular Contributor
timestamp: January 13, 2016, 09:35:23 am
content: Quote from: Brutte on January 13, 2016, 08:47:54 amNXP LPC3220/30/40/50http://www.nxp.com/documents/data_sheet/LPC3220_30_40_50.pdf

author: coppice
author_rank: Super Contributor
timestamp: January 13, 2016, 09:44:59 am
content: Quote from: Codemonkey on January 13, 2016, 09:35:23 amNXP describe that as a microcontroller, but its not really what most people think of as a microcontroller. It has a lot of on board peripherals, but needs external memory. This is becoming a grey area, though. A number of chips most people do think of as MCUs may have internal memory, but that needs to be booted from an external serial flash chip.

author: Jeroen3
author_rank: Super Contributor
timestamp: January 13, 2016, 09:57:20 am
content: 32 bit processors often have a von neumann software approach, whiles using a harvard hardware approach.This results in a single piece of assembler being able to read/write from any place. Peripherals, RAM and ROM and external ram/rom. The core will have multiple buses to the bus matrix, yet the programmer is not able to influence which is used. As opposed to AVR or 8051 where you need separate instructions to read from flash, switch address overlays to access more memory if it does not fit in a 16 bit address. Which makes the software design more lower level.In short: you can use pointers more easily, which can make your life hell or heaven depending on your coding skills.Allowing you to take more distance from assembler, and go into the higher layers.

author: VEGETA
author_rank: Super Contributor
timestamp: January 13, 2016, 10:56:16 am
content: from my opinion, I find 8-bit uC still better in terms of using them by beginners. Like, they can be hooked on a breadboard and with minimal circuitry. However, 32-bit ones MUST be on a dev/whatever board to be used by beginners. One can buy a PIC chip and use it, but when he wants to buy a 32-bit ARM one he asks "which manufacturer is better?" and "what board should I get?".Also, dev tools like IDE and compilers are harder in 32 bit. you can not even name a standard one that the industry uses.

author: dannyf
author_rank: Super Contributor
timestamp: January 13, 2016, 11:42:12 am
content: QuoteMicrochip produces 32-bit chips in pdip packaging, NXP has one offering there as well. Luminary did too.ST has 32-bit chips in ssop packaging that can be easily converted to pdip through an adapter. and I am sure others as well.Lots of choices.

author: dannyf
author_rank: Super Contributor
timestamp: January 13, 2016, 11:43:27 am
content: QuoteNor could you name a standard one for 8-bit, 16-bit, or even your windows PC, etc. because a beast like that does NOT exist by its very definition.

author: AlxDroidDev
author_rank: Frequent Contributor
timestamp: January 13, 2016, 12:04:06 pm
content: Quote from: VEGETA on January 13, 2016, 10:56:16 amThat's my point: development is a lot harder, more time consuming and more expensive in the 32-bit world.

author: Kalvin
author_rank: Super Contributor
timestamp: January 13, 2016, 12:05:00 pm
content: If you are designing a commercial product, there are quite many variables to be considered when selecting the microcontroller - not just 8-bits vs 32-bits. For hobby projects one can use both 8-bit and 32-bit devices and both provide good possibilities for learning.My personal preference for the hobby projects is microcontroller with a decent C compiler and enough on-chip resources (RAM, Flash, peripherals), although I use AVR (Arduino) if I need to test something and I can find a suitable code snippet from the net. The 32-bit ARM-based controllers provide higher performance, more memory, more capable peripherals, more devices from different manufacturers in decent price range etc. and there are quite a few breadboarding friendly modules available.From the architecture point of view, the 32-bit architecture allows more efficient compiler code generation with better addressing modes thus faster execution time and possibly even smaller energy consumption (if that is important factor in the design), as others have already pointed out. Quite often the peripherals are more than 8-bit in nature (12-bit ADC, 12-bit DAC, 16-bit/32-bit timers etc.) so the 32-bit architecture have a natural advantage there already.

author: mikerj
author_rank: Super Contributor
timestamp: January 13, 2016, 12:11:06 pm
content: Quote from: AlxDroidDev on January 13, 2016, 12:04:06 pmThat is simply not true. For Cortex M parts, the debuggers are cheap (e.g. ST-Link is under $20, comes built into the very cheap STM32 eval boards), good compilers can be had for free (GCC) and there are thousands of eval boards and code examples available for the popular micros.

author: rsjsouza
author_rank: Super Contributor
timestamp: January 13, 2016, 12:39:31 pm
content: Quote from: dannyf on January 13, 2016, 11:43:27 am+1. The number of offerings for 32-bits did not change much when compared to older days when 8-bit microprocessors were mainstream (Z80s, 8051s, etc.). Only from a programmer's level you start to see something closer to a "standard" in the shape of a high level programming language such as C but, as I said before, there is very little correlation between this and the datapath size of the processor.Quote from: mikerj on January 13, 2016, 12:11:06 pm+1 to that. Another example: Arduino for 8-bits and Energia for 16 (MSP430) and 32 bit (Tiva, MSP432 and C2000) devices. They are absolutely identical!There is no direct correlation between the datapath size and the complexity of the tools, nor the complexity of programming in a high level language.

author: dannyf
author_rank: Super Contributor
timestamp: January 13, 2016, 01:14:45 pm
content: "For Cortex M parts, the debuggers are cheap (e.g. ST-Link is under $20, comes built into the very cheap STM32 eval boards), good compilers can be had for free (GCC) and there are thousands of eval boards and code examples available for the popular micros."That is selective comparison, as the same can be said about some 8 bit mcus.I think 8 bit wins in terms of simplicity, pricing, availability, and code base / user base.

author: retrolefty
author_rank: Super Contributor
timestamp: January 13, 2016, 01:46:06 pm
content: QuoteThis++ A better starting point for base zero users for smoother learning curve.

author: theatrus
author_rank: Frequent Contributor
timestamp: January 13, 2016, 06:10:39 pm
content: Quote from: 0xdeadbeef on January 12, 2016, 10:49:27 pmThe Freescale Kinetis parts have a crystal-less USB capability presumably using some sort of clock steering and recovery from the host device.As for the 8/32 bit divide - resources are being poured into the Cortex market like none other, while the 8bitters are largely stagnant. I'm pretty sure Atmel is still betting on Arduino crossovers and legacy projects to drive any sort of future sales for them.

author: zapta
author_rank: Super Contributor
timestamp: January 13, 2016, 06:13:30 pm
content: The OP asks if there are any advantages for 32bit MCUs, not what word size beginners should chose.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: January 13, 2016, 06:29:36 pm
content: Quote from: zapta on January 13, 2016, 06:13:30 pmJust taking the word size differences into consideration and ignoring everything else, a 32-bit MCU has the advantage when it comes to doing fixed point math. Manipulating large numbers is faster and easier than doing the equivalent on an 8-bit or 16-bit MCU. Most 32-bit MCUs can run at a higher clock rate than most 8-bit and 16-bit MCUs, so they tend to perform better overall.

author: Brutte
author_rank: Frequent Contributor
timestamp: January 13, 2016, 07:16:21 pm
content: Quote from: dannyf on January 12, 2016, 11:10:25 pmI'd say that the 32-bitters I know about are much easier to learn than 8-bitters, when requirements are fixed. For example try doing a 20 bit PWM on 8-bit micro that typically only has 16-bit timers. With 32-bitter it is a breeze. 100kB array for samples? No problem, lets round it to 128kB. Or try to design a controller on a slow uC. That is pita when you are trying to squeeze every bit of cpu time.However, when learning means reading and understanding of all the details of RTFM provided, learn it by heart then I suggest OP should consider transistors as an alternative. Transistors have short DS and you can still do same stuff with a transistor than can be done with 32-bitter. Well, you need 2 zillions of those but that is still doable and less RTFM-ing!Now coding difficulty. How come perhaps 95% of the code ever written runs on 32-bitters? Well, recently we had revolution and 64-bitters are in offensive but if the 8-bitter programming theory was true, we would have 8-bit software everywhere. Concluding - writing software for something with less constrains cannot be harder.Current current consumption. 32-bitters are typically made for performance so most of the available designs has huge appetite for code (popular STM32F407 consumes around 480MB (~0.5GB) of instructions each second) but there are those that top at 12MHz and eat up under 1mA at full throttle. Anyway, transistor wins again - there are some that draw less current than any 8-bitter!Now naked truth about the price - with other factors fixed (performance, memories, pinouts, etc), 32-bit microcontrollers are more expensive a pop. So instead of $2 for 8-bitter you pay $3 for comparable 32-bitter in volume. But discrete transistors might be cheaper (a pop).

author: dannyf
author_rank: Super Contributor
timestamp: January 13, 2016, 09:26:13 pm
content: My own experience may be an interesting case both for and against 8-bit mcus.I started my professional career with mcs48. when I picked up mcus again, professionally, ~10 years ago, I took on PIC in a firm that's predominantly 32-bit. Very quickly, I came to the conclusion that there is no hope for 8-bit mcus in our market and I dropped all (future) support for 8-bit mcus and focused the firm on 32-bit mcus exclusively.Personally, I have been a huge fun of PIC24 (for its remappable pins and consistent peripheral and a good compromise between speed and complexity), and lately STM8 (just love it for its value, and modern trace support). From time to time, I pick up a 32-bit chip (mostly STM32 and then old LPC210x) but I may write a few peripheral routines to beef up my library. Rarely there is a real reason for a 32-bit chip over an 8-bit chip.I would sum that up by saying that 1) if you are making a living off of an 8-bit chip, you should be very concerned; and 2) if you are a hobbyist looking to pick up a 32-bit chip, think hard about why you are doing that.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: January 13, 2016, 11:22:38 pm
content: When I started my professional career in embedded programming >30 years ago, I started with the 68000, so I've been 32-bit my entire career, with one exception. I once had to do a project using an 8-bit Hitachi 64180 and it was a real pain having to deal with memory mapping and doing multiple precision math with the 8-bit registers.

author: dannyf
author_rank: Super Contributor
timestamp: January 13, 2016, 11:28:30 pm
content: One thing that the 8-bit fanboys (i'm one of them) often bring up is code density: longer instructions means more flash space for the same number of instructions - no doubt about it. However, in favor of the 32-bit chips is the fact that often times they need fewer instructions to perform the same job (hardware multipliers / dividers for example).My causal observation - highly unscientific - is that for the same task, 32-bit applications do seem to compile into most flash space. However, I cannot attribute that entirely to 32-bit width vs. 8-bit.Would be interesting to see if someone has done real-life surveys on this topic.Another point worth considering: may of today's "32-bit" ARM chips, like M0 - M3, are closer to 16-bit chips than to 32-bit chips, for their reliance on Thumb/Thumb2 instructions.

author: coppice
author_rank: Super Contributor
timestamp: January 14, 2016, 01:39:12 am
content: Quote from: dannyf on January 13, 2016, 11:28:30 pmIt depends a lot on the type of code you are writing. If the application is mostly bit twiddling on ports an 8051 can achieve very dense code. Try to do some serious computation or data manipulation and its code density is horrible compared to an ARM. Code density for high level language users is also an issue. A few small MCU cores, like the MSP430, are built like bigger machines, and high level languages compile well for them. Most small cores show poor code density compiled from C.

author: westfw
author_rank: Super Contributor
timestamp: January 14, 2016, 03:15:58 am
content: The BIG advantage of most 32bit micros is that 32-bit unified address space, and the "regular" access to it. Compiler writers LOVE that (and indeed, a sub-advantage is that you're likely to get better compilers for 32bit micros.) You can throw a GB of address space at RAM, another 2GB at flash, and still have enough room left over to let your peripherals "spread out" and get "feature-full" without getting really weird.Of course, that's a disadvantage too. Someone mentioned "code density"... An 8bit microcontroller usually has special instructions for dealing with the IO space, while a typical 32bit micro will have the "IO space" be treated any other memory. Right away your AVR single-instruction "set a bit (3bit identifier) in an IO port (5bit identifier) that ends up fitting in a single two-byte instruction becomes a sequence like:Code:ld r1, [32bit literal address of IO reg] ; 6 bytesld r2,  ; probably 2 bytes; <atomicity handling> ; about 8 bytes ?ld r3, (r1) ; get value ; two bytesor r3, r2 ; set bit ; two bytesst r3, (r1) ; store new val ; two bytes; <more atomicity handling> ; about 4 bytes?12:1 code size difference! (and register usage!) Fortunately most microcontrollers make the peripherals fancier (set/clear registers), or the bus fancier ("bit-banding"), and manage to do away with some of that code. And usually real code will manage to "share" some of those "extra instructions", and the circumstances under which you could have used that single-instruction on your 8-bitter are more limited than you might have thought anyway, but still...

author: macboy
author_rank: Super Contributor
timestamp: January 14, 2016, 02:46:34 pm
content: I like this thread. People are making good points on each side and are doing so without coming to blows. Keep it up!Some say development time is less on 8 bit. This might be true if you are very familiar with the uC family and the dev tools, and you are picking up a new device in that family. The datasheet will be smaller and easier than one for a new 32-bitter. However, if you are very familiar with your favorite 32-bit uC family and its tools, you can develop on it faster than switching to an unfamiliar 8-bitter. My point is that the fastest development time is in the one you are most proficient with.Cost: Some argued that 8-bit costs less to get into than 32-bit. I disagree.Let's take Microchip PIC. You need a Pickit3 at minimum, so that's $40 or so, then you need the free IDE, but you need to buy the C compiler to get a not-useless version of it. If you are working on a low pin count device (<28 pins) and want to do ICD, then you need the special ICD adapter for $20. The devices themselves are cheap, entry cost not so much once you consider the programmer/debuger and compiler.Now consider something like Cypress PSoC 4. This is a 32-bit ARM device with good peripherals. You can buy a dev board for $4 which has a built in USB-based programmer/debugger, and breaks out all pins to a breadboard-compatible DIP footprint. The IDE and good C compilers are free. And the devices can be had cheaper than any remotely comparable PIC (if it isn't cheaper than the <insert competitor> you are considering, tell Cypress, and they will make it so... I heard of them going well under $1/chip). Entry cost: $4.That low lost is not unique. The 32-bit space is highly competitive not only within 32 bit but also with 8 and 16 bit as well. You can get under $10 dev boards with programmer/debugger integrated for many 32-bit families. You can even cheaply play with some very powerful 32-bitters like the PSoC 5 - the device costs around $16 a pop but the dev board costs around $10.edit:price

author: Dielectric
author_rank: Regular Contributor
timestamp: January 14, 2016, 03:17:01 pm
content: The cost on 8 vs 32 bit is interesting. Many of the 8 bit MCUs are on larger process technologies than 32 bit parts. That translates into more parts per wafer and you get a knee in the cost curve. Of course, some vendors can get really dirty on cost for their 8 bit MCUs because the equipment is fully amortized and basically prints money.On code density, it is really common to find much better code density on 32 bit stuff for certain applications. If you compare the code size for a FAT filesystem implementation on a PSoC3 (8051DP) vs PSoC5 (M3), you'll see that the M3 core uses HALF the flash of the 8051. Interestingly, the SRAM usage doesn't scale quite as dramatically. Math functions beyond 8 bits are the same, look at the torture an 8 bit core needs to go through to compute a 32-bit multiply (assume no MAC is available).

author: nctnico
author_rank: Super Contributor
timestamp: January 14, 2016, 03:51:39 pm
content: Quote from: westfw on January 14, 2016, 03:15:58 amActually this can be made much shorter! You can store a constant relative to the PC (program counter) so reading the register value is likeld r2,[pc+20]Thumb2 allows some immediate 8 bit values:or r2,r2,bit_valueAnd then store the new value.st [pc+20],r2Almost all NXP ARM controllers however have GPIO with seperate registers for bit set/reset and some even toggle. So there is no nead to read the current value and modify it.

author: zapta
author_rank: Super Contributor
timestamp: January 14, 2016, 03:59:23 pm
content: Quote from: nctnico on January 14, 2016, 03:51:39 pmThat's the beauty of a large address space. More freedom in surfacing the I/O in easy to use and usable forms.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: January 14, 2016, 05:50:54 pm
content: Quote from: nctnico on January 14, 2016, 03:51:39 pmBesides, all Cortex M3 (and above?) CPUs support bit-banding. There are two bit band regions, each 1MB: one for SRAM, one for peripherals.Unfortunately, e.g. in the LPC1768 one of the two RAM banks is outside the bit-band region as well as some of the peripherals. But e.g. all GPIO registers are inside the bit band region.

author: XFDDesign
author_rank: Frequent Contributor
timestamp: January 14, 2016, 06:06:36 pm
content: Quote from: andyturk on January 13, 2016, 01:05:59 amOn which brand implementation of Arm?Every time I have attempted to get into ARM, the barrier to entry is so ridiculous (compilers are a mess, documentation to get started is awful, data on how to burn the parts is non existent, all of which is true until you're willing to drop a serious amount of capital on getting vested) I walk away in disgust. I never even got the clusterbuck mess of GCC for Arm to compile usable code.As such, I specifically got into the PIC32F line. The same basic simplicity of the 8-bit micros, expanded to 32 bits, has an FPU on-chip and runs like a cat on fire. The Pickit3 programs the things without hassle, and I was able to write the typical blinking-led program and verify correct operation in under 30 minutes.

author: mikerj
author_rank: Super Contributor
timestamp: January 14, 2016, 06:14:50 pm
content: Quote from: dannyf on January 13, 2016, 01:14:45 pmIt's not selective at all, it's simply an example which disproves the statement made about 32 bit development being expensive, difficult and time consuming. It might be for some processor families, but typically not for ARM Cortex parts which are surely the most popular 32 bit micros these days.I agree the learning curve is steeper compared to a PIC or AVR (quite a lot steeper in some cases) and I wouldn't necessarily advise a complete beginner to start with 32 bit micros but that's a different argument. Once you have a reasonable grasp of the basics, development can actually be quite a bit faster on a 32 bit part.

author: jolshefsky
author_rank: Regular Contributor
timestamp: January 14, 2016, 06:17:09 pm
content: I think a lot of it comes down to "use the right tool for the job". Anything an 8-bit MCU can do, a 32-bit MCU can as well, but not the other way around. Ibelievethat 8-bit MCUs are more mature, and hence, more likely to be available for many years to come, while 32-bit MCUs are fairly new and come and go. I know that is not absolutely true, and basically just intuitively so—but if you're designing a product for the long-haul, it may be wise to look to the product's expected life-cycle.I got bit by a problem where a product my company made for several decades suddenly had a critical chip vanish from the Earth due to the original mask being destroyed in a fire. I did a redesign, first as an adapter then as a dedicated main board. In it, I needed a precise 90° phase difference between two highly stable clocks to run roughly 5KHz. Although I'm sure there's a chip to do just this sort of thing, a PIC 12F683 (8-pin, 8-bit micro) made it possible to do with just a bypass cap. And because it's one of the more generic PICs (not lowest power, not lowest pin-count, etc.), I expect it to be available for a long time to come. I'm still a little embarrassed that I'm not making use of any of the advanced features or peripherals, but it got the job done.So in my mind, 8-bit MCUs are a great way to implement simple state machines and the like. If you're making a simple logic array and realize you need to hold a little state information, do a little math, or it's just getting way to complicated, an 8-bit MCU can simplify a design a lot.The toughest task an 8-bit MCU can do is something like controlling 4 PWM outputs at a low rate of change (e.g. a motor controller for a simple CNC machine.) Beyond that, you're better off designing with a 32-bit MCU as it offers the speed and flexibility to handle a lot more. Like if you want to do FFT, MP3 decoding, or handle more than hundreds of bytes of data, you can pretty much forget about doing it on an 8-bit.All that said, I do amuse myself with projects wholly inappropriate for 8-bit MCUs, albeit not in a professional setting. For instance, I have a project with 50 RGB LEDs that I control via bit-banged PWM using an 8-bit processor. It's quite a feat to individually control all 150 outputs with 8-bit resolution and still have enough CPU power left over to create patterns at a rate of about 12 frames per second. But if I were to make this a product in any way, it would be way more sensible to go with a 32-bit processor, especially if anyone else will be trying to work on the code.

author: Howardlong
author_rank: Super Contributor
timestamp: January 14, 2016, 06:36:30 pm
content: Completely nuts, but yesterday I built a narrow band FM transmitter on the 2m band using a breadboarded PiC16F1718 and an 8MHz crystal. No more than about 40-50 lines of code. Looking to put it on a $0.53 (1ku) 8 pin PIC16F18313 when I get delivery next week.The on-chip NCO has just about enough resolution for reasonable NBFM after filtering the 11th harmonic with some passives. I built it for use as a low power calibrated and modulated signal source, but equally it can be used as an exciter for any number of other projects.If I'm honest I'd have preferred doing it on a 16 or 32 bit device, but when it comes to really low pin count and random peripherals like this it's hard to beat the 8 bit PICs.

author: westfw
author_rank: Super Contributor
timestamp: January 14, 2016, 07:09:35 pm
content: QuoteWell, no. There is a (rather small) range limit on the offset you can use pc-relative addressing, and it definitely doesn't extend to accessing the peripheral address space from the program flash space.And while thumb2 gives you some immediate values, it does so by expanding the instruction size from 16 to 32 bits, so it still takes the same space as the "mov const to reg, or register" sequence (though it does save the register.) And CM0/CM0+, where you care most about code space efficiency, doesn't have Thumb2 :-((Mind, you have to dig pretty deep through several levels of manuals to figure this out. For a "RISC" architecture, there's a fair amount of ugliness hidden behind the "clean" instruction formats described at the assembly level. Especially once you take into account the several currently-active "architecture variants." Grr.)

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: January 14, 2016, 07:21:18 pm
content: Quote from: westfw on January 14, 2016, 07:09:35 pmAs there are 13 general purpose registers available for Cortex M3, you could sacrifice two registers to serve as base for offset based access to e.g. the SRAM or peripheral registers.I'm not sure if this is actually used by GCC for Cortex cores, but e.g. for PPC cores there was/is a convention that certain registers are not used during runtime as they hold the address of some "small data areas".

author: Jeroen3
author_rank: Super Contributor
timestamp: January 14, 2016, 07:25:07 pm
content: You don't need to keep the offset, you can store the full address.The compiler does notneedthem all. You can "demand" a few for your own use, even in C, by using the keywordregister. (the optimiser will automatically do this for you on O1).

author: c4757p
author_rank: Super Contributor
timestamp: January 14, 2016, 08:23:59 pm
content: registeris just a suggestion¸ it's generally ignored - and you have to put the compiler into-Opotatoto make it not do this automatically anyway.Anyone who usesregisteris micro-optimizing. Structure your code better and the compiler will do it for you.

author: Howardlong
author_rank: Super Contributor
timestamp: January 14, 2016, 10:40:02 pm
content: Quote from: c4757p on January 14, 2016, 08:23:59 pmI'd agree that randomly using register is wishful thinking.In general you need to have a reasonably good understanding of the CPU and bus/memory architecture of your device to do a better job than the compiler (for example it doesn't know which busses are slow and where there may be contention), but occasionally it makes sense to help it out. Sometimes manual loop unrolling, using idioms and interleaving assignments to avoid stalls for example can do a better job than the compiler as it makes generalised assumptions about data parameters that you have more information than you can tell it about. But yes, it is very much the exception than the rule, and you are very much at risk of making unmaintainable code.

author: andyturk
author_rank: Frequent Contributor
timestamp: January 15, 2016, 01:14:08 am
content: Quote from: Howardlong on January 14, 2016, 10:40:02 pmYeah, you gotta do something like this to make it stick:Code:static inline ContextSwitchFrame* __attribute__((always_inline)) save() {ContextSwitchFrame* result asm("r0");// r4-r11 must be saved according to the Arm Procedure Call Standard (APCS)// http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf//// r12 is the intra-procedure call scratch register, and is not saved// r2 & r3 are filled with two other values that must be saved with the context// r2-r11 (10 registers) can then be saved with a single instructionasm volatile("mrs r0, psp \n""mrs r2, control \n""mov r3, lr \n""stmdb r0!, {r2-r11} \n": // output"=r"(result): // input: // clobber"r0", "r2", "r3", "memory");return result;}

author: westfw
author_rank: Super Contributor
timestamp: January 15, 2016, 02:42:18 am
content: QuoteThe maximum offset for baseReg/offset addressing is only 4095; often peripherals are further apart than that (I had two CM3/4 datasheets handy. The TI ARM3s have their GPIO ports spaced 4k apart. An Atmel SAM3X has all the GPIO ports within a single 4k block. huh.) (This is a good example of how the 32bit address space is both blessing and curse. You COULD fit a lot of peripherals inside 4k, but chips generally don't.)Using a 12bit offset (instead of 0..1020), or registers beyond r0..r7 pushes you into thumb2 territory. 32bits long and not available on CM0...

author: theatrus
author_rank: Frequent Contributor
timestamp: January 15, 2016, 03:50:08 pm
content: Quote from: c4757p on January 14, 2016, 08:23:59 pmThere is one C keyword which can be useful and needs to be specified in certain cases as the C standard assumes a lax default: restrict.In some C code forcing nothing to alias via a compiler flag would be disastrous.https://en.m.wikipedia.org/wiki/Restrict

author: nctnico
author_rank: Super Contributor
timestamp: January 15, 2016, 03:58:10 pm
content: Quote from: westfw on January 14, 2016, 07:09:35 pmSmall oversight indeed... but this is how a decent C compiler for ARM would solve it by putting a constant with the register's address somewhere close to the function:ld r1,[pc+20] #get pointer to register's address 20 is just fictionalld r2, #read valueor r2,r2,bit_value #modifyst ,r2 #write valueThat is 8 bytes worth of instructions.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: January 15, 2016, 05:57:53 pm
content: Quote from: westfw on January 15, 2016, 02:42:18 amIndeed I was too lazy to look up the according opcodes for Thumb-2. In the PPC world cores like e200z7 have load/store instructions with a signed 15bit offset, so with one small data area (SDA) pointer you can address 64k.

author: bson
author_rank: Unknown
timestamp: January 15, 2016, 09:53:58 pm
content: Quote from: westfw on January 15, 2016, 02:42:18 amJust bite the bullet and have each device instance have its own configurable base address. With a 12 bit offset limitation the compiler has to emit these constants anyway. 4 bytes is a small price to pay for the flexibility and namespace hygiene it offers. Something like this (just a rough stab at an example I typed up for this post):Code:// Example#ifndef __NXP_GPIO_H__enum BaseAddrnamespace nxp_io {// Non-banded GPIO. Subclass and replace to utilize banding when// available. All inlinable, simple ops.class GpIo __novtable {public:struct bits __packed {uint16_t _enable; // Pin enablesuint16_t _ub_in; // Unbuffered inputuint16_t _l_out; // Latching out};protected:struct bits& _base;public:Gpio(uintptr_t base_addr): _base(*(struct bits*)base_addr) {}void set(uint8_t bitnum) { _base._l_out |= 1<<bitnum; } // rmwvoid clear(uint8_t bitnum) { _base._l_out &= ~(1<<bitnum); }// Note this is const. Some devices are volatile in that they clear// non-persistent status bits, but gpio reads are const. This// yields undefined behavior if another thread or context// (e.g. interrupt) is racing to set/clear, but that's actually a// reasonably expected behavior.bool test(uint8_t bitnum) const { return (_base._ub_in & (1<<bitnum)) != 0; }};} // ns nxp_io#endif // __NXP_GPIO_H__#include "board_conf.h"// the above implies:// using namespace nxp_io;// the io_config contains a set of enums with base addresses, processor dependent and// imported from the board config.Gpio port_a_output(io_config::GPIO_A_BASE_ADDR);Timer timer_1(io_config::TIMER_1_BASE_ADDR, 1000); // 1kHz prescaleint main() __noreturn {for (;;) {port_a.set(io_config::led_blinker);timer_1.delay(500); // In prescale unitsport_a.clear(io_config::led_blinker);timer_1.delay(500);}// not reached}

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: January 15, 2016, 11:41:08 pm
content: Quote from: nctnico on January 15, 2016, 03:58:10 pmA decent ARM chip is so fast and has so much memory that the 'inefficiency' isn't an issue.You could try tweaking a poor compiler to make better code, or bite the bullet and write it all in optimized assembler, but the whole point of a compiler is to get away from that sort of thing. Just accept that RISC architecture needs more instructions to do the job, and don't worry about it.8 bit PICs are a bit more code efficient than AVRs, but their instruction cycle timing is 4 times slower at the same clock speed. ARM needs even more cycles to do the job, But AVR tops out at 20MHz, so even a 'slow' ARM can beat it inmostapplications.

author: westfw
author_rank: Super Contributor
timestamp: January 16, 2016, 02:24:34 am
content: QuoteThe "or" instruction is 4 bytes, and the first load has a 4-byte constant (in program space), so I'd call it 14 bytes...And it's almost exactly why I had in my first message about this, except it doesn't do any atomicity handling.real code (with real peripherals) is more likely to look like (10-12bytes):Code:ldr r3, [pc, #8] ; 32-bit constant gpio base.mov r2, #bitvalue ; could be 2 or 4 bytes.str r2, [r3, GPIO_BITSET] ; store to bitset reg.QuoteQuoteQuoteYes, to all of those. And my point (if I have one) is not to complain about the ARM architecture or 32 bit efficiency; I'm just pointing out that the 32bit address space does have pretty direct consequences on "code density." It's the sort of thing that makes an 8-bit programmer shake their head, and it becomes a bit worrisome when ARM manufacturers start offering really cheap "8-bit replacements" that DON'T have "so much memory", and whose libraries still assume you do. And it's a bit annoying to have an assembly language that is so ... difficult to predict, in what is supposed to be a RISC environment (admittedly, things get cleaner if you use a real 32-bit ARM instructions, and not thumb/thumb2 "compressed" instructions.)The other interesting thing is ... you have to think about how you actually DO GPIO/etc. That single-instruction bitset in AVR is just fine for a constant bitvalue on a constant pin. But it doesn't work if either one is a variable. By the time you get to an arduino-like digitalWrite(pin, val) function where everything is variable and there's some mapping involved, the AVR code has gotten "bloated and slow" and complicated, while the ARM code is ... about the same (and it's now smaller than the AVR code.)

author: dannyf
author_rank: Super Contributor
timestamp: January 16, 2016, 12:21:40 pm
content: QuoteThat's generally true for modern mcus in most applications, including the 8-bit mcus, in the sense that 1) speed / memory is generally not the constraining factor; and 2) if it is, you can always step up to a bigger chip.It is a fool's errand to pick a generic mcu based on its core or data width. What distinguishes one mcu from another is its peripherals, vendor support (hardware + software), corporate sourcing strategies and price if you are unfortunate.This "ARM" thing is a fad. A good fad from an ARM investor's point of view,

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: January 16, 2016, 01:35:36 pm
content: Quote from: westfw on January 16, 2016, 02:24:34 amAs pointed out before, on Cortex M3 and above you can (usually) use bit banding on GPIOs. Well, it the GPIO registers are in the bit banding area - but they usually are.However my understanding of bit banding is that internally, it's still a read/modify access on the whole register while using set/clear registers will really only affect the bit.So while the read/write instruction for bit banding is still single-cycle, internally a bit banding write results in two back-to-back bus accesses and a read typically creates a stall cycle.

author: Kalvin
author_rank: Super Contributor
timestamp: January 16, 2016, 01:47:53 pm
content: Quote from: 0xdeadbeef on January 16, 2016, 01:35:36 pmCortex M4:http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0439b/Behcjiic.html"The processor does not stall during bit-band operations unless it attempts to access the System bus while the bit-band operation is being carried out."Cortex M3:http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.100165_0201_00_en/ric1417773736773.html"The processor does not stall during bit-band operations unless it attempts to access the System bus while the bit-band operation is being carried out."

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: January 16, 2016, 05:02:07 pm
content: Hm, I'm not quite sure why you quote that as it's less precise than what I wrote above. But just to show that I can quoteinfocenter.arm.comas well (but beware: that site tends to semi-crash my Firefox):Quote

author: Kalvin
author_rank: Super Contributor
timestamp: January 16, 2016, 05:20:28 pm
content: Sorry, I should have bolded the text I was referring to.Quote from: Kalvin on January 16, 2016, 01:47:53 pmI interpreted that you were discussing setting and clearing individual bits using the bit-banding operations (read/modify access). Thus the quotations to the reference material and it should be a single cycle action without stall.Reading the bit value from the bit-banding area and the using its value in the next instruction will create a stall.