Sometimes I want to watch the price development of a product in different online web shops over some time. My intention is to compare prices and to find a point in time where the product gets cheaper and therefore more interesting to buy
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.
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 stumbled upon a problem which I thought could be easily solved when I wanted to do design a PCB with an unusual board outline (e.g. a star-shaped board).
Since I am not such a great artist when it comes to painting or drawing, I downloaded an .svg file of the shape from Wikipedia and I thought it could be easily imported in KiCad. But this is apparently not possible using a direct approach (at least not up to version 4.0.3 at this time of writing). KiCad only supports .dxf files as of now. So you must first convert from .svg to .dxf.
After some searching on the internet and some frustrating experiences later (e.g. the shape dimensions were extremly off after importing), the following workflow seems to do the job:
- Open the .svg file in Inkscape and adjust the shape to your needs. That means cropping and more important scaling it to the size of the board outline. Use real dimensions like “mm” and not “px”. Set the dimensions in the document settings.
- Convert the object to a path (Inkscape: Path -> Object to path). I don’t know if this is really necessary in all cases.
- Save a copy of the file using the .eps file format (Encapsulated PostScript). Use the default settings.
- Get the nice little tool pstoedit.
- Convert the .eps file to a .dxf file using the following command line: pstoedit -dt -f "dxf:-polyaslines -mm" shape.eps shape.dxf where shape.eps is the source file from step 3.
- Finally you can import the newly generated shape.dxf file in KiCad’s Pcbnew.
This approach does not only apply to the board outline, but you can also use this technique to import shapes for example to the silkscreen. Just select the desired target layer in KiCad.
I hope someone finds this helpful, at least I think you can do a lot of cool things with custom shapes. 😉 Maybe some time later this post will become obsolete when KiCad eventually gets support of native .svg imports.
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.