What µC are you preffering - Page 1
Forum section: electronics / general

author: Attobos
author_rank: Newbie
timestamp: March 05, 2020, 07:14:17 pm
content: 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?

author: balage
author_rank: Regular Contributor
timestamp: March 06, 2020, 09:34:48 am
content: 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.

author: wraper
author_rank: Unknown
timestamp: March 06, 2020, 09:41:37 am
content: 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: March 06, 2020, 10:08:32 am
content: 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 implementationactuallyworks - see separate "errata" to partially find out what they actually sold you, reverse-engineer the rest) are definite cons, but not showstoppers.

author: balage
author_rank: Regular Contributor
timestamp: March 06, 2020, 10:16:31 am
content: Quote from: blueskull on March 06, 2020, 09:52:10 amYes, 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?

author: Siwastaja
author_rank: Super Contributor
timestamp: March 06, 2020, 10:49:30 am
content: Quote from: balage on March 06, 2020, 10:16:31 amThere 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, youneedto get the things done, and learn how to cope. After graduating this harsh reality, you are ready for any MCU you'll ever find!

author: RoadRunner
author_rank: Frequent Contributor
timestamp: March 06, 2020, 11:08:33 am
content: 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.

author: brucehoult
author_rank: Super Contributor
timestamp: March 06, 2020, 11:29:06 am
content: Quote from: Attobos on March 05, 2020, 07:14:17 pmIt 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/B07TGF9VMQThe 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.htmlYou 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.

author: balage
author_rank: Regular Contributor
timestamp: March 06, 2020, 12:03:22 pm
content: Quote from: blueskull on March 06, 2020, 10:45:41 amAh, 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.

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: March 06, 2020, 07:35:28 pm
content: 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

author: luiHS
author_rank: Frequent Contributor
timestamp: March 07, 2020, 12:08:25 am
content: 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.

author: mark03
author_rank: Frequent Contributor
timestamp: March 07, 2020, 01:06:44 am
content: 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.)

author: Styno
author_rank: Regular Contributor
timestamp: March 07, 2020, 08:08:17 pm
content: 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.

author: ogden
author_rank: Super Contributor
timestamp: March 07, 2020, 09:30:43 pm
content: Quote from: Attobos on March 05, 2020, 07:14:17 pmRight. 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.

author: daqq
author_rank: Super Contributor
timestamp: March 07, 2020, 10:49:05 pm
content: 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.

author: MarkR42
author_rank: Regular Contributor
timestamp: March 07, 2020, 11:21:35 pm
content: 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.

author: norand
author_rank: Contributor
timestamp: March 08, 2020, 01:02:12 am
content: 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!

author: ogden
author_rank: Super Contributor
timestamp: March 08, 2020, 07:47:24 am
content: Quote from: norand on March 08, 2020, 01:02:12 amRight. 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: March 08, 2020, 05:06:30 pm
content: Quote from: Attobos on March 05, 2020, 07:14:17 pmWhen 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.

author: ogden
author_rank: Super Contributor
timestamp: March 08, 2020, 06:37:28 pm
content: Quote from: NorthGuy on March 08, 2020, 05:06:30 pmThis 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

author: nigelwright7557
author_rank: Frequent Contributor
timestamp: March 08, 2020, 06:48:52 pm
content: 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.

author: luiHS
author_rank: Frequent Contributor
timestamp: March 08, 2020, 09:07:32 pm
content: 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, RT10202.- NXP Kinetis MK66, MK263.- ST STM32Completely discarded for a long time, PIC32 and ATSAMS70 (S70, E70, V70), both from Microchip.

author: mcovington
author_rank: Regular Contributor
timestamp: March 08, 2020, 09:24:27 pm
content: 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.)

author: amymcneil
author_rank: Contributor
timestamp: March 08, 2020, 11:56:25 pm
content: 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: March 09, 2020, 01:43:38 am
content: Quote from: ogden on March 08, 2020, 06:37:28 pmLoL!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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 09, 2020, 01:52:32 am
content: 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*

author: techman-001
author_rank: Frequent Contributor
timestamp: March 09, 2020, 02:36:15 am
content: Quote from: SiliconWizard on March 09, 2020, 01:52:32 amDid you miss the recent one about "what's your favorite OS" ?

