EmbeddedRelated.com
Forums

interfacing PS/2 voltage levels to CMOS

Started by Laszlo Cser February 17, 2004
Laszlo Cser <cserl@freemail.hu> wrote:

> What approach should I take?
> The interrupt handler could be written either as a separate .s module or in > inline assembler.
I don't think you can actually do that, unless the AVR is a rather unusual platform (I've never used it myself...). Interrup handlers either have to be written completely in asm, or the C compiler has to give you special support to allow writing them in C, because they almost invariably need a different kind of call convention (RTI instead of RET on return, and similar nitbits). So yes, it quite probably should be done as a .S module (capital S and you'll have the C preprocessor applied to it, which may come in quite handy...)
> I don't see how the interconnection could be done by the > latter one.
The interconnection isn't the problem --- the call frame is.
> #1 - interrupt handler is implemented in a separate assembly > module. Fixed SRAM addresses reserved by the linker command file > form an interface towards the rest of the software. (What't the best > way to do this?)
There shouldn't be any particular reason to have fixed SRAM addresses for that. The linker can resolve those for you, i.e. your assembler code can directly reference variables defined and declared by C. In case of doubt, write a simple prototype interrupt handler routine in C and use 'gcc -S' to see how to access those variables from assembly. -- Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.
On 22 Feb 2004 19:02:06 GMT, Hans-Bernhard Broeker
<broeker@physik.rwth-aachen.de> wrote:

>Laszlo Cser <cserl@freemail.hu> wrote: > >> What approach should I take? > >> The interrupt handler could be written either as a separate .s module or in >> inline assembler. > >I don't think you can actually do that, unless the AVR is a rather >unusual platform (I've never used it myself...). Interrup handlers >either have to be written completely in asm, or the C compiler has to >give you special support to allow writing them in C, because they >almost invariably need a different kind of call convention (RTI >instead of RET on return, and similar nitbits).
Or write a small assembly routine that saves some registers, then calls a function written in C and when it returns, the assembler routine takes over and restores the registers and perform the actual RTI instruction. If the interrupt service routine is coded in C, it is extremely important that it does not call any run time library routines explicitly or implicitly (e.g. emulated floating point addition), since the library routines are not set up properly or their activation may cause strange errors, if the libraries are not designed to be called from the ISR.
>> #1 - interrupt handler is implemented in a separate assembly >> module. Fixed SRAM addresses reserved by the linker command file >> form an interface towards the rest of the software. (What't the best >> way to do this?) > >There shouldn't be any particular reason to have fixed SRAM addresses >for that. The linker can resolve those for you, i.e. your assembler >code can directly reference variables defined and declared by C.
Many C-compilers add an underscore to the global function and variable names, so if you declare outside of any function volatile unsigned char Var1 ; the assembly language should contain a reference similar to EXTERN _Var1 (or Var1_) The linker should take care of mapping the C and assembly language references to the same physical address. It is also very important to use the volatile keyword in non-interrupt C-code, if the interrupt routine updates the Var1 memory location. Paul
Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> writes:

> Interrup handlers > either have to be written completely in asm, or the C compiler has to > give you special support to allow writing them in C, because they > almost invariably need a different kind of call convention (RTI > instead of RET on return, and similar nitbits).
I've seen several instances where the RTOS provides a tiny interrupt handler stub that calls the actual programmer supplied handler (via a C function pointer perhaps). -- Darin Johnson Caution! Under no circumstances confuse the mesh with the interleave operator, except under confusing circumstances!
"Laszlo Cser" <cserl@freemail.hu> wrote in message
news:c1att5$7s7$1@news.wplus.net...
> Hi, > > I have to design the interconnection of an assembly interrupt handler the > rest of the C language software. The handler performs some speed
sensitive
> portread+process operations. The results (a few 8-bit variables) should be > passed on to the rest of the software. Implementation is done by an Atmel > AVR microcontroller and the WinAVR port of the AVRGCC compiler. > > What approach should I take? > > The interrupt handler could be written either as a separate .s module or
in
> inline assembler. I don't see how the interconnection could be done by
the
> latter one.) > > #1 - interrupt handler is implemented in a separate assembly module. Fixed > SRAM addresses reserved by the linker command file form an interface
towards
> the rest of the software. (What't the best way to do this?)
Don't use fixed addresses. This is destined to lead to errors. Either declare the variables in the C module and use exernals in the assembly module or declare the variables in the assembly module and use externals in the C module (e.g. extern char Value;). I always declare the variable the the module that 'produces' the data. Meindert
> What approach should I take?
Can you no just write the lot in C, using WinAVR extensions? For example, an ISR for compare match A can be written as: void SIG_OUTPUT_COMPARE1A( void ) __attribute__ ( ( signal ) ); void SIG_OUTPUT_COMPARE1A( void ) { /*compiler automatically saves used registers here.*/ /* ... Your C code here ... */ /*compiler automatically restores registers and inserts end of interrupt instruction here.*/ } Richard. http://www.FreeRTOS.org
On 2004-02-23, Richard <noemail@nospamthanks.com> wrote:
>> What approach should I take? > > Can you no just write the lot in C, using WinAVR extensions?
I don't have any experience with the AVR port, but the corresponding feature in the H8 port works great: void myISR(void) __attribute__((interrupt_handler)) { /* gcc saves all used registers */ /* user code here */ /* gcc does return-from-interrupt */ } -- Grant Edwards grante Yow! One FISHWICH coming at up!! visi.com
Paul Keinanen <keinanen@sci.fi> wrote:
> On 22 Feb 2004 19:02:06 GMT, Hans-Bernhard Broeker > <broeker@physik.rwth-aachen.de> wrote:
> >I don't think you can actually do that, unless the AVR is a rather > >unusual platform (I've never used it myself...). Interrup handlers > >either have to be written completely in asm, or the C compiler has to > >give you special support to allow writing them in C, because they > >almost invariably need a different kind of call convention (RTI > >instead of RET on return, and similar nitbits).
> Or write a small assembly routine that saves some registers, then > calls a function written in C and when it returns, the assembler > routine takes over and restores the registers and perform the actual > RTI instruction.
In that case, though, you still write the actual interrupt handler in asm. It's just calling some C function to help with the job. You're correct debunking my statement that it had to be "completely" in asm, though. An ASM wrapper is sufficient.
> Many C-compilers add an underscore to the global function and variable > names,
"Many" C-compilers are beside the point, though. It's the single compiler actually being used in the particular situation that matters, and that's where the option of having the C compiler generate assembler code for output comes in handy. You don't have to know what convention is used by the compiler, you don't even have to RTFM for it. You just have the compiler tell you all the ugly details --- it must obviously know what the convention is, after all. "gcc -S" (or its equivalent on the compiler in question) is about the best documentation tool for low-level aspect of ABIs ever invented.
> It is also very important to use the volatile keyword in non-interrupt > C-code, if the interrupt routine updates the Var1 memory location.
Definitely. -- Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.