This allows you to list and explore connected USB devices. It
only stubs out the methods to communicate to endpoints. That will
come in a follow up once TinyUSB has it. (It's in progress.)
Related to #5986
This is needed so that the floppy flux reader can enable the pull up
on the index pin while using it as a pio jmp pin.
Also fixes a doc bug where the `jmp_pin` was omitted in one spot in the docs.
This tweaks the RMT timing to better match the 1/3 and 2/3 of 800khz
guideline for timing. It also ensures a delay of 300 microseconds
with the line low before reset.
Pin reset is now changed to the IDF default which pulls the pin up
rather than CircuitPython's old behavior of floating the pin.
Fixes#5679
The port is free to return NULL for any/all of these, and the caller has
to check.
This will be used in the floppy code, because aside from getting the
registers, it looks like all is independent of MCU.
This brings the pins in line with the documented [pinouts]. The only
"special" pins:
- GP0, GP1 are mentioned as the default UART, so we init them as
such and give them the TX and RX alternative names.
- GP16 is connected to the onboard neopixel DIN line and we assign it
the NEOPIXEL name. (Power of the neopixel is connected to the 3.3V
rail, not a pin. See [schematic].)
- GP26, GP27, GP28, GP29 have unambiguous ADC designations in the
[pinouts], so we assign the `A` analogue names as the Pico board
definition does.
[pinouts]: https://www.waveshare.com/wiki/RP2040-Zero#Pinouts
[schematic]: https://www.waveshare.com/w/upload/4/4c/RP2040_Zero.pdf
If, for some reason, you mix up TX and RX when calling `busio.UART` (who would do that ;) ), you get `Invalid pins`. When you go to try again, you'll get `All UART peripherals are in use` because the interface was claimed as busy before pins are verified. This should fix that issue.
This targets the 64-bit CPU Raspberry Pis. The BCM2711 on the Pi 4
and the BCM2837 on the Pi 3 and Zero 2W. There are 64-bit fixes
outside of the ports directory for it.
There are a couple other cleanups that were incidental:
* Use const mcu_pin_obj_t instead of omitting the const. The structs
themselves are const because they are in ROM.
* Use PTR <-> OBJ conversions in more places. They were found when
mp_obj_t was set to an integer type rather than pointer.
* Optimize submodule checkout because the Pi submodules are heavy
and unnecessary for the vast majority of builds.
Fixes#4314
By having a pair of buffers, the capture hardware can fill one buffer while
Python code (including displayio, etc) operates on the other buffer. This
increases the responsiveness of camera-using code.
On the Kaluga it makes the following improvements:
* 320x240 viewfinder at 30fps instead of 15fps using directio
* 240x240 animated gif capture at 10fps instead of 7.5fps
As discussed at length on Discord, the "usual end user" code will look like
this:
camera = ...
with camera.continuous_capture(buffer1, buffer2) as capture:
for frame in capture:
# Do something with frame
However, rather than presenting a context manager, the core code consists of
three new functions to start & stop continuous capture, and to get the next
frame. The reason is twofold. First, it's simply easier to implement the
context manager object in pure Python. Second, for more advanced usage, the
context manager may be too limiting, and it's easier to iterate on the right
design in Python code. In particular, I noticed that adapting the
JPEG-capturing programs to use continuous capture mode needed a change in
program structure.
The camera app was structured as
```python
while True:
if shutter button was just pressed:
capture a jpeg frame
else:
update the viewfinder
```
However, "capture a jpeg frame" needs to (A) switch the camera settings and (B)
capture into a different, larger buffer then (C) return to the earlier
settings. This can't be done during continuous capture mode. So just
restructuring it as follows isn't going to work:
```python
with camera.continuous_capture(buffer1, buffer2) as capture:
for frame in capture:
if shutter button was just pressed:
capture a jpeg frame, without disturbing continuous capture mode
else:
update the viewfinder
```
The continuous mode is only implemented in the espressif port; others
will throw an exception if the associated methods are invoked. It's not
impossible to implement there, just not a priority, since these micros don't
have enough RAM for two framebuffer copies at any resonable sizes.
The capture code, including single-shot capture, now take mp_obj_t in the
common-hal layer, instead of a buffer & length. This was done for the
continuous capture mode because it has to identify & return to the user the
proper Python object representing the original buffer. In the Espressif port,
it was convenient to implement single capture in terms of a multi-capture,
which is why I changed the singleshot routine's signature too.
ZodiusInfuser
Scott Shawcroft
Dan Halbert
Dan Halbert
Michael Himing
Radomir Dopieralski
Jeff Epler
Scott Gauche
root
Neradoc
microDev
Neradoc
Scott Shawcroft
Chris Wesseling
arturo182
Pontus Oldberg
Chris Wesseling
Jeff Epler
Danny Staple
Pierre Constantineau
Kong Wai Weng
Seth Kerr
foamyguy
Kattni Rembor
Timon
lady ada