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
I recently bought myself one of ST’s cheap Nucleo development boards with an STM32F072RB controller on it to quickly start developing one of my projects. The microcontroller has native USB support even without an external clock which makes it quite attractive.
The downside is that this board does not come with a USB connector that can be used by the controller itself. The USB connector on it is already used by ST’s own programmer (ST-Link). You could of course rewire the port to the microcontroller directly – but then you would lose the connection to the ST-Link and had to connect an external programmer.
So I came up with another solution: I just glued a straight (180°) THT mini USB connector to the bottom side of the board and wired the USB-D- pin to PA11 and USB-D+ pin to PA12. Luckily both pins are not already used on the board and are easily accessible since they are routed to pin headers. USB GND (and shield) must also be connected to GND. You can see the little hack in the following picture. The same hack can probably be done with all Nucleo boards that provide a controller with USB support. Maybe someone finds this useful. 😉
This is a follow-up post to my previous project page Part 5 (PC software).
This is the last post concerning this project. I have done some tests with the final hardware and software. Furthermore I have written a small conclusion to this project.
An interesting test is the transient response on a sudden change of the setpoint current. In this case I stepped the setpoint current from 2 A to 0 A. The following picture shows the voltage across the shunt. You can see a voltage drop of 200 mV (corresponding to 2 A) within a time span of around 20 ms. The time could be reduced by decreasing C18 and C21 in the schematic. The latter one should be adjusted carefully because a too small capacitor may destabilise the control loop.
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.
This is a follow-up post to my previous project page Part 2 (Hardware design details).
In this post I briefly present the full schematic and PCB layout of this project. As a proof that I actually built this device, there are also some pictures included at the end of the post. 😉
Full schematic and PCB layout
The schematic and layout has been drawn with KiCad 4. The full schematic is attached below (as PNG image, PDF and KiCad’s native format). The layout is not depicted in this post, it should be opened with KiCad directly for clarity.
You can also find the latest version of the schematic and the PCB in my GitHub repository.
Pictures of the finished device
Read further on as I describe the firmware part of the project in part 4.
This is a follow-up post to my previous project page Part 1 (Requirements).
In the last part I laid out the requirements and specifications of my active load without going too much into detail. This is about to change while I write about the different implementation details.
The main task of the active load is – of course – to dissipate power. This can be done by any device which has resistance. The simplest load is just a resistor but the problem is that a resistor usually has a fixed resistance which makes no sense in an active load. So we need a device which can dissipate (a lot of) power and has a controllable resistance. This can be done with a power transistor or in this particular case with a power FET. The idea is to control the gate-source voltage in order to influence the drain-source resistance. The device under test is just connected to drain and source.
This time I would like to write about a project of mine: A (simple) active load with support from a microcontroller.
There are times when you need a dummy load to test and validate some equipment or part of a schematic, e.g. a power supply. In the past I just used some power resistors as a load but this solution is very inflexible. Often you don’t have the right resistors at hand or you must switch resistors when you want to change the simulated load.
It would be nice to have a simple and cheap active load which solves the above problems. My design approach relies on the great Re:load 2 project by Arachnid Labs. I added a STM32 microcontroller with USB support and LCD to my own design. This way I can use my active load as a standalone device which shows me all important pieces of information on the display. Or I can connect a computer via USB to the device and let the PC control and monitor the simulated load.
Here are the requirements:
- Power supply from around 3.3V to 40V
- Should be powered by device under test
- Alternative power supply via USB
- Maximum dissipated power: Around 12W permanently at room temperature
- Maximum current: 3A
- Robust (protected from overvoltage, overcurrent and overtemperature conditions)
- Device under test should be connected via banana plugs or screw terminals
- A PC should be able to monitor the actual current and control the desired current via USB
- Small display to monitor actual and setpoint current
- Rotary encoder to change setpoint current
- Small (5×10 cm)
- Measure temperature at heatsink
Read further on as I write about the hardware design details in part 2.
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”