| Async errors [message #772] |
Fri, 16 January 2009 20:03  |
Eclipse User |
|
|
|
I have some ISR code that might hit an error condition. Id like to inform
the application about the error but there is no calling context to pass it
up. Im 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 Im 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. Ill 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 #776 is a reply to message #772] |
Fri, 16 January 2009 23:16  |
| Eclipse User |
|
|
|
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 18:13 |
| Eclipse User |
|
|
|
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 18:58 |
| Eclipse User |
|
|
|
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.
|
|
|
| Re: Async errors [message #849 is a reply to message #780] |
Sat, 17 January 2009 19:03 |
| Eclipse User |
|
|
|
dave russo wrote:
per my earlier response, simply figure out a way to "pass" an
Error_Block to the ISR.... presumably, someone else will be calling
Error_check on it at some point down the road....
this design does raise the question of the atomicity of Error
operations.... since the Error_Block is potentially shared between ISR
and program thread, there could be an issue....
but if you think of this not unlike a driver (where shared buffers
systematically move between the main thread and an ISR) then a scheme
whereby ISRs are "given" Error_Blocks can be imagined.
> 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.
>>
> You could also ask the user to "register" the Error to raise. This
> would allow the user to create a module of error "ids" that can easily
> be identified from within a raiseHook (supplied by the same person that
> defines the error ids).
>
> The default could be one of the "generic" errors defined by
> xdc.runtime.Error.
>
>
>> Thoughts?
>> Todd
>>
>>
|
|
|
Powered by
FUDForum. Page generated in 0.24293 seconds
Home