Author Topic: Is ST Cube IDE a piece of buggy crap?  (Read 252760 times)

0 Members and 1 Guest are viewing this topic.

Offline peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 4443
  • Country: gb
  • Doing electronics since the 1960s...
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1250 on: November 16, 2024, 06:50:32 pm »
I am not aware of any "nice to have" Cube IDE fixes since I've been using it, c. 2018. Maybe something not obvious.
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline elektryk

  • Regular Contributor
  • *
  • Posts: 145
  • Country: pl
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1251 on: November 16, 2024, 08:33:41 pm »
Clones are a good thing, surely? I am using a 32F417 and if I use software crypto then there is a chinese 32F407 which "should" be the same.

Legit F407/F417 should also be compatible each other.
Check how many problems are generated by F103 clones, different flash page sizes, problems with ADC DMA...

Quote
What I have seen is that full time employees like picking the latest chips (because the company is picking up the huge bill for the learning curve, and extra parts stock) while contractors and business owners stick with chips with which they have lots of experience :)

This time it was about something that would be available for a long time. Learning something new is also an interesting aspect.

Quote
I also have not seen the 32F417 get more pricey. It is roughly back to pre-covid levels now. Which chips have you seen go up significantly?

I use 32F407, which I want to replace with 32H562. It has its drawbacks, but the second model is twice as cheap.

btw Cube IDE 16.1 seems to work on Win7. I changed ST GDB Server to OpenOCD and selected software reset.
For now I only did the test with Discovery 32F407, the only downside its that MCU stays in reset state after programming with green arrow button (Run).

« Last Edit: November 16, 2024, 08:36:20 pm by elektryk »
 

Offline elektryk

  • Regular Contributor
  • *
  • Posts: 145
  • Country: pl
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1252 on: November 16, 2024, 08:40:22 pm »
I am not aware of any "nice to have" Cube IDE fixes since I've been using it, c. 2018. Maybe something not obvious.

I'm tryin' the new version hoping that they will fix opening of (not quite) random files problem. New MCU is other reason, otherwise I would still use AC6.
 

Offline peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 4443
  • Country: gb
  • Doing electronics since the 1960s...
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1253 on: November 16, 2024, 10:43:19 pm »
No; that random file opening problem has not been fixed. Endless threads on the ST forum.

What actually happens is that Cube opens whatever source file the CPU happened to be "in" when it got stopped/started. It is not a random file. The fix is fairly obvious but needs hacking around in the Eclipse breakpoint handling code (it was discussed in this thread way back too) and evidently nobody in ST wants to get into it.

Quote
Cube IDE 16.1 seems to work on Win7. I changed ST GDB Server to OpenOCD and selected software reset.

Very interesting; thanks.

Do you need new Cube IDE (1.16.x) for the 32H562? I think there should just be a CPU type config somewhere.
« Last Edit: November 16, 2024, 10:46:40 pm by peter-h »
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6591
  • Country: nl
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1254 on: November 17, 2024, 09:17:15 am »
This time it was about something that would be available for a long time.
Indeed the company I worked for the commercial and hardware architects choose the chip, even to which RAM size it was limited for costs but also for long term availability.
The joke was back then that ST would sell its newest chips for way less than the established ones , first because production was starting for full soon and second to push the new chip in the field. Sometimes we had prototypes delivery year before launch and the agreement was that any issue should be reported right away.
At least half the addendum would either be from this stage or solved if possible.
 

Offline peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 4443
  • Country: gb
  • Doing electronics since the 1960s...
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1255 on: November 17, 2024, 10:03:26 pm »
That's a bad way to choose a MCU, but it is probably OK for a large OEM user who will always get priority when times are hard and there is a large scale panic (covid). A small business owner will choose the common commodity option, even if it means some (usually dirt cheap) discrete components on the board, especially if there is in-house expertise, tools, etc.
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline elektryk

  • Regular Contributor
  • *
  • Posts: 145
  • Country: pl
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1256 on: January 10, 2025, 08:44:50 pm »
Finally I couldn't stand the random windows opening problem and created a simple script which is for FW download only (not debug).

Place download.bat in a project directory, provide your Cube Prog path, add run configuration as in the picture.

Code: [Select]
"C:\Program Files (x86)\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin\STM32_Programmer_CLI.exe"  -c port=SWD freq=4000 -d %1

