Hackaday just published an article about Noether's theorem. In it they described the principle of least action using the STM32 development board, but not in a way you would think. The article describes a hacker who after many hours of working on getting GCC and STM32 to work has given up in a fit of rage and through the stupid thing at the wall. Clearly the trajectory of STM32 will follow a path which minimizes work. Personally I prefer the Fermat's principle interpretation, but I digress...

I spent most of this week trying to get the STM32 massive $$\Sigma\Delta$$ ADC to sample based on an embedded timer. This will allow the hardware to control the sampling and leave the CPU free for more interesting tasks. Now in order to do that I of course had to read the API. Ok fair enough I set everything as the API described and after four wasted hours of debugging I was no closer to that sweet, sweet interrupt based acquisition. Enter the STM32F3 Peripheral interconnect matrix. This document describes in great detail that not every timer channel is created equal, and only certain ones can be used for certain peripherals. So my attempt at driving the ADC with timer 2 channel 4 was doomed to failure, but switching to timer 2 channel 3 got everything working. At least sort of working, my ADC was missing signals limiting the sampling to 12.4KSps. As is clearly explained in Getting Started with the SDADC in STM32F373 and nowhere else, the ADC is limited to 12.4kSps UNLESS the user enables continuous acquisition and fast mode, however it fails to describe what these parameters actually do. What I am trying to get at here is documentation organisation needs some work. The bootstrapping procedure for my STM32F3 will work for every chip in the family and with a small change for the whole STM32 series. The HAL API documentation shown above is largely unchanged from the STM32F4 and the STM32F0, even though the silicon is completely different. While abstracting away the differences in STM32 operations the HAL designers neglected to talk about the quirks of each family. This is made even more unfortunate by the fact the the datasheet is labeled as a family specific datasheet, and as such it lulls the developer into the false sense of security. The silicon specifics are treated as errata, instead of first class documentation.

In the end I managed to get the sampling working as driven via a timer. I also added some control registers accessible via UART for loading and reading parameters from the STM32. The final bit of development is the new build system for the project. Prior to today I have been using Makefiles for code generation. Now I finally switched to CMake. The main advantage here, besides the beautiful green build log is that Clion uses cmake files as project files. I am finally able to use a real IDE for embedded development. A few extra rules and the in-system-programming scheme I developed for OPQBox2 lets me deploy and test STM32 code via Raspberry Pi without leaving the couch.

Next up I will be setting up UART to work asynchronously and setting up SPI on both the PI and the DSP. I expect that I will need to get JTAG debugging going as well. C'est la vie!