What µC are you preffering

[Attobos]

Hi, which µC are you preffering and why?
Where to find a good reliable microcontroller, well documented, good debug features, fast to program, easy to learn good IDE, good programmer/debuger?
Or is there not the one and really depends on your needs what you prefer and which manufacturer you choose?

[balage]

Hi,

The microcontroller thing depends on your needs. But generally if you are a beginner and looking for something to start with than I would suggest Arduino. You can get familiar with programming and can learn electronics related thing as well. It is very well documented, there are a lots of sources.

For example in my projects I generally use Atmel MCUs (programmed in Atmel Studio in C), especially the Atmega series. If I want to do something for my own or a proof-of-concept than I use Arduino that is fast to program, easy to interface with things and cheap. If I need more I use something embedded e.g. Raspberry, but than I ask somebody to program it.

[wraper]

I prefer Silicon Labs EFM8. Particularly EFM8UB1 for USB HID devices. They are cheap, require no external components besides decoupling caps, have built in Vreg, free IDE, easy to debug.

[Siwastaja]

STM32 due to large selection of devices, most with fairly good set of peripherals, and affordable pricing.

Not interested in IDE/debugging environment.

Inconsistency in peripherals between devices (hindering code reuse), poorly maintained documentation (where the documentation matches the original design intent, not how the implementation actually works - see separate "errata" to partially find out what they actually sold you, reverse-engineer the rest) are definite cons, but not showstoppers.

[balage]

So my answer is, I pick whatever I found the most convenient for the job and fits the bill.

Yes, but to use a specific family (if they fits the spacs) or a specific vendor is better as you are familiar with the vendor specific things, isn't it? You also care about which one you have used earlier, right?

[Siwastaja]

So my answer is, I pick whatever I found the most convenient for the job and fits the bill.

Yes, but to use a specific family (if they fits the spacs) or a specific vendor is better as you are familiar with the vendor specific things, isn't it? You also care about which one you have used earlier, right?

