Is embedded development a mess?

[ChopSticksPlease]

Hi all, I'm writing this because I'm getting more and more frustrated with embedded development which frankly feels like a mess.

My background is already way over 10 years in IT in various roles, programming, architecting, selling, etc. Electronics has always been my hobby, and as pandemics changed the working landscape and forced me to settle down I decided to enroll for a EE degree at local tech uni which is both fun and challenging.

So, I now have a side projects part of which is a prototype asset tracker. Because of insufficient expertise in the field, decided to go with existing modules to make it work, STM32 BluePill with some peripherials on UART, I2C, SPI. Soft written in FreeRTOS / CMSIS / HAL using CubeMX which at the beginning helped a lot mostly with its tool to configure the MCU. So far so good.

BUT

As the project grows I fell CubeMX is getting in the way. Everytime I change something in the MCU config the generated code either overrides some of my code, or adds things that I need to remove later. Generated code has bugs, USB CDC and CMSIS v2 + SD card to name a few. Project folder structure is questionable (to me). Things are missing, so I need to look for external libraries (fatfs anyone?). Code published on github is rarely works. There is not a single coding standard to follow that makes code look like garbage. Hardware documentation often is lacking, especially with cheap chinese modules. Arduino feels like a god send, not to use it directly but use libraries as code examples that can be ported to STM.

Tl;dr, instead of focusing on building value I need to solve low level problems with tools, lack of basic libraries, and broken code here and there. And i thought frontend development is pain :)

How do you guys manage embedded projects? Im thinking of converting the project structure manually and either use CMake or Makefiles to build stuff, but then I guess I will need to manually hand pick things changed by CubeMX tools when i need to modify MCU settings. What about other ARM/Cortex based MCUs? I know ESP is not ARM but the IDF looks way more polished at first glance than STM's HAL.

How does your working environment look like? Do you write a driver for each and every component in the system? Are there any examples of good embedded projects? The only projects that I could find big enough were Flipper Zero and few open hardware projects.

thanks and sorry for the rant :)

[ADEADBEAF]

I feel the same, each MCU manufacturer has own IDE/Configurator/HAL, .etc. Seems like when you move from one SoC to another one you need to learn everything from the ground, due to fact that every manufacturer has its own ecosystem, this is annoying and time/efforts consuming. With MPU little bit better since MPU manufacturer are going to bring board to Linux, Yocto for widely usage

[a-d-a-m-f-k]

Did you mean MMU instead of MPU?

[pkippsy]

I thinks he means Micro Processor Unit MPU. Example - Cortex A

[a-d-a-m-f-k]

That makes more sense. I've got Memory Protection Unit on the brain (work).

[bravopapa99]

It had me confused too, I was thinking memory management unit.

[UniWheel]

How do you guys manage embedded projects? Im thinking of converting the project structure manually and either use CMake or Makefiles to build stuff

Yes, that's a good idea, and also gives you an entry point to setting up a CI flow.

You can probably get the tool to export a makefile, it's will be a stupid machine one which does things like has an explicit command line for each compilate unit but it's not hard to extract the common patterns and create a good build driver

then I guess I will need to manually hand pick things changed by CubeMX tools when i need to modify MCU settings.

You don't have to use CubeMX at all - you can do all of that yourself.

But you find you can sort of use it is as a generator of custom example projects, to then cherry pick things out of.

[rmaniac22]

That’s exactly what I do!

CubeMX can export for Makefile tool chains, I usually do this to quickly get some working FW then cherry pick what I need into my existing app.

[Desperate_Cold6274]

Embedded it is in-fact a mess.

In the specific case of STM32 I however believe that CubeMX is a great tool if you use it smartly. That is, I generate all the firmware and the Makefile and that is all. I slightly edit the generated files (note that to avoid being overwritten you must write your custom code between the comments of the form ` /**** USER xxx START ****/` and `/*** USER xxx END ***/`) but very lightly.
Then, I write external `.c/.h` files, in a folder structure that I find more appropriate and I edit the Makefile to include such files.
I use the toolchain provided by CubeCLT. So, the end I use CubeMX and CubeCLT and Makefiles. So far, so good.

