avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] Bootloader interrupt callbacks


From: Eric Pasquier
Subject: Re: [avr-gcc-list] Bootloader interrupt callbacks
Date: Mon, 18 May 2009 11:23:02 +0200

Hi Sven,

Some "guru" are going to respond to you and will give your a better response than mine.
In the mean time, let me tell you my personal comment.

In fact, you are wondering how the compiler should threat function calls from an ISR.
I do not see any difference between callback or direct call.
Every procedure should preserve/restore any register, except r18-r31 and take care of r1, r0.

As you already know, an ISR can occur at any time and corrupt these registers with the calls made. That's why you should tell the compiler, and below is an example of the code generated : as you see, the compiler is saving the others registers. This code is certainly the same if the fonction is called in "callback", which is only a pointer to a fonction.

Do you really have problems or where you only preoccupied about this case ?


ISR( SIG_UART_DATA )
{
 write_to_uart();
}

198 0110 1F92        push __zero_reg__
199 0112 0F92        push __tmp_reg__
200 0114 0FB6        in __tmp_reg__,__SREG__
201 0116 0F92        push __tmp_reg__
202 0118 1124        clr __zero_reg__
203 011a 2F93        push r18
204 011c 3F93        push r19
205 011e 4F93        push r20
206 0120 5F93        push r21
207 0122 6F93        push r22
208 0124 7F93        push r23
209 0126 8F93        push r24
210 0128 9F93        push r25
211 012a AF93        push r26
212 012c BF93        push r27
213 012e EF93        push r30
214 0130 FF93        push r31
215 0132 CF93        push r28
216 0134 DF93        push r29
217 0136 CDB7        in r28,__SP_L__
218 0138 DEB7        in r29,__SP_H__
219                /* prologue end (size=21) */
220                .LM21:
221 013a 0E94 0000   call read_from_uart
222                /* epilogue: frame size=0 */
223 013e DF91        pop r29
224 0140 CF91        pop r28
225 0142 FF91        pop r31
226 0144 EF91        pop r30
227 0146 BF91        pop r27
228 0148 AF91        pop r26
229 014a 9F91        pop r25
230 014c 8F91        pop r24
231 014e 7F91        pop r23
232 0150 6F91        pop r22
233 0152 5F91        pop r21
234 0154 4F91        pop r20
235 0156 3F91        pop r19
236 0158 2F91        pop r18
237 015a 0F90        pop __tmp_reg__
238 015c 0FBE        out __SREG__,__tmp_reg__
239 015e 0F90        pop __tmp_reg__
240 0160 1F90        pop __zero_reg__
241 0162 1895        reti
242                /* epilogue end (size=19) */



----- Original Message ----- From: "Sven Schlender" <address@hidden>
To: <address@hidden>
Sent: Monday, May 18, 2009 11:18 AM
Subject: [avr-gcc-list] Bootloader interrupt callbacks


Hello,

for our project we probably have an odd problem and no ideas to resolve it.

What we already do:
- We have a bootloader on an atmegaAVR which handle all the interrupts
(timer, communication, IO) and stays in the AVR all the time.
- We have some functions in bootloader, each with a well defined address,
which can be called by the main application.
- As communication channel from bootloader to the main app we have an event
queue, which must be polled periodically by the main app.

What we want to do:
We want to add another back channel. Assuming it is possible for the main
app to register a callback function (probably with parameters) at runtime.
After registration this function is directly called from an ISR. Now, due
the project architecture, the compiler in the main app does not know, that a
callback function is part of an ISR. Is there a possibilty to say the
compiler, that some code is part of an ISR or else simply auto save and
restore used register for a given code part? Also the "sei" command must not
used by the callbacks.

Thanks for any ideas!

Best regards,

Sven Schlender



_______________________________________________
AVR-GCC-list mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list






reply via email to

[Prev in Thread] Current Thread [Next in Thread]