### Features
The FlashStorage_STM32F1 library, inspired by [Cristian Maglie's FlashStorage](https://github.com/cmaglie/FlashStorage), provides a convenient way to store and retrieve user's data using emulated-EEPROM, from the non-volatile flash memory of STM32F1/F3, including non-genuine CH32F103xx, CS32F103xx, etc. boards.
The flash memory, generally used to store the firmware code, can also be used to store / retrieve more user's data and faster than from EEPROM. Thanks to the **buffered data writing and reading**, the flash access time is greatly reduced to **increase the life of the flash**.
Currently, the library supports both new [**STM32 core v2.0.0**](https://github.com/stm32duino/Arduino_Core_STM32/releases/tag/2.0.0) and previous [**STM32 core v1.9.0**](https://github.com/stm32duino/Arduino_Core_STM32/releases/tag/1.9.0)
* add TCA9555
* add RobTIllaart/SGP30
* Add AGS02MA
TVOC sensor - experimental library, use low speed I2C < 30 KHz, UNO does not really work as it cannot go that low.
Some minor adjustments to the comments in the configuration files for the tools used by the repository's CI system to
bring them into sync with the upstream "template" assets.
The use of the `error` workflow command will cause the important error message output to be surfaced prominently in the
workflow run summary and log. The workflow run logs can be somewhat labyrinthine to those who don't work with them
regularly, so finding the previous output to determine what caused the failure might have been challenging.
Even if it works as intended, it is not clear what the effect is of the escaped quote at the end of the environment
variables in the shell commands used to check the license detection results. Wrapping the variable names in braces
ensures they are as expected and also makes the working of the code clear.
There are two file extensions in common use for YAML files: `.yaml` and `.yml`. Although this project uses `.yml`
exclusively for YAML files, this is a standardized workflow which might be applied to projects that have established the
use of the other extension. It will be most flexible if it supports both.
The `workflow_dispatch` event allows triggering the workflow via the GitHub web interface. This makes it easy to trigger
an immediate workflow run after some relevant external change.
The `repository_dispatch` event allows triggering workflows via the GitHub API. This might be useful for triggering an
immediate check in multiple relevant repositories after an external change, or some automated process. Although we don't
have any specific need for this event at the moment, the event has no impact on the workflow, so there is no reason
against having it. It is the sort of thing that can end up being useful if it is already in consistently in place, but
not worth setting up on demand, since the effort to set it up is greater than the effort to trigger all the workflows
manually.
This will make it easier for the maintainers to sync fixes and improvements in either direction between the upstream
"template" workflow and its installation in this repository.
* Add libraries for new RAKwireless modules
RAK13005-TLE7259-Library - RAKwireless library for RAK13005 LIN bus module with TLE7259 transceiver IC
RAK-MQx-Library - RAKWireless library for the WisBlock MQx Gas Sensor Modules
* Add RAK12010 library
Co-authored-by: beegee1962 <bernd.giesecke@rakwireless.com>
Removed https://gitlab.com/F-Schmidt/uulm-mcp23008. This is my first library which will be renamed and restructured. The new libraries uulm-mcp23008-core and uulm-mcp23008-user (or similar) will follow soon. They will also provide examples and have a much better documentation.
