[ECOS] Real Time Clock

[ECOS] Real Time Clock

[Privat]

Dear Ecos Developers and Maintainers,

i have a question regarding the real time clock.
I have a FreeSacle which runs at 116 Mhz, which means  i have 1 000 000
000  ns / 116 000 000  or 8ns per cycle.

I set the dividend to 1000, and the divisor to 116 which following the
documentation (http://ecos.sourceware.org/docs-2.0/ref/kernel-clocks.html)
 - should always yield the ratio of ns between clock ticks.
Unfortunatly that does not result in correct values.

Strange as it sounds, the default works near perfect.
But reading the realtime clock resolution i got a dividend 1000000000
and a divisor of 1000 - which would be correct for a 100 Hz processor.

Any help or advice is welcome. I would also like to know, how the system
is able to derive its own cyclerate.

Regards Picasso

-- 
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] Real Time Clock

[Ilija Kocho [Илија Кочо]]

On 17.12.2015 11:31, Privat wrote:
> Dear Ecos Developers and Maintainers,
>
> i have a question regarding the real time clock.
> I have a FreeSacle which runs at 116 Mhz, which means  i have 1 000 000
> 000  ns / 116 000 000  or 8ns per cycle.

Is it a Kinetis?

>
> I set the dividend to 1000, and the divisor to 116 which following the
> documentation (http://ecos.sourceware.org/docs-2.0/ref/kernel-clocks.html)
>  - should always yield the ratio of ns between clock ticks.
> Unfortunatly that does not result in correct values.
>
> Strange as it sounds, the default works near perfect.
> But reading the realtime clock resolution i got a dividend 1000000000
> and a divisor of 1000 - which would be correct for a 100 Hz processor.
>
> Any help or advice is welcome. I would also like to know, how the system
> is able to derive its own cyclerate.
>
> Regards Picasso
>


-- 
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] Real Time Clock

[Privat]

Its a MPC5668x ?

Am 17.12.2015 um 12:07 schrieb Ilija Kocho [Илија Кочо]:
> On 17.12.2015 11:31, Privat wrote:
>> Dear Ecos Developers and Maintainers,
>>
>> i have a question regarding the real time clock.
>> I have a FreeSacle which runs at 116 Mhz, which means  i have 1 000 000
>> 000  ns / 116 000 000  or 8ns per cycle.
> Is it a Kinetis?
>
>> I set the dividend to 1000, and the divisor to 116 which following the
>> documentation (http://ecos.sourceware.org/docs-2.0/ref/kernel-clocks.html)
>>  - should always yield the ratio of ns between clock ticks.
>> Unfortunatly that does not result in correct values.
>>
>> Strange as it sounds, the default works near perfect.
>> But reading the realtime clock resolution i got a dividend 1000000000
>> and a divisor of 1000 - which would be correct for a 100 Hz processor.
>>
>> Any help or advice is welcome. I would also like to know, how the system
>> is able to derive its own cyclerate.
>>
>> Regards Picasso
>>
>


-- 
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] Real Time Clock

[Jonathan Larmour]

Privat wrote:
> Dear Ecos Developers and Maintainers,
> 
> i have a question regarding the real time clock.
> I have a FreeSacle which runs at 116 Mhz, which means  i have 1 000 000
> 000  ns / 116 000 000  or 8ns per cycle.
> 
> I set the dividend to 1000, and the divisor to 116 which following the
> documentation (http://ecos.sourceware.org/docs-2.0/ref/kernel-clocks.html)
>  - should always yield the ratio of ns between clock ticks.
> Unfortunatly that does not result in correct values.

The kernel real time clock doesn't run at 116 MHz though! The clock speed 
for the processor is different from the clock you want the kernel to use 
to measure time - the latter drives a clock interrupt that is used to 
handle e.g. kernel alarms or timeslicing. You can't have a tick (and 
therefore a clock interrupt) every CPU cycle :-).

You would need to set it to the number of nanoseconds per clock interrupt 
you would get when the clock setting given by CYGNUM_HAL_RTC_PERIOD is 
programmed into the PowerPC decrementer.

I don't know your HAL, but if it is derived from the MPC5554demo HAL, 
which seems most likely, CYGNUM_HAL_RTC_PERIOD defaults to the expression 
(CYGHWR_HAL_POWERPC_MPC55XX_FSYS/CYGNUM_HAL_RTC_DENOMINATOR) (with name 
changed for you)

so that it becomes easy to make the denominator correspond to the kernel 
clock frequency you want. In other words, if you want the standard 100Hz 
kernel clock tick, you probably do indeed want to leave it as it is.

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine

-- 
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] Real Time Clock

[Gary Thomas]

On Thu, 2003-10-23 at 05:44, James Yates wrote:
> I have a platform which when boots, copies code that was placed to be run from RAM, from a flash device to the correct location in RAM. The VBR is then modified correctly and a jump is made to the first address contained in the first entry of the vector table.
> 
> The app I have built which I store in flash is a simple eCos app consisting of 2 threads and I am trying to get timeslicing working. I am a bit unsure of the build options I should set since although this is running from RAM it is not running through a debug stub or rom monitor.
> 
> Should I disable all ROM Monitor Support in this case and link it as if it was to be placed in ROM but modify the corresponding memory layouts to actualy place it in RAM? This is a bit of a special scenario for eCos but unfortunately I have to build it this way.
> I seem to get an exception when the scheduler is started, I think the RTC is getting an interrupt but the VSR doesn't have an entry in. So when the interrupt happens, it atempts to jump to a routine that doesn't exist. Provided the HAL_CLOCK_INITIALIZE, HAL_CLOCK_RESET, HAL_CLOCK_VAR_INITIALIZE and HAL_CLOCK_READ macros are valid, should the realtime clock code in the kernel handle everything else for me or do I need to make any special calls to setup the RTC isr?

If you don't have an [eCos compatible] ROM monitor running, then
set your application thusly.  Make sure that CYGSEM_HAL_USE_ROM_MONITOR
is not set and it should take over everything, including all of the
interrupt & exception processing.  This is invariant of the ROM/RAM
startup type setting (although RAM mode often implies USE_ROM_MONITOR)

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


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

[ECOS] Real Time Clock

[James Yates]

I have a platform which when boots, copies code that was placed to be run from RAM, from a flash device to the correct location in RAM. The VBR is then modified correctly and a jump is made to the first address contained in the first entry of the vector table.

The app I have built which I store in flash is a simple eCos app consisting of 2 threads and I am trying to get timeslicing working. I am a bit unsure of the build options I should set since although this is running from RAM it is not running through a debug stub or rom monitor.

Should I disable all ROM Monitor Support in this case and link it as if it was to be placed in ROM but modify the corresponding memory layouts to actualy place it in RAM? This is a bit of a special scenario for eCos but unfortunately I have to build it this way.
I seem to get an exception when the scheduler is started, I think the RTC is getting an interrupt but the VSR doesn't have an entry in. So when the interrupt happens, it atempts to jump to a routine that doesn't exist. Provided the HAL_CLOCK_INITIALIZE, HAL_CLOCK_RESET, HAL_CLOCK_VAR_INITIALIZE and HAL_CLOCK_READ macros are valid, should the realtime clock code in the kernel handle everything else for me or do I need to make any special calls to setup the RTC isr?

	Many Thanks in advance.


		James Yates

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