AMiRo-LLD issueshttps://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-LLD/-/issues2023-02-01T11:42:32+01:00https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-LLD/-/issues/12VL53L5CX driver2023-02-01T11:42:32+01:00Svenja KennewegVL53L5CX driverImplement a driver for the VL53L5CX which is used in the new Sensorring
Also implement a test which should test the attached ToF:
1. Turn Port 1 of the Mux (PCA9544) on (I2C Bus 2 (software = 1!!!) and adress 0x77)
2. Test ToF driver
...Implement a driver for the VL53L5CX which is used in the new Sensorring
Also implement a test which should test the attached ToF:
1. Turn Port 1 of the Mux (PCA9544) on (I2C Bus 2 (software = 1!!!) and adress 0x77)
2. Test ToF driver
Hint: Flash the PowerManagement over
`make flash_PowerManagement_1-2 BOARD_SENSORRING=BOARD_TOFPROX_SENSOR`https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-LLD/-/issues/11PCA9554 driver2023-02-01T11:29:28+01:00Svenja KennewegPCA9554 driverImplement a driver for the PCA9554 which is used in the new Sensorring.
Also add a new BOARD_SENSORRING tag for the new Sensorring in the AMiRo-OS.
Hint: Flash the PowerManagement over
`make flash_PowerManagement_1-2 BOARD_SENSORRING...Implement a driver for the PCA9554 which is used in the new Sensorring.
Also add a new BOARD_SENSORRING tag for the new Sensorring in the AMiRo-OS.
Hint: Flash the PowerManagement over
`make flash_PowerManagement_1-2 BOARD_SENSORRING=BOARD_TOFPROX_SENSOR`https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-LLD/-/issues/10Investigate I2C issues2022-09-15T11:25:09+02:00Thomas SchöppingInvestigate I2C issuesIn commit cf203e0c an issue was "fixed" but only by a workaround solution.
The issue was, that the contents of the `rxbuf` variable would not be written by the `apalI2CMasterTransmit()` function call, resulting in apparently correct valu...In commit cf203e0c an issue was "fixed" but only by a workaround solution.
The issue was, that the contents of the `rxbuf` variable would not be written by the `apalI2CMasterTransmit()` function call, resulting in apparently correct values, even if they were not.
With the workaround in place, `rxbuf` would contain only zeros, indicating that something went wrong.
However, there are two major problems with this workaround:
- Even though a value of `0` can be used to detect issues for sensor values, because such would normally never be returned by the device, this is not the case for threshold values, which may be zero indeed.
- In fact, the `rxbuf` _must_ have be filled with data if the `apalI2CMasterTransmit()` function does not return an error value.
As result, the actual cause of the original issue is rooted somewhere in the `apalI2CMasterTransmit()` function and should be investigated.https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-LLD/-/issues/9periphAL UART interface2022-07-01T13:04:10+02:00Thomas SchöppingperiphAL UART interfaceImplement a UART interface in periphAL.Implement a UART interface in periphAL.https://gitlab.ub.uni-bielefeld.de/AMiRo/AMiRo-LLD/-/issues/3Introduction of callbacks in periphAL2022-04-04T11:19:18+02:00Thomas SchöppingIntroduction of callbacks in periphALThere is a major issue with periphAL 1.x, if an interface (e.g. a GPIO) can not be accessed directly bu only via further devices (e.g. a GPIO extender with I2C interface).
Such scenarios can not be represented by periphAL.
This issue ca...There is a major issue with periphAL 1.x, if an interface (e.g. a GPIO) can not be accessed directly bu only via further devices (e.g. a GPIO extender with I2C interface).
Such scenarios can not be represented by periphAL.
This issue can be solved by introducing individual callback function pointers for each interface instance.
All interface structs need to feature dedicated function pointers for all interface functions (e.g. read GPIO, write GPIO, etc.), which can be set individually per instance.
Since this modification would fundamentally change how periphAL works and cause vast incompatibilities, this enhancement will most probably entangle a major version upgrade to v2.0.
For the example given above, the callbacks of a GPIO can still point to the "native" functions and replicate the same bahavior as the current version of periphAL.
In case a device is accessed via a GPIO extender, however, the callback can be used to execute any required code transparently.
Such callbacks could even be nested for complex setups (e.g. MCU/SoC --SPI--> I2C driver --I2C--> I2C multiplexer --I2C--> GPIO extender --GPIO--> target device).