Rather than returning the negative error value.
This is intended to close#7606, though I did not test with mqtt.
Instead, I created a simple standalone test program:
```python
import wifi, socketpool, ssl, time
#wifi.radio.connect(<omitted>)
import socketpool
socket = socketpool.SocketPool(wifi.radio)
ctx = ssl.create_default_context()
b = bytearray(8)
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sss = ctx.wrap_socket(s, server_hostname='example.com')
sss.connect(('example.com', 443))
sss.setblocking(False)
r = sss.recv_into(b)
print(r, b) # prints 4294967285 which is -11 as unsigned
sss.close()
```
Before the change, r was the out of range value 4294967285. After the
change, the recv_into call raises OSError instead.
This is comparable to the behavior on standard Python, though an
SSLWantReadError is raised instead.
The original (mis)behavior seems to match what was uncovered deep inside
minimqtt by adding logging:
```
370.578: DEBUG - PKT: _sock_exact_recv: recv_len = 4294967285
```
This 2-in-1 PR started with the goal of support the Bangle.js 2
smartwatch with *no USB*.
* Adds "secure" DFU build support with a committed private key.
* Adds 3-bit color support with one dummy bit for the JDI memory display
* Allows nrf boards to have a board_background_task() run in RUN_BACKGROUND_TASK.
This is needed because the Bangle.js 2 uses the watchdog to reset.
* Renamed port_background_task() to port_background_tick() to indicate it
runs on tick, not RUN_BACKGROUND_TASK.
* Marks serial connected when the display terminal is inited. This means
that safe mode messages show up on the display.
ACep, 7-color epaper displays also pack 3 bits in 4. So, I added that
support as well.
* Adds 3-bit ACeP color support for 7-color e-paper displays. (Not
watch related but similar due to color depth.)
* Allows a refresh sequence instead of a single int command. The 7" ACeP
display requires a data byte for refresh.
* Adds optional delay after resetting the display. The ACeP displays
need this. (Probably to load LUTs from flash.)
* Adds a cleaning phase for ACeP displays before the real refresh.
For both:
* Add dither support to Palette.
* Palette no longer converts colors when set. Instead, it caches
converted colors at each index.
* ColorConverter now caches the last converted color. It should make
conversions faster for repeated colors (not dithering.)
Watchdogs are used to reboot out of the bootloader. There is a
scratch register for user watchdogs. So use sdk functions to better
distinguish these.
Related to #7346
The comment says it is `buffer[start:end]` but it assumed elements
were a single byte long. Now it correctly does multibyte elements
from array.array.
Fixes#4988
Now, open wifi works on Pico W, so this closes#7438.
For the web workflow it's now OK to either
* specify an empty password string (as before)
* not have the CIRCUITPY_WIFI_PASSWORD key at all (new functionality)
reset_port calls reset_all_pins, which disables the built-in pull
down. In theory, this could allow some CYW43 interfacing pin to float
to an inappropriate value. There's no proof of this! but the move can't
really hurt, either
* read() is now readinto() and takes the buffer to write into.
* readinto() returns the number of valid samples.
* readinto() can be interrupted by ctrl-c.
* readinto() API doesn't support signed numbers because it never did.
* sample_rate is now required in the constructor because supported
values will vary per-port.
* 16 bit values are full range. 12 bit samples from RP2040 are stretched
in the same way they are for AnalogIn.
Fixes#7226
This needs thorough testing before it's merged, as we tried
and reverted this once before (#5341 and #5356).
I think that besides checking for tinyusb having "something to do",
the fact that `port_interrupt_after_ticks` and `port_disable_tick`
weren't implemented that was causing a secondary problem.
I've tested this on a pico w over reboot-cycles and ctrl-c-cycles,
with and without drive automounting, with and without serial repl open,
and on a power-only connection.
I didn't notice the problem reported in #5356 after merely implementing
port_idle_until_interrupt; but I did notice that sleeps in general would
take over-long until "something" (like writing to the USB drive) happened;
I think "something" was probably calling port_enable_tick(). When this
problem was happening, sleeps would take a lot longer; for instance,
`sleep(.001)` would take about 1/20s and `sleep(.1)` would take about 1/7s.
