The state of embedded development in 2021 - Page 1
Forum section: electronics / general

author: galvanix
author_rank: Contributor
timestamp: March 24, 2021, 07:42:01 am
content: Hi,I've wanted to get back into some embedded projects and I think it's time to embrace the ARM dominance of the market.I've mainly used 8-bit micros (AVR, PIC) a couple of years ago and the simplicity can't be beat for most things IMHO.I'm also a fan of using free software toolchains like gcc so ARM theoretically seems like a great fit.In recent years I've been playing around with some higher level programming languages like Rust and Nim and some of the language features are really nice. The tooling support (at least for Rust) is also pretty great.I have a bit of experience working with STM32s from a couple of years ago and I'm shocked that basically nothing changed until now. The HAL is craptastic and bloated (many threads on this forum about it) and everybody seems to roll their own which just sounds very inefficient to me; reinventing the same UART/SPI/I2C drivers over and over and over again.People don't go around rewriting their TCP/IP stacks all the time either (except maybe the ones who propagate the "rewrite everything in Rust" meme).What is the way forward for someone who is looking to pick up ARM Cortex-M development in 2021? ChibiOS? FreeRTOS?

author: alexanderbrevig
author_rank: Frequent Contributor
timestamp: March 24, 2021, 09:50:43 am
content: I want to propagate the "(re)write everything in Rust" meme:https://github.com/rust-embedded/cortex-m-quickstartChibiOS > FreeRTOS IMHO. Also ChibiOS/HAL works great, though their naming scheme feels a bit off to me but I always get used to it.

author: galvanix
author_rank: Contributor
timestamp: March 24, 2021, 10:03:32 am
content: Quote from: alexanderbrevig on March 24, 2021, 09:50:43 amFair enoughDo you have any experience using it in something that's not a toy or simple hello world project?

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 24, 2021, 04:09:41 pm
content: Do you realize that the topic of this thread is very close to "what's the best programming language in 2021?" and is likely to get you the same kind of answers?

author: galvanix
author_rank: Contributor
timestamp: March 24, 2021, 04:57:03 pm
content: Quote from: SiliconWizard on March 24, 2021, 04:09:41 pmThat's a good point that I hadn't considered before. I didn't set out to start yet another flame war of what's the best programming language or framework.I was asking for experiences regarding the stuff that's commonly used on STM32s and other ARM Cortex-Ms in order to circumvent the less-than-stellar vendor HALs, something along the lines of "yeah these days everyone is using X, even though it has some pitfalls it's the best we have right now".Maybe it's just ST with the notoriously annoying libs and the NXP offerings are much better, idk, that's why I asked.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 24, 2021, 05:19:38 pm
content: Quote from: galvanix on March 24, 2021, 04:57:03 pmI'm sure you weren't, but I was just anticipating what would likely be coming.Quote from: galvanix on March 24, 2021, 04:57:03 pmNow that question is a bit more focused, and I think you will get relevant answers. Alternatives to the HAL for STM32, for instance, are frequently discussed on this forum. There is a whole range of options, from programming them bare metal to using RTOSes, with things in between. You may want to take a look at libopencm3 for instance:https://libopencm3.org/(it was originally written to support Cortex-M3 MCUs, but it also supports M0 and M4 now.)Regarding NXP vs. STM32, I don't know what to think quite yet. I have recently started evaluating the iMXRT1062, for now using the NXP SDK. I'm not sure I can say this SDK is hugely better than STM32's HAL. As for the docs, NXP docs tend to be even more obscure than STM32 ones IMHO, but YMMV.But all in all, there is just no single approach. It all depends on your requirements, your skills, whether you work in a team or alone, the kind of project you use them for, and so on. So trying to get a single definitive answer will inevitably lead to the "best language" syndrome. Hopefully you'll get a handful of options in here, and you'll get to pick whichever feels more adequate and more comfortable to you.

author: NorthGuy
author_rank: Super Contributor
timestamp: March 24, 2021, 05:56:15 pm
content: Quote from: galvanix on March 24, 2021, 07:42:01 amIn any more or less big project, the UART/SPI/I2C "drivers" is such a small part compared to everything else that it doesn't really matterhow you do thisif you spend some short time doing it the way you like.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 24, 2021, 06:04:34 pm
content: Quote from: NorthGuy on March 24, 2021, 05:56:15 pmAgreed. There is some obsession for cross-platforming everything possible, and in the end it often costs more than it saves. Yes, even for non-embedded software, but that's a whole topic in itself, and would be off-topic here. Point is, in many situations, as you said, the platform-specific code is relatively small and simple compared to the rest of the code, and when it's not, then it might mean your design is a mess.

