ChibiOS Free Embedded RTOS

Hi Giovanni ,
news about PLL Setup ? why with internal xtal on stm32 we going at half speed ? Another question .. what varriable i can use as system time ? I need to start a new time or there're is yet a structure ? What limit ? Have a micro second resolution ?
Regards
Roberto

You should read the clock diagram in the Reference Manual on pagr 84 figure 8, the HSI clock is divided by two before entering the PLL so you have to adjust the multiplier parameter too in order to obtain the final frequency, I think the maximum frequency using the HSI is 64MHz using a 16 multiplier.

The function chTimeNow() returns the current time but its resolution is 1mS using the default configuration, if you need uS class resolutions then you should use an HW timer.

Giovanni

Giovanni wrote:You should read the clock diagram in the Reference Manual on pagr 84 figure 8, the HSI clock is divided by two before entering the PLL so you have to adjust the multiplier parameter too in order to obtain the final frequency, I think the maximum frequency using the HSI is 64MHz using a 16 multiplier.

The function chTimeNow() returns the current time but its resolution is 1mS using the default configuration, if you need uS class resolutions then you should use an HW timer.

Giovanni

Thanks very much Giovanni.
Now i check and then reset the timing on PWM output .. I need to modify your original code in the clock init or i can use your define in mcuconf ?
Regards
Roberto

Ok I found the limit of HSI , is 64 Mhz instead of 72 Mhz , is a good speed for our application I think that i can change the variable
#define STM32_PLLMUL_VALUE 9
to
#define STM32_PLLMUL_VALUE 16
That's is right because in my test the speed was half of HSE ... Perfect!!!
Regards
Roberto

Giovanni wrote:The function chTimeNow() returns the current time but its resolution is 1mS using the default configuration, if you need uS class resolutions then you should use an HW timer.

I have not yet inspected any timer code but usually there is some hardware timer for which its divider has been programmed such that it requests a (periodic) interrupt, in this case probably/reasonably 1ms. So if you need higher resolution it's usually best to read the current countdown value of the divider and calculate the appropriate microsecond fraction from that (and add it to what chTimeNow() returns). Not a big deal, I will be happy to do that as soon as I get the MP32 (still waiting).

Stephan

Hi Stephan,

Correct, in Cortex-Mx ports the Systick timer is used in order to generate 1mS periods, it is possible to read the counter of the Systick timer in order to implement smaller delays.

Anyway in that STM32 there are a lot of timers that can be used too.

Giovanni

Giovanni wrote:Anyway in that STM32 there are a lot of timers that can be used too.

Usually when people talk about "microsecond resolution" of timers (as Roberto did above), they expect to find some machanism so they can program a timer (callback) event. However, in most systems, such a high resolution is not available for timer *events* but only when reading the *current* time (timer value).

In other words, periodic and episodic timer events are often available with a reslution of only >1ms, simply because the main system timer (tick) is incremented every 1ms, which means 1000 interrupts per second. Many systems use substantially lower frequencies (some 100Hz) in order to minimize CPU load and overall overhead.

If more than one hardware timer is available, then additional, more fine-grained timers can actually be implemented on an as-needed basis.

As I said, I will be happy to implement all that once I get hold of my MP32.

Stephan

Hi Giovanni,
w're starting a massive port of Multipilot32 library to ChbiOS , we need some help from you , for a template that support C++ classes mixed with standard C call . We need the support for serial , pwm , spi ,i2c in our enviroment.
Can you help us to implement the template please. So our development team can work with your support on a porting , if you are available by skype we can doing a conference about this task.
Best
Roberto

No problems.

Anyway you should consider that you can already call the current C functions from C++, creating C++ wrappers around all the drivers would add overhead without giving a clear advantage.

My recommendation would be to create high level C++ classes for the your functionalities but use the C API from inside your library. Adding an extra layer in between would be mostly just wasted space IMHO.

Giovanni

Ok perfect ,
we have a lot of library that now we would port to ChibiOS ...
So actualy the configuration of code is :

main code in one .cpp file.
one directory with inside all the library called by main program and another directtory with inside only the file needed for the library is in C++ if you download the VRIDE from the repo understand better how is the tree of directory.
So i need a standard tree directory with a makefile that can compile standard .c and .cpp file ...
send me a pm so we organize a small meeting and i explain to you my idea.
When your template it's ok i ask to developer to work around it to implement with library and port the program.
Best
Roberto