| |
In lugnet.robotics.rcx.java, Chris Phillips wrote:
> In lugnet.robotics.rcx.java, Brian B. Alano wrote:
> >
> > 1. Why do some packets use fd instead of f5 for the opcode?
>
> I re-used a function to send command packets to the RCX that was designed for
> use with the original firmware, so it toggles the 0x08 bit of any repeated
> opcode bytes. Mark pointed this out to me when I was developing Full Throttle,
> but then he "fixed" it in LDCC, so I never actually fixed my code. (I really
> should do that...) To be fully compatible with the current implementation, you
> should mask off the 0x08 bit from the packet opcodes, although this isn't
> specified (AFAIK) in the LDCC IRP documentation.
Yes, this is right, to be friendly to as many implementations of the Lego IR
protocol as possible, receiving programs should just mask off bit 3.
> > 2. What's the purpose of the 01 in the second byte? Future use as an LDCC
> > controller address?
>
> That is correct. Mark designed the LDCC IRP with the ability to address up to
> 15 RCXes running LDCC, although at last report this was not yet implemented in
> the LDCC firmware. (All current LDCC RCXes are hard-coded at address 01.) This
> is one of the enhancements that I alluded to in an earlier post that will make
> it possible to control more than 9 locomotives on one layout.
While the code is there to discern packets with different addresses, I haven't
yet added the functionality to the UI to change the address, so it is
effectively hard-coded to address 1. :-)
> > Oh, here's another LDCC IRP question:
> > 3. in ldcc105.zip, the example file ldcc_lnp.c uses lnp_addressing_write() to
> > send IRP commands. Does this mean that LDCC is listening for both IRP commands
> > using opcode 0xf5 AND for IPR commands embedded in LNP packets?
>
> Mark could say for sure, but I believe that this is the case. LDCC is intended
> to recognize both simple F5 opcodes and LNP packets.
You can send an LDCC command wrapped in either a standard Lego packet (using the
prefix F5 01), or wrapped in an LNP addressing packet. LDCC can receive either
type of packet. LNP packets are preferable, though, because they use less IR
bandwidth (i.e. there are no complement data bytes sent). See below for more.
> > Then a leJOS question (I think) and my real problem:
> > 4. As far as I can tell, the only significant difference between the speed
> > commands and the other commands at the packet level is that the speed commands
> > are 6 bytes long (e.g. f5 01 01 01 80),and the others are 3 to 5 bytes long (e.g.
> > f5 01 04). I'm using the Serial class to read the packets. As far as I can tell,
> > Serial isn't doing any validity checking on the packets, just taking whatever the
> > ROM gives it. I assume the ROM can read this packets or LDCC wouldn't recognize
> > them either. Why would the Serial class ignore the shorter packets?
Not that this helps much, but I chose the 0xF5 opcode because a) it was unused
and b) there are other Lego opcodes ending with a 5 (like 0x45-ContinueDL and
0x95-LCheckDo) that do not adhere to the 6-byte rule. Also, LDCC doesn't use
the ROM for serial I/O (it uses the hardware directly), so that's how I can
process both Lego and LNP packets.
Here's a copy of some documentation (slightly updated) I sent Chris while he was
developing Full Throttle (that unfortunately didn't make it into my last zip
file):
LDCC Application Layer
======================
The first byte is the LDCC opcode:
0x01 - Set loco speed & direction
0x02 - Turn loco function off (headlight, etc...)
0x03 - Turn loco function on (headlight, etc...)
0x04 - Stop all locos
0x05 - Track power off
0x06 - Track power on
0x07 - Close switch (straight route)
0x08 - Throw switch (divergent route)
Below are formats for the arguments for each opcode.
Set loco speed & direction packet:
0x01 LOCO SPEEDH SPEEDL
LOCO <- Loco # (valid range is 1 to 9)
SPEEDH <- High byte of speed
SPEEDL <- Low byte of speed (optional - assumed zero when absent)
The speed is a 16-bit signed integer. 0 is stop, 16384 is full speed forward,
-16384 is full speed reverse.
Examples:
0x01 0x03 0x20 0x00
Set loco #3 to half speed forward
0x01 0x05 0xC0 0x00
Set loco #5 to full speed reverse
0x01 0x07 0x00 0x00
Stop loco #7
0x01 0x05 0xC0
Set loco #5 to full speed reverse (short version)
0x01 0x07 0x00
Stop loco #7 (short version)
Turn loco function off (headlight, etc...)
0x02 LOCO FUNC
Turn loco function on (headlight, etc...)
0x03 LOCO FUNC
LOCO <- Loco # (valid range is 1 to 9)
FUNC <- Decoder function # (FL=0, F1=1, F2=2, ... F12=12)
Examples:
0x03 0x06 0x00
Turn on the headlight (i.e. FL) of Loco #6
0x02 0x08 0x04
Turn off function 4 (F4) of Loco #8
Stop all locos
0x04
Track power off
0x05
Track power on
0x06
These packets don't have any arguments.
Close switch (straight route)
0x07 SWITCH
Throw switch (divergent route)
0x08 SWITCH
SWITCH <- Switch number (range is 1 to 255)
Examples:
0x07 0x05
Close switch #5
Lego Packet Layer
=================
Each of the above LDCC commands gets prefixed as follows:
0xF5 ADDR {LDCC command}
ADDR <- RCX host address (valid range is 1 to 15)
This allows up to 15 different RCX's to be addressed. Right now the firmware
is preset to address 1, but this will be configurable.
Here's an example:
Turn headlight on for Loco #5:
0xF5 0x01 0x03 0x05 0x00
Which when transmitted as bytes on the tower looks like this:
0x55 0xFF 0x00 0xF5 0x0A 0x01 0xFE 0x03 0xFC 0x05 0xFA 0x00 0xFF CS ~CS
CS <- The normal RCX checksum
LNP Packet Layer
================
Alternatively, LDCC commands can be wrapped in an LNP addressing packet. Here is
the same command (turn headlight on for loco #5) transmitted with LNP:
0xF1 LENGTH DEST SRC 0x03 0x05 0x00 CS
LENGTH <- length of entire packet minus 3 (5 in this example)
DEST <- host and port number (currently 0x11)
SRC <- host and port number of sending process (anything)
CS <- LNP checksum (sum of all other bytes minus 1)
Anyways, I know this probably doesn't help with question #4, but it seemed
otherwise relevant... :-)
Cheers,
Mark
|
|
Message is in Reply To:
 | | Re: leJOS & LDCC IRP
|
| (...) I re-used a function to send command packets to the RCX that was designed for use with the original firmware, so it toggles the 0x08 bit of any repeated opcode bytes. Mark pointed this out to me when I was developing Full Throttle, but then he (...) (21 years ago, 12-Sep-03, to lugnet.robotics.rcx.java, lugnet.trains)
|
14 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
