Xlwww's interrupt method currently also uses an array to store the time values. For both that method and the DMA input capture method, the size of the array elements could be reduced to two bytes (after all it is only a 16-bit timer), or maybe even to 1 byte per entry (would probably still have sufficient resolution to work). However, the interrupt method does allow the entire transmission to be reduced to 5 bytes quite easily, as I already suggested. Reducing the number of elements in the array needed for the DMA method is also possible, but is a bit more tricky.ag123 wrote: ↑Mon Jan 02, 2023 1:17 pm There is another funky, hardware driven way using a counter is to use a timer and DMA.
Accordingly, a timer can trigger DMA, e.g. to read a set of gpios in sequence, this is actually 'the' way to 'read/write parallel data'.
As DHT11/DHT22 is first triggered using a single pulse from the mcu, this can be done using the usual digitalWrite().
The timer and dma needs to be setup in advance
Once done, enable dma and I think it'd begin reading (sampling) data in sync with the timer.
After this, you can 'parse' that data buffer to decode data sent from the DHT11/DHT22, the downside is this needs some memory.
The benefit is I think this approach may tolerate an RTOS 1ms context switching, as it is all hardware driven.
That, of course is what I did, except I did not write it from scratch, I found a bloke named Rob Tillaart already wrote such a thing, which needed minimal modification. Rob has also written a DHTxx library, but it looks like that would not be easily adapted for STM32.
For reception, the Adafruit DHTxx library worked for me straight out of the box using the official STM core. I did not try it on the "Roger" core but at a guess, it could work. However, it blocks for around 23-24ms, and disables interrupts for around 4ms after the start pulse.
Using the same method as mentioned in another thread here (viewtopic.php?f=7&t=955&start=20), the total handler_channel_1() interrupt processing time (the "out-to-lunch" time, using the terminology from the other thread) is around 3.4μs. Taking out the "debug" digitalWrite to PB11 cut that down to about 2.5μs. Given the DHT11 pulse times, I don't think I would be too worried. I have a feeling that the interrupt time doing the equivalent thing using the STM core might be a bit longer, but unlikely to be a real concern.
For even higher resolution, the DWT cycle counter can be used, but that is totally unnecessary here.
With whatever you use, if the count is treated as an unsigned integer, wrapping around once is not a problem, and wrapping around more than once might well be impossible given the duration of the entire transmission. If xlwww followed my suggestion of setting the timer counter to zero at the end of the start pulse, the 16 bit counter is not going to get anywhere near to wrapping around even once during the transmission.