* 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
Add definitions for compatibility to many platforms and libraries
- clockCyclesPerMicrosecond()
- clockCyclesToMicroseconds(a)
- microsecondsToClockCycles(a)
Older builds included C++ locale information in RAM/flash as well as a
bunch of exception code which can't get called since they're not enabled.
Remove them by adjusting final link command and not instantiating them
in main.cpp in the first place.
Blink went from:
> Sketch uses 215604 bytes (10%) of program storage space. Maximum is 2093056 bytes.
> Global variables use 18152 bytes (6%) of dynamic memory, leaving 243992 bytes for local variables. Maximum is 262144 bytes.
To:
> Sketch uses 56112 bytes (5%) of program storage space. Maximum is 1044480 bytes.
> Global variables use 12152 bytes (4%) of dynamic memory, leaving 249992 bytes for local variables. Maximum is 262144 bytes.
For a savings of **155KB of flash** and **6KB of RAM**
Most users w/the Library Manager will get a little nervous with the GH site.
The ReadTheDocs site includes links to the GH site, too, so they can still
find the origin.
BOOTSEL needs to be multicore protected, too.
Reading BOOTSEL required disabling the flash interface, so the other
core needs to be idles while this runs.
Make the PIO program object multicore safe, too, so that if both cores
try to load a program they won't step on each other.
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.
