The problem with microcontroller development... - Page 1
Forum section: electronics / general

author: westfw
author_rank: Super Contributor
timestamp: July 03, 2024, 07:51:55 pm
content: 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...

author: Karel
author_rank: Super Contributor
timestamp: July 03, 2024, 09:48:55 pm
content: Quote from: westfw on July 03, 2024, 07:51:55 pmWho 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!

author: mikerj
author_rank: Super Contributor
timestamp: July 04, 2024, 02:54:13 pm
content: Quote from: Karel on July 03, 2024, 09:48:55 pmAnyone that has to develop for multiple different targets. You have a single target family (STM32) so you are not affected.

author: tszaboo
author_rank: Super Contributor
timestamp: July 04, 2024, 03:11:49 pm
content: 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.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: July 04, 2024, 03:32:56 pm
content: 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

author: uer166
author_rank: Super Contributor
timestamp: July 04, 2024, 11:15:55 pm
content: Quote from: tszaboo on July 04, 2024, 03:11:49 pmA 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 05, 2024, 12:11:13 am
content: Quote from: mikerj on July 04, 2024, 02:54:13 pmThat'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.

author: nctnico
author_rank: Super Contributor
timestamp: July 07, 2024, 08:31:03 am
content: 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.

author: Psi
author_rank: Super Contributor
timestamp: July 07, 2024, 01:22:11 pm
content: 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.

author: mtwieg
author_rank: Frequent Contributor
timestamp: July 07, 2024, 07:10:38 pm
content: 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

author: tszaboo
author_rank: Super Contributor
timestamp: July 08, 2024, 07:49:30 am
content: Quote from: uer166 on July 04, 2024, 11:15:55 pmSure, 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 transceiverThen check back to me and tell me how it went.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 08, 2024, 07:58:25 am
content: 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 08, 2024, 08:00:09 am
content: Quote from: mikerj on July 04, 2024, 02:54:13 pmWhat 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.

author: mtwieg
author_rank: Frequent Contributor
timestamp: July 08, 2024, 12:31:06 pm
content: 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.

author: bson
author_rank: Unknown
timestamp: July 08, 2024, 07:22:34 pm
content: Quote from: mtwieg on July 07, 2024, 07:10:38 pmCCS 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.

author: tggzzz
author_rank: Super Contributor
timestamp: July 08, 2024, 07:33:32 pm
content: Quote from: mtwieg on July 08, 2024, 12:31:06 pmYes 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 . 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. yes, Python is pushing its luck in that respect

author: Silenos
author_rank: Regular Contributor
timestamp: July 08, 2024, 08:37:05 pm
content: Quote from: mtwieg on July 08, 2024, 12:31:06 pmBut 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".

author: brucehoult
author_rank: Super Contributor
timestamp: July 08, 2024, 11:57:31 pm
content: 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...

author: scuzzyTerminator
author_rank: Regular Contributor
timestamp: July 09, 2024, 01:49:06 am
content: 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?

author: brucehoult
author_rank: Super Contributor
timestamp: July 09, 2024, 05:04:32 am
content: 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.

author: westfw
author_rank: Super Contributor
timestamp: July 09, 2024, 05:10:25 am
content: QuoteWell, 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...)

author: brucehoult
author_rank: Super Contributor
timestamp: July 09, 2024, 05:29:03 am
content: Quote from: westfw on July 09, 2024, 05:10:25 amHeh. 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 :-)

author: RoGeorge
author_rank: Super Contributor
timestamp: July 09, 2024, 06:43:03 am
content: Quote from: westfw on July 03, 2024, 07:51:55 pmOften 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.

author: mtwieg
author_rank: Frequent Contributor
timestamp: July 09, 2024, 01:53:23 pm
content: Quote from: bson on July 08, 2024, 07:22:34 pmYes 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).

author: DavidAlfa
author_rank: Super Contributor
timestamp: July 09, 2024, 07:12:20 pm
content: 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.

author: westfw
author_rank: Super Contributor
timestamp: July 09, 2024, 09:20:58 pm
content: QuoteHeh. 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!

author: PlainName
author_rank: Super Contributor
timestamp: July 09, 2024, 10:53:15 pm
content: QuoteYou need to at least double, preferably triple, whatever size you end up with for backups.Quote"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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 10, 2024, 12:11:01 am
content: Quote from: PlainName on July 09, 2024, 10:53:15 pmWell, 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).

author: DavidAlfa
author_rank: Super Contributor
timestamp: July 10, 2024, 04:56:17 am
content: Quote from: PlainName on July 09, 2024, 10:53:15 pmThat'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.Quote from: PlainName on July 09, 2024, 10:53:15 pmNot 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.

author: PlainName
author_rank: Super Contributor
timestamp: July 10, 2024, 08:54:12 am
content: Quote from: DavidAlfa on July 10, 2024, 04:56:17 amAh, 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.

author: brucehoult
author_rank: Super Contributor
timestamp: July 10, 2024, 09:36:13 am
content: Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 10, 2024, 10:27:39 am
content: 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.

author: tszaboo
author_rank: Super Contributor
timestamp: July 10, 2024, 11:46:25 am
content: Quote from: DavidAlfa on July 09, 2024, 07:12:20 pmThis 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.

author: mtwieg
author_rank: Frequent Contributor
timestamp: July 10, 2024, 01:00:22 pm
content: Quote from: DavidAlfa on July 09, 2024, 07:12:20 pmYeah 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.Quote from: mikeselectricstuff on July 10, 2024, 10:27:39 amYeah 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).