Subject:
|
reply framing in firmdl3/rcx_comm.c
|
Newsgroups:
|
lugnet.robotics.rcx
|
Date:
|
Thu, 6 Feb 2003 12:52:31 GMT
|
Viewed:
|
2405 times
|
| |
|
|
--- From: Kekoa Proudfoot [via Pat LaVarre]
About rcx_comm.c waiting twice, I see where the confusion is now.
If no bytes are available, the wait will be T. If some bytes are available,
obviously you have to wait at least as long as it takes for all the bytes to
arrive at the serial port. The wait will be T for the final select where no
bytes are received, plus what you called T-M, which is the extra time added
by the second-to-last select. However, this is only true if maxlen is set
greater than the actual size of the incoming message. If maxlen is less
than or equal to the actual size of the message received, the wait is simply
T-M. There will be no zero-byte select.
Looking at the code, there are four places where nbread is called. One of
these, the nbread in rcx_send which receives the tower echo, already makes
use of maxlen. Two of the remaining three calls to nbread could be
optimized to use maxlen. The nbread in rcx_wakeup_tower could be rewritten
to optimize the case when the warmup "10 ef 10 ef" is received correctly.
The nbread in rcx_recv could be rewritten to take into account maxlen,
assuming the user set that to the expected number of bytes to be received.
Another way to say this is that every call to nbread should be split into
two calls, one to receive an expected number of bytes, and another to
receive any extras if the expected bytes fail validity checks. The calls to
nbread in rcx_recv are already split this way. The same could be done in
rcx_send and rcx_wakeup_tower.
I don't know who really cares about this if anybody, but definitely things
could be improved a bit.
...
One other improvement I just thought of. rcx_recv has a caller-specified
timeout. This is because sometimes the RCX takes a bit of time to formulate
a response, especially when unlocking the firmware, since the firmware is
examined before a response is sent. The caller-specified timeout really
applies to the first byte and first select only. Subsequent selects could
use a smaller timeout based on the expected time between bytes...
Another tiny optimization should anybody really care to optimize all this.
...
--- End From
I'd say Kekoa wrote this forwardable reply re how the Linux/ Solaris/ etc.
rcx_comm.c does frame standard RCX replies after offline discussion sparked by:
http://news.lugnet.com/robotics/rcx/?n=1926
Subject: Re: frame RCX reply how
From: "Pat LaVarre" <ppaatt@aol.com>
... I'll have to decipher code on the web that purportedly works, such as:
http://graphics.stanford.edu/~kekoa/rcx/tools.html#Firmdl
...
http://graphics.stanford.edu/~kekoa/rcx/firmdl3.tar.gz
71,680 bytes
...
I'd now guess the firmdl3/rcx_comm.c algorithm for framing standard RCX
replies is... til ...ms elapses twice without bytes or ...
...
How inaccurate are my guesses? Personally I'm vastly ignorant of the
details of the Linux serial API, but I knew a select in a past life.
...
|
|
Message has 1 Reply:
 | | Re: reply framing in firmdl3/rcx_comm.c
|
| --- From: Kekoa Proudfoot [via Pat LaVarre] ... About message framing, I would not say that the designers at Lego had something specific in mind for RCX-to-PC messages. Framing for those messages is very ad-hoc. One thing which is very useful is the (...) (21 years ago, 7-Feb-03, to lugnet.robotics.rcx)
|
2 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
