A new flexible and powerful "pluggable discovery" system was added to the Arduino boards platform framework. This system
makes it easy for Arduino boards platform authors to use any arbitrary communication channel between the board and
development tools.
Boards platform configurations that use the old property syntax are automatically translated to the new syntax by
Arduino CLI:
https://arduino.github.io/arduino-cli/latest/platform-specification/#sketch-upload-configuration
> For backward compatibility with IDE 1.8.15 and older the previous syntax is still supported
This translation is only done in platforms that use the old syntax exclusively. If `pluggable_discovery` properties are
defined for the platform then the new pluggable discovery-style `upload.tool.<protocol_name>` properties must be defined
for each board as well.
This platform includes a "UF2 Devices" discovery tool for `uf2conv` protocol ports. This tool now uses the modern
Arduino pluggable discovery system. `pluggable_discovery` properties were added to `platform.txt` in order to configure
the Arduino development tools to use this pluggable discovery tool. The `upload.tool.<protocol_name>` properties in
`boards.txt` were not updated at that time.
Global properties of that name were added to platform.txt, but this approach is not provided for by the Arduino Platform
specification:
https://arduino.github.io/arduino-cli/latest/platform-specification/#sketch-upload-configuration
> A specific upload.tool.<protocol_name> property should be defined for every board in boards.txt:
Those missing properties caused uploads to fail for users of the recent versions of Arduino IDE and Arduino CLI with an
error of the form:
Error during Upload: Property 'upload.tool.<protocol_name>' is undefined
(where `<protocol_name>` is the protocol of the selected port, if any)
It is also important to provide compatibility with versions of Arduino development tools from before the introduction of
the modern pluggable discovery system. For this reason, the old style `<board ID>.upload.tool` properties are retained.
Old versions of the development tools will treat the `<board ID>.upload.tool.<protocol_name>` properties as an unused
arbitrary user defined property with no special significance and the new versions of the development tools will do the
same for the `upload.tool` properties.
* analogWrite: fix overflow and wrap value (#917)
-avoid overflow when calculating analogScale * analogFreq, perform
the multiplication in floating point.
-use analogScale - 1 to set the PWM wrap value. Wrap is the highest
value the counter reaches, not the counter period.
* analogWrite: increase frequency range (#917)
- increase frequency range to 10 MHz
- decrease the lowest allowed resolution to 2 bits, and the
minimal analogRange value to 3. This makes 10 MHz output possible
with system clock frequencies down to 50 MHz.
- allow clkdiv values >= 1.0, was 2.0. This makes it possible to
manually set frequency and analogRange so that
frequency * analogRange = system clock frequency.
This gives the best possible frequency accuracy and
resolution.
Random crashes, infinite loops, and other lockups were happening to the PicoW
while under high load from multiple clients.
This seems to have been due to two issues:
* The periodic sys_check_timeouts() call from an alarm/IRQ was happening while
the core was in LWIP code. LWIP is not re-entrant or multi-core/thread safe
so this is a bad thing. Some calls may not have been locked with a manual
addition of the LWIPMutex object to hit this.
* The WiFi driver supplies packet data during an interrupt. PBUF work is
legal in an interrupt, but actually calling netif->input() from an IRQ to
queue up the Ethernet packet for processing is illegal if LWIP is already
in progress.
Rearchitect the LWIP interface to fix these problems:
* Disable interrupts during malloc/etc. to avoid the possibility of the
periodic LWIP timeout check interrupting and potentially calling user
code which did a memory operation
* Wrap all used LWIP calls to note LWIP code will be executing, instead of
manually eyeballing and adding in protection in user code.
* Remove all user code LWIPMutex blocking, the wrapping takes care of it.
* When an Ethernet packet is received by interrupt and we're in LWIP code,
just throw the packet away for now. The upper layers can handle retransmit.
(A possible optimization would be to set the packet aside and add a
housekeeping portion to the LWIP wrappers to netif->input() them when safe).
* Ignore callbacks during TCP connection teardown when the ClientContext
passed from LWIP == nullptr
noInterrupts/interrupts use a stack to allow multiple calls to work
properly. The original code was using a std::stack which will use
malloc() to allocate entry space. This seems like a bad idea, and
makes it so it's impossible to disable interrupts for malloc/free,
etc.
Define a fixed stack size and use straight C code to manage the IRQ
stacks. Slightly more fixed memory requirements, but significantly
lower total RAM requirements and no malloc() dependency.
When moving between different modes or even WiFi.begin/ends, any setting
of the IPs will fail because the internal flag _started was not cleared.
Clear _started on a ::end call.
Fixes#884
Allow the IDE to detect UF2 volumes (i.e. when you hold BOOTDEL and
plug in the board).
Allows the IDE2 to properly upload using OTA and serial.
Fixes#890 and others
Call `rp2040.enableDoubleResetBootloader()` anywhere in the code to
enable the check. W/o that call, the checker will be linked in.
See #892
CORE1 doesn't start until well after the C runtime initialization,
so the flag won't be overwritten.
Also increase timeout to 350ms because OTA bootup can be
slow.
