Why even consider switching from C++ for embedded UI SW development?
History
In the past, when the hardware was much more limited than today, the software for that hardware was a monolithic binary containing everything. The (embedded) OS, the drivers and the application itself. The embedded operating systems evolved and introduced things like multi threading or something in the middle of threads and processes. At that stage hardware resources were the biggest constraint so that switching from C to C++ was considered a crazy step. All those virtual tables that eat up RAM and ROM! At that time the applications were rather simple. No complex UI flows or things like content that can be downloaded by the user.
As the decision to buy a MacBook has settled the next step was to select what MacBook to buy. Normally I like to have a notebook in the 13” range as it is portable and when used at home I always connect an external monitor to it. My previous device was a Microsoft Surface Pro 6 so I was quite used to such a screen size and didn’t need to change it.
The keyboard
There is one problem with the MacBooks that was very prominent in the media: The butterfly keyboard seemed not to be the best decision Apple made. So it was clear to me: I don’t want to get a MacBook with a butterfly keyboard. This ruled out all 13” Models before 2020 and all 15” models. So the available options were: 13” 2020 or 16” 2019. The 2019 MacBook is roughly half a year old so it can be bought at some discount. The situation for a i7-10, 16GB RAM and 512GB storage device was that the 16” costs 100€ more than the 13”. I also noticed that the reviewers mentioned that the 16” has a redesigned cooling system that works much better than the old one and that the 13” sadly doesn’t have this improvement. Another thing that I’ve seen in the news is that the 13” has some USB 2.0 problems. So I decided to go with the bigger device because it promised more power. Having a dedicated GPU can’t hurt, right?
Having the perfect machine for development and also for stuff I’m doing besides development (Web browsing, online banking, Netflix, …) is always a thing I strive for. As most of you will do. A special thing about the “dev machine” (and also about my mobile phone) is something that is very hard to explain, but I will try nevertheless.
The social factor
I always try to have a setup that is achievable by “normal” people. Being gifted with a hobby that I’m quite good at that I can do as a full time job and is also payed very well I can afford almost any setup (dev machine, mobile phone, infrastructure) that I want to have. But I always try to find the best setup that is not dependent on having much money to spare still considering things that are important to me like privacy and robustness.
This is my nth attempt to start something like a blog. The last attempts all ended with me not writing anything. This time I try to force myself to do so every week.
Regarding topics here I think you can expect mainly software development related stuff. Embedded SW development (If this can be called like that nowadays), .NET stuff, Android development and whatever is engaging me currently.
My name is Michael Lamers (also known as Devmil in the internets) and I work for B/S/H/, a Bosch company creating household appliances of different brands. The most known ones are Bosch, Siemens, Neff, Thermador and Gaggenau. My job is defining the SW architecture of the UI software in those appliances. I also work in the UI Framework team providing all those UI projects a basis to create their UI software on. As a technology stack we use C++ and Qt but even after 10 years of doing C++ I still don’t like that language. It is messy, error prone and leads to very long development cycles (change - build - test - repeat takes really long) So a hobby of mine is to look out for alternatives that we might be able to use at work.
We recently moved to Linux as operating system which opened a huge door for alternative technology stacks. At our current stage we are still very limited in hardware resources so currently most of the alternatives have no chance because of the size of the compiled binary + the framework needed to run it.
