Which api's can be invoked from an isr?

[Scott J]

	Thanks Joel, thanks Branko, but... Oops...I call timer_cancel() and timer_fire_after() in timer service routines to re-configure my timers. My system runs well for now. Do I need to modify my code to avoid the potential danger?


>> Hi, all
>>     I'm now so clear about which api's could be invoked from an isr. For example, in a timer service, I know it is part of rtems_clock_tick() which is the timer isr in general, can I call rtems_task_start()? There is a list of system calls which can be called from an isr in RTEMS C User' Guide, but only a few functions listed there. So it is dangerous if I did call functions not listed there?
>
>Yes.  
>
>The general rules are that 
>
>  + you can not block in an ISR because you are not in a task.  
>  + You can not allocate any resources via RTEMS create services,
>    regions, or the C program heap.
>  + You should not do any time consuming operations (broadcast 
>    and printf come to mind here).
>  + Unless you save the floating point context yourself, you
>    should not use floating point operations.
>  + Most if not all network operations are off limits.
>
>>         Thanks for anyone helps.
>>         
>> PS. I find message_queue_send() and message_queue_urgent() are listed there but message_queue_broadcast() not. I'm confused somewhat. :-p
>
>Broadcast is an O(n) operation where n is the number of tasks that will
>receive the message.  Do you really want the overhead of unblocking
>an arbitrary number of tasks and copying the message n times?
>
>FWIW I suspect it is safe from RTEMS perspective to call queue broadcast
>from an ISR but I would say it was bad form to do so in an ISR due to
>the implications on system wide performance and responsiveness.
>
>--joel