VTI Instruments Corp.
APPENDIX C
96
02 84 00
The first line indicates that the driver call used to send the data was successful. The second indicates
how long the packet sent was: 3 bytes, which is what was expected. The next line is the printout of
the packet. The first byte in the packet, as previously stated, is the length of the packet. In this case,
2 bytes (this length does not include the length byte). The other bytes are the CMD_RESET and
CMD_GETBUF commands, in that order.
It is sometimes necessary to allocate space for a return buffer in the sent packet. All MLAN
commands will send back at least two bytes: the command performed and the response to that
command. Additional components may also be included, such as CRC bytes, data echo, or an error
message, but two bytes is the minimum.
In this instance, three bytes were returned: the length of the data, the command performed, and the
response to the command. As before, the length of the packet does not include the length byte. The
two bytes returned are “84” and “00”, where “84” is from the sent packet, the CMD_RESET
command. This is the bus master echoing the command to confirm what was sent. The “00” byte is
the response to that command, in this case ML_SUCCESS. The CMD_GETBUF is not echoed back
in the response, nor is there an error code returned, as this information would be superfluous. This
indicates that the MLAN repeater received the bus master reset and that it was successful. If an error
was encountered during this process, it might look like this:
sent packet without errors
Packet length: 3
02 84 85
got a packet without errors on receive
Packet length: 3
03 84 86 02
This time, 3 bytes were received. The “84” for CMD_RESET, and then “86 02”. From IEEE 1451.4,
Annex G, “86” is the code for CMD_ERROR. This buffer was not processed successfully, and we
have not reset the bus master. The “02” is also in Annex G, and means “RET_BUSY, previous
buffer has not been processed yet.” It will be necessary to wait until the last command completes
before processing this one. Note that this error is purely hypothetical, but illustrates the typical
format for an MLAN error.
With some basic programming completed, the more complex functions required to access a 1-wire
device can be examined.
The get_urn() function, below, is the simplest function in many ways, and the most generic.
int get_urn(
string
name)
{
CComSafeArray<
short
> WriteBuf;
WriteBuf.Create();
WriteBuf.Add((
short
)0);
// reserve first byte for length
// clear the search state so we find the 'first' device
WriteBuf.Add(CMD_RESET);
// do a reset, search and then read results
WriteBuf.Add(CMD_ML_RESET);
WriteBuf.Add(CMD_ML_SEARCH);
WriteBuf.Add((
short
)DATA_ID);
WriteBuf.Add((
short
)0);
// request the result buffer as the last command
WriteBuf.Add(CMD_GETBUF);
// set the length
WriteBuf[0] = (
short
)WriteBuf.GetCount() - 1;
