-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathPROTOCOL.txt
174 lines (118 loc) · 5.89 KB
/
PROTOCOL.txt
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
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
Th BMF protocol
===============
This document defines a protocol for communications over a serial line between
a host running the bmf application and an embedded system to control a
bi-dimensional machining facility.
The host is a system running the application based on python and bindings for
the QT development library. The application is developed on Linux and deployed
on Windows. For the purpose of this document, the host is referred to
as *the PC*.
The embedded system in the prototype is a Z80 family processor, with the peer
implementation in assembly language for that processor. The embedded system
is therefore referred to as *the Z80*.
The PC runs an application which displays a user interface, sends frames to
the Z80, and receives frames as well. The Z80 sends updates to counters and
display on the PC. The user interface features:
-- Keys arranged on one or more keyboards.
-- A dialog of counters
-- A character-based display (using a fixed font, and fixed dimensions) for the z80 to display arbitrary information.
Protocol has not yet been analyzed. In general, the PC being more powerful, handles user interaction, and often checks for
arrival of new data from the Z80 (without polling), and will post commands from the user as needed. The Z80, having real-time constraints and limited resources, will check for data when convenient, and post commends when ready.
Original implementation was expecting 10´s of updates per second. It turns out that the Z80 code is simplest when
it sends several hundred updates per second.
Notation
--------
Raw hexadeximal values are assumed for all numbers (no prefix used.)
In some cases, ASCII names will be used for characters.
NUL - ASCII NUL character (00)
LF - ASCII LF (Line Feed) character (0x0a)
The protocol is peer to peer, with each side able to send commands asynchronously. frames are structured as follows:
<opcode> <arguments> LF
opcode is a single byte determining the meaning of the rest of the frame. LF terminates the frame.
In some cases, LF may be present in the middle of the frame, but these cases are to be minimized.
Opcodes:
Other opcodes are:
3A - Intel hex formated data record
Trigger send of data in 8-bit Intel Hex format, blocked by 24 byte frames.
if frame less than 24 bytes, it is padded with NULs.
':' <datacount> <AddrH> <AddrL> <type> <data> <chksum> <padding... >
static last frame, triggers a return to command mode:
':' 00 01 ff 00 00 00 ...
80 - Block Mode
<name>,LF
Initiate a block mode transfer. Data transfer uses intel hex format data
records. In this mode, transfers are synchronous. Sender sends one
intel hex record, awaits an acknowledgement. if sender receives negative
acknowledgement, sender should resend.
<name>, is optional. It can be used if the peer has a file system
available, to write the file.
FIXME: retransmission is an infinite loop... limit it somehow?
81 - Display characters
<x>, <y>, <string> LF
x - single byte column dimension bitwise ored with 0x80
y - single byte row dimension bitwise ored with 0x80
<string> -- arbitrary sequence of printable ASCII characters
sequence ends with line feed.
if x=ff and y=ff, then it means clear screen.
error conditions:
- dimensions off screen.
- non-printable characters in string.
82 - Button State Change
<Id>,flags,LF
Id - one byte index of the button pressed.
00 - button release
01 - button set.
Key ID's defined:
10 - 1f - keypad 1
20 - 2f - keypad 2
-- labels can be set using the same indices.
83 - Acknowledge last command received
<status>, LF - completion status of last command received.
00 - OK - ack.
otherwise, bad. - nack / negative acknowledgement.
01 - malformed line, resend please
note: unless in block mode, acknowledgements are not required.
84 - Position Counter
<idx>,<i>,<j>,LF
request that character display include the idx counter at the
given position. Future counter updates will cause a 6 character
string update at that location.
encoding is similar to write string command.
i=7f,j=7f -> cancel (stop updating counter value here.)
85 - Update LEDS
<LED>,LF
bit mask of LEDS to light.
86 - Update Labels - change a label in the UI somewhere.
<idx>,String,LF
index is straight...
Idx: 0-3 LEDS 0-3.
Counter Display
4-7 Column heading, then labels for three counters (0,1,2)
8-11 2nd column heading, labels for three counters (3,4,5)
10-1f - keypad 1 keys
20-2f - keypad 2 keys
87 - Send Me - request z80 dump contents of memory.
SH,SL,CH,CL,String,LF
Start Address, High, then Low byte.
transfer count, High, then low byte.
String = filename
Send me the file named by the string. If the file ends in .hex,
then use the addressing from the file. Otherwise, use the given
start address when building the intel hex transfer records.
peer is to respond with a 0x80 with the same filename followed by
a series of intel-hex encoded records of data from the named file.
initial destination address of data given by Start.
88 - MousePress
<i>,<j>,LF
indicate column and row where a mouse click has occurred.
encoding is similar to write string command.
90 -> 9f - update counters 0 through f.
<Hi>,<Lo>
AA - Alcaholics Anonymous...
drunken sailor mode, peer is to respond with a large number of screen
and counter updates, to demonstrate functionality.
Protocol Analysis
-----------------
now that it is symmetrical, am reassured.
re-synchronization... if we get lost, how do we get back in sync? not sure the resync stuff works,
what if they both lose sync... what should they do?