Releases: bxparks/AceRoutine
Releases · bxparks/AceRoutine
v1.5.1 - upgrade tool chain; add Adafruit nRF52 boards to Tier 2 support
- 1.5.1 (2022-09-20)
- Add Adafruit nRF52 boards to "Tier 2" after validation by community
member. - Upgrade tool chain
- Arduino CLI from 0.19.2 to 0.27.1
- Arduino AVR Core from 1.8.4 to 1.8.5
- STM32duino from 2.2.0 to 2.3.0
- ESP32 Core from 2.0.2 to 2.0.5
- Teensyduino from 1.56 to 1.57
- Add Adafruit nRF52 boards to "Tier 2" after validation by community
v1.5.0 - add profiling; add coroutine names
- 1.5.0 (2022-03-19)
- (Re)add support for human-readable coroutine names.
- See Coroutine Names in the
USER_GUIDE.md
. - Adds the following methods to the
Coroutine
class:setName()
,
setName()
,getCName()
,getFName()
,getNameType()
, and
printNameTo()
. - Resource consumption
- Increases flash usage by 6-10 bytes per coroutine.
- Increases static ram usage by 3 bytes (AVR) or 4 bytes (32-bit)
per coroutine, plus the additional storage for the string itself.
- See Coroutine Names in the
- Support profiling of
Coroutine::runCoroutine()
execution time.- See Coroutine Profiling in the
USER_GUIDE.md
. - API changes
- Add
CoroutineProfiler
interface with aupdateElapsedMicros()
method. - Add
Coroutine::setProfiler()
to store the profiler pointer. - Add
Coroutine::runCoroutineWithProfiler()
which measures the
elapsed time ofrunCoroutine()
and calls
CoroutineProfiler::updateElapsedMicros()
. - Add
CoroutineScheduler::runCoroutineWithProfiler()
which calls
Coroutine::runCoroutineWithProfiler()
instead of the normal
Coroutine::runCoroutine()
. - Add
CoroutineScheduler::loopWithProfiler()
public static method
which callsrunCoroutineWithProfiler()
.
- Add
- Provide
LogBinProfiler
subclass ofCoroutineProfiler
.- Keeps a frequency count of the elapsed microseconds using 32 bins
representing thelog2()
function of the elapsed microseconds.
- Keeps a frequency count of the elapsed microseconds using 32 bins
- Provide 2 renderers of
LogBinProfiler
:LogBinTableRenderer::printTo()
prints a formatted table of the
frequency count over all coroutines. This represents a poor-man's
version of the log-log graph of the frequency count.LogBinJsonRenderer::printTo()
prints the frequency count
in JSON format.
- See HelloCoroutineWithProfiler
and HelloSchedulerWithProfiler. - Thanks to peufeu2@ who provided the ideas and proof of concept in
Discussion#50.
- See Coroutine Profiling in the
- Coroutine consumes more static RAM
- due to extra pointers to support
setName()
andsetProfiler()
- 8-bits: increases from 11 bytes to 16 bytes per coroutine
- 32-bits: increases from 20 bytes to 28 bytes per coroutine
- due to extra pointers to support
- Move
Coroutine::sStatusStrings
toPROGMEM
- Saves 12 bytes of static RAM on AVR and 24 bytes on ESP8266, if
CoroutineScheduler::list()
is used.
- Saves 12 bytes of static RAM on AVR and 24 bytes on ESP8266, if
- (Re)add support for human-readable coroutine names.
v1.4.2 - remove direct dependency to AceCommon library
- 1.4.2 (2022-02-04)
- Remove dependency to AceCommon library in
libraries.properties
.- AceRoutine core no longer depends on AceCommon.
- A few programs in
tests/
andexamples/
still depend it though,
but those are used mainly by the developers, not end-users.
- Clean up and update
examples/ChannelBenchmark
and itsREADME.md
.- Use
generate_readme.py
andgenerate_table.awk
scripts, just like
examples/AutoBenchmark
.
- Use
- Remove dependency to AceCommon library in
v1.4.1 - upgrade tool chain; downgrade support for SAMD21
- 1.4.1 (2022-02-02)
- Update
examples/SoundManager
to demonstrate coroutines defined in
separate files (see
Discussion#40). - Update various unit tests to conform to EpoxyDuino v1.2.0 which
revertsPrint::println()
to print\r\n
instead of just\n
. - Remove SAMD21 boards into new "Tier 3: May work but unsupported" tier
because the SAMD21 tool chain no longer works for me, and Arduino SAMD21
boards use the ArduinoCore-api which is incompatible. - Upgrade tool chain
- Arduino IDE from 1.8.13 to 1.8.19
- Arduino CLI from 0.14.0 to 0.19.2
- Arduino AVR Core from 1.8.3 to 1.8.4
- STM32duino from 2.0.0 to 2.2.0
- ESP8266 Core from 2.7.4 to 3.0.2
- ESP32 Core from 1.0.6 to 2.0.2
- Teensyduino from 1.54 to 1.56
- Update
v1.4.0 - add optional setupCoroutine() to Coroutine class
- 1.4.0 (2021-07-29)
- Upgrade STM32duino Core from 1.9.0 to 2.0.0.
- MemoryBenchmark: Flash usage increases by 2.3kB across the board, but
static RAM goes down by 250 bytes. Very little change to AceRoutine
code itself. - AutoBenchmark: No change.
- MemoryBenchmark: Flash usage increases by 2.3kB across the board, but
- Upgrade SparkFun SAMD Core from 1.8.1 to 1.8.3.
- No change observed in MemoryBenchmark or AutoBenchmark.
- Add virtual
Coroutine::setupCoroutine()
with a default empty
implementation, and optionalCoroutineScheduler::setupCoroutines()
to
automatically loop over all coroutines.- See Issue #36 for
motivation. - If not used,
Coroutine::setupCoroutine()
increases flash consumption
by 4 bytes, and static memory by 2 bytes per coroutine on AVR
processors. - If used,
Coroutine::setupCoroutine()
can consume a significant
amount of memory resources. On AVR, at least 50-60 bytes per
coroutine. On 32-bit processors, about 30-40 bytes per coroutine.
- See Issue #36 for
- Upgrade STM32duino Core from 1.9.0 to 2.0.0.
v1.3.1 - reimplement COROUTINE_DELAY_MICROS() and COROUTINE_DELAY_SECONDS()
- 1.3.1 (2021-06-02)
- Bring back
COROUTINE_DELAY_MICROS()
and `COROUTINE_DELAY_SECONDS(),
with an alternate implemenation that increases flash and static memory
only if they are used.- The
Coroutine
itself knows whether it is delaying in units of
milliseconds, microseconds, or seconds, based on its continuation
point. - Make
CoroutineScheduler::runCoroutine()
always call into
Coroutine::runCoroutine()
when theCoroutine::mStatus
is delaying,
instead of preemptively trying to figure out if the delay has expired. Coroutine
does not need a runtimemDelayType
descriminator.- The result is that the code to support
COROUTINE_DELAY_MICROS()
and
COROUTINE_DELAY_SECONDS()
is not pulled into the program if they are
not used.
- The
- Bring back
v1.3 - reduce flash consumption by 800-1000 bytes
- 1.3.0 (2021-06-02)
- Activate GitHub Discussions for the project.
- Potentially Breaking: Change
Coroutine
destructor from virtual to
non-virtual.- Saves 500-600 bytes on AVR processors, 350 bytes on SAMD21, and 50-150
bytes on other 32-bit processors. - Coroutines can now be created only statically, not dynamically on the
heap.
- Saves 500-600 bytes on AVR processors, 350 bytes on SAMD21, and 50-150
- Potentially Breaking: Lift
Coroutine
intoCoroutineTemplate
class.
LiftCoroutineScheduler
intoCoroutineSchedulerTemplate
class.- Define
Coroutine
to beCoroutineTemplate<ClockInterface>
, almost - fully backwards compatible with previous implementation.
- Define
CoroutineScheduler
to be
CoroutineSchedulerTemplate<Coroutine>
, almost fully backwards
compatible with previous implementation. - All macros (e.g.
COROUTINE()
,COROUTINE_DELAY()
,
COROUTINE_YIELD()
, etc) should work as before. - Replace the 3 clock virtual methods on
Coroutine
(coroutineMicros()
,coroutineMillis()
,
coroutineSeconds()
) with a injectableClockInterface
template
parameter. - Breaking: Convert
Coroutine::coroutineMicros()
,
Coroutine::coroutineMillis()
, andCoroutine::coroutineSeconds()
intoprivate static
functions which delegate to
ClockInterface::micros()
,ClockInterface::millis()
, and
ClockInterface::sesconds()
. - Create
TestableClockInterface
for testing. - Create
TestableCoroutine
for testing. - Create
TestableCoroutineScheduler
for testing. - Only 0-40 bytes of flash memory reduction on AVR processors, to my
surprise. - But 100-1500 bytes of flash memory reduction on various 32-bit
processors.
- Define
- Breaking: Remove
COROUTINE_DELAY_SECONDS()
.- Saves ~200 bytes on AVR processors, about 40%.
- Saves about 20-30 bytes on 32-bit processors.
- The replacement is a for-loop around a
COROUTINE_DELAY()
,
as shown in USER_GUIDE.md#Delay.
- Breaking: Remove
COROUTINE_DELAY_MICROS()
.- Saves about 15-20 bytes of flash and 1 byte of static memory
per coroutine on AVR processors. - Saves about 80-100 bytes of flash on 32-bit processors, plus an
additional 20-30 bytes of flash per coroutine on 32-bit processors. - The
COROUTINE_DELAY_MICROS()
was never reliable because it depended
on other coroutines to release control of execution faster than the
value of the delay microseconds. This is very difficult to guarantee
in a cooperative multitasking environment. - Removing this simplifies the code a fair amount.
- Saves about 15-20 bytes of flash and 1 byte of static memory
- Breaking: Remove
Coroutine::getName()
andCoroutine::mName
. The
human-readable name of the coroutine is no longer retained, to reduce
flash and static memory consumption.- Remove
setupCoroutineOrderedByName()
, since it is no longer possible
to sort by name. - Since we don't need to capture the name of the coroutine, we can
movesetupCoroutine()
functionality directly into
Coroutine::Coroutine()
constructor. - Deprecate
setupCoroutine(const char*)
andsetupCoroutine(const __FlashStringHelper*)
into no-ops. They are retained for backwards
compatibility. - Print the coroutine pointer address instead of its name in
CoroutineScheduler::list()
, since the name is no longer retained. - Saves 10-30 bytes of flash and 3 bytes of static memory per coroutine
instance on AVR. - Saves 10-40 bytes of flash and 8 bytes of static memory per coroutine
instance on 32-bit processors.
- Remove
- Blacklist platforms using the https://github.com/arduino/ArduinoCore-api
to give a user-friendly message instead of pages and pages of compiler
errors. - Update
Direct Scheduling or CoroutineScheduler
section to recommend direct calls toCoroutine::runCoroutine()
on 8-bit
processors, and limit theCoroutineScheduler
to 32-bit processors with
sufficient flash memory. - Add preliminary support for ATtiny85.
v1.2.4 - Update UnixHostDuino 0.4 to EpoxyDuino 0.5
- 1.2.4 (2021-01-22)
- Update UnixHostDuino 0.4 to EpoxyDuino 0.5.
- No functional change in this release.
v1.2.3 - officially support STM32
- 1.2.3 (2021-01-19)
- Add official support for STM32 by validating on a Blue Pill board.
- Add scripts to
AutoBenchmark
to automate data collection. - Update
MemoryBenchmark
andAutoBenchmark
tables with STM32; re-add
Teensy 3.2 benchmarks now that I'm able to upload again. - No functional change in this release.
v1.2.2 - add generic FPSTR() macro for unrecognized platforms
- 1.2.2 (2020-12-20)
- Add generic definition of
FPSTR()
macro for unrecognized platforms.
Allows code withARDUINO_ARCH_STM32
dependencies to compile. I will
support it officially after I get hardware to perform actual validation. - Clean up MemoryBenchmark scripts for consistency with other
Ace*
libraries. - No functional change in this release.
- Add generic definition of