[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 112: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 112: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 112: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 112: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4688: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3823)
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4690: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3823)
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4691: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3823)
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4692: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3823)
Parallella Community • View topic - Programming Interrupt Handlers

Programming Interrupt Handlers

Discussion about Parallella (and Epiphany) Software Development

Moderators: amylaar, jeremybennett, simoncook

Programming Interrupt Handlers

Postby ysapir » Tue Apr 16, 2013 10:23 pm

Attached is a sample project, demonstrating two methods provided by the eSDK for writing and using interrupt handlers.

A few notes:

The Epiphany's IVT is a table of relative branch instructions (not the target addresses!), with an entry for each event type. When an event occurs, the processor jumps to the respective entry (updating the return address to the IRET register) and performs whatever instruction it finds there. Normally, the branch will target the interrupt handler, which should be terminated by an RTI instruction. When programming an ISR in C, one uses the "interrupt" function attribute, so the compiler generates the appropriate interrupt handler code (like massive registers save and restore, and RTI instead of RTS).

Thus, the 1st entry is populated by the environment with a jump to the beginning of the program. Obviously, the entries cannot contain more than one 32-bit instruction.

Now, there are basically two ways of programming and registering an ISR - the direct and the indirect. With the direct method, one programs the ISR and then sets the branch address in the respective IVT entry to that ISR entry point. Currently, this needs to be done explicitly using pointers and constructing the opcode for the instruction.

Additionally, there's the indirect method. The C runtime provides a default interrupt dispatcher. This dispatcher handles all event types except for the lower two, and uses a function address table to invoke the actual user ISR. Here, the ISR should be registered using the signal() function call. Because the handling is done indirectly, this is a slower method (mostly negligible, though), but it is easier to implement.

The attached code shows the usage of the TIMER0 interrupt event. It is comprised of a host program which loads a master and a slave programs on cores 0x808 and 0x809 resp. After loading, the master is started, registering the ISR in one of the two methods (selectable at compile time with a macro definition), and starting the TIMER0 count. Once the counter reaches zero, the ISR is fired.

In the master's ISR, a "wake-up" signal is raised at the slave core. A mailbox in the DRAM is updated by the cores according to the program's advance, and is sampled by the host to show the program status.

** While writing this demo, I noticed that there is a discrepancy in the E-LIB, where some functions were programmed expecting to get different signal numbers than the default numbers of the E-LIB. There is an offset of 3 between the two sets of enumerations, so you can see the compensation in the master program, in the form of the SOFF constant.
Attachments
interrupt-test.tgz
(2.68 KiB) Downloaded 1624 times
User avatar
ysapir
 
Posts: 393
Joined: Tue Dec 11, 2012 7:05 pm

Re: Programming Interrupt Handlers

Postby Takouh » Wed Apr 24, 2013 9:47 am

Takouh
 
Posts: 13
Joined: Mon Jan 28, 2013 4:39 pm
Location: Stockholm, Sweden

Re: Programming Interrupt Handlers

Postby ysapir » Wed Apr 24, 2013 1:04 pm

First, can you explain *why* you'd want to modify IRET?

Then, I don't know what the new address points at. It is generally safer to let the linker resolve any addresses of relocateable objects. You can use a label (a function name, for example) instead.
User avatar
ysapir
 
Posts: 393
Joined: Tue Dec 11, 2012 7:05 pm

Re: Programming Interrupt Handlers

Postby Takouh » Wed Apr 24, 2013 1:19 pm

Thanks for the prompt response.

The reason why I modify IRET is to be able to call a routine (to go directly to the routine after executing the handler, instead of returning to the previous pc address and resuming the previous program).
I want to invoke a scheduler when the timer expires. I believe if I call the scheduler inside the interrupt routine, the scheduler would be nested inside the interrupt routine, meaning that after execution of the scheduler, it will return to the interrupt routine which is not desirable in my case, since the scheduler itself is invoking some tasks.
So I need to be able to change the return address (PC) of the interrupt handler routine, to make sure after returning from interrupt, the scheduler will be executed.

I used the function label at first, but when it did not work, I thought of using the address itself. The problem is, regardless of the address written in IRET, it always returns to the previous pc and resumes the program.

Thank you
Takouh
 
Posts: 13
Joined: Mon Jan 28, 2013 4:39 pm
Location: Stockholm, Sweden

Re: Programming Interrupt Handlers

Postby ysapir » Wed Apr 24, 2013 1:29 pm

User avatar
ysapir
 
Posts: 393
Joined: Tue Dec 11, 2012 7:05 pm

Re: Programming Interrupt Handlers

Postby Takouh » Wed Apr 24, 2013 1:39 pm

OK, I will do it now. Thank you :)
Takouh
 
Posts: 13
Joined: Mon Jan 28, 2013 4:39 pm
Location: Stockholm, Sweden

Re: Programming Interrupt Handlers

Postby Takouh » Fri Apr 26, 2013 11:33 am

I followed the assembly code of the interrupt handler, the content of the IRET register changes inside the handler, but something else is rewriting it again and forcing it to go back where the interrupt was fired. it happens when it exits the interrupt routine. Is it possible that the content of the IRET is pushed on the stack and when it exits the routine, the IRET is popped? even if the interrupt is not nested?
Takouh
 
Posts: 13
Joined: Mon Jan 28, 2013 4:39 pm
Location: Stockholm, Sweden

Re: Programming Interrupt Handlers

Postby ysapir » Thu May 23, 2013 7:04 pm

User avatar
ysapir
 
Posts: 393
Joined: Tue Dec 11, 2012 7:05 pm

Re: Programming Interrupt Handlers

Postby Suleyman » Thu Jul 16, 2015 7:16 pm

User avatar
Suleyman
 
Posts: 15
Joined: Tue May 21, 2013 7:20 am


Return to Programming Q & A

Who is online

Users browsing this forum: No registered users and 10 guests