### Initial Releases v1.0.0
1. Initial coding to support **Portenta_H7 boards** such as Portenta_H7 Rev2 ABX00042, etc., using [**ArduinoCore-mbed mbed_portenta** core](https://github.com/arduino/ArduinoCore-mbed) with `Vision-shield Ethernet` ot `Murata WiFi`
* 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.
* add MTP40C CO2 and air pressure sensor
* Add MTP40C CO2 and air pressure sensor
* Update repositories.txt
add experimental library - DAC8550
* Update repositories.txt
* Update repositories.txt
* add MINMAX library
Library to find peaks in a signal
In order to facilitate the testing and review of proposed changes to the repository label infrastructure, the
"Sync Labels" template workflow does a dry run when triggered under conditions that indicate it would not be appropriate
to make real changes to the repository's labels. The changes that would have resulted are printed to the log, but not
actually made.
One of the criteria used to determine "dry run" mode usage is whether the event occurred on the repository's default
branch. A trigger on a development branch or for a pull request should not result in a change to the labels.
It turns out that GitHub does not define a `github.event.repository.default_branch` context item when a workflow is
triggered by a `schedule` event. This resulted in the workflow always running in "dry run" mode on a `schedule` trigger.
Since `schedule` and `repository_dispatch` triggers are only permitted for the default branch, there is no need to check
whether the event's ref matches the default branch and it is safe to always run in write mode on these events.
Incorrect context key name resulted in impossible to satisfy conditional, meaning the dry run determination code was
solely dependent on the check for whether the workflow was triggered from the default branch name.
The repository contains labels for each of the distinct operations that may be requested for the library registrations or index data. These labels are defined in a local configuration file for management by the "Sync Labels" GitHub Actions work in combination with the shared universal Arduino tooling project repository labels configuration file.
Since there has not yet been an internal request for a type change operation, the associated "topic: type change" label was forgotten when creating the configuration file. It will be best to have the label in place so every standard operation can be accomplished without unnecessary complication.
Removed library uulm_mcp23008_core. Reason: Another library for the port expander MCP23008 will be used for all projects, so this library will not be implemented. Gitlab repository is already removed.
### Initial Releases v1.0.0
1. Initial coding to support **Portenta_H7 boards** such as Portenta_H7 Rev2 ABX00042, etc., using [**ArduinoCore-mbed mbed_portenta** core](https://github.com/arduino/ArduinoCore-mbed) and `Vision-shield Ethernet`
### Initial Releases v1.0.0
1. Initial coding to support **Portenta_H7 boards** such as Portenta_H7 Rev2 ABX00042, etc., using [**ArduinoCore-mbed mbed_portenta** core](https://github.com/arduino/ArduinoCore-mbed) and `Vision-shield Ethernet`
### Initial Releases v1.0.0
1. Initial coding to support **Portenta_H7 boards** such as Portenta_H7 Rev2 ABX00042, etc., using [**ArduinoCore-mbed mbed_portenta** core](https://github.com/arduino/ArduinoCore-mbed) and `Vision-shield Ethernet`
### Initial Releases v1.0.0
1. Initial coding to support **SAMD21/SAMD51 boards** such as NANO_33_IOT, ITSYBITSY_M4, SEEED_XIAO_M0, SparkFun_SAMD51_Thing_Plus, etc. using Arduino, Adafruit or Sparkfun core
2. The hybrid ISR-based PWM channels can generate from very low (much less than 1Hz) to highest PWM frequencies up to 1000Hz with acceptable accuracy.
1. Initial coding to support **STM32F/L/H/G/WB/MP1 boards** such as NUCLEO_H743ZI2, NUCLEO_L552ZE_Q, NUCLEO_F767ZI, BLUEPILL_F103CB, etc., using [`Arduino Core for STM32`](https://github.com/stm32duino/Arduino_Core_STM32)
2. The hardware-based PWM channels can generate very high PWM frequencies up with high accuracy.
### Initial Releases v1.0.0
1. Initial coding to support **STM32F/L/H/G/WB/MP1 boards** such as NUCLEO_H743ZI2, NUCLEO_L552ZE_Q, NUCLEO_F767ZI, BLUEPILL_F103CB, etc., using [`Arduino Core for STM32`](https://github.com/stm32duino/Arduino_Core_STM32)
2. The hybrid ISR-based PWM channels can generate from very low (much less than 1Hz) to highest PWM frequencies up to 1000Hz with acceptable accuracy.
* 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.
* add MTP40C CO2 and air pressure sensor
* Add MTP40C CO2 and air pressure sensor
* Update repositories.txt
add experimental library - DAC8550
* Update repositories.txt
* Update repositories.txt
