Hi,
What would you recommend in this case:
1. Use STM HAL instead of ChibiOS HAL drivers with removing your HAL Drivers
2. Keep ChibiOS HAL drivers and rewrite CubeMX calls to ChibiOS calls
3. Combine: add STM drivers for peripheral that ChibiOS do not have and rewrite CubeMX calls for peripheral that ChibiOS has drivers for.
In the other words - are STM HAL drivers fully compatible with ChibiOS or there are some restrictions that have to be met for using with ChibiOS?
ChibiOS & Nucleo L152RE Board
Moderator: RoccoMarco
- Giovanni
- Site Admin
- Posts: 14892
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: ChibiOS & Nucleo L152RE Board
Hi,
I would start assessing if the ChibiOS HAL offers already what you need, if not, then gaps could be filled using STM's code.
From my experience STM HAL drivers are hard to use with any RTOS. Any difficulty you may find would not be ChibiOS-specific.
Giovanni
I would start assessing if the ChibiOS HAL offers already what you need, if not, then gaps could be filled using STM's code.
Code: Select all
are STM HAL drivers fully compatible with ChibiOS or there are some restrictions that have to be met for using with ChibiOS?From my experience STM HAL drivers are hard to use with any RTOS. Any difficulty you may find would not be ChibiOS-specific.
Giovanni
Re: ChibiOS & Nucleo L152RE Board
Giovanni,
Sorry for bothering with such newbie's question, but please help!!!
Before any other changes to demo to get closer to my project I'm trying to get sysclk on MCO output (PortA bit 8). Two days spent without any luck
It seems like nothing to do, I found a couple of projects on Internet (without nay RTOS, though - one in English and one in Russian for newbies, ), but something goes wrong with mine...
Here is the main (by emblocks based on your code with non-principal modifications) with my additions:
I even tried to change hal_lid.h in the part of STM32_MCOSEL definition
It did not help.
I stopped in hal_lid.c at the place where this part controlled, the STM32_MCOSEL had been set to 0!!!
Tried to change that bit manually in the register - did not work. What am I doing wrong?
And, well, the LED blinking without any problem
Sorry for bothering with such newbie's question, but please help!!!
Before any other changes to demo to get closer to my project I'm trying to get sysclk on MCO output (PortA bit 8). Two days spent without any luck
It seems like nothing to do, I found a couple of projects on Internet (without nay RTOS, though - one in English and one in Russian for newbies, ), but something goes wrong with mine...
Here is the main (by emblocks based on your code with non-principal modifications) with my additions:
Code: Select all
/** @file main.c
* @brief The file where everything starts.
* @author Murat "Sensei" Ursavas
* @attention All rights reserved. Copyright (c) Rasatron Ltd.
*/
#include "ch.h"
#include "hal.h"
//#define STM32_MCOSEL STM32_MCOSEL_SYSCLK // to add MCO output to PA8 - redefined here
/** @brief The main function where everything starts.
*
* @return To foo exit code required for GCC warning suppression
*
*/
static WORKING_AREA (waBlinky, 128);
static msg_t Blinky(void *arg);
int main(void)
{
halInit(); /* initialize hardware abstraction layer */
chSysInit(); /* initialize ChibiOS kernel */
//#if (STM32_MCOSEL == STM32_MCOSEL_SYSCLK) // <-- tried to bring here part of hal_lid.c
// RCC->CFGR |= STM32_MCOPRE | STM32_MCOSEL |
// STM32_PPRE2 | STM32_PPRE1 | STM32_HPRE;
//#endif
/* configure GPIOA pin 5 as output */
palSetPadMode(GPIOA, GPIOA_LED_GREEN, PAL_STM32_MODE_OUTPUT | PAL_MODE_OUTPUT_PUSHPULL);
// Configure GPIOA8 as output for MCO = sysclock
palSetPadMode(GPIOA, GPIOA_PIN8, PAL_MODE_OUTPUT_PUSHPULL | PAL_STM32_OSPEED_HIGHEST | PAL_STM32_MODE_ALTERNATE);
chThdCreateStatic(waBlinky, sizeof(waBlinky),NORMALPRIO, Blinky, NULL);
while(1)
{
chThdSleepMilliseconds(100);
/* palSetPad(GPIOA, GPIOA_PIN8); // <-- checked that PA8 works under fw control to be sure I look with scope on the correct pin.
chThdSleepMilliseconds(100);
palClearPad(GPIOA, GPIOA_PIN8);*/
}
}
static msg_t Blinky(void *arg)
{
chRegSetThreadName("Blinky");
while(1)
{
palSetPad(GPIOA, GPIOA_LED_GREEN);
chThdSleepMilliseconds(500);
palClearPad(GPIOA, GPIOA_LED_GREEN);
chThdSleepMilliseconds(500);
}
return 0;
}I even tried to change hal_lid.h in the part of STM32_MCOSEL definition
Code: Select all
/**
* @brief MCO clock source.
*/
#if !defined(STM32_MCOSEL) || defined(__DOXYGEN__)
// #define STM32_MCOSEL STM32_MCOSEL_NOCLOCK
#define STM32_MCOSEL STM32_MCOSEL_SYSCLOCK
// #define STM32_MCOSEL STM32_MCOSEL_PLL
#endifIt did not help.
I stopped in hal_lid.c at the place where this part controlled, the STM32_MCOSEL had been set to 0!!!
And, well, the LED blinking without any problem
- Giovanni
- Site Admin
- Posts: 14892
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: ChibiOS & Nucleo L152RE Board
All the settings you need are in mcuconf.h, you should never change the HAL LLD files directly.
About MCO, you need to program the appropriate alternate function on the pin. You can do this calling palSetPinMode(), see the datasheet for the right alternate number.
Giovanni
About MCO, you need to program the appropriate alternate function on the pin. You can do this calling palSetPinMode(), see the datasheet for the right alternate number.
Giovanni
Re: ChibiOS & Nucleo L152RE Board
Hi,
Yes, I understand that changing hal drivers header is not a good idea
Just did not know where to look at.
Made changes in mcuconf.h
When changed
#define STM32_MCOSEL STM32_MCOSEL_SYSCLK
the compiler gives 8 errors: #error "invalid STM32_MCOSEL value specified"
If I make
#define STM32_MCOSEL STM32_MCOSEL_PLL
there are now errors.
Could it be a bug?
There is no such function, only palSetPadMode(), which I'm using.
Yes, I understand that changing hal drivers header is not a good idea
Made changes in mcuconf.h
When changed
#define STM32_MCOSEL STM32_MCOSEL_SYSCLK
the compiler gives 8 errors: #error "invalid STM32_MCOSEL value specified"
If I make
#define STM32_MCOSEL STM32_MCOSEL_PLL
there are now errors.
Could it be a bug?
You can do this calling palSetPinMode(),
There is no such function, only palSetPadMode(), which I'm using.
Re: ChibiOS & Nucleo L152RE Board
With palSetPadMode(GPIOA, GPIOA_PIN8, PAL_STM32_OSPEED_HIGHEST | PAL_STM32_MODE_ALTERNATE);
i.e. without PAL_MODE_OUTPUT_PUSHPULL I am able to get PLL frequency on CMO.
Thanks for pointing me to correct header that I can edit.
However, question about using STM32_MCOSEL_SYSCLK still needs to be verified, why it causes errors during compilation.
i.e. without PAL_MODE_OUTPUT_PUSHPULL I am able to get PLL frequency on CMO.
Thanks for pointing me to correct header that I can edit.
However, question about using STM32_MCOSEL_SYSCLK still needs to be verified, why it causes errors during compilation.