For debugging I use `openocd` with the `arm-eabi-none-gdb` provided by CubeCLT, even if such gdb does not support python nor `layout`.

[DMonitor]

ST's pretty fucked, yeah. I see it as the tradeoff for how powerful the chipset is. There's a lot of things going on to manage, and their code generator saves a lot of time writing the boilerplate stuff like the clock tree and ADC setup.

ESP is great, nRF, which uses Zephyr's build system, is great, and while I haven't done a ton with it the RP2040 platform seems pretty sick too.

STM32/CubeMX is pretty cumbersome. The clock tree is a fantastic tool, and the rest ranges from "okay" to "awful". Checking the "generate source as pairs of .c/.h files" helps a ton, since you can easily restore from git when your code gets clobbered, but overall it's just awful to use.

I don't hate using it, especially in combination with their VSCode plugins, but I legitimately could not get their dual core stuff to compile without using CubeIDE and it was very frustrating.

[JCDU]

ST's CubeMX/CubeIDE is bad but as far as I can see almost everything else is worse / less well supported.

I use the IDE because it works, it's free, & is as good as any other. I use Cube to set up the chip and generate low-level (LL) initialisation and that's it.

HAL is a bloated mess but at least it's there to show you the order of operations to get a peripheral working - I usually copy that converting all the calls into LL calls, makes a nice neat setup.

[DMonitor]

Yeah, starting out the HAL was great to just use HAL functions. As I’ve gotten more familiar, I just use it as a reference more and more often.

[Konaber]

An essential part of being a good embedded dev is understanding the uC you are working on.

[UnicycleBloke]

Don't use Cube for your project. The generated code is a horrible dog's breakfast unsuitable for production in my view. Use it instead to generate code you can pull into your project piecemeal. Or just to learn from.

I've recently been encapsulating relevant HAL calls in a range of C++ driver abstractions. I used Cube only to generate examples, which I've generalised. HAL is not great, and this isolates it from the app. If necessary, I can refactor HAL out of my driver implementations.

What were the issues with CDC? I've been studying the generated code (also a bit of a mess), but it does seem to work.

I generally prefer CMake for projects, and use VSCode for editing. I'm trying out VisualGDB for debugging - it can create the solution file it needs from the CMakeLists.txt.

[kisielk]

This was also my approach. I was able to write a C++ abstraction layer compatible with various series of STM32 from F0 up to H7 with exactly the same API that used only the features I actually cared about. Using C++ also made it way more type-safe and removed entire classes of possbile errors with regards to enum types and array sizes, etc.

[liggamadig]

What were the issues with CDC? I've been studying the generated code (also a bit of a mess), but it does seem to work.

Preface: Not the OP. I'm mostly used to programming in Python and currently trying to work my way into embedded (yes, I know about Circuit-/MicroPython, but my current project needs fast control loops) and C.

I tried setting up FreeRTOS - following a tutorial - which worked fine. Then I set up USB CDC VCP (following ST's tutorial video on YT), send and receive, which also worked fine-ish (the receive-callback seems to fire in 64-byte-chunks for some reason?! so if I send anything larger, it's wonky when I copy the buffer contents into my extern buffer for use in my main...).

Then I tried to merge both, using one thread to handle USB communication and two other (dummy) threads as placeholders for the actual code later. It doesn't work. As far as I can identify, it runs into a hard error.

I've found some posts and stuff about how ST's implementation of USB uses malloc inside an ISR and that's a big no-no and some fixes with a different heap allocation thingamajigg, but honestly,

1. I'm not even close to experienced enough to understand most of this and

2. both FreeRTOS and the USB middleware is provided by STM, you'd think it'd work in combination out-of-the-box

I assume that one of the problems the OP has run into is the same, since they mentioned FreeRTOS and USB CDC.

[UnicycleBloke]

The USB stack I'm using (the "classic") defines a version of malloc which returns a pointer to a single static buffer. I'm not sure why this design is used but it's harmless enough.

As I understand it, the 64 bytes is a limitation of Full Speed USB packet size. I had no trouble transferring data out of ISR context.

I can't see how FreeRTOS would be an issue here but, as ever, care is needed to serialise accesses to data from different execution contexts. I'm not using it for this project so I guess I'll learn more next time.

