• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 99 subscribers
  • Views 1325 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

What SYS/BIOS functions to avoid when using HWI_plug to handle ISRs directly instead of using HWI library?

Graham Bartlett
Intellectual 460 points
Other Parts Discussed in Thread: SYSBIOS

I've asked previously about how to get maximum performance from interrupts, and the answer was to handle ISRs directly, using Hwi_eventMap() and Hwi_plug() to set up the interrupt instead of using the HWI library.  This is working fine (with the important note to other engineers that you need to follow the steps in TI datasheet SPRUFE8B section 5.6.2 if you want preemptable interrupts).

Your docs (and advice here) have said that these ISRs must not call SYS/BIOS functions though, and I'd like a bit more clarification on that, please.

All your examples of this have concentrated on Semaphores.  OK, no using them in these ISRs.  Is it possible to call Swi_post() from these ISRs though, or is that out of the question too (since the context switch won't check for new SWI triggers)?  How about other operations, such as posting HWIs, starting/stopping/checking Timers, starting/stopping Clocks, handling Events or Queues, etc.?

You already have "Calling context" sections in your help for each library module, which tell us where we can call each function from.  What I'm basically after is the missing first column from that table of "plugged ISRs" which would logically come before "HWI".

  • 0
    TI__Mastermind 26780 points

    Graham,

    Right, *some* APIs can be called in a minimal ISR.  What must be avoided are any APIs that will trigger scheduling of a thread to run, because the scheduler and thread will run immediately in the context of the ISR.  A “normal” ISR managed by the Hwi module will have the necessary protection to avoid this.   

    We generally say “no APIs” to be on the safe side.  Some APIs obviously affect scheduling (like Swi_post(),  Task_sleep(), Task_yield(), Semaphore_post(), Event_post()), but there are others that might not be obvious, for example Mailbox_post() (which internally does a Semaphore_post()).

    There are some that should be safe though, for example, Queue operations, and starting/stopping individual Timers and Clocks.  And a Hwi_post() is probably OK too, as long as the Hwi being posted is similarly minimal.

    I suggest:  1) stay away from any APIs that are already documented as not being OK from a Hwi, and 2) look at the source code for the APIs you want to call, and verify that the API sufficiently avoids thread scheduling for your use case.  The kernel sources are in your SYS/BIOS installation at a location like:  <bios_6_x_y_z>/packages/ti/sysbios/

    Hope this helps.

    Scott

  • 0 in reply to ScottG
    Intellectual 460 points

    OK, thanks Scott.  It's not quite the answer the answer I hoped for, but it's the answer I expected based on what I knew about the kernel. :-/ 

    What it is, I've got a HWI which sometimes (but not always) posts a SWI, and I'd like to reduce overheads on it, but of course I can't set it up as a minimal ISR if it needs to post the SWI.  I have an idea that perhaps making this a minimal ISR and then having it post a "normal" HWI which in turn posts the SWI might work, and IER bitmasking on the HWIs/ISRs would keep it out of the way of higher-priority stuff.  I'll check the kernel code and see whether that'll do it.  If it works, I'll put some sample code up for other people to use, because it seems like it'd be a useful code pattern.

    Thanks again for the feedback.

  • 0 in reply to Graham Bartlett
    TI__Mastermind 26780 points

    Graham,

    If you post a normal Hwi from a minimal ISR, and that triggers scheduling, new thread(s) will run before your minimal ISR completes.  Even if you’re masking via IER bits.  This will probably eventually unwind OK, but there may be some non-obvious side effects.  It will increase context on the immediate stack, and if you have a bunch of stacking of interrupts (e.g., one of those threads posts the minimal ISR again) the SP it might blow past the allocated stack.  But maybe this is not a concern for your particular application(?)

    On other CPU architectures where interrupt priority will fully and automatically block out lower priority interrupts from running until the higher priority finishes, I think you should be able to post a lower priority “normal” Hwi without stack concerns.

    Scott