author: Siwastaja
author_rank: Super Contributor
timestamp: March 24, 2021, 06:12:19 pm
content: I don't understand what it means to "reinvent UART/SPI/I2C drivers".These simple interfaces can be easily used directly in the application, "driver" at most being maybe a helpfully named macro or a 5-line helper function; these may or may not follow along from project to another. In any case, these take tiny fraction of the development time.The reason it works this way is:* The simplest cases (for example, just initialize UART for a certain baudrate, then send bytes in a loop or give a buffer address for DMA and let it work freely, give an interrupt on received byte) that youcouldwrite a generic driver interface for, also are so simple to implement ad-hoc that such generic interface is not needed. This is the trivial case; it's not utterly important whether you use libraries or not, but in general, I recommend avoiding unnecessary complications.* The difficult cases (where you utilize the more advanced features of said peripherals, so that they intervene in twisted ways with your complete application including other peripherals) are always hardware specific and coming up with aninterfaceto catch all difficult use cases and HW features is basically impossible, or only makes thingsmore difficult, so youdon't wantto add layers. This is where projects completely crash when people try to force the libraries which simply can't do the job. If they don't have the skills (or guts) to Do The Right Thing, they are stuck, and the project just dies.So, basically no to extra layers. Only do work which can be proved beneficial and not hindrance.Sure, it will be hardware dependent and migrating to another microcontroller requires some work, but in case of SPI or UART that would be something between zero to a few hours max (unless you hit a case where the original peripheral implemented some really important special HW feature youneeded; in this case, no amount of layers or interfaces will fix the problem, quite the opposite, they willhideit), even in a large project. This is nothing compared to the tedious work of hardware redesign.How ST solved this problem, for example? They created abstraction layers that abstract absolutely nothing. But now management people requiring these layers are happy. Almost all peripheral features are accessible because the layers do not abstract anything, it's just syntactic and semantic mapping interns write the in a rush with some errors.Free tip of the day: open the documentation. Write in C, bare metal, using just the headers defining register names etc. The same old way it worked in PIC or AVR, since 1990's. It still works, and it still workswell. You can do anything, use the part to the fullest, with least amount of code, which is easy to follow and modify later.GNU toolchain is great, and the interface has been the same for decades. Don't add extra layers to it, just use the GNU tools, namely compiler, linker, binutils. make is good for automation.

author: JOEBOBSICLE
author_rank: Regular Contributor
timestamp: March 24, 2021, 06:22:37 pm
content: ST have done their best job at making something abstract.Sure it's a bit runtime configuration focussed instead of compile time but the parts have oodles of flash. If you have an issue it's easy to rip out that code and make it however you like.It's not like it's difficult to look at the map files

author: alexanderbrevig
author_rank: Frequent Contributor
timestamp: March 24, 2021, 07:32:37 pm
content: Quote from: galvanix on March 24, 2021, 10:03:32 amNo, not really. I would not use Rust for my next project - not for a while I think.https://github.com/rust-embedded/not-yet-awesome-embedded-rust

author: ajb
author_rank: Super Contributor
timestamp: March 24, 2021, 10:17:13 pm
content: Quote from: JOEBOBSICLE on March 24, 2021, 06:22:37 pmIt's not so much the fact that the high level libraries use a bit of extra flash that's the problem (although there are some egregious cases, like using USB CDC via Atmel's ASF on their SAM-D parts consumes something like 14kB of flash, on parts that have as little as 16kB! Whereas forum member ataradov has a USB CDC application that's IIRC ~2kB and no less useable). There are some performance penalties in execution time due to the level of abstraction, but in general the bigger problem is that in order to expose all use cases of a given peripheral while hiding the hardware complexity away there is so much software complexity that the libraries are virtually guaranteed to have errors in some use cases, and when they do fail it's tremendously painful and time consuming to debug them. And despite how comprehensive and abstract they attempt to be, they almost always miss use cases, or still require a level of familiarity with the peripheral that can only be obtained from the reference manual anyway.So they're inefficient, untrustworthy, difficult to support, and in the end don't even help that much! Plus the code generators that are practically required to set them up hide a lot of detail that you generally want to at least be aware of anyway, like shared clock sources or limitations in DMA channel assignments, etc etc.So in general I agree with Siwastaja and SiliconWizard that basic peripherals like UART, SPI, timers, etc are generally just plain easier to write your own drivers for. The code you write on top of those drivers (like for communication protocols or whatever) can be just as effectively decoupled from the hardware via your own drivers as via ST or whoever's drivers while still allowing you to ensure that the drivers reliably do whatever your application requires of them.The comparison to TCP/IP stacks is really a completely different game, because that whole set of protocols has a ton of complexityabovethe wire level. LWIP requires, what, like four hardware-specific functions? An Ethernet MAC is inherently a more complex peripheral than a UART, but it's still not THAT hard compared to the rest of the IP protocol stack.

