I'm now a Software Quality Engineer at Qteal!
In may I accepted an offer from Qteal to start in October. You can find more information about the how/what/why of Qteal on the website.
I picked Qteal because I appreciate the atmosphere and because I'm fascinated by the teal concept.
While I'm not actively looking for new projects or jobs, you can contact me about projects.
I will discuses them with the rest of the company. We are always open for new opportunities.
I created a Proof of Concept of a voice controlled ESP32 demo board.
Once again I got invited to "play" R&D Engineer at E.D.&A. this summer. This time to help them evaluate the
ESP32 as an hardware platform to build connected devices on.
Part of the assignment was to create a demo with voice assistant integration. The targets where Siri (Apple Homekit), Google Home and Amazon Alexa.
I confirmed that the ESP32 is a lot more stable than the ESP2866, and it's programming library is very usable.
It might even be good enough to serve as the only processor for simpler applications. Of particular interest
was the ability to update not only the firmware of the ESP but also that of another micro-controller.
After that I researched the required steps to create voice assistant controlled devices.
Unfortunately for Apple, they close off their program and didn't manage to reply within the assignment time frame.
The communication between the voice assistant clouds is handled via MQTT.
For Google Home I used an existing product called gBridge, for Amazon Alexa
I created my own version that runs on Amazon AWS Lambda with some extra server infrastructure.
The included diagram shows how I would implement a device that is cross compatible within multiple assistants.
From that diagram I only implemented what was required for the minimal viable product. Namely it only supports
Alexa (because gBridge covers Google Home), limited user and device management, and has no status updates
from the device to the cloud. That last one is required to get approval from Amazon (and Google Home) to widely
deploy your application.
A super short (30 second) demo video.
Post on LinkedIn and on the
I did my thesis around the benchmarking of FPGAs. More details can be found here.
With this thesis I graduated cum laude from my Masters at KU Leuven.
Functional software tests running on real hardware.
I was asked to come back to E.D.&A. once again to setup a Raspberry Pi based Hardware Test Farm.
The (simplified) idea is that the hardware abstraction layer simulates the hardware conditions based in input from the python tests, and sends back any changes to outputs or internal state.
This means the layers above the HAL can be automatically tested with as little changes from the production version as possible.
The testing framework was already in use, but was not automated or Linux compatible.
I created a mostly automatic setup for the Pis, along with some improvements to the test framework.
Several hardware setups where initially added to serve as examples for later additions and to find as many possible issues as possible.
One oddity I'm particularly proud of solving is the way the iMX6 platform is handled.
Due to the flashing software required for the setup not having Linux support, I designed an alternative way of loading the software.
The bootloader from the project is designed to load updates from an installer/servicemen's USB key if present.
I decided to try to emulate one with a Raspberry Pi Zero Wireless, which worked beautifully after some tinkering.
Since the Zero doesn't have a USB hub chip on board, the USB bus from the SOC is directly accessible.
This in combination with some scripts and the Linux USB Gadget driver makes the Zero Wireless the ideal automatable USB key.
All of the Pis are Jenkins nodes, and thanks to the Jenkins Pipeline system they are generic.
This means if multiple projects share the same CPU, they can usually share a hardware setup.
Thanks to a colleague's CNC skills it also not only looks neat, but the setups are portable.
So if there are issues, developers can just go grab the box from the farm, put it on their desk and debug away.
From the internal newsletter:
E.D.&A. gets a Test Farm
E.D.&A. already successfully employed Jenkins for building and monitoring the quality of code and MISRA compliance each night. These past weeks Dries Kennes has extended our Continuous Integration (CI) setup with a Test Farm. This allows us to automatically run functional tests on each platform as part of our CI pipeline to ensure the quality of our code and detect any issues as soon as possible. The Test Farm Dries created consists of a generic solution using Raspberry Pi’s, which can program our targets with the latest firmware and run Python based tests on target. Due to the generic nature of the Test Farm new and old platforms and projects can be added.
Post on LinkedIn.
I'm now the proud owner of a 3D printer. Build from an FLSun I3 kit. I can print 300x300x400mm, in dual color/material when my dual extruder kit arrives.
I plan on creating a separate page/site for 3D printer projects, for now I'll add links to the 3D printing sites I create profiles on in the section on the side of this page.
I plan on creating timelapses with a Raspberry Pi camera module, but I have not gotten around to setting it up yet.
Once I fine-tune printing profiles and firmware configurations (for Marlin) I plan on publishing them. Along with any 3D models I design and decide to open source.
More news/updates to come :)
An SQA system with VisualSVN, Jenkins, Parasoft C++Test, & Python.
After finishing the follow up of my Bachelor's Thesis project, I was asked to (attempt to) setup an SQA server. This system would use Jenkins to automatically run Parasoft CppTest.
First I made the Jenkins 'build' script in Batch, but I kept running into issues, so moved to Python. This allowed for much more flexibility, so a Python module was developed. This means most of the common functionality could be shared between different jobs without losing configurability.
The static analysis plugins in Jenkis are able to parse the Parasoft Report, and the email plugin could be made to get data from it. This meant emails send out (when there are Parasoft warnings) contain references to the file, line number, revision number and likely culprit.
Eventually the project scope was extended to include a hardware testing setup. This involved programming a board and running a python unit test module. The major issue with this is that it's not possible to specify what programmer device the programming CLI tool should use. To remedy this, I extended the Python module to include an API to a third party Device Manager (DevManView) that has a CLI. This allows a Jenkins job to make sure it's talking to a specific piece of hardware.
Another interesting item was VisualSVN. Internally E.D.&A. was using SVN on file based repositories instead of using a repository server. This was a problem for Jenkins, which refused to clone repositories on a network share. After some research I proposed VisualSVN Server, since it's easy to manage and allows for domain user integration and repository replication.
SVN is also used for select clients to share documentation and libraries or application code. With VisualSVN this was all integrated into one smooth setup. Because of security concerns and company policy a secondary instance was setup on an externally accessible VM, with it's own list of (non-domain) users. Because of the replication capability, internal developers can use the same repository server for both internal and external repositories.
This project was considered a complete success by the project managers, some of the developers may be less enthusiastic when they look at their email in the morning to find a list of violations :-)
Update: I helped them move the setup to permanent (and stable) Windows Server machine. The SVN server was separated out to make it less dependant on system load when a Jenkins job is running. The schematic has been updated.
Android on iMX6ul
My bachelors thesis is with E.D.&A., the details are not publicly
available but it's about running Android on OEM embedded platform powered by an iMX6ul.
Update: This project was extended as part of my summer student job.
It became clear that, even though running Android is possible on the platform, it is not fast enough for commercial applications.
I've become a hobby brewer with a website!
The website was made as part of a school project, its a Docker composition with
- LetsEncrypt (although that's not running in production since I have a wildcard cert)
- Flask (python 3)
The site is meant to be easily forkable and near instant deployable.
It features a full user management system, markdown enabled posts, email notifications, ...
Every beer/brew/batch is its own little micro-blog, with a main page and posts. This allows for follow-up that's easily visible. There are also separate pages, such as the ToS or the homepage.
The website. Source on Github.
Properly export your KU Loket roster to an iCal file.
I made this page because the existing tools became useless after the KU Loket roster layout changed.
All the existing tools used HTML parsing to figure out the roster, and thus the slightest changes rendered them useless.
My version uses an (internal) json API to retrieve data, that you then paste in a textbox.
(Due to cross site scripting protection I can't pull it directly, security is important!)
(Another thing I disliked about the existing pages.)
KUL To iCal
A simple, private, expendable url shortener service.
I needed dynamic QR codes. The existing solutions are sometimes rather expensive or limited, so I made my own.
It is a simple, PHP-MySQL bases system with an HTTP/REST API.
The "users" (or rather API keys) are just added by hand via PhpMyAdmin.
The full schema.
Based on an existing ESP Altium library and custom parts, all available on Github.
This PCB includes:
Space for the ESP-12-E. (ESP-12, ESP-12-F, or ESP-14 should also work)
- Breadboard friendly spaced headers for all 'usefull' pins.
Headers (on top) for UART.
Headers (on top) for Flash Quad-SPI.
- All the required pull resistors and filter capacitors. (smd or through-hole elcos)
- reset switch.
- programming switch (GPIO 0), also has an extra LED.
WS2812 RGB LED (GPIO15), with Dout pin also broken out. (Pick between 5v and 3v3.)
- 5v to 3v3 regulator.
- 7 x 5 Prototype area with GND, 5V, and 3v3 rails and GPIO4, 5, 12, 13, and 14 pins.
- Silkscreen for all of it.
Solder bridge for GPIO16 and reset. (For MicroPython's Deep Sleep)
An FPGA based Z-Machine implementation, written in VHDL, made for Basys3.
The Z-Machine is a virtual machine for text based adventure games.
Too much work to finish for the school project, and lack of interest to finish. I ended up reusing a lot of the code for a mini-casino (it just has roulette and high-low) and it was more then enough to get a good grade.
All source material is on Github.
A Raspberry Pi Zero based 'smart' alarm clock.
It uses your Google Calendar to get your earliest appointment and your preferences to pick an ideal wake up time. We learned a lot about Python and Linux Kernel Modules.
This project ended up taking more time then we had, our PCB's arrived 2 days after the presentation (due to some issues with DHL), so we never assembled the final version. The presentation used the prototype shown above.
The accompanying report (in Dutch) is available here.
All source material and more pictures for this project are on Github.
There is also a (Dutch) website we made (it was a requirement for the course), available here.
A clone of the game Mastermind that uses a 96 RGB LED display to display the board.
It runs on a combination of an ATMega128A and a Beck IPC SC12. The SC12 provides the (Ethernet based) web-interface and game logic. The ATMega drives the WS2812 LEDs and LCD. They communicate via shared Dual Port RAM.
This setup is based on a development board called RIOT made by MGM and [dp]. The hardware largely remained the same, though I did redesign the PCB.
One of the hardest things about this project was the old hardware. The SC12 was more then 15 years old when I started. Since its a 16 bit DOS like system, most compilers for it run on 16 bit DOS systems. 64 bit Windows doesn't support 16 bit apps anymore. I tried a few things, including DOSBOX but ended up making a build script that uploads my code to my old Linux server, compiles it via an SSH session, and then uploads the result to the SC12 via FTP, then it reboots the SC12 via Telnet.
The accompanying report (in Dutch) is available here.
All source material and more pictures for this project are on Github.
There is also a (Dutch) website I made for my HTML+CSS+JS course, available here.
An assembler/IDE for 8051 asm files, written in Java.
It can compile and decompile to and from hex files, while showing you the steps in between to allow easy debugging.
I made this program because there are no programs with a modern, not cluttered, interface that met my needs. I needed the assembler to flawlessly read files written for Rigel51, as many of the files used in my school where written with that program.
The entire project, including a .jar release is available on GitHub.
This project also can upload the compiled hex files to the XC888 via serial (or usb-serial) cross platform.