Yes, we'll move to errno codes any time soon. I'd prefer we go with the
* @brief Start counter device.Looks like we are moving to Posix error codes, so it would be wise to do
* @param dev Pointer to the device structure for the driver instance.
* @retval DEV_OK If successful.
* @retval DEV_* Code otherwise.
it here as
well. (better now than after the API is upstream). Apply that to all.
current error code convention (DEV_*) at the moment and fix all drivers
at once in the 'errno patchset'.
I missed the idea that DEV_* will anyway be mapped to errno, so keep
This is a better comment.
/**Set an alarm callback. If the counter was not started yet, this will do
* Set an alarm callback. If the counter was not started yet, this
* function starts and set the alarm.
(no need to call counter_start()).
Actually, follow Jesus's comment. counter_set_alarm() should not star
What about (let me know if I am wrong, hw feature wise) resetting an alarm?API-wise, I think it makes sense we have the counter_unset_alarm. I'm just
Currently, it set set it, and nothing cannot stop it.
So we may want a counter_unset_alarm() ?
wondering if the counter_stop API does cover the use case. I mean, counter_stop
stops the counter so the alarm won't be fired.
Now question is: would it be enough to have 1 alarm set a time, or couldATM, I'd say we should go with one alarm set a time. For such functionality
interesting to link alarms? (so different subsystem could use set an alarm)
you described, I think the user probably wants to use a system-wide timer,
such as the system timer, instead. Bare in mind that this is a driver API
and some platforms may not have any counter available.
If you are using 1 alarm at all time, then don't add counter_unset_alarm()
User could just use counter_set_alarm() with a NULL pointer as a callback