VTI Instruments EX1629, Руководство пользователя

Страница: 338 / 346

VTI Instruments Corp.
338 EX1629 Onboard Memory
// set the length
SendPkt[0] = sendLen - 1;
// send and receive the frame
MLanHostPacketSend(SendPkt, channel);
CRCcalc(SendPkt, 6, 11);
recLen = MLanHostPacketReceive(RecPkt, channel, MLAN_PACKET_SIZE);
return recLen;
}
This follows the same format as the DS2430’s command as it is a concatenation of the
WRITE_SCRATCHPAD and COPY_SCRATCHPAD commands. The CRC16 is calculated on
the sent packet, and the returned result still contains the CRC bytes. However, as the results are
already written to memory, a bad write will only be evident after the fact.
Here is some example output from this command:
sent packet without errors
Packet length: 27
1A 82 0A 0C 0D 0F 00 00 AA 02 03 04 05 06 07 08 82 0A 05 04 55 00 00
07 0B 01 82
CRC16: 74E4
got a packet without errors on receive
Packet length: 26
19 82 00 0A 0D 0F 00 00 AA 02 03 04 05 06 07 08 74 E4 82 00 0A 04 55
00 00 07
We can again see the CRC returned at the end of the WRITE_SCRATCHPAD portion of the
WRITE_AND_COPY command, and that it matches what was calculated, indicating a successful
write.
A
DDITIONAL
N
OTES
Checksums
It should be noted that a “page” in the main memory of 1-Wire device consists of 32 bytes
according to the IEEE 1451.4 specification. Each page of memory is supposed to have a one-byte
checksum as the first bit, which when added to the other 31 bits in the page (dropping any carry)
makes the result 0. In the example code (and in the EX1629 driver used to implement it) there are
no checks made to ensure that the user inserts a checksum properly. If the user wishes to
implement checksums (and, therefore, be fully compliant with the IEEE 1451.4 standard), a proper
checksum should be written to the first page of memory, updated when memory is updated, and
the checksums should be calculated and verified on reads.
Sending & Receiving
The “
MLanHostPacketReceive
” and “
MLanHostPacketSend
” functions are not defined
in the above examples. This is because the implementations of these functions are specific to the
interface to the device. The example code does, however, provide definitions of these functions
which work with the EX1629 instrument driver. These are below:
int MLanHostPacketReceive(uint8_t *receive_packet, int channel, int
len)
{
int result = 0;
int data = NULL;
ViChar error[256];
#define MLANBUFLEN 48
// add platform/protocol specific code here