As of release 3.1.4 my library is an official Arduino library. Since there existed already some DCF77 library I had to chose a different name for mine. The first try was dcf77. Although this worked fine for Linux it clashed terribly for Windows. Hence I had to rename my library differently. I chose dcf77_xtal because my library will only work for crystal based Arduinos.
You might wonder why it took me that long to make it an official library. After all I only had to add some metadata and an issue for the Arduino repo. There were several reasons. The most important one was that I was not fully satisfied with the quality of the 3.0 release. In particular I had some doubts if the change to a template based approach might have created some regressions. Thus I was testing for quite a while. Then there was another much nastier issue. After I was somewhat satisfied the Arduino IDE upgraded and introduced a new compiler version. This new compiler refused to compile my library. Fixing this took me much longer than expected although the root cause was some name clash. Once I figured this out and had fixed it with version 3.1.3 adding the missing metadata was just a small step.
What are the advantages of the new library?
- First and most important it is now an official Arduino library managed by the library manager. Thus anyone can use it and can always get the most up to date version. This seems not that impressive but for me this makes support a lot simpler. I can just push the newest version to github and ever user of the library will notice more or less automatically that a newer and (hopefully) better version is available.
- It has better test coverage.
- It works with the newest compiler version. Sounds like a no brainer? Yeah, but read on below.
Why would I be excited about compatibility with the newest compiler version? Lets conduct some experiments. I will compile the “simple clock” sketch in 4 different ways. I will use different IDE and library versions and compare the results with regard to memory consumption.
First lets have a look at flash (program memory) consumption.
| Arduino 1.6.9 / GCC 4.8.1 | Arduino 1.8.1 / GCC 4.9.2 | |
|---|---|---|
| Library V2.0.4 | 18 712 bytes (60%) | 16 178 bytes (52%) |
| Library V3.1.4 | 16 584 bytes (53%) | 13 858 bytes (45%) |
The V3 branch is always 7% points below the V2 branch. This is due to the introduction of templates. Thus the template approach introduced quite nice gains. In both cases the compiler will save 8% points of memory by upgrading from 4.8.1 to 4.9.2. Together a total of 15% points. Given the tight memory constraints of the Arduino controller this is a really significant improvement.
Second lets look at sram (variable memory) allocation.
| Arduino 1.6.9 / GCC 4.8.1 | Arduino 1.8.1 / GCC 4.9.2 | |
|---|---|---|
| Library V2.0.4 | 739 bytes (36%) | 721 bytes (35%) |
| Library V3.1.4 | 753 bytes (36%) | 735 bytes (35%) |
Here the situation appears to be worse. Although the compiler and/or better Arduino libraries seem to reduce the memory footprint the new library uses more sram. This is not due to the template approach. This is mainly caused by the new decoder approach. Since I changed the convolutional decoders from loops to a stream based configuration they require some additional helper variables for housekeeping. This costs 14 bytes independent of the compiler version. But what does it buy us? Well, the new convoluters burn less CPU cycles. Hence 16 MHz controllers with sufficient memory can switch to high phase resolution. It is also the enabler for the 8 MHz versions. I consider this more than an acceptable price for these options. It also leads to more even distribution of the burned CPU cycles thus reducing interrupt inflicted timing jitter in the rest of the applications. Anyway the price is fully compensated by switching from the older Arduino version to the newest one.
Thus overall I consider the new V3 branch clearly superior to the V2 line.
Blinkenlight 