Hi,
You can use the times (or any other peripheral) independently from the HAL as long those are not assigned to some device driver in mcuconf.h. In order to use a timer in a custom driver you should *not* assign it in mcuconf.h.
It is your responsibility to enable the clock for the peripheral of course, you can use the RCC helper or do it directly in RCC registers.
Giovanni
Application design
Moderators: RoccoMarco, lbednarz, tfAteba
- Giovanni
- Site Admin
- Posts: 14891
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
-
hazelnusse
- Posts: 77
- Joined: Thu May 24, 2012 8:01 am
Re: Application design
Giovanni wrote:Hi,
You can use the times (or any other peripheral) independently from the HAL as long those are not assigned to some device driver in mcuconf.h. In order to use a timer in a custom driver you should *not* assign it in mcuconf.h.
It is your responsibility to enable the clock for the peripheral of course, you can use the RCC helper or do it directly in RCC registers.
Giovanni
In my case, this means all STM32_GPT_USE_TIMx are set to FALSE in my mcuconf.h, which then causes this error:
os/hal/platforms/STM32/gpt_lld.h:174:2: error: #error "GPT driver activated but no TIM peripheral assigned"
So, I presume I need to also disable the GPT systemin halconf.h, and then in my own peripheral initialization code I need to enable the peripheral clocks and configure the peripheral registers as needed. I guess it doesn't matter too much where I have this code run as long as it is before any of my threads that depend on these encoder timers.
~Luke
- Giovanni
- Site Admin
- Posts: 14891
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: Application design
Correct, in halconf.h you enable the various abstract subsystems, in mcuconf.h you assign physical peripherals and do the HW-related settings. In you case the HAL complains that the GPT is enabled but no timers are assigned to it.
If a peripheral is not used in the HAL then the initialization and the handling are no different than a normal HAL-less application, you can do bare-metal programming as usual, just write ISRs using the ChibiOS style if you need to interact with the kernel. Note that you can still use the shared support code like the RCC helper and the DMA helper.
Giovanni
If a peripheral is not used in the HAL then the initialization and the handling are no different than a normal HAL-less application, you can do bare-metal programming as usual, just write ISRs using the ChibiOS style if you need to interact with the kernel. Note that you can still use the shared support code like the RCC helper and the DMA helper.
Giovanni
-
hazelnusse
- Posts: 77
- Joined: Thu May 24, 2012 8:01 am
Re: Application design
Great, thank you!
Thanks to you and the ChibiOS/RT community for writing this RTOS and making it so usable. In less than 1 week I had ported my application to ChibiOS and had it up and running with way more functionality than I had with FreeRTOS. Getting the micro SD card, i2c IMU sensors, and the shell customized for my needs has really let me focus on my application design as opposed to lower level details that have been abstracted away very cleanly in ChibiOS/RT.
~Luke
Thanks to you and the ChibiOS/RT community for writing this RTOS and making it so usable. In less than 1 week I had ported my application to ChibiOS and had it up and running with way more functionality than I had with FreeRTOS. Getting the micro SD card, i2c IMU sensors, and the shell customized for my needs has really let me focus on my application design as opposed to lower level details that have been abstracted away very cleanly in ChibiOS/RT.
~Luke
- Giovanni
- Site Admin
- Posts: 14891
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: Application design
I am glad you finalized you application so quickly, thanks for your kind words.
Giovanni
Giovanni