author: ogden
author_rank: Super Contributor
timestamp: March 09, 2020, 05:13:14 am
content: Quote from: NorthGuy on March 09, 2020, 01:43:38 amComplexity of those MCU's differ. Amount of user manual pages to read indeed makes difference - for beginner. The simpler the better.

author: westfw
author_rank: Super Contributor
timestamp: March 09, 2020, 07:48:12 am
content: 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. :-(

author: brucehoult
author_rank: Super Contributor
timestamp: March 09, 2020, 09:07:33 am
content: Quote from: westfw on March 09, 2020, 07:48:12 amI 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.

author: hans
author_rank: Super Contributor
timestamp: March 09, 2020, 09:46:52 am
content: Quote from: NorthGuy on March 09, 2020, 01:43:38 amOf 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.

author: Psi
author_rank: Super Contributor
timestamp: March 09, 2020, 10:47:28 am
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 09, 2020, 05:01:27 pm
content: Quote from: techman-001 on March 09, 2020, 02:36:15 amWhich one?

author: techman-001
author_rank: Frequent Contributor
timestamp: March 09, 2020, 05:58:12 pm
content: Quote from: SiliconWizard on March 09, 2020, 05:01:27 pmhttps://www.eevblog.com/forum/programming/what-os-do-you-use-for-embedded-software-development/msg2952618/#msg2952618

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 09, 2020, 06:11:34 pm
content: Quote from: techman-001 on March 09, 2020, 05:58:12 pm- 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.

author: techman-001
author_rank: Frequent Contributor
timestamp: March 09, 2020, 07:16:39 pm
content: Quote from: Psi on March 09, 2020, 10:47:28 amThe 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 ?

author: Psi
author_rank: Super Contributor
timestamp: March 09, 2020, 10:10:05 pm
content: 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

author: reyntjensm
author_rank: Regular Contributor
timestamp: March 10, 2020, 12:04:08 am
content: 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.

author: steenerson
author_rank: Newbie
timestamp: March 10, 2020, 06:42:43 am
content: Quote from: wraper on March 06, 2020, 09:41:37 amVery 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!

author: brucehoult
author_rank: Super Contributor
timestamp: March 10, 2020, 08:12:42 am
content: Quote from: steenerson on March 10, 2020, 06:42:43 amOk, 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.

author: wraper
author_rank: Unknown
timestamp: March 10, 2020, 09:34:53 am
content: Quote from: brucehoult on March 10, 2020, 08:12:42 amThere 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-QFN20EFM8UB10F16G-C-QFN20EFM8UB10F16G-C-QFN28BTW you can get USB VID/PID from Silabs for free.

author: brucehoult
author_rank: Super Contributor
timestamp: March 10, 2020, 10:32:38 am
content: 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.

author: Scrts
author_rank: Frequent Contributor
timestamp: March 10, 2020, 05:10:10 pm
content: Quote from: blueskull on March 10, 2020, 04:00:17 pmIt 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.

author: wraper
author_rank: Unknown
timestamp: March 10, 2020, 05:18:32 pm
content: Quote from: Scrts on March 10, 2020, 05:10:10 pmYou 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.

author: nctnico
author_rank: Super Contributor
timestamp: March 10, 2020, 05:33:28 pm
content: Quote from: blueskull on March 10, 2020, 04:00:17 pmThat 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.

author: rx8pilot
author_rank: Super Contributor
timestamp: March 10, 2020, 06:36:40 pm
content: Quote from: wraper on March 10, 2020, 05:18:32 pmI 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.

author: wraper
author_rank: Unknown
timestamp: March 10, 2020, 06:44:47 pm
content: Quote from: rx8pilot on March 10, 2020, 06:36:40 pmDon'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.

author: rx8pilot
author_rank: Super Contributor
timestamp: March 10, 2020, 07:12:48 pm
content: Quote from: wraper on March 10, 2020, 06:44:47 pmFair 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: March 10, 2020, 07:59:39 pm
content: Quote from: blueskull on March 10, 2020, 04:00:17 pmThe 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.

author: brucehoult
author_rank: Super Contributor
timestamp: March 10, 2020, 09:09:20 pm
content: Quote from: NorthGuy on March 10, 2020, 07:59:39 pmI'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.

author: MarkR42
author_rank: Regular Contributor
timestamp: March 10, 2020, 10:13:55 pm
content: Quote from: brucehoult on March 10, 2020, 09:09:20 pmYeah, 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: March 10, 2020, 11:30:50 pm
content: Quote from: brucehoult on March 10, 2020, 09:09:20 pmI 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).Quote from: MarkR42 on March 10, 2020, 10:13:55 pmThe air temperature must've been too high.

