My customer, after all, is paying for (say) an STM32 project with a boot loader and some reserved Flash memory for persistent configuration settings - not three weeks learning where to put the dots in the right place in a linker script.
On the other hand, once you have done it a few times, you start to understand how it works, and after that, something great happens:
gcc, ld and make (and gdb, but I don't use debugger very often) have been there for decades, and there are no signs whatsoever that they would be phased out in the MCU development; quite the opposite, everybody seems to be migrating towards them (as a backend).
Now,
if you know how to use them directly, you are free from the confusion caused by:
* Multitude of totally differently working IDEs depending on which product family you end up with
-> knowhow of direct usage of GNU tools allows you to better jump between families
* Changing "this years trend IDE" culture
* New versions working differently to the old ones
* Front end bugs
* Front end doing things people "usually want" behind your back
I admit this is kind of idealistic and simplified goal, but I took the bullet and am
very happy right now that I did.
The one guy who recently did the
massive and totally awesome comparison of sub $1 MCUs of 2017 got me thinking: there must be a better way.
Most of the article was comparing how the development flow of writing C code goes in different product segments even though it was basically all doing the same job: writing C code. Today, we depend too much on code generation and tools that assist typing, when we should concentrate on creating
high-quality code, including high-quality headers, libraries etc. that solve the problem on the source level (C is good enough for that, really!) instead of interactive text editing level.
So really, I feel like this is an issue where:
* Direct, raw use of the backend tools have a steep learning curve, but it really gives valuable experience, and it
really gets easier after that (I'm surprised at this myself):
+---------------------------
|
|
|
|
|
|
|
|
----+
* Using them through IDEs softens the learning curve quite a bit, but then you need to keep learning new IDEs, new details about them, and, worst, each time something doesn't quite work out automatically, you are yet again looking for help how to solve it through that IDE.
+------------
|
+------------
|
+------------
|
+------------
|
----+
Yes, I fought about half a year to get the understanding how to use the backend tools directly and separately.
But after that, it has been extremely simple, in fact, FUN, to do things people often consider difficult, like building custom bootloaders, utilizing secondary scratchpad memories, relocating vector tables, doing persistent flash storage, etc., all without help of device-specific libraries or device-specific tool documentation. In fact, if I had to do it the way people "usually" do it, I have no idea where I'd even start. There is no standard way. The way I do it is closest to universal, and anybody can modify the code and just run make without configuring anything, without having to install and learn the right "development environment".
The funny thing is, all the pain and agony I went through could be
easily fixed just by writing some basic tutorials, with simple examples. But since very few people are seeing it from the same viewpoint as I am, no one writes it (except that Swedish Ubuntu guy who made it too complex and had it completely wrong
. Still, I'm very grateful). (It's worth noting there never was any issue with the actual installation of the tools; my source files were faulty since I had no idea how to do them - but now I have. It's great when you don't depend on the actual tool installation being right, but everything is contained in your actual sources as much as possible!)
But everyone writes tutorials on what IDE buttons to click - which should be something not needing an explanation at all if the IDEs were properly designed to do the job they exist for - be an user interface to soften the backend usability.
--
Today, my customers are paying for experience, so I want to gather even more of it. After being a hobbyist for a long time, I started at very low hourly rates, barely getting something to eat, in non-time-critical projects, gaining experience, compensating for the fact that sometimes I was stuck, maybe for weeks, learning how to do it in a sustainable way, instead of just doing a "quick solution". Now I consider myself "mid-experienced". I'm starting to see the extrapolation that after a few years, I can provide very quick, flexible services exactly because of the experience and knowhow, relying on any specific tool as little as possible - I never want to be a one trick pony. (OTOH, you have to rely on something; but I find it's
much more sustainable to understand and memorize a few common gcc flags, than to understand what hidden buttons to click in a this years favorite IDE to achieve the same, or to depend on code generation tools, which tend to be seriously broken year after year.)
But I understand very well that talking about steep learning curves and giving promises like: "it will get easy after that big mountain!!" is not motivating. In school we were learning the German language, and our teacher mostly wanted to focus on all the details of grammar, making it sound more complex than it really was, and people didn't like it. We were given motivational speeches roughly like this:
"After
this grand grammar hurdle, it gets super duper easy and we'll have fun speaking German fluently and everybody's singing and dancing in class".
But when the same pattern repeated year after year, we realized that the fun times weren't coming, the "big mountain" was always in the front of us, again and again.
So I promise, going without any IDEs will get easy, unlike our German classes! Trust me
..... or maybe just follow the majority and forget about what I'm doing. Maybe I just like to work differently.
Home
Help
Search
Login
Register
