ARM and the framework disaster
-
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.In their defense a lot of the crap is for supporting hardware that the device has, even if you won't be using most of it (they don't know in advance what you will use) - but the ESP-IDF has a "menuconfig" script that will remove headers for components you aren't using to shorten the compile times. IoT doesn't suffer from the "free lunch problem" you describe. Every cycle and byte counts. You're dealing with 80kB of RAM and 256kB of non-volatile flash program space and that's being generous. Some have far less.
Real programmers use butterflies
-
Are you using Azure Resource Manager scripts? I found the Azure CLI to be a lot shorter and more readable :D Seriously though, we're running out of abbreviations and this one always gets me :doh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Oh heck no. ARM processors. :)
Real programmers use butterflies
-
Oh heck no. ARM processors. :)
Real programmers use butterflies
I know ;)
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
In their defense a lot of the crap is for supporting hardware that the device has, even if you won't be using most of it (they don't know in advance what you will use) - but the ESP-IDF has a "menuconfig" script that will remove headers for components you aren't using to shorten the compile times. IoT doesn't suffer from the "free lunch problem" you describe. Every cycle and byte counts. You're dealing with 80kB of RAM and 256kB of non-volatile flash program space and that's being generous. Some have far less.
Real programmers use butterflies
Maybe that'll be the blessing of IOT, that those who work on it will learn to think about performance.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
I know ;)
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
I always assume you're messing with me, but I reply as though you're not just to mess with you. :)
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
Never thought C++ was usable for developing UI's. I use C# and VS compiles my packages to ARM, ARM64, x86 and x64.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
-
Never thought C++ was usable for developing UI's. I use C# and VS compiles my packages to ARM, ARM64, x86 and x64.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
I seriously doubt it runs on an Arm Cortex-M0 with 80kb of RAM and 256kB of flash. ARM Cortex-As are a much different animal. They're basically fancy smartphone or surface PC CPUs.
Real programmers use butterflies
-
I seriously doubt it runs on an Arm Cortex-M0 with 80kb of RAM and 256kB of flash. ARM Cortex-As are a much different animal. They're basically fancy smartphone or surface PC CPUs.
Real programmers use butterflies
-
Building ships in bottles.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
My smart watch is a ship in a bottle?
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
People still use C++? *ducks*
-
Maybe that'll be the blessing of IOT, that those who work on it will learn to think about performance.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.Its because we have to think of performance, cycles, milliamp hours, that I choose to play with uControllers. Protected mode made the x86 landscape considerably less fun. Pre-emptive multi-tasking? Meh, why even bother anymore! I'll just play games on it. :-\
-
Its because we have to think of performance, cycles, milliamp hours, that I choose to play with uControllers. Protected mode made the x86 landscape considerably less fun. Pre-emptive multi-tasking? Meh, why even bother anymore! I'll just play games on it. :-\
I don't want to worry about cycles or milliamp hours. But I'm pretty much with you on the rest. :) Well, except that I rarely play games.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
People still use C++? *ducks*
*sideeyes you* :suss:
Real programmers use butterflies
-
*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.
