The problem with microcontroller development...

[westfw]

I haven't kept track, but there are at least two copies of Eclipse in there.  (and no plain Eclipse install, nor any x86-target IDEs. (and several IDEs are out of date.))


Oh sure, you could set up VS Code or plain Eclipse to do everything, or use EMACS and CLI tools, but that can be pretty painful, ndthen if you try to share code you'd get complaints about your non-standard environment...

[Karel]

(Attachment Link)
I haven't kept track, but there are at least two copies of Eclipse in there.  (and no plain Eclipse install, nor any x86-target IDEs. (and several IDEs are out of date.))


Oh sure, you could set up VS Code or plain Eclipse to do everything, or use EMACS and CLI tools, but that can be pretty painful, ndthen if you try to share code you'd get complaints about your non-standard environment...

Who cares?

I use gcc & make & openocd for stm32 development.
No ide, just Kate.

Again, who cares?


In the past I used Microchip MplabX. Then I switched to STM32 & Systemworkbench & Cube.
I hated them all. Then I took the linkerscript generated by the IDE, studied it, modified it as I saw fit.
Now I don't need an IDE anymore. No dependencies anymore. Hooray!

[mikerj]

Who cares?

Anyone that has to develop for multiple different targets.  You have a single target family (STM32) so you are not affected.

[tszaboo]

This is not even the main problem. The problem starts when you have to "set up" the IDE to work with one specific microcontroller family, download third party compliers and such. Every time that happened to me, there goes a day of work. Not fun work, on a scale of 0-10 it's a 0 amount of fun.

[T3sl4co1l]

I have Code::Blocks for IDE, set up to run GCC for AVR and ARM, and that's all I do, and more than I would ever want to do.  Oh, maybe I've done an x86 project in there too, I've got a... a couple x86 compilers on here probably.

Not too interested in using the precooked IDEs and setup tools, but the reality is, most MCUs these days have too many features than are worth reading the manual and setting up entirely by hand, and using Cube or etc. is very quickly the better way to go, and you swallow the bloat.

*Goes back to turning knobs on his oscilloscope*

Tim

[uer166]

This is not even the main problem. The problem starts when you have to "set up" the IDE to work with one specific microcontroller family, download third party compliers and such. Every time that happened to me, there goes a day of work. Not fun work, on a scale of 0-10 it's a 0 amount of fun.

A day of work? It takes 15m to go from nothing to fully functional CubeIDE. I would expect a custom Makefile/Cmake setup to take more than a day, and it's not easily transferable to a colleague. At the end of the day who cares if you have 1 or 10 applications installed, storage is cheap.

[SiliconWizard]

Who cares?

Anyone that has to develop for multiple different targets.  You have a single target family (STM32) so you are not affected.