author: nctnico
author_rank: Super Contributor
timestamp: March 11, 2020, 07:55:24 pm
content: Quote from: blueskull on March 10, 2020, 06:02:56 pmI 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.

author: ogden
author_rank: Super Contributor
timestamp: March 18, 2020, 10:39:47 pm
content: Quote from: Psi on March 09, 2020, 10:10:05 pmWhen 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.

author: Psi
author_rank: Super Contributor
timestamp: March 18, 2020, 10:48:20 pm
content: Quote from: NorthGuy on March 10, 2020, 07:59:39 pmyeah, 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

author: NorthGuy
author_rank: Super Contributor
timestamp: March 19, 2020, 03:07:05 pm
content: Quote from: Psi on March 18, 2020, 10:48:20 pmPutting 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.

author: Scrts
author_rank: Frequent Contributor
timestamp: March 19, 2020, 08:46:37 pm
content: Quote from: NorthGuy on March 19, 2020, 03:07:05 pmWhen 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.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: March 20, 2020, 01:36:20 am
content: I definitely do not agree with:QuoteWhen 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.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: March 24, 2020, 04:30:48 pm
content: 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: March 24, 2020, 05:20:00 pm
content: Quote from: Doctorandus_P on March 20, 2020, 01:36:20 amYou won't believe how many people still use these old PIC16s. The question is why?

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 24, 2020, 05:23:30 pm
content: Quote from: NorthGuy on March 24, 2020, 05:20:00 pmComfort zone.

author: wraper
author_rank: Unknown
timestamp: March 24, 2020, 05:40:37 pm
content: Quote from: NorthGuy on March 24, 2020, 05:20:00 pmLazy 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.

author: firewalker
author_rank: Super Contributor
timestamp: March 25, 2020, 11:12:10 am
content: 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.

author: Scrts
author_rank: Frequent Contributor
timestamp: March 25, 2020, 07:30:23 pm
content: Quote from: firewalker on March 25, 2020, 11:12:10 am10 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: March 25, 2020, 09:01:53 pm
content: Quote from: Scrts on March 25, 2020, 07:30:23 pmLook 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.

author: Scrts
author_rank: Frequent Contributor
timestamp: March 26, 2020, 02:52:26 am
content: Quote from: NorthGuy on March 25, 2020, 09:01:53 pmExactly 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...

author: westfw
author_rank: Super Contributor
timestamp: March 26, 2020, 04:02:52 pm
content: 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.

author: jmelson
author_rank: Super Contributor
timestamp: March 26, 2020, 04:36:28 pm
content: Quote from: firewalker on March 25, 2020, 11:12:10 amYes, 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

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 26, 2020, 04:47:35 pm
content: 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.

author: jemangedeslolos
author_rank: Frequent Contributor
timestamp: March 27, 2020, 02:45:28 pm
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 27, 2020, 03:05:18 pm
content: Quote from: jemangedeslolos on March 27, 2020, 02:45:28 pmSTM32 MCUs have this as well.

author: jemangedeslolos
author_rank: Frequent Contributor
timestamp: March 27, 2020, 03:11:44 pm
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 27, 2020, 03:15:48 pm
content: Quote from: jemangedeslolos on March 27, 2020, 03:11:44 pmHave 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.

author: jemangedeslolos
author_rank: Frequent Contributor
timestamp: March 27, 2020, 03:31:53 pm
content: Quote from: SiliconWizard on March 27, 2020, 03:15:48 pmone example :On STM32F446 you only have 2 options :you can have SPI1 on PA5 PA6 PA7.PA5 is SCKPA6 is MISOPA7 is MOSIor you can have SPI1 on PB3 PB4 PB5PB3 is SCKPB4 is MISOPB5 is MOSIdsPIC33EP512MC806 :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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 27, 2020, 03:52:46 pm
content: Quote from: jemangedeslolos on March 27, 2020, 03:31:53 pmOh, 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.

