PulseIn: add frequency selection #4457
Conversation
014e4d9 to
b918b23
Compare
.. implemented only on raspberrypi, where it's easiest. If this is considered useful enough, we can potentially implement it on at least SOME other ports. However, each port is a bit different so for now I just made them ignore the frequency= constructor parameter and return 1_000_000 for the frequency property. This is useful to me because using a frequency of 1000 lets me track the length of WWWB symbols, which range in length from 200ms to 800ms long.
b918b23 to
284239e
Compare
|
I'm not sure we want or need this. I tend to think of values as time and resolution, not frequency. My assumption for measuring slower signals was that you'd use do it manually with time.monotonic or time.monotonic_ns. |
|
My application needs to monitor these time pulses relatively precisely (ms-level) while doing other things (redrawing a displayio screen). I need something running more predictably than a "forever loop" of python bytecode that also redraws a display. Using exactly the approach you suggest (count time periods with polling plus monotonic_ns) I actually spent quite a bit of time believing I was dealing with interference from the power switching of the RGBMatrix display interfering with a weak radio signal, because when that's the ONLY thing my forever-loop did it worked really well .. but once the display was running and being updated once per second, "reception" suffered. It wasn't until I split the task of counting the pulse lengths to its own CircuitPython board (but running from the same power supply still) and the "interference" 100% went away that I realized the connection. If this is unlikely to be accepted then please feel free to close it up, especially since I think I can code it in pio+python once I get around to implementing the "jmp pin". But, no, CircuitPython without core support is NOT good at counting these intervals no matter how long a time 200ms sounds like, especially when displayio is in the mix. (There are additional complications that result from (A) the radio signal having an 'edge' exactly aligned to the second and (B) wanting to update the display as close to the edge of the second as possible; this puts the sampling and the display updating in direct conflict within the forever-loop. And timing can't be driven entirely from radio signal edges, because the clock has to continue functioning even when there is actual interference with the radio signal, which can both cause extra edges to appear or make no edges appear for periods of time) |
|
Ok, well I'm ok with this. Your need makes sense. I think that it'd be good to:
Reading the docs here may help you understand what I mean: https://circuitpython.readthedocs.io/en/6.1.x/shared-bindings/pulseio/index.html#pulseio.PulseIn Updating from the C side can make it hard to see the bigger picture. |
|
I don't think I'll get around to this. |
.. implemented only on raspberrypi, where it's easiest. If this is considered useful enough, we can potentially implement it on at least SOME other ports. However, each port is a bit different so for now I just made them ignore the frequency= constructor parameter and return 1_000_000 for the frequency property.
This is useful to me because using a frequency of 1000 lets me track the length of WWWB symbols, which are from 200ms to 800ms long.