Hi Giovanni.
BTW for ARR handling the new ICU checks for zero since zero is invalid (stops timer) and users are likely to set zero expecting that to work as a normal full count overflow.
So in the case where .arr is 0 the driver will set 0xFFFF or 0xFFFFFFFF depending on TIM size (yes it a not necessary to differentiate but done anyway).
Otherwise the driver uses the value in config which then sets the configurable ICU wrap around count.
--
Bob
ICU driver and 32 bits timer
Re: ICU driver and 32 bits timer
An issue... if a configurable ARR is allowed then the scaling will need to be re-worked to handle variable sized overflow (currently just works on halfword, word, doubleword overflow).
Last edited by FXCoder on Thu Apr 30, 2020 6:22 am, edited 2 times in total.
- Giovanni
- Site Admin
- Posts: 14893
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 997 times
Re: ICU driver and 32 bits timer
I will keep this on hold then, I need to proceed with releases.
Giovanni
Giovanni
Re: ICU driver and 32 bits timer
OK.
Thinking this over perhaps best to just remove .arr from the config and with the new driver just eliminate the setting of ARR to anything other than full count.
Anyway lets deal with the new driver in the next trunk iteration.
For the immediate release would be better to just set ARR = 0xFFFFFFFF in the current driver and remove the .arr from config.
Right now setting .arr will require existing projects to have updated config.
Thinking this over perhaps best to just remove .arr from the config and with the new driver just eliminate the setting of ARR to anything other than full count.
Anyway lets deal with the new driver in the next trunk iteration.
For the immediate release would be better to just set ARR = 0xFFFFFFFF in the current driver and remove the .arr from config.
Right now setting .arr will require existing projects to have updated config.
Re: ICU driver and 32 bits timer
Being able to set .arr is really handy, I and people of my team had take habit to set ARR after icuStart, so having .arr in the config would be a plus (your zero value of .arr handling is a good idea).
Nevertheless, if .arr is not in the config, that will not stop user to set ARR, and this should not trig buggy behavior in the ICU driver.
Alexandre
Nevertheless, if .arr is not in the config, that will not stop user to set ARR, and this should not trig buggy behavior in the ICU driver.
Alexandre
- Giovanni
- Site Admin
- Posts: 14893
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 997 times
Re: ICU driver and 32 bits timer
Hi,
I think there is an use case for ARR setup, I added a check on zero (it becomes 0xFFFFFFFF) and fixed that typo.
Giovanni
I think there is an use case for ARR setup, I added a check on zero (it becomes 0xFFFFFFFF) and fixed that typo.
Giovanni
Re: ICU driver and 32 bits timer
Hi.
Here is the simple change in hal_icu.h to enable ICU scaling by using the overflow callback.
The overflow scaling is only available where a callback is set.
The callback is not called until edge sync is obtained.
If there is concern over legacy behavior a #define could be added (e.g.) #I2C_USE_OVERFLOW_SCALING with guard !defined(...) to FALSE.
--
Bob
Here is the simple change in hal_icu.h to enable ICU scaling by using the overflow callback.
The overflow scaling is only available where a callback is set.
The callback is not called until edge sync is obtained.
If there is concern over legacy behavior a #define could be added (e.g.) #I2C_USE_OVERFLOW_SCALING with guard !defined(...) to FALSE.
--
Bob
Code: Select all
/**
* @brief Common ISR code, ICU timer overflow event.
* @note An overflow interrupt without a callback brings the driver
* back to the @p ICU_WAITING state.
*
* @param[in] icup pointer to the @p ICUDriver object
*
* @notapi
*/
#define _icu_isr_invoke_overflow_cb(icup) do { \
if ((icup)->config->overflow_cb != NULL && (icup)->state == ICU_ACTIVE) \
(icup)->config->overflow_cb(icup); \
else { \
(icup)->state = ICU_WAITING; \
} \
} while (0)