I don't know about everyone else here, but putting interrupt routines in
a library seems like a bad idea to me. My philosophy of library
functions are usually to make them generic and reusable in a variety of
situations. Casting them as interrupt seems to destroy that.
It would seem to me that the best solution would be to have an interrupt
routine that calls a generic function:
Interrupt( UART1RX_VECTOR ) Usart1_Rx( Void_t )
{
Receive_from_Uart1();
}
Put this in your regular compiled code, then put the function
Void_t Receive_from_Uart1( Void_t );
In your library. Then it could be used for the interrupt and if you
every have the need to read from Uart1 with interrupts turned off, it
can be used in a polling mode as well.
That's my opinion, FWIW.
Randy
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Yvan
Castilloux
Sent: Friday, July 29, 2005 12:11 PM
To: [email protected]
Subject: Re: [Mspgcc-users] Problem linking interrupt functions in
library
I tried this:
Void_t (*Timer_A0_Ptr)( Void_t );
Void_t (*Usart1_Rx_Ptr) (Void_t);
Timer_A0_Ptr=&Timer_A0;
Usart1_Rx_Ptr=&Usart1_Rx;
The functions header are:
interrupt( TIMERA0_VECTOR ) Timer_A0( Void_t ); and
interrupt( UART1RX_VECTOR ) Usart1_Rx( Void_t );
The linker doesn't add the functions. It says they are not used.
However if I call the interrupt functions like this in main:
Timer_A0();
Usart1_Rx();
I can see that the code size has gone up, which makes me think they were
linked somehow. The difference in size corresponds to the function
sizes.
However, the code doesn't work.
Any other solutions/comments?
Thank you,
Yvan
>From: "Thomas W. Carley" <[email protected]>
>Reply-To: [email protected]
>To: [email protected]
>Subject: Re: [Mspgcc-users] Problem linking interrupt functions in
library
>Date: Fri, 29 Jul 2005 10:20:43 -0400
>
>One simple hack is to reference the function, for instance set a
pointer to
>it.
>
>Yvan Castilloux wrote:
>
>>Ok,
>>
>>You're saying that functions in the libary that are not direclty
called
>>are not linked. Do you have any solution to suggest besides not
putting
>>these functions in the library? I'm sure there's a way to make them
link
>>since interrupt functions are a special case.
>>
>>Thank you very much,
>>
>>Yvan
>>
>>>From: "diwil" <[email protected]>
>>>Reply-To: [email protected]
>>>To: <[email protected]>
>>>Subject: RE: [Mspgcc-users] Problem linking interrupt functions in
>>>library
>>>Date: Fri, 29 Jul 2005 12:11:16 +0400
>>>
>>>If object code does not refer some function residing in library, the
last
>>>one will not be linked.
>>>~d
>>>
>>>-----Original Message-----
>>>From: [email protected]
>>>[mailto:[email protected]] On Behalf Of Yvan
>>>Castilloux
>>>Sent: Friday, July 29, 2005 12:25 AM
>>>To: [email protected]
>>>Subject: [Mspgcc-users] Problem linking interrupt functions in
library
>>>
>>>Hi,
>>>
>>>I use msp430-ar to make a library of functions. When I include the
>>>interrupt functions in the library, the linker just disregard them.
For
>>>instance, the following function with header
>>>
>>>interrupt( UART0RX_VECTOR ) Usart0_Rx( Void_t )
>>>{
>>>...
>>>}
>>>
>>>will not link if it is pre-compiled in the library but it will if it
is
>>>compiled normally.
>>>
>>>Here are the commands I use in the make file:
>>>1-library
>>>ldevicelib: $(DEVICE_OBJS) $(DEVICE_HEAD)
>>> msp430-ar -ruv $(LIBDIR)/libdevicelib.a $(DEVICE_OBJS) ;
>>>
>>>2-compiling
>>>$(OBJ_DIR)/%.o : $(SRCDIR)/%.c
>>> $(CC) $(CCOPTIONS) $(OPTIMIZER) $(DEBUGGER) $(DEFINED)
-I$(INCLDIR)
>>>
>>>-I$(CC_INC_DIR) $< -o $@
>>>
>>>3-linking
>>>rfseals.elf : ${OBJECTS}
>>> ${CC} -mmcu=${CPU} -o $@ -L$(LIBDIR) ${OBJECTS}
>>>$(LDFLAGS) \
>>> -ldevicelib
>>>
>>>Any commments?
>>>
>>>The only thing I can think of is that the linker disregards them
because
>>>it
>>>thinks the functions are not used anywhere (they are not called in
the
>>>code
>>>like standard functions). Can you force the linkage then?
>>>
>>>Thank you,
>>>
>>>Yvan
>>>
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>>September
>>>19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>>>Agile & Plan-Driven Development * Managing Projects & Teams * Testing
&
>>>QA
>>>Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
>>>_______________________________________________
>>>Mspgcc-users mailing list
>>>[email protected]
>>>https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>>September
>>>19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>>>Agile & Plan-Driven Development * Managing Projects & Teams * Testing
&
>>>QA
>>>Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
>>>_______________________________________________
>>>Mspgcc-users mailing list
>>>[email protected]
>>>https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>>
>>
>>
>>
>>
>>-------------------------------------------------------
>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>September
>>19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>>Agile & Plan-Driven Development * Managing Projects & Teams * Testing
& QA
>>Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
>>_______________________________________________
>>Mspgcc-users mailing list
>>[email protected]
>>https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
>
>
>-------------------------------------------------------
>SF.Net email is Sponsored by the Better Software Conference & EXPO
>September
>19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>Agile & Plan-Driven Development * Managing Projects & Teams * Testing &
QA
>Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
>_______________________________________________
>Mspgcc-users mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/mspgcc-users
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
