Subject:
|
dllx for liblnp+lnpd uploaded to arthurdent
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Fri, 7 Jan 2000 02:17:56 GMT
|
Viewed:
|
1378 times
|
| |
|
|
Hello,
i finally managed to get my old 486 back to live and build a little home
network to test lnpd & liblnp in a networked environment. As expected
;-), it works perfectly -- with 2400 baud 8-(.
Running with 4800 baud, i encountered some interesting things. It looks
like the tower has DC related problems in this mode.
If the tower is connected to my old 486 with a real 16450 uart, the
sucessfull transmission depends remarkably on the contents of the
frames. If consecutive long frames containing only 0xff values are
transmitted, the tower seems to screw up sometimes. If this happens, one
has to wait for up to one second before the tower becomes usable again.
Best performance is achieved if the frames transmitted contain something
like 0x55, means: no DC. Astonishingly, frames containing all zeros are
also sent quite well. If i connect the tower to my newer box, which has
16550A uarts integrated on the motherboard, the same symptoms show up,
but by far not as extreme. Unfortunately i don´t have a scope to
investigate this further.
To achieve not too error prone transmission with 4800 baud, it might be
helpfull to use some DC avoiding scheme, like manchester encoding or
stuffing. However, this will burden the RCX with additional load, and
loose more or less of the bandwidth won by doubling the speed.
Currently, i think it´s not worth to invest too much time in this issue,
because fast transmission only works for short distances.
Anyways, for fast dll uploads of large programs i found a somewhat
robust solution: i modified the lnp_assured_write() routine of dll to
detect wether a transmission error or an acknowledge timeout appeared.
Additionally, repeated transmission after errors is done with increasing
gaps between frames sent. This way, i was able to download binaries
consisting of 8k of pure 0xff quite reliably. ( from my hopefully worst
case 486 oldie )
If several screp-ups of the tower happen during one download, sending
with 2048 baud may be faster after all, but it´s also not very realistic
to have an initialized array of 1000 0xff values. ( we have malloc(),
don´t we ? ). The source for dllx is currently in the incoming of
arthurdent, i guess Luis will put it into the LNP directory next week or
so.
|
|
1 Message in This Thread:
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
