.. and enable it on atmel-samd and raspberrypi. On trinket_m0 this saves
96 net bytes of flash. There are 216 bytes actually saved by reducing
the flash storage size of the property descriptors, but added code in
several paths takes back over half of the 'raw savings'.
By organizing the "get-only" and "get-set" (but no delete) properties
each in a different section, we can represent then more efficiently.
Testing performed: that a get-only property can still be gotten but
can't be set or deleted; that a get-set property can sill be gotten or
set but can't be deleted. Tested on pygamer.
Because this requires linker file support, I only enabled it on two of
the ports.
As I mentioned in issue #6310 while investigating that the Teensy port
did not support RS485_dir pin on normal GPIO pins, I found that it
was not implemented either as well on some other ports.
So was curious to implement it for RP2040 using same approach as I did
for the MIMXRT in the Pull Request #6328
That is I setup the specified pin as a normal GPIO pin in output mode
and then when you do a write operation it sets the GPIO pin logically
high, and when the write completes I set it logically low.
Note: knowing when I can set it low can be tricky, as you need to make
sure the full output has completed otherwise the data will be corrupted.
I am using: uart_tx_wait_blocking(self->uart);
Which looks like it is supposed to wait until the busy status is no
longer set, which the Reference manual mentioned, but this is leaving
the line logically set longer than I would like.
however I have tried running it with my hacked up version of the
Python Robotis DynamixelSDK and was able to talk to some AX servos.
I did have to change the library slightly for the RP2040, as the
library was erroring out when you did something like uart.read(5)
and it timed out without receiving anything. The RP2040 returned
None whereas I think the Teensy returned an empty set, which is what
it looks like the PySerial original code expects.
Not sure if anyone is interested in this, but thought i would
put it out as PR and see.
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.
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.
