|
| Re: Async errors [message #776 is a reply to message #772] |
Sat, 17 January 2009 04:16   |
 Bob Frankel
Messages: 12
Registered: July 2009 |
Junior Member |
|
|
Depending upon what might happen in Error_raise(), calling it from an
ISR might not always be advised. To be conservative, treat the ISR as
an effective extension to external hardware -- which (clearly!) can't
call Error_raise() directly.
I would recommend that the ISR simply return status as part of the
current job, which then can be turned into an Error_raise call.
The callback scheme could also work, especially if it's treated as a way
to simply "latch" the fact that an error occurred; the latch could be
polled, or alternatively trigger a thread when written to.... either
way, someone other than the ISR can then call Error_raise.
Finally, since ISR can/may run on their own stack, the concept of
unwinding upon an Error_raise call makes no sense!!!
Todd Mullanix wrote:
> I have some ISR code that might hit an error condition. I�d like to
> inform the application about the error but there is no calling context
> to pass it up. I�m thinking of simply calling Error_raise() (with a
> local Error_Block) with the specific error. Then the application could
> have a raise hook and be able to deal with the specific error.
> On the surface this seems like an easy solution, but I�m a little
> worried it does not scale well. If everyone did this, the hook would get
> long. The application could have some type of callback registration
> mechanism to keep the raiseHook small, but then we asking the app to do
> more work.
>
> Another option was simply allow the user to register a callback with my
> module. I�ll call that when an async error occurs. Of course there would
> be some restrictions on the callback since it would be ISR context.
>
> Thoughts?
> Todd
>
>
|
|
|
|
| Re: Async errors [message #811 is a reply to message #776] |
Sat, 17 January 2009 23:13 |
Dave Russo
Messages: 172
Registered: July 2009 |
Senior Member |
|
|
Bob Frankel wrote:
> Depending upon what might happen in Error_raise(), calling it from an
> ISR might not always be advised. To be conservative, treat the ISR as
> an effective extension to external hardware -- which (clearly!) can't
> call Error_raise() directly.
>
> I would recommend that the ISR simply return status as part of the
> current job, which then can be turned into an Error_raise call.
>
> The callback scheme could also work, especially if it's treated as a way
> to simply "latch" the fact that an error occurred; the latch could be
> polled, or alternatively trigger a thread when written to.... either
> way, someone other than the ISR can then call Error_raise.
>
> Finally, since ISR can/may run on their own stack, the concept of
> unwinding upon an Error_raise call makes no sense!!!
>
So an ISR can't/shouldn't call any method that has an Error_Block as a
parameter? If so, API designers need to be very careful to avoid the
use of Error in code that can _potentially_ be called from an ISR.
It's certainly true that you should minimize the time in an ISR, but
Error is fast enough that it's not unreasonable to call it (or another
function that uses Error) in ISR code; especially, if you don't control
the code that you are calling.
That said, the recommendation to "latch" errors and use other non-ISR
threads to handle errors is probably the best design.
|
|
|
| Re: Async errors [message #826 is a reply to message #811] |
Sat, 17 January 2009 23:58 |
Bob Frankel
Messages: 12
Registered: July 2009 |
Junior Member |
|
|
i take back what i said earlier....
i think the real question is.... where did the ISR get the Error_Block*
that would be passed to Error_raise().... passing NULL would (of
course) bring the system potentially....
i could imagine a driver whose 'startIO' function might require an
Error_Block, which is then made available to the ISR.... in this case,
a call to Error_raise() would make perfect sense.... the driver would
then return to its client, who can call Error_check() in the usual
way....
dave russo wrote:
> Bob Frankel wrote:
>> Depending upon what might happen in Error_raise(), calling it from an
>> ISR might not always be advised. To be conservative, treat the ISR as
>> an effective extension to external hardware -- which (clearly!) can't
>> call Error_raise() directly.
>>
>> I would recommend that the ISR simply return status as part of the
>> current job, which then can be turned into an Error_raise call.
>>
>> The callback scheme could also work, especially if it's treated as a
>> way to simply "latch" the fact that an error occurred; the latch could
>> be polled, or alternatively trigger a thread when written to....
>> either way, someone other than the ISR can then call Error_raise.
>>
>> Finally, since ISR can/may run on their own stack, the concept of
>> unwinding upon an Error_raise call makes no sense!!!
>>
> So an ISR can't/shouldn't call any method that has an Error_Block as a
> parameter? If so, API designers need to be very careful to avoid the
> use of Error in code that can _potentially_ be called from an ISR.
>
> It's certainly true that you should minimize the time in an ISR, but
> Error is fast enough that it's not unreasonable to call it (or another
> function that uses Error) in ISR code; especially, if you don't control
> the code that you are calling.
>
> That said, the recommendation to "latch" errors and use other non-ISR
> threads to handle errors is probably the best design.
|
|
|
|
Powered by
FUDForum. Page generated in 0.03694 seconds
] 
Search
Help
Register
Login
Home
