Proposal: Esp32 machine.PCNT through Encoder.py and Counter.py #8253
Conversation
This needs to be improved. Three ways to address this are:
I would probably suggest option 3, because it's always going to be beneficial to have as minimal latency as possible for this kind of class. |
Yes, but only partly. In my actual use case these counters are not simply be used as such. I do run motors which are connected to the counters and one use case is to stop the motors in the handler once they have run a given distance. So I still like to have the ability to run python handlers. So doing the counter handling purely in C is not a full solution. Doing this IRQ in C will of course mean that the counter that is increased inside that IRQ handler is also on the C side and some control over the IRQ sources also has to be on the C side. I'd still like to keep this as simple as possible ... I actually see a fourth solution which would be making the python side cope with these delays. I could e.g. try to check for pending interrupts when the user wants to read the counter value thus making sure that the handler fixing the counters is explicitly called in that case. But I am afraid that I cannot easily tell whether there's a handler call pending as the IRQ itself already has been serviced and it's the handler call that's pending. Anyway, I see that this needs work. That's why I did this as a proposal. But the original solution does not support my use cases at all ... |
|
I would like to revoke this PR in favor of #7582 which basically does the same in a very same way but overall a little bit nicer ... |
[Fix] Wrong fix of cache use for STM32
|
This is an automated heads-up that we've just merged a Pull Request See #13763 A search suggests this PR might apply the STATIC macro to some C code. If it Although this is an automated message, feel free to @-reply to me directly if |
This is an attempt to implement the Counter classes as described in #8072 in Python rather than C. It's thus meant as a replacement of #6639. It converts machine into a Python class similar to #8244
This is using a rather direct implementation of the ESP32 PCNT API in C with the Encoder and Counter classes derived from this.
One advantage is that the C part is way simpler. Also the full PCNT API is available allowing other type of counters (e.g. an up/down counter using dedicated pins for up and down) to be implemented besides Counter and Encoder using PCNT directly.
There are also downsides. In the current approach Counter and Encoder.py share quite some code and functionality so a common CounterBase class may be nice in-between PCNT and Counter/Encoder.
Also the interrupt handling in Python introduces a significant delay. This is a problem since the hardware counter automatically falls back to zero on overflow and it's up to the interrupt handler to adopt to these overflows correctly. This is less of a problem with C as there's only few delay between the counter being reset and the handler being called. In Python this time is longer and a Python program reading the counter value between the hardware counter rolling to 0 and the interrupt handler adjusting for that will read wrong counter values. One solution would be to implement the overflow interrupt in the PCNT.c.