That's actually a very good reason for this approach. Especially if most targets you use are Cortex-M based, all you need to change in your makefiles are some options (-march) and possibly defines.
The startup code and linker script can usually (never run into a case, so far, for which it wasn't true) be found in example projects given for the MCU, and off you go.

There is some initial time investment that you'll thank yourself for forever, once you see myriads of coworkers and people online fighting with vendor tools endlessly, sometimes wasting days or weeks.

[nctnico]

I agree. It is better to have a single environment like Eclipse or VS code to do software development for multiple targets compared to having a myriad of IDEs each with their own weird idiosyncrasies (and which may go out of service due to OS updates or the vendor moving to a different IDE).

For sure some vendor IDEs have code generators; typically I copy the generated code into my own project.

[Psi]

I've started moving all my projects to VS code.
Mainly because
- The dark mode works properly, too many IDEs have bugs where the background of one of the IDE windows stays white. Or there are items you want to change the color of but they are fixed.
- The extensions work pretty well to get things working reasonably quickly for a lot of different MCUs
- The search system is really nice
- General navigation around your code is nice
- Lots of online help available if you have issues because so many people use it.

[mtwieg]

Recently the software team at my job asked if they could build the code for the C2000 MCU on my board without making use of Code Composer Studio (which I used to write the firmware). I definitely understand why they don't like having to maintain another piece of software, but from what I understand it's not possible (or at least TI is not interested in supporting it). I certainly do prefer VScode as an IDE overall.

I've heard that the next major version of CCS will be based on "Theia," which is apparently similar to Eclipse and VScode, depending on the source of info 

[tszaboo]

This is not even the main problem. The problem starts when you have to "set up" the IDE to work with one specific microcontroller family, download third party compliers and such. Every time that happened to me, there goes a day of work. Not fun work, on a scale of 0-10 it's a 0 amount of fun.

A day of work? It takes 15m to go from nothing to fully functional CubeIDE. I would expect a custom Makefile/Cmake setup to take more than a day, and it's not easily transferable to a colleague. At the end of the day who cares if you have 1 or 10 applications installed, storage is cheap.

Sure, now please time the same thing for
- STM8
- PIC32 MicroC complier on the MPLAB (no X) for a legacy project
- IAR for AVR
- Setup Keil uvision debugger and compiler for an 8051 project inside a TI radio transceiver

Then check back to me and tell me how it went.

[Siwastaja]

This is again one of those "doctor it hurts when I do this" problems. I don't have this problem at all; I don't understand why would anyone do this crap when you can simply choose not to.

[Siwastaja]

Who cares?

Anyone that has to develop for multiple different targets.  You have a single target family (STM32) so you are not affected.

What Karel described works perfectly for nearly every "target". There might be a few legacy oddball product families that are exceptions to the rule. For weird unique snowflake product families, you tell your customers you don't recommend them, and if customer insists on them, or if you have to work on legacy projects and have no choice, then you price your services accordingly.

[mtwieg]

In the last several years I've learned there's a vast gulf between myself, who learned about programming and MCUs in tandem with vendor-provided IDEs and compilers, and "real" software/firmware engineers that run cmake and vi from CLI. What seems trivial to the latter can be overwhelming to the former.

[bson]

Recently the software team at my job asked if they could build the code for the C2000 MCU on my board without making use of Code Composer Studio (which I used to write the firmware).

CCS absolutely supports batch building.  It will output Makefiles and if you add things like header files and anything else needed to your project it'll build just fine.  Obviously the compiler and other tools have to be installed, but the IDE never needs to be started for automated builds.

[tggzzz]

In the last several years I've learned there's a vast gulf between myself, who learned about programming and MCUs in tandem with vendor-provided IDEs and compilers, and "real" software/firmware engineers that run cmake and vi from CLI. What seems trivial to the latter can be overwhelming to the former.

Yes and no.

I'm somebody that started by hand assembling code, without a compiler in sight (oops, that ignores Tony Hoare's seminal Algol-60 compiler. )

I never want to have to write another text file where different whitespace characters are silently semantically significant [1]. Yes make, I'm looking at you.

I'd much rather use an IDE, and examine the generated object code to verify it was what I expected.

[1] yes, Python is pushing its luck in that respect

[Silenos]

In the last several years I've learned there's a vast gulf between myself, who learned about programming and MCUs in tandem with vendor-provided IDEs and compilers, and "real" software/firmware engineers that run cmake and vi from CLI. What seems trivial to the latter can be overwhelming to the former.

But that's how large and "matured" embedded projects look like: you get the "fix this" assignment , you get the privilleges to the repository, link to the confluence or sth "building xxx project", usually outdated, you get the backlog and "have fun".
You clone repos and submodules, crap is already donwloading for an hour. And what you usually get is a hardened shitball of cmake, crap python scripts with dozens of implicitly version-sensitive dependencies, greenhills or iar or some other proprietary toolchains crying for a licence (have fun connecting to the company license server), some random tools like misra demanding more licenses, all the supporting software which require msvc and c# and 20 additional licensed components, loading tools, production tools, service tools, customer tools, resources generators, then another large blob of tests, then all the clusterfuck for security features and then another set of hacks for developers to work with security, blabla. "Oh, fortunately there is no linux bundled, yeee." Building it all from scratch takes hours on a reasonable power workstation.

