GitLab

Fixes #348

Add the RTC header path in the SDK to the Arduino build path.  Also add
pico_utils to the libpico.a for the datetime_to_str call.

Note that the pico_sdk has a bug in the datetime.h header so you need to
manually bracket the include file as "C":

extern "C" {
    #include "pico/util/datetime.h"
}

By default RTTI (Run-Time Type Information) is disabled because most apps
don't need run time type info enabled.  However, certain libraries expect
to be able to query types of objects at runtime, so add a menu to enable it.

In `pinMode()` I think it would be better to call `gpio_disable_pulls()` on the ulPin when ulMode == INPUT.
Adding `gpio_disable_pulls(RP_PIN);` after `pinMode(RP_PIN, INPUT);` solves the issue.

Fixes #312

* Add package.json

To make package easily integratable with PlatformIO

* Correct name back to original one

* Format package.json

* Add first shot at builder script

* Add USB stack flags, fix compile flags

* Formatting

* Add more link & USB flags

* Build Boot2 bootloader

* Formatting

* Generate linkerscript, linker fixes

* Fix linkflags, make firmware runnable

* Update USB flags and RAM size

* Correct USB flags, add dynamic sketch partitioning

* Restructure filesystem size and flash size logic into platform code

* Move C++ only flags to CXXFLAGS

* Add PlatformIO documentation

* Link to new platform.io document in the docs TOC

* Fix typos in platformio docs

* Fix one additional typo in platformio.rst

* Update docs

* Remove wrongly commited build folder

Reset the SDA and SCL pins to INPUT at Wire.end() to prevent multiple pins connected to I2C when changing pins (#302)

Fixes #289

Per #276, #277, #274 there seems to be an issue with interrupts and some
other low-level ARM operations when using the distributed libstdc++.

Use the default libstdc++ built with the toolchain, instead.

Fixes #277
Fixes #276
Fixes #274

* Adds support for Challenger RP2040 WiFi boards

* Added Challenger board to makeboards build script

* Adds new challenger board with LTE modem.

* Updated after getting approved PID from Raspberry Pi

Identify some spots that GCC's -fanalyzer noted might need nullptr
checks, and add them.

Use the existing Arduino Stream method of setTimeout to set the Wire
I2C timeout delay.

Fixes #260

When LittleFS.begin() or SDFS.begin() is called after the filesystem is
already mounted, don't unmount/remount.  When an unmount happens, all old
Files become invalid (but the core doesn't know this), so you would end
up with random crashes in FS code.

Now, check for _mounted, and if so just return immediately from begin().

you had "esrle" instead of "earle" in the GH URL :)

Wire::requestFrom() returns the number of bytes read from the slave.  In
the case of error, the slave can end up returning a very large integer
for PICO_GENERIC_ERROR which would then be used as the # of bytes read
causing crashes and errors.

Running TalkingToMyself without connecting the I2C ports would show
this behavior.

Now, when PICO_GENERIC_ERROR is returned, set the read-back buffer len
to 0 explicitly.

When a Python MSI/etc. is installed under Windows, it sets a global
PYTHONHOME and other variables.  Our shipped Python can end up using
these variables and attempt to load the wrong PYC files and fail
to run.

Avoid by using -I isolated mode in Python calls

Fixes #252

Use a libstdc++ compiled with -fno-exceptions to avoid including the
code needed to unwind C++ exceptions.

Saves ~4K RAM and ~5K flash.

The PWM HW can only divide 125MHZ sysclk by 1...256.  That's only down to
about 500khz.  If the max count of the PWM (analogWriteScale) is too low
then the actual PWM period will be much less than desired (and PWM frequency
of course much higher).

For example, at analogWriteFreq(100); analogWriteScale(256); the true
PWM period would be 125M / 256 (pwmdiv) / 256 (scale) = ~2khz.

Conversely, at high frequencies and large scales it is impossible to achieve
the requested frequency and a much lower one would be generated.  For
example: freq(60K), scale(32768). PWM period = 125M / 1 (pwmdiv) / 32768 =
~4kHz.

Avoid this by adjusting the analogWrite scale in the core to either increase
the PWM count for low frequencies, or decrease it for high frequencies.
This is done behind the scenes and code is not required to be changed.

The PWM frequency will still not be perfcetly exact due to the divider HW
and clocks involved, but it will be very close across the whole range.

Fixes #234