* [ECOS] Cortex-M1/3 SysTick/RTC
@ 2008-09-11 15:18 simon.kallweit
2008-09-11 15:36 ` Andrew Lunn
0 siblings, 1 reply; 9+ messages in thread
From: simon.kallweit @ 2008-09-11 15:18 UTC (permalink / raw)
To: ecos-discuss
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ECOS] Cortex-M1/3 SysTick/RTC
2008-09-11 15:18 [ECOS] Cortex-M1/3 SysTick/RTC simon.kallweit
@ 2008-09-11 15:36 ` Andrew Lunn
2008-09-11 15:44 ` simon.kallweit
0 siblings, 1 reply; 9+ messages in thread
From: Andrew Lunn @ 2008-09-11 15:36 UTC (permalink / raw)
To: simon.kallweit; +Cc: ecos-discuss
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ECOS] Cortex-M1/3 SysTick/RTC
2008-09-11 15:36 ` Andrew Lunn
@ 2008-09-11 15:44 ` simon.kallweit
2008-09-11 15:52 ` Andrew Lunn
0 siblings, 1 reply; 9+ messages in thread
From: simon.kallweit @ 2008-09-11 15:44 UTC (permalink / raw)
To: simon.kallweit, ecos-discuss
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ECOS] Cortex-M1/3 SysTick/RTC
2008-09-11 15:44 ` simon.kallweit
@ 2008-09-11 15:52 ` Andrew Lunn
2008-09-11 16:02 ` simon.kallweit
0 siblings, 1 reply; 9+ messages in thread
From: Andrew Lunn @ 2008-09-11 15:52 UTC (permalink / raw)
To: simon.kallweit; +Cc: ecos-discuss
> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ECOS] Cortex-M1/3 SysTick/RTC
2008-09-11 15:52 ` Andrew Lunn
@ 2008-09-11 16:02 ` simon.kallweit
2008-09-11 16:29 ` simon.kallweit
0 siblings, 1 reply; 9+ messages in thread
From: simon.kallweit @ 2008-09-11 16:02 UTC (permalink / raw)
To: simon.kallweit, ecos-discuss
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ECOS] Cortex-M1/3 SysTick/RTC
2008-09-11 16:02 ` simon.kallweit
@ 2008-09-11 16:29 ` simon.kallweit
2008-09-11 17:17 ` Andrew Lunn
0 siblings, 1 reply; 9+ messages in thread
From: simon.kallweit @ 2008-09-11 16:29 UTC (permalink / raw)
To: simon.kallweit, ecos-discuss
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ECOS] Cortex-M1/3 SysTick/RTC
2008-09-11 16:29 ` simon.kallweit
@ 2008-09-11 17:17 ` Andrew Lunn
2008-09-12 12:00 ` simon.kallweit
0 siblings, 1 reply; 9+ messages in thread
From: Andrew Lunn @ 2008-09-11 17:17 UTC (permalink / raw)
To: simon.kallweit; +Cc: ecos-discuss
> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ECOS] Cortex-M1/3 SysTick/RTC
2008-09-11 17:17 ` Andrew Lunn
@ 2008-09-12 12:00 ` simon.kallweit
2008-09-12 13:46 ` simon.kallweit
0 siblings, 1 reply; 9+ messages in thread
From: simon.kallweit @ 2008-09-12 12:00 UTC (permalink / raw)
To: simon.kallweit, ecos-discuss
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ECOS] Cortex-M1/3 SysTick/RTC
2008-09-12 12:00 ` simon.kallweit
@ 2008-09-12 13:46 ` simon.kallweit
0 siblings, 0 replies; 9+ messages in thread
From: simon.kallweit @ 2008-09-12 13:46 UTC (permalink / raw)
To: simon.kallweit, ecos-discuss
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2008-09-12 13:46 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-09-11 15:18 [ECOS] Cortex-M1/3 SysTick/RTC simon.kallweit
2008-09-11 15:36 ` Andrew Lunn
2008-09-11 15:44 ` simon.kallweit
2008-09-11 15:52 ` Andrew Lunn
2008-09-11 16:02 ` simon.kallweit
2008-09-11 16:29 ` simon.kallweit
2008-09-11 17:17 ` Andrew Lunn
2008-09-12 12:00 ` simon.kallweit
2008-09-12 13:46 ` simon.kallweit
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).