Replies: 1 comment
-
I suggest two clearly separated, stacked APIs: Low lvl Timer API - Feature completeGives unified, generic access to timers, independent of the MCU nor the MCU-family. High lvl Timer API - Application orientedInherits or aggregates Low lvl API and feels like a peripheral driver. Like with peripheral drivers, the application-designer don't wants to be confronted with the inner mechanisms and topologies. He/She/It just wants the functionality that makes use of Timers. Examples
|
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Currently the only Timer driver(s) in modm are written for STM32 and the API is very hardware-specific. See e.g. https://docs.modm.io/develop/api/nucleo-g474re/classmodm_1_1platform_1_1Timer8.html
I propose to rename the current API to TimerHal (similar to SpiHal) and to add APIs for different functionalities (PWM generation, encoder input, DC- and BLDC- motors, ...)
cc @TomSaw @salkinium
Beta Was this translation helpful? Give feedback.
All reactions