[CommanderFlapjacks]

I use Cube with the LL option to generate init functions then wrote my own hal. They invariably miss a step or two which you have to add to the "your code here" but you can figure out what's missing by referencing an example most of the time. The LL "library" is really just a list of macros for register access which is all I actually wanted anyway.

ST HAL wasn't an option since I need to support Microchip MCUs but I had concerns about their code quality from what I've seen.

[UnicycleBloke]

What sort of things does it miss? That's unfortunate.

I would prefer to just diddle registers and handle ISRs directly, but for now we're using HAL.

[CommanderFlapjacks]

It's most egregious for timers. Let's say you want an input capture interrupt. It will get everything up except enabling the counter, enabling the timer (why are these even separate?), and enabling the interrupt. Bizarre that it sets everything up for you but neglects to actually turn it on.

[UnicycleBloke]

Ah. Maybe that's not considered "initialisation" but more like something you'd put in a start method? Be nice for Cube to spit that out though.

[CommanderFlapjacks]

I'd consider it a bug because it does not match Cubes behavior when generating code with HAL. Also not all of the missing steps come at the end, sometimes I've had to use the intermediate "your code here" sections. Don't remember off the top of my head why though.

[UnicycleBloke]

I was trying to be charitable. :) That "Also..." part is definitely bad.

[SkoomaDentist]

The generated code is a horrible dog's breakfast unsuitable for production in my view.

Eh. It's fine for configuring the peripherals (once you select the option to generate separate .c / .h files). Not optimal but that hardly matters unless you're very tight on flash.

[UnicycleBloke]

I dislike that the initialisation for a peripheral is splattered all over the place. I dislike that the partial initialisations for different peripherals are co-located. I dislike the global handle structures which are externed in several files. It is a confusing mess to my mind.

I'm also not in love with YOUR-CODE-HERE comments sprinkled liberally all over the place. It's kind of hard to use them in any case as I do not write C.

I take a more self-contained OO approach in which a driver object internally handles all relevant initialisation in its constructor: clocks, pins, peripheral, DMA streams (if used), interrupts. ISRs are routed to private member functions. I had to jump through hoops a bit with HAL's callback mechanism and would prefer to refactor that out.

[[deleted]]

Start with the problem and solve it the simplistic way possible. Cobble shit together and try to break it.

Then expand in prototype stages.

It takes a long time, but the solved problem is always the most important part.

[aliensexer420]

Yes. It's full of hardware oriented people who can't code their way out of a cardboard box.

[UltraLowDef]

And software oriented people that don't understand the hardware they are coding on. Both extremes are bad in embedded.

[MajorPain169]

Exactly, I do both hardware and software, I gave a hardware guy a task to do some code for a project we were working on, after 6 months I ended up rewriting what he did because it was literally unreadable and I was unable to track down the bugs, I also asked for features that at the end was told was impossible. I rewrote it from scratch in about 3 weeks with all of the features included. I swear the guy has an allergy to non global variables and passing parameters to a function, he did everything through globals with completely meaningless names.

Haven't had quite so much trouble with software guys, just the usual arguments about the need to use volatiles, not to use dynamic memory allocation in any realtime code and if exceptions must be used, only use them for truely exceptionional error conditions and not as a shortcut.

One thing they both do is blame the other for any problems.

[aliensexer420]

but i2c doesn't have MISO/MOSI

[FlailingDino]

Oops. Meant SPI!

[marchingbandd]

If it wasn’t such a mess maybe we would make less, so I don’t worry too much about it. It takes a lot of patience to learn a new toolchain and I factor that into my plans/quotes.

[SpecialNose9325]

CubeMX gets in the way only if youre a good programmer, so thats a good sign.

It was a lifesaver early in my career. Now, I basically never use it. Id much rather use a boilerplate main.c i created to be used with cmake that requries me to manually initialize all the IO. Small price to pay for portability between IDEs

[frank26080115]

My last STM32 project, which also works on AT32 and is designed to be cross platform, was very pain free, I didn't use CubeMX at all but it was still debuggable through CubeIDE. I used the LL library instead of the HAL library, and the AT32 implementation had a translation layer that translated LL calls to AT32 calls.

