| |
Hi Markus, sorry for the delayed response, but finally i'm back:
You wrote:
>
> the FD_ZERO bug sounds interesting. Maybe there's a way to work around
> this issue in a more portable way? Like, remove /usr/include from the
> Makefile and hope for the best?
i found a way that may be somewhat cleaner, by separating the lnp
related header files needed by the utilities from the libc stuff:
created a directory in legOS/include named lnp, and moved lnp.h and
lnp-logical.h from legOS/include th this directory. created a directory
named sys in this directory, and moved irq.h, lnp.h and lnp-logical.h
from
legOS/include/sys to this directory. Changed the CINC Variable in
Makefile.Common to
CINC =-I$(LEGOS_ROOT)include -I$(LEGOS_ROOT)include/lnp -I.
changed the CFLAGS in the dll-src Makefile to
CFLAGS=-O2 -Wall -I. -I../../include/lnp
> The debugging output shows that the host is sending packets and
> receiving their echos, so sending/receiving IR works. But the RCX
> doesn't acknowledge those packets.
after some hours of fiddling with the code i realised the Hex Codes seen
in the debugging output are coming from the IR-Tower, not from the RCX.
The Tower is echoing everything sent to it (it might also be the linux
terminal driver, but if i disconnect the tower, nothing is echoed).
Tomorrow i'll have a closer look at that.
by the way, i think i found a little bug in loader.c/sigio_handler()
void sigio_handler(int signo) {
if(signo==SIGIO) {
struct timeval last,now;
^^^^^^^^^^^^^^^^^^^^^^^^
as i understand it >last< must be static to preserve it's value across
subsequent calls of the handler. Further, the first invocation is very
likely to fail because last isn't initialized. My quick hack: make last
a global static and initialize it in lnp_assured_write(). I think this
is not foolproof, because writing a struct timeval is not atomic. What
do you think about switching to POSIX signals, which can be blocked ?
>
> Maybe the timeouts I chose for the host side are too aggressive. Try
> higher values, if this works, I shall increase them.
>
> What's please remove battery mode? Does legOS hang? If it doesn't, press
> ON/OFF and PRGM simultaneously to return to ROM.
increasing the timeouts doesn't help, imho because nothing comes back
from the RCX. Indeed, it looks like the RCX hangs immediately after the
tower has started transmission. ON/OFF-PRGM has no effect anymore, so i
have to remove the batteries to get the RCX back to life.
uuh, must go to bed now, it's 5:50 and work start's at 9:00. Have a nice
day,
Martin
|
|
Message has 1 Reply:
Message is in Reply To:
 | | Re: legOS-0.2.2
|
| Hi Martin, the FD_ZERO bug sounds interesting. Maybe there's a way to work around this issue in a more portable way? Like, remove /usr/include from the Makefile and hope for the best? The debugging output shows that the host is sending packets and (...) (25 years ago, 9-Nov-99, to lugnet.robotics.rcx.legos)
|
14 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
