Pulse counter support

All ESP32 boards running MicroPython.
Target audience: MicroPython users with an ESP32 board.
MasterOfGizmo
Posts: 50
Joined: Sun Nov 29, 2020 8:17 pm

Re: Pulse counter support

Post by MasterOfGizmo » Sun Jan 23, 2022 10:42 am

Roberthh wrote:
Fri Jan 21, 2022 12:25 pm
There is a PR open and ready to merge since a while at https://github.com/micropython/micropython/pull/6639. This PR shares the API with a counter/Encoder class for the MIMXRT port and the pure Python implementations for e.g. rp2.
I don't fully understand the idea behind that PR. It doesn't expose the PCNT API but instead implements two specific kinds of counters. Why not exposing the PCNT API and subclass the specific counters from that? The MP internal parts would be smaller and simpler, it would leave room for different PCNT usage and the custom parts would be python and thus easier to understand or modify for end users.

User avatar
Roberthh
Posts: 3667
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: Pulse counter support

Post by Roberthh » Sun Jan 23, 2022 11:14 am

That was an implementation discussed a while ago, and not used in favor of a simple API at MicroPython firmware level, which then can be shared by various ports.

MasterOfGizmo
Posts: 50
Joined: Sun Nov 29, 2020 8:17 pm

Re: Pulse counter support

Post by MasterOfGizmo » Sun Jan 23, 2022 11:22 am

Roberthh wrote:
Sun Jan 23, 2022 11:14 am
That was an implementation discussed a while ago, and not used in favor of a simple API at MicroPython firmware level, which then can be shared by various ports.
But the simple API does not exist yet? I see in the discussions here that some people prefer a software solution as they are afraid that the hardware version will miscount. I don't see how that should happen, especially with the PCNT filters being used. And the PCNT has the huge advantage of giving you Mhz rates at no CPU cost.

User avatar
Roberthh
Posts: 3667
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: Pulse counter support

Post by Roberthh » Sun Jan 23, 2022 11:32 am

The Encoder/Counter class for ESP32 uses the ESP32 PCNT API, counting up to MHz, implementing the same simple basic API which is also provided by Software modules for platforms, which do not have a Hardware Pulse Counter or Encoder.

MasterOfGizmo
Posts: 50
Joined: Sun Nov 29, 2020 8:17 pm

Re: Pulse counter support

Post by MasterOfGizmo » Sun Jan 23, 2022 12:18 pm

Roberthh wrote:
Sun Jan 23, 2022 11:32 am
The Encoder/Counter class for ESP32 uses the ESP32 PCNT API, counting up to MHz, implementing the same simple basic API which is also provided by Software modules for platforms, which do not have a Hardware Pulse Counter or Encoder.
But it does that by using PCNT directly. I don't understand why it's desirable to hide that PCNT API and do the Encoder/Counter in C instead of implementing the PCNT API as a module and do Encoder and Counter on top of that in Python. I simply don't see the benefit if that. Actually I only see disadvantages. So I'd like to understand what the advantages are.

MasterOfGizmo
Posts: 50
Joined: Sun Nov 29, 2020 8:17 pm

Re: Pulse counter support

Post by MasterOfGizmo » Thu Jun 23, 2022 9:46 am

There are now several implementations for this.

I have started myself this some time ago:
https://github.com/harbaum/micropython/ ... ine_pcnt.c

And recently this has been implemented:
https://github.com/micropython/micropyt ... ne_counter

User avatar
Roberthh
Posts: 3667
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: Pulse counter support

Post by Roberthh » Thu Jun 23, 2022 9:51 am

I've seen it. If I count right, there are now 4 implementations for ESP32 plus the generic GPIO based version. That does not improve the situation.

MasterOfGizmo
Posts: 50
Joined: Sun Nov 29, 2020 8:17 pm

Re: Pulse counter support

Post by MasterOfGizmo » Thu Jun 23, 2022 10:48 am

Roberthh wrote:
Thu Jun 23, 2022 9:51 am
I've seen it. If I count right, there are now 4 implementations for ESP32 plus the generic GPIO based version. That does not improve the situation.
What's the problem with that? Improvements IMHO are great.

The older versions didn't look very pleasing to me and weren'r working properly. I'd actually prefer the latest version from Jonathan if he fixes the race condiction.

Post Reply