Re: Question about Bluepill arduino using OnePulse mode
Posted: Mon Jan 02, 2023 9:36 pm
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.dannyf wrote: Mon Jan 02, 2023 1:35 pmyou can write a dht slave to simulate a dht device, transmitting whatever data you want. making debugging easier. it is the opposite of what the OP wants to do but equally funNow given there was no DHT11 attached![]()
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.dannyf wrote: Mon Jan 02, 2023 1:33 pm for a non-blocking implementation, you can use external interrupts, or pin change interrupts, or even input capture. the downside is that the ISR overhead will mean that it is very difficult to implement somethng like thing on a slow mcu.
For even higher resolution, the DWT cycle counter can be used, but that is totally unnecessary here.ag123 wrote: Mon Jan 02, 2023 1:42 pm I'd think counting 'ticks' should work but that it'd need to be micros(), perhaps micros() may be appropriate, but one'd need to be careful of wrap around.
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.