Now a 'once' and a 'loop' buffer can be specified.
'once' is useful for things like writing a neopixel strip in the background,
if you can guarantee the buffer contents are stable until the write is complete.
'loop' is useful for periodic things, like pwm & servos.
both together are useful for some special cases of pwm/servo, where a
transitional waveform needs to be played for one repetition and then
a new waveform needs to be played after that.
The API is renamed to reflect that it's a more generic 'background'
operation.
There were two main issues with the PWM support.
The first is they would fail to work properly if the board goes
into low power mode, when you do things like: time.sleep(0.25)
Can make partially work with this by turning on the proper flags
in each of the FlexPWMTimer Timers/sub-timers, but this did not
appear to work if for example you have both A and B channels
enabled.
Second main problem is that the code did not work with the X
channel of each timer/sub-timer. It looks like someone had
earlier started support for this, But was not sufficient.
Needed to bypass the SDK code and get it closer to the PJRC code.
That is we set the PWM_CTRL_FULL_MASK, which then uses base->SM[submodule].VAL1 to control
when the timer is reset, so it sets up your cycle/frequency. But then this implies that X channel
which uses 0, 1 has to be handled specially. So for the different channels:
A - Uses VAL2 to turn on (0) and VAL3=duty to turn off
B - Uses VAL4 to turn on (0) and VAL5 to turn off
X - As mentioned above VAL1 turns off, but its set to the timing for freqency. so
VAL0 turns on, so we set it to VAL1 - duty
Renamed the board both name of directory within boards, but also the
name reported board name: board_id -- sparkfun_teensy_micromod
Adafruit CircuitPython 7.3.0-beta.0-10-g2a3eb49da-dirty on 2022-04-10; SparkFun Teensy MicroMod Processor with IMXRT1062DVL6A
While testing out this and the new MicroMod Teensy port, @mjs513
and myself found it desirable to have logical pin names for the
different Serial UART objects. It is a lot easier and clearer
to use and maintain to do something
like: uart4 = busio.UART(board.TX4, board.RX4)
than have to go look up the pin numbers for each board.
I fixed a couple issues in the pin name definitions.
The pin names are sort of Teensy centric in that the priority is given
to the pin names you would use in Arduino like D0, D1, ...
But also added names for the MicroMod names in particular the names
on the front of the ATP carrier board
Also updated manufacturer to be both PJRC and Sparkfun
As mentioned in issue #6241 the commit to setup port hooks is now
causing all input/output that are to go to the Mu window to also
go to the LpUart that is defined the port serial.c
and in this case it goes to lpuart4, which on Teensy 4, 4.1 is
used on Arduino Serial2. With this new code this port no longer
works properly.
This is one way to solve it, in that there is a #if defined() that
if not set, all of the code in this file is ignored and the higher
level supervisor stub versions of these functions will be used, which
don't interfere with Serial2 and my test sketch works again.
Note: the PR for Switch to Port Serial Hooks, also changed code in
other ports. I have not tried to see how.
There are other more global fixes for this, in which maybe a higer
level #if that disables the code within the top level supervisor. Or
could be software controlled
Again this may not be the final solution, but at least it gets
Serial2 up and running agin.
I instrumented RTC_Handler and determined that on SAMD51 it was possible
for the interrupt to be delivered well before the actual overflow of the
RTC COUNT register (e.g., a value as small as 0xffff_fffd could be seen
at the time of overflow)
Rather than depending on the overflow interrupt coming in at the same time
as COUNT overflows (exactly), rely only on observed values of COUNT in
_get_count, overflowing when it wraps around from a high value to a low
one.
With this change, PLUS a second change so that it is possible to warp
the RTC counter close to an overflow and test in 20ms instead of 3 days,
there was no problem detected over 20000+ overflows. Before, a substantial
fraction (much greater than 10%) of overflows failed.
Fixes#5985
Change to common-hal/rtc/RTC.c for time warping (plus make rtc_old_count non-static):
```patch
void common_hal_rtc_set_calibration(int calibration) {
+
+ common_hal_mcu_disable_interrupts();
+
+ RTC->MODE0.COUNT.reg = 0xffffff00;
+ rtc_old_count = 0;
+ do {
+ while ((RTC->MODE0.SYNCBUSY.reg & (RTC_MODE0_SYNCBUSY_COUNTSYNC | RTC_MODE0_SYNCBUSY_COUNT)) != 0) { }
+ }
+ while(RTC->MODE0.COUNT.reg < 0xffffff00);
+ common_hal_mcu_enable_interrupts();
+
+ mp_printf(&mp_plat_print, "Warping RTC in calibration setter count=%08x rtc_old_count=%08x\n", RTC->MODE0.COUNT.reg, rtc_old_count);
```
Test program:
```python
import time
from rtc import RTC
i = 0
while True:
RTC().calibration = 1 # Warps to ~16ms before overflow, with patch to RTC code
t0 = time.monotonic_ns()
et = t0 + 20_000_000 # 20ms
while (t1 := time.monotonic_ns()) < et: pass
i += 1
print(f"{i:6d}: duration {t1-t0}")
if t1-t0 > 200_000_000: break
print()
```
Dan Halbert
Jeff Epler
KurtE
ViktorWiz
root
Dan Halbert
Neradoc
George White
mjs513
Xu Hao
root
ZodiusInfuser
BigTuna94
Limor "Ladyada" Fried
foamyguy
Dominic Davis-Foster
Pontus Oldberg
ViktorWiz
Mark
gamblor21
Tod Kurt
Michael Himing