- Use standard RIOT style `ina2xx_params_t` on initialization as explained in
[1] instead of a custom API
- Provided a default configuration via `ina2xx_params_t` as required by [1] that
works fine for the INA219 breakout board and with an optimal resolution that
still covers the whole range of USB high-power devices (500 mA @ 5V) with a
comfortable safe margin.
- Changed initialization procedure to include a device reset and connectivity
test, as required by [1]
- The calibration value is now calculated by the driver
- This simplifies using the driver a lot
- The user can still choose a trade-off between range and resolution that
matches the application requirements, but now among predefined values
- This allows the driver to easily convert the raw data into meaningful
physical data, as the resolution of the raw data is known
- All measurements are provided as meaningful physical data as required by [1]
[1]: https://github.com/RIOT-OS/RIOT/wiki/Guide:-Writing-a-device-driver-in-RIOT
The INA219 has the exact same interface as the INA220 (including values and
semantics of the configuration register). Thus, this driver can be used for
both. The ina220 has been renamed to ina2xx to reflect this and pseudo modules
for the ina220 and ina219 have been added.
functional changes:
- enable test to test the driver in SPI mode
style changes and code simplification:
- enable SPI mode
- fixed typos in doxygen
- fixed line length issues
- simplified code
- use fmt for formatting numbers
- use US_PER_SEC instead of magic value
- use named return values provided by driver
- use puts where ever applicable
Newer gcc versions have an option to enable overflow warnings for string operations. This option is enabled by default. For this test, it is necessary to disable this warning if the compiler supports this option.
To be able to catch a core panic in debugger and to get the last output from asynchronous UART , e.g., if the stack is smashed, the system is not rebooted immediately anymore but breaks, which stops the execution in debugger or reboots the system after WDT timeout.
This test application defines a packages which imports a very simple Arduino library that is used by test application to demonstrate how an Arduino library can be imported as package and used by an application.
Log outputs generated by binary ESP32 SDK libraries are mapped to the ESP32's log module which supports colored and tagged log outpus. Tagged log outputs from SDK libraries are handled accordingly.
The implementation of `log_module` for ESP32 was changed from functions to a macro-based implementation to be able to use the bunch of macros for colored and tagget log output generation.
Enable IDLE and Deep Powerdown mode.
IDLE is pretty straightforward - insteady of busy waiting, the CPU will
enter an idle state from which it will resume on any event.
Deep Power Down shuts off the entite system except for the battery backup
power domain.
That means the CPU will reset on resume and can be woken by e.g. RTC.
SLEEP and POWERDOWN disable the PLL and the PLL and Flash respectively.
This requires some proper wake-up handling.
Since this turned out to be a major time sink and those modes are never
currently never used in RIOT outside of tests, I left this as an exercise
for a future reader.
`pm_set()` gets called by the idle thread whose stack is too small
for normal DEBUG()/printf().
Use DEBUG_PUTS() instead to print the static debug strings.
To make it possible to use an Arduino library, a new pseudomodule arduino_lib is introduced. This pseudomodule enables implicitly module arduino but avoids that a sketch is required or generated and compiled. Thus, it is possible to compile and use a package or directory with some source files from an Arduino library in RIOT applications.
Renames crypto functions of ESP32 SDK in vendor code to resolve the conflicts between `wpa-supplicant` crypto functions and RIOT's `crypto` and `hashes` modules.
To resolve the conflicts between `wpa-supplicant` crypto functions (part of the ESP32 SDK) and RIOT's `crypto` and `hashes` modules, the crypto function headers from ESP32 SDK are added to vendor code and the crypto functions are renamed using the prefix `wpa_`.