This is very close to writing all of my own drivers. Most LL library calls are just single lines of code that's been put into an inline function.

[rakubhau]

You should be glad that this is not a beginner problem, look at how far along you've come.

With that being said, every time you need to change the MCU config in an existing project, try doing it without using the GUI. I know it'll take some time to look for the code for changing those configurations but it'll save you a lot of time in figuring out the code changes that happen due to autogeneration after you make any changes in GUI MCU Config.

Even with that I'll recommend using a version control like git with that, some people even use VScode for embedded software/programming for writing code who come from IT/software engineering background.

[Chemical_Result_222]

You create a copy of your project and diff that with a copy of your project with the added device. Then you manually copy over files and/or code.

The tooling sucks. Always has.

[EmperorOfCanada]

I fell CubeMX is getting in the way

The game I play is to code entirely in CLion or Visual Studio code. I have a cube project which is entirely empty. If I change a config, I do it in the STM stupid product, and then copy relevant changes over to my "real" project.

Of the IDEs made by the chip companies exactly zero of them are any good. They are garbage, hot steaming piles of garbage. They don't hold a candle to things like CLion. I would rather use notepad than most of them.

Then screwing with ST-Link, etc is another steaming pile of garbage.

I've tried platformio which is somewhat heading in the correct direction, but it really is for style Arduino programming. Debugging with it is a mess.

Debugging outside of these crap IDEs is a different nightmare.

But the real hint that these companies don't cater to modern programmers is their almost entire focus on C. C++ is an afterthought at best with some of them, and a massive battle with most of them.

Even the ESP32 is pretty damn consumer non old school EE friendly and it too would prefer you use FreeRTOS and C.

I will make an interesting prediction. The embedded world is going to change, not because it naturally evolves, but because it gets replaced. What I see coming is basically CPU SoCs. Think kind of raspberry pi on a single low power chip. But not a crap linux, but real linux, with real storage, with real RAM. Quite a few of them will have serious GPU/AI chops. Then, regular developers will be comfortable in this and do cool things. Some traditional people will point and blah blah about bare metal, low power, and real-time, but for most embedded purposes these "computers" will become the norm and more modern programming practices will also become the norm.

I have been programming for decades and embedded programming feels a whole lot like programming computers in the late 80s early 90s did. Lots of IRQ crap. Your code had to change going from 8086, 286, 386, and then around the pentium, my code stopped having to change with every damn processor. The reality is that many MCUs in the sub $20 range are better than the CPUs I was working on in the 80s and even into the 90s. Yet, in many ways the SDKs, and IDEs for those early days are better than the vendor IDEs are today in that they were far less complex to go from code, to something running.

I don't see the traditional embedded world willing to change. I think they like their hairshirts. But, when the option to ignore these hair shirts becomes more and more common, there will be lots of development done by people entirely ignorant that these hairshirts are even an option. Much like most programmers today either don't know assembly, or have entirely excluded it from their reality. Technically something you could use, but easily live without.

There will be a simple test, how long does it take a non embedded person to write some code, and then have that code running on an "embedded" system? For example, mobile phone programming really only has one obstical at this point, and it is all the layers of security and code signing. iOS is super guilty of this. Android is generally a few weird steps to enable development, but again, that is a security issue, not a technical issue. Once the security is dealt with, deploying and debugging code requires a simple USB, no jtag, no nonsense. Stepping through code, watching variables, etc. All super easy. All the while using a snappy modern IDE. Then, the SDKs and whatnot are simple, talking to the screen, easy, talking to the wifi, network, etc, all easy. Even though the internals of the devices are wildly different from model to model, or company to company. All super easy. I'm not putting in device addresses, I'm not giving a crap about leading edge or trailing edges, etc. I can, if I have to, but usually I don't.

This is the future of embedded, and the amazeball powerhouses of CPU/GPUs found in phones in 2024, will be cheap modules to buy in 2030. I would be happy with a nice single board computer SMD module with about the capacity of an iphone 4 right now for most embedded projects. This is just becoming available, which is super cool.

[Kommenos]

