on specific SCK/MOSI/MISO pins, the `common_hal_busio_spi_construct`
method always skip miso pins which will lead to a `invalid pin`
exception when SPI initilized
This prevents running into the pins that cannot be reset. On 1011
it was off by one pin that isn't attached to the package. So,
having the USB pins forbidden prevented resetting to a NULL address.
Fixes#7952
This adds a script to generate the peripherals files (except clock).
It adds support for the 1015, 1020, 1040, and 1050 EVKs.
Some work was started on 1176 but it isn't working. So, the board
def is in a separate branch.
Fixes#3521. Fixes#2477.
This makes all the samples from Dan's collection register as 440Hz
when playing on pwmio or i2sout, using https://webaudiodemos.appspot.com/pitchdetect/index.html
to detect the frequency played (all should show as A 440Hz; an error
of up to 20 "cents" should be treated as OK)
There's an audible carrier with PWM output and the 8kHz samples. This is
probably a limitation of the peripheral which is documented as being for
input signals of 44 kHz or 48 kHz; the carrier frequency is a fixed
multiple of the sample frequency.
Closes#7800
.. via a peripheral known as the "MQS" (medium quality sound). It uses an
~192kHz PWM signal to generate audio. It sounds OK on a small speaker with
no amplifier. There's a small pop when starting/stopping audio, as is
typical.
.. and write a general 'pin change interrupt' facility to power it
This uses the same quadrature state machine as atmel-samd, nrf, and
rp2040. The 1011 doesn't have a dedicated encoder peripheral, so we
go the pin-change + software route.
tested on metro m7 (green prototype version) with max98357a i2s amplifier and the following test code:
```py
import board
import time
import digitalio
from audiobusio import I2SOut
from audiocore import RawSample
from microcontroller import pin
from ulab import numpy as np
n = np.array(np.sin(np.linspace(0, np.pi*2, 218, endpoint=False)) * 200, dtype=np.int16)
print(n)
r = RawSample(n, sample_rate=8000, channel_count=2)
def main():
with digitalio.DigitalInOut(board.LED) as l:
l.switch_to_output(True)
value = False
while True:
with I2SOut(pin.GPIO_06, pin.GPIO_07, pin.GPIO_04) as i:
time.sleep(.01)
l.value = value = not value
i.play(r, loop=True)
print(i.playing)
time.sleep(.5)
i.stop()
print("STOPPED")
print(i.playing)
time.sleep(.5)
i.play(r, loop=True)
print(i.playing)
print("PLAY AGAIN")
time.sleep(.5)
time.sleep(1)
```
Only stereo, 16-bit, raw samples were tested; the sample rate is actually fixed
at 48kHz in the core right now. There is more to do, but the basics work.
# Conflicts:
# ports/mimxrt10xx/Makefile
# ports/mimxrt10xx/mpconfigport.mk
* Enable dcache for OCRAM where the VM heap lives.
* Add CIRCUITPY_SWO_TRACE for pushing program counters out over the
SWO pin via the ITM module in the CPU. Exempt some functions from
instrumentation to reduce traffic and allow inlining.
* Place more functions in ITCM to handle errors using code in RAM-only
and speed up CP.
* Use SET and CLEAR registers for digitalio. The SDK does read, mask
and write.
* Switch to 2MiB reserved for CircuitPython code. Up from 1MiB.
* Run USB interrupts during flash erase and write.
* Allow storage writes from CP if the USB drive is disabled.
* Get perf bench tests running on CircuitPython and increase timeouts
so it works when instrumentation is active.
This helps my development scripts work better, and probably also fixes
a problem switching from the circuitpython environment back to arduino.
(specifically, the "1200 baud" serial trick was not rebooting into
the bootloader but was just resetting)
It now handles deinit, never_reset and sharing tracking. PWM
now runs in the WAIT state as well during a time.sleep().
_reset_ok() was removed because it was called in one spot right
before deinit().
Some PWMOut were also switched to a bitmap for use instead of
reference count. That way init and deinit are idempotent.
Fixes#6589. Fixes#4841. Fixes#4541.
There are apparently two RTC interfaces in the mimxrt10xx dev
kit. The low power interface access the battery backed up hardware.
I've tested this on the Teensy41 and it seems to
fix issue #4574
there return of a read operation that times out with no data received
is inconsistent:
```
Adafruit CircuitPython 7.3.0-beta.1-31-g73f6b4867-dirty on 2022-04-30; Adafruit Feather RP2040 with rp2040
>>>
>>> import board, busio
>>> print(board.UART().read(5))
None
Adafruit CircuitPython 6.3.0 on 2021-06-01; FeatherS2 with ESP32S2
>>> import board,busio
>>> print(board.UART().read(5))
None
Adafruit CircuitPython 7.3.0-beta.1 on 2022-04-07; Adafruit Feather STM32F405 Express with STM32F405RG
>>> import board, busio
>>> print(board.UART().read(5))
None
Adafruit CircuitPython 7.3.0-beta.1-31-g73f6b4867-dirty on 2022-04-28; Teensy 4.1 with IMXRT1062DVJ6A
>>> import board, busio
>>> print(board.UART().read(5))
b''
```
Since I have a PR on this file anyway, I thought I would put in the change to make it consistent
with the other 3 board types I tried. Can not say about any of the others.
The existing code was setup that allowed you to specify an RTS
pin to be used as an RS485 direction pin, however there are no
RTS pins that are exposed on any of the Teensy 4.x boards.
Instead Arduino code base allowed you to specify any GPIO pin to
work instead. So I added the code in to facilitate this.
In addition the alternative code to wrap your own GPIO pin set high and low
around call(s) to uart.write() will not currently work, unless maybe you
fudge it and add your own delays as the write will return after the last
byte was pushed onto the UART’s hardware FIFO queue and as such if you
then immediately set the IO pin low, it will corrupt your output stream.
The code I added detects that you are setup to use the RS485 pin and
before it returns will wait for the UART’s Transfer complete status flag
to be set.
