For the “JEM” JeeLabs Energy Monitor, we’re going to need to put the ADC on the Olimexino’s STM32F103 to some serious work: the goal is to acquire 4 ADC channels at 25 Khz each, so that we can capture a full cycle of the 50 Hz AC mains signal with a resolution of 500 samples, as well as collecting the readings of up to three current transformers.
Since AC mains voltage is being sampled via the negative peaks of the incoming 9V AC supply, we really only get half cycles, with flat segments in between. To be able to reconstruct a full cycle, we need to capture at least 3 segments: in the worst case, two flat ones with only one complete negative cycle. This requires a data sampling window of at least 30 ms.
As described earlier, we’re going to aim for the following setup:
- single ADC, acquiring 4 channels every 40 µs
- for each channel, two buffers of 800 samples
- this gives an acquisition time of 32 ms per buffer
The STM32F103 has a very capable ADC subsystem, as seen in this diagram from the datasheet:
To distill some other relevant info from the datasheet for our use case:
- the ADC can take up to 1 million samples per second
- it’s slightly less when running at 72 MHz (max ≈ 850 Ksps)
- there’s a “SCAN” mode to read 1..16 specific ADC channels in rapid succession
- the ADC can be triggered to run from a hardware timer, set to 25 KHz in this case
So this means we’re getting one new ADC reading every 10 µs on average. There is one catch: in scan mode, the ADC can only be used in combination with DMA, which makes sense since these data rates would completely overwhelm the CPU if handled through interrupts.
A benefit of using a hardware timer + DMA is that the ADC acquisition timing will be rock solid.
That DMA controller itself is an equally sophisticated part of the µC chip, by the way:
Note that both diagrams include hardware which is not on the “low end” STM32F103RB used on the Olimexino-STM32 board, which has only one ADC and one DMA unit.
It takes quite some reading in the (1137-page!) reference manual for the STM32F1xx chips, to figure out all the settings needed to implement the above acquisition mode. Then again, once that’s done, the code is remarkably short.
Here’s the basic DMA-based acquisition cycle to keep the ADC permanently running:
: adc1-dma ( addr count pin rate -- ) \ continuous DMA-based conversion
3 +timer \ set the ADC trigger rate using timer 3
+adc adc drop \ perform one conversion to set up the ADC
2dup 0 fill \ clear sampling buffer
0 bit RCC-AHBENR bis! \ DMA1EN clock enable
2/ DMA1-CNDTR1 ! \ 2-byte entries
DMA1-CMAR1 ! \ write to address passed as input
ADC1-DR DMA1-CPAR1 ! \ read from ADC1
0 \ register settings for CCR1 of DMA1:
%01 10 lshift or \ MSIZE = 16-bits
%01 8 lshift or \ PSIZE = 16 bits
7 bit or \ MINC
5 bit or \ CIRC
\ DIR = from peripheral to mem
0 bit or \ EN
DMA1-CCR1 !
0 \ ADC1 triggers on timer 3 and feeds DMA1:
20 bit or \ EXTTRIG
%100 17 lshift or \ timer 3 TRGO event
8 bit or \ DMA
0 bit or \ ADON
ADC1-CR2 ! ;
It’s not so important at this stage how this works, just what it does:
- a buffer + length is passed in, where the DMA unit will deposit all its readings
- the DMA unit is set up to fill this buffer in circular mode, going on forever
- the ADC is set up to acquire data on every timout of timer 3 at a specified rate
This was created in an earlier experiment, titled Reading ADC samples via DMA to implement an oscilloscope. That was for a single channel, whereas here we need four. Luckily, we can keep that DMA code as is and modify the ADC settings on the fly to switch to 4-channel scan mode:
: quad-adc ( -- ) \ configure ADC and DMA for quad-channel continuous sampling
+adc 6 us adc-calib
adata #abytes VAC-IN arate-clk adc1-dma
VAC-IN adc# \ channel 0
CT1 adc# 5 lshift or \ channel 1
CT2 adc# 10 lshift or \ channel 2
CT3 adc# 15 lshift or \ channel 3
ADC1-SQR3 ! \ set up the ADC scan channels
3 20 lshift ADC1-SQR1 ! \ four scan channels
8 bit ADC1-CR1 bis! \ enable SCAN mode
;
The above code depends on a number of constants, defined as follows:
4 constant #adcs
800 constant #asamples
2 constant #abuffers
#adcs #asamples * #abuffers * 2* constant #abytes
40 constant arate-us
arate-us 72 * constant arate-clk
It also needs this definition of a 12.8 KB buffer to store all acquired data in:
#abytes buffer: adata
Note that the timer and DMA settings have not changed: timer 3 will fire once every 40 µs and trigger a burst of four ADC conversions, one for each channel. Each completed conversion then triggers a DMA transfer, filling up the circular buffer four times faster than before.
All this code looks complex, and of course in a way it is indeed - this is a complex use case for the ADC + DMA hardware contained in the µC, after all! But in actual use it couldn’t be simpler:
quad-adc
That’s it. Now - magically - the adata buffer will be continuously filled
with ADC samples from all four channels, without the CPU doing any work at
all. It’s all happening in the background, and perhaps most surprising of all:
the current drawn for all this extra activity is only 2 mA!
The processing overhead is negligible: one 16-bit read and one 16-bit write by the DMA unit - once every 10 µs on average. Since both ADC and SRAM are on the fast internal bus, this will occupy that internal data bus less than 0.3% of the time.
We do need to be careful with timing and synchronise our processing to avoid DMA changing values while we’re still using them. This is solved by inspecting a few status bits in the DMA controller: there is one bit for when the buffer has been filled halfway and another bit when the buffer is full and the DMA unit starts over from the beginning. These happen 40 µs x 800 samples = 32 ms apart, so we can simply poll this in the main loop of our application. There is even no need to introduce interrupts - 32 ms is a very long time for a µC running at 72 MHz.
At the halfway point, we have 32 ms to process the 1st buffer. At the end point, we have another 32 ms to process the 2nd buffer. And so on. This is the circular equivalent of double buffering.
Another subtle issue, is that we can no longer use the ADC in polled mode. To read out the LiPo voltage for example, we need to somehow make the ADC read out an extra channel, without interfering with the above high-speed acquisition cycle. As it happens, the designers at STM thought of that too, and came up with the concept of “injected data channels”: it’s possible to make the ADC acquire 1..4 extra channels, and have it place the results in separate registers.
Using this mechanism, we could specify that we want to read PB0 as well for example (once!), and then simply wait for the ADC scan to pick that request up after it has taken care of all the regular channels. This will allow reading out a few other analog pins, with at most 40..50 µs delay - the worst-case time needed by the ADC to start again and process our “injected” request.
As you can see, modern ARM µCs are a lot more than just a CPU-with-some-memory!