Note: lists.zephyrproject.org will be down for maintenance on Monday, September 26th, starting at 9AM Pacific Time (4PM Monday September 26, 2022 UTC), for approximately one hour.
- RFC: Counter driver API
Re: RFC: Counter driver API
Andre Guedes <andre.guedes@...>
Quoting Jesus Sanchez-Palencia (2016-03-03 09:52:43)
Probably better here to:
* Start the counter device. If the device is a 'count up' counter the
* counter initial value is set to zero. It it is a 'countdown' counter
* the initial value is set to the maximum value supported by the device.
* @brief Start counter device.
* @param dev Pointer to the device structure for the driver instance.
* @retval DEV_OK If successful.
* @retval DEV_* Code otherwise.
@retval DEV_NO_SUPPORT if the device doesn't support starting the
counter (e.g. free running counters).
I don't think DEV_NO_SUPPORT will be ever returned by the counter_start API
since this is a very basic API and all counter must support it.
Anyways, I think we should list in the documentation all the return codes
a given API can return instead of simply saying DEV_*.
Looks like we are moving to Posix error codes, so it would be wise to do It's still not clear if the change will go straight to Posix errors or
it here as
well. (better now than after the API is upstream). Apply that to all.
if the transition through DEV_* will happen first. We can't mix both.
/**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()).
In general having an API that does 2 things is not a good idea.
An API called 'counter_set_alarm' should do only that, IMO. I'd rather have
2 API calls for that (set and start), but if we really want it to do both, then maybe
better calling it counter_init_alarm(..., int count); ?!
I'm fine with we have 2 API calls (counter_start and counter_set_alarm).
Join firstname.lastname@example.org to automatically receive all group messages.