I guess I should clarify further, set_vector usually just calls some function that installs a "template" in the handler, which consists of basically calling a function. You can see some examples in the cpukit/score or the SPARC is at libbsp/sparc/shared/irq/ -Gedare
On Tue, Jul 1, 2014 at 8:59 AM, Gedare Bloom <ged...@rtems.org> wrote: > For a "simple vectored architecture", the usual approach in RTEMS is > to implement some "set_vector()" function that will install a function > pointer in the IRQ table. This function pointer will either be called > in "rtems" mode via trampoline code (ISR_Handler) that sets up a safe > C environment, or will be called directly in "raw" mode and is > responsible to avoid trashing the preempted stack. > > For the few interrupt handlers that are provided by the BSP and can > fit in 64 instructions (256 bytes / 4 bytes per insn) you can just > write directly in the IRQ table. I don't know if there are examples in > RTEMS of an API for doing so. Normally, a user just wants to install > an IRQ in "rtems" mode, since that will provide safe access to some > RTEMS directives and gives a usable C program stack. > > Gedare > > On Mon, Jun 30, 2014 at 7:51 PM, Hesham Moustafa > <heshamelmat...@gmail.com> wrote: >> Hi, >> >> I want to implement an API for OpenRISC IRQ. The hardware assumes that the >> handlers are installed at addresses 0x100 * N, meaning that every interrupt >> handler is starting at a multiple of 0x100, and each of each is of size 0xFF >> at maximum. Once an interrupt occurs, the processors jumps to the >> corresponding 0x100 * N address according to the interrupt type. >> >> There are some solutions I propose for the implementation of Install_ISR >> function: >> >> First, the ISR code text can be copied to the correct 0x100 * N address, but >> this will fail if the code text is longer than 0xFF. >> >> Second, the interrupt handlers at 0x100 * N can have the first instruction >> to always jumps to the next word (or any other address in the range of 0x100 >> * N : 0x100 * (N+1) - 1, which is the address of the ISR that the installer >> would write. >> >> I would appreciate any other suggestions. >> >> Regards, >> Hesham >> >> _______________________________________________ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
