Semihosting is handy for debugging, so allow the core to use `SerialSemi` as the
::printf port. Add menu item to the IDE to allow selection.
Add RISC-V implementation of semihost call
Adds a menu item to enable onboard profiling. This requires significant
RAM and really only makes sense on devices with PSRAM to store the state.
When the menu item is selected, allocates RAM and tracks function calls and
periodically samples the PC to generate a histogram of application usage.
The onboard gmon.out file can be written over Semihosting or
some other way to transfer to a PC for analysis.
Adds a profiling example with command lines.
* Migrate RP2040-specific bits to separate dirs
* Add chip to boards.txt, isolate RP2040-specifics
* Add RP2350 boot2, bearssl, and libraries
* Platform.IO adjust to new paths
* Add RPIPICO2 JSON for P.IO
* Add RP2350 to Platform.io
* Update Picotool and OpenOCD for all hosts
* Use picotool to generate UF2s
* Build separate libpico blobs serially
Thanks for the review, @aarturo182 !
* Add RP2350 to CI
* Allow Ethernet/WiFi building for RP2350
* Update Adafruit TinyUSB to latest
* Test skip fix
* Make RP2350 Picotool work. update USB ID
* Fix EEPROM/FS flash locations
RP2350 adds a 4K header sector to the UF2, meaning we have 4K less total
flash to work with. Adjust all constants appropriately on the RP2350.
* Adds ilabs board and PSRAM support. (#2342)
* Adds iLabs boards and basic PSRAM support.
* Make PSRAM come up as part of chip init
Uses SparkFun psram.cpp to set timings on clocks which are defined in the
variant file. Prefix things with RP2350_PSRAM_xxx for sanity.
Users don't need to call anything, PSRAM "just appears". Still need to
add in malloc-type allocation.
* Add board SparkFun ProMicro RP2350
Same pinout as the SparkFun ProMicro RP2040 with 8MB PSRAM and RP2350
* Add TLSF library for use w/PSRAM
Fork of upstream to include add'l C++ warning fixes.
* Add pmalloc/pcalloc to use PSRAM memory
free() and realloc() all look at the pointer passed in and jump to the
appropriate handler. Also takes care of stopping IRQs and taking the
malloc mutex to support multicore and FreeRTOS (when that workd)
* Fix BOOTSEL for RP2350
* Add simple rp2040.idleOtherCore test
* Add Generic RP2350 and clean up PSRAM menus
Commercial boards now only have 1 size PSRAM, no need to have menu for them.
* Add Solder Party RP2350 Stamp boards (#2352)
* Add PSRAM heap info helpers, mutex lock mallinfo
* Add RP2350 docs
* FreeRTOS and OTA unsupported warnings for RP2350
RP2040::memcpyDMA implements a DMA-controlled memory copy call identical in
function to standard memcpy, but using an onboard DMA engine. For large
memory transfers this can be significantly faster than using the CPU-based
memcpy. Only 4-byte aligned source, destination, and counts are allowed.
If any inputs are not 4-byte aligned, then standard memcpy will occur so
it will behave correctly for any inputs.
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.
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.
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.