"C:\Program Files (x86)\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin\STM32_Programmer_CLI.exe"  -c port=SWD freq=4000 -run

Tested with IDE 16 and 16.1.

BTW this script can be easily modified to use with UART bootloader.
« Last Edit: January 10, 2025, 09:51:21 pm by elektryk »
 

Offline peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 4443
  • Country: gb
  • Doing electronics since the 1960s...
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1257 on: January 13, 2025, 02:56:34 pm »
Would you be able to explain what this does?
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline wek

  • Frequent Contributor
  • **
  • Posts: 548
  • Country: sk
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1258 on: January 13, 2025, 04:37:11 pm »
As elektryk said above:

> a simple script which is for FW download only (not debug).

i.e. it avoids running gdb etc. in eclipse, and just uses CubeProgrammer's command-line version ("CLI") to download and run the binary.

JW
 

Offline elektryk

  • Regular Contributor
  • *
  • Posts: 145
  • Country: pl
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1259 on: January 15, 2025, 06:42:33 am »
Exactly.

Another possible speed improvement is mass erase instead of block erase, it works, but doens't make sense if bootloader is used or user data is stored in flash.
« Last Edit: January 15, 2025, 06:44:25 am by elektryk »
 

Offline paulca

  • Super Contributor
  • ***
  • Posts: 4428
  • Country: gb
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1260 on: January 17, 2025, 10:04:47 am »
This is the constant dichotomy of IDEs and CASE tools in general.

Their aim is to make things easier by automating tasks and operations.  They start out that way.  Simple.  They solve 90% of things for 90% of people.  They are simple, fast, reliable.

Then they start with the constant flow of tickets demanding "Support X", "Support Y" and ever increasingly obscure configurations and complications.

Sooner or later they end up bloated, slow, almost as complicated and as slow as the manual process was.  The complexity leads to unreliability.

Usually it takes a completely new tool to appear to try and return it to simplicity and then it repeats around again.

Bypassing IDE components and doing your own build/run/deploy scripting is usually the solution as elektryk demonstrates.  Bring it back to solving only the problem YOU currently have.  It comes at a cost though.  Now you have to maintain all that if it is subjected to external changes.
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 
The following users thanked this post: westfw, Siwastaja, Dazed_N_Confused

Offline peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 4443
  • Country: gb
  • Doing electronics since the 1960s...
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1261 on: January 17, 2025, 01:54:12 pm »
I think the problem is that ST picked up an existing tool (Eclipse) and have run with it, but have not allocated in-house resources to tidy up the loose ends.

And being open source, there is a lot of loose ends! People get bored, life changes, etc, and they move on.

And it was written in Java which is notorious for bloat. This is c:\st



17k files! Admittedly a lot of that is chip support libraries but still this thing is massive. No wonder nobody understands it.

But what other tools could they have used instead? With Cube IDE, we have a tool which is

- free of charge
- license free
- does not report to the church HQ (well, you can turn it off)
- does not need internet access to work (now, or ever) so it can be archived with the project, and doesn't rely on license servers to be maintained
- runs in win7-64 (despite win10+ claims) or higher
« Last Edit: January 17, 2025, 02:21:27 pm by peter-h »
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline paulca

  • Super Contributor
  • ***
  • Posts: 4428
  • Country: gb
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1262 on: January 18, 2025, 10:53:55 am »
Have been through this before already?  The 2.5Gb is not Java code.  A very small fraction is.  Most of it, as I recall is documentation and firmware.  aka "Collateral"

Eclipse is written in Java AND GTK (IIRC).  The GUI library is native C and is called via the JNDI bindings in Java...  Many dependencies in Java contain "hooks" which can access native libraries if they are made available.  GUI frameworks are a very common thing to "natively accelerate".

Java's bloating is caused by sensible engineering ... although I think the cost benefit analysis gets skipped too often.  It stems from the preference to re-use already existing and tested code where possible.  This has the tendency to see a "complex or complicated" part of a problem and immediately go look for some other poor fools efforts for solving that in a testable way, rather than tackle the complexity themselves.

