The motivation for doing this is so that we can allow
common_hal_mcu_disable_interrupts in IRQ context, something that works
on other ports, but not on nRF with SD enabled. This is because
when SD is enabled, calling sd_softdevice_is_enabled in the context
of an interrupt with priority 2 or 3 causes a HardFault. We have chosen
to give the USB interrupt priority 2 on nRF, the highest priority that
is compatible with SD.
Since at least SoftDevice s130 v2.0.1, sd_nvic_critical_region_enter/exit
have been implemented as inline functions and are safe to call even if
softdevice is not enabled. Reference kindly provided by danh:
https://devzone.nordicsemi.com/f/nordic-q-a/29553/sd_nvic_critical_region_enter-exit-missing-in-s130-v2
Switching to these as the default/only way to enable/disable interrupts
simplifies things, and fixes several problems and potential problems:
* Interrupts at priority 2 or 3 could not call common_hal_mcu_disable_interrupts
because the call to sd_softdevice_is_enabled would HardFault
* Hypothetically, the state of sd_softdevice_is_enabled
could change from the disable to the enable call, meaning the calls
would not match (__disable_irq() could be balanced with
sd_nvic_critical_region_exit).
This also fixes a problem I believe would exist if disable() were called
twice when SD is enabled. There is a single "is_nested_critical_region"
flag, and the second call would set it to 1. Both of the enable()
calls that followed would call critical_region_exit(1), and interrupts
would not properly be reenabled. In the new version of the code,
we use our own nesting_count value to track the intended state, so
now nested disable()s only call critical_region_enter() once, only
updating is_nested_critical_region once; and only the second enable()
call will call critical_region_exit, with the right value of i_n_c_r.
Finally, in port_sleep_until_interrupt, if !sd_enabled, we really do
need to __disable_irq, rather than using the common_hal_mcu routines;
the reason why is documented in a comment.
This pulls all common functionality into `shared-bindings` and keeps
platform-specific code inside `nrf`. Additionally, this performs most
validation in the `shared-bindings` site.
The only validation that occurs inside platform-specific `common-hal`
code is related to timeout limits that are platform-specific.
Additionally, all documentation is now inside the `shared-bindings`
directory.
Signed-off-by: Sean Cross <sean@xobs.io>
For `microcontroller.reset()`, don't manually call NVIC_SystemReset().
Instead, call the `port_reset()` in case the port wants to do any
cleanup.
Signed-off-by: Sean Cross <sean@xobs.io>
This adds preliminary support for the nRF52833, which is a variant of
the nRF52840 with half the RAM, half the flash, and fewer peripherals.
Signed-off-by: Sean Cross <sean@xobs.io>
This started while adding USB MIDI support (and descriptor support is
in this change.) When seeing that I'd have to implement the MIDI class
logic twice, once for atmel-samd and once for nrf, I decided to refactor
the USB stack so its shared across ports. This has led to a number of
changes that remove items from the ports folder and move them into
supervisor.
Furthermore, we had external SPI flash support for nrf pending so I
factored out the connection between the usb stack and the flash API as
well. This PR also includes the QSPI support for nRF.
This commit cleans up the pin generation code, all the pins and their
AF (only ADC, for now) are specified in nrf52_af.csv and board use their
own csv file to specify which pins are available on that board and if
they have any special names.
Before this change, `microcontroller.cpu.uid` returned values
where the top 4 bits of each byte were zero, because of
an incorrect bitmask used in this function.