So what IDE to run this? Noone gives a crap what you run and noone ever mentions this subject. It is assumed: "Jenkins can build it, so you do, and that's actually all what is needed to work".

[brucehoult]

Been there, done that, on e.g. the Galaxy S / Galaxy Tab Android build at Samsung. Repos and submodules? That's not what Perforce calls them: views and paths ...

There's a reason we did as much development as possible on AOSP on Google devices ... and actually, even before that, developing algorithms on x86 Linux and then Arm Linux on a Pi or Odroid, and THEN on AOSP, and finally lastly as late as possible on the actual production code base. Even then the builds happened in Korea, overnight, and we downloaded the assets next day (if it didn't fail).

Working on open source projects hosted on github is sheeeeeer looksury in comparison: porting DotNET to RISC-V at the moment ... builds in a Ubuntu container on Mac / Windows / Linux whatever...

[scuzzyTerminator]

A question to the community.

One of the reasons I prefer the gnu cli toolchain is the expectation it will inflict little upgrade friction over time. My effort put into mastering the tools and writing long scripts and makefiles seems worth it.

This raises a question concerning the life expectancy of your development tools. I don't mean how long they will be available, but how long will you continue to use them.

I think the most meaningful metric is usually a track record.  So, my question is: how long have you actually been using your present development environment?

[brucehoult]

Linux/Unix in general, mid 1996, MkLinux part time on my Mac. I soon picked up a SPARC ELC (running Solaris) for $50 plus another $50 for the seller to put a fresh OS install on it, then a Pentium Pro HP server new but cheap when the Pentium 2 ones came out (1997). So GCC for PowerPC and x86 from that time. And emacs, which I first used at work on Sun in 1006 I think. And obviously GNU make was in the mix there.

I was already familiar with Unix-style tools from BSD on a Zilog Z8000 at university in 1984 and then Apple MPW (Macintosh Programmer's Workshop) from late 1986.

Obviously I've used various IDEs along the way (Think Pascal, Zortech/Symantec C++, CodeWarrior, Visual Studio on NT 3.51 and 4, VSCode, Eclipse, XCode)

But it's a huge thing to be able to use familiar tools with familiar features on everything from a $3 Milk-V Duo (1 GHz 64 bit RISC-V, 64 MB RAM ... much bigger and faster than my early SPARC and x86 Linux machines) up to servers worth tens of thousands of dollars, not to mention both local and remote (e.g. AWS) machines.

I'd much rather be told "add X to CFLAGS and Y to LDFLAGS" than have to hunt through nested dialog boxes to manually find the right checkbox to select. Not only to set up the same configuration as someone else (or a web site etc) but also to compare setups. With option strings you KNOW there isn't some obscure checkbox in a buried dialog that you forgot or never found. Thank goodness IDEs these days at least store that stuff in XML or JSON or something, which can be stored / transmitted / put in source control / hand edited even if it's nearly unreadable.

[westfw]

I don't understand why would anyone do this crap

Well, if one is career-oriented and not already "senior", you want to say that you know how to use "the standard tools" (or at least "a standard tool.")
If you're developing open source stuff for the hobbyist (or other) community, it's good to use the same tools that most of your audience is using.  Even if that means suffering through an "inferior" IDE (cough, Arduino.)
If you're expecting help from the manufacturer (or "the community"), you'd better be using the tools that they provide and "support", rather than "Oh, I'm using a g++ v13 build so that I could get <obscure C++23 feature>"
If you're student, you're similarly stuck with the tools provided (mostly.)

(OTTH, as a vendor, it would be nice if you didn't do things entirely differently than everyone else.  For instance, a lot of experienced microcontroller developers were rather taken aback by the RPi Pico toolchain environment.  Weird directory structure, CMake AND Make...)

[brucehoult]

If you're student, you're similarly stuck with the tools provided (mostly.)

Heh. When I was a 1st year university student they taught us Pascal on a PDP-11/34. In the 2nd year "Algorithms and Data Structures" paper (by that time on a VAX) they didn't actually tell us what language to use. They just kind of assumed we'd use Pascal. I made a point of using a different language for every assignment. Ones I remember using include Fortran, Cobol, Lisp, BCPL, Stoic (a Forth), C. This probably stressed out the poor sods who had to mark the assignments :-)

[RoGeorge]

(and several IDEs are out of date.)

Often the lifespan of software tools for a given HW is only a couple of years, after which the manufacturer do not support it any longer, or even remove it from their current/future SW tools.

Either you go with the wave for the latest and the shiniest current thing, or you preserve the SW dev tool such that the same devboard can still be reprogrammed years later.

Best take is to create a Virtual Machine for each hardware platform.  Not containers, but a full OS install inside a VM.  Then, install in the VM all the dev tools needed, then keep that VM frozen, isolated from Internet and never upgrade it.  The update/upgrade frenzy is useless for MCU dev tools.  If something must be changed later, then take a VM snapshot first, then put the VM online for a few minutes to install/upgrade, but only if it must.

A VM would still run 10+ years from now, no matter the OS.  Disk space is cheap enough to keep one VM for each devboard/MCU family.

[mtwieg]

Recently the software team at my job asked if they could build the code for the C2000 MCU on my board without making use of Code Composer Studio (which I used to write the firmware).

CCS absolutely supports batch building.  It will output Makefiles and if you add things like header files and anything else needed to your project it'll build just fine.  Obviously the compiler and other tools have to be installed, but the IDE never needs to be started for automated builds.

Yes CCS can build headless i.e. from the command line without using the GUI. But what my coworkers want is a way to build without ever installing CCS in the first place. AFAIK this isn't possible (or at the very least TI isn't interested in supporting such a use case).

