Re: Interrupts and Split Memory

Jonathan Sharret wrote:

>Hi,
>
>Continuing my progress from previous posts.
>
>I have managed to split the memory into code memory and data memory and
>in so doing can program my DSP.
>  
>
Your peripheral is using PCE space?

>The DSP sends me interrupts and I need to then clear the interrupt and
>read certain memory locations in the DSP.  I have a couple of questions
>about this:
>
>1)  My split memory routine disables interrupts and after
>reading/writing enables them.  Do I also need to protect this code
>section using "TINIOS_ENTER_CRITICAL_SECTION" and
>"TINIOS_EXIT_CRITICAL_SECTION" when done?
>  
>
No. Critical sections keep you from being process swapped. Disabling 
interrupts does the same and more. This step would be redundant.

>2)  Is it safe to use these routines from within my java Interrupt Event
>Listener:
>"public void externalInterruptEvent(ExternalInterruptEvent e) { //
>native method call here }".  I'm a little confused by what you can and
>can't do from within this method.  Are interrupts already disabled in
>this method?  Is it safe to disable interrupts and split the memory from
>within this method?
>  
>
This event method is Java code. Critical Sections and splitting the 
memory are native method concepts. This event class is intended for use 
by those who are not brave enough to write native code and do not need 
the much faster response time afforded by native ISRs. If you are 
already writing native code I would recommend going straight to the 
native methods and skip this unnecessary step.

Interrupts are not disabled while executing externalInterruptEvent .

>3)  I've also been considering handling interrupts entirely in native
>code.  From what I've read, it goes something like this:
>	a)  Register the ISR code using "System_InstallInterrupt" and
>register a process destroy so clean up.  Is 0x13 used as the interrupt
>offset?
>	b)  The ISR code would read certain DSP memory and put them into
>shared memory space (probably an indirect)
>	c)  A poll routine would check the indirect and if something was
>in it wake up a thread
>	d)  The woken up thread would call a native method to read and
>return the value in the indirect then clear it
>	e)  The native method puts the thread back to sleep
>	f)  Go to b
>
>A few questions on this:
>	1)  Can I split memory in the ISR?
>
Yes.

>  If so, what protections do I
>use?  Disable interrupts?  
>
ALWAYS disable interrupts when splitting the memory map. If any 
interrupt fires and the memory map is not in the default state... BAD 
THINGS WILL HAPPEN.

Also, be careful not to leave interrupts disabled too long. You can lose 
data controlled by other interrupts. For example, If you are receiving 
serial data at 115200 bps you can lose a byte after 86uS 
(1/115200bps*10bits) if you leave interrupts disabled for this duration. 
If you have to move large blocks of data then move the data in a loop, 
disabling interrupts and splitting the map at the top of the loop and 
recombining the map and enabling interrupts at the bottom.

>Enter critical section?
>  
>
See above comments.

>	2)  If I'm working in a multithreaded environment how do I
>control from the native code which thread is put to sleep and woken up?
>	3)  Does the native code need to put the thread back to sleep?
>Or can the thread be in a loop that makes it sleep right after waking up
>and reading the value?
>  
>
Timed sleeps in native code are easy. See native_methods.txt and the 
NativeLibrary example. Suspend and Resume from native code are a bit 
more difficult. The native thread can suspend itself. NEVER resume from 
an ISR. You will eventually get into a deadlock situation (Resume 
completes before Suspend and you will sleep forever waiting for a Resume 
that has already occurred) if you try. Use IOPoll to resume the native 
thread. Your ISR signals IOPoll through some shared memory.

>
>Thanks,
>Jonathan Sharret
>
>TELEGRID Technologies, Inc.
>Email: j.sharret-vt2K7lilQm9Wk0Htik3J/[email protected]
>  
>


-- 
Thomas Chenot

_______________________________________________
TINI mailing list
TINI-6tN4nzCoH/[email protected]
To UNSUBSCRIBE, edit your profile, or see list archives:
http://lists.dalsemi.com/mailman/listinfo/tini