Zur Übersicht - INFO - Neueste 50 Beiträge - Neuer Beitrag - Suchen - Zum C-Control-I-Forum - Zum C-Control-II-Forum

Re: Interrupt handling Kategorie: Programmierung Assembler (von Torsten - 25.03.2014 19:56)
Als Antwort auf Interrupt handling von PepeV - 21.03.2014 21:03
Ich nutze:
CC-Pro 128 Application Board, Pro-Bot128
> Hi all,
>
> I am trying to find out if and how assembly routines are interrupted
> by the bytecode interpreter. The reason is that when my Probot128
> records or plays sounds, it remains in an assembly routine for many
> seconds.  If possible it should at the same time keep track of
> the pulses from the wheel encoders via external interrupts.
>
> Now I found out that during an assembly routine, when interrupts are
> not disabled with cli, when an interrupt occurs, the byte code
> increases a counter associated with that particular interrupt. (It is
> that counter that is read and reset with Irq_GetCount.) It seems that
> is the only thing that happens. In any case, no user written ISR is
> carried out.
>
> If interrupts are disabled with cli, any interrupt that occurs is
> remembered by the hardware. When the assembly routine is left and
> interrupts are enabled again with sei, the bytecode interpreter
> increases the counter and jumps to the user defined ISR.
>
> Is that correct?

Hallo Pepe,

I think the bytecode-interpreter only checks the
value of the counter-variable and the actual interrupt-routine
does increament this variable.

>
> Would it be possible to locate the address of the routine that
> increases the interrupt counter?

Surely, because the address of the interrupt-routine should be
placed in the interrupt-vector-table. But we must know where
the table is. Is it at the start of the flash memory or at the
the beginning of the boot loader section of the flash.
Maybe we could check the IVSEL-BIT (interrupt vector select bit)
in the MCU-Control-Register.

>
> Would it be possible to replace that routine with another one, e.g.
> by changing the interrupt vector?

I would warn urgently against that unless you knows the system
very exactly. For polling the interrupt flag you need only few
system clocks.

GruÃ? Torsten

>
> I would be grateful for your ideas and insights.
>
> Regards,
> Pepe
>
>


    Antwort schreiben


Antworten:

Re: Interrupt handling (von PeterS - 29.03.2014 14:06)
    Re: Interrupt handling (von Torsten - 31.03.2014 20:44)
        Re: Interrupt handling (von PeterS - 3.04.2014 11:39)
            Re: Interrupt handling (von Torsten - 3.04.2014 20:39)
                Re: Interrupt handling (von PeterS - 13.04.2014 10:44)
                Re: Interrupt handling (von PepeV - 8.04.2014 17:31)
                    Re: Interrupt handling (von Torsten - 8.04.2014 20:37)
                       Re: Interrupt handling (von PepeV - 9.04.2014 20:14)
                          Re: Interrupt handling (von Torsten - 14.04.2014 20:10)