author: westfw
author_rank: Super Contributor
timestamp: March 25, 2021, 04:31:05 am
content: QuoteWhile TCP stacks are a great example of "firmware" that you probably don't want to write yourself, I'd like to point out that that back when the world was open you couldn't got to an embedded computing trade show without finding half-a-dozen would-be software vendors that were offering JUST some network stack, somehow better than all the other networking stacks...And a vendor-specific networking stack, or RTOS, or whatever, is probably something that should be avoided. They tend to come with license restrictions "only use on our chips!" that throws portability out of the window :-( What you DO want is some clear and well-written lower level drivers that allow the other "standard" stacks/etc to interoperate with the hardware. (LWIP is certainly one of them. Maybe LUFA or tinyUSB for USB (runs (approximately) on both Atmel AVR and NXP ARM chips.)

author: tmadness
author_rank: Regular Contributor
timestamp: March 25, 2021, 05:12:53 am
content: I swear I am not a teensy shill. But teensy is what attracts me to NXP, paul and the people who work on teensy's HAL are amazing. The libraries tend to be simple, well documented (always check the forum for a question) and pretty well written. Moving from away from ST was refreshing. And the 600 MHz RT1062 support is the cherry on top.

author: galvanix
author_rank: Contributor
timestamp: March 25, 2021, 07:42:29 am
content: Thanks everyone for the thorough and thought out replies!To recap:- There's no silver bullet- Don't make things more complicated than they need to be- Register level programming is still king- make + gcc + binutils = <3- Avoid vendor specific middleware like TCP stacks to prevent vendor lock-in- Teensy may be worth considering

author: tmadness
author_rank: Regular Contributor
timestamp: March 25, 2021, 06:48:03 pm
content: The single bullet thing is absolutely true, but a lot of use cases, at least in my world of computation heavy no serious power constraints, are now well served by really powerful general purpose MCUs and their tools. I remember using a blackfin for a while and it was a PITA, there was little general purpose capability both in hardware and usage.I was testing a colleague's new prototype and computation+spi task that took 500 us - 1 ms were working at < 1us times on the NXP IMX RT1062 (teensy 4.0), all this while being easy to port (the previous code came from a gcc compiled MCU from the mid-late 2000s) and extend functionality. Hell the latest ARM GCC version (i think it was 10.x) dropped the size of some of my code to 60% of original.Its a good time to develop on and deploy MCUs: ton of development effort from both the community and manufacturers, relatively standard tools, debugging is actually useful and getting pretty powerful, CHEAP-REALLY CHEAP MCUs, etc.I see the field head in the general direction of more flash + more ram, for me, this is beautiful. NXP MCU I was talking about comes with upto 1024K RAM! Holy bananas! all the while being capable of bare metal real time operations.Oh, and USB peripherals in most MCUs suddenly started working pretty pain free. most MCUs now come with pretty decent USB hardware, are easy to deploy and have good USB stacks. Hell even the bemoaned ST HAL has pretty usable USB CDC.And there are so many other small things that make a quality of life improvements,there is a lot of vendor diversity, a lot of good tools supporting every type of development style, simpler input voltage/power requirements, clocks that are pretty configurable, some MCUs have "custom perepherals" with state machines etc.And I did not even bring in Zynq...

author: westfw
author_rank: Super Contributor
timestamp: March 26, 2021, 11:20:00 am
content: One of current trends is that cpus are faster, have more memory, and are cheaper. So people are throwing “horribly slow and bloated languages” like Python at them, and they’re almost powerful enough that that works pretty well for a lot of the actual use cases. And 60% of the time you used to spend writing clever code is now spent searching for the best libraries that have already been written, and oft times they ARE out there...It’s not what I signed up for, or even what I like to do, but it might be the best way to solve many problems...

