| |
Yesterday I downloaded legOS 0.2.5 and peeked at the code. Btw. README is
not up to date.
For last two month I was working with a friend of mine on a transport
protocol implemented on top of LNP for the transmission of packets of
unlimited size and with acknowledgements. This was meant mainly as way for
a PC to communicate with an RCX without bothering with collisions, lost
packets, retransmissions... (I know that there is a program which works as
gateway between TCP and LNP, but on the RCX you still have to write code to
communicate and (but I'm not sure) it have no acknowledgments. To cut time
in programming and, above all, in debugging, I decided to write code that
could be run both on Linux and on legOS, using preprocessor directives
where necessary. I wanted to use the same lnp.c on both platforms and so I
studied LNP in depth (but not so deep to reach the interrupt calling
mechanism).
This is the introduction, now comes the real stuff. In version 0.2.3
lnp_addressing_write() and lnp_integrity_write() were not thread-safe. The
patch applied in 0.2.4 fixes this, but it raises two problems:
1. Now lnp_logical_write() is no more thread-safe. Furthermore calling
lnp_logical_write() screw up the semaphore (tx_sem) and so the other two
lnp_XXX_write() become thread-unsafe.
2. On the host computer LNP is still thread unsafe.
I fix this in my work. I wonder if there is some interest in a patch to
apply to the ufficial distribution.
During my perusuals I noticed two points that can be improved in lnp.c.
The function lnp_checksum() computes a 16-bit checksum, while LNP uses only
the 8 low order bits. Removing some lines of unuseful code can speed up
the function. The other interesting thing is how lnp_integrity_byte()
checks the incoming message for integrity. When all data is received it
computes the checksum and compare it with the checksum read from the IR
port. Then it calls the handler set up by the user program, and that
handler probably copies the received packet in a buffer for later
inspection. So the packet is read two times during the same interrupt
call, while previous calls of the same interrupt did very little work. It
seems to me a good idea to generate the checksum as data arrives, easing
the burden of the last call. An alternative could be to compute the
checksum immediatly after receiving the last data byte, but before the
arrival of the checksum byte.
Again if this changes are thought useful, I have no problem to modify the
code and post a patch.
Happy hacking to everyone!
bye,
Bernardo
|
|
Message has 2 Replies:
 | | Re: LegOS 0.2.5 and LNP
|
| (...) Btw. README is (...) Ooops... :-) Changed to 0.2.5 version inside. (...) transport (...) packets of (...) mainly as way for (...) collisions, lost (...) which works as (...) write code to (...) To cut time (...) code that (...) directives (...) (24 years ago, 17-Jan-01, to lugnet.robotics.rcx.legos)
| | | Re: LegOS 0.2.5 and LNP
|
| (...) I cleaned up my code (found one bug!), the patch follows. As you may see now there are two semaphore, because two are the resources to give access to: the LNP buffer and the IR port. I modified the calling of the handlers to avoid race (...) (24 years ago, 20-Jan-01, to lugnet.robotics.rcx.legos)
|
9 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
