Remove redundant macros since CONFIG_ZTIMER_USEC_TYPE and
CONFIG_ZTIMER_USEC_DEV were already set to their default values.
Signed-off-by: Gilles DOFFE <g.doffe@gmail.com>
Migrate motor driver configuration from inline definition in board.h to
the new board-specific motor_driver_params.h header file.
The old approach defined motor_driver_config[] directly in board.h and
unconditionally included motor_driver.h, causing compilation failures
for applications that do not use the motor_driver module.
This allows the motor driver header to be included only when the module
is actually used, while board-specific parameters take precedence over
driver defaults due to include path ordering.
Configuration migrated:
- Driver 0: PWM device 1, 3 motors (channels 1, 3, 0)
- Driver 1: PWM device 2, 1 motor (channel 0)
- Mode: MOTOR_DRIVER_1_DIR with inverted brake for both drivers
Signed-off-by: Gilles DOFFE <g.doffe@gmail.com>
The motor_driver module has been reworked in a previous commit to be
compliant with RIOT device driver guide.
Thus declaration in board.h is no more needed and should not work
anymore.
Signed-off-by: Gilles DOFFE <g.doffe@gmail.com>
The motor_driver module has been reworked in a previous commit to be
compliant with RIOT device driver guide.
Thus declaration in board.h is no more needed and should not work
anymore.
Moreover the driver test was calling a callback specific to the native
architecture to simulate the native QDEC periph driver according to
motors speed. This is not relevant as a test should only test the
feature it has been developed for.
Signed-off-by: Gilles DOFFE <g.doffe@gmail.com>
The motor_driver device driver is developed as a periph driver and it
should not.
Make this driver compliant with RIOT device driver development guide
[1].
Also make some cleanups and fix some typos.
[1] https://doc.riot-os.org/driver-guide.html
Signed-off-by: Gilles DOFFE <g.doffe@gmail.com>
Co-authored-by: crasbe <crasbe@gmail.com>
The STM32F3 requires a dedicated digital signal to emulate a disconnect
event by pulling D+ down via a 1.5 kOhm resistor. Some boards, such as
the OLIMEXINO-STM32F3, do not directly connect a GPIO but place a
transistor in between. Depending on the exact implementation, the logic
level may end up being inverted compared to directly connecting a
GPIO.
This adds a flag member to the `stm32_usbdev_fs_config_t` and a new flag
to indicate inverted logic. In addition the members in the struct are
sorted by alignment, as this is a foolproof algorithm to prevent wasting
memory on unneeded padding.
Finally, the USB driver is adapted to honor the flag.
Co-authored-by: crasbe <crasbe@gmail.com>
Nucleo144 boards for L5 and U5 have a completely different analog pin configuration. It's a very small change, but due to style changes it seems like a big change. In fact, the configuration has been changed just by adding an #ifdef ... #else ... #end and the six analog pins for L5 and U5 boards.
According to user manuals the pin configuration for Arduino pins D14/D15 is PB9/PB8. The configuration was mixed up. Furthermore, I2C_DEV(1) is configured correclty with SDA=PB9 and SCL=PB8 that have to be mapped to Arduino pins D14=SDA and D15=SCL, respectively, to be compatibly with Arduino shields.
