ARM and the framework disaster
-
*sideeyes you* :suss:
Real programmers use butterflies
LOL!!! I do miss C++
-
First of all, regarding the requirement of using code generators and drag and drop widgets to "program" in C++, can we simply not? Whoever thought that was a good idea is currently at the top of my naughty list. I'm looking at you stm32CubeIDE. Tell me what the venn diagram looks like between people that code in C and C++ and people that want drag and drop heavy handed code generator "modules" they have to muck with in a weird IDE that you're suddenly tied to? Because I don't think the intersection is very big. This junk makes VB6 look streamlined. Also why does it have to be such a hassle to code ARM devices? I have two of them collecting dust because every single framework has something terrible about it that makes it unusable. All I want is to code in C++, in a framework people actually use, and one that doesn't take an hour ever time the firmware needs to be rebuilt. Apparently the people that write the toolchains for ARM find that to be too tall an order. I just don't get it. At this rate, I'm never coding for ARM Cortex-Ms.
Real programmers use butterflies
I am working with STM32 for several years. Looks like every new release has more and more bugs, which are never fixed. On the other hand, new CubeIDE version has super-ugly new look. Probably they have too much UI programmers, but not enough hadrware programmers. CubeMX code generator produces non-working code. But if you don't want code generator, you can write everything from scratch. All code samples are written from scratch without CubeMX. CubeIDE itself is OK, it is Eclipse-based and makes its work. Starting a new project now, I think I will look for another options. If looks like STM moves in wrong direction.
-
I am working with STM32 for several years. Looks like every new release has more and more bugs, which are never fixed. On the other hand, new CubeIDE version has super-ugly new look. Probably they have too much UI programmers, but not enough hadrware programmers. CubeMX code generator produces non-working code. But if you don't want code generator, you can write everything from scratch. All code samples are written from scratch without CubeMX. CubeIDE itself is OK, it is Eclipse-based and makes its work. Starting a new project now, I think I will look for another options. If looks like STM moves in wrong direction.
I really like the ESP32s. The ESP-IDF is nice to code in - you can use fopen() and printf() and such, though I've had some issues with the SPI, but SPI works great under the Arduino framework with it. The achilles heel is it's kind of quirky and draws more power than some other offerings. However, again, coding with it is just great compared to the STM32, IMO. They are also powerful for an IoT device. The minimum configuration is single core, 360k or so of RAM and 4MB of NVS flash. A typical configuration has 520k of RAM and two cores. They have generous IO, with multiple SPI and I2C controllers, a ton of built in widgets including bluetooth and wifi, touch sensors, a magnetic field detector, ADCs (though a bit dodgy) and DACs, and all the pins are remappable in software. They really are fantastic little machines.
Real programmers use butterflies
-
First of all, regarding the requirement of using code generators and drag and drop widgets to "program" in C++, can we simply not? Whoever thought that was a good idea is currently at the top of my naughty list. I'm looking at you stm32CubeIDE. Tell me what the venn diagram looks like between people that code in C and C++ and people that want drag and drop heavy handed code generator "modules" they have to muck with in a weird IDE that you're suddenly tied to? Because I don't think the intersection is very big. This junk makes VB6 look streamlined. Also why does it have to be such a hassle to code ARM devices? I have two of them collecting dust because every single framework has something terrible about it that makes it unusable. All I want is to code in C++, in a framework people actually use, and one that doesn't take an hour ever time the firmware needs to be rebuilt. Apparently the people that write the toolchains for ARM find that to be too tall an order. I just don't get it. At this rate, I'm never coding for ARM Cortex-Ms.
Real programmers use butterflies
-
I absolutely agree! I tried using STM32CubeIDE while working with a custom board using the STM32 processor. The libraries were either horrible or non-existent. We ended up hiring an electronics engineer to develop a specific framework to use with the design of the board from scratch. I don't see how this IDE and framework are used in a professional setting. It's like it's designed to teach rather than produce.
"When you are dead, you won't even know that you are dead. It's a pain only felt by others; same thing when you are stupid." Ignorant - An individual without knowledge, but is willing to learn. Stupid - An individual without knowledge and is incapable of learning. Idiot - An individual without knowledge and allows social media to do the thinking for them.
Hello, I am using the MS visual studio (2019) with some external tools for compiling and linking. The tools are the .bat file invoking the GNU compiler. I am using the same construction also for the AVR processor. It is working good enough (after my opinion). The main reason to implement this system was to keep the same development tool for any application. If you need more details, contact me. Emil Motolici
-
First of all, regarding the requirement of using code generators and drag and drop widgets to "program" in C++, can we simply not? Whoever thought that was a good idea is currently at the top of my naughty list. I'm looking at you stm32CubeIDE. Tell me what the venn diagram looks like between people that code in C and C++ and people that want drag and drop heavy handed code generator "modules" they have to muck with in a weird IDE that you're suddenly tied to? Because I don't think the intersection is very big. This junk makes VB6 look streamlined. Also why does it have to be such a hassle to code ARM devices? I have two of them collecting dust because every single framework has something terrible about it that makes it unusable. All I want is to code in C++, in a framework people actually use, and one that doesn't take an hour ever time the firmware needs to be rebuilt. Apparently the people that write the toolchains for ARM find that to be too tall an order. I just don't get it. At this rate, I'm never coding for ARM Cortex-Ms.
Real programmers use butterflies
My experiences with ARM so far are very negative: Keil makes VisualStudio 6 look futuristic, stm32CubeIDE as you say makes VB6 look streamlined (and I have a decade of experience with VB6). Also the programmers (devices, not coworkers) suck, especially the Infineon line, and they try to scam developers with incomplete devices that allow for minimal debugging (limited breakpoints, no trace...). I much preferred the Renesas microcontroller, despite MultiIDE being absolutely terrible and buggy.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
People still use C++? *ducks*
Yes, of course. I will never try to write firmware in JavaScript... Actually, I prefer C.
-
First of all, regarding the requirement of using code generators and drag and drop widgets to "program" in C++, can we simply not? Whoever thought that was a good idea is currently at the top of my naughty list. I'm looking at you stm32CubeIDE. Tell me what the venn diagram looks like between people that code in C and C++ and people that want drag and drop heavy handed code generator "modules" they have to muck with in a weird IDE that you're suddenly tied to? Because I don't think the intersection is very big. This junk makes VB6 look streamlined. Also why does it have to be such a hassle to code ARM devices? I have two of them collecting dust because every single framework has something terrible about it that makes it unusable. All I want is to code in C++, in a framework people actually use, and one that doesn't take an hour ever time the firmware needs to be rebuilt. Apparently the people that write the toolchains for ARM find that to be too tall an order. I just don't get it. At this rate, I'm never coding for ARM Cortex-Ms.
Real programmers use butterflies
honey the codewitch wrote:
Because I don't think the intersection is very big.
Likely only a hand full, but never the main group. Do you think this is part of the push by the industry to introduce low-code environments? if they are aiming for the average joe to be able to put together a system on something that critical, they are out of their minds. Years ago (maybe a decade now) I developed on TERN system devices, basically x86 (186,286, and 386) single board computers with 16k flash. good equipment, very stable, but very little in board packages to support all the chips, so if you wanted to use that nifty CMOS, or general IO chips that were built into the board you had to write the code to run those data lines. It was a mixed bag because they did have code snippets for touchscreens and such. I liked their products and the IDE worked great with a JTAG debugger, the community was pretty limited though, but the company I worked for decided to not pursue that direction any longer. There goes 6 months of R&D, and it was so close to a finished product, just a few more weeks of testing. Oh well, I got paid all the same. I have to say I've never gotten into ARM development, it was always at the edges of the different projects over the years. Sorry to hear about the frustration.
-
honey the codewitch wrote:
Because I don't think the intersection is very big.
Likely only a hand full, but never the main group. Do you think this is part of the push by the industry to introduce low-code environments? if they are aiming for the average joe to be able to put together a system on something that critical, they are out of their minds. Years ago (maybe a decade now) I developed on TERN system devices, basically x86 (186,286, and 386) single board computers with 16k flash. good equipment, very stable, but very little in board packages to support all the chips, so if you wanted to use that nifty CMOS, or general IO chips that were built into the board you had to write the code to run those data lines. It was a mixed bag because they did have code snippets for touchscreens and such. I liked their products and the IDE worked great with a JTAG debugger, the community was pretty limited though, but the company I worked for decided to not pursue that direction any longer. There goes 6 months of R&D, and it was so close to a finished product, just a few more weeks of testing. Oh well, I got paid all the same. I have to say I've never gotten into ARM development, it was always at the edges of the different projects over the years. Sorry to hear about the frustration.
Part of it to be honest is I misunderstood the IDE. It's not *all* visual, it's just part of it where you do the pin layouts. Still, that speaks to a larger issue. I couldn't make heads or tails of the IDE. Give me VS Code and some build scripts/toolchain to use, you know? I'm not exactly green at development, but the IDE broke my 5 minute rule. I couldn't do anything at all with it in 5 minutes. Not because the tasks were non-trivial but because I couldn't even figure out how to begin. I wanted a main.cpp to start, with maybe some headers (or docs telling me the headers) It seems like that's a lot to ask of people these days. X|
Real programmers use butterflies
-
First of all, regarding the requirement of using code generators and drag and drop widgets to "program" in C++, can we simply not? Whoever thought that was a good idea is currently at the top of my naughty list. I'm looking at you stm32CubeIDE. Tell me what the venn diagram looks like between people that code in C and C++ and people that want drag and drop heavy handed code generator "modules" they have to muck with in a weird IDE that you're suddenly tied to? Because I don't think the intersection is very big. This junk makes VB6 look streamlined. Also why does it have to be such a hassle to code ARM devices? I have two of them collecting dust because every single framework has something terrible about it that makes it unusable. All I want is to code in C++, in a framework people actually use, and one that doesn't take an hour ever time the firmware needs to be rebuilt. Apparently the people that write the toolchains for ARM find that to be too tall an order. I just don't get it. At this rate, I'm never coding for ARM Cortex-Ms.
Real programmers use butterflies
Using code-generator frameworks has never been a feasible way of doing any form of coding, beyond the most simplistic of tasks. In the early 1990s (or late 1980s, I can't remember exactly), Oracle was one of the first companies to produce a sophisticated database application generator. It worked quite well. The problem was, that as the application became more sophisticated, the use of the tool became increasingly complex to use and at some point became less efficient to use than to simply code the application by hand with the use of supporting libraries. This was all the rage back then as a result of a tool called, "Magic PC", which promised the ability to create highly complex applications. Well, that didn't work out either... Promoters of such software have been at it ever since. And the new phase is "low code" software tools with prediction that it will take over a lot of coding tasks in the next 10 years. Sure it will... :^) Low-code software is the same thing that was peddled years ago but with the advent of newer AI tools (which they aren't in all reality), the hope is that such tools will finally make it into the mainstream. However, if you have seen the actual testing by scientists who work in Artificial Intelligence development and research, one finds that it our supposed AI makes a lot of seriously stupid decisions. But we are now supposed to believe that it will be able to create wonderful applications by assisting the Human coder? Sure it will... :doh:
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
-
Using code-generator frameworks has never been a feasible way of doing any form of coding, beyond the most simplistic of tasks. In the early 1990s (or late 1980s, I can't remember exactly), Oracle was one of the first companies to produce a sophisticated database application generator. It worked quite well. The problem was, that as the application became more sophisticated, the use of the tool became increasingly complex to use and at some point became less efficient to use than to simply code the application by hand with the use of supporting libraries. This was all the rage back then as a result of a tool called, "Magic PC", which promised the ability to create highly complex applications. Well, that didn't work out either... Promoters of such software have been at it ever since. And the new phase is "low code" software tools with prediction that it will take over a lot of coding tasks in the next 10 years. Sure it will... :^) Low-code software is the same thing that was peddled years ago but with the advent of newer AI tools (which they aren't in all reality), the hope is that such tools will finally make it into the mainstream. However, if you have seen the actual testing by scientists who work in Artificial Intelligence development and research, one finds that it our supposed AI makes a lot of seriously stupid decisions. But we are now supposed to believe that it will be able to create wonderful applications by assisting the Human coder? Sure it will... :doh:
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
Steve Naidamast wrote:
he problem was, that as the application became more sophisticated, the use of the tool became increasingly complex to use and at some point became less efficient to use than to simply code the application by hand with the use of supporting libraries.
I wrote something similar based around annotated XSD and ran into the same issue. I am a firm believer in code generation, particularly as time saving tools for fixed tasks, but not as a replacement for actual coding.
Steve Naidamast wrote:
However, if you have seen the actual testing by scientists who work in Artificial Intelligence development and research, one finds that it our supposed AI makes a lot of seriously stupid decisions. But we are now supposed to believe that it will be able to create wonderful applications by assisting the Human coder?
There's a funny dynamic here - one I love to study, that involves lots and lots of agents in a system, and how they operate collectively. This include human systems which themselves are rife with errors and stupidity. Furthermore although we don't notice it, our systems are always on the precipice of disaster, and yet nevertheless they persist - and *we persist*. The phenomena that give rise to this are covered in Complex Adaptive Systems theory which covers a type of non-linear dynamical system. In lay terms that means a system that **collectively behaves differently than its individual agents do** That last bit is so important. What it means is despite all the errors and stupidity, that too "feeds the beast" and keeps the system adaptive and vital - "alive". Evolutionary biology is another example of this, with imperfect gene transfer and imperfect gene expression playing the role of the errors that give rise to adaptation. I hope that makes sense. My point is in all this is the AI is doing exactly what it's supposed to do. The errors and stupid decisions are part of the process, and the system could scarcely function without them, since it too runs with a network of many many agents in a (simulated) complex adaptive system of sorts**. ** it's not technically this, but exhibits many of the same properties. like i said - simulated.
Real programmers use butterflies
-
First of all, regarding the requirement of using code generators and drag and drop widgets to "program" in C++, can we simply not? Whoever thought that was a good idea is currently at the top of my naughty list. I'm looking at you stm32CubeIDE. Tell me what the venn diagram looks like between people that code in C and C++ and people that want drag and drop heavy handed code generator "modules" they have to muck with in a weird IDE that you're suddenly tied to? Because I don't think the intersection is very big. This junk makes VB6 look streamlined. Also why does it have to be such a hassle to code ARM devices? I have two of them collecting dust because every single framework has something terrible about it that makes it unusable. All I want is to code in C++, in a framework people actually use, and one that doesn't take an hour ever time the firmware needs to be rebuilt. Apparently the people that write the toolchains for ARM find that to be too tall an order. I just don't get it. At this rate, I'm never coding for ARM Cortex-Ms.
Real programmers use butterflies
Since almost all the ARM projects I've worked on had small amounts of RAM and no ethernet or USB my framework was (retired 2 years ago) jEdit, gcc/g++ and make. Only the last ARM project I worked on before retiring had all the bells and whistles (256KB RAM, ethernet, USB, gp I/O, etc). For that project I used TI's Code Composer Studio (Eclipse based IDE).
-
The first problem is frameworks that are cluttered with crap that hardly anyone uses. Why? Because its architects are either clueless or actually think they're doing users a favor. There has to be a use case for everything in a framework. If it isn't going to be used as soon as it's added, it should only go in if there are likely-to-occur scenarios where it would clearly be useful. The other problem affects the whole industry. The hardware weenies do too good a job delivering faster processors, more memory, and more disk space. Thoughtless developers then piss it away because it's all good if it runs in less than an hour.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.I completely agree. 25% of the framework probably suffices for the bulk of the problems we're trying to solve. It's literally as if the framework architects don't understand SOLID. Developer: "I'm going to Antarctica on a scientific expedition." Framework (a.k.a. 'Mom'): "I've packed you some shorts and tee-shirts, in case you get some warm weather."
-
I completely agree. 25% of the framework probably suffices for the bulk of the problems we're trying to solve. It's literally as if the framework architects don't understand SOLID. Developer: "I'm going to Antarctica on a scientific expedition." Framework (a.k.a. 'Mom'): "I've packed you some shorts and tee-shirts, in case you get some warm weather."
Another problem with frameworks is that their surface-to-volume ratio keeps getting worse because of the unwillingness to deprecate anything, let alone make "breaking changes" that force users to update their code.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
Yes, of course. I will never try to write firmware in JavaScript... Actually, I prefer C.
Yeah, I know. I'm just messing. TBH I thought a lot of that is Java now though. Goodness knows why
