[ECOS] Cortex-M1/3 SysTick/RTC

[ECOS] Cortex-M1/3 SysTick/RTC

[simon.kallweit]

I had a quick look at the ecos clock system. The clock is usually 
implemented using a timer interrupt in the variant or platform code. 
With the Cortex-M1/3, we have a SysTick timer which belongs to the 
architecture itself. I think we should use the SysTick as the clock 
source. The STM32 additionally provides an RTC, but I guess this should 
be implemented as a Wallclock driver, right? A quick look over the 
wallclock interface showed that there is no function for setting wakeup 
alarms. Is this functionality defined elsewhere or is it missing?

Concerning the system clock interrupt. Why is it called 
CYGNUM_HAL_INTERRUPT_RTC? This can be a bit misleading, but I guess has 
historic reasons.

Simon

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Cortex-M1/3 SysTick/RTC

[Andrew Lunn]

On Thu, Sep 11, 2008 at 05:18:11PM +0200, simon.kallweit@intefo.ch wrote:
> I had a quick look at the ecos clock system. The clock is usually  
> implemented using a timer interrupt in the variant or platform code.  
> With the Cortex-M1/3, we have a SysTick timer which belongs to the  
> architecture itself. I think we should use the SysTick as the clock  
> source.

I agree. Use the NVIC clock. It is there, always. It makes a port to a
new target so much simpler since often the clock is often a hard part.

 The STM32 additionally provides an RTC, but I guess this should  
> be implemented as a Wallclock driver, right? A quick look over the  
> wallclock interface showed that there is no function for setting wakeup  
> alarms. Is this functionality defined elsewhere or is it missing?

I just had a very quick look at the date sheet. The RTC looks like it
could be used for a wallclock, however it depends on the hardware. Is
it equipped with a 32.786 Hz clock? Is it using the internal RC clock?
is it calibrated etc? So writing a generic STM32 wallclock driver
might not be possible, it probably needs to the target specific.

The wallclock interface does not support alarms, etc.

> Concerning the system clock interrupt. Why is it called  
> CYGNUM_HAL_INTERRUPT_RTC? This can be a bit misleading, but I guess has  
> historic reasons.

No idea. It was before my time.

   Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Cortex-M1/3 SysTick/RTC

[simon.kallweit]

Andrew Lunn wrote:
> On Thu, Sep 11, 2008 at 05:18:11PM +0200, simon.kallweit@intefo.ch wrote:
>   
>> I had a quick look at the ecos clock system. The clock is usually  
>> implemented using a timer interrupt in the variant or platform code.  
>> With the Cortex-M1/3, we have a SysTick timer which belongs to the  
>> architecture itself. I think we should use the SysTick as the clock  
>> source.
>>     
>
> I agree. Use the NVIC clock. It is there, always. It makes a port to a
> new target so much simpler since often the clock is often a hard part.
>   

Yes, I will use the SysTick for the real time clock source, moving this 
to the architecture. So there will be no need to define this in new 
variants and platforms. We probably should provide macros for overriding 
though?!?

>  The STM32 additionally provides an RTC, but I guess this should  
>   
>> be implemented as a Wallclock driver, right? A quick look over the  
>> wallclock interface showed that there is no function for setting wakeup  
>> alarms. Is this functionality defined elsewhere or is it missing?
>>     
>
> I just had a very quick look at the date sheet. The RTC looks like it
> could be used for a wallclock, however it depends on the hardware. Is
> it equipped with a 32.786 Hz clock? Is it using the internal RC clock?
> is it calibrated etc? So writing a generic STM32 wallclock driver
> might not be possible, it probably needs to the target specific.
>   

The RTC can be sourced from variable clocks. For serious RTC 
applications an external 32.768 is pretty much a must, so I guess the 
wallclock could define that as a requirement.



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Cortex-M1/3 SysTick/RTC

[Andrew Lunn]

> Yes, I will use the SysTick for the real time clock source, moving this  
> to the architecture. So there will be no need to define this in new  
> variants and platforms. We probably should provide macros for overriding  
> though?!?

That is easy to do. The porting guide says the official interface is:

HAL_CLOCK_INITIALIZE( period )
HAL_CLOCK_RESET( vector, period )
HAL_CLOCK_READ( pvalue )

So you can include var_io.h or plf_io.h first and then do:

ifndef HAL_CLOCK_INITIALIZE( period )
#define HAL_CLOCK_INITIALIZE cyg_cortex_clock_init( (period))
#endif

etc...

        Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Cortex-M1/3 SysTick/RTC

[simon.kallweit]

Andrew Lunn wrote:
>> Yes, I will use the SysTick for the real time clock source, moving this  
>> to the architecture. So there will be no need to define this in new  
>> variants and platforms. We probably should provide macros for overriding  
>> though?!?
>>     
>
> That is easy to do. The porting guide says the official interface is:
>
> HAL_CLOCK_INITIALIZE( period )
> HAL_CLOCK_RESET( vector, period )
> HAL_CLOCK_READ( pvalue )
>
> So you can include var_io.h or plf_io.h first and then do:
>
> ifndef HAL_CLOCK_INITIALIZE( period )
> #define HAL_CLOCK_INITIALIZE cyg_cortex_clock_init( (period))
> #endif
>
> etc...
>   

Ok, moving the clock source to the architecture, we need a way to define 
the frequency of the SysTick clock source, which is implementation 
defined. Can we do this using a CDL interface, requiring the cortex 
variants to provide the SysTick clock frequency? Otherwise we'd have to 
move the clock functions back to the variant.

Simon



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Cortex-M1/3 SysTick/RTC

[simon.kallweit]