author: ucanel
author_rank: Regular Contributor
timestamp: March 26, 2021, 04:39:34 pm
content: I am using CubeMx and Keil,i do not have any problems with it.I have programmed pic12 to DsPic30F with assemblerwrote sd Fat libs, bootloaders, etc.I do not think enviroments or tools are the problem,even talking about what is best is meaningless.Try it, if it fits you wear it,if it does not fit loose some weight, make it fit.

author: Kerlin
author_rank: Regular Contributor
timestamp: March 27, 2021, 11:28:47 pm
content: Quote from: tmadness on March 25, 2021, 05:12:53 amYes agree, that's why I am looking at it.Can you help with one possible issue I have with Teensy ? It is only mentioned in the Teensy forums and I cant find much on it with web searches.Is there some kind of license chip on the board ? Seems its connected to the rest pin.Looks like the boot loader is in it, in some cases the programmed chip can be bought separately.It concerns me (always a worrier) that it may make it hard to develop a project and then make a custom board?

author: DC1MC
author_rank: Super Contributor
timestamp: March 28, 2021, 08:14:06 am
content: Quote from: Kerlin on March 27, 2021, 11:28:47 pmA license chip, this is new, could you point it on the schematic:https://www.pjrc.com/teensy/schematic41.pngCheers,DC1MC

author: Kerlin
author_rank: Regular Contributor
timestamp: March 28, 2021, 09:15:05 am
content: Woah Woah, reading comprehension required.I did not say there is a license chip so why ask where it is.I said - It is mentioned in the Teensy forums and I cant find much on it with web searches.I was reading this and did then did further searches.https://forum.pjrc.com/threads/25875-Teensy-3-1-based-custom-designhttps://forum.pjrc.com/threads/66715-Can-t-connect-customized-Teensy4-1-board-with-PC?highlight=bootloader+chipIn those further web searches I did find some mentions of a mysterious license chip.Think they were misinformed and were talking about the boot loader chip so I was inquiring if anyone had heard of this as I couldn't find any clear information on it.If it is in fact the dedicated boot loader chip, then my question is, would it cause me any problems if I want to produce a custom board ?The Teensy website shows you can buy it separately, is it essential on a custom board?

author: westfw
author_rank: Super Contributor
timestamp: March 28, 2021, 10:09:07 am
content: You should not need the proprietary bootloader chip if you make a custom board that loads software via some other mechanism (jtag, swd, or some other bootloader.)The neat thing about the pjrc bootloader is that it takes up zero space on the main cpu.

author: tmadness
author_rank: Regular Contributor
timestamp: March 28, 2021, 05:06:19 pm
content: Yup that's right if you want your pcb to behave like a teensy for programming, then yes you need PJRC's pre loaded bootloader. I've put MK66, ie teensy 3.6 chips in the wild without any bootloader chip and just swd programming.Also in case you want the bootloader chip for the imx rt1060:https://www.pjrc.com/store/ic_mkl02_t4.htmlThey have some good info on the power requirements of the RT chip on the page as well.

author: nctnico
author_rank: Super Contributor
timestamp: March 28, 2021, 05:21:46 pm
content: Quote from: Siwastaja on March 24, 2021, 06:12:19 pmI hear you but... software engineers don't know about hardware so a library which abstracts it, is just convenient for such people. Secondly, in ST's case having hardware abstraction library is almost mandatory because every different type of microcontroller from them seems to have entirely different peripherals. It is a huge mess.OTOH if you already have a reasonable library then it usually isn't much work to port it. The UART & I2C drivers I'm using where initially developed on an 8051 microcontroller and got ported to a boatload of different microcontrollers over the decades.

author: DavidAlfa
author_rank: Super Contributor
timestamp: March 28, 2021, 07:05:13 pm
content: ST libraries are not like arduino, ex "serial.begin". That's easy when you have very specific hardware to support.With ST you still need to know the hardware. But it makes life much easier, instead having to read the whole manual when you want to change a little thing.STM32 is a bit obscure world, you will need to practice a lot.Must say, I'd be much happier with microchip.

author: Kerlin
author_rank: Regular Contributor
timestamp: March 28, 2021, 10:15:23 pm
content: Quote from: tmadness on March 28, 2021, 05:06:19 pmThanks heaps for that, yes I do understand that a boot loader is not needed and the chip can be programmed other ways.But I think that its not impossible to set it up so it is required, so was hoping to hear from some one who has done it.In reality I would just buy the Teensy board as it is readily available if a replacement is required and I could not make it cheaper.Just fit it to my custom board.Was just looking to make 100% sure as I would not like to be stuck with it as a must have.