| Re: Interrupt handling Kategorie: Programmierung Assembler (von PeterS - 29.03.2014 14:06) | |
|
Als Antwort auf Re: Interrupt handling von Torsten - 25.03.2014 19:56
| |
|
> > 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. The interrupt table in the bootloader is active, but that code uses the vectors at the begin of the interpreter. > > > > > 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. You are right, changing the interrupt vectors can have ugly side effects. But except the timer interrupt that is used for multitasking, servo and clock, experimenting with the other interrupts should not be fatal. Regards, Peter > > GruÃ? Torsten > > > > > I would be grateful for your ideas and insights. > > > > Regards, > > Pepe > > > > | |
Antwort schreiben Antworten:  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) | |
Zur Übersicht - INFO - Neueste 50 Beiträge - Neuer Beitrag - Suchen - Zum C-Control-I-Forum - Zum C-Control-II-Forum