 | | Re: signals / legOS internals
|
|
(...) I should add that since many things are vectored in this version of Librcx, overriding functionality is easy for the advanced user to do. For example: extern void (*__event_vector)(void); void my_setup_func() { // ... __event_vector = (...) (25 years ago, 24-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: signals / legOS internals
|
|
(...) I think you're missing the point. Now correct me if I'm wrong, Lou -- I believe the intent of the signal mechanism is to allow a way to specify a function to run when a system event occurs: e.g. a message arrives across the IR port. It is (...) (25 years ago, 24-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: signals / legOS internals
|
|
I misspoke when I said before that we have semaphores. What I meant was mutexes. We have had mutexes for quite awhile. Certainly long before I started on this signal thing. I started this long enough ago that I don't remember what particular problem (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | RE: signals / legOS internals
|
|
(...) Ummmmm, I don't want to speak for Markus, but most embedded kernels (and I use a lot of them) use the term signal and semaphore interchangably. I'm willing to bet a couple of bricks that the intent is to implement semaphores to facilitate (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: signals / legOS internals
|
|
(...) Because they are useful at times, and Markus directed me to implement them. I think the upcoming network code is going to use them, too (at least, that's what I heard). Just 'cause they're there doesn't mean you have to use them. (...) How do (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: signals / legOS internals
|
|
(...) This second methed doesn't really solve anything since you still have to communicate with the compute thread from the receive thread. (...) But what can you actually do in the signal handler? Modify the state of the state of the executing (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: signals / legOS internals
|
|
(...) This is the same thing as most modern RTOS use, called various things. The terminology I use for this is FLIH/SLIH (first level interrupt handler and second level interrupt handler). Coupled with lock priority inheritance, it makes for a very (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: signals / legOS internals
|
|
(...) In OSE interrupt processes (first class processes, that is why we don't call them ISR's) use OS mechanisms (usually messages) to communicate with normal processes. The OS handles all update of shared data structures (such as message queues). A (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: signals / legOS internals
|
|
(...) An ISR can certainly modify data that is used by the executing code. For example, if it doesn't save registers that are used the interrupted code will certainly be affected. In fact, the ISR is of little use if it doesn't modify data that can (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: signals / legOS internals
|
|
(...) But hardware interrupts schedule a different context (the interrupt process or ISR) from the one already executing. A Unix-style signal asynchronously signal interrupts the executing process and jumps to a different location in the code that (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
