This is the lwip no-os version of SO_REUSEADDR, which is set on all
listening sockets in the espressif port; do so here as well,
it makes running servers easier. The "address in use" error does
not occur.
You might wonder how this fixes a problem with PulseIn, when the
changes aren't to any of those files! PulseIn is implemented in terms of
StateMachine, which had some assumptions about the relation between
the index of a pin object in mcu_pin_global_dict_table and its "pin
number". This was true, until some pins were removed from the
microcontroller module on Pico W.
Closes: #7078
Weirdly we have to stop the AP too (which we never started),
or cyw43_tcpip_link_status still reports that STA is connected.
As long as AP mode isn't implemented, this doesn't matter and
we can just do it.
Foamyguy discovered that trying to send >2920 bytes at once consistently
failed. I further discovered that sometimes trying to send >1460 bytes
would fail too. By "fail", I mean that it would take a very long time
(around 200 * 50ms) before erroneously reporting that all bytes were
written.
In my testing, this change causes larger writes to successfully
send either 2920 or 1460 bytes (possibly after doing some 50ms waits
for a previous packet to clear).
The documentation of socket.send always stated that it COULD send fewer
bytes than requested, but adafruit_httpserver assumed that the number
of requested bytes were always sent, so after this change alone,
adafruit_httpserver will still not work properly.
Closes: #7077 (albeit fixes are needed in adafruit_httpserver too)
This reduces power consumption during true deep sleep.
In my measurements with ppk2 and a program that _irrevocably_ entered
deep sleep (no time alarm or pin alarm), power usage as measured on a
ppk2 decreased from ~10mA to ~1mA.
The prefixed versions raise Python exceptions, the un-prefixed return
negative error values. We don't want to raise an exception from here,
it leaves the SSL stack in an undefined state.
## Testing self-signed certificates and `load_verify_locations`
Obtain the badssl "self-signed" certificate in the correct form:
```sh
openssl s_client -servername self-signed.badssl.com -connect untrusted-root.badssl.com:443 < /dev/null | openssl x509 > self-signed.pem
```
Copy it and the script to CIRCUITPY:
```python
import os
import wifi
import socketpool
import ssl
import adafruit_requests
TEXT_URL = "https://self-signed.badssl.com/"
if not wifi.radio.ipv4_address:
wifi.radio.connect(os.getenv('WIFI_SSID'), os.getenv('WIFI_PASSWORD'))
pool = socketpool.SocketPool(wifi.radio)
context = ssl.create_default_context()
requests = adafruit_requests.Session(pool, context)
print(f"Fetching from {TEXT_URL} without certificate (should fail)")
try:
response = requests.get(TEXT_URL)
except Exception as e:
print(f"Failed: {e}")
else:
print(f"{response.status_code=}, should have failed with exception")
print("Loading server certificate")
with open("/self-signed.pem", "rb") as certfile:
context.load_verify_locations(cadata=certfile.read())
requests = adafruit_requests.Session(pool, context)
print(f"Fetching from {TEXT_URL} with certificate (should succeed)")
try:
response = requests.get(TEXT_URL)
except Exception as e:
print(f"Unexpected exception: {e}")
else:
print(f"{response.status_code=}, should be 200 OK")
```
Tested with badssl.com:
1. Get client certificates from https://badssl.com/download/
2. Convert public portion with `openssl x509 -in badssl.com-client.pem -out CIRCUITPY/cert.pem`
3. Convert private portion with `openssl rsa -in badssl.com-client.pem -out CIRCUITPY/privkey.pem` and the password `badssl.com`
4. Put wifi settings in CIRCUITPY/.env
5. Run the below Python script:
```py
import os
import wifi
import socketpool
import ssl
import adafruit_requests
TEXT_URL = "https://client.badssl.com/"
wifi.radio.connect(os.getenv('WIFI_SSID'), os.getenv('WIFI_PASSWORD'))
pool = socketpool.SocketPool(wifi.radio)
context = ssl.create_default_context()
requests = adafruit_requests.Session(pool, context)
print(f"Fetching from {TEXT_URL} without certificate (should fail)")
response = requests.get(TEXT_URL)
print(f"{response.status_code=}, should be 400 Bad Request")
input("hit enter to continue\r")
print("Loading client certificate")
context.load_cert_chain("/cert.pem", "privkey.pem")
requests = adafruit_requests.Session(pool, context)
print(f"Fetching from {TEXT_URL} with certificate (should succeed)")
response = requests.get(TEXT_URL)
print(f"{response.status_code=}, should be 200 OK")
```
Closes: #7017
* Remove the 'GP23' alias for CYW1
* Remove the 'CYW0' alias for CYW0
* Switch VBUS_SENSE to CYW2, remove 'GP24' alias
Code that wants to use SMPS_MODE, VBUS_SENSE and LED while being
portable to the W and non-W variants should use those names, not alias
names.
* Remove A3 / VOLTAGE_MONITOR
Right now this cannot be used. The ability to check the voltage monitor
should be added back in some fashion in the future.
This is intended (but not entirely verified) to match our esp32 builds.
It does fix accessing https://circuitpython.org, which failed before with
"MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE".
It still doesn't work on a personal website of mine with valid letsencrypt
certificate but I haven't verified whether it works on esp32s2 with CP.
That site only allows TLS 1.3, while this mbedtls only supports up to
1.2.
The version of mbedtls we adopted based on micropython's use has no
TLS 1.3 support, but the one in espressif esp-idf does.
Note: at this time, the ssl module on pico_w never verifies the server
certificate. This means it does not actually provide a higher security
level than regular socket / http protocols.
Before this, CIRCUITPY would start at 1MB anyway. This appeared to work
only because I hadn't checked the actual size of the CIRCUITPY drive,
and because until now the flash hadn't actually crossed that 1MB
boundary into CIRCUITPY storage.
WARNING: on pico_w, upgrading/downgrading CircuitPython across this commit
boundary will erase the CIRCUITPY filesystem. After this commit,
switching between pico and pico_w firmware will erase the CIRCUITPY
filesystem
.. the value actually needs to be enforced each time the STA or AP
is enabled, because internally there's a call to cyw43_wifi_pm with the
library's defaut power management value, not ours.
Add a getter, though it only returns our idea of what the power
management register is set to, it doesn't read out from the actual
hardware, sadly.
Originally, black_bindings found each contiguous "//|" block and sent
it to black independently. This was slower than it needed to be.
Instead, swap the comment prefix: when running black, take off
"//|" prefixes and put "##|" prefixes on all un-prefixed lines.
Then, after black is run, do the opposite operation
This more than doubles the overall speed of "pre-commit run --all",
from 3m20s to 55s CPU time on my local machine (32.5s to under 10s
"elapsed" time)
It also causes a small amount of churn in the bindings, because
black now sees enough context to know whether one 'def' follows another
or ends the 'def's in a 'class'. In the latter case, it adds an extra
newline, which becomes a "//|" line.
I'm less sure why a trailing comma was omitted before down in
rp2pio/StateMachine.c but let's roll with it.
My pings go out, and then they come back
```py
import os
import wifi
import ipaddress
wifi.radio.connect(os.getenv('WIFI_SSID'), os.getenv('WIFI_PASSWORD'))
ipv4 = ipaddress.ip_address("8.8.4.4")
print("Ping google.com: %f ms" % (wifi.radio.ping(ipv4)*1000))
```
a NULL first pin object is used to indicate that there are zero
of some kind of pin associated with the StateMachine. However,
mask_and_rotate wasn't checking for zero. It actually read data from
near address 0x0 and (in my case) got a nonzero mask, which then
caused a program with GPIO11 and GPIO12 as input with pull-up and no
out pins to erroneously encounter the error "pull masks conflict with
direction masks"
Totally untested change (will try with the artifact), but I think every board should have a board.LED if possible to be able to use the learn guide basic instruction.
- define CIRCUITPY_BUILD_EXTENSIONS to predefined values
- set CIRCUITPY_BUILD_EXTENSIONS in port and board config
- reuse the support matrix "get_settings_from_makefile" to get it
- move the existing port and board specific values
- remove the C3 specific board values because it's not the default
- update build_release_files.py to use get_settings_from_makefile
.. 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.
