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().
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.
* update included tinyusb to 1.2.0
move tusb_config.h from core to library for more portability
* pump tinyusb
* update tinyusb to 1.3.0
* try to fix ci warning
Use the 24-bit SYSTICK peripheral, wrapped in logic to extend it to a
full 32 or 64bits. W/o the wrapper, SYSTICK will wrap around in ~100ms.
Adds rp2040.getCycleCount() and rp2040.getCycleCount64()
Clean up the libpico build process as crt0.S from the pico-sdk should
be directly used.
Clean up the keywords file.
Fixes#222
The HW needs to have the TXC_ABRT flag cleared when a slave transmission is
cut short by the master, or else it will effectively break the I2C bus and
never recover.
The O_CREAT/etc. flags on the Pico are a full 32-bits in size, but the
core was generating a flag for SdFat using an 8-bit type, so all the
O_CREAT, O_TRUNC, O_APPEND, etc. flags got cut off.
Fix the flag size.
Fixes#214
The PIO programs that generate tone() and Servo() use the TX FIFO to
receive updates to the period/duty cycle.
The original code would push into the FIFO (potentially blocking the
app if the FIFO was full) and generate at least one cycle of every
value written into the control. Basically, the output would
lag the changes by 1 cycle or more (which could be 20ms+ on Servo).
Fix this by clearing any old, ungrabbed values from the FIFO before
sending a new one to the program. Instead of a FIFO, there is
effectively now just a control register and updates will be immediate.
Update the Siren.ino example with delays because now the tone() calls
will not block and run 10x+ faster.
Fixes#121
Supersedes #185
Redo the PIO program to allow the tone generator on a pin to be updated
without interruption, at waveform boundaries. This allows for things like
sirens or slurs to be implemented simply.
Use an alarm, not the PIO hardware, to manage time-limited tones().
Add a simple siren example.
When multiple libraries contain files matching an #include directive in the program, the Arduino build system must pick
one to use for compilation. Multiple factors are used in order to make an intelligent determination of which library is
best.
In order to enhance this determination, the closeness of match between the library.properties name value and the
filename in the #include directive is being added as one of those factors. This new factor is referred to as
"Library Name Priority".
Unfortunately, this change can result in platform bundled libraries which had previously been correctly correctly chosen
no longer being given priority over their equivalent standalone libraries, which may be incompatible or not optimized
for the platform's boards.
This priority inversion only occurs when all the following conditions are true:
- There is a standalone library installed which provides a header filename collision.
- The platform bundled library is architecture optimized (e.g., architectures=esp32).
- The standalone library is architecture compatible (architectures=*).
- The standalone library has equal "Folder Name Priority".
- The standalone library has better "Library Name Priority" (e.g., name=SD vs name=SD(ESP32) for a library with primary
header file SD.h.
The fix is to simply give the platform bundled library a perfect "Library Name Priority".
Some platform bundled libraries were given a modified name as a workaround to a bug in the Arduino IDE's Library Manager
which caused Library Manager to always show the library as updatable under specific circumstances. That bug was fixed in
Arduino IDE 1.8.6, ~3 years ago.
Fixes#169
Trying to change pinout while running, or to an illegal configuration,
will now immediately panic() with an error message. Such an attempt
is a pretty big problem since pinouts are hardware related/static.
Prior code would fail silently and return false, but nobody checked
the setXXX return values, anyway.
Fixes#167
For Serial when selecting TinyUSB. Can't include in the core because Arduino IDE
will not link in libraries called from the core. Instead, add the header to all
the standard libraries in the hope it will still catch some user cases where they
use these libraries.
See https://github.com/earlephilhower/arduino-pico/issues/167#issuecomment-848622174
* initial tinyusb lib port
* add Adafruit_TinyUSB_Arduino as submodules
* add yield() to main loop
* sync with tinyusb lib latest
* add USB manufacturer and product
* fix typo in tinyusb lib
* sync with master
updating implementation
* Rationalize link stage command line
Make the build process less insane.
* clean up delay
* clean up platform and board
* update makeboards.py for generating usbstack menu
* update tinyusb lib to 1.0.0
Update pico-sdk to 1.1.2
Add methods to block the opposite core while doing flash updates.
Ensure opposite core is stopped in LittleFS and EEPROM while doing
flash updates.
Update documentation with new calls.
Support running code on the second core by adding a setup1() and/or
a loop1() routine to a sketch. These functions operate exactly like
the normal Arduino ones, and anything they call will be run on
the second core automatically.
Add a simple multicore example.
Fix the drive logic for pullup and pulldown inputs.
Add a bitbanged I2C ACK checker for 0-byte I2C transfers (since the HW
doesn't support it).
Add a timeout on I2C reads and writes so they don't hang forever if a
device is not present.
Fixes#38
Use a constexpr template to calculate the valid pins for different IO
hardware. This lets us have an easily readable list of pin numbers that
we can adjust/check.
Avoid any short pulses which could cause servo twitches or damage by
adding a shutdown command to the PIO program and checking it's in that
safe part of the loop before detaching the servo.
