Embedded Software Engineer

I'm a quality evangelist, open source activist, and a full-time consultant. I’ve designed and written software for the Brazilian industry in PoS, Power Quality Metering and Home Automation fields, dealt with embedded Linux, distributed IoT and complex mathematical algorithms, from big companies to startups. As open source contributor, I maintain a recently launched framework for real time event-driven embedded systems, called react.o.Currently I'm full time consultant. I apply test-driven development, continuous integration, a bit of agile processes and the state of the art approach for software development whenever possible. Believe these are fundamental tools for achieving increased team performance as well high quality products on any medium to complex project.In most cases, the project risk is all about software, that’s where Quality and I fit into.


's contributions
    • Taking the closely related matter of C being obsolete, I'd like to express some thoughts. We need, as business, a fastest language than C and C++ do develop, there's a lot of money wasted on reinventing the wheel over and over again. But as engineers, we find hard time relying on highly abstracted languages such as Python, Java, C#, etc. There's rust and its safety promise that will be of great use on micro-controllers, but Mozilla is not interested in porting it to small processors yet (also it has just left beta) Java tried, years ago, to bite the embedded market but didn't find traction and I don't really know why. There's also a ton of choices if you are running embedded Linux, yet, C is still used. Think about Assembly, it was replaced by C, but it is still used in corner cases. GCC has made incredible achievement of being compilable for a huge number of architectures (like, every one human kind invented?), any other language will find porting difficulties. Also, the MCU libraries (register and peripheral abstractions, etc.) are written in C. So, the next system language shall be compatible with C the way C is to Assembly, be compatible to every existing architecture and existent ecosystem, low level and at the same time modern (easy to use with Generics, Closure, Asyncs, Smart allocation, Objects, etc.). Ops! There's one language almost like that! Its C++, except that decades ago it took a wrong turn and went into the hacker land (complicated to the point that if you use it wrong, you'll blow your head). If I could I'd create a language that is a C# subset 100% compatible with C. Like Vala, but it would have its own standard library. Ok, talking about data: 2016 Barr Group Survey shows 75% adoption for C, 20% C++ and 1,5% C#, as the first 3 languages mostly used in embedded systems (don't ask me why C# is the third and Python is 8th, I'd never expect that.) Seems that engineers are being forced to tame the C++ monster.

    • Michael, It's been 4 yrs since you wrote this article. How would you update the "Trend 2: Complexity forces programmers beyond C."? There's a language called Vala, that generates C code, it cant run on bare metal embedded since it has dependencies. Anyway, do you still believe this kind of approach might get traction?

    • Only a small errata on the opaque convention: - Whenever I say `opaque pointer`, consider `void pointer`. A void pointer is a kind of opaque pointer, not all opaque pointers are void pointers.

    • Rick, that was fan to read, thanks! About the matter, I believe you lost this battle. The MiB is silly, I agree, I kinda fill embarrassed when I use it, but there's no way we can rollback people's head, such as we'd do with a git repository. There was a lot of energy spent due to the confusion in the MB concept and now that it's got the "solved" status, it is gonna be hard to revisit the matter. I confess when I say Mebibyte in public it feels like I'm in the kindergarten all over again. I prefer to pronounce "mibs" and "kibs", at least it sounds like food in Portuguese :)