author: jemangedeslolos
author_rank: Frequent Contributor
timestamp: March 27, 2020, 04:15:20 pm
content: 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 kiddingI 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 27, 2020, 04:33:26 pm
content: Quote from: jemangedeslolos on March 27, 2020, 04:15:20 pmNothing prevents you from still using PIC MCUs depending on the project?

author: NorthGuy
author_rank: Super Contributor
timestamp: March 27, 2020, 04:34:11 pm
content: Quote from: jemangedeslolos on March 27, 2020, 04:15:20 pmWhy didn't you?

author: jemangedeslolos
author_rank: Frequent Contributor
timestamp: March 27, 2020, 07:14:43 pm
content: 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.

author: westfw
author_rank: Super Contributor
timestamp: March 28, 2020, 01:45:59 am
content: QuoteQuoteHeh. 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 :-( )

author: Psi
author_rank: Super Contributor
timestamp: March 28, 2020, 02:22:33 pm
content: 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

author: NorthGuy
author_rank: Super Contributor
timestamp: March 28, 2020, 06:01:19 pm
content: Quote from: Psi on March 28, 2020, 02:22:33 pmGet FPGA. This gives you real freedom in pin assignment.

author: nctnico
author_rank: Super Contributor
timestamp: March 29, 2020, 02:31:12 am
content: Quote from: NorthGuy on March 28, 2020, 06:01:19 pmNot 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: March 29, 2020, 02:56:47 am
content: Quote from: nctnico on March 29, 2020, 02:31:12 amSure 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.

author: ogden
author_rank: Super Contributor
timestamp: March 29, 2020, 02:34:06 pm
content: Quote from: NorthGuy on March 29, 2020, 02:56:47 amDo 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, checkCypress PSoC MCU's first (pdf).

author: NorthGuy
author_rank: Super Contributor
timestamp: March 29, 2020, 02:58:27 pm
content: Quote from: ogden on March 29, 2020, 02:34:06 pmNo

author: ogden
author_rank: Super Contributor
timestamp: March 29, 2020, 03:04:57 pm
content: Quote from: NorthGuy on March 29, 2020, 02:58:27 pmRiiiightAnyway check PSoC before you continue with your FPGA mantra.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 29, 2020, 03:26:04 pm
content: 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: March 29, 2020, 04:06:57 pm
content: Quote from: ogden on March 29, 2020, 03:04:57 pmFPGAs 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.

author: ogden
author_rank: Super Contributor
timestamp: March 29, 2020, 05:21:01 pm
content: Quote from: NorthGuy on March 29, 2020, 04:06:57 pmIndeed 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: March 29, 2020, 07:11:18 pm
content: Quote from: ogden on March 29, 2020, 05:21:01 pmI 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.

author: ogden
author_rank: Super Contributor
timestamp: March 29, 2020, 07:23:39 pm
content: Quote from: NorthGuy on March 29, 2020, 07:11:18 pmYou think or know?QuoteRight. How many dream MCU's did you built using FPGA? What did you successfully build using FPGA, if anything?

author: NorthGuy
author_rank: Super Contributor
timestamp: March 29, 2020, 09:00:49 pm
content: Quote from: ogden on March 29, 2020, 07:23:39 pmComplexity 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.QuoteNone. 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.

author: ogden
author_rank: Super Contributor
timestamp: March 29, 2020, 09:22:24 pm
content: Quote from: NorthGuy on March 29, 2020, 09:00:49 pmWhen you *actually* do something complex - you know metrics.

author: NorthGuy
author_rank: Super Contributor
timestamp: March 29, 2020, 10:00:53 pm
content: Quote from: ogden on March 29, 2020, 09:22:24 pmWhat metrics? What units do you measure it in?

author: ogden
author_rank: Super Contributor
timestamp: March 29, 2020, 10:59:54 pm
content: Quote from: NorthGuy on March 29, 2020, 10:00:53 pmhttps://en.wikipedia.org/wiki/Man-hour

author: rvalente
author_rank: Frequent Contributor
timestamp: March 30, 2020, 01:09:16 am
content: For general use in automotive electronics?Not for making a engine control module, but still OEM, why would you use?

author: NorthGuy
author_rank: Super Contributor
timestamp: March 30, 2020, 01:52:46 pm
content: Quote from: ogden on March 29, 2020, 10:59:54 pmWell. 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.

