GitLab

Fixes #578

Need to munge the platform.txt on release.

Fixes #576

Co-authored-by: Arya11111 <xuepeng@dfrobot.com>

Reverse the order of IRQ and idle restore to match the way
they were initiated.

Rewrite the I2S code from scratch to eliminate the dependence on the
pico-extras implementation and to support I2S input as well.

8-bit, 16-bit, 24-bit, and 32-bit words are supported.

Multiple I2S ports are allowed (theoretically up to 6 because
2 DMA channels are required per port).

I2S input and I2S output are supported.

Add input example

Fixes #535
Fixes #99
Fixes #562

Co-authored-by: Stephan Korner <stephan.korner@trihow.com>

Thanks to @StefanKellerAC !

The chip supports 133MHz and the other Pico core already defaults to
the higher speed, so make 133 the default.

It can still be changed through the menus and will stay at 125 unless
pre-existing users change it so they will see no difference.

To remove compiler warning the valid core macro was modified to only check
that the core passed in was < # of total cores.  Unfortunately there are
parts of the FreeRTOS code where the passed in core # is -1.  The upstream
catches this and returns FALSE, but my hacked version returned TRUE.  This
caused interesting memory corruption errors and crashes when the
current task block[-1] was updated.

Undo the change and fix the 1 spot where a warning happens instead.

Undo the forced compiler -O0 for port.c, it was only masking the fault.

Use low power WFE when idle.

Set PORT.C to built `-O0` always because it seems to occasinally end
up with interrupts disabled in task code, causing the SYSTICK never to
fire and killing task switching.

No need for dynamic exceptions.  We don't move the execbase.

Alabaster is not my favorite, try something with colors...

Adds code to define which pins are used, moving them from the defaults, which are the same as the only three analogue input pins, and adding comments to explain how to change them.

The original didn't give any clues about which pins were used, which isn't ideal for a beginner - it was necessary to look at the code for the library, to work that out.

The new code redundantly defines a pWS pin number (as pBCLK+1), which isn't used in the example, but is meant as a reminder to the person using it, of how to wire up WS.

Using all the work from @hfellner and others, add FreeRTOS
SMP support.

Allow idling cores through the FreeRTOS FIFO queue to
allow for file system and EEPROM support.

Make delay a weak function so FreeRTOS can override.

Add cycle count support under FreeRTOS using a PIO SM.

Use a task-based approach for handling the USB periodic work
instead of the IRQ-based one in the main core.

Set 8 prio levels so it fits in 3 bits nicely (0..7).

I receive mails weekly asking how to use `SoftwareSerial` on this core.
Avoid the issue by including a simple wrapper class around `SerialPIO`
which gives the proper class name and constructor parameters.

Note that inverted mode is not supported.

Matching the Arduino SoftwareSerial API

Fixes #522

Adjust the 1/2 bit time to match the number of extra cycles in the actual
PIO loop.

Throw out the entire start bit, which results in sampling the data at the
midpoint and not the starting time of a bit (which was causing random
failures on read data).

Tested at 300bps all the way to 2,000,000bps using a loopback connection.

Fixes #360

Fixes #537

Fixes #524

* Avoid "chunkiness" of UART FIFO availability

The UART FIFO will generate an IRQ to transfer data into the SerialUART
FIFOs either every 4 received bytes, or every 4 idle byte times.  This
causes the ::available count to report "0" until either of those two
cases happen, causing a potentially delay in data becoming available to
the app.

Change the code to pull data from the HW FIFO on a read/available/peek.
Use a non-blocking mutex and IRQ disabling to safely empty the FIFO from
user space.  The mutex added to the IRQ is non-blocking and will be
a single CAS the vast majority of the time, so it should not impact the
Serial performance.

Fixes #464 and others where `setPollingMode()` was needed as a workaround.

Make sure we have all mutexes locked before we disable the port and free
the queue to avoid evil cases.

Only init the mutexes once, on object creation.

In polled mode, don't bother acquiring/releasing the fifo mutex.

When begin() is called on an already running port, call end() to clean
up the old data/etc. before making a new queue/config.  This avoids a
memory leak and potential write-after-free case.

Originally from https://github.com/episource/platform-raspberrypi/blob/my-platform-pico/builder/frameworks/arduino-pico/arduino-pico.py#L104-L115

Define ARDUINO_PICO_MAJOR/_MINOR/_REVISION for app use and update the
Platform.IO and Arduino files for a new release version.

Fixes #309
Fixes #487