Since a long time now, mp_obj_type_t no longer refers explicitly to
mp_stream_p_t but rather to an abstract "const void *protocol". So there's
no longer any need to define mp_stream_p_t in obj.h and it can go with all
its associated definitions in stream.h. Pretty much all users of this type
will already include the stream header.
Also, re-enable calibration storage for CircuitPlayground Express.
Tested with a 500hz PWMOut on Metro M0 with Saleae:
* with crystal 500hz
* with usb 500hz +- 0.1hz
* without either 487hz += 0.1hz
SAMD51 is skipped due to DFLL errata and the fact it defaults to a
factory calibrated 48mhz that works fine for USB.
Fixes#648
We can provide a basic version of mp_errno_to_str even if the uerrno
module won't be provided. Rather than looking errno names up in the
uerrno module's globals dict, we'll just rely on a simple mapping in the
function itself.
This uses the crystal to clock the RTC on boards which have a crystal.
Disable clock generator 2 which was enabled in commit
8e2080411f ("atmel-samd: Add rtc module support").
samd51 differs from samd21 when it comes to the RTC clock. samd51 doesn't
have an explicit clock peripheral so no need for a clock generator.
The same commit didn't even setup XOSC32K correctly, it missed EN1K and XTALEN.
The RTC uses the 1k clock output, so enable it on the OSCULP32K even if it works without it.
Refactor the convoluted asf4 clock setup into something more readable.
enable_clock_generator() has 2 changes:
- Set 'Output enabled' to match the current clock setup
- Handle divisors above 511
Add an enable_clock_generator_sync() version which makes it possible to setup
clocks without waiting for syncing. The bootup would hang without this.
I have checked these registers:
NVMCTRL->CTRLA = 0x00000004
Peripheral clocks (only non-zero shown):
PCHCTRL[1]=0x00000045
PCHCTRL[10]=0x00000041
Generator clocks (only non-zero shown):
GENCTRL[0] = 0x00010907
GENCTRL[1] = 0x00010906
-GENCTRL[2] = 0x00041104
+GENCTRL[2] = 0x00200904
GENCTRL[4] = 0x00010907
GENCTRL[5] = 0x00180906
DFLL clock:
OSCCTRL->DFLLCTRLA = 0x00000082
OSCCTRL->DFLLCTRLB = 0x00000000
OSCCTRL->DFLLVAL = 0x00008082
OSCCTRL->DFLLMUL = 0x00000000
DPLL clocks:
OSCCTRL->Dpll[0].DPLLCTRLA=0x00000002
OSCCTRL->Dpll[0].DPLLCTRLB=0x00000000
OSCCTRL->Dpll[0].DPLLRATIO=0x0000003b
OSCCTRL->Dpll[1].DPLLCTRLA=0x00000080
OSCCTRL->Dpll[1].DPLLCTRLB=0x00000020
OSCCTRL->Dpll[1].DPLLRATIO=0x00000000
OSC32KCTRL clock:
OSC32KCTRL->RTCCTRL = 0x00000000
OSC32KCTRL->XOSC32K = 0x00002082
OSC32KCTRL->CFDCTRL = 0x00000000
OSC32KCTRL->EVCTRL = 0x00000000
OSC32KCTRL->OSCULP32K = 0x00002300
Only gen2 changed which is due to samd51 having more bits in the simple
division register so DIVSEL wasn't necessary, and it didn't have OE set.
The Wiznet5k series of chips support a MACRAW mode which allows the host to
send and receive Ethernet frames directly. This can be hooked into the
lwIP stack to provide a full "socket" implementation using this Wiznet
Ethernet device. This patch adds support for this feature.
To enable the feature one must add the following to mpconfigboard.mk, or
mpconfigport.mk:
MICROPY_PY_WIZNET5K = 5500
and the following to mpconfigboard.h, or mpconfigport.h:
#define MICROPY_PY_LWIP (1)
After wiring up the module (X5=CS, X4=RST), usage on a pyboard is:
import time, network
nic = network.WIZNET5K(pyb.SPI(1), pyb.Pin.board.X5, pyb.Pin.board.X4)
nic.active(1)
while not nic.isconnected():
time.sleep_ms(50) # needed to poll the NIC
print(nic.ifconfig())
Then use the socket module as usual.
Compared to using the built-in TCP/IP stack on the Wiznet module, some
performance is lost in MACRAW mode: with a lot of memory allocated to lwIP
buffers, lwIP gives Around 750,000 bytes/sec max TCP download, compared
with 1M/sec when using the TCP/IP stack on the Wiznet module.
It should be up to the NIC itself to decide if the network interface is
removed upon soft reset. Some NICs can keep the interface up over a soft
reset, which improves usability of the network.
If mbedtls_ctr_drbg_seed() is available in the mbedtls bulid then so should
be mbedtls_entropy_func(). Then it's up to the port to configure a valid
entropy source, eg via MBEDTLS_ENTROPY_HARDWARE_ALT.
Otherwise the "sock" member may have an undefined value if wrap_socket
fails with an exception and exits early, and then if the finaliser runs it
will try to close an invalid stream object.
Fixes issue #3828.