author: ogden
author_rank: Super Contributor
timestamp: March 30, 2020, 02:53:56 pm
content: Quote from: NorthGuy on March 30, 2020, 01:52:46 pmRight. 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: March 30, 2020, 04:01:32 pm
content: Quote from: ogden on March 30, 2020, 02:53:56 pmWhy 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.

author: crayon
author_rank: Newbie
timestamp: March 30, 2020, 05:22:42 pm
content: 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....

author: ogden
author_rank: Super Contributor
timestamp: March 31, 2020, 02:16:41 am
content: Quote from: NorthGuy on March 30, 2020, 04:01:32 pm"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

author: Bassman59
author_rank: Super Contributor
timestamp: March 31, 2020, 05:38:11 am
content: Quote from: ogden on March 31, 2020, 02:16:41 amOr, 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 designisan 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.

author: ogden
author_rank: Super Contributor
timestamp: March 31, 2020, 08:25:47 pm
content: Quote from: Bassman59 on March 31, 2020, 05:38:11 amYes 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 isrecurring topichere.

author: Bassman59
author_rank: Super Contributor
timestamp: March 31, 2020, 09:10:30 pm
content: Quote from: ogden on March 31, 2020, 08:25:47 pmYeah, that makes no sense at all.

author: psysc0rpi0n
author_rank: Frequent Contributor
timestamp: April 16, 2020, 10:40:16 pm
content: 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!

author: brucehoult
author_rank: Super Contributor
timestamp: April 16, 2020, 11:39:03 pm
content: 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!

author: ogden
author_rank: Super Contributor
timestamp: April 17, 2020, 05:01:39 pm
content: Quote from: psysc0rpi0n on April 16, 2020, 10:40:16 pmFor 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: April 17, 2020, 05:56:40 pm
content: Quote from: ogden on April 17, 2020, 05:01:39 pmYeah, 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.

author: ogden
author_rank: Super Contributor
timestamp: April 17, 2020, 06:07:51 pm
content: Quote from: NorthGuy on April 17, 2020, 05:56:40 pmYes, you need toknowbe 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).

author: NorthGuy
author_rank: Super Contributor
timestamp: April 17, 2020, 07:02:06 pm
content: Quote from: ogden on April 17, 2020, 06:07:51 pmYou 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?

author: ogden
author_rank: Super Contributor
timestamp: April 17, 2020, 07:29:13 pm
content: Quote from: NorthGuy on April 17, 2020, 07:02:06 pmI 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".

author: NorthGuy
author_rank: Super Contributor
timestamp: April 17, 2020, 08:02:37 pm
content: Quote from: ogden on April 17, 2020, 07:29:13 pmWould 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.

author: ogden
author_rank: Super Contributor
timestamp: April 17, 2020, 08:20:45 pm
content: Quote from: NorthGuy on April 17, 2020, 08:02:37 pmIt 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)?

author: NorthGuy
author_rank: Super Contributor
timestamp: April 17, 2020, 09:06:25 pm
content: Quote from: ogden on April 17, 2020, 08:20:45 pmI 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.

author: brucehoult
author_rank: Super Contributor
timestamp: April 18, 2020, 12:22:02 am
content: Quote from: ogden on April 17, 2020, 06:07:51 pmThere 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)

author: ogden
author_rank: Super Contributor
timestamp: April 18, 2020, 06:53:15 pm
content: Quote from: NorthGuy on April 17, 2020, 09:06:25 pmI 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: April 18, 2020, 09:47:45 pm
content: Quote from: ogden on April 18, 2020, 06:53:15 pmI 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.

author: psysc0rpi0n
author_rank: Frequent Contributor
timestamp: April 20, 2020, 08:57:45 pm
content: Quote from: brucehoult on April 16, 2020, 11:39:03 pmHello.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!

author: ogden
author_rank: Super Contributor
timestamp: April 20, 2020, 09:11:10 pm
content: Quote from: NorthGuy on April 18, 2020, 09:47:45 pmYes 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.

author: brucehoult
author_rank: Super Contributor
timestamp: April 21, 2020, 01:44:36 am
content: Quote from: psysc0rpi0n on April 20, 2020, 08:57:45 pmI 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.

