Switch SAMD21 ticks to PER event

[tannewt]

The EVSYS is used to generate an interrupt from the event. This
simplifies timing used in pulseio that conflicted with the
auto-reload countdown.

Fixes #3890

[DavePutz]

I tested this PR using pulsein for a DHT11 on a Metro M0 Express. It consistently failed with too few pulses (between 69 and 73). The protocol is expecting 81 pulses. I will see if I can determine the cause.

[DavePutz]

It looks like the issue is that the line:
RTC->MODE0.COMP[0].reg = target;
in port_interrupt_after_ticks() is taking about 100us to complete. Since the pulses coming in from a DHT11 can be as short as
24us there can be more than one pulse counted as a single pulse. port_interrupt_after_ticks() looks to be getting called about every 525us, so in a ~4ms sequence of incoming pulses there will be several combined values, causing the inaccurate number of pulses. This looks like the same issue mentioned at https://www.avrfreaks.net/comment/2507091#comment-2507091; where modifying the COMP register on the SAMD21 can take up to 180us.

[tannewt]

Why does the duration of setting interrupt after tick matter? It should be interruptable by the pulsein code.

[DavePutz]

The time it takes to set and synchronize the COMP register is longer than some incoming pulses; and does not seem to be interruptible. This means we cannot afford to do that while an incoming pulse is taking place. As painful as it is, I think we need a way to simply avoid the COMP setting while in a pulse. I did some testing with a boolean flag that returns from port_interrupt_after_ticks() in supervisor/port.c before hitting the COMP statement. It is set in pulsein_interrupt_handler( ) in PulseIn.c when self->first_edge is true (i.e. at the very start of a pulse) and then is reset in common_hal_pulseio_pulsein_popleft() and common_hal_pulseio_pulsein_get_len() when self->len is 0 (i.e. as soon as possible at the the end of a pulse). This seems to work, allowing auto-reloads to work. I realize that there may be a slight delay if the reload gets scheduled while we're in the midst of an incoming pulse; but that window is ~4ms for a DHT and ~68ms for an irremote.

[tannewt]

Ok, @DavePutz. I added back the COMP set disable. I couldn't find a way to make it not stall the interrupt processing. It doesn't impact ticks anymore though because they use a separate EVSYS interrupt now.

[DavePutz]

I have found that moving the rtc_start_pulse from common_hal_pulseio_pulsein_construct to the pulsein_interrupt_handler
shortens the pulsein window and lets the auto-reload work more consistently. Patch file I used looks like:

--- a/ports/atmel-samd/common-hal/pulseio/PulseIn.c
+++ b/ports/atmel-samd/common-hal/pulseio/PulseIn.c
@@ -101,6 +101,9 @@ void pulsein_interrupt_handler(uint8_t channel) {
         start_overflow = overflow_count;
     }
     if (self->first_edge) {
+        #ifdef SAMD21
+        rtc_start_pulse();
+        #endif
         self->first_edge = false;
         pulsein_set_config(self, false);
     } else {
@@ -240,9 +243,6 @@ void common_hal_pulseio_pulsein_construct(pulseio_pulsein_obj_t *self,

     // Set config will enable the EIC.
     pulsein_set_config(self, true);
-    #ifdef SAMD21
-    rtc_start_pulse();
-    #endif

 }

Other than that the PR looks good.

[tannewt]

@DavePutz I don't want to move it to the interrupt handler because it could be delayed by a sleep. I did add a start/stop in resume/pause so that sleep will be allowed when pulsein is paused.

[jepler]

Thank you! No testing performed.