Honestly you cannot fault the intent.  The implementation of it in many cases leaves a lot to be desired.  On my high horse I'd say the issue is too many people called "Software Engineers" that don't have the first clue what software engineering is and are really just "coders".  They wouldn't understand the concept of appraising tools and techniques through measurement.  Cost, benefit analysis.  Technical debt budgeting.  Auditing, security, licensing, legal....
 ethics.  And so on.  Learning to code on Code Academy or via YouTube will NOT teach you the "Engineering" aspect or even why it's important.
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline tellurium

  • Frequent Contributor
  • **
  • Posts: 288
  • Country: ua
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1263 on: January 19, 2025, 09:33:05 am »
I am not bothered by size much. But the responsiveness sometimes drives me nuts.

I open my Cube, click on the list of examples, and wait for 10+ seconds for it to load.
Again, I am here in 2025 waiting 10+ seconds to load a list of example projects.
When I use Cube - like open files, switch views, open projects - it is ridiculously slow.

Editors I used in 1980s were considerably more snappier.

Plus the whole idea of code generation with the "USER CODE BEGIN/END" blocks is a joke, to be honest.
Not to say that the whole process is tailored to the single-user usage, not a team work.
To work on Cube projects in a team, people must resort to tricks.
Open source embedded network library https://github.com/cesanta/mongoose
TCP/IP stack + TLS1.3 + HTTP/WebSocket/MQTT in a single file
 
The following users thanked this post: Nominal Animal

Offline woofy

  • Frequent Contributor
  • **
  • Posts: 381
  • Country: gb
    • Woofys Place
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1264 on: January 19, 2025, 10:58:26 pm »
Plus the whole idea of code generation with the "USER CODE BEGIN/END" blocks is a joke, to be honest.

I've only just started a project with CubeIDE and assumed that was to prevent the code generator overwriting user code by providing a safe place to put it. This is a pain with MPLABX/Harmony where we have to manually guide the merge.

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 7315
  • Country: fi
    • My home page and email address
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1265 on: January 20, 2025, 01:57:20 am »
If you need a code generator, you should generate the code to a file designated as such (perhaps a custom file extension, or at least a hint in the file name), and never mix user-edited and machine-generated/edited code in the same file: it is a maintenance hell!  You cannot even tell from the modification timestamp when it was last generated and when last modified by a human.

In C and C++, the preprocessor can #include any file, so there are many different patterns one can choose from: You can have the generated file include user code files, or have a "scaffolding" file including both generated and user-maintained files, or you can tell the user to include specific snippets in the files they maintain.  Lots of options, all superior to mixing user- and machine-maintained source code.

Just because every other source code tool (including UI editors for windowing toolkits like Qt and Gtk) does this, does not make it sane or acceptable, in my opinion.
 
The following users thanked this post: Siwastaja, SiliconWizard

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15962
  • Country: fr
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1266 on: January 20, 2025, 03:35:41 am »
If you need a code generator, you should generate the code to a file designated as such (perhaps a custom file extension, or at least a hint in the file name), and never mix user-edited and machine-generated/edited code in the same file: it is a maintenance hell!  You cannot even tell from the modification timestamp when it was last generated and when last modified by a human.

In C and C++, the preprocessor can #include any file, so there are many different patterns one can choose from: You can have the generated file include user code files, or have a "scaffolding" file including both generated and user-maintained files, or you can tell the user to include specific snippets in the files they maintain.  Lots of options, all superior to mixing user- and machine-maintained source code.

Just because every other source code tool (including UI editors for windowing toolkits like Qt and Gtk) does this, does not make it sane or acceptable, in my opinion.

Exactly, and what CubeMX does is completely atrocious, with sections of "user code" guarded by, uh, special comments. Pure madness.
 
The following users thanked this post: Siwastaja

Offline peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 4443
  • Country: gb
  • Doing electronics since the 1960s...
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1267 on: January 20, 2025, 03:40:57 pm »
Quote
I open my Cube, click on the list of examples, and wait for 10+ seconds for it to load.
Again, I am here in 2025 waiting 10+ seconds to load a list of example projects.
When I use Cube - like open files, switch views, open projects - it is ridiculously slow.

I don't see that. As an editor, it runs quite fast (6 core i7, 24GB RAM).

However I am not familiar with the examples you refer to.

Quote
Plus the whole idea of code generation with the "USER CODE BEGIN/END" blocks is a joke, to be honest.

