public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* RE: [ECOS] HAL macros and RTC
@ 2003-01-28  4:07 Fabrice Gautier
  2003-01-28  4:33 ` Jonathan Larmour
  0 siblings, 1 reply; 6+ messages in thread
From: Fabrice Gautier @ 2003-01-28  4:07 UTC (permalink / raw)
  To: 'Gary Thomas'; +Cc: Ecos-List (E-mail)

> -----Original Message-----
> From: Gary Thomas [mailto:gary@mlbassoc.com]
> Subject: Re: [ECOS] HAL macros and RTC
> 
> 
> The platforms define CYGNUM_HAL_INTERRUPT_xxx and they are very
> much platform specific.  CYGNUM_HAL_INTERRUPT_RTC is the one 
> interrupt which must be defined by a platform for the heartbeat
> clock/timer, thus the platform neutral name.
> 
> Is this not how you expected it to work?

Well, I was just suggesting to change the name of the macros, because i got
confused.
What make  CYGNUM_HAL_INTERRUPT_RTC more platform neutral than say
CYGNUM_HAL_INTERRUPT_UART0 and the others ? 

When I started my port, I listed my interrupt vectors and called them
CYGNUM_HAL_INTERRUPT_xxx, and one of them is for an hardware Clock so i just
named it CYGNUM_HAL_INTERRUPT_RTC. And then everything compiled fine and
redboot runs, i didnt realized that CYGNUM_HAL_INTERRUPT_RTC was more
special than the other CYGNUM_HAL_INTERRUPT_xxx until i tried to do
multitasking.  

So thats why i'm suggestion another name like CYGNUM_KERNEL_RTC_VECTOR (or
whatever is judged appropriate) maybe change the other names to
CYGNUM_HAL_myarch_INTERRUPT_xxx (but they are many more)... 

But It's not that important...

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

^ permalink raw reply	[flat|nested] 6+ messages in thread
* RE: [ECOS] HAL macros and RTC
@ 2003-01-29 10:50 Fabrice Gautier
  2003-01-29 18:53 ` Nick Garnett
  0 siblings, 1 reply; 6+ messages in thread
From: Fabrice Gautier @ 2003-01-29 10:50 UTC (permalink / raw)
  To: 'Jonathan Larmour'; +Cc: 'Gary Thomas', Ecos-List (E-mail)

> -----Original Message-----
> From: Jonathan Larmour [mailto:jifl@eCosCentric.com]
> Sent: Monday, January 27, 2003 8:25 PM
> To: Fabrice Gautier
> Cc: 'Gary Thomas'; Ecos-List (E-mail)
> Subject: Re: [ECOS] HAL macros and RTC
> 
> 
> 
> > When I started my port, I listed my interrupt vectors and 
> > called them CYGNUM_HAL_INTERRUPT_xxx, and one of them is
> > for an hardware Clock so i just
> > named it CYGNUM_HAL_INTERRUPT_RTC. And then everything 
> > compiled fine and redboot runs, i didnt realized that 
> > CYGNUM_HAL_INTERRUPT_RTC was more special than the other
> > CYGNUM_HAL_INTERRUPT_xxx until i tried to do
> > multitasking.  
> 
> Read the porting documentation then ;-).

Actually I did it, (after i found the problem), and it says...

"3. Real-time clock interrupts drive the eCos scheduler clock. Many embedded
CPUs have an on-core timer (e.g. SH) or decrementer (e.g. MIPS, PPC) that
can be used, and in this case it will already be supported by the
architecture/variant HAL. You only have to calculate and enter the proper
CYGNUM_HAL_RTC_CONSTANTS definitions in the platform CDL file."
and 
"4. Interrupt decoding usually differs between platforms because the amount
and type of devices on the board differ. In plf_intr.h you must either
extend or replace the vector definitions otherwise provided by the
architecture or variant interrupt headers. You may also have to define
HAL_INTERRUPT_xxx control macros."

I dont know if the "on core timer" is always plugged into the same IRQ line
for MIPS or PPC, but thats not the case for me. I think we should have in
the guide: 

"You only have to calculate and enter the proper CYGNUM_HAL_RTC_CONSTANTS
definitions in the platform CDL file and define CYGNUM_HAL_INTERRUPT_RTC in
[some include file]"

By the way shouldnt the interrupt be a CDL option like the other RTC related
constants ?

Thanks,

-- 
Fabrice Gautier, 
Fabrice_Gautier@sdesigns.com

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

^ permalink raw reply	[flat|nested] 6+ messages in thread
* [ECOS] HAL macros and RTC
@ 2003-01-28  1:13 Fabrice Gautier
  2003-01-28  1:43 ` Gary Thomas
  0 siblings, 1 reply; 6+ messages in thread
From: Fabrice Gautier @ 2003-01-28  1:13 UTC (permalink / raw)
  To: Ecos-List (E-mail)

Hi,

In most hal, CYGNUM_HAL_INTERRUPT_xxx macros are used to describe all the
different Interrupts vectors. Most of the CYGNUM_HAL_INTERRUPT_xxx are arch
specific however. For example some arch define CYGNUM_HAL_INTERRUPT_TIMER0
and _TIMER1 whereas other could define _TIMER1 and TIMER2 or just _TIMER if
they have only one. So i assumed that those macros where completely arch
specific and I defined a CYGNUM_HAL_RTC to the interrupt vector of an
hardware clock.

Unfortunately this macros is used as by the kernel (in clock.cxx) as the
interrupt driving the kernel internal clock. So i actually have to define
CYGNUL_HAL_INTERRUPT_RTC as CYGNUM_HAL_INTERRUPT_TIMER and find another name
for ny hardware clock.

Would you think it would be a better idea to let the
CYGNUM_HAL_INTERRUPT_xxx macro arch-specifique and come up with a generic
name to be used by the kernel ? 

The name doesnt matter really, it's just that I got confused on that...

Thanks,

-- 
Fabrice Gautier, 
Fabrice_Gautier@sdesigns.com

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

^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-01-29 18:09 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-01-28  4:07 [ECOS] HAL macros and RTC Fabrice Gautier
2003-01-28  4:33 ` Jonathan Larmour
  -- strict thread matches above, loose matches on Subject: below --
2003-01-29 10:50 Fabrice Gautier
2003-01-29 18:53 ` Nick Garnett
2003-01-28  1:13 Fabrice Gautier
2003-01-28  1:43 ` 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).