Course code: WEB-33
Years with company:
Primary programming language:
Other programming languages:
C++, Assembly, Python, Matlab/Octave.
Unit test harnesses:
I am a micro-engineer specialized in robotics, and my main area of focus has been the miniaturization of autonomous systems. Therefore, I have a shared background in electronics and in software which I have found to be useful when delving into embedded software.
Following my MSc, I have worked for a few years on nano-satellites and have been interested in the development of embedded electronics + software.
I have then pursued a PhD in robotics and autonomous systems. Over the course of my thesis, I have tackled the development of integrated control for a small sensorless piezoelectric actuator. I have also had the opportunity to develop automated test environments for this type of actuator.
Since then, I have returned to the world of embedded electronics and software by joining Astrocast as an embedded software engineer.
Test practice now:
After having written a code following a phase of planning, I write unit tests for the code and try to cover the possible outcomes of software units as extensively as possible.
Nano-satellite subsystems powered by constrained hardware with space flight heritage (TI MSP430, some STM32 architectures). Used to working against code size limitations, to favoring deterministic behavior, and efficient CPU/memory usage tradeoffs.
Git, IAR Embedded Workbench, Visual Studio, Visual GDB, GCC, Logic analyzers, Oscilloscopes, Matlab
In addition of halving delved into automotive MISRA-C and DO-178B standards, I try to keep to these principles:
- No dynamic allocation
- Deterministic behavior
- Code abstraction where appropriate
Function too long:
Generally, a function is too long if it:
- Is using logic that is present in other functions
- Has control loops / structures that span several levels
- Attempts to do more than one thing at once,
- Has an unclear purpose
They are usually only done when examining pull requests to the main development branch following the development of a feature.
Favorite thing about dev:
I genuinely like seeing complex embedded systems coming together thanks to soundly developed software.
I enjoy tackling challenges of code size restriction, execution optimization, efficient memory usage, and execution reliability.
Least favorite thing about dev:
I don't like spending whole afternoons hunting bugs that are caused by minute mistakes in code implementation !
I am somewhat aware that increasing testing and appropriately planning for it will greatly reduce the amount of time wasted chasing bugs. It is my understanding that tests should be written before even the code itself, not the other way around.
Why are you attending:
I always feel like there is a lot to learn in this trade, I want to know how to be more efficient with my time.
I am also genuinely curious to know if there are possibilities of testing with hardware in the loop.