That is the code from the Cube MX code generator. They generate this template sort of stuff. I've edited it out whenever I found any of that. But MX was used only to get my project started, c. 2016. After that, the guy who set it up used MX to generate code fragments for Peripheral X etc and then chucked away the MX project.

Quote
Not to say that the whole process is tailored to the single-user usage, not a team work.
To work on Cube projects in a team, people must resort to tricks.

Yes; it is not for multi-dev projects. But then you need more complexity because you have to lock files, etc. I see this in Sage accounting software. They lock modules, but also need a "locking manager".
« Last Edit: January 20, 2025, 03:43:13 pm by peter-h »
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 7315
  • Country: fi
    • My home page and email address
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1268 on: January 20, 2025, 06:19:28 pm »
Quote
Not to say that the whole process is tailored to the single-user usage, not a team work.
To work on Cube projects in a team, people must resort to tricks.

Yes; it is not for multi-dev projects. But then you need more complexity because you have to lock files, etc. I see this in Sage accounting software. They lock modules, but also need a "locking manager".
In POSIXy land, it would suffice to do a
    // int descriptor = fileno(FILEhandle);
    struct flock  lock = {
        .l_type = F_WRLCK,
        .l_whence = SEEK_SET,
        .l_start = 0,
        .l_len = 0,
    };
    do {
        result = fcntl(descriptor, F_SETLK, &lock);
    } while (result == -1 && errno == EINTR);
    if (result == -1) {
        // Lock failed, see errno; do F_GETLK to find which process has it locked (lock.l_pid)
    } else {
        // File is now write-locked by self
    }
to acquire an advisory write lock on the target file while it is being edited, even across NFS/Samba (assuming correctly configured server).  It does not stop anyone from accessing/reading/writing/replacing the file, it is just advisory, so perfect for interactive tools (that would pop up a window when the file is detected already locked).

Another common approach is to use lock directories: creating a directory named say .lock-name in the same directory, to lock file named name.  This was widely used in the olden days of Unix when NFS servers never had their lock subsystems configured.  Directory creation is atomic, even over shared filesystems, unlike files and file metadata changes and file content changes.  Unlike advisory locks, these lock directories would remain if the application crashed, though, so workarounds for stale locking had to be devised.  And conventions for lock directory names also varied by application/service, so they rarely co-operated well.
 

Offline paulca

  • Super Contributor
  • ***
  • Posts: 4428
  • Country: gb
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1269 on: January 20, 2025, 07:18:58 pm »
Don't we solve that differently these days?  Or did I miss understand.   Is this just "Concurrent versioning"?
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 4443
  • Country: gb
  • Doing electronics since the 1960s...
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1270 on: January 20, 2025, 08:16:45 pm »
Quote
In POSIXy land, it would suffice to do a

That's neat, but it implies "unix" usage, and what about windows?

ST just happened to pick a tool which doesn't support multiple users.
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 7315
  • Country: fi
    • My home page and email address
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1271 on: January 20, 2025, 11:03:32 pm »
Quote
In POSIXy land, it would suffice to do a
That's neat, but it implies "unix" usage, and what about windows?
Very difficult, because Windows simply wasn't designed for multiple concurrent users.  The problem is that in Windows, the analogous byte-range locks (LockFileEx) are enforced/mandatory: the lock prevents access by any other process.  Everywhere else, they're co-operative/advisory only, they don't affect any I/O operations.

The one "portable" approach limits file sizes to less than 2 GiB-1 bytes: use the byte at offset 2³¹-1 as a lock indicator, locking and examining the lock at that single byte only.  Because the byte does not actually exist in the files (assuming editable files are shorter than that), whether the lock is mandatory (Windows) or advisory (Unix/POSIX) does not matter, as the byte won't ever be accessed.  (Byte-range locks can be placed at any offset in the file, regardless of whether the file is that long or whether a sparse file has data at that offset.  The choice of 2 GiB-1 is not random: although irrelevant for current Samba and NFSv4, with any other shared filesystem it has the best chance of actually being supported, but as far above actual content in human-edited files as possible.)

In C and C++ code it is trivial, #ifdef _WIN32 ... #else ... #endif selecting between Windows and POSIX/Unix.  Similarly, in Python, one can at runtime use either msvcrt or fcntl module.  In both cases you can easily wrap the functionality to an OS-specific source file, and make this cleanly, without much red tape at all.