author: brucehoult
author_rank: Super Contributor
timestamp: April 21, 2020, 02:04:09 am
content: Quote from: ogden on April 20, 2020, 09:11:10 pmOMG. 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 XC402018: Volvo XC602017: Mazda CX-92016: Mazda MX-52015: -2014: BMW i32013: VW Golf VII2012: Toyota 86 / Subaru BRZ2011: Honda CRZ2010: VW PoloThis 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.

author: westfw
author_rank: Super Contributor
timestamp: April 21, 2020, 08:28:19 am
content: QuoteARM (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.

author: ogden
author_rank: Super Contributor
timestamp: April 21, 2020, 10:06:14 am
content: Quote from: brucehoult on April 21, 2020, 02:04:09 amLOL. You must be kidding? I did mean itfiguratively. Please do not derail this discussion into pointlessabout actual cars.

author: brucehoult
author_rank: Super Contributor
timestamp: April 21, 2020, 12:25:23 pm
content: Quote from: westfw on April 21, 2020, 08:28:19 amSince 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: April 21, 2020, 12:58:55 pm
content: Quote from: ogden on April 20, 2020, 09:11:10 pmWhen 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.

author: ogden
author_rank: Super Contributor
timestamp: April 22, 2020, 06:31:30 pm
content: Quote from: NorthGuy on April 21, 2020, 12:58:55 pmDoes 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.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: April 22, 2020, 09:04:23 pm
content: Quote from: ogden on April 22, 2020, 06:31:30 pm+1When 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.

author: splin
author_rank: Frequent Contributor
timestamp: April 22, 2020, 11:53:06 pm
content: Quote from: Sal Ammoniac on April 22, 2020, 09:04:23 pmThen 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.QuoteRisking 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. 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: April 23, 2020, 03:46:58 am
content: Quote from: ogden on April 22, 2020, 06:31:30 pmMay 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 23, 2020, 05:44:02 pm
content: 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.

author: NorthGuy
author_rank: Super Contributor
timestamp: April 23, 2020, 06:40:26 pm
content: Quote from: SiliconWizard on April 23, 2020, 05:44:02 pmOf 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.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: May 19, 2020, 10:46:06 pm
content: Quote from: splin on April 22, 2020, 11:53:06 pmDid you read what I wrote? I said we evaluated forfitness 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 19, 2020, 11:02:16 pm
content: Quote from: Sal Ammoniac on May 19, 2020, 10:46:06 pmYes, that's hype-driven development.

author: splin
author_rank: Frequent Contributor
timestamp: May 21, 2020, 10:55:21 pm
content: Quote from: Sal Ammoniac on May 19, 2020, 10:46:06 pmOf course I did thank you - that was why I responded.QuotePerhaps you could have had the courtesy to have actually read what I wrote? It was all about why popular is important.QuoteObviously, 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:QuoteEngineering 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.QuoteI'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.

author: m12lrpv
author_rank: Regular Contributor
timestamp: May 21, 2020, 11:16:42 pm
content: 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)

author: wraper
author_rank: Unknown
timestamp: May 21, 2020, 11:29:45 pm
content: Quote from: m12lrpv on May 21, 2020, 11:16:42 pmDefine what's "aren't complete crap".

author: m12lrpv
author_rank: Regular Contributor
timestamp: May 21, 2020, 11:39:05 pm
content: Quote from: wraper on May 21, 2020, 11:29:45 pmActually 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.

author: wraper
author_rank: Unknown
timestamp: May 21, 2020, 11:58:18 pm
content: Quote from: m12lrpv on May 21, 2020, 11:39:05 pmVague 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.

author: m12lrpv
author_rank: Regular Contributor
timestamp: May 22, 2020, 12:05:57 am
content: Quote from: wraper on May 21, 2020, 11:58:18 pmYou 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.

author: wraper
author_rank: Unknown
timestamp: May 22, 2020, 12:08:53 am
content: Sorry for refusing giving answer to completely undefined question.QuoteDon'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.

author: m12lrpv
author_rank: Regular Contributor
timestamp: May 22, 2020, 12:13:13 am
content: Quote from: wraper on May 22, 2020, 12:08:53 amNo probs.But you do understand that this isn't stack overflow?

author: brucehoult
author_rank: Super Contributor
timestamp: May 22, 2020, 12:20:15 am
content: Quote from: m12lrpv on May 21, 2020, 11:16:42 pmSeems 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.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: May 22, 2020, 12:34:30 am
content: Quote from: m12lrpv on May 21, 2020, 11:16:42 pmSiLabs 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 eyeZSSC3240CI3https://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_pagethat one claims24-bit analog-to-digital converter and 26 bits digital-signal-conditioning math coreReprogrammable, nonvolatile memory (NVM)Programmable 16-bit digital-to-analog-converter and outputSome vendors are now doing Wide Vcc MCU with high end ADC includedhttps://www.renesas.com/us/en/products/microcontrollers-microprocessors/rx/rx200/rx23e-a.htmland they also have ARM32 core versions with 24b and 16b ADC & 12-bit D/A, 8-bit D/Ahttps://www.renesas.com/us/en/products/microcontrollers-microprocessors/ra/ra2/ra2a1.html#productInfo

author: splin
author_rank: Frequent Contributor
timestamp: May 22, 2020, 12:36:29 am
content: Quote from: m12lrpv on May 21, 2020, 11:16:42 pmWell 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.

author: m12lrpv
author_rank: Regular Contributor
timestamp: May 22, 2020, 12:46:07 am
content: Quote from: brucehoult on May 22, 2020, 12:20:15 amInduction 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.

author: chriva
author_rank: Regular Contributor
timestamp: May 22, 2020, 12:58:20 am
content: 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.

author: nigelwright7557
author_rank: Frequent Contributor
timestamp: May 22, 2020, 01:46:16 am
content: Quote from: Attobos on March 05, 2020, 07:14:17 pmChoosing 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.

author: westfw
author_rank: Super Contributor
timestamp: May 22, 2020, 02:09:55 am
content: Quotethe "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...

author: PCB.Wiz
author_rank: Super Contributor
timestamp: May 22, 2020, 02:58:42 am
content: Quote from: m12lrpv on May 22, 2020, 12:46:07 amFor that, you could also look at the new TI LDC1001 5V, 16-bit Rp, 24-bit L resolution, inductance to digital converterhttps://www.ti.com/product/LDC1001

author: m12lrpv
author_rank: Regular Contributor
timestamp: May 22, 2020, 03:32:08 am
content: Quote from: PCB.Wiz on May 22, 2020, 02:58:42 amThe 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.

author: brucehoult
author_rank: Super Contributor
timestamp: May 22, 2020, 03:57:44 am
content: Quote from: m12lrpv on May 22, 2020, 12:46:07 amCouldn'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?

author: m12lrpv
author_rank: Regular Contributor
timestamp: May 22, 2020, 04:10:57 am
content: Quote from: brucehoult on May 22, 2020, 03:57:44 amNow 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: May 22, 2020, 08:28:32 am
content: 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.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: May 22, 2020, 09:12:57 am
content: Quote from: m12lrpv on May 22, 2020, 03:32:08 amTry one and see.You already know what frequency gives good change in penetration response, & frequency is easier to measure than amplitude.

author: purfield
author_rank: Regular Contributor
timestamp: May 23, 2020, 06:35:13 am
content: 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.

author: Bassman59
author_rank: Super Contributor
timestamp: May 26, 2020, 01:54:27 am
content: Quote from: nigelwright7557 on May 22, 2020, 01:46:16 amWhat 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.QuoteAnd 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.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: May 26, 2020, 02:25:06 am
content: Quote from: Bassman59 on May 26, 2020, 01:54:27 amI thinkAtmelMicrochip 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.

author: nigelwright7557
author_rank: Frequent Contributor
timestamp: May 27, 2020, 09:14:07 pm
content: 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.

author: pidcon
author_rank: Contributor
timestamp: June 28, 2020, 11:06:38 am
content: Quote from: Attobos on March 05, 2020, 07:14:17 pmMy 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.Quote from: nigelwright7557 on May 22, 2020, 01:46:16 amYes, 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.

author: garethw
author_rank: Regular Contributor
timestamp: June 28, 2020, 10:18:25 pm
content: 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.

author: Rudolph Riedel
author_rank: Regular Contributor
timestamp: July 09, 2020, 05:02:28 pm
content: 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.

author: uer166
author_rank: Super Contributor
timestamp: July 13, 2020, 05:49:15 pm
content: Quote from: Rudolph Riedel on July 09, 2020, 05:02:28 pmWhat do you mean by this? Did they cut some features from the IP or didn't provide something to it?

