 | | Re: signals / legOS internals
|
|
(...) Cool. I will proceed. (...) Yup. I was out of the loop for awhile, and am once again whompin' on this project. (...) That is true. Signals would give the task the opportunity to stop/start tasks under its control, though, without the task that (...) (25 years ago, 26-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: legOS make newbe question
|
|
(...) More to the point, it cannot recognize the '(cd' command. Now, why that is, or how you can fix it, I do not know. It would appear to be a problem with make or with your shell. It should just be farming the entire line off to the shell, which (...) (25 years ago, 26-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: signals / legOS internals
|
|
(...) No, you should not abandon your implementation - not if you want to use LegOS. I was only explaining how I implemented similar functionality, for the sake of comparison. Regarding Librcx, I might release another version at some point, to add (...) (25 years ago, 26-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: legOS make newbe question
|
|
I reinstalled everything and I have progressed to the point of seeing the first-c++.o file and it stops with the following error: -snip- C:\legOS-0.1.7>make h8300-hms-g++ -DCXX -O2 -fno-builtin -fomit-frame-pointer -Wall -Wno-unused -Wno (...) (25 years ago, 26-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: signals / legOS internals
|
|
(...) So, should I abandon my implementation? If something every bit as good is already there, it may be silly for me to continue. I haven't looked at Librcx yet, so I don't completely understand how it works. I think one of the original reasons for (...) (25 years ago, 26-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: signals / legOS internals
|
|
Ola, I do not see why you persist. I understand that a signal handler is very low level, that it is difficult to use right, that it only allows some things and not others, unless you're very careful. But you still missed my point, which was this: (...) (25 years ago, 25-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: signals / legOS internals
|
|
(...) When a frame or character has been received by the IR port it signals an interrupt to the processor. The processor (OS) handles this by invoking an ISR (Interrupt Service Routine). In OSE ISR's are known as interrupt processes and they execute (...) (25 years ago, 25-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | 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)
|
| |
| | Re: signals / legOS internals
|
|
(...) An asynchronous signal models a hardware interrupt. There are times when that is the appropriate interface. There are times when other interfaces are less error prone and are easier to write correctly. Frequently using only synchronous (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: signals / legOS internals
|
|
(...) Why signals?!? Unix-style asynchronous signals is the last feature I would ever want to implement or use. Brain-dead and very dangerous "feature". As you write; "The problem is that a signal can happen at any time". You shouldn't pass this (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: signals / legOS internals
|
|
(...) Actually, gcc moves the stack pointer before using any variables, so it is always safe to use stack below the current stack pointer. If you are using a different C compiler or doing assembly tricks, then you are on your own. (...) Traditional (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | RE: signals / legOS internals
|
|
(...) Not to put too fine a point on it, and I hope Kekoa agrees, but the "fluff" is the reason why replacement firmware works in the first place. Without the ROM vectors being dispatched through RAM pointers that are initialized by the ROM and then (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: signals / legOS internals
|
|
(...) Since it sounds like it might matter to you, I should point out that the interrupt situation on the RCX is a bit more complicated than the H8 manual makes it out to be. Interrupt vectors are in ROM, but the ROM does a dispatch to interrupt (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: signals / legOS internals
|
|
(...) Yes, that is correct. As for passing parameters to a function, they are simply pushed onto the stack before the function call. Therefore, the H8 stack usually looks something like e.g. this: function param sp+10 function param sp+8 return (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: signals / legOS internals
|
|
(...) I may have answered my own question here. Since the SP is adjusted before anything is actually done with the local variables, the rule about it always pointing to the last valid datum is not violated even if local variables are placed after (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: signals / legOS internals
|
|
(...) I may have down and up reversed, since different machines grow the stack upward or downward, and I've worked with a few. I do have push and pop clear in my mind, though. So, yeah, down. So, by the "always" rule, nothing will ever be below the (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: signals / legOS internals
|
|
(...) When you define a bunch of local variables (more than fit in available registers), where are they? Unless you happen to know the answer, I may have to do some more experimenting. Admittedly, it has been awhile, but the last time I was heavy (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: signals / legOS internals
|
|
(...) Reading this again, I should mention that pushing things on the stack asynchronously is fine, as long as the stack pointer is always in the right place, which is why it must always always always point to the location I mentioned (and seemingly (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: signals / legOS internals
|
|
(...) The stack pointer must always always always point at the bottom of the stack data area, i.e. to the last valid data item on the stack. As a consequence, push val (or mov.w val,@-r7) never overwrites data. When an interrupt occurs, the first (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | signals / legOS internals
|
|
Peek-a-boo! I've been banging my head against this a bit and thought I'd see if any of you can shove me in the right direction. I am trying to implement signals in legOS. The problem is that a signal can happen at any time. I know how to make that (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: IR questions
|
|
(...) Only transmitting keeps the tower alive, at least according to my tests. If absolutely necessary, an occasional 0xff sent by the PC will keep the tower alive; this will result in only a start bit being sent, which ought to occupy very little (...) (25 years ago, 22-Jun-99, to lugnet.robotics.rcx.legos, lugnet.robotics)
|
| |
| | IR questions
|
|
This is a whole bunch of IR questions, which come from my first serious fooling around with the IR. Since some of these are legOS or Linux specific, I've cross-posted- I hope no one is too offended. 1) Despite putting the bot in an infinite while (...) (25 years ago, 22-Jun-99, to lugnet.robotics.rcx.legos, lugnet.robotics)
|
| |
| | Re: legOS make newbe question
|
|
(...) I'm sorry it took so long to reply, Phil, but as a non-windows user, well, I didn't see much in the initial messages that led me to think I could help. From what I've seen, this is the cause of the error- the two Makefiles (Makefile and (...) (25 years ago, 22-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: www.legOS.net, maybe?
|
|
(...) Markus, It might be a good idea to carefully review the LEGO Group's policies on domain names, possibly even retaining an attornery if you are serious, or contacting TLG attorneys with specific questions. Note that TLG's "Fair Play" page (URL) (...) (25 years ago, 21-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Blocking IR
|
|
Hi Kekoa, Could you post your working IR .srec code or email me if possible? I have tried the examples with the LegOS read sensor routines and I still get the same results. i.e. it works at about 2mm from the unit but fails after more than 5mm. I (...) (25 years ago, 21-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: www.legOS.net, maybe?
|
|
Well, for at least one year (possibly two) I can keep binaries and other large items on arthurdent (which is where the HOWTO and my Debian binaries are kept.) Let me know if you want space... -Luis (...) ###...### Profanity is the one language that (...) (25 years ago, 21-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: www.legOS.net, maybe?
|
|
(...) ??? Are you sure: I just looked, and they appear to redirect to some other site ((URL) who give you 20 MB and register you at InterNIC - but here's the catch: InterNIC will bill you! There's also a 1.2 MB file size limit (which may or may not (...) (25 years ago, 21-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | www.legOS.net, maybe?
|
|
Hello, sorry for being out of touch. I just stumbled across a service called www.registernic.net. Apparently, they are handing out .com, .org and .net domains and 6MB of webspace free for two years. They register in your name, and they don't even (...) (25 years ago, 21-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Blocking IR
|
|
I'll have to wait now till I get home from work to try the examples :( Phil (...) (25 years ago, 21-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: legOS make newbe question
|
|
Thanks for all of your help. I am surprised also, I thought alot of others were successfully using legOS and thought there would be someone who had gone through this. I checked as you said, and c, c++ and mint are in the legOS.0.1.7 lib directory, (...) (25 years ago, 21-Jun-99, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Blocking IR
|
|
In addition to what I mentioned in the previous message, I also set the sensor input port to active. Setting it to passive also works, in which case the ambient light level seems to be around 480-495, and the sensor aimed directly at the IR port (...) (25 years ago, 21-Jun-99, to lugnet.robotics.rcx.legos)
|