[DavidAlfa]

So a compact, easily manageable, 5-minute setup, complete ecosystem, is a problem for you.
Yeah, better to spend 5 hours setting everything up manually, crossing fingers nothing screws up someday.

My IDE is broken! Reinstall, back to work in the time I took a coffee.
Terrible.

Seems to me you'd keep climbing the mountain with an old rope to reach home everyday instead using the new electric elevator.

Why is this matter coming up so often?
HDDs no longer have 70MB, my gawd.

[westfw]

When I was a 1st year university student

Heh.  I handed in at least two major "final projects" written entirely in PDP10 assembly language.It wasn't until MUCH later that I noticed that this might have been a really mean thing to do to the profs/graders (who may or may not have had any knowledge of PDP10s.)
Aced the classes, though!

[PlainName]

HDDs no longer have 70MB, my gawd.

You need to at least double, preferably triple, whatever size you end up with for backups.

So a compact, easily manageable, 5-minute setup, complete ecosystem, is a problem for you.

"Compact"? Pretty much all the manufacturer IDEs are bloaty things which assume the end user will be using it in the same way the developer does (or, seemingly, thinks he would if he actually used it). The editors are complete shite, nothing is consistent, stuff is hard to track down when it goes wrong and they shit all over your system drive.

And then just as you finally manage to put up with it all, they change the damn thing.

Thing is, for the chip manufacturer the development tool isn't a core product. And it shows.

[SiliconWizard]

Thing is, for the chip manufacturer the development tool isn't a core product. And it shows.

Well, it's a key marketing thing, but sure not the core of their business. Not sure the investment/effort is the problem here. The problem, IMO, is just that's it's big software, and big software sucks these days, wherever it comes from, pretty much.

I personallly think vendors should focus on providing good, correct and *exhaustive* support files for their chips (memory map, complete register definitions including all bits, linker scripts, startup code, etc), clearly document the compiler options required (march/mabi/etc), and that's it. And a few clear example projects using make or Cmake. They may additionally provide extensions for VSCode or whatever, saving time for people using that. And that would be it. No need to maintain their own "IDE". Just a thought. It's a waste of their time, and, in the end, that of developers (when they end up realizing how much time they have wasted).

[DavidAlfa]