author: Rudolph Riedel
author_rank: Regular Contributor
timestamp: July 14, 2020, 08:27:44 am
content: Quote from: uer166 on July 13, 2020, 05:49:15 pmThey 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 IDsWith 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 IDsBut 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 H7that requires carefull planning.

author: uer166
author_rank: Super Contributor
timestamp: July 15, 2020, 07:59:55 pm
content: 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.

author: nudge
author_rank: Contributor
timestamp: September 13, 2020, 10:49:55 pm
content: Quote from: mark03 on March 07, 2020, 01:06:44 amNXP 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.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: September 14, 2020, 05:43:39 pm
content: Quote from: nudge on September 13, 2020, 10:49:55 pmI 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).

author: nigelwright7557
author_rank: Frequent Contributor
timestamp: March 28, 2021, 04:52:12 am
content: 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.

author: DavidAlfa
author_rank: Super Contributor
timestamp: March 28, 2021, 10:55:39 pm
content: 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

author: brucehoult
author_rank: Super Contributor
timestamp: March 29, 2021, 04:53:35 am
content: 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

author: DavidAlfa
author_rank: Super Contributor
timestamp: March 29, 2021, 09:12:32 am
content: 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...

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 29, 2021, 10:01:53 pm
content: Quote from: DavidAlfa on March 29, 2021, 09:12:32 amYou 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 29, 2021, 10:13:19 pm
content: Quote from: brucehoult on March 29, 2021, 04:53:35 amFor 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.

author: brucehoult
author_rank: Super Contributor
timestamp: March 30, 2021, 02:57:07 am
content: What I found interesting was how very much faster the M7 is compared to the A7 in the Pi 2.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 30, 2021, 05:25:51 pm
content: Quote from: brucehoult on March 30, 2021, 02:57:07 amThe 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.

author: brucehoult
author_rank: Super Contributor
timestamp: March 30, 2021, 11:08:35 pm
content: Quote from: SiliconWizard on March 30, 2021, 05:25:51 pmI 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 30, 2021, 11:28:34 pm
content: Quote from: brucehoult on March 30, 2021, 11:08:35 pmI'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.

author: brucehoult
author_rank: Super Contributor
timestamp: March 31, 2021, 12:29:26 am
content: Quote from: SiliconWizard on March 30, 2021, 11:28:34 pmYes, 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).QuoteWhen 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 31, 2021, 01:04:33 am
content: Quote from: brucehoult on March 31, 2021, 12:29:26 amI 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.

author: westfw
author_rank: Super Contributor
timestamp: March 31, 2021, 02:14:14 am
content: QuoteWell, I'd expect the external memory to be slower, right?

author: brucehoult
author_rank: Super Contributor
timestamp: March 31, 2021, 02:16:45 am
content: 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=275370More than five years after 64 bit Pi hardware came out, I find this ... surprising ... disappointing ... rather poor form ...

author: brucehoult
author_rank: Super Contributor
timestamp: March 31, 2021, 02:18:09 am
content: Quote from: westfw on March 31, 2021, 02:14:14 amThe 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 31, 2021, 05:16:28 pm
content: Quote from: brucehoult on March 31, 2021, 02:16:45 amI 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.

author: westfw
author_rank: Super Contributor
timestamp: March 31, 2021, 09:25:03 pm
content: QuoteWhatever. 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...

author: brucehoult
author_rank: Super Contributor
timestamp: March 31, 2021, 11:51:14 pm
content: Quote from: westfw on March 31, 2021, 09:25:03 pmIn 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 01, 2021, 12:51:38 am
content: Quote from: brucehoult on March 31, 2021, 11:51:14 pmYep, yep!

author: nctnico
author_rank: Super Contributor
timestamp: April 01, 2021, 09:25:52 am
content: Quote from: brucehoult on March 31, 2021, 11:51:14 pmThis 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!

author: brucehoult
author_rank: Super Contributor
timestamp: April 01, 2021, 08:47:06 pm
content: Quote from: nctnico on April 01, 2021, 09:25:52 amWith 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 singlesubsequent 16-bit instruction from a restricted set are deprecated, as are explicit references to the PC within thatsingle 16-bit instruction. This permits the non-deprecated forms of IT and subsequent instructions to be treated as asingle 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.