* [ECOS] scheduler/printf questions
@ 2001-11-14 15:35 Mathieu Lacage
2001-11-14 17:59 ` Andrew Lunn
0 siblings, 1 reply; 5+ messages in thread
From: Mathieu Lacage @ 2001-11-14 15:35 UTC (permalink / raw)
To: ecos-discuss
hi all,
I am currently trying to understand the basic architecture of the eCos
HAL (and yes, I read the docs which are excellent btw :).
I have two questions:
- so that the scheduler can interrupt a task which reached the end of
its timeslice, there must be a timer somewhere to trigger an interrupt
which asks for a reschedule. So, where is this setup ? And where can I
find this interrupt handler's code ? I have tried to find it in the
ARM/Integrator example but failed miserably.
- what are the semantics of a printf call ? I have tried to trace in
the package/langage libc source what happens but I still cannot figure
out where the data will be printed. I would expect there is a way to
configure this on different targets. For example, if the target has an
output serial port, I would expect the bytes to be written there. Is
this a safe assumption ? If so, where can such configuration options be
found ?
Any answer will be welcome :)
Mathieu
--
Mathieu Lacage <mathieu_lacage@realmagic.fr>
#p: +33 1 69 19 61 97
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [ECOS] scheduler/printf questions
2001-11-14 15:35 [ECOS] scheduler/printf questions Mathieu Lacage
@ 2001-11-14 17:59 ` Andrew Lunn
2001-11-15 4:35 ` Mathieu Lacage
0 siblings, 1 reply; 5+ messages in thread
From: Andrew Lunn @ 2001-11-14 17:59 UTC (permalink / raw)
To: Mathieu Lacage; +Cc: ecos-discuss
> I am currently trying to understand the basic architecture of the eCos
> HAL (and yes, I read the docs which are excellent btw :).
These questions deal with more than the HAL....
>
> I have two questions:
> - so that the scheduler can interrupt a task which reached the end of
> its timeslice, there must be a timer somewhere to trigger an interrupt
> which asks for a reschedule. So, where is this setup ? And where can I
> find this interrupt handler's code ? I have tried to find it in the
> ARM/Integrator example but failed miserably.
Im not familiar with that target. I know the EBSA well....
hal_hardware_init() starts the hardware timer by calling
hal_clock_initialize with the correct timer period.
Then in the kernel clock.cxx
Cyg_RealTimeClock::Cyg_RealTimeClock()
: Cyg_Clock(rtc_resolution),
interrupt(CYGNUM_HAL_INTERRUPT_RTC, 1, (CYG_ADDRWORD)this, isr, dsr)
Installs the isr/dsr which are just bellow in the source code. The dsr
calls the scheduler to do a timeslice.
> - what are the semantics of a printf call ? I have tried to trace in
> the package/langage libc source what happens but I still cannot figure
> out where the data will be printed. I would expect there is a way to
> configure this on different targets. For example, if the target has an
> output serial port, I would expect the bytes to be written there. Is
> this a safe assumption ? If so, where can such configuration options be
> found ?
Its all configurable via CDL and the ecos.ecc file. There are a number
of virtual devices which map onto the physical drivers. eg /dev/tty0
is a virtual device which is normally mapped onto the physical device
/dev/ser0. Similarly /dev/termios0 is mapped to /dev/ser0. I think
normal printf is mapped to the console, which defaults to
/dev/ttydiag.
Andrew
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [ECOS] scheduler/printf questions
2001-11-14 17:59 ` Andrew Lunn
@ 2001-11-15 4:35 ` Mathieu Lacage
2001-11-19 1:59 ` Gary Thomas
0 siblings, 1 reply; 5+ messages in thread
From: Mathieu Lacage @ 2001-11-15 4:35 UTC (permalink / raw)
To: Andrew Lunn; +Cc: ecos-discuss
le ven 23-11-2001 à 16:33, Andrew Lunn a écrit :
> > I am currently trying to understand the basic architecture of the eCos
> > HAL (and yes, I read the docs which are excellent btw :).
>
> These questions deal with more than the HAL....
>
> >
> > I have two questions:
> > - so that the scheduler can interrupt a task which reached the end of
> > its timeslice, there must be a timer somewhere to trigger an interrupt
> > which asks for a reschedule. So, where is this setup ? And where can I
> > find this interrupt handler's code ? I have tried to find it in the
> > ARM/Integrator example but failed miserably.
>
> Im not familiar with that target. I know the EBSA well....
>
> hal_hardware_init() starts the hardware timer by calling
> hal_clock_initialize with the correct timer period.
this is not the case on the INTEGRATOR board. I guess it must be
somwhere else... Dunno where though :)
>
> Then in the kernel clock.cxx
>
> Cyg_RealTimeClock::Cyg_RealTimeClock()
> : Cyg_Clock(rtc_resolution),
> interrupt(CYGNUM_HAL_INTERRUPT_RTC, 1, (CYG_ADDRWORD)this, isr, dsr)
>
> Installs the isr/dsr which are just bellow in the source code. The dsr
> calls the scheduler to do a timeslice.
I see.
>
> > - what are the semantics of a printf call ? I have tried to trace in
> > the package/langage libc source what happens but I still cannot figure
> > out where the data will be printed. I would expect there is a way to
> > configure this on different targets. For example, if the target has an
> > output serial port, I would expect the bytes to be written there. Is
> > this a safe assumption ? If so, where can such configuration options be
> > found ?
>
> Its all configurable via CDL and the ecos.ecc file. There are a number
> of virtual devices which map onto the physical drivers. eg /dev/tty0
> is a virtual device which is normally mapped onto the physical device
> /dev/ser0. Similarly /dev/termios0 is mapped to /dev/ser0. I think
> normal printf is mapped to the console, which defaults to
> /dev/ttydiag.
right.
Thanks for your answer,
Mathieu
>
> Andrew
>
--
Mathieu Lacage <mathieu_lacage@realmagic.fr>
#p: +33 1 69 19 61 97
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [ECOS] scheduler/printf questions
2001-11-15 4:35 ` Mathieu Lacage
@ 2001-11-19 1:59 ` Gary Thomas
2001-11-28 12:30 ` Gary Thomas
0 siblings, 1 reply; 5+ messages in thread
From: Gary Thomas @ 2001-11-19 1:59 UTC (permalink / raw)
To: Mathieu Lacage; +Cc: Andrew Lunn, eCos Discussion
On Mon, 2001-11-26 at 00:58, Mathieu Lacage wrote:
> le ven 23-11-2001 à 16:33, Andrew Lunn a écrit :
> > > I am currently trying to understand the basic architecture of the eCos
> > > HAL (and yes, I read the docs which are excellent btw :).
> >
> > These questions deal with more than the HAL....
> >
> > >
> > > I have two questions:
> > > - so that the scheduler can interrupt a task which reached the end of
> > > its timeslice, there must be a timer somewhere to trigger an interrupt
> > > which asks for a reschedule. So, where is this setup ? And where can I
> > > find this interrupt handler's code ? I have tried to find it in the
> > > ARM/Integrator example but failed miserably.
> >
> > Im not familiar with that target. I know the EBSA well....
> >
> > hal_hardware_init() starts the hardware timer by calling
> > hal_clock_initialize with the correct timer period.
>
> this is not the case on the INTEGRATOR board. I guess it must be
> somwhere else... Dunno where though :)
>
It's actually done using the HAL_CLOCK_INITIALIZE() macro (which is what
the HAL actually uses, even if the Integrator HAL maps this onto the
function hal_clock_initialize()).
Look in: .../ecc/kernel/current/src/common/clock.cxx
> >
> > Then in the kernel clock.cxx
> >
> > Cyg_RealTimeClock::Cyg_RealTimeClock()
> > : Cyg_Clock(rtc_resolution),
> > interrupt(CYGNUM_HAL_INTERRUPT_RTC, 1, (CYG_ADDRWORD)this, isr, dsr)
> >
> > Installs the isr/dsr which are just bellow in the source code. The dsr
> > calls the scheduler to do a timeslice.
>
> I see.
>
> >
> > > - what are the semantics of a printf call ? I have tried to trace in
> > > the package/langage libc source what happens but I still cannot figure
> > > out where the data will be printed. I would expect there is a way to
> > > configure this on different targets. For example, if the target has an
> > > output serial port, I would expect the bytes to be written there. Is
> > > this a safe assumption ? If so, where can such configuration options be
> > > found ?
> >
> > Its all configurable via CDL and the ecos.ecc file. There are a number
> > of virtual devices which map onto the physical drivers. eg /dev/tty0
> > is a virtual device which is normally mapped onto the physical device
> > /dev/ser0. Similarly /dev/termios0 is mapped to /dev/ser0. I think
> > normal printf is mapped to the console, which defaults to
> > /dev/ttydiag.
>
> right.
>
>
> Thanks for your answer,
>
> Mathieu
>
> >
> > Andrew
> >
> --
> Mathieu Lacage <mathieu_lacage@realmagic.fr>
> #p: +33 1 69 19 61 97
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [ECOS] scheduler/printf questions
2001-11-19 1:59 ` Gary Thomas
@ 2001-11-28 12:30 ` Gary Thomas
0 siblings, 0 replies; 5+ messages in thread
From: Gary Thomas @ 2001-11-28 12:30 UTC (permalink / raw)
To: Mathieu Lacage; +Cc: Andrew Lunn, eCos Discussion
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2605 bytes --]
On Mon, 2001-11-26 at 00:58, Mathieu Lacage wrote:
> le ven 23-11-2001 à 16:33, Andrew Lunn a écrit :
> > > I am currently trying to understand the basic architecture of the eCos
> > > HAL (and yes, I read the docs which are excellent btw :).
> >
> > These questions deal with more than the HAL....
> >
> > >
> > > I have two questions:
> > > - so that the scheduler can interrupt a task which reached the end of
> > > its timeslice, there must be a timer somewhere to trigger an interrupt
> > > which asks for a reschedule. So, where is this setup ? And where can I
> > > find this interrupt handler's code ? I have tried to find it in the
> > > ARM/Integrator example but failed miserably.
> >
> > Im not familiar with that target. I know the EBSA well....
> >
> > hal_hardware_init() starts the hardware timer by calling
> > hal_clock_initialize with the correct timer period.
>
> this is not the case on the INTEGRATOR board. I guess it must be
> somwhere else... Dunno where though :)
>
It's actually done using the HAL_CLOCK_INITIALIZE() macro (which is what
the HAL actually uses, even if the Integrator HAL maps this onto the
function hal_clock_initialize()).
Look in: .../ecc/kernel/current/src/common/clock.cxx
> >
> > Then in the kernel clock.cxx
> >
> > Cyg_RealTimeClock::Cyg_RealTimeClock()
> > : Cyg_Clock(rtc_resolution),
> > interrupt(CYGNUM_HAL_INTERRUPT_RTC, 1, (CYG_ADDRWORD)this, isr, dsr)
> >
> > Installs the isr/dsr which are just bellow in the source code. The dsr
> > calls the scheduler to do a timeslice.
>
> I see.
>
> >
> > > - what are the semantics of a printf call ? I have tried to trace in
> > > the package/langage libc source what happens but I still cannot figure
> > > out where the data will be printed. I would expect there is a way to
> > > configure this on different targets. For example, if the target has an
> > > output serial port, I would expect the bytes to be written there. Is
> > > this a safe assumption ? If so, where can such configuration options be
> > > found ?
> >
> > Its all configurable via CDL and the ecos.ecc file. There are a number
> > of virtual devices which map onto the physical drivers. eg /dev/tty0
> > is a virtual device which is normally mapped onto the physical device
> > /dev/ser0. Similarly /dev/termios0 is mapped to /dev/ser0. I think
> > normal printf is mapped to the console, which defaults to
> > /dev/ttydiag.
>
> right.
>
>
> Thanks for your answer,
>
> Mathieu
>
> >
> > Andrew
> >
> --
> Mathieu Lacage <mathieu_lacage@realmagic.fr>
> #p: +33 1 69 19 61 97
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2001-11-28 20:30 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-11-14 15:35 [ECOS] scheduler/printf questions Mathieu Lacage
2001-11-14 17:59 ` Andrew Lunn
2001-11-15 4:35 ` Mathieu Lacage
2001-11-19 1:59 ` Gary Thomas
2001-11-28 12:30 ` Gary Thomas
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).