Author Topic: The problem with microcontroller development...  (Read 4809 times)

0 Members and 3 Guests are viewing this topic.

Offline westfwTopic starter

  • Super Contributor
  • ***
  • Posts: 4397
  • Country: us
The problem with microcontroller development...
« on: July 03, 2024, 07:51:55 pm »

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...
« Last Edit: July 03, 2024, 08:03:10 pm by westfw »
 
The following users thanked this post: mikerj, scuzzyTerminator, faststoff

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2307
  • Country: 00
Re: The problem with microcontroller development...
« Reply #1 on: July 03, 2024, 09:48:55 pm »
(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!
 

Online mikerj

  • Super Contributor
  • ***
  • Posts: 3450
  • Country: gb
Re: The problem with microcontroller development...
« Reply #2 on: July 04, 2024, 02:54:13 pm »
Who cares?

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

Offline tszaboo

  • Super Contributor
  • ***
  • Posts: 8503
  • Country: nl
  • Current job: ATEX product design
Re: The problem with microcontroller development...
« Reply #3 on: July 04, 2024, 03:11:49 pm »
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.
 
The following users thanked this post: mikerj, 2N3055

Offline T3sl4co1l

  • Super Contributor
  • ***
  • Posts: 22435
  • Country: us
  • Expert, Analog Electronics, PCB Layout, EMC
    • Seven Transistor Labs
Re: The problem with microcontroller development...
« Reply #4 on: July 04, 2024, 03:32:56 pm »
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
« Last Edit: July 04, 2024, 03:35:27 pm by T3sl4co1l »
Seven Transistor Labs, LLC
Electronic design, from concept to prototype.
Bringing a project to life?  Send me a message!
 
The following users thanked this post: kaevee, 2N3055

Offline uer166

  • Super Contributor
  • ***
  • Posts: 1052
  • Country: us
Re: The problem with microcontroller development...
« Reply #5 on: July 04, 2024, 11:15:55 pm »
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.
 
The following users thanked this post: faststoff

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 16301
  • Country: fr
Re: The problem with microcontroller development...
« Reply #6 on: July 05, 2024, 12:11:13 am »
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.
 
The following users thanked this post: nctnico, pardo-bsso, kaevee

Online nctnico

  • Super Contributor
  • ***
  • Posts: 28769
  • Country: nl
    • NCT Developments
Re: The problem with microcontroller development...
« Reply #7 on: July 07, 2024, 08:31:03 am »
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.
« Last Edit: July 07, 2024, 08:32:56 am by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Psi

  • Super Contributor
  • ***
  • Posts: 10482
  • Country: nz
Re: The problem with microcontroller development...
« Reply #8 on: July 07, 2024, 01:22:11 pm »
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.

Greek letter 'Psi' (not Pounds per Square Inch)
 

Online mtwieg

  • Frequent Contributor
  • **
  • Posts: 592
  • Country: us
Re: The problem with microcontroller development...
« Reply #9 on: July 07, 2024, 07:10:38 pm »
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  :-//
 

Offline tszaboo

  • Super Contributor
  • ***
  • Posts: 8503
  • Country: nl
  • Current job: ATEX product design
Re: The problem with microcontroller development...
« Reply #10 on: July 08, 2024, 07:49:30 am »
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.
 

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 9704
  • Country: fi
Re: The problem with microcontroller development...
« Reply #11 on: July 08, 2024, 07:58:25 am »
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.
 

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 9704
  • Country: fi
Re: The problem with microcontroller development...
« Reply #12 on: July 08, 2024, 08:00:09 am »
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.
 

Online mtwieg

  • Frequent Contributor
  • **
  • Posts: 592
  • Country: us
Re: The problem with microcontroller development...
« Reply #13 on: July 08, 2024, 12:31:06 pm »
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.
« Last Edit: July 08, 2024, 12:37:32 pm by mtwieg »
 

Offline bson

  • Supporter
  • ****
  • Posts: 2565
  • Country: us
Re: The problem with microcontroller development...
« Reply #14 on: July 08, 2024, 07:22:34 pm »
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.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 22175
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: The problem with microcontroller development...
« Reply #15 on: July 08, 2024, 07:33:32 pm »
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
« Last Edit: July 08, 2024, 07:36:44 pm by tggzzz »
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Online Silenos

  • Regular Contributor
  • *
  • Posts: 65
  • Country: pl
  • Fumbling in ignorance
Re: The problem with microcontroller development...
« Reply #16 on: July 08, 2024, 08:37:05 pm »
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".
« Last Edit: July 08, 2024, 09:02:45 pm by Silenos »
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 5078
  • Country: nz
Re: The problem with microcontroller development...
« Reply #17 on: July 08, 2024, 11:57:31 pm »
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...

 

Offline scuzzyTerminator

  • Regular Contributor
  • *
  • Posts: 65
  • Country: us
Re: The problem with microcontroller development...
« Reply #18 on: July 09, 2024, 01:49:06 am »
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?
« Last Edit: July 09, 2024, 01:51:34 am by scuzzyTerminator »
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 5078
  • Country: nz
Re: The problem with microcontroller development...
« Reply #19 on: July 09, 2024, 05:04:32 am »
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.
 
The following users thanked this post: Karel

Offline westfwTopic starter

  • Super Contributor
  • ***
  • Posts: 4397
  • Country: us
Re: The problem with microcontroller development...
« Reply #20 on: July 09, 2024, 05:10:25 am »
Quote
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...)
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 5078
  • Country: nz