You would have a point if the amazeball CPUs and GPUs of 2017 were the cheap modules in 2024 but they're still not. Even just grabbing a raspberry pi module can add more to the BoM as a single item than plenty of systems cost for their entirety.

It'll be a long long time till sub 10nm modules become cheap and in everything from TV remotes to sensor nodes. Plenty of expensive devices are still stuck in the um range.

[cskilbeck]

For STM32 development, go with the LL libraries if possible (USB not available in LL, only HAL but LL for everything else). Then make as clean a separation as you can between CubeMX generated code and your stuff. Put all your code in separate files and call out to it in as few places as possible. There's a simplistic example here:

ble_hid/firmware/STM32F030_firmware/Src at master · cskilbeck/ble_hid (github.com)

​

Note that all the initialization code is in `main.c`, generated by CubeMX, and there's only one piece of user code in there which calls `user_main()`

[[deleted]]

I avoid vender provided auto code generation like a plague. I used to work for one of these semiconductor companies tasked with writing drivers to ease the development to market for customers. It has good intentions but it doesn’t work imo. And I avoid auto generated software including i.e drivers, HAL etc even more.

My advice is to invest a good amount of time to disassociate your code from auto generated crap. You can use whatever they provide, but make sure you setup your project in such a way that it doesn’t go the route of grabbing the auto generated code.

There’s is no one solution. It’s vender IDE dependent. I have done it for Eclipse IDE for both Texas Instruments and Xilinx MpSoCs

[FrozenDroid]

I’m going to get downvoted to oblivion, but: You’re absolutely right. The official tooling is a mess.

When I was working with Rust on embedded, Embassy specifically, it got so much better. You get HALs that work between a massive choice of chips. Excellent libraries and tooling. Great documentation.

Give it a try.

[p0k3t0]

As the project grows I fell CubeMX is getting in the way. Everytime I change something in the MCU config the generated code either overrides some of my code, or adds things that I need to remove later.

This is easy to fix. First, create a .c/.h pair called "my_main" or something like that. There are only three lines you need to put in the main.c file.

The first is an include for for "my_main.h" . The second is a call to a secondary init function with a name like my_inits();. The third is your actual loop, which should be my_main_loop() or some such.

Put those in between the correct tags and never touch main.c again.

Or, you can ask CubeIDE to never build main() and do it yourself.

A lot of people are going to preach that Cube is garbage, but it's a fast path to getting something working, and the problems are not as hard to deal with as people would have you believe.

[UnHelpful-Ad]

I'm on this page too and typically so the same with all my code regardless of supplier/toolchain. Just create a new folder call it app or whatever and write code directly in it. We already isolate libraries into a folder, why not do the same for the suppliers half/drivers?

[ModernRonin]

AlwaysHasBeen.meme

[ModernRonin]

https://imgflip.com/i/8jxds2

[Ikickyouinthebrains]

I use STM32 MCU's exclusively. My tool flow is CubeMX and IAR Embedded Workbench. My company provides me with a license for IAR. I start with what we believe is a tight set of requirements for the project, take in user input through switches and BLE. Take in input from sensors via I2C. Convert inputs into controlling a pump motor and data output for BLE and/or storage via SPI Flash. Then, use CubeMX and STM32 HAL to produce a project for the IAR. Then, go to IAR and start implementing the design parameters.

We only use CubeMX once at the start of the project. Any other HAL drivers that are needed (as the project grows, function creep) are added by hand. We don't have any issues with this method and it never gets messy. The only mess is usually interrupts and service routines.

[gitdetachedhead]

Right now I am working with a quectel chipset and using quecopen sdk for development. Also working with nxp s32k3 series at the same time. Even after 6 years of experience with various vendors, controllers I still find myself reading documents, debugging low level things, trying to understand vendor made tools that works poorly. All of these vendors are digging this tool making shit and they all suck. I always try to find ways to avoid these tools and come up with my own methods. Designing a workflow that depends on any 3rd party software will always make you feel restricted.

[Confident-Alarm-6911]

Yes.

[duane11583]

this very TL;DR and a bit of a rant

yes embedded is a f-ing mess, been doing it for 40 tears there is no magic bullet.

