Real time clock, more ADC stuff, reporting and unit tests

This is going to be a mammoth entry as this weekend I did a lot of stuff to the firmware...

First off, I got the RTC working. Now, this was originally going to keep track of wall time so that serial reports can be timestamped correctly. This was also the driver behind the battery backup and the low power modes, so the time would be right. However, on reflection, the only time the RTC would be useful is when there is something on the serial/USB port, and should there be something on that port, it can periodically set the time. In fact, it will need to set the time as the LPRC is not the most accurate clock source. So, when you add these factors up, there is no point in using the battery backup at all. In fact removing the parts needed for the backup will reduce the component cost by about 30%, even ignoring any board real estate savings it might afford. So the client software will send a set to the PSU periodically that will update the RTC to the current wall time. The 1 second "chime" will be used to generate the report to send to the PC which will have the date and time from the RTC in it.

After this realization and implementation, I started looking into the remains of the ADC work. The voltage feedback was working correctly, but I was getting a non-dynamic value for the current reading. So I started exploring the cause of this, I went and got some high power low value resistors to use as a dummy load, and replaced the fuses in my meter (again!) and started poking about. It looked like it should have worked from a hardware standpoint, but I was seeing a non-changing value. So it was time to look at the firmware...

The intention for the ADC is to measure 3 values: the output of the voltage divider with a thermistor for temperature monitoring, the output voltage and the output current. As mentioned the voltage feedback was working, but purely by luck. I am using the ADC scanning mode, I had incorrectly set it to interrupt after every sample, so the interrupt happened after the first sample had been taken, which normally would be the temperature sensor. However, I had not configured the relevant input as analog, so the first valid input was the voltage feedback. After resetting the interrupt it returned to the start, so it never actually sampled the current reading. To fix this, I needed to configure the temperature input, and then I updated the number of samples/interrupt to 3 and everything started working. So I took a set of current measurements and generated the formula for the line. After doing a few more tests I think the formula is not quite right, but I suspect that is due to poor averaging on my part, and I can easily revisit it. I have not gone as far as calibrating the temperature sensor yet as I will have to remove the thermistor from the board so I can put it on ice for 32°F, and boiling water for 212°F.

With the "ticking" sorted, and both values of interest being calculated, I came around the writing the periodic report. This was going to be a JSon object with the data in various fields. First of all I got no output at all which previous experience has shown to be related to the heap size, so I doubled the heap and started getting some output. Then it stopped! So I looked back at the code and realized that I had not added the required calls to heap_free so essentially after 2 reports, it ran out of memory. I added the necessary clean up code so I no longer leaked memory, and discovered that the output had completely dried up again. I made an educated guess and decided that it was probably something wrong with the deallocation code. Which brings me to the final thing I did this weekend...

The heap system is distinctive in that it can run under linux as it doesn't have any microcontroller specific code in it, other than #include <xc.h> at the top. So I decided that I needed a proper unit test for it. As I have been using gtest for the last couple of years at work I reached for that testing framework and started the unit test. First of all I wrote tests surrounding the heap being uninitialized, and making sure that behaved as expected. Then I added some allocation tests, and then some deallocation tests. I added some heap exploration functions to the heap code that are only compiled in when building on linux to allow the unit tests to walk the heap and confirm it's consistency. When running the tests they started failing (as suspected) on deallocation, it turns out that when I wrote the code I made a very obvious error, I was adding the current block size to the previous block pointer when reaggregating the free space. Fixing that fixed the unit tests, and when testing on the microcontroller, the power supply generated a properly formatted report every second for several hours.

On an aside, I also started on a wxWidgets application to provide an onscreen display of the settings and outputs as well as provide settings changes to the PSU. It's pretty rudimentary at the moment but it does seem to work.

Subject: