forked from clearwater/gaugette
-
Notifications
You must be signed in to change notification settings - Fork 0
/
notes.txt
executable file
·115 lines (73 loc) · 2.23 KB
/
notes.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
Calibration of relief themometer:
-15C is step 0
50C is step 700
55C is FSD
65C is 700 steps
70C is 700 x 70/65 = 753 steps
----------------------------------------------------------------------
Pin 8 Brown 1 TR viewed from back
Pin 9 Orange 2 BR
Pin 10 Blue 3 BL
Pin 11 Green 4 TL
PROTOCOL:
Actions:
DIAL <n> <value>
set gauge to value
I think 100 is not enough steps,
so maybe express as float or 1000ths or 0..255
or query the device to get the fsd range
LED <n> <value>
set led on or off. If we have multiple leds
per device we could address them as 1,1
RGB values? LED 1,1 100,255,128
So what about generalizing dial and led to a single command:
SET a v
where n is an address (which could be a comma separated list)
and v is a value (which could be a comma separated list)
SET 0 0
GET 0 echos back "a v" (or maybe "a v t", see below regarding time stamps)
Later if we support input we can get unsolicited input: "a v"
in the same format, so a push button event might be:
0,1 1
0,1 0
Maybe we want a time stamp to help determine duration of events?
0,1 1 1234
0,1 1 1238
======================================================================
command parser
What we want to get:
First letter of command
Address tuple
Value tuple
Each tuple should be
count,value0,value1...
parser should call
command_handler(command, address, value)
where command is a byte representing the command.
(the first character of the command?), address is a vector of bytes,
and value is a vector of bytes.
Hmmm - that limits me to 256 step resolution, which seems poor.
What about making the values 16-bit signed integers instead?
That seems better.
S 0,0 1000
S 0,0 0
G 0,0
Maximum tuple length is 3 (for rgb) so we need 2 x 4 int16 arrays or 16 bytes.
Seems fine.
So in loop we call the parser
loop:
if there is a character ready, parse_character
end
parse_command checks for serial input.
It could state-machine or parse on CRLF. The latter
would allow backspaces!
parse_character(c)
if input
if input is crlf terminate input string and parse it
else
if buffer is not full add to end of buffer
parse_line(buffer, length)
c = parse_command
a = parse_tuple
v = parse_tuple
command_handler(c,a,v)