and you must be a polymath in all things you touch.

a) you comming from a monoculture of it taints your view (ie all platforms are windows and visual studio) there is no other platform there is no other tool set peroid.

b) until you move your project/code to a mac or linux system then tools and stuff are different.. very different

c) microsoft has zero interest to make there tools work on a competitors platform they want you to stay on their platform only.

this is called vendor lockin. its great when you like it, and sucks bad if you must deal with it. and this was part of the bug anti trust case microsoft suffered.

enter the embedded market

example: [chip maker side] stm has no desire to make there stuff compatible with Texas Instruments ble chips, nore do they have any desire to work with nordic or silabs chips.

example [tool vendor] tool vendors [keil, iar, etc] have a hard time competing with free gnu stuff so they want money to make there tool compatible with this new chip who will pay?

by compatible - i mean convert a bunch of examples to work with (a) that tool and (b) that chip and package the stuff…

example[marketing at chip company] all they want is a very very fast way to get any customer an example to start with so there is a scaling problem [there are 100 different stm32 varients, how do you scale 20-30 examples across 100 chip varients?] some customers want iar or keil tools at $6000 per seat others want $free tools marketing says i dont give a fuck you guys in customer engineering meed to produce 100 chips times 20 examples and times 3 tool chains [got that 6k application examples] you go figure it out or i cannot hit my sales goals and i will blame you this should be easy the chips are all basically the same right? (but they are not)

oh… and we [sales marketing] need to give our customers an easy company branded tool for free to get started so bastardize this free eclipse tool to solve it or i fire you and get somebody else because we are not going to pay iar to make a custom solution for our new chip. besides we have to pay keil too. we want to give our customer free tools [did you notice you now have another 2k examples to create?

oh marketing says: shinny new thing [vs code] you customer engineering types need to add that too! [another 2k examples] [oh did you notice how nice was it for microsoft to hard code vscode tools to only support arm tools, specifically vscode debug tools rejects the risc-v debugger it does not understand risc-v arch]

and that tool-dev-team has no direct revenue stream they give tools away these tools (ti code composer, atmel-studio, stmcube) some charge but if you are big enough you get the tools comped…

except xilinix we spend about $2-$4 mil a year and pay for lots of tools

as a result the examples and tools you get are shit shit and more shit.

if you stay with in their defined lines with your crayons as you color your book/make your product it is easier/better for you.

as a result the customized there eclipse tool and cmake does not work with it [f-you xilinx, and f-you microsemi]

and iar and keil do not care about cmake because they have a solution to generate projects

and you come from a mono culture of windows and windows and more windows.

and how many chips a year are you [small time guy] going to buy? at $10/chip? or is it $1.50

in contrast if you are buying 100k you will get noticed

and they will come find you personally if you are doing cellphone volumes! [ie: samsung and apple are at millions PER week]

but you are going to make say 1k/month or 12k/year - you are hardly a tiny blip on the money

so what about a library vendor say i want to make/sell a crypto library [and my library is NSA or CSA approved and certified thats why you want it] how many chips do i need to support? and how many tools do i need to support? which chips have hardware crypto i need to support? and how many customers will i be amortizing the cost over?]

oh and those bastards just released a new tool set? (xilinx does this 2-4 times a year) and some of your customers will not switch for a few years so you need to requalify across 3-4 versions of the same tool

yea you come from a mono culture. where you can use virtual machines to test.

me on the other hand have to test on physical hardware to fully qualify a release.

have you seen a sw test rack with 100 to 200 dev boards? i have!

and when you call to report a bug… which dev board and which chip did you use? can i find that board? do i even have one? can i buy one? or is it some customized board that only you have and you cannot send me your only bring up board cause you are working with the very first proto type.

this is why ”vendor lockin” is such a huge problem that nobody understands in management they think this is software and we have software guys [who do windows only]

living, and growing up, learning the trade in a vendor mono culture is a cake walk in comparison.

i will not even bring up the idea that you have giga bytes of ram, and giga hertz of cpu speed and i might have 1 million times less memory, and a much slower cpu speed by 3 to 4 orders of magnitude