Re: The problem with microcontroller development...
« Reply #21 on: July 09, 2024, 05:29:03 am »
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 :-)
 
The following users thanked this post: xvr

Online RoGeorge

  • Super Contributor
  • ***
  • Posts: 7271
  • Country: ro
Re: The problem with microcontroller development...
« Reply #22 on: July 09, 2024, 06:43:03 am »
(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.
« Last Edit: July 09, 2024, 08:22:48 pm by RoGeorge »
 

Online mtwieg

  • Frequent Contributor
  • **
  • Posts: 592
  • Country: us
Re: The problem with microcontroller development...
« Reply #23 on: July 09, 2024, 01:53:23 pm »
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).
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 6544
  • Country: es
Re: The problem with microcontroller development...
« Reply #24 on: July 09, 2024, 07:12:20 pm »
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.
« Last Edit: July 09, 2024, 07:21:22 pm by DavidAlfa »
Hantek DSO2x1x            Drive        FAQ          DON'T BUY HANTEK! (Aka HALF-MADE)
Stm32 Soldering FW      Forum      Github      Donate
 
The following users thanked this post: uer166

Offline westfwTopic starter

  • Super Contributor
  • ***
  • Posts: 4397
  • Country: us
Re: The problem with microcontroller development...
« Reply #25 on: July 09, 2024, 09:20:58 pm »
Quote
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!
 

Offline PlainName

  • Super Contributor
  • ***
  • Posts: 7689
  • Country: va
Re: The problem with microcontroller development...
« Reply #26 on: July 09, 2024, 10:53:15 pm »
Quote
HDDs no longer have 70MB, my gawd.

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

Quote
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.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 16301
  • Country: fr
Re: The problem with microcontroller development...
« Reply #27 on: July 10, 2024, 12:11:01 am »
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).
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 6544
  • Country: es
Re: The problem with microcontroller development...
« Reply #28 on: July 10, 2024, 04:56:17 am »
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.
« Last Edit: July 10, 2024, 05:00:05 am by DavidAlfa »
Hantek DSO2x1x            Drive        FAQ          DON'T BUY HANTEK! (Aka HALF-MADE)
Stm32 Soldering FW      Forum      Github      Donate
 

Offline PlainName

  • Super Contributor
  • ***
  • Posts: 7689
  • Country: va
Re: The problem with microcontroller development...
« Reply #29 on: July 10, 2024, 08:54:12 am »
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.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 5078
  • Country: nz
Re: The problem with microcontroller development...
« Reply #30 on: July 10, 2024, 09:36:13 am »
Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it.
 

Online mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 14197
  • Country: gb
    • Mike's Electric Stuff
Re: The problem with microcontroller development...
« Reply #31 on: July 10, 2024, 10:27:39 am »
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.


Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline tszaboo

  • Super Contributor
  • ***
  • Posts: 8503
  • Country: nl
  • Current job: ATEX product design
Re: The problem with microcontroller development...
« Reply #32 on: July 10, 2024, 11:46:25 am »
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.
 

Online mtwieg

  • Frequent Contributor
  • **
  • Posts: 592
  • Country: us
Re: The problem with microcontroller development...
« Reply #33 on: July 10, 2024, 01:00:22 pm »
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).
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf