public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* interrupt handling
@ 2001-12-18  1:44 Abhilash R
  2001-12-18 11:48 ` Kai Ruottu
  2001-12-24  9:54 ` Interrupt Handling S. Bharathi
  0 siblings, 2 replies; 3+ messages in thread
From: Abhilash R @ 2001-12-18  1:44 UTC (permalink / raw)
  To: crossgcc, gcc-help

Hello,
We are using GNU C compiler in one of our project. The microcontroller
on our target board is MMC2107.  However we are facing some problem
during interrupt handling.
In my code I have defined an interrupt as fast interrupt coming on egde
port EP.4. I have done all the initialisations properly & simulated that

interrupt using Interrupt force register of MMC2107. Reading back the
status register shows that interrupt is valid & there is an interrupt
pending for execution. However the branching to ISR is not happening.

Kindly let us know the solution for this problem as soon as possible.

regards
abhilash

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: interrupt handling
  2001-12-18  1:44 interrupt handling Abhilash R
@ 2001-12-18 11:48 ` Kai Ruottu
  2001-12-24  9:54 ` Interrupt Handling S. Bharathi
  1 sibling, 0 replies; 3+ messages in thread
From: Kai Ruottu @ 2001-12-18 11:48 UTC (permalink / raw)
  To: Abhilash R; +Cc: crossgcc, gcc-help

Abhilash R wrote:
> 
> Hello,
> We are using GNU C compiler in one of our project. The microcontroller
> on our target board is MMC2107.  However we are facing some problem
> during interrupt handling.
>
> In my code I have defined an interrupt as fast interrupt coming on egde
> port EP.4. I have done all the initialisations properly & simulated that
> interrupt using Interrupt force register of MMC2107. Reading back the
> status register shows that interrupt is valid & there is an interrupt
> pending for execution. However the branching to ISR is not happening.

 AFAIK the M.CORE "interrupt processing uses an interrupt vector table and
a set of internal shadow registers while making the transition to an
Interrupt Service Routine (ISR)", as one of my docs says...

 And :
-------------
"The FINT is the fast interrupt request input. If enabled the FE bit in
PSR is set, it has higher priority than the normal interrupt input INT.
Fast interrupts use the FPSR and FPC exception shadow registers and
consequently are not masked when the EE bit in PSR is cleared.  Fast
interrupts are masked when the FE bit in PSR is cleared. When FINT is
asserted, either the AVEC input can be asserted to cause autovectoring
to occur, or a 7-bit vector number can be provided to select one of
vectors 32-127 to be used. (No explicit attempt is made by the processor
to preclude use of vectors 0-31.) If a fast interrupt is autovectored,
the vector at offset 0x2C from the vector table base is used.

So for the vectorable interrupts FINT and INT, a seven-bit interrupt
vector number can be supplied at the time a request is generated, or
the autovector input AVEC can be asserted to indicate that the appropriate
predefined vector should be used. If AVEC is asserted, the VEC# inputs
are ignored."
-------------

 I see this meaning that either the AVEC-input must be set to something,
then the address entry in offset 0x2c in the vector table will be used,
ie. only one fast interrupt is in use... Or a 7-bit vector number is put
somewhere (on the VEC# inputs ?) and the vectors 32-127 in the vector
table will be used for the 96 possible Fast-ISR's...

 You didn't mention the interrupt vector table at all, although it will
be needed in both cases, so perhaps it is simply missing... And the state
of the AVEC input was left unclear...

 Also AFAIK the plain vanilla GCCs for M.CORE don't include any ISR-support,
like producing the following prologue and epilogue with the
'__attribute__((interrupt))' or something:

-------------
	.file	"isr_demo.c"
gcc2_compiled.:
	.text
	.align	1
	.export	handle_intr
	.type	 handle_intr,@function
handle_intr:
	subi	sp,32
	subi	sp,28
	stm	r1-r15,(sp)

	<the function code>

	ldm	r1-r15,(sp)
	addi	sp,32
	addi	sp,28
	rte
-------------

 So I'm curious how you now produce the ISRs with GCC ?  Over a year ago I
did some fixes to the 'mcore-elf' support in my GCC-sources and added some
kind of ISR-support... But haven't seen anybody else asking about this
possibility.

> Kindly let us know the solution for this problem as soon as possible.

 Was this soon enough ? ;-)

Cheers, Kai


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Interrupt Handling
  2001-12-18  1:44 interrupt handling Abhilash R
  2001-12-18 11:48 ` Kai Ruottu
@ 2001-12-24  9:54 ` S. Bharathi
  1 sibling, 0 replies; 3+ messages in thread
From: S. Bharathi @ 2001-12-24  9:54 UTC (permalink / raw)
  To: GNC GCC

Hello All,

     How to write a Interrupt Driven Program using
     GCC in Linux ?

     Any documentation or samples avilable for this ?

ThanX,
Bharathi S.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2001-12-24 17:54 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-12-18  1:44 interrupt handling Abhilash R
2001-12-18 11:48 ` Kai Ruottu
2001-12-24  9:54 ` Interrupt Handling S. Bharathi

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).