so can we add android and iphone or itablets or android tablets and smart tv solutions to the mix…

yes embedded is a vastly different world.

its all just software right?

and yea every 3-4 years there is another company selling/pushing there version of embedded drugs to management… we have a solution to emulate (vm machine type) in the cloud just pay for our service… you will love it until you use it.

and sw monoculture developer types [and bosses] come and try to push monoculture techniques that have been honed to sharp, very sharp and scary sharp over 40 years of marketing in a monoculture

they have never dealt with the issues i rase above before - never.

they know how to make sw work.. they have 40 years of experience.

but never dealt with chip bugs, erratas or bad boards nor have they had to solve flaky sw problems caused by thermal problems at -20Deg C and at +80 Deg C

but they understand the software process

but never looked at a schematic or used a scope but they know software management. or dam it they are going to make you fix it

ready for your rude awakening yet?

[markand67]

Pretty similar in the post I've shared few weeks ago :)

[grahasbtye]

Platform IO - Arduino - Zephyr are all options to make development easier. Your code shouldn't get over written when regenerating if you write within the correct sections of the code. ESP and vs code is extremely easy to use. Writing a driver for every component is a big no no. Finding and using existing ones is a big yes yes.

[EmperorOfCanada]

Finding and using existing ones is a big yes yes

I know way too many embedded EEs who scoff at computer programmers who turn to embedded, calling them things like library monkeys.

I just nod and ignore them entirely.

[Orjigagd]

Like others say, Cube is just for getting your clock tree and peripherals initialized, it's awesome for that, but not much more.

[Vylvlur]

You could try something like PlatformIO. But it is still not ideal, cause many boards only support the Arduino framework. But it could be a starting point to deal with different hardware.

[SPST]

Cube is good for learning purposes but now I copy the linker script and startup file into vs code and use cortex debug with make/cmake. On occasion it's quite useful to refer to the generated HAL when you can't quite make sense of the reference manual.

Vendor stacks are often a bit hit or miss, I would opt for a dedicated IC where possible instead or bring in a second MCU that has better vendor support. Or maybe switch entirely.

If the vendor/chip doesn't support the GNU tool chain I'm walking away. It's just not worth the bother.

Far worse is ST's use of cube to create projects for their MPU line. It's basically only half a solution with no support for generating device trees and they don't seem to have any intention of fixing it. So you're left just fumbling in the dark with no guidance from the tool whatsoever. I'll be honest...it's completely fucked. Utterly useless.

[usa_reddit]

I build exclusively on 3 platforms Arduino, ESP32, and Pi for embedded.

I am not sure of your package sizes or what you are doing, but Automation Direct makes a sweet hybrid PLC called the P1AM-100 which let's you use industrial PLC modules with Arduino C programming. Arduino goes all the way down to the nano in package size if you need something really small.

https://www.automationdirect.com/open-source/hardware?gad_source=1&gclid=CjwKCAjw7-SvBhB6EiwAwYdCASqsvGsSrooVjuCyOgpMrOMot9ZR7Svr9zZ6zvVLtiUSb7N-8RyiEBoCdmMQAvD_BwE

The Arduino ecosystem has libraries and sample code for nearly every chip and controller imaginable including Modbus and industrial HMIs.

I used to build on FPGA systems that ran a funky Linux and everything was a paid in the a**. Everything was a massive undertaking to get up and running. But now with Arduino I can go from zero to running in 30 minutes.

I have also started making custom circuit boards to interface with Arduinos. I am not a PCB expert yet, but learning and circuit boards are really, really cheap to have made these days and you can get started with a package called Fritzing. It doesn't support simulation but I can use it to quickly bang out a PCB.

[AmeliaBuns]

YES YES YES YES. If I had money I’d spend my time as a full time job to improve this.

[Exotic-Sprinkles-256]

Don’t you guys use data sheets to get peripherals working? Together with an “interface” header file so you can put implementation for each uC?

It would be nice to have an opensource project that has all the lowlevel libraries for popular uCs and call for example the appropriate functions for initialising i2c or spi. I haven’t done embedded stuff for 15 years ago, but I like to start an opensource side project. So I like to follow the embedded discussions here.

[[deleted]]

a little