In Java, byte-range locks are accessible via FileLock, but I'm not sure if Java Runtimes correctly map it to LockFileEx/fcntl() byte-range locks.

I do not personally use Eclipse, but its documentation implies it uses rather wonky "file locking" schemes, including a file named .lock in the project configuration directory, which is often read-only for unprivileged users, leading users to disable file locking in Eclipse.  It all sounds utterly crazy to me.  I do not believe those who developed Eclipse in the first place had worked on shared filesystems or multi-user environments before – or at least considered those irrelevant or an afterthought.
« Last Edit: January 20, 2025, 11:05:23 pm by Nominal Animal »
 

Offline paulca

  • Super Contributor
  • ***
  • Posts: 4428
  • Country: gb
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1272 on: January 21, 2025, 09:46:04 am »
I do not personally use Eclipse, but its documentation implies it uses rather wonky "file locking" schemes, including a file named .lock in the project configuration directory, which is often read-only for unprivileged users, leading users to disable file locking in Eclipse.  It all sounds utterly crazy to me.  I do not believe those who developed Eclipse in the first place had worked on shared filesystems or multi-user environments before – or at least considered those irrelevant or an afterthought.

IIRC Eclipse is/was actually IBM Websphere.  IBM wanted to create a fully integrated IDE for their new application server they began writing the basic editor/application etc.  They decided to opensource it to get the community to do the heavy lifting and allow them to focus on the IBM bespoke application server and let the OSS folks do the IDE, in exchange for a pretty good "base" to begin with.

IBM are well know for trades like this.  Postfix for example.  Was traded for a closing source of a version of Apache HTTPD.

EDIT:  As mentioned before, and somewhat explained above as to why, Eclipse is primarily used for Java application development, particularly web-application development or otherwise "application server" enterprise WAR/EAR style applications.

However as IBM put the split in a particular place between the OSS IDE Core and the application server metrics, panels, plugins and feature suite relating to IBM WebSphere tooling.  It left the "Eclipse" IDE with only basic Java tooling.

Yes there are many "suites" of add-ons to convert Eclipse into C/C++ IDE with the CDT toolkit and friends.  There are dozens of flavours of these "suites" and in the past I have learnt the hard way why they exist.  You are 100 times better off downloading the latest CDT version of Eclipse than you are trying to use Vanila Eclipse and add all the components, plugins, toolchains and convert it yourself.  Similarly so if you are working with RedHat JBoss.  Use the specific Eclipse version for JBoss.  Just as we are using the specific version for STM32.
« Last Edit: January 21, 2025, 10:30:13 am by paulca »
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline paulca

  • Super Contributor
  • ***
  • Posts: 4428
  • Country: gb
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1273 on: January 21, 2025, 12:58:31 pm »
A further point on performance.

It's not a Java problem.

In work for the past few years I have switched from "free" eclipse to using £1000+ "InteliJ ultimate edition" from JetBrains.

It is not written in Java.  It's slow and sluggish as ole crap.  It has many bugs and frustrations.

It's over complicated and trying to do too many things, in too many different ways for too many different people.

As an example.  Many of our build scripts include a git hook to find tagged collateral and use it to generate code.  However the way that is presently implemented causes it to ask for credentials.  "ENTER, ENTER" is all that is required.  However if you accidentally let InteliJ build the application "first" it will run this build context and 100% hang the process with no way to recover it, except to restart the whole IDE.  There is no way to inject those 2 line feeds into standard in for the build and InteliJ has not enough balls in it's process control mechanisms to even kill it.  Windows mandatory locks also prevent the normal build for running concurrently.  The work around is to quickly build the application from it's own build script (maven) so that those files are generated and the InteliJ auto build systems don't "declaratively" look to building it themselves.  There are many others.

No IDE is perfect. It's a balance of costs, benefits, annoyances and joys.  Sometimes it's shit the IDE sucks and you have no choice.  Some day the weather is better.
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 4443
  • Country: gb
  • Doing electronics since the 1960s...
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1274 on: January 21, 2025, 09:45:26 pm »
And I bet that 1k IDE has a license / checks it online every time you start, etc, so a project cannot be archived, revisited 10 years later, etc.
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf