New user questions

[Chris Johns]

Mike Panetta wrote:

> I am new to RTEMS, and I had a few, possibly simple questions.  I have
> read some of the documentation on line, but it does not seem to answer
> my particular question.
> 
> The first question is not really related to RTEMS in itself but to the
> list.  Are there any list archives that I can search through?  It seems
> there were at one point, but the link is broken now.
> 
> The second question is this:  Is there a way to do something similar to
> setjmp/longjmp from a fault signal handler (say like a SIGBUS handler
> for example), but from an rtems ISR?  I am writing a piece of code that
> I want to be able to let recover from a bus error, but I am not quite
> sure how to do it in RTEMS using an ISR.  I know how to set up the ISR,
> but I am not quite sure how to do the context save/restore for the task
> that I want to recover.  Does such a facility exist in RTEMS?  If not,
> what would be involved to get this idea to work?  Is it even a good
> idea? ;) The basic idea is I have a VME rack, that may or may not have a
> memory card at a particular address, and if its not there I want it to
> gracefully recover from the bus error thats generated.  Having something
> like setjmp/longjmp for this would be great, because I could save the
> task context before I do the bus op that may fail, and if it does I can
> get notification via the return value of the "setjmp" function, which
> would also restore the task back to the place it was before it failed.
> 


I have code to do this for m68k targets. It uses setjmp/longjmp. Its 
make a simple means of probing hardware.

I attach the start of the API for RTEMS. A header file called probe.h 
needs to be created and add to the rtems include tree. Maybe Joel can 
help here. I currently have the CPU_probe_exception_* hooks in a 
separate C file for the m68k family. These could be inlined in the cpu.h 
file for the specific processor.

In time the way the probes are implemented may. A machine check of any 
form should result in the task being suspended rather than RTEMS stopping.

I hope this helps.

-- 
  Chris Johns, cjohns at cybertec.com.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtems-probe-api.tar.gz
Type: application/octet-stream
Size: 1303 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20020214/bde5c056/attachment-0001.obj>