There is less difference than you might think. ARM standardizes the core, and thus the compiler and the tools are the same as well (if this is not true for someone, it's their problem. I use gcc, make, gdb and so on, and completely avoid all "different tool" issues.)

Even the peripherals between different ARM vendors are kinda similar in design principles. If you have made ADC work on one, it will be very similar on the next one. It's either one-hour job of finding out which library usage example to copy-paste, or a two-hour job of going through the registers with the manual. (The latter way allows you to take actual control of things later when you need any advanced features of those peripherals play together with your system. For example, in ADC, this would be injected channels, triggers from another peripheral, etc.)

On the other hand, there are variations even inside product families; STM32 is notorious for the fact that almost every device you pick has re-implemented basic peripherals and they are broken in a different way than the previous one you worked with.

If you can handle different STM32 products and product lines, there is little difference going for other ARM Cortex-M manufacturers.

STM32 is quite a good for a beginner, because they give you the false impression of giving you a product family, ecosystem, unified tools and all that shit. And when once hit the bullet, you find out the hard way there is no consistency, and not even stable tools, let alone libraries, but something "new" every other year. Now committed to this pile of steaming shit, you need to get the things done, and learn how to cope. After graduating this harsh reality, you are ready for any MCU you'll ever find!

[RoadRunner]

I have worked with many STM32 at work. After messing with many silicon level bugs throughout the product range, crappy driver library. Won't touch STM32  even with stick. Production also always have issue with sourcing the right part because STM32 had 1Zillion variant of every chip.

If going with ARM i will take NXP. with MIPS will take PIC32.  For Low power go with MSP430 or XLP PIC.

[brucehoult]

Hi, which µC are you preffering and why?
Where to find a good reliable microcontroller, well documented, good debug features, fast to program, easy to learn good IDE, good programmer/debuger?
Or is there not the one and really depends on your needs what you prefer and which manufacturer you choose?

It depends on what your needs are!

How much I/O, and what types? How big will your program code be? How much data? What processing speed?

I keep a few 8 pin ATtiny85's on hand. There's a lot of places you can just poke one. They need zero external components, start up at 1 MHz from the factory but you can switch them to 16 MHz for a bit more ooomph. Six I/O pins (but be cautious about reusing the reset pin), up to 4 as ADCs, 8 KB FLASH, 512 bytes RAM, 512 bytes EEPROM. About a US$ each from Digikey etc in small quantity. Easy to download programs to using an Arduino as a programmer, using either the Arduino IDE or avrdude directly. Use Arduino libraries or bit bang the registers yourself -- it's all easy.

If you need more I/O then the good old ATmega328 has four times the I/O, program size, RAM for $2 each in DIP-28. And the ATmega2560 has another 4x the I/O and RAM and 8x the program size for $10. Sadly with so many pins they only come in BGA and 100-TQFP, so it's generally better to buy them on a $10 board -- same price as the bare chip, so why not? e.g. https://www.amazon.com/dp/B07TGF9VMQ

The only thing is all these run at exactly the same speed, run full speed only with 8 bit data, don't have an FPU etc. It's enough speed for many many purposes.

The next thing that's super easy to use, with lots of documentation, libraries, examples is the $20 Teensy 4.0. For that you get a 600 MHz 32 bit dual-issue ARM CPU with FPU, 1024 KB RAM, 2048 KB flash, 40 I/O pins (23 easier to use than the others) https://www.pjrc.com/store/teensy40.html

You might consider a Teensy-LC for $12. It's got the same RAM, less flash, less I/O than the ATmega2560 at the same price but maybe around 10x the CPU processing power (but 20x less than the Teensy 4).

Again, Teensy board have a fantastic out-of-the-box getting started experience, great documentation and examples, work with the Arduino IDE and libraries or not -- your choice.


The RISC-V CPUs and boards coming out of China are looking very interesting.

The Longan Nano is $5 bought from China, $10 on Amazon. For that you get a 108 MHz 32 bit CPU, 128 KB flash, 32 KB RAM, a similar amount of I/O to an ATmega328 (swings and roundabouts) but 10x to 20x the processing power. And you get a small LCD display and plastic case thrown in for your $5.

There are also other boards using the same GD32VF103 chip -- which is close to being a clone of STM ARM chips with suspiciously similar product codes (and is in fact physically pin compatible) but with RISC-V CPU instead of ARM.

There are also the Kendryte K210 based RISC-V boards. These have pretty incredible specs, but a reputation for being not very well documented and hard to work with.

I think beginners should probably stay clear of these Chinese RISC-V boards for a while yet, even though they're very cheap and powerful.

[balage]

Yes, but to use a specific family (if they fits the spacs) or a specific vendor is better as you are familiar with the vendor specific things, isn't it? You also care about which one you have used earlier, right?

I only use the ones with very good API libraries and preferably an RTOS, so I don't care how the registers are used.
To me, anything with a standard C API is good. It takes me a few minutes to learn a peripheral with C API, so porting an entire project takes less than an hour. That's the cost I can take.

Ah, yes, that is clear for me now. This is how I should do things also, instead of diving into registers of atmegas... I am planning to move to Texas Instruments' MCUs, but the beginning of learning path is always a pain. And time consuming. I've started twice, but it was so complex I gave it up.

[ali_asadzadeh]

For ultra low price  in single qty (under 0.1$) I would go with padauk MCU, like PFS173 (have 8-bit ADC too), nothing beat's that thing, as a bounce you can build the programmer with a STM32 too, there's a thread on that in eevblog too.

For higher performance ones I would go to STM32 , like STM32F030KT6 for 0.5$ and go up till STM32H750 for around 4$,you can get 480MHz M7 with lot's of Stuff, for even higher performance I would go into i.MXRT series from NXP.

Also there is the G0 and G4 series from ST, that I would consider soon, when they are easily sourced from china with good prices.
Right now,I'm design a cool product that contain several paduak parts and an i.MXRT part and a GOWIN FPGA

[luiHS]

 
The NXP i.MXRT series, are cheap and very powerful (cortex M7 500/600Mhz).

MCUXpresso is the NXP IDE for their ARM microcontrollers, totally free, including the GCC compiler. I think today is much better than the ST CubeMX environment for the STM32.

I like many things about MCUXpresso, and with each new version they release, they include very useful features. I really like the SDK with many examples of source code for the most common applications, which you can import and use directly from the IDE.

I started using the Microchip PIC32 many years ago, then I decided to migrate to ARM with the STM32 of ST, already within the ARM world I decided to try the Kinetis of NXP with its MCUXpresso IDE, and now I am migrating to the i.MXRT NXP RT1020.

I think that today the NXP i.MXRT is the best option for any project with microcontrollers. The MCUXpreso development environment is fantastic, very easy to use, you have practically everything you need to work optimally, and all for free.

[mark03]

What I see in this thread is that [duh!] the preference depends on your criteria.

I use a lot of STM32 at work, so for me as a hobbyist, it is almost always faster to choose an STM32 that I am familiar with than to learn the quirks of a different vendor's ARM Cortex-M.  For me It makes sense to pick a family that I like and stick with it, so I tend to pick STM32L4 series for almost all hobby uses.  (Parts cost is irrelevant for a hobbyist, so there is no reason to scale down to an M0 or M3 core when you are already familiar with another one.)

Other than familiarity, your software strategy should probably be the main deciding factor.  Most people seem to use the vendor driver libraries, so if that describes you too, you should be swayed toward families with better SW libraries, and detailed documentation is slightly less important.  Me, I cannot stand using vendor code, so I generally write everything from scratch.  In this context, proper documentation in readable, grammatically correct English is *essential*.  I recently sat down with the i.MXRT 1060 reference manual to answer some questions about a design I was contemplating.  Four hours later, I had decided to use an STM32H7 instead, even though I would have preferred the extra horsepower of the NXP chip.  I cannot abide poor documentation, and the NXP reference manual was among the worst I have seen.  I could tell I would be wasting countless hours reverse-engineering the part if I were to choose it.  (In truth, almost every vendor's documentation nowadays is terrible, when compared to the 1980s or 90s, but ST Micro "wins" here by earning a C- or D+, rather than an F.)

[Styno]

I make primarily low wireless power sensors and have used MSP430FR2433 and FR2155 quite a bit. I especially enjoy the MSP’s simple clock tree and peripherals (i.e. interrupts and pullups/downs on all I/O). FRAM is great as it handles more like battery backup SRAM than EEPROM/flash. For small/fast projects there is Energia (Arduino) and for more serious work there is CCS. Energytrace++ is great for optimizing power and Launchpads for programing.

I also worked wit STM32L0 but found that much more complex, e.g. only one interrupt on each unique pin number for all ports? C’mon thats just backward.

[ogden]

Or is there not the one and really depends on your needs what you prefer and which manufacturer you choose?

Right. One size do not fit all. That's why so many various microcontrollers exist. In case you are inexperienced hobbyist - just pick Arduino. After you done mastering it, *then* most likely you will have better idea of what you actually *need*.

This is recurring question which is the same as to ask one single kind & size of nail for every possible carpenter work.

[daqq]

There's no 'One MCU to rule them all, one size to fit them all', otherwise they would have an absolute monopoly since no one would want to buy anything else.

That said, the STM32 series covers a pretty broad range of applications while managing to be reasonably coherent within the family and having reasonable tools. Expect the occasional issue.

[MarkR42]

I'm using the "TinyAVR" Microchip/Atmel chips, attiny1614 (small+ easily hand solderable), attiny3217 (top of range, more tricky) etc, they are relatively new and there are not a massive number of examples. They're far less popular than the older AVR chips or the PIC chips, but I can actually understand the datasheets.

I haven't really compared enough to know how good is the cpu core, of course it's an 8-bit core, but Jay Carlson seems to like it compared to other 8-bits.

I find the 8-bit chips easier to understand than the 32-bit stuff which is so common nowadays.

[norand]

From a strictly learning point of view, I started learning from the Arduino (using Arduino Language  ). It has it's drawbacks, but will give you a high level understanding of how to do simple tasks on a microcontroller, and there are plenty of examples and YouTube tutorials.

Once I got the grip of Ardunio stuff I started working on any Atmel chips I could program with an Arduino e.g AtTiny85 and ESP8266 and started learning proper C. However when I got to Uni, we were taught C on ARM based chips such as mbeds, and STM32 discovery kits. I found I have a much better understanding doing it this way, and wished I'd gone from Arduino straight to an STM32. There's also a fair few YouTube tutorials for some of there HAL libraries, and the MXCube software (GUI interface for microcontroller configuration) can be quite good from a beginners point of view, however I do try to avoid it where possible as sometimes there are problems you can't see under the hood!

I have never used a PIC, but a lot of the old folks I have met in Industry love them , I would expect a similar level of tutorials/examples to the STM32 to be available for the PICs too, but I've never heard anything bad said about them!

[ogden]

wished I'd gone from Arduino straight to an STM32

Right. Going Arduino->stm32duino->stm32 is good idea, especially using "blue pill" for stm32duino. When done with *duino, "blue pill" can be used for for bare stm32 programming as well. Worth to mention that Arduino, "blue pill" stm32f103 board and ST-Link programmer do not cost much.

[NorthGuy]

Hi, which µC are you preffering and why?

When a chicken hatches from an egg, he thinks the first object he sees is his mother. This is called imprinting. Of course, the object may be anything and the chicken's opinion about how his mother looks like is terribly biased.

The same with MCUs. The first one you use, you're going to like (unless, of course, you do some terrible mistakes and decide to blame them on the poor MCU). Same happen to other people. And that's what they tell you.

Then through the years you will have different projects, will try different MCUs. New MCUs will appear as well. In the end, they're not so much different. And the differences between families lie mostly in your emotions, skills, preferences etc.

Of course, you choose MCU for your task, so the set of MCUs you ever use will depend on what your projects are. And that's how you should start. Decide what your project requires, do a search, and use what fits.

[ogden]

And the differences between families lie mostly in your emotions, skills, preferences etc.

This is true only if *all* MCU's can be classified as "chicken". To say that AVR and ATSAM differ only in your emotions, skills and preferences is 

[nigelwright7557]

I am into ADC and  USB so using a PIC micro with Harmony was about the easiest way to go.
Harmony has modules for basic system i/o and clock, USB and ADC built in so saves a lot of time and hassle.
MPLABX is the IDE for PIC's. Definitely not the easiest thing to use but is functional once you find your way around.

[luiHS]

 
To my previous comment, I forgot to mention that I also tested the ATSAME70 Cortex M7 from Atmel / Microchip, series S70, E70, V70.

I dismissed them immediately, because the development environment is very bad, horrible, I have not seen in my life something worse done and more neglected. Besides the documentation is also terrible.

I have also tried Teensy boards that work with Kinetis microcontrollers, under the Arduino development environment. The hardware is fine, but the Arduino environment is terrible, very basic, I prefer to work with MCUXpresso for these boards, or directly create my own hardware with Kinetis or RT1020.

My priority list would be this:
1.- NXP i.MXRT, RT1020
2.- NXP Kinetis MK66, MK26
3.- ST STM32

Completely discarded for a long time, PIC32 and ATSAMS70 (S70, E70, V70), both from Microchip.

[mcovington]

For the cheapest and simplest, I have seen here two mentions of ATtiny and none of the low-end PICs.  What is the advantage of ATtiny?  (Just asking, not debating.)

[amymcneil]

My current fav is the STM32 family in all their glorious idiosyncrasies.  Mostly because the documentation doesn't suck too badly and I've put the time into understanding members of the STM32F0/F3/F4 families. I've done a number of projects with them and have been happy with the results and the minimal pain involved. This has been using the GCC tool chain along with the Black Magic probe, running in a UNIX type environment. The direct connection between GDB and the Black Magic probe make things really easy (assuming you aren't repulsed by GDB). WARNING: When moving from one STM32 chip to another, read the documentation of the peripherals you are planning on using CAREFULLY! You'd think that the UART would have the same features across all of the STM32 family, but NO! Ditto some of the other subsystems. The ARM core & ARM specified peripherals are consistent, though.

My second choice is the Atmel/Microchip AVR family. I've used the ATmega32U4 in a USB connected application for my employer using the awesome LUFA USB library (http://fourwalledcubicle.com/LUFA.php) and a couple other work projects using the atmega328 chip. All of these projects have been done using the GCC tool chain (avr-gcc) running under Windows. The projects were relatively simple, staying with one tool chain makes things easier to document for future coworkers.

I don't usually use the chip manufacturers' libraries except as a reference on how to program the peripherals. Way too often adding one of those libraries results in far much bloat and not enough space for *my* stuff!

I prefer working with multiple text windows rather than an IDE, most probably because I'm an old school UNIX geek, that's the way I'm most comfortable with. 'make', properly set up (feels like more art than skill some days), can do wonders. If you use Windows and want a decent IDE for the AVR series parts, the Atmel AVR Studio offering is a great way to get up and running (price is right, too - free!), assuming you are already comfortable with direct programming of the chip and the 'C' programming language. The documentation that Atmel provided for the AVR series of chips is excellent. Very readable, easy to understand and detailed.

If you are just getting your feet wet, start with the Arduino environment. Great beginner's environment to get familiar with the world of microcontrollers (two of my children have learned programming and basic electronics this way). Once you start feeling like the environment is limiting you, you're ready to move on to something like AVR Studio, or bare metal programming with GCC.

[NorthGuy]

And the differences between families lie mostly in your emotions, skills, preferences etc.

To say that AVR and ATSAM differ only in your emotions, skills and preferences is 

LoL!

Absolutely so. If you want to pick up your first MCU to start fiddling with, whether you select AVR or SAM, will not make any difference whatsoever. And if someone thinks differently, this is because of his emotions, skills, preferences etc.

[SiliconWizard]

Yeah.

We've been so lucky lately with two threads, one about favorite MCUs, another about HDLs, similar in essence, and they invariably trigger the same kind of posts and reactions. *sigh*
 

[techman-001]

Yeah.

We've been so lucky lately with two threads, one about favorite MCUs, another about HDLs, similar in essence, and they invariably trigger the same kind of posts and reactions. *sigh*
 

Did you miss the recent one about "what's your favorite OS" ?

[ogden]

Absolutely so. If you want to pick up your first MCU to start fiddling with, whether you select AVR or SAM, will not make any difference whatsoever.

Complexity of those MCU's differ. Amount of user manual pages to read indeed makes difference - for beginner. The simpler the better.

[westfw]

Well, I do mostly stuff where the requirements are modest, the programming language is likely to be C, and my primary concern was "can I get a good deal."   So i've bought some PICs in various packages, some 8051s, some AVRs, some MC9S08, and more recently various ARM chips.  Usually when they showed up cheap on eBay, or in Newark's "overstock" area, or cheap boards from Aliexpress, in "bulk" quantities (for a hobbyist, anyway.  100 at a time or so.)DO NOT DO THIS.  It's stupid.  Any money I've saved on chips I've spent on programmers, or on the time spent to get a set of tools installed and working to the extent of being able to use them.  :-(

[brucehoult]

Well, I do mostly stuff where the requirements are modest, the programming language is likely to be C, and my primary concern was "can I get a good deal."   So i've bought some PICs in various packages, some 8051s, some AVRs, some MC9S08, and more recently various ARM chips.  Usually when they showed up cheap on eBay, or in Newark's "overstock" area, or cheap boards from Aliexpress, in "bulk" quantities (for a hobbyist, anyway.  100 at a time or so.)DO NOT DO THIS.  It's stupid.  Any money I've saved on chips I've spent on programmers, or on the time spent to get a set of tools installed and working to the extent of being able to use them.  :-(

I basically can't be bothered to learn something that doesn't have gnu binutils, gcc, and ideally gdb (but I'm fine with printf debugging) It doesn't matter if the gcc is a little old (my avr-gcc is 5.4.0 from .. omg .. June 2016). I know the flags. I know how the machine-independent optimizations work (pretty well!). I know how to sling around .o and .elf files, extract them to hex or get the compiler to generate assembly language and then assemble that ... everything is just familiar and comfortable across a dozen or more instruction sets.

Preferably it's possible to program boards over USB, and stand-alone chips using something I already have e.g. it's so easy to use an Arduino Uno to program bare AVR chips. In the last week or so a friend had a commercial board (Blinkstick Square) with 8 RGB LEDs and an ATtiny85 in SOIC-8 and I was able to use an Uno and a test clip to replace the firmware with some code of my own devising to do something totally different with the board.

I know the proprietor of this site likes PIC and runs down AVR "fanboys". As far as I can make out they're pretty damn similar in peripherals, RAM, flash, price etc across a wide range with little technical reason to choose between them. I guess I just like that AVR is friendly enough to conventional compilers for high level languages that I can use the same toolchain family as I do for ARMv7, AARMv8, RISC-V, and my x86_64 workstation. And the Arduino project has resulted in a lot of highly compatible boards at many capability levels -- and not only with AVR processors -- which is great too. I believe there is Arduino IDE and library and compiler support for some PIC32 (i.e. MIPS) boards, but not 8 bit PIC. The same goes for Platformio which is pretty darn nice, totally free for all supported platforms now (thanks to sponsorship from Western Digital and SiFive), and supports a ton of stuff including PIC32 .. but not 8 bit PIC.

[hans]

And the differences between families lie mostly in your emotions, skills, preferences etc.

To say that AVR and ATSAM differ only in your emotions, skills and preferences is 

LoL!

Absolutely so. If you want to pick up your first MCU to start fiddling with, whether you select AVR or SAM, will not make any difference whatsoever. And if someone thinks differently, this is because of his emotions, skills, preferences etc.

Of course you can fiddle with any part all day, but if you cannot follow the documentation (overwhelming RTL of modern ARM chips for a beginner), you won't get very far.
This is why Arduino can still be an ideal platform to start with. People first need to develop an appreciation for the connection between software and hardware worlds, and can then dive deeper to find how the split, at a register level, occurs.

I think this learn ranking for AVR and SAM parts is also still true, or ideal at best.

Whether someone sticks with a particular part/family of parts can be somewhat irrational. Some people stick with 8-bit controllers because "it's so simple, I like it!". Is that objectively the best design solution for every project? Probably not, but people will try to make it work like it's 2005. And honestly there is nothing wrong with that. I stick to 32-bit STM32s because they have served me well, and I'm too lazy to switch back to C and abandon my C++ embedded library & creature comforts I'm adjusted to. Which means that in some cases, I have got a few K of code running before I can even blink a LED.

[Psi]

For quick development i go for the ATTiny or ATMega, but this is mainly because i know it so well. 
Price wise they're not very cheap compared to other MCUs.

For low price, or if i need a little more power than ATTiny/Mega, i go for STM32F0
(The STM32F103 might actually be better but i've never actually used one yet)

If i need something super powerful i go for STM32F4 (i wouldn't mind trying F7 but have not needed to yet)

If having Wifi would be useful i go for the ESP32 (i used to use ESP8266 but support for newer wifi networks on ESP8266 is lacking)

If i need EEPROM i go for ATTiny/Mega or STM32L series depending on price and speed requirements.

[SiliconWizard]

Yeah.

We've been so lucky lately with two threads, one about favorite MCUs, another about HDLs, similar in essence, and they invariably trigger the same kind of posts and reactions. *sigh*
 

Did you miss the recent one about "what's your favorite OS" ?

Which one?

[techman-001]

Yeah.

We've been so lucky lately with two threads, one about favorite MCUs, another about HDLs, similar in essence, and they invariably trigger the same kind of posts and reactions. *sigh*
 

Did you miss the recent one about "what's your favorite OS" ?

Which one?

https://www.eevblog.com/forum/programming/what-os-do-you-use-for-embedded-software-development/msg2952618/#msg2952618

[SiliconWizard]

https://www.eevblog.com/forum/programming/what-os-do-you-use-for-embedded-software-development/msg2952618/#msg2952618

- We're getting off-topic, sorry -

Oh, this one was not quite in the same vein IMO. It didn't ask for anything favorite, just what people were actually using, and was a lot more specific. It didn't trigger the same kind of reactions either, I think the overall posts in it were quite constrained and reasonable.

[techman-001]

For quick development i go for the ATTiny or ATMega, but this is mainly because i know it so well. 
Price wise they're not very cheap compared to other MCUs.

For low price, or if i need a little more power than ATTiny/Mega, i go for STM32F0
(The STM32F103 might actually be better but i've never actually used one yet)

If i need something super powerful i go for STM32F4 (i wouldn't mind trying F7 but have not needed to yet)

If having Wifi would be useful i go for the ESP32 (i used to use ESP8266 but support for newer wifi networks on ESP8266 is lacking)

If i need EEPROM i go for ATTiny/Mega or STM32L series depending on price and speed requirements.

The STM32F103 isn't better than the STM32F0, certainly 3 -5 x faster, but also a lot older. I used the STM32F0 first and hated the GPIO config of the STM32F1 when I tried it a few years later. The STM32F103 may also be missing a few peripherals such as the Touch Sensor, Comparators and DAC etc. Not to mention bugs such as not being able to read the DBG registers internally unless debugging hardware is attached (ironically, later fixed in the 'compatible' clones).

How about the STM32WB55 for inbuilt wireless ?

[Psi]

Interesting.
The main reason i was wondering about the STM32F103  is that everyone else seems to be using them and they are cheap due to volume.

Never looked at STM32WB55 Looks to be BLE/Zigbee. I usually use full wifi

[reyntjensm]

Hi everyone,

I started as a child with a PIC(microchip) kit from Velleman, a shitty brand in Belgium. It never worked out for me.
With the release of the Arduino i was finally able to start using microcontrollers and got stuck with electronics since then.
As i wanted i reliable microcontroller for my projects and i was over my arduino-period, a teacher from school told me about Infineon XMC series and i started to work with this. It took me so much time to get my first project working since the documentation is so bad/hard to find so i gave up and started with STM.
I'm using system workbench and cubeMX for all my projects and achieved very good results with this.
Documentation is easy to find and the software(cubeMX) is very handy and easy to use!
So i would say STM is a good brand to start with, example projects,documentation , chips for every application at a good price point and they work fine.
I hope this input from a beginner might be handy for somebody and i don't receive any money from STM for this.

[steenerson]

I prefer Silicon Labs EFM8. Particularly EFM8UB1 for USB HID devices. They are cheap, require no external components besides decoupling caps, have built in Vreg, free IDE, easy to debug.

Very cool, 3x3mm chip with a built in USB bootloader for a dollar in unit quantity. I have a couple things where I just need a USB port and I've been using 5x5mm STM32s that cost 3-4x that, and they aren't even USB programmable out of the box. Think I'll grab one of these dev boards, thanks!

[brucehoult]

I prefer Silicon Labs EFM8. Particularly EFM8UB1 for USB HID devices. They are cheap, require no external components besides decoupling caps, have built in Vreg, free IDE, easy to debug.

Very cool, 3x3mm chip with a built in USB bootloader for a dollar in unit quantity. I have a couple things where I just need a USB port and I've been using 5x5mm STM32s that cost 3-4x that, and they aren't even USB programmable out of the box. Think I'll grab one of these dev boards, thanks!

Ok, those look interesting enough to check out.  I've ordered a $30 dev kit, a $6.65 dev board (cheaper chip without USB), and the last four EFM8UB11F16G-C-QSOP24 DigiKey had in stock. The chips were $1.38 each, though yes they're $1.03 at 1000 qty (which I'll never need).

Those are about 5 mm wide (plus pins) by 8 mm long which is a lot bigger than what you said so I'm not sure what you found -- but I don't like dealing with things I can't see and hand-solder :-)

The only thing that is ugh is 8051.

The dev board says it comes with a Keil license, so that will be a new experience. Internet also says there is a gcc for 8051 but I don't know what quality it is.

[wraper]

I prefer Silicon Labs EFM8. Particularly EFM8UB1 for USB HID devices. They are cheap, require no external components besides decoupling caps, have built in Vreg, free IDE, easy to debug.

Very cool, 3x3mm chip with a built in USB bootloader for a dollar in unit quantity. I have a couple things where I just need a USB port and I've been using 5x5mm STM32s that cost 3-4x that, and they aren't even USB programmable out of the box. Think I'll grab one of these dev boards, thanks!

Ok, those look interesting enough to check out.  I've ordered a $30 dev kit, a $6.65 dev board (cheaper chip without USB), and the last four EFM8UB11F16G-C-QSOP24 DigiKey had in stock. The chips were $1.38 each, though yes they're $1.03 at 1000 qty (which I'll never need).

Those are about 5 mm wide (plus pins) by 8 mm long which is a lot bigger than what you said so I'm not sure what you found -- but I don't like dealing with things I can't see and hand-solder :-)

The only thing that is ugh is 8051.

The dev board says it comes with a Keil license, so that will be a new experience. Internet also says there is a gcc for 8051 but I don't know what quality it is.

There is 16 kB version in QFN-20 and QFN-28 and 8kB version in QFN-20 (costs $0.6 @ qty of 1000). QSOP version is the most expensive.
EFM8UB10F8G-C-QFN20
EFM8UB10F16G-C-QFN20
EFM8UB10F16G-C-QFN28
BTW you can get USB VID/PID from Silabs for free.

[brucehoult]

I'm just a lot more confident using a QSOP or SOIC in a kitchen table project/prototype, possibly including soldering it to an adapter board to DIP. If I ever got to a product that I pay someone to assemble then that's different.

[Scrts]

I'm just a lot more confident using a QSOP or SOIC in a kitchen table project/prototype, possibly including soldering it to an adapter board to DIP. If I ever got to a product that I pay someone to assemble then that's different.

I'd go with QFN over leaded packages on any day. The bridging is so hard to clean with a leaded package, while with QFN a simple swipe with the correct iron gets it all done.

It also depends on PCB and solder mask. I remember the nightmares of soldering TQFP208 on a PCB that did not have solder mask between the pins. Soldering with solder mask between the pins make sit super easy and doesn't require hot air station.

[wraper]

It also depends on PCB and solder mask. I remember the nightmares of soldering TQFP208 on a PCB that did not have solder mask between the pins. Soldering with solder mask between the pins make sit super easy and doesn't require hot air station.

You don't need hot air station for TQFP, and actually it's completely counterproductive to use one for soldering. And in no way it will help with solder bridges unless you apply solder paste with stencil. Solder mask pad separation is not required too, you just need to know learn to do soldering properly.

[nctnico]

I'm just a lot more confident using a QSOP or SOIC in a kitchen table project/prototype, possibly including soldering it to an adapter board to DIP. If I ever got to a product that I pay someone to assemble then that's different.

I'd go with QFN over leaded packages on any day. The bridging is so hard to clean with a leaded package, while with QFN a simple swipe with the correct iron gets it all done.

That depends entirely on the PCB layout. If you have problems with bridging on QFP then you are not using enough flux and the tip is too small. Use a bigger tip and more flux. For hand soldering QFN you'll need footprints which leave about 0.5mm room to put a soldering iron on but I'd take QFP over QFN every day.

Regarding the type of uC: I've been very happy with the ARM controller from NXP (LPC series). There is good hardware compatibility between the devices so hardware drivers can be re-used and the serial bootloader is very mature / reliable.

[rx8pilot]

You don't need hot air station for TQFP, and actually it's completely counterproductive to use one for soldering. And in no way it will help with solder bridges unless you apply solder paste with stencil. Solder mask pad separation is not required too, you just need to know learn to do soldering properly.

I cannot agree with that statement. While you can certainly solder TQFP without hot-air - it is (along with most solder jobs) quite a bit easier with a pre-heated PCB. I use my hot-air system to get the PCB at around 100-125 or so and the solder flows VERY easily, evenly, and without bridges.

On the topic at hand - I prefer the ATMEGAs but only out of pure habit and unwillingness to go through another learning curve. I know the ATMEL system and can develop it quickly. The newer 0-Series 4808/4809 have a different architecture which forced me into a learning curve but nothing crazy. They are very cheap and easily available.

I almost always use VQFN packages because they are small and I already have them dialed in to my library.

[wraper]

I cannot agree with that statement. While you can certainly solder TQFP without hot-air - it is (along with most solder jobs) quite a bit easier with a pre-heated PCB. I use my hot-air system to get the PCB at around 100-125 or so and the solder flows VERY easily, evenly, and without bridges.

Don't agree with what? Hot air was mentioned not about preheating. And preheater not necessarily uses hot air. IIRC you made your preheater from hot air gun and machined piece of metal but it does not entitle it to be mentioned as "hot air" out of this context.

[rx8pilot]

Don't agree with what? Hot air was mentioned not about preheating. And preheater not necessarily uses hot air. IIRC you made your preheater from hot air gun and machined piece of metal but it does not entitle it to be mentioned as "hot air" out of this context.

Fair enough.....

To be clear - I use hot air the majority of the time as a pre-heating mechanism to make soldering considerably easier. It is certainly true that preheating can be accomplished without hot air. For manual PCB assembly, I usually do not use paste for most devices. I do have a precision paste dispenser, but it usually gets used to apply flux when I am hand-soldering.

Perhaps what I should have attempted to communicate is that a soldering iron alone is not a complete system for TQFP packages IMHO. Possible? Yes, of course but not very good.

[NorthGuy]

I'd go with QFN over leaded packages on any day. The bridging is so hard to clean with a leaded package, while with QFN a simple swipe with the correct iron gets it all done.

The bridging depends on the pitch. 0.65mm is usually not a problem. 0.5mm is Ok. With 0.4mm, the bridging is very hard to get rid of, at least for me.

But 0.4mm QFN is not fun neither, especially small ones. Pins are so small that I cannot really put enough solder on the footprint before heating. Then I need to add solder to pins manually, and I need really thin tip to get to the pins, and it feels like poking in the dark to me.

[brucehoult]

I'd go with QFN over leaded packages on any day. The bridging is so hard to clean with a leaded package, while with QFN a simple swipe with the correct iron gets it all done.

The bridging depends on the pitch. 0.65mm is usually not a problem. 0.5mm is Ok. With 0.4mm, the bridging is very hard to get rid of, at least for me.

But 0.4mm QFN is not fun neither, especially small ones. Pins are so small that I cannot really put enough solder on the footprint before heating. Then I need to add solder to pins manually, and I need really thin tip to get to the pins, and it feels like poking in the dark to me.

I'm glad I've stuck to 2.54 and 1.27 spacing packages so far. But I've just ordered a few chips (see above) with 0.635.

I've been moving around the world a lot (next international move is in three weeks from now) and can't carry a whole workshop of equipment with me -- I've just got a basic temperature controlled soldering iron. I buy little PCBs to break everything out to 2.54 spacing to go on a breadboard or protoboard *anyway* so tiny packages are utterly wasted on me.

[MarkR42]

I buy little PCBs to break everything out to 2.54 spacing to go on a breadboard or protoboard *anyway* so tiny packages are utterly wasted on me.

Yeah, absolutely, for evaluating devices break them out to breadboard-compatible packages.

Also, Oshpark's PCB service is so cheap for very small boards, you can just layout your own breakout boards (add a few smd passives if you like) for a similar price to buying off-the-shelf breaksouts.

I am a hobbyist, 2 years ago I'd never soldered a smd, but now I'm doing 0.5mm QFN with no real problem.

Except hot air guns, don't use a hot air gun on a part you want to use (it's ok to use it to remove a dead part) because I've killed a part or two with hot air.

I also decided that no-leads packages are actually easier to handle than small-leaded packages. The tiny pins can get bent or snapped easily. This is not an issue with QFNs, DFNs.

[NorthGuy]

I buy little PCBs to break everything out to 2.54 spacing to go on a breadboard or protoboard *anyway* so tiny packages are utterly wasted on me.

I do this too. I have dozens of these. This is very handly. However, I'm gradually moving more towards "everything on the PCB" approach as PCBs are now so easy to get (and hopefully this continues).

Except hot air guns, don't use a hot air gun on a part you want to use (it's ok to use it to remove a dead part) because I've killed a part or two with hot air.

The air temperature must've been too high.

[nctnico]

That depends entirely on the PCB layout. If you have problems with bridging on QFP then you are not using enough flux and the tip is too small. Use a bigger tip and more flux. For hand soldering QFN you'll need footprints which leave about 0.5mm room to put a soldering iron on but I'd take QFP over QFN every day.

I usually leave 0.25mm pad extension, which is totally fine for QFN with proper iron, but not enough for QFP. The reason drag soldering work is by wicking solder from across pins to pad extension, and it only works with long enough pad extension.

A large enough iron with large enough wicking capability (like those with a spoon inside) may also work, but I don't have a T12 station, and Metcal doesn't offer such tips for MFR series. My JBC station is small enough not to wick enough solder. If I use that C105128 spoon tip, I have to clean the tip for every 3 or 4 pins, which makes it very counter productive.

I have a 'spoon' tip as well but a big flat 4mm tip + flux works much better. I usually solder 3 to 4 pins in one go. When using lead free solder you definitely need the right temperature though. 330 degrees Celsius works best in my experience.

[ogden]

The main reason i was wondering about the STM32F103  is that everyone else seems to be using them and they are cheap due to volume.

When you work for the hobbyist masses - you use currently most popular chip. When you work for the mass production - you use cheapest chip. When your work description is "custom solution fast", you disregard all of above.

[Psi]

But 0.4mm QFN is not fun neither, especially small ones. Pins are so small that I cannot really put enough solder on the footprint before heating. Then I need to add solder to pins manually, and I need really thin tip to get to the pins, and it feels like poking in the dark to me.

yeah, i would recommend anyone new stay away from 0.4mm unless they have no other options.

I agree that QFN is easier/quicker to solder than QFP.
Usually you can just tin the pads, add flux and hot air a QFN to the board without much else needed. Get it to giggle with the hot air and you're good.
Some people (inc me) get a bit OCD about getting solder to flow up the sides of all the pads on QFN, but, if you used flux under it, it will have soldered correctly under the chip. So a side swipe isn't really needed, It does look pretty though

[NorthGuy]

Some people (inc me) get a bit OCD about getting solder to flow up the sides of all the pads on QFN, but, if you used flux under it, it will have soldered correctly under the chip. So a side swipe isn't really needed, It does look pretty though

Putting the exact amount of solder on centerpad is key. If you put too little, it may not solder. You may need to press the chip down hard to fix this. If you put too much, it'll create a cushion and then regular pins on one of the sides will sit too high. In such case the "side swipe" is absolutely necessary. I often make mistakes, one way or the other. Thus, I don't like QFN, and prefer TQFP where you can see pins and errors are easily fixed.

With stencil and paste, the amount of solder on the centerpad is regulated by the stensil, so QFN is certainly better than TQFP.

[Scrts]

Some people (inc me) get a bit OCD about getting solder to flow up the sides of all the pads on QFN, but, if you used flux under it, it will have soldered correctly under the chip. So a side swipe isn't really needed, It does look pretty though

Putting the exact amount of solder on centerpad is key. If you put too little, it may not solder. You may need to press the chip down hard to fix this. If you put too much, it'll create a cushion and then regular pins on one of the sides will sit too high. In such case the "side swipe" is absolutely necessary. I often make mistakes, one way or the other. Thus, I don't like QFN, and prefer TQFP where you can see pins and errors are easily fixed.

With stencil and paste, the amount of solder on the centerpad is regulated by the stensil, so QFN is certainly better than TQFP.

When I did not have a hot air station, I used to make small balls with the hand solder on the QFN pads and then solder the component to the PCB using enough flux. However, this cannot work on some components, that do not have the GND pads exposed and rely solely on the center square under the component itself.

[Doctorandus_P]

I definitely do not agree with:

The same with MCUs. The first one you use, you're going to like

When I was young microcontrollers were difficult to handle. You had to buy very expensive chips (starting around USD50) which had ceramic housings and a blob of glass and had to put them under UV light to erase them. Alternative were the Eprom based systems which needed some 40+ wires just to get a blinking led because you had to wire up data and address busses and such.

A few years later came the PIC16F84A. One of the fist with Eeprom. Everighing together in a simple DIP package, you didn't even need a crystal oscillator if the built-in RC was good enough. That was the first uC I bought. They were also cheap enough to buy a handful of them, because you know, hobbyists blow things up. I never got around to doing more than a few blinking led projects with the bloody thing. It had a completely abhorrent instruction set (Yeah only 20 or so instructions to learn). What a marketing bullshit.

Then came the AT90S1200, and quick thereafter the at90s2313 and ATMEGA8, which I all bought in various amounts. The internet was also booting up and information was increasingly easy to find. The 1200 was quite limited because of lack of RAM, and the only thing I ever did was to bitbang AN910 in it, which was programming software which interface between a serial port and the SPI bus for programming other Atmel AVR's. Bitbanging a uC in those days was by putting a few wires directly into the LPT port of your PC, and onto a breadboard with your uC. Not very reliable, but enough to bootstrap yourself on a low budget.

My sole reason for turning to Atmel was the availability of GCC for the AVR's. Programming a uC in C that is luxury!
After that I never attempted to even use any microcontroller that is not supported by GCC.

Over the years I've done some 50 odd projects with the ATmega's. and always liked them, and they were fit for my purposes, so for a long time I did not feel a need to learn a new uC family.  I briefly had a look at the ATtiny's, but I disliked them very much and quick. Instead of a decent sereal port they have a USI, the I2C (which atmel called "twi" for vague reasons) worked completely differently from the ATMega's, for which I had just written and debugged a nice I2C library. Right then I vowed to never use the ATtiny's again.

Nowadays such hardware implementation differences may be hidden in  software libraries, but this was all mostly before "arduino" even existed.
I could start a big rant about all the reasons I dislike "arduino" (no capital there), but I also see it's an easy way to get acquainted with uC's.
Just do not EVER use their half baked java based editor that is not worthy of the name IDE. If you want to start with "arduino" then at least use a decent IDE, such as anything supported by Platformio, or if you're on windows, the IDE that Atmel (now Microchip) distributes. I believe it's based on some Microsoft IDE and people seem to be happy with it.

Advantage of Platformio is that you can easily set up a complete tool chain and it is completely vendor independent. From whatever IDE you use with Platformio you can switch between projects with ATMEGA, ESP8266, Blue Pills, and some 20 or so other uC families. You can also work with "arduino", "mbed", and other platforms. It really is an amazing tool to try out some new uC and it's capabilities without much worrying about how to set up a complete tool chain for whatever uC you're using this week. It just pulls them from the internet somewhere.

A few years ago I decided that I wanted something "new". Nice small TFT displays became available and the ATmega's just do not have the horsepower to drive such an LCD. I do not want to wait to see individual pixels popping up on the screen. Also other projects were growing a bit, and the ATmega's were a bit sluggish or needed a lot of careful programming and interrupt scheduling to ensure proper operation.

Out of curiosity I bought a handful of "Blue Pills" and "Maple Mini's" from China. Significantly more powerful processors, these can update such a TFT with 10 or more FPS which is plenty for a responsive user interface. I fiddled a bit with "stm32duino", a website which has now closed, I believe ST has taken over it's content, and I also fiddled a bit with mbed. It feels like multiple layers of incompatibility libraries thrown together in a bowl and mixed together. When trying to understand the initialization code you find 4 function calls deep an empty funktion with the comment that you can add something there if you want. Yuch. Those 4 function calls should not have been there in the first place. I also really disliked ST's way of first declaring a structure, filling it with some bytes and then calling a library function with that structure, with the end result of just setting or clearing a single bit in a register.

The teensy's may be nice but It's unlikely I will spend USD20 on their development boards. An important factor for deciding for a uC is also the package it's in. I must be able to solder the chips relatively easy on bare PCB's I've ordered. QFP's with a pitch of 0.5mm are OK, but I'm apprehensive of using BGA's. I have never done those, and you can't visually inspect them.

I've always liked to build my own programmers, or use pre-built programmers as long as they are cheap. I thought long and hard about buying an "AVR Dragon", which was about USD80 at that time, but decided against it after reading too many stories of the thing blowing itself up. For the "Blue Pill" you buy USD3 "ST-Link V2" clones and these just work. Even if you damage them, from standing on it, ESD damage or whatever, Who cares for an USD 3 programmer? Just buy a handful of them, which also gives you more opportunities to debug the hardware if you suspect hardware problems with your programmer, you can just swap it for another. I think I've managed to damage 5 or more programmers in the last 30 years, and that is no fun if they cost USD150 each.
I do not like "bootloaders" They are far overrated. Often they are also not user friendly, they take up FLASH, you have to pamper them, often have to press a button to get into "bootloader mode" and other disadvantages. With a decent programmer you have no worries about all those things. Just connect the wires, tell your PC to program your uC and it does it. Always and reliable. Bootloaders can be handy in some niche applications in the field, but for at home on the bench a normal programmer is much easier to use.

I got my first "blue pill" working from a very nice 4 page tutorial from "pandafruits" which explains everything from initialization code & compiling and even connecting with GDB from the command line. It's a very good "getting started" guide.

Another tool I want to mention is Sigrok / Pulseview. Together with an USD 5 Cypress CY768013_something based development board, (or Saleaeae clone) you have a very capable logic analyzer that everyone should learn to use with their first blinking led project on the first uC they ever use. With the "logic analyser" in a plastic box you get 8 channels, with a generic CY7C... board you get 16 channels, but these do not have ESD protection on the inputs. This hardware can sample upto a few Msps and stream directly to Sigrok over USB, so sample depth is not an issue. It is also plenty fast for sampling UART, SPI, I2C and some 100+ other low speed serial protocols. I've even successfully sampled and decoded low-speed USB with it. (1.5Mbit/s) Such a LA is a much better debugging tool then just outputting some bytes to a serial port or printf to an lcd. You can for example continuously output trace information to any un-used peripheral your uC supports. Write "0x13" every time a specific ISR triggers, and another when another ISR triggers, and you can back track timing after your uC program crashed. With a normal debugger you can set breakpoints and halt (which completely destroys all timing) but how do you back track from there to see where it first went wrong? GDB is a powerful tool, but a logic analyzer is a good extra tool to have in your toolbox.

If you read through here you probably thought it was worth it.

[Sal Ammoniac]

I prefer underdogs generally, which is why I like the Infineon XMC series. Good, well thought out peripherals, good documentation, etc. The only downside of this MCU family is the limited selection of development boards.

My second choice is STM32, but I find that family frustrating at times as their peripherals are all over the map with virtually no consistency between series. There's a good selection of development boards, however.

[NorthGuy]

A few years later came the PIC16F84A.

You won't believe how many people still use these old PIC16s. The question is why?

[SiliconWizard]

A few years later came the PIC16F84A.

You won't believe how many people still use these old PIC16s. The question is why?

Comfort zone.

[wraper]

A few years later came the PIC16F84A.

You won't believe how many people still use these old PIC16s. The question is why?

Lazy to switch, so stay with old deprecated crap. But if they switched, it most likely would end up doing their work more efficiently and making better and cheaper products. Spend time on learning new MCU, save time on coding or doing HW design with not abysmal platform. Not to say at some point someone's ass will start burning because supply of parts for recently designed product suddenly in no longer there.

[firewalker]

8-bit AVRs. Really easy to setup the peripherals with good community support. Up until now I didn;t had to the need for something more complex or powerful. I really "hate" ARM micros with huge datasheets and difficult  peripherals configuration and stock libraries that causes more problem than you would expect from the company that designed the part.

Alexander.

[Scrts]

8-bit AVRs. Really easy to setup the peripherals with good community support. Up until now I didn;t had to the need for something more complex or powerful. I really "hate" ARM micros with huge datasheets and difficult  peripherals configuration and stock libraries that causes more problem than you would expect from the company that designed the part.

Alexander.

10 years ago it took me weeks to learn GPIOs, I2C, SPI, CAN and UART on AVR. It took me less than 1 day to get everything running on STM32Cube. Sorry, but ARM is at different level. And when you include debug and trace capabilities, there's no discussion anymore.

[NorthGuy]

8-bit AVRs. Really easy to setup the peripherals with good community support. Up until now I didn;t had to the need for something more complex or powerful. I really "hate" ARM micros with huge datasheets and difficult  peripherals configuration and stock libraries that causes more problem than you would expect from the company that designed the part.

10 years ago it took me weeks to learn GPIOs, I2C, SPI, CAN and UART on AVR. It took me less than 1 day to get everything running on STM32Cube. Sorry, but ARM is at different level. And when you include debug and trace capabilities, there's no discussion anymore.

Look at these two opinions. Is it possible that the two people observe objective reality and, based on the same facts, came to two completely different conclusions? There's only one explanation - these opinions are based on emotions and preferences.

Of course, there's nothing wrong with that. But this clearly demonstrates that it is impossible to pinpoint the single "best" group. It's just as hopeless as trying to select the "best" dish in the restaurant.

[Scrts]

8-bit AVRs. Really easy to setup the peripherals with good community support. Up until now I didn;t had to the need for something more complex or powerful. I really "hate" ARM micros with huge datasheets and difficult  peripherals configuration and stock libraries that causes more problem than you would expect from the company that designed the part.

10 years ago it took me weeks to learn GPIOs, I2C, SPI, CAN and UART on AVR. It took me less than 1 day to get everything running on STM32Cube. Sorry, but ARM is at different level. And when you include debug and trace capabilities, there's no discussion anymore.

Look at these two opinions. Is it possible that the two people observe objective reality and, based on the same facts, came to two completely different conclusions? There's only one explanation - these opinions are based on emotions and preferences.

Of course, there's nothing wrong with that. But this clearly demonstrates that it is impossible to pinpoint the single "best" group. It's just as hopeless as trying to select the "best" dish in the restaurant.

Exactly right, but you need to try at least a couple to find something that is better over the other... And trying doesn't mean power it up for 5 minutes, but actually try and do something working...

[westfw]

Nowadays, you need to take into account the existence of code/libraries/infrastructure for the uC you're trying to choose.If you're going to rely on ASF or Cube or Arduino, you may never learn the details of the uC as much as you would have if you had to start from the datasheet and write everything (perhaps in assembler.)  The flip side is that you probably don't really need or want to understand all 1000+ pages of datasheet for a modern chip - if your problem fits into the feature and performance envelope of Arduino, and is "easy" using that tool, then in some ways it's foolish to insist on more care and complexity.
The same is true for programming languages.  No matter how much you love a particular languages efficiencies, I don't think it makes a lot of sense to write heavy-duty program that falls outside of the easy and efficient areas, just because some other's language features or syntax offends your sensibilities.

[jmelson]

8-bit AVRs. Really easy to setup the peripherals with good community support. Up until now I didn;t had to the need for something more complex or powerful. I really "hate" ARM micros with huge datasheets and difficult  peripherals configuration and stock libraries that causes more problem than you would expect from the company that designed the part.

Alexander.

Yes, I just did a little project with an ATTINY13A in 8-pin SOIC.  The programming in C was WAY easier than any micro project ever before, the whole project was done in a couple days.  Totally amazing devices!  I highly recommend them for small projects.

For bigger projects that need net connectivity, maybe exporting a GUI, that sort of thing, then the Beagle Bone Black is quite awesome.  A complete Linux node for $60 or so.

Jon

[SiliconWizard]

Anyway, nothing inherently wrong in reusing the same old part over and over again if you're very familiar with it, it's still available and it still fits your requirements.

If you never use anything else/newer,  you will just miss learning opportunities, which is a shame, but it's everyone's call really. If you don't want or don't need to learn, it's a pity but your problem entirely.

[jemangedeslolos]

Hello,

I develop high-end circuits and/or in very small quantity so the price is not a concern.
I used Microchip family a lot  ( PIC24EP and dsPIC33EP ) even when it's not necessary and a small 8bit would have been enough.
I switched to ST M3/M4 "just because" and It was hard because of the documentation is not written according to the same logic.

I miss the peripheral pin select wich is a killer feature. It is much more easy when you need almost all peripheral for the layout.
I have to test PIC32 family but with a personal project first. I heard so much hate about PIC32 ( or Microchip.....or Mplab )
I have to make my own opinion.

[SiliconWizard]

I miss the peripheral pin select wich is a killer feature. It is much more easy when you need almost all peripheral for the layout.

STM32 MCUs have this as well.

[jemangedeslolos]

Which ones do you have in mind ?
I have to look more deeply in their new references.
The ones I used ( STM32F405/407, STMF446 for example ) have some capabilities in pin assignment but it is not as flexible as Microchip PPS feature.

[SiliconWizard]

Which ones do you have in mind ?
I have to look more deeply in their new references.
The ones I used ( STM32F405/407, STMF446 for example ) have some capabilities in pin assignment but it is not as flexible as Microchip PPS feature.

Have only worked with the 4xx line (F4/L4) so far, and yes this is what I had in mind. I don't quite remember how that was on PIC24. It may have been a bit more flexible, but as I remember, there were also some restrictions as to which function could be assigned to which pin? Maybe fewer restrictions though, can't remember the details.

[jemangedeslolos]

Which ones do you have in mind ?
I have to look more deeply in their new references.
The ones I used ( STM32F405/407, STMF446 for example ) have some capabilities in pin assignment but it is not as flexible as Microchip PPS feature.

Have only worked with the 4xx line (F4/L4) so far, and yes this is what I had in mind. I don't quite remember how that was on PIC24. It may have been a bit more flexible, but as I remember, there were also some restrictions as to which function could be assigned to which pin? Maybe fewer restrictions though, can't remember the details.

one example :

On STM32F446 you only have 2 options :
you can have SPI1 on PA5 PA6 PA7.
PA5 is SCK
PA6 is MISO
PA7 is MOSI

or you can have SPI1 on PB3 PB4 PB5
PB3 is SCK
PB4 is MISO
PB5 is MOSI

dsPIC33EP512MC806 :

You have lots of remappable pins. You just have to be careful because there are RPn pins ( can be input or output ) and RPIn ( can be input only ).
If I look quickly, I see that I can assign MOSI_1 to any af RPn pins ( 16 possibilities ) and/or I can switch between MOSI and SCK if it is useful for my layout.

[SiliconWizard]

(...)
You have lots of remappable pins. You just have to be careful because there are RPn pins ( can be input or output ) and RPIn ( can be input only ).
If I look quickly, I see that I can assign MOSI_1 to any af RPn pins ( 16 possibilities ) and/or I can switch between MOSI and SCK if it is useful for my layout.

Oh, now I remember a bit more. Yes, apart from this RP/RPI thing, this was more flexible indeed. Peripherals on STM32 can only be mapped to specific sets of pins, even when there are several such possible sets, but not each function signal to any IO (IIRC, the exception was with I2C I think?). That's indeed a lot more limited for STM32 parts, and requires more planning. I've never really be bothered too much by this, but I have worked with layout guys that would go crazy if they could not re-assign almost any pin to any signal while routing.

[jemangedeslolos]

Yes there is dedicated hardware inside the MCU for I2C so there are less flexibility.
The rest is only important for real French wizards. Just kidding 

I can live with STM32 without this nice feature but as always, it is difficult when we have known better in some aspects.
I remember having to switch from 64 to 100 pin because PPS was missing.
I could have kept a 64pins package with a PIC24EP / dsPIC33EP.

[SiliconWizard]

I could have kept a 64pins package with a PIC24EP / dsPIC33EP.

Nothing prevents you from still using PIC MCUs depending on the project?

[NorthGuy]

I remember having to switch from 64 to 100 pin because PPS was missing.
I could have kept a 64pins package with a PIC24EP / dsPIC33EP.

Why didn't you?

[jemangedeslolos]

With some clients, I have lists of requirements with different level of flexibility.
In this list, I had to use, among other things, 32 bit STM32 family. And this one was "non-negitiable".
There was no particular constraint about PCB density and they left me the choice of the lines as long as it is part of their 10 years longevity commitment.

[westfw]

You won't believe how many people still use these old PIC16s [like PIC16F84]. The question is why?

I just did a little project with an ATTINY13A in 8-pin SOIC.  The programming in C was WAY easier than any micro project ever before

Heh.  At this point, the ATtiny13 ought to be in the same "you're using that ANCIENT chip" category as the 16F84 (or nearly.)  It was cheap at small and easy for quite a while, but these days you can get one of the tiny0 or tiny1 chips (eg ATtiny402) with 4x as much memory and real peripherals, and they cost less.  (alas, not available in DIP, I guess :-( )

[Psi]

i remember my jaw hitting the floor when i saw that on nRF52 you can remap any GPIO to any peripheral function you want.
Up until that point i had only ever used AVR and STM32 with maybe 2 or 3 remap options

[NorthGuy]

i remember my jaw hitting the floor when i saw that on nRF52 you can remap any GPIO to any peripheral function you want.
Up until that point i had only ever used AVR and STM32 with maybe 2 or 3 remap options

Get FPGA. This gives you real freedom in pin assignment.

[nctnico]

i remember my jaw hitting the floor when i saw that on nRF52 you can remap any GPIO to any peripheral function you want.
Up until that point i had only ever used AVR and STM32 with maybe 2 or 3 remap options

Get FPGA. This gives you real freedom in pin assignment.

Not really. Think about hard-ip blocks, clock inputs, distributed clock areas, bank-wide I/O voltages, input-only pins and logic constraints. Just like any microcontroller design I start an CPLD/FPGA design by carefully studying the pin usage limits.

[NorthGuy]

Not really. Think about hard-ip blocks, clock inputs, distributed clock areas, bank-wide I/O voltages, input-only pins and logic constraints. Just like any microcontroller design I start an CPLD/FPGA design by carefully studying the pin usage limits.

Sure there are some constrains, but even what you perceive as a problem still a huge leap compared to MCUs  - a dazen of clock inputs in FPGA compared to typically one in MCU, bank-wide voltages compared to single voltage for the whole MCU.

[ogden]

Sure there are some constrains, but even what you perceive as a problem still a huge leap compared to MCUs  - a dazen of clock inputs in FPGA compared to typically one in MCU, bank-wide voltages compared to single voltage for the whole MCU.

Do you use "FPGA in place of MCU just for better I/O pin mapping" approach yourself? Share your experience. For others: before you follow this strange advice, check Cypress PSoC MCU's first (pdf).

[NorthGuy]

Do you use "FPGA in place of MCU just for better I/O pin mapping" approach yourself?

No

[ogden]

Do you use "FPGA in place of MCU just for better I/O pin mapping" approach yourself?

No

Riiiight Anyway check PSoC before you continue with your FPGA mantra.

[SiliconWizard]

Ahah, that was some fun.
"What µC are you preffering?"
"- An FPGA."
 

Surely FPGAs can be pretty useful in a whole range of applications, but just choosing to use one if an MCU was otherwise a perfect fit just to be able to remap pins more easily (so just to ease the board layout) sounds kind of crazy. Unless maybe you were dealing with a 500+ IOs design (but I'd be curious to see some MCU with that many IOs) or something, or you/the layout guy is an extremely lazy lad.

[NorthGuy]

Riiiight Anyway check PSoC before you continue with your FPGA mantra.

FPGAs surely have problems - price, space, power. So, it is rarely useful for simple projects. However, if other things were equal, it's certainly much easier to deal with FPGA than with MCU.

I never worked with PSoCs, but, from the distance, they look overpriced, overhiped, and overcompilcated.

[ogden]

I never worked with PSoCs, but, from the distance, they look overpriced, overhiped, and overcompilcated.

Indeed more complex than common MCU's like stm32 or sam, still *far* from complexity and price of FPGA. At least you don't have to completely break and reset your linear logic before you even start to comprehend what FPGA is, not to mention produce working product. With PSoC you can still stay in the MCU realm.

[NorthGuy]

still *far* from complexity and price of FPGA.

I think it's less complexity. Aside of some special elements (such as BRAM or DSP), FPGA fabric consists of logic blocks, which are predominantly LUTs and flip flop, and interconnect between them.  That's all. You can use them to build periphery that you need. Once designed, you can create many instances (you can have 50 of something, totally independent of each other) or you can move it to the other project with no or little changes. If you wish, you can look at this process as the process of building your dream MCU which exactly matches your task.

In contrast, in MCUs you have a diverse set of peripheral and you need to select an MCU which already has all the periphery you need. Every manufacturer has its own peculiarities in their periphery. You need to remember these peculiarities, or re-read the datasheet. The periphery may not do exactly what you want (e.g. 9-bit SPI), so you need to find workarounds. If you want many of something, you need to make sure all will work together - such as enough DMA chanells, no bus collisions, etc. You need to think of interrupt latencies and clashes. There's none of this in FPGAs.

[ogden]

I think it's less complexity.

You think or know?

Aside of some special elements (such as BRAM or DSP), FPGA fabric consists of logic blocks, which are predominantly LUTs and flip flop, and interconnect between them.  That's all. You can use them to build periphery that you need. Once designed, you can create many instances (you can have 50 of something, totally independent of each other) or you can move it to the other project with no or little changes. If you wish, you can look at this process as the process of building your dream MCU which exactly matches your task.

Right. How many dream MCU's did you built using FPGA? What did you successfully build using FPGA, if anything?

[NorthGuy]

I think it's less complexity.

You think or know?

Complexity is not something which is easily measurable. So, I guess this is a philosophical question. Is a box with 1000 lego blocks more complex than one lego block? In my opinion it isn't, because once you understand how a single Lego block works, you can use 1000s of them to build practically anything. In my opinion, it's easier to deal with lego blocks than with IKEA furniture you build from big parts using instructions. I see the same relationship between FPGAs and MCUs.

Right. How many dream MCU's did you built using FPGA?

None. FPGAs are expensive. Nobody will pay me for turning them into MCUs. But I often design peripherals for my FPGA projects which are commonly present in MCUs - SPI, I2C, UART, PWM, flash and EEPROM interfaces, RGMII, etc. I found it more flexible and easier. If I had a choice, I would prefer working with FPGAs.

[ogden]

Complexity is not something which is easily measurable.

When you *actually* do something complex - you know metrics.

[NorthGuy]

When you *actually* do something complex - you know metrics.

What metrics? What units do you measure it in?

[ogden]

When you *actually* do something complex - you know metrics.

What metrics? What units do you measure it in?

https://en.wikipedia.org/wiki/Man-hour

[rvalente]

For general use in automotive electronics?

Not for making a engine control module, but still OEM, why would you use?

[NorthGuy]

What metrics? What units do you measure it in?

https://en.wikipedia.org/wiki/Man-hour

Well. You would just drop the pre-made modules into your project, add a core of your choice (can even use ARM if you wish), assign AXI addresses, and that's it. I don't see how this could take more than few hours. From this point on, this is not different from a regular MCU, only it's built-to-order and will save you lots of time later. Not to mention that if you need to add a peripheral module you just do it, as opposed to going to a different MCU. And if the module you want doesn't exist, you just design it. Looks like huge time savings to me.

Certainly, what holds FPGAs from the market is not complexity, but cost.

Perhaps, 20 years later it'll change.

[ogden]

Well. You would just drop the pre-made modules into your project, add a core of your choice (can even use ARM if you wish), assign AXI addresses, and that's it. I don't see how this could take more than few hours.

Right. You *can* do many stupid things. Question is: do you solve anything at all? Such solution will introduce external RAM and flash, will consume much more power than common MCU not to mention PCB real estate and BOM money consumption. What's worse - it will not solve initial problem because instead of single IC "pin mapping challenges" you are getting three that must be properly interconnected.

[NorthGuy]

Right. You *can* do many stupid things. Question is: do you solve anything at all? Such solution will introduce external RAM and flash, will consume much more power than common MCU not to mention PCB real estate and BOM money consumption. What's worse - it will not solve initial problem because instead of single IC "pin mapping challenges" you are getting three that must be properly interconnected.

Why would you use a big monstrous 32-bit MCU which requires external parts where a small PIC16 would suffice? Sounds stupid, right? But prices come down, power consumption improves, psychology changes, your time becomes more valuable. Suddenly, it doesn't sound stupid anymore, at least for most people.

Similarly, what if FPGAs costs come down and they become cheaper than today's 32-bit MCUs. What if they become smaller, will consume less power and will have built-in flash. Suddenly, it doesn't sound stupid anymore, right? Technology has a potential. It's only a matter of time.

[crayon]

That would depend on the ECU you want to develop, and again, the specific problem you want to solve. There are ECU specific microcontrollers designed to satisfy common industry use cases, eg. instrument clusters, pcm, bcm, hvac....

[ogden]

Similarly, what if FPGAs costs come down and they become cheaper than today's 32-bit MCUs. What if they become smaller, will consume less power and will have built-in flash. Suddenly, it doesn't sound stupid anymore, right?

"What if" hope that FPGA capable of running 32-bit soft core MCU will become cheaper than same 32-bit MCU implemented in ASIC, will consume less - sounds insanely stupid. It will never happen. Period. Just stop dreaming and *actually* implement something using FPGA

[Bassman59]

Similarly, what if FPGAs costs come down and they become cheaper than today's 32-bit MCUs. What if they become smaller, will consume less power and will have built-in flash. Suddenly, it doesn't sound stupid anymore, right?

"What if" hope that FPGA capable of running 32-bit soft core MCU will become cheaper than same 32-bit MCU implemented in ASIC, will consume less - sounds insanely stupid. It will never happen. Period. Just stop dreaming and *actually* implement something using FPGA

Or, you could actually choose the device which makes the most sense for the design. You probably don't want to do a USB device stack (after the serial interface engine, anyway) in an FPGA, nor an Ethernet interface. And you can't directly interface 32 channels of LVDS/DDR serial high-speed ADCs to a microprocessor.

But you can use a processor bus interface to connect the two.

-----------

Sometimes the non-obvious approach works. For the hell of it, I built a nice audio ADC/DAC. It has an SRC4392 that implements the S/PDIF interfaces and does SRC for the DAC side. I used an SiLabs clock synthesizer chip for the clocking (mainly to see if it would work for audio, and yay, it works great). The SRC, the clock and the converters all have I2C and/or SPI interfaces for configuration. Cool! I'll pick a micro that has the interfaces and it'll be easy.

And it was. Until I decided I wanted to add Dorrough-style input metering to the ADC side. Sure, the micro has its own ADC of more-than-adequate resolution and sample rate (12 bits at 100 kHz or whatever is more than enough for metering) and it can do the averaging and generate peak hold and all of that. OK, time to drive LEDs. How many GPIO do I have left over? Or should I do it serially and go SPI out to HC595s or to dedicated LED drivers or what? What costs the least?

But wait! The design is an ADC. Why not just spy on the I2S port from the ADC and connect it to the micro as well as the SRC? Oh, great! Lots of ARMs have synchronous serial ports that can be configured to do I2S! This will be easy! Except ... when I looked closely I saw that were limits on the rate of the I2S bit clock when the micro's port is run in slave mode? Nothing I found supported I2S bit clocks of 12.288 MHz in slave mode. (This was a couple of years ago, I'm sure now there is something that can do this now.) So no 192 kHz sampling capability. Phooey.

So I looked at doing the whole thing in an FPGA. Multiple SPI and I2C ports for configuring the devices? Check. ROM lookup tables for those configurations? Check. Implement I2S slave and doing the math for meter averaging and peak detect? Check. A bit of logic to determine the frequency of an input word clock, to which the clock chip syncs, and use that to set up the clock chip for correct operation with that frequency? Check. Enough I/O pins for multiplexed LED drive for the metering? Check.

Cheaper than a microcontroller? Actually, check -- I did it with a Lattice MachXO2-1200.

Of course now I want to eliminate the $17 SRC4392 and do the S/PDIF interface and the SRC in an FPGA.

And I also want to add USB. So, back to the micro and the FPGA together. Or an XMOS part.

[ogden]

"What if" hope that FPGA capable of running 32-bit soft core MCU will become cheaper than same 32-bit MCU implemented in ASIC, will consume less - sounds insanely stupid. It will never happen. Period. Just stop dreaming and *actually* implement something using FPGA

Or, you could actually choose the device which makes the most sense for the design.

Yes indeed. Many or I would say most designs /w FPGA have some host and/or service CPU as separate IC or soft core. My argument was against "FPGA in place of MCU just for better I/O pin mapping", and only. Price/consumption comparison was between ARM MCU like STM32L072 and FPGA which can run said MCU soft core with all the peripherals. FPGA vs CPU/MCU is recurring topic here.

[Bassman59]

"What if" hope that FPGA capable of running 32-bit soft core MCU will become cheaper than same 32-bit MCU implemented in ASIC, will consume less - sounds insanely stupid. It will never happen. Period. Just stop dreaming and *actually* implement something using FPGA

Or, you could actually choose the device which makes the most sense for the design.

Yes indeed. Many or I would say most designs /w FPGA have some host and/or service CPU as separate IC or soft core. My argument was against "FPGA in place of MCU just for better I/O pin mapping", and only.

Yeah, that makes no sense at all.

[psysc0rpi0n]

Hello.

I just started to learn about ARM microcontrollers/microprocessors and using openOCD to load code and eventually debugging in the future. I'm just taking the first steps at all. I don't know how openOCD works nor ever seen an ARM datahsheet at all.

I bought a Chinese clone of a Discovery board with an STM32F407VET6 chip. OpenOCD do not see it as a Discovery board but as a standalone SMT32F4x chip.
I'm actually reading on the main subjects of openOCD manual/documentation. Then, I'll take a survey on the chip reference manual and datasheet. I'm using a Jlink device (also a Chinese clone) to talk to the board using a mode called SWD. I see this as a simpler JTAG approach as it uses this jlink device but it don't use all JTAG pins.

The thing is that I think I'm not mature enough to stick to something until the end. I used AtMega328p in the past, and did a few thing with it. I just learnt the very basics I guess. Then I won a dev board in some contest I participated in and I had a project in mind for it but couldn't make it happen. I ended up leaving it aside as I got interest in other things in the meantime. It was a Microchip IoT dev board with some google cloud shit and a wireless communication antenna and also an on-chip debugger. The chip taking care of all the peripherals was an AtMega4808.

Now I'm on this ARM thing. Let's see for how long!

[brucehoult]

Hey, sounds like fun! Have you got a helloWorld or blinky going?

I think OpenOCD can work in quite different ways on different systems. On the board I use most it works together with gdb to use JTAG over USB to download a small program into RAM on the MCU, which is then used to do self-programming of the flash. it's a lot of different stuff tied together with gaffer tape!

[ogden]

Now I'm on this ARM thing. Let's see for how long!

For quite long. Beauty of ARM "ecosystem" is that you are fully covered from simple & low cost chips up-to hi-performing "embedded monsters" with single set of software/hardware tools and knowledge (of CPU architecture). Yes, you need to know peripherals of particular MCU, but at least you don't have to bend your mind and learn completely different CPU and IDE and compiler as you did when migrated between AVR and PIC. No matter you use STM32F0 < 1$ low cost generic MCU or STM32H7 "monster", you basically are fine with same tools and knowledge. Same apply for other ARM MCU manufacturers - Microchip, NXP and so on.

[NorthGuy]

Now I'm on this ARM thing. Let's see for how long!

For quite long. Beauty of ARM "ecosystem" is that you are fully covered from simple & low cost chips up-to hi-performing "embedded monsters" with single set of software/hardware tools and knowledge (of CPU architecture).

Yeah, but then there are variations, such as Thumb2. And then there's Aarch64 which is quite a bit different from 32-bit ARMs, and who knows what's next.

[ogden]

For quite long. Beauty of ARM "ecosystem" is that you are fully covered from simple & low cost chips up-to hi-performing "embedded monsters" with single set of software/hardware tools and knowledge (of CPU architecture).

Yeah, but then there are variations, such as Thumb2. And then there's Aarch64 which is quite a bit different from 32-bit ARMs, and who knows what's next.

Yes, you need to know be informed about both 32bit and Thumb opcodes, yet I am not sure Aarch64 will be ever used in µC which BTW is main subject here (check Subject if in doubt).

[NorthGuy]

Yes, you need to know be informed about both 32bit and Thumb opcodes, yet I am not sure Aarch64 will be ever used in µC which BTW is main subject here (check Subject if in doubt).

You can never predict the future ... but if you  had an MCU with A53 core, would you have difficulties using Aarch64 because it has different "opcodes" than 32-bit ARM architectures?

[ogden]

if you  had an MCU with A53 core, would you have difficulties using Aarch64 because it has different "opcodes" than 32-bit ARM architectures?

I would have no problems of using ARM MCU with "other kind" of opcodes if needed, especially when I do not have to invest significant additional money in tooling. That BTW was my main point in post about ARM "ecosystem".

[NorthGuy]

I would have no problems of using ARM MCU with "other kind" of opcodes if needed, especially when I do not have to invest significant additional money in tooling. That BTW was my main point in post about ARM "ecosystem".

Would you then have problems using an MCU which uses a different architecture, such as MIPS (used in PIC32) or RISC-V?

They both are supported very well by GCC. I think MIPS has been supported by GCC long before ARM, so it is very mature. RISC-V is excellent ISA without pre-historic overhead and is also supported by GCC. And it's all free and open source - no money to pay at all.

[ogden]

Would you then have problems using an MCU which uses a different architecture, such as MIPS (used in PIC32) or RISC-V?

They both are supported very well by GCC. I think MIPS has been supported by GCC long before ARM, so it is very mature. RISC-V is excellent ISA without pre-historic overhead and is also supported by GCC. And it's all free and open source - no money to pay at all.

It depends. You consider me hobbyist doing one piece of hardware per month at best or decision maker of commercial entity doing thousands or more (per month)?

[NorthGuy]

Would you then have problems using an MCU which uses a different architecture, such as MIPS (used in PIC32) or RISC-V?

They both are supported very well by GCC. I think MIPS has been supported by GCC long before ARM, so it is very mature. RISC-V is excellent ISA without pre-historic overhead and is also supported by GCC. And it's all free and open source - no money to pay at all.

It depends. You consider me hobbyist doing one piece of hardware per month at best or decision maker of commercial entity doing thousands or more (per month)?

I consider you a forum participant who introduced the concept of "ARM ecosystem" and I'm trying to understand what stands behind the concept (if anything). Therefore, I'm interested to know if you feel like you would have difficulties working with similar non-ARM CPUs. I have selected two RISC CPUs as an example of similar CPUs from outside the "ARM ecosystem".

I'm certainly interested on engineering (as opposed bureaucratic) viewpoint.

[brucehoult]

For quite long. Beauty of ARM "ecosystem" is that you are fully covered from simple & low cost chips up-to hi-performing "embedded monsters" with single set of software/hardware tools and knowledge (of CPU architecture).

Yeah, but then there are variations, such as Thumb2. And then there's Aarch64 which is quite a bit different from 32-bit ARMs, and who knows what's next.

Yes, you need to know be informed about both 32bit and Thumb opcodes, yet I am not sure Aarch64 will be ever used in µC which BTW is main subject here (check Subject if in doubt).

There are a ton of 64 bit RISC-V microcontrollers being used. Being 64 bit isn't an obstacle and in fact is often highly desirable especially if the rest of the chip needs 64 bit addressing. The big issue with Aarch64 is that there are no subsets defined, it's all or nothing. RV64I is a 64 bit CPU, but still tiny.

My pick is ARMv9 is going to introduce 1) one or more subsets of Aarch64, and 2) a completely new instruction encoding for Aarch64 with both 16 and 32 bit opcodes, similar to A32 and T32.

You heard it here first.

(but I've been saying it for a while)

[ogden]

Therefore, I'm interested to know if you feel like you would have difficulties working with similar non-ARM CPUs.

I personally will be fine with "non-ARM" core - if needed for some strange reason. As I ignore various cults like "best CPU architecture ever" or "X MCU is few percent cheaper than Y MCU", I just stick with ARM MCU, STM32 to be specific. That series cover my needs well. There are plenty of stuff for ARM around, including optimized libraries and what not. That "plenty of stuff" can be considered "ecosystem"

When we talk about small/medium business - then many other considerations come into play. Apart from pure MCU hardware/peripheral considerations, volume contracts you preferably sign with only one MCU manufacturer, there are other stuff like RTOS, 3rd party IP (libraries/stacks), capabilities of your developers and manufacturing house and so on. Sometimes you look at multidimensional matrix of variables and not always MCU of potential choice is what you or your developers like. What's worse - often preferences of EE department, SW department and business unit do not match.

[NorthGuy]

Therefore, I'm interested to know if you feel like you would have difficulties working with similar non-ARM CPUs.

I personally will be fine with "non-ARM" core - if needed for some strange reason. As I ignore various cults like "best CPU architecture ever" or "X MCU is few percent cheaper than Y MCU", I just stick with ARM MCU, STM32 to be specific. That series cover my needs well. There are plenty of stuff for ARM around, including optimized libraries and what not. That "plenty of stuff" can be considered "ecosystem"

I see. There's plenty of stuff for everything. And getting more. There's no reason to single ARM out into its own ecosystem on that basis.

[psysc0rpi0n]

Hey, sounds like fun! Have you got a helloWorld or blinky going?

I think OpenOCD can work in quite different ways on different systems. On the board I use most it works together with gdb to use JTAG over USB to download a small program into RAM on the MCU, which is then used to do self-programming of the flash. it's a lot of different stuff tied together with gaffer tape!

Hello.

Long discussing going on. I'm a bit out of it as I cannot discuss much about it.

About your question, yes, I made a blinky program working on it, but it was a ready-to-use source file that I just compiled with an also ready-to-use Makefile. I found an whole set of ready-to-use source files in github. I used them just to learn how OpenOCD works and also dfu-utils. I never worked with any of these tools.

But, just for the record, I have no prior experience. I'm just a mid age person that completed graduation in Electrical Engineering (Electronics and Telecommunications) in early 2018 and I developed an interest (and a passion, I guess) for electronics and programming, but NEVER worked on this area/field so I have only academic knowledge which is very limited so I struggle many times with real-world basic situations that were ignored in school, so we got no intuition whatsoever about real world scenarios. That is my complaint and regret for the unfortunate I was by not discovering this world years ago.

Anyways, I'm always trying to learn about new things but in the case of ARM, it was quite a big change because changed the architecture, changed the tools (avrdude mostly for AVR), changed registers, amount of things that needs to be configured, etc, etc.

And a reference manual of an ARM is like 1700 pages. AVR's (at least the one I was reading) was about 400.

Another thing I regret about myself is that I usually start something and then I just can't stick to it until the en. I think, in this field, my mind is very immature. I have at least 2 things, plus now the ARM chip, laying around doing nothing. On of them, I never tried it before, which was a small board I bought from china to try to listen/sniff/whatever Li-Ion battery controllers. The other one is a Mivrochip dev board called somethin like AVR IoT WG which comprises an AtMEga4808, some Google Cloud shit, a Wireless antenna, on-chip debugger , some security/cryptography/encryption feature and a couple of on-chip/built-in sensors. I started to explore this board but also dumped it after some time. I even had a small project to it but I lost interest, probably because to be able to use all these features all at once, a few thousands of lines of code were needed and it was a little bit of a daunting task to learn like 3000 lines of code just to read temp and light and send that info to some Google Cloud server and show it in some web page. I guess I lost the interest because of that huge amount of code.

Anyways, I always try to learn new things. I hope I can stick longer to ARM chips!

[ogden]

There's no reason to single ARM out into its own ecosystem on that basis.

Yes indeed. There is no reason for family sedan, "car of the year" to be the coice of transportation for everything. Yet when random & clueless people are seeking for means of transportation you usually suggest them what? - Car of the year.

[brucehoult]

Hey, sounds like fun! Have you got a helloWorld or blinky going?

About your question, yes, I made a blinky program working on it, but it was a ready-to-use source file that I just compiled with an also ready-to-use Makefile. I found an whole set of ready-to-use source files in github. I used them just to learn how OpenOCD works and also dfu-utils. I never worked with any of these tools.

I think it's fair to say that most people working with microcontrollers don't actually have much idea exactly how tools such as avrdude or openocd operate. Once they have an example blinky project that works they will just incrementally modify that to do what they need.

Of course curiosity is great and you should learn whatever you want to, but if the goal is to complete some useful project using a microcontroller then studying the internals of openocd is an unnecessary distraction, just as learning all the details of exactly how gcc works would be.

The same goes for using a HAL (Hardware Abstraction Layer), whether manufacturer-supplied or something like the much maligned Arduino libraries, rather than learning and programming the machine registers directly. Of course for unusual needs sometimes there is no choice, but often it's fine to take a higher level approach. Especially on a higher-performance CPU.

[brucehoult]

There's no reason to single ARM out into its own ecosystem on that basis.

Yes indeed. There is no reason for family sedan, "car of the year" to be the coice of transportation for everything. Yet when random & clueless people are seeking for means of transportation you usually suggest them what? - Car of the year.

OMG. I would probably *never* recommend a clueless person to buy the "car of the year" chosen by some journalist or group of journalists. Instead I'd recommend they get something super boring and reliable e.g. a Toyota or if the person often drives on bad or mountainous roads or in "real" winter conditions, Toyota's 20% owned subsidiary, Subaru.

Since this is an Aussie-based site, lets look at the Wheels COTY winners:

2019: Volvo XC40
2018: Volvo XC60
2017: Mazda CX-9
2016: Mazda MX-5
2015: -
2014: BMW i3
2013: VW Golf VII
2012: Toyota 86 / Subaru BRZ
2011: Honda CRZ
2010: VW Polo

This list leans heavily towards expensive (and unreliable and poorly supported in Australia) European cars and sports cars. The clueless should be buying neither of those!

The only thing on that list I'd suggest a random person consider is the CX-9, and even there it is more sporty and less practical and more expensive than excellent competitors from Toyota, Subaru, Honda, Kia, Hyundai.

[westfw]

There's no reason to single ARM out into its own ecosystem on that basis.

ARM (especially the Cortex M series) seem to have better-than-average debugging support/documentation/etc.A lot of chips seem to leave debugging to proprietary interfaces (Atmel AVR is particularly guilty :-( (but getting better?))  And wasn't it some of the RISC-V chips that were "it has JTAG, but you'll need a new debug probe to actually do debugging.")
OTOH, ARM seems weak in the simulation department.

[ogden]

OMG. I would probably *never* recommend a clueless person to buy the "car of the year".

LOL. You must be kidding? I did mean it figuratively. Please do not derail this discussion into pointless  about actual cars.

[brucehoult]

There's no reason to single ARM out into its own ecosystem on that basis.

ARM (especially the Cortex M series) seem to have better-than-average debugging support/documentation/etc.A lot of chips seem to leave debugging to proprietary interfaces (Atmel AVR is particularly guilty :-( (but getting better?))  And wasn't it some of the RISC-V chips that were "it has JTAG, but you'll need a new debug probe to actually do debugging.")
OTOH, ARM seems weak in the simulation department.

Since much of the debugging functionality of a "JTAG probe" depends on halting the user program, downloading a very short bit of native code into a small special memory area (perhaps 16 bytes), and running it -- yes, the JTAG probe (if "smart") or the software that drives it (if "dumb") needs to understand the ISA of the chip.

SiFive chips (and FPGA bitstreams of them) work fine with a bog standard and cheap Olimex ARM-USB-TINY-H, which I take it means it is a "dumb" JTAG and not actually ARM-specific at all.

SEGGER and Lauterbach have provided explicit support for RISC-V for several years now.

[NorthGuy]

Yes indeed. There is no reason for family sedan, "car of the year" to be the coice of transportation for everything. Yet when random & clueless people are seeking for means of transportation you usually suggest them what? - Car of the year.

When something gets popular, people feed from each other to augment popularity, sometimes way beyond reason. Therefore popularity is very poor as a guide to engineering.

There's an excellent book. It's slightly on a different subject, but it explains the phenomenon very well:

Charles MacKey: "Extraordinary popular delusions and the madness of crowds".

This is a very interesting read.

[ogden]

When something gets popular, people feed from each other to augment popularity, sometimes way beyond reason.

Does not apply here. MCU is not consumer product. Those who buy MCU in significant volume usually are successful companies. Saying that they feed from each other to augment popularity is beyond reason.

[Sal Ammoniac]

When something gets popular, people feed from each other to augment popularity, sometimes way beyond reason.

Does not apply here. MCU is not consumer product. Those who buy MCU in significant volume usually are successful companies. Saying that they feed from each other to augment popularity is beyond reason.

+1

When companies I've worked for evaluated MCUs for use in products, we never considered what competitors were using in their similar products. We evaluated each MCU for fitness for our purpose and not on its popularity.

[splin]

we never considered what competitors were using in their similar products.

Then perhaps you should - maybe your competitors know something you don't? ([EDIT: I'm not referring to 'you' specifically - what you did worked presumably worked well for you/your company - but I don't think your approach is desirable for many/most developments].

'Considering' doesn't mean 'blindly following' or even conducting a protracted in depth analysis. But if your competitors are reasonably competent you should at least consider, even if briefly, why they might have made their choices the way they did.

We evaluated each MCU for fitness for our purpose and not on its popularity.

Risking choosing a product which could get very expensive or obsoleted in short order because you are the only manufacturer in the market not using the popular part - which gets ever cheaper as popularity drives volumes and even brings in second or third sources? Ok. the latter isn't very common these days but does still happen occasionally - eg. the GD STM32 clones.

Popularity is good and should be high on the list of factors influencing the decisions. Popularity likely means a larger pool of available experienced developers in the job market. Third party tools, software and hardware may become available for popular parts, but not obscure ones. This might become important later when you find that the part itself, or the maufacturer's tools turn out to have some crippling bugs, limitations or performance and productivity stifling issues that they are unwilling to fix because of low demand.

Popular parts are much more likely to get silicon revisions to fix errata and/or improve cost and performance and to add new features. At the least the manufacturer isn't going to put much effort into support for low volume parts.

Meanwhile your competitors are laughing all the way to the customers, even if their design isn't the most elegant or 'optimal' from an engineering viewpoint.

[EDIT] Clearly this is all very dependent on the market you are operating in - highly specialised, low volume markets developing one off solutions for specific customer requirments is very different to consumer type products where the design might have a long lifespan with incremental development and improvement over many years.

[NorthGuy]

Does not apply here. MCU is not consumer product. Those who buy MCU in significant volume usually are successful companies. Saying that they feed from each other to augment popularity is beyond reason.

May be they do, but for every big and successful company, there are thousands of small guys who recommend MCUs to "random and clueless" people because this is an "MCU of the year" - marketers, journalists, bloggers and whatnot. That's what creates popularity for MCUs. Big companies whose decisions don't get published anywhere has very little to do with popularity.

[SiliconWizard]

Popularity certainly does influence to some degree vendors/architectures choice in big companies, especially since the selection process is often only partially in the hands of tech people. And just like with hiring people, using "popular" solutions just makes things easier for the deciders that are definitely not the ones who design products. If you're going for ARM, what's the probability you could get in trouble with your choice? Now if you're going for some obscure architecture/vendor for your next big project, however a great fit it was, and the project fails (for any reason), your choices are likely to be held against you (even if that's not relevant.)

In the same vein, some of you may "never" consider what competitors use, but I've seen this pretty frequently myself. When a prestigious company uses something specific and it's known in the field, it certainly does influence decisions for others in some way.

[NorthGuy]

... if you're going for some obscure architecture/vendor for your next big project, however a great fit it was, and the project fails (for any reason), your choices are likely to be held against you (even if that's not relevant.)

Of course, if you chose something and then, two years from now, when your product is in full bloom, the vendor stops selling the chip or increases price 5 times, you're doomed. There's no way you can prevent this 100%. All vendors want to sell something hot and popular, but very few are willing to continue with products which lost popularity (as all the products eventually do). The only indication is the past behaviour of the vendor. Something you should consider.

These are rational considerations. Popularity, however, is irrational - you chose something not because you have your own considerations, but because you rely on others. This also absolve you from responsibility - you have chosen something that other people praised so high, how can you be responsible for them? So, many people use what other recommends, and then start recommending the same to others, thus magnifying popularity. This is very common for bureaucrats at all levels and regular folks alike.

[Sal Ammoniac]

We evaluated each MCU for fitness for our purpose and not on its popularity.

Popularity is good and should be high on the list of factors influencing the decisions. Popularity likely means a larger pool of available experienced developers in the job market. Third party tools, software and hardware may become available for popular parts, but not obscure ones. This might become important later when you find that the part itself, or the maufacturer's tools turn out to have some crippling bugs, limitations or performance and productivity stifling issues that they are unwilling to fix because of low demand.

Did you read what I wrote? I said we evaluated for fitness for our purpose. So what if a part is popular? It can be the most popular part in the world, but if it doesn't fit our application, it's useless to us. I've seen too many engineers try to shoehorn an application onto an MCU that wasn't suited for that application merely because the part was popular and was the latest craze in the industry.

[SiliconWizard]

We evaluated each MCU for fitness for our purpose and not on its popularity.

Popularity is good and should be high on the list of factors influencing the decisions. Popularity likely means a larger pool of available experienced developers in the job market. Third party tools, software and hardware may become available for popular parts, but not obscure ones. This might become important later when you find that the part itself, or the maufacturer's tools turn out to have some crippling bugs, limitations or performance and productivity stifling issues that they are unwilling to fix because of low demand.

Did you read what I wrote? I said we evaluated for fitness for our purpose. So what if a part is popular? It can be the most popular part in the world, but if it doesn't fit our application, it's useless to us. I've seen too many engineers try to shoehorn an application onto an MCU that wasn't suited for that application merely because the part was popular and was the latest craze in the industry.

Yes, that's hype-driven development.

[splin]

Did you read what I wrote? I said we evaluated for fitness for our purpose.

Of course I did thank you - that was why I responded.

So what if a part is popular?

Perhaps you could have had the courtesy to have actually read what I wrote? It was all about why popular is important.

It can be the most popular part in the world, but if it doesn't. fit our application, it's useles to us.

Obviously, that goes without saying. Why would anyone choose a part that wasn't fit for purpose? I didn't say you should select a part because it is popular - what I actually said was:

Popularity is good and should be high on the list of factors influencing the decisions.

Engineering is about trading off a multitude of factors including performance, price, ease of development, reliability and availability amongst many others. 'Popularity' has an impact on many of those in both the short and long terms. Your ideal 'fit for purpose' choice won't be fit for any purpose if you can't buy them because they proved to be so unpopular that the manufacturer stops making it.

Or they were unpopular because they are bug-ridden carp that don't work in the specific configuration that you need to use because the chip developers didn't test it in that mode and nobody else ran across it due to its unpopularity. And when discovered the manufacturers won't fix it because - you guessed it - it's unpopular.

I've seen too many engineers try to shoehorn an application onto an MCU that wasn't suited for that application merely because the part was popular and was the latest craze in the industry.

I'm sure that happens though I've never encountered it personally (at least in hardware design - software is a very different matter!). There are inexperienced/misguided/incompetent engineers everywhere but in a well run organisation good processes and procedures, including design reviews, ought to reduce the number of such poor design choices getting past first base.

[m12lrpv]

Stepping into the room a bit late but i'm interested in the topic. (not the argy bargy)

Like many hobbyists I started with arduino but imediately stepped away from blinking led's and started doing stuff with the chips themselves directly. Logically I moved into tiny's as there's no sense using an atmega when you only need 3 pins doing something.

Wanting to expand my horizons I tried the TI MSP430 and TM4?125 Arm chips. The issue there was they were a nightmare to program and while I did do some interesting things with the TM4 it was just too inefficient time and effor wise to try and use them.

A few years on now and I've just started shipping out another project with the atmega328p at it's heart and every pin was utilised. No room to add features in the future.

But what for the future?

I'm seeing STM32 everywhere but is that a viable upgrade?

What about programing environments? Ti's CCS really burn't me badly but from the chatter i'm seeing it sounds like things are better in STM land. I don't get a hard on from reading datasheets, they're a means to an end, so something like CubeMX sounds useful for those just trying to get a job done like I am.

The problem I have is that my projects are typically analog and the ADC is a big part of it.

I've played with analog on 3.3v before (The Ti chip) and the noise just swamps out the detail. I've spent a lot of time getting the atmega ADC's to work with good precision and I can't afford to lose that.

What are some good uC options for analog work where the inbuilt ADC's aren't complete crap? (Yes I saw Blueskull recommending PSoC 5LP and damn they look nice but oh the cost)

[wraper]

What are some good uC options for analog work where the inbuilt ADC's aren't complete crap?

Define what's "aren't complete crap".

[m12lrpv]

What are some good uC options for analog work where the inbuilt ADC's aren't complete crap?

Define what's "aren't complete crap".

Actually I won't because I don't want to restrict people responses. Needless to say though something that can handle more than just an analog keypad matrix.

[wraper]

Actually I won't because I don't want to restrict people responses. Needless to say though something that can handle more than just an analog keypad matrix.

Vague as hell. Thus you will not get any suggestion at least for me. Don't want to waste time listing something that probably will be "crap" in your opinion. Or something that's higher spec than needed and thus too expensive.

[m12lrpv]

Actually I won't because I don't want to restrict people responses. Needless to say though something that can handle more than just an analog keypad matrix.

Vague as hell. Thus you will not get any suggestion at least for me. Don't want to waste time listing something that probably will be "crap" in your opinion. Or something that's higher spec than needed and thus too expensive.

You could have just not posted at all and saved everyone from your attitude.

You're stating that you won't post any suggestions because you're expecting me to come back and declare it to be crap in my opinion. Suggesting I will do that is highly offensive. I'm after opinions based on experience and it would be very wrong for me to ask such a thing and then criticise any genuine responses. That's not how I work and you should either apologise or delete your posts.

[wraper]

Sorry for refusing giving answer to completely undefined question.

because you're expecting me to come back and declare it to be crap in my opinion.

Don't put words in my mouth. You may not say it, and keep such opinion to yourself. Regardless if you say or don't say anything, it becomes waste of time posting answer of no use.

[m12lrpv]

Sorry for refusing giving answer to completely undefined question.

No probs.  But you do understand that this isn't stack overflow?

[brucehoult]

The problem I have is that my projects are typically analog and the ADC is a big part of it.

I've played with analog on 3.3v before (The Ti chip) and the noise just swamps out the detail. I've spent a lot of time getting the atmega ADC's to work with good precision and I can't afford to lose that.

What are some good uC options for analog work where the inbuilt ADC's aren't complete crap?

Seems like you must be doing pretty specialized stuff.

The ADCs in things like ATTiny and ATMega or probably anything else  are more than good enough for most things people want them for. I don't know how accurate the last bit or two is on an absolute scale but I've always found the output to be stable and monotonic. On the ATTiny85 You can do 15k samples a second using the recommended 200 kHz ADC clock (which can be pushed to 1 MHz with some loss of accuracy?)

That's more than good enough for old fashioned telephone audio.

If you want to do CD quality then of course you need much better. I guess probably there are MCUs with built-in ADCs that good, but it might be easier (and for the analogue design too) to use an external ADC.

[PCB.Wiz]

The problem I have is that my projects are typically analog and the ADC is a big part of it.

I've played with analog on 3.3v before (The Ti chip) and the noise just swamps out the detail. I've spent a lot of time getting the atmega ADC's to work with good precision and I can't afford to lose that.

What are some good uC options for analog work where the inbuilt ADC's aren't complete crap? (Yes I saw Blueskull recommending PSoC 5LP and damn they look nice but oh the cost)

SiLabs EFM8LB1 spec a 14b ADC, and 12b DACs, so that could be worth evaluating for 'better analog' smallish MCUs.

If you want to go more fringe, and more extreme Analog, a part like this configurable sensor signal conditioner caught my eye
ZSSC3240CI3https://www.idt.com/us/en/products/sensor-products/sensor-signal-conditioners-ssc-afe/zssc3240-high-end-24-bit-sensor-signal-conditioner-analog-and-digital-output?utm_campaign=sensors_ssc_zssc3240&utm_source=press_release&utm_medium=press_release&utm_content=zssc3240_product_page


that one claims
24-bit analog-to-digital converter and 26 bits digital-signal-conditioning math core
Reprogrammable, nonvolatile memory (NVM)
Programmable 16-bit digital-to-analog-converter and output

Some vendors are now doing Wide Vcc MCU with high end ADC included
https://www.renesas.com/us/en/products/microcontrollers-microprocessors/rx/rx200/rx23e-a.html
and they also have ARM32 core versions with 24b and 16b ADC  & 12-bit D/A, 8-bit D/A
https://www.renesas.com/us/en/products/microcontrollers-microprocessors/ra/ra2/ra2a1.html#productInfo

[splin]

What are some good uC options for analog work where the inbuilt ADC's aren't complete crap? (Yes I saw Blueskull recommending PSoC 5LP and damn they look nice but oh the cost)

Well it is a bit of a "how long is a piece of string question", but here goes anyway (all based on datasheet values).

The LPC4370 has an 80MSPS 12 bit ADC with approx 10bits ENOB. 80MSPS lets you do quite a bit of oversampling to increase the resolution and still get decent sample rates.

The STM32F1 and STM32F4 processors 12bit ADCs but they are a bit noisy achieving around 10 bits ENOB. The F4's have up to 3 x 2.4MSPS ADCs which can be interleaved to sample a single signal at 7.2MSPS.

The STM32F3 range have up to 4 x 5MSPS 12 bit ADCs with 11.2bits ENOB. In practice someone here posted that the internal buses/DMA aren't fast enough to allow all 4 to sample at full speed, topping out at around 18MSPS total (if I remember correctly). In any case you have precious little processor speed to process 18MSPS of data if you need continuous streaming at full speed. You can average the samples for oversampling (but you have to do it in assembler) but not much else. Pairs of ADCs can be interleaved to 10MSPS.

The STM32F373 and 378 have 3 x 50KSPS 16 bit sigma-delta ADCs with over 14bits ENOBs.

The STM32H7 range are the best that I know of, on paper, with 3 x 3.6MSPS 16 bit ADCs with 13.2bits ENOB. But there are some severe limitations - for the gory detail see:

https://www.eevblog.com/forum/microcontrollers/stm32h7-adc-performance-ya-gotta-read-the-fine-print!/

Also note that oversampling can increase the resolution/noise performance it doesn't improve the linearity errors (INL) which rarely betters 12bits in an MCU - even the above '16 bit' ADCs.

[m12lrpv]

Seems like you must be doing pretty specialized stuff.

Induction sensors measuring metal thickness variations to a few microns. It's hobby stuff though. The ADC's on the atmega's can be massaged to give good stability providing the board layout is done properly. Fed a nice stable external V-Ref and controlling when and when not to sample, like when switching ADC channels, will let it perform pretty well.

[chriva]

Usually I'd say what gets the job done but I'm going to change the question slightly: which one has been the most fun.

I'd highly recommend old powerpc or cpu32(embedded 68020 ish) processors with a TPU. What can be done with that thing is up to your imagination. Extremely powerful co-processor for anything timing based.

[nigelwright7557]

Hi, which µC are you preffering and why?
Where to find a good reliable microcontroller, well documented, good debug features, fast to program, easy to learn good IDE, good programmer/debuger?
Or is there not the one and really depends on your needs what you prefer and which manufacturer you choose?

Choosing a microcontroller can be a nightmare especially the more complicated ones.
Its vital you read datasheet and errata sheets before choosing one.

I just started a atsame70j21b USB scope project. What a pig to even work out the power supply connections, its complicated by core running off low volts yet i/o can run off 3v3. I took ages to try to find a connection for the Snap programmer to the uC.
When  I eventually got to power it up it programmed once and the wouldnt program again. However it did flash a LED !
I opened a ticket with Microchip and they looked at my circuit.
I had reset on Snap connected to pin 6 instead of pin 1. They also threw a huge spanner in the works by telling me that the uC I had chosen the USB hardware has a bug and doesn't work !

While MPLAB x and Harmony 3 are very clever it is highly complex.

[westfw]

we evaluated for fitness for our purpose.

the "problem" is that for many, many, applications, you have a large choice of chips that are "fit for the purpose", and are left with modifiers "I know someone who has used it before", "the local SE seems very knowledgeable", "The datasheet seems more readable", "the vendor has been around for a long time", "there seems to be a good upgrade path to bigger, faster, chips", "There's a good online forum", "the vendor IDE is slightly more palatable than that other IDE", "there is more than one compiler", "the architecture is popular", and etc...

[PCB.Wiz]

Seems like you must be doing pretty specialized stuff.

Induction sensors measuring metal thickness variations to a few microns. It's hobby stuff though. The ADC's on the atmega's can be massaged to give good stability providing the board layout is done properly. Fed a nice stable external V-Ref and controlling when and when not to sample, like when switching ADC channels, will let it perform pretty well.

For that, you could also look at the new TI LDC1001  5V, 16-bit Rp, 24-bit L resolution, inductance to digital converter
https://www.ti.com/product/LDC1001

[m12lrpv]

For that, you could also look at the new TI LDC1001  5V, 16-bit Rp, 24-bit L resolution, inductance to digital converter
https://www.ti.com/product/LDC1001

The time and effort I had to put in over the last decade to get the precision I wanted and Ti go and put it into a single chip. Don't know if I should laugh or cry.   

Definitely going to have to have a look at that. 


Edit: Just had a look at the data sheet. Works on resonant frequency so unfortunately just proximity detection. Damn. Similar emotions... Don't know whether to be relieved or disapointed.

[brucehoult]

Seems like you must be doing pretty specialized stuff.

Induction sensors measuring metal thickness variations to a few microns. It's hobby stuff though. The ADC's on the atmega's can be massaged to give good stability providing the board layout is done properly. Fed a nice stable external V-Ref and controlling when and when not to sample, like when switching ADC channels, will let it perform pretty well.

Couldn't you do that with something that altered a frequency of oscillation, which then converts the task into measuring a time interval (and possibly the difference of two frequencies), which can be done very very precisely and easily?

[m12lrpv]

Couldn't you do that with something that altered a frequency of oscillation, which then converts the task into measuring a time interval (and possibly the difference of two frequencies), which can be done very very precisely and easily?

Now i'm going off topic... The way I did it was to choose the frequency needed to get the penetration of the material then subtract the Sense signal from a Refence coil signal and amplify. It works and works well but i'm always open to alternatives going forward.

[Siwastaja]

Is ATMega328 ADC crap?

If it's good enough for you, any STM32 has a better ADC. Most have two extra bits, and at least ten times the sample rate. DMA makes high sample rates piece of cake. In my experience, they are not any noisier than the AVR ADC, even when you sample with the core running.

With ARM, you don't need to use any vendor-specific IDE workflows. Just GCC, make, openocd, etc, and the code editor of your choice.

[PCB.Wiz]

For that, you could also look at the new TI LDC1001  5V, 16-bit Rp, 24-bit L resolution, inductance to digital converter
https://www.ti.com/product/LDC1001

The time and effort I had to put in over the last decade to get the precision I wanted and Ti go and put it into a single chip. Don't know if I should laugh or cry.   

Definitely going to have to have a look at that. 


Edit: Just had a look at the data sheet. Works on resonant frequency so unfortunately just proximity detection. Damn. Similar emotions... Don't know whether to be relieved or disapointed.

Try one and see.
You already know what frequency gives good change in penetration response, & frequency is easier to measure than amplitude.

[purfield]

My go-to micro controller is the PSoC 5LP.  I mostly work on a projects where the cost of the micro controller is not a huge factor, so I like the PSoC 5LP since it's like a Swiss army knife.

[Bassman59]

They also threw a huge spanner in the works by telling me that the uC I had chosen the USB hardware has a bug and doesn't work !

What exactly was the bug? I have been looking at micros with High Speed USB support, and the SAME70 ticks that box. I even bought one of their eval boards, but between Atmel Studio 7.0 and ASF and now MPLAB-X and Harmony I'm not sure of the state of support for the parts. And I got kinda lost looking though the USB stack, but that's the case with all of the vendors.

While MPLAB x and Harmony 3 are very clever it is highly complex.

And it's easy to get lost in it. You have to know a lot about the device, to the point where at that point you are able to write all of the initialization code yourself.

[PCB.Wiz]

...I have been looking at micros with High Speed USB support, and the SAME70 ticks that box. ..

I think Atmel Microchip use a HS-USB part as the USB Debug Host Bridge on their newest 8 bit Eval boards, so that would seem to be a proven choice ?
Nuvoton also have a few HS-USB parts, NUC505, M48x etc , but not in super-small packages.

[nigelwright7557]

I worked for a PIC consultancy for 13 years so most of my work was PIC based.
Got into the 8051 microcontroller at times.
In more recent years started using 32 bit PIC's for jobs like USB scopes and transistor curve tracers.
The current project is an ATSAME70 processor but it throws an exception when trying to set up I/O.
Microchip are currently looking into it for me.

[pidcon]

Hi, which µC are you preffering and why?
Where to find a good reliable microcontroller, well documented, good debug features, fast to program, easy to learn good IDE, good programmer/debuger?
Or is there not the one and really depends on your needs what you prefer and which manufacturer you choose?

My preference is PIC, simply because I worked heavily with it during my university days. Choice of compilers were scarce and expensive. I had to do all the work in assembly language, but I still enjoyed it. Over time I had used 8051, AVR, Panasonic MCUs, STM32, etc. My criteria for choosing a particular MCU to use is much like everyone else's. It boils down to:

- The manufacturer has a history of creating pin-compatible MCU families, especially when older MCUs are replaced by newer models.
- Publicly accessible datasheets, erratas, and application notes.
- Free IDE and compiler, or at least a free assembler, or an affordable compiler from a third-party tool company.
- Cheap hardware programmer, or open-source version of the programmer.
- Good options for hardware debugger/ICE tools.
- Minimal components to bring the bare MCU circuit up and running.
- Easy to purchase from local or regional distributor at low cost.

Choosing a microcontroller can be a nightmare especially the more complicated ones.
Its vital you read datasheet and errata sheets before choosing one.

Yes, a very important task before design work to be done. I just hate the periodical erratas that are published later, and having to keep track of any effects on the software and hardware.

[garethw]

I started with an Arduino Uno. Then I started asking questions like "what is this ATMega thing and how does it work". Quickly moved onto Microchip PICs and so bought myself a PICKIT3 and started writing C code. Did some 8051 assembly at uni (really enjoyed that for some reason) then took the leap to STM32. Last project was using an STM32070CB with STM32Cube IDE.

To answer your question...I like the PICs for 8 bit stuff, blinking LEDs, simple jobs. STM32s for anything a bit more complicated.

Am currently reading up on Arm assembly language, using CMSIS directly (i.e without CUBEMX) as well as dissecting the startup code (which is usually in assembly) and the linker scripts.

[Rudolph Riedel]

I am currently using ATSAMC21 & ATSAME51 as I need CAN-FD for my job.
These are not only in the group of select few that are available thru catalog distribution, these also come in both normal and Automotive qualified versions.

Only recently ST added CAN-FD to the STM32G4 series but chose to castrate the M_CAN module like they did for the STM32H7 series.

[uer166]

Only recently ST added CAN-FD to the STM32G4 series but chose to castrate the M_CAN module like they did for the STM32H7 series.

What do you mean by this? Did they cut some features from the IP or didn't provide something to it?

[Rudolph Riedel]

Only recently ST added CAN-FD to the STM32G4 series but chose to castrate the M_CAN module like they did for the STM32H7 series.

What do you mean by this? Did they cut some features from the IP or didn't provide something to it?

They gutted it in regards of memory.

With the Bosch M_CAN IP you get:
- up to 64 RX Buffers
- up to 32 TX Buffers
- TX event FIFO with up to 32 elements
- two RX FIFOs with upto 64 entries each
- up to 128 filters for 11-bit IDs
- up to 64 filters for 29-bit IDs

With the implementation in a STM32G4 you get:
- no RX Buffer
- 3 TX Buffers
- TX event FIFO with 3 elements
- two RX FIFOs with 3 entries each
- 28 filters for 11-bit IDs
- 8 filters for 29-bit IDs
 
But I was wrong about the STM32H7 series, or at least RM0399 and RM0433 do not have these restrictions.
At least not directly, but these only do have 10 Kbyte of dedicated message RAM that is shared between two CAN modules.
That is a maximum of 2560 words for all elements of two CAN modules.
A full set of elements (excluding TT) would be 4352 words per CAN module.

This is way better than the fixed and restricted message RAM layout for the G4 but still quite a severe limitation for the H7
that requires carefull planning.

[uer166]

It seems they know their market. Analog-heavy/DSP/realtime controllers usually don't need massive CAN bandwidth, makes sense that on the H7 they stuffed more CAN stuff in there since it's more of an applications processor.

I'd rather the G4 have more timers/opamps/comparators that I actually use, than extra CAN memory that is mostly pointless in this case.

[nudge]

I recently sat down with the i.MXRT 1060 reference manual to answer some questions about a design I was contemplating.  Four hours later, I had decided to use an STM32H7 instead, even though I would have preferred the extra horsepower of the NXP chip.  I cannot abide poor documentation, and the NXP reference manual was among the worst I have seen.  I could tell I would be wasting countless hours reverse-engineering the part if I were to choose it.  (In truth, almost every vendor's documentation nowadays is terrible, when compared to the 1980s or 90s, but ST Micro "wins" here by earning a C- or D+, rather than an F.)

NXP acquired the i.MX line from Freescale, and I agree, Freescale documentation is amongst some of the worst. The documentation for actual NXP designed parts are much better (ie the LPC line).

I started evaluating STM32 for a recent project and found the STM libraries pretty buggy and incomplete (USB stack anyways), so decided to give NXP a shot. I found that even though the STM docs are easier to approach, the NXP LPC ones seem more complete. Could be just me though as STM32’s are hugely popular.

[Sal Ammoniac]

I found that even though the STM docs are easier to approach, the NXP LPC ones seem more complete. Could be just me though as STM32’s are hugely popular.

I would rate STM32 docs fairly low down on the totem pole. I've read several thousand pages of ST documentation, including reference manuals, datasheets, and app notes in the last few months, and find them uniformly poorly written. They often have missing information or the information is widely scattered among many documents in an often haphazard way. For example, I recently implemented a CAN-FD driver for the STM32H743 from scratch and had to scour the reference manual, the datasheet, several app notes, and, ultimately, the Bosch M_CAN documentation in order to fit the scattered bits and pieces together sufficiently to create a working driver.

Another issue I have with ST documentation is that it all appears to be written by non-native English speakers. That's fine, but the final documents should be proofread by native English speakers to correct all of the awkward phrasing and word choice that inevitably creeps in. Some parts of the CAN-FD chapter in the STM32H7 reference manual were so bad I literally had no idea what the hell the writer was talking about (and I've written probably a dozen CAN drivers for Microchip, TI, Freescale, NXP, Infineon, and ST parts, so I am familiar with CAN).

[nigelwright7557]

I tend to use PIC microcontrollers.
MPLAB X and Harmony are free and very useful once you get used to them.
I use everything from 8 pin devices up to 100 pin devices so that fits in with ranges of PIC's.

[DavidAlfa]

Holy crap, I knew the Teensy 4.0 was fast (600MHz), but I it can be easily overclocked to 1GHz!


Will have to get it an make a 250MHz Led blink:
https://twitter.com/szeloof/status/1266054701440786434

[brucehoult]

Uh .. yes.

In my tests in 2019, it didn't actually get any faster at settings above 960 MHz. It gets hot to the touch at that, but not burn your finger hot, at least for a short time.

In my primes test, the dual-issue Teensy 4 at 960 MHz very slightly beats out the single-issue (and 64 bit) HiFive Unleashed at 1.45 GHz. (measurements made and reported on this board in 2019)

http://hoult.org/primes.txt

[DavidAlfa]

The only thing that I see, they should had made a higher pin version, without any fancy expensive stuff, just the same thing with 48,64pins.

600MHz and all that... Try to interface a LCD using RGB interface, or a external RAM...
Such power but very limited connectivity.

Edit: I saw the teensy 4.1, a little better... But that price is already the same as much more powerful options like rpi, nanopi...

[SiliconWizard]

Edit: I saw the teensy 4.1, a little better... But that price is already the same as much more powerful options like rpi, nanopi...

You can't compare them. The NXP iMXRT MCUs are still MCUs. They can be programmed baremetal, are fully documented (as opposed to SOCs on the RPi or others), and draw considerably less power. It's a completely different world.

[SiliconWizard]

In my primes test, the dual-issue Teensy 4 at 960 MHz very slightly beats out the single-issue (and 64 bit) HiFive Unleashed at 1.45 GHz. (measurements made and reported on this board in 2019)

http://hoult.org/primes.txt

For the Coremark benchmark, the iMXRT1060 series is rated at ~5 Coremark/MHz, as opposed to ~3 Coremark/MHz for the HiFive you mention (IIRC). So what you noticed seems consistent with that.

I used your code for testing and benchmarking purposes on my RISC-V core, and as I remember, the compiler generates pretty tight loops with many load-use hazards. I haven't looked at the code generated for ARM Cortex targets, but I suspect something similar. It thus isn't particularly favorable for pipelined cores (except very short pipelines). Cortex-M7 have 6-stage pipelines. The fact it's superscalar may not help as much as it could here either due to the load-use hazards. I'm sure code really taking advantage of the Cortex-M7 architecture would show a larger difference.

[brucehoult]

What I found interesting was how very much faster the M7 is compared to the A7 in the Pi 2.

[SiliconWizard]

What I found interesting was how very much faster the M7 is compared to the A7 in the Pi 2.

The Pi2 has a Cortex-A53, which is in the ARMv7 family. "A7" would not be quite correct. Just nitpicking though.

Drawing again from Coremark scores - I know this is just one benchmark but it gives a comparison point which is usually not bad - it's again not very surprising. I'll have to trust this:
https://github.com/fm4dd/sbc-benchmarks/blob/master/cm-benchmark.md
(but it seems consistent with other Coremark scores I'ven seen for similar CPUs.)

The Pi 2B has a score of 3.09 Coremark/MHz - almost the same as the HiFive Unleashed. It sounds surprising, but yes, the Cortex-M7 *is* much faster per MHz. The Pi3 should have a score similar to the M7 - haven't checked in your "primes" test results - and the Pi4 should be much faster.

[brucehoult]

What I found interesting was how very much faster the M7 is compared to the A7 in the Pi 2.

The Pi2 has a Cortex-A53, which is in the ARMv7 family. "A7" would not be quite correct. Just nitpicking though.

I can assure you that *my* Pi 2, purchased in February 2015 when that was the best Pi available, has a 900 MHz Cortex A7.

After the Pi 3 was released in February 2016, a new Pi 2 v1.2 with derated A53 was released in October 2016.

I have no idea why anyone would buy an A53 Pi 2 as the price is the same as the faster Pi 3 which was released 8 months earlier.

[SiliconWizard]

What I found interesting was how very much faster the M7 is compared to the A7 in the Pi 2.

The Pi2 has a Cortex-A53, which is in the ARMv7 family. "A7" would not be quite correct. Just nitpicking though.

I can assure you that *my* Pi 2, purchased in February 2015 when that was the best Pi available, has a 900 MHz Cortex A7.

After the Pi 3 was released in February 2016, a new Pi 2 v1.2 with derated A53 was released in October 2016.

I have no idea why anyone would buy an A53 Pi 2 as the price is the same as the faster Pi 3 which was released 8 months earlier.

I'm not ultra familiar with all the Cortex-A series, so I had to check a little. So here it is:

- The Cortex-A7 is a 32-bit processor, the last of the aarch32 series as far as I've understood. Armv7 architecture.
- The Cortex-A53 is a 64-bit processor, aarch64. Armv8 architecture.

As to the Pi2, I must have been confused with the two versions. The Coremark score I linked to above is for the version with a Cortex-A7 as far as I can tell. And yes, the M7 is much faster per MHz.

[brucehoult]

What I found interesting was how very much faster the M7 is compared to the A7 in the Pi 2.

The Pi2 has a Cortex-A53, which is in the ARMv7 family. "A7" would not be quite correct. Just nitpicking though.

I can assure you that *my* Pi 2, purchased in February 2015 when that was the best Pi available, has a 900 MHz Cortex A7.

After the Pi 3 was released in February 2016, a new Pi 2 v1.2 with derated A53 was released in October 2016.

I have no idea why anyone would buy an A53 Pi 2 as the price is the same as the faster Pi 3 which was released 8 months earlier.

I'm not ultra familiar with all the Cortex-A series, so I had to check a little. So here it is:

- The Cortex-A7 is a 32-bit processor, the last of the aarch32 series as far as I've understood. Armv7 architecture.

Yes, of course. Just like the M7.

The Cortex A15 is a much more powerful out-of-order 32 bit CPU, found in things such as the Odroid XU3/4 (Samsung Exynos 5422) and the Apple A6 (iPhone 5 -- apparently a fairly tweaked A15, not standard).

- The Cortex-A53 is a 64-bit processor, aarch64. Armv8 architecture.

When used in a Raspberry Pi, the A53 is used only in 32 bit mode. In fact the Raspbian operating system and applications use only the 32 bit fixed-length ARMv6 instruction set, for compatibility with the original Raspberry Pi and Pi Zero.

It is only in the last year, approximately, that an experimental 64 bit ARMv8-A Raspbian has been available even though Raspberry Pis for the last five years have had 64 bit-capable CPUs.

They seem to have skipped using the ARMv7-A (i.e. Thumb2) instruction set entirely.

[SiliconWizard]

When used in a Raspberry Pi, the A53 is used only in 32 bit mode. In fact the Raspbian operating system and applications use only the 32 bit fixed-length ARMv6 instruction set, for compatibility with the original Raspberry Pi and Pi Zero.

It is only in the last year, approximately, that an experimental 64 bit ARMv8-A Raspbian has been available even though Raspberry Pis for the last five years have had 64 bit-capable CPUs.

I think we're getting off-topic... but just to say, for RPi's, my distribution of choice has been ArchLinux ARM for years: https://archlinuxarm.org/
A 64-bit version has been available for several years now. Never had any issue.

As to again the A7 and M7, they may both have a common ancestor, but the architecture is slightly different: Armv7-A for the A7, Armv7E-M for the M7.
The A7 is a 8-stage pipeline. Not sure if it's superscalar (if you happen to know?)
The M7 is a 6-stage pipeline, superscalar.
As we can again see from benchmarks, their raw performance is quite different.

[westfw]

yes, the M7 is much faster per MHz.

Well, I'd expect the external memory to be slower, right?

[brucehoult]

I found instructions for installing 64 bit Arch on the Pi 3 from November 17 2018, about 2.4 years ago. The Pi 3 has been out for five years.

That's great you've been using 64 bit Arch for a couple of years. I've only ever run 64 bit Ubuntu on my Pi 4 too.

Almost three years from the hardware coming out to getting 64 bit OS support from 3rd parties seems rather slow to me.

The official Raspberry Pi OS 64 bit version is still now in beta. In the latest snapshot in November things such as accelerated video still don't work. It's not even easy to find -- as far as I can tell the way to find it is basically this thread on the forums:

https://www.raspberrypi.org/forums/viewtopic.php?t=275370

More than five years after 64 bit Pi hardware came out, I find this ... surprising ... disappointing ... rather poor form ...

[brucehoult]

yes, the M7 is much faster per MHz.

Well, I'd expect the external memory to be slower, right?

The benchmark I'm using uses 8000 + epsilon bytes of RAM. It fits into a Mega2560, and into the L1 cache (i.e. static RAM) of pretty much anything, including the Cortex A7.

Coremark and Dhrystone will also fit into the L1 caches.

[SiliconWizard]

More than five years after 64 bit Pi hardware came out, I find this ... surprising ... disappointing ... rather poor form ...

I think this has been discussed on a regular basis, but software support on most of those SBCs is lacking, and usually after a couple years, the vendors release a new model, and stop improving the support for the older ones. So you're screwed. The RPi foundation is not the worst out there for that, it's actually not all bad, but it's still lacking. And again the fact those boards use SOCs the documentation of which is very hard to get just prevents effective contributions.

[westfw]

I found instructions for installing 64 bit Arch on the Pi 3 from November 17 2018, about 2.4 years ago. The Pi 3 has been out for five years.

Whatever.  I thought the driving factor behind 64bits was support for more than 4G of address space, so I don't see a lot of motivation (or need) for porting a 64bit OS to hardware with 1GB of RAM...

[brucehoult]

I found instructions for installing 64 bit Arch on the Pi 3 from November 17 2018, about 2.4 years ago. The Pi 3 has been out for five years.

Whatever.  I thought the driving factor behind 64bits was support for more than 4G of address space, so I don't see a lot of motivation (or need) for porting a 64bit OS to hardware with 1GB of RAM...

In ARM and x86 land the 64 bit ISAs also have twice the number of registers -- and more than twice the *usable* registers as things such as PC and SP and FP and LR taker a fixed overhead out of the registers (and on arm64 the PC isn't in a general register at all)

Even when the current hardware has less than 4 GB, you may want to get a head start on writing software that will run on systems with more than 4 GB. Raspberry Pis are now available with 8 GB RAM -- and the supported OS is still 32 bit.

The A53 in the Pi 3 runs 64 bit code about 20% faster than 32 bit code.

There are a ton of reasons.

[SiliconWizard]

I found instructions for installing 64 bit Arch on the Pi 3 from November 17 2018, about 2.4 years ago. The Pi 3 has been out for five years.

Whatever.  I thought the driving factor behind 64bits was support for more than 4G of address space, so I don't see a lot of motivation (or need) for porting a 64bit OS to hardware with 1GB of RAM...

In ARM and x86 land the 64 bit ISAs also have twice the number of registers -- and more than twice the *usable* registers as things such as PC and SP and FP and LR taker a fixed overhead out of the registers (and on arm64 the PC isn't in a general register at all)

Even when the current hardware has less than 4 GB, you may want to get a head start on writing software that will run on systems with more than 4 GB. Raspberry Pis are now available with 8 GB RAM -- and the supported OS is still 32 bit.

The A53 in the Pi 3 runs 64 bit code about 20% faster than 32 bit code.

There are a ton of reasons.

Yep, yep!

[nctnico]

The A53 in the Pi 3 runs 64 bit code about 20% faster than 32 bit code.

This seems odd to me. It is likely that the instruction set in 64 bit mode is optimised better compared to an older 32 bit instruction set. Also keep in mind that on 64bit ARM an integer in C is still 32 bit!

[brucehoult]

The A53 in the Pi 3 runs 64 bit code about 20% faster than 32 bit code.

This seems odd to me. It is likely that the instruction set in 64 bit mode is optimised better compared to an older 32 bit instruction set. Also keep in mind that on 64bit ARM an integer in C is still 32 bit!

With the exception of PUSH and POP (or LDM/STM) with more than two registers, A64 programs tend to use fewer instructions than A32 or T32 programs. The code size between A32 and A64 is often not much different, with A32 smaller in function entry and exit code, but A64 smaller in loops (and so executing fewer instructions overall if the loops iterate a few times).

It's certainly possible that some 64 bit CPU core might implement 32 bit instructions less efficiently due to the pipeline being optimized for only what the 64 bit instruction set needs. For example it's very likely that PUSH/POP/LDM/STM might execute at 1 clock cycle per register (as in fact 32 bit cores do), while 64 bit LDP/STP run at 1 clock cycle per *pair *of registers. It's even possible a 64 bit core might take a clock cycle for every register, whether it is included in the mask or not, at least until the mask becomes 0. As A64 doesn't have/need predication, it's possible A32 predicated instructions and T32 IT* instructions might be executed in the pipeline as a conditional branch for every predicated instruction. I can't recall off-hand whether every A32 addressing mode is also present in A64. If not then some might be split into 2 uops on some 64 bit cores.

From the ARMv8-A manual:

"ARMv8-A deprecates some uses of the T32 IT instruction. All uses of IT that apply to instructions other than a single
subsequent 16-bit instruction from a restricted set are deprecated, as are explicit references to the PC within that
single 16-bit instruction. This permits the non-deprecated forms of IT and subsequent instructions to be treated as a
single 32-bit conditional instruction."

To me this suggests ARM intends the execution pipeline (on cores that support both 32 bit and 64 bit) to efficiently handle this restricted set of uses of IT, but other uses may be lower performance or even, after some time, not supported at all.

As far as I can tell, the A53 core executes 32 bit code as efficiently as possible (not worse than an A7, for example). But I think STP/LDP in function entry/exit code are faster than PUSH/POP (even if they are bigger code), and A64 executes fewer instructions in a number of other situations.


The size of a C integer depends on what OS / ABI / compiler you are using. It's true that most 64 bit systems have settled on an "LP64" model (Long and Pointer are 64 bits, Int remains 32) with fewer adopting ILP64 and Windows using LLP64 (Both int and long are 32 bits, you need to cast pointers ti use long long for pointer arithmetic).

There are also ILP32 environments on 64 bit instruction sets which allows you to make use of more registers and a more modern instruction set on x86 and ARM 64 bit without increasing memory usage of data structures containing pointers, if 4 GB is enough for a single program. The x32 ABI on Linux is an example. The arm64 processor in the Apple Watch is used with an ILP32 ABI also.

The hardware doesn't care.

As long as you use types such as size_t, ptrdiff_t, uintptr_t in your C code then the programmer also doesn't care whether a pointer needs to be cast to int, long, or long long.