simon.kallweit@intefo.ch wrote:
> Andrew Lunn wrote:
>>> Yes, I will use the SysTick for the real time clock source, moving 
>>> this  to the architecture. So there will be no need to define this 
>>> in new  variants and platforms. We probably should provide macros 
>>> for overriding  though?!?
>>>     
>>
>> That is easy to do. The porting guide says the official interface is:
>>
>> HAL_CLOCK_INITIALIZE( period )
>> HAL_CLOCK_RESET( vector, period )
>> HAL_CLOCK_READ( pvalue )
>>
>> So you can include var_io.h or plf_io.h first and then do:
>>
>> ifndef HAL_CLOCK_INITIALIZE( period )
>> #define HAL_CLOCK_INITIALIZE cyg_cortex_clock_init( (period))
>> #endif
>>
>> etc...
>>   
>
> Ok, moving the clock source to the architecture, we need a way to 
> define the frequency of the SysTick clock source, which is 
> implementation defined. Can we do this using a CDL interface, 
> requiring the cortex variants to provide the SysTick clock frequency? 
> Otherwise we'd have to move the clock functions back to the variant.

After some more investigation it looks like the SysTick is not THAT 
usable as the source of the realtime clock. On the STM32, the SysTick 
cannot be calibrated, and is by default calibrated for 1ms ticks (at 
maximum system clock frequency). This can be enough for timeslicing but 
it won't cut it delay_us. The luminary is obviously also pre-calibrated. 
Do you still think SysTick is a good idea?

Simon


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Cortex-M1/3 SysTick/RTC

[Andrew Lunn]

> After some more investigation it looks like the SysTick is not THAT  
> usable as the source of the realtime clock. On the STM32, the SysTick  
> cannot be calibrated, and is by default calibrated for 1ms ticks (at  
> maximum system clock frequency). This can be enough for timeslicing but  
> it won't cut it delay_us. The luminary is obviously also pre-calibrated.  
> Do you still think SysTick is a good idea?

The documentation about this is interesting....

http://ecos.sourceware.org/docs-latest/ref/hal-clocks-and-timers.html

There are three main ways of implementating the macro:

   1. a counting loop, typically written in inline assembler, using an
   outer loop for the microseconds and an inner loop that consumes
   approximately 1us. This implementation is automatically thread-safe
   and does not impose any dependencies on the rest of the system, for
   example it does not depend on the system clock having been
   started. However it assumes that the cpu clock speed is known at
   compile-time or can be easily determined at run-time.  

   2. monitor one of the hardware clocks, usually the system
   clock. Usually this clock ticks at a rate independent of the cpu so
   calibration is easier. However the implementation relies on the
   system clock having been started, and assumes that no other code is
   manipulating the clock hardware. There can also be complications
   when the system clock wraps around.

   3. a combination of the previous two. The system clock is used
   during system initialization to determine the cpu clock speed, and
   the result is then used to calibrate a counting loop. This has the
   disadvantage of significantly increasing the system startup time,
   which may be unacceptable to some applications. There are also
   complications if the system startup code normally runs with the
   cache disabled because the instruction cache will greatly affect
   any calibration loop.

SysTick is great for the eCos clock.

You could do a very simple HAL_DELAY_US(us) which only has 1ms
resolution. Not great, but it at least will work and gets you going.

Or you can go for implementation 3, using a 1ms calibration time
derived from the SysTick. 

        Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Cortex-M1/3 SysTick/RTC

[simon.kallweit]

Andrew Lunn wrote:
> SysTick is great for the eCos clock.
>
> You could do a very simple HAL_DELAY_US(us) which only has 1ms
> resolution. Not great, but it at least will work and gets you going.
>
> Or you can go for implementation 3, using a 1ms calibration time
> derived from the SysTick. 
>   

I have implemented the real-time-clock using the SysTick. It should work 
pretty well as I found out with some simple tests. I have also used the 
SysTick counter for a default implementation of the HAL_DELAY_US 
function, which should be pretty accurate (0.01 us accuracy with 72mhz 
clock). What bothers me though, is how to implement the SysTick 
interrupt. It belongs to the default exception vectors of the Cortex 
core. So I guess the architecture should define this ISR vector, but 
normally these go into the variant or platform packages. How can we do that?

Simon

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Cortex-M1/3 SysTick/RTC

[simon.kallweit]

simon.kallweit@intefo.ch wrote:
> Andrew Lunn wrote:
>> SysTick is great for the eCos clock.
>>
>> You could do a very simple HAL_DELAY_US(us) which only has 1ms
>> resolution. Not great, but it at least will work and gets you going.
>>
>> Or you can go for implementation 3, using a 1ms calibration time
>> derived from the SysTick.   
>
> I have implemented the real-time-clock using the SysTick. It should 
> work pretty well as I found out with some simple tests. I have also 
> used the SysTick counter for a default implementation of the 
> HAL_DELAY_US function, which should be pretty accurate (0.01 us 
> accuracy with 72mhz clock). What bothers me though, is how to 
> implement the SysTick interrupt. It belongs to the default exception 
> vectors of the Cortex core. So I guess the architecture should define 
> this ISR vector, but normally these go into the variant or platform 
> packages. How can we do that?

Did some more reading on the exception and interrupt handling on the 
cortex. The cortex architecture defines the first 16 exception vectors 
by default. The SysTick interrupt belongs to these first 16 vectors. 
Variants may implement up to 240 interrupts, which follow the first 16 
exception vectors. Unfortunately, register for enabling/disabling, 
priority etc. of the exception vectors are not linear for both the 16 
system vectors and the interrupt vectors. If the SysTick should be 
usable as a normal interrupt source, it will be the "only" special case. 
How can, or should that be implemented efficiently? Any ideas?

Simon

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss