I recently came up with the idea to write a clean template project for creating new STM32F4-based projects. The effort to create new firmware projects should be minimal while still maintaining maximum control and transparency over what happens in the build stage. Continue reading “A clean CMake-based STM32F4 template for kickstarting new firmware projects”
If you want to develop your own embedded hardware, you often need a communication interface to a host, usually a PC. In times where the classic but easy-to-handle RS232 interfaces are no longer standard components in modern computers, you basically have two options when it comes to wire-bound connections:
- Use a USB to UART converter chip in your device
- Go for native USB support by using a controller which has a USB (device) subsystem on board
This is a follow-up post to my previous project page Part 4 (Firmware).
One way to interface with the active load device is to use a terminal program and query the state of the device or send commands to it manually. But this is of course very cumbersome and not very user-friendly. That’s why I have written a program called Active Load Tool in C# for Windows.
The setpoint current can be changed and all relevant pieces of information can be monitored. Furthermore the tool allows to calibrate the device and plot oscilloscope-like graphs visualising current, voltage, power and temperature.
Actually I have separated the program into two different projects: ActiveLoadProtocol and ActiveLoadTool. The former one is a class library which capsulates the interface between application and device, while the latter one depends on this library to present a GUI to the user. The class library can easily be used in own projects, for example to automate and log test runs.
You can find the source code of the software (project written with Visual Studio 2015) in my GitHub repository.
This is a follow-up post to my previous project page Part 3 (Schematic, layout and pictures).
At this point the hardware development is finished and fortunately nothing blew up as I had plugged in a voltage source for the first time. 😉 But of course there is no functionality yet. The load sinks (nearly) no current which is a good sign because all port pins of the microcontroller are in a high impedance state while there is no firmware on it. That means the setpoint current and also the actual current of the current control loop are (nearly) zero (the opamp input “sees” ground). This is considered a safe state as nothing bad can happen in this case: no functionality – but also no potential to destroy something.
I recently needed to write a special bootloader for the STM32 controller. One requirement was the ability to explicitly start the bootloader from the application. In this case the bootloader stays active until the next power cycle or when a firmware upgrade has been successfully applied. Continue reading “Howto: Remanent data after microcontroller software reset”
I recently developed a protocol agnostic driver library for HopeRF’s RFM69 modules. Protocol agnostic means that you get full control over the module and the data packets that you want to send or receive. You can use this library for receiving packets from existing commercial devices like temperature sensors, or you can set up your own RF network using your own protocol. Continue reading “RFM69 C++ driver library for STM32 (and other controllers)”