|
|
 | | Re: legOS-0.1.7 released
|
| I finally got my scheduler working on 0.1.6. Porting it to 0.1.7 wasn't too painful. But when I tested it (I have been testing with demo/tm-and-ir), I found that there is junk (not necessarily alphanumeric characters) displayed on the LCD. Thinking (...) (26 years ago, 20-Mar-99, to lugnet.robotics.rcx.legos)
| | | | | Re: Debugging
|
| (...) Try delay(). It's the non-scheduler version of msleep(). If you have a version that's better calibrated, please patch delay() in conio.c to reflect that. (...) A branch to itself is probably the best you can do, as you need an atomic (...) (26 years ago, 20-Mar-99, to lugnet.robotics.rcx.legos)
| | | | | Re: H8300 Stack and SLEEP
|
| Sorry I'm late. I believe this is not an issue with legOS. legOS only calls the ROM powerdown function at the end of its kmain() loop, where the stack pointer should be in the on-chip RAM area anyway. When sleeping in the idle task, legOS directly (...) (26 years ago, 20-Mar-99, to lugnet.robotics.rcx.legos)
| | | | | Re: Idle process
|
| (...) Yes, it's a start byte. Jacob suggested using 0xFn to identify protocol versions, 0xFF being the LEGO standard. (...) Actually, you wouldn't have to change much, just treat P_SUSPENDED tasks like they're P_WAITING and the condition failed. (...) (26 years ago, 20-Mar-99, to lugnet.robotics.rcx.legos)
| | | | | Re: Idle process
|
| (...) Cool! (...) I had been thinking along the same lines. (...) What is the ID? Is it for framing? Is it a byte that is not currently taken up by a Lego bytecode? Do we even care about colliding with Lego's communication protocol? (...) (...) (26 years ago, 19-Mar-99, to lugnet.robotics.rcx.legos)
|
|
