I wrote a short page about the snow flake project from end of 2017. On the page you will find a summary of the project and the link to the repository with all the required files. Everything is open source, including the design files for the hardware and a base version of the firmware for […]
Author / Lucky Resistor
Recently I received boards for a sensor array from PCBWay. This boards were made in a very good quality considering the low price level. I really like the green solder mask they use, it creates a nice optical effect shifting the green colour towards yellow somehow. The solder mask produces a very nice contrast between […]
Sadly there is a ton of badly written code out in the wild. Hardware related code, seem to suffer more in this regards. I imagine, many developer in this segment are unwillingly to invest time in quality or are just inexperienced.
Even if you are dedicated in reliable and high quality code, you will probably run into the situation, where you have to use a library with really low standards.
There are a number of strategies to deal with this code:
- Rewrite the library.
- Refactor the code.
- Wrap the library.
- Wrap the interface.
Rewrite the Library
This is actually the best you can do and it is also the most time-consuming approach. Yet, write the code from scratch will give you several benefits:
- You will perfectly understand how the original library and the accessed hardware works. Actually you have to understand it, otherwise you are unable to rewrite the code.
- The new code will be modern, fast, reliable and in your coding style.
- If you open source the new code, you will give people an alternative and a better example how to implement something the right way.
- You can also selectively remove unwanted/bloated parts from the original code, which can reduce the overall binary size of the final project.
- It will also give you the option to implement a proper error handling in the new code.
If you have the time and motivation to rewrite the code, do it!
Refactor the Code
Changing the code, without changing the functionality is called code refactoring. This is a good strategy, a compromise, between rewriting and wrapping. Usually you will just go, line by line, through the original code, modernise it and cleaning it up.
Flags play an important role in embedded software development. Microcontrollers and chips are using registers where single bits or combinations of bits play a big role in the configuration. All the bits and their role are described in the specification, but writing the bits directly in the code would be very confusing and hard to read:
AHBMASK.reg = 0x14 // Huh!?
For this reason it makes sense to write an interface to access the registers of a chip. This interface will define identifiers, in the form of constant values, to build bit combinations to write into the registers.
The Outdated and Bad Approach
Chip manufacturers are well known for their extremely bad and outdated interfaces to access chip registers. Let us have a look at the CMSIS implementation from Atmel. This is part of the interface to access registers in one of the microcontrollers. Please ignore the copyright block, it is just added for legal reasons.
Do you feel the dust on this code? There are a vast amount of problems caused by this interface.
First the values are defined as macros instead of constants. All this identifiers will clutter the global namespace of your code and make naming conflicts very likely. Way better would be using simple constants like this:
const uint8_t PM_AHBMASK_DSU_Pos = 3; const uint32_t PM_AHBMASK_DSU = (0x1ul << PM_AHBMASK_DSU_Pos);
This would give the compiler the correct hint about the used data type for the registers. All this constants could be put into a own namespace to prevent any name collisions with the user code. It would still not prevent incorrect assignments.
I can write and compile the following code, which absolutely makes no sense:
CPUSEL.reg = PM_AHBMASK_DSU; // nonsense!
There will be not even a compiler warning about any problems and this is exactly what makes debugging embedded code very difficult.
Use the C++ Language!
I personally think, many software developers writing C++ code for hardware do not make fully use of the language. One reason could be the lack of support of many language features at the beginning or just the lack of experience.
In the the last 10 years, there was a huge progress in the development of the C++ language. Ignoring this progress would be silly in my opinion. Especially the C++11 standard added lots of useful features to the language.
A good support for the C++11, C++14 or even better for C++17 is very important, especially for embedded software development. Many of the introduced features will improve your code, make it simpler and more readable, without adding any additional byte to your firmware.
The features I describe in this article will not increase the size of the final firmware, they will just affect safety, readability and simplicity of your code. At the end, the optimiser in the compiler will resolve all the code and generate small and compact binaries.
For my current project I searched for a good boost power converter which is able to deliver continuous 400mA power for various sensors.
There are an endless number of good boost converters around, but not many can be hand soldered to a board. I would really like to see some like the
TPS61092 with SOIC or similar packages. The biggest problem seems to be the heat transport, why most chips have to be mounted flat on the board.
Before using the chip in my project, I created a small test board. Using this board I can test various things. First I liked to test the performance under load. Next I tested if the chip can be hand soldered and finally I tested the final board layout I will use in my project.
The performance of this chip is really good, producing a very stable output. I designed everything for a load up to 2A with all suggested components from the specification. There will never be a higher load than 0.5A, so I probably could use a smaller coil for the final project.
Running under 0.5A load from 3.3V for over half an hour, the chip stays quite cold. Even in my case, where the chip bottom is not directly soldered to the board, it seems to be able to transfer the heat into the board. This is nicely visible in the thermal image of the board.
The board was produced by OSH Park in a good quality. If you like to experiment with this chip, you can order this board very cheap at OSH Park using the following link.
Last week the new PCBite Kit 2.0 from Sensepeek arrived. The new kit comes with the great PCBite holder from the previous version, which are very useful to fasten a PCB for soldering, rework or analysis. New to this kit are the handy probes, which also can be magnetically attached to the mirror board.
The mirror finish of the board let you keep the bottom side of the board in sight while you are working on the top side. It is a very useful feature, like in the example shown in my photos where I analyse the communication of the snow flake board and can see the LEDs on the bottom side.
The probes have a nice weight and come with a very precise gold needle tip. You can easily place them on even the finest pin or trace. The tip contains a spring like a pogo pin, therefore it keeps an equal amount of pressure on the board and does not move if there are vibrations or if you carefully move the board around.
With each probe, there is also a different needle with a crown tip. This alternative tip is more like a really tiny fork to be placed on small wires and pins. Continue Reading
For a current project I need a step-up converter to get 5 volts from 2.5V-5.5V input. The output of this converter is used to power sensors which drive motors and small heat elements from this source. The average consumed current is 160mA with a peek at 320mA.
In the photo you can see the latest Boldport project with a test setup for the XC9142B50DMR-G from Torex Semiconductor. I made the mistake and just relied on the specifications stated on the website from Mouser:
This looks really good: 500mA output current… So I did a quick test. Obviously the magic smoke in the photo is a composition, but this is what actually happened somewhere at a constant ~250mA load with 5V input. Continue Reading
Today I got the PCB coaster from Adafruit. They look so much better in real than on the photos in the shop. The coasters are made from 2.4mm FR4 PCB material. There is a transparent solder mask on the top to protect the copper and gold elements. The frame around the image is black silkscreen. I […]
|Surface Finish||HASL Lead Free|
|Minimum Solder Mask Dam||0.4mm↑|
|Plated Half-holes / Castellated Holes||No|
|Minimum Drill Hole Size||0.3mm|
|Base Material||FR-4 TG130|
|No. of Layers||2 layers|
|Blind or Buried Vias||No|
|Trace Width / Spacing||6/6 mil|
I payed $27.40 for five boards with the option shown above and there were additional $20 shipping costs.
My board design has a very low quality class B4: Minimum drill size is 0.35mm, minimum trace size and spacing is 0.2mm.
Ordering and Shipping
The order process was very simple. The website provides an assistant with all possible options and calculates a quote in real time. I just noticed these minor things:
- The shipping cost is not displayed in this quote.
- The dimensions were not correctly extracted from my Gerber files.
The production of the boards and the shipping was quite fast, the whole process only took 10 days until the packet with the boards arrived.
The boards were well protected in the package, so there were no scratches from the shipping of the boards.
The boards have a good quality for the chosen options and the price. The alignment of the layers is not perfect, but everything is in an acceptable range.
The front side of the two boards. Continue Reading