Hi, I'm quite new to ChibiOS but really love it with the HAL and everything! But I have a problem that I can't seem to solve.
Each timer supports input capture for all its 4 channels but I seem to only be able to choose Ch. 1 or Ch. 2, plus I cannot chose to use both channels at the same time.
Is this a limitation in the HAL or have I misunderstood the usage of it?
If this is a limitation in the HAL, what is the best course of action? Write this part of the drivers myself and not use the HAL?
ICU, use both channels?
Moderator: RoccoMarco
-
Giovanni
- Site Admin
- Posts: 14892
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: ICU, use both channels?
Hi,
It is a limitation of the STM32, you cannot use both channels at the same time.
Giovanni
It is a limitation of the STM32, you cannot use both channels at the same time.
Giovanni
Re: ICU, use both channels?
If you are using it in PWM measurement mode, is this what you are reffering to?
If you only want it to react to a rising/falling edge and give an interrupt with the Capture value, it is possible. (when you use it as "independent channels")
This is the feature I was trying to access, to use each channel by itself in independent mode.
If you only want it to react to a rising/falling edge and give an interrupt with the Capture value, it is possible. (when you use it as "independent channels")
This is the feature I was trying to access, to use each channel by itself in independent mode.
-
Giovanni
- Site Admin
- Posts: 14892
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: ICU, use both channels?
Hi,
The ICU drivers only implements PWM-input mode. Other modes require custom code.
Giovanni
The ICU drivers only implements PWM-input mode. Other modes require custom code.
Giovanni
Re: ICU, use both channels?
Okey, then I know not to look any more. 
Just one thing though, why is not TIM12 supported for PWM input (STM32F4)?
It is the same as TIM9 (just another ISR vector). Maybe this is planned to be added?
Just one thing though, why is not TIM12 supported for PWM input (STM32F4)?
It is the same as TIM9 (just another ISR vector). Maybe this is planned to be added?
-
Giovanni
- Site Admin
- Posts: 14892
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: ICU, use both channels?
Hi,
The problem is that some timers share interrupts on some STM32s, this creates a problem because the timers are shared by both PWM and ICU drivers.
A workaround would be possible by creating a shared module containing ISRs for both PWM and ICU drivers but this could take a while.
Giovanni
The problem is that some timers share interrupts on some STM32s, this creates a problem because the timers are shared by both PWM and ICU drivers.
A workaround would be possible by creating a shared module containing ISRs for both PWM and ICU drivers but this could take a while.
Giovanni
Re: ICU, use both channels?
Hi Giovanni,
I have expanded your original ICU driver to include measurements of pulses and edge trigging, but I have one bug that eludes me completely!
Everything works as it should, the counters are counting and registering events (and the correct counter value), but when the counter reaches the value of the ARR register (set to 0xFFFF) the entire CPU seems to crash (or there is an infinite interrupt generation).
I have been going through the timer datasheet for a day without luck, so I thought that maybe you know why this happens? Because it has something to do with the overflow of the ARR register.
I made a test using the PWM setup (which is uses the same code as the one from your code) and then everything works as expected, so it must be an error in the setup of the timer when in Edge detect mode or Pulse detect mode (in eicu_lld_enable or eicu_lld_start).
You can find my code here: https://github.com/korken89/KFly_ChibiO ... er/drivers
I renamed it to the E(xtended)ICU to not collide with the normal ICU.
When I have finished fixing the bug I will tidy up to follow your code style, would you be interested to use this to expand the original ICU HAL module's functionality?
Or will this cause some problems for the OS?
Thanks!
Best Regards
Emil
Edit: I'm testing this on a STM32F405 MCU.
I have expanded your original ICU driver to include measurements of pulses and edge trigging, but I have one bug that eludes me completely!
Everything works as it should, the counters are counting and registering events (and the correct counter value), but when the counter reaches the value of the ARR register (set to 0xFFFF) the entire CPU seems to crash (or there is an infinite interrupt generation).
I have been going through the timer datasheet for a day without luck, so I thought that maybe you know why this happens? Because it has something to do with the overflow of the ARR register.
I made a test using the PWM setup (which is uses the same code as the one from your code) and then everything works as expected, so it must be an error in the setup of the timer when in Edge detect mode or Pulse detect mode (in eicu_lld_enable or eicu_lld_start).
You can find my code here: https://github.com/korken89/KFly_ChibiO ... er/drivers
I renamed it to the E(xtended)ICU to not collide with the normal ICU.
When I have finished fixing the bug I will tidy up to follow your code style, would you be interested to use this to expand the original ICU HAL module's functionality?
Or will this cause some problems for the OS?
Thanks!
Best Regards
Emil
Edit: I'm testing this on a STM32F405 MCU.
-
Giovanni
- Site Admin
- Posts: 14892
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: ICU, use both channels?
Hi,
On reload the driver calls the overflow_cb callback. Is that field NULL?
About driver extensions: it depends, drivers are not supposed to support STM32-specific features, just to implement their stated function. If you need to use a specific function of the STM32 then you have 2 options:
1) Create a custom driver.
2) Add a custom API to the driver low level by marking it using the device name, for example: icuSTM32DoSomething().
Giovanni
On reload the driver calls the overflow_cb callback. Is that field NULL?
About driver extensions: it depends, drivers are not supposed to support STM32-specific features, just to implement their stated function. If you need to use a specific function of the STM32 then you have 2 options:
1) Create a custom driver.
2) Add a custom API to the driver low level by marking it using the device name, for example: icuSTM32DoSomething().
Giovanni
Re: ICU, use both channels?
Hi Giovanni, thanks for the quick answer!
Yes, the overflow_cb pointer is NULL, but on line 807-808 in eicu_lld.c in function eicu_lld_enable:
So ther interrupt should be disabled if the callback is NULL. Or did you refer to something else?
Because when I use it PWM mode I also have overflow_cb = NULL and this does not cause a problem then.
About the ICU extension, the pulse input and edge triggering is one of the basic functionality of any ICU, so should this not be in the main driver?
Best Regards
Emil
Yes, the overflow_cb pointer is NULL, but on line 807-808 in eicu_lld.c in function eicu_lld_enable:
Code: Select all
if (eicup->config->overflow_cb != NULL)
eicup->tim->DIER |= STM32_TIM_DIER_UIE;So ther interrupt should be disabled if the callback is NULL. Or did you refer to something else?
Because when I use it PWM mode I also have overflow_cb = NULL and this does not cause a problem then.
About the ICU extension, the pulse input and edge triggering is one of the basic functionality of any ICU, so should this not be in the main driver?
Best Regards
Emil