You need to at least double, preferably triple, whatever size you end up with for backups.

That's not the way you make backups, 3 copies of the same thing in the same drive, makes "pop" and all copies are gone.
Ever heard of git or svn? Or just Google Drive.

Anyways, space this is irrelevant when you can buy 2TB drivers for peanuts.

"Compact"? Pretty much all the manufacturer IDEs are bloaty things which assume the end user will be using it in the same way the developer does (or, seemingly, thinks he would if he actually used it). The editors are complete shite, nothing is consistent, stuff is hard to track down when it goes wrong and they shit all over your system drive.

And then just as you finally manage to put up with it all, they change the damn thing.

Not really. Everything is well contained i.e. C:\ST, or Program files\Microchip.
IDE editors are great with syntax and real time checks, Code assist, go to declaration/definition...
There's no such  "as you finally manage to put up with it all, they change the damn thing.", setup takes 5-10 minutes and you're done.
Maybe every 10-15 years something changes, that's progress. Otherwise we'd keep writing hex machine code manually.

ST is a bit of an exception here as they had 5 IDEs in 10 years before finally staying with CubeEIDE.
Still, the libs were the same, so it wasn't a terrible drama.

Sounds more like "Let me be, I don't wanna learn anything new" thing.

[PlainName]

You need to at least double, preferably triple, whatever size you end up with for backups.

That's not the way you make backups, 3 copies of the same thing in the same drive, makes "pop" and all copies are gone.
Ever heard of git or svn? Or just Google Drive.

Ah, someone that doesn't do backups. And thinks a reinstall of everything is a 5 min job.

You would be using removable drives, and since you would never write a backup to the last media used you would need at least two. Plus something like a NAS for on-the-fly and/or automated jobs (you aren't going to remember or bother to switch removeable drive every day or whatever). So that's minimally three drives you've got to upgrade for the new 'not very big really' requirements.

[brucehoult]

Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it.

[mikeselectricstuff]

Inevitable I'm afraid - vendors have to support their tools, so need to have a well-defined configuration, even though this will usually have lots of characteristics inherited from earlier versions, possibly going back decades.

Of course users are free to adapt & do what they want, but from experience  this becomes problematic long-term when support for new parts is needed, or projects need to be useable by others.

This is a particular issue where an external consultant/contractor delivers code to a client who wants to be able to maintain it.  "Just install manufacturer tool version x.yy and load the project" is all they want to hear.
Say what you want about Microchips tools, but IME the above "just works"  for everything from a 6-pin SOT23 to a 32 bit 200MHz device.

[tszaboo]

So a compact, easily manageable, 5-minute setup, complete ecosystem, is a problem for you.
Yeah, better to spend 5 hours setting everything up manually, crossing fingers nothing screws up someday.

My IDE is broken! Reinstall, back to work in the time I took a coffee.
Terrible.

Seems to me you'd keep climbing the mountain with an old rope to reach home everyday instead using the new electric elevator.

Why is this matter coming up so often?
HDDs no longer have 70MB, my gawd.

This goes for also the others that say: "Why don't you do X?"
Most Firmware developers I've seen work in teams. Teams have rules. You might not have any say in what tool to use to program your micro.
You might be working on legacy projects that you are not supposed to change much, just "Make it work with extra X" that are decades old. Developed by engineers that didn't care, don't work here anymore.

If you don't work like that, we are happy for you.

[mtwieg]

So a compact, easily manageable, 5-minute setup, complete ecosystem, is a problem for you.
Yeah, better to spend 5 hours setting everything up manually, crossing fingers nothing screws up someday.

Yeah I suspect that even if I found a way to build without installing CCS, they would immediately see it's an even worse option and reject it. Not sure what they're actually hoping to get.

Inevitable I'm afraid - vendors have to support their tools, so need to have a well-defined configuration

Yeah to me this is the true benefit of a vendor-provided IDE. It packages many things (compiler, linker, debugger, libraries, maybe an SDK) in a tested configuration. Editing code in the IDE is basically its least important function (just use VScode for that).