Intermec IV7 Basic Reader Interface Programmer's Reference Manual (BRI version - Page 25

Transport Initialization, Multi-Threaded Implementation

Get Intermec IV7 PDF manuals and user guides View all Intermec IV7 manuals
Add to My Manuals
Save this manual to your list of manuals

Page 25 highlights

Chapter 2 - Designing Robust BRI Applications Handler. Lines must be separated in some way, such as preserving the s or converting each line into a separate string. 4 (Optional) Remove and verify the checksum. Remove the last 2 characters from the message line and interpret them as an 8-bit hexadecimal value. Compare the value to the least significant 8 bits of the sum of the rest of the message. If the comparison fails, there is no way to tell the reader to resend a line. Instead, you should notify the Message Layer of a communication failure. Transport Initialization A BRI application should assume as little as possible about the state of the RFID reader when it first connects to the reader. The application can overcome some unexpected prior states of the reader by sending a few BRI commands to initialize the reader before entering normal operation. Immediately after establishing data transport with the reader, the BRI Transport Layer may send an initialization command sequence to the reader and then consume the input stream until it receives the expected number of OK> response terminators. The initialization command sequence depends on the type of transport you are using. To confirm connectivity and expected operation of the RFID reader, use the BRIVER command. For help, see "BRIVER" on page 40. Multi-Threaded Implementation You can implement the Message Layer and Transport Layer using multiple threads. In most cases, you can follow this design, which includes three threads: • BRI Command Processor Thread. This thread calls the BRI Command Processor to execute a BRI command. Once a BRI command is sent to the reader via the transport layer, the Command Processor Thread usually blocks waiting for the OK> BRI response terminator to be returned by the Input Message Thread, described next. • Input Message Thread. It is best to maintain a separate thread that always monitors responses and events from the reader. This input thread routes messages based on whether they are command responses or asynchronous event messages. Typical processing logic for the Input Message Thread is defined by the following pseudo-code: While connected to reader { Read line from input stream If input line begins with "EVT:" then Send line to BRI Event Handler Else Send line to BRI Command Processor } Basic Reader Interface Programmer Reference Manual 13

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
Chapter 2 — Designing Robust BRI Applications
Basic Reader Interface Programmer Reference Manual
13
Handler. Lines must be separated in some way, such as preserving the <CRLF>s
or converting each line into a separate string.
4
(Optional) Remove and verify the checksum. Remove the last 2 characters from
the message line and interpret them as an 8-bit hexadecimal value. Compare the
value to the least significant 8 bits of the sum of the rest of the message. If the
comparison fails, there is no way to tell the reader to resend a line. Instead, you
should notify the Message Layer of a communication failure.
Transport Initialization
A BRI application should assume as little as possible about the state of the RFID
reader when it first connects to the reader. The application can overcome some
unexpected prior states of the reader by sending a few BRI commands to initialize
the reader before entering normal operation.
Immediately after establishing data transport with the reader, the BRI Transport
Layer may send an initialization command sequence to the reader and then
consume the input stream until it receives the expected number of OK><CRLF>
response terminators.
The initialization command sequence depends on the type of transport you are
using. To confirm connectivity and expected operation of the RFID reader, use the
BRIVER command. For help, see
“BRIVER” on page 40
.
Multi-Threaded Implementation
You can implement the Message Layer and Transport Layer using multiple threads.
In most cases, you can follow this design, which includes three threads:
•
BRI Command Processor Thread.
This thread calls the BRI Command
Processor to execute a BRI command. Once a BRI command is sent to the reader
via the transport layer, the Command Processor Thread usually blocks waiting
for the OK> BRI response terminator to be returned by the Input Message
Thread, described next.
•
Input Message Thread.
It is best to maintain a separate thread that always
monitors responses and events from the reader. This input thread routes
messages based on whether they are command responses or asynchronous event
messages. Typical processing logic for the Input Message Thread is defined by
the following pseudo-code:
While connected to reader {
Read line from input stream
If input line begins with “EVT:” then
Send line to BRI Event Handler
Else
Send line to BRI Command Processor
}