chiark / gitweb /
change power to 0x10 and 0x11; new crash reset command
[trains.git] / cebpic / README.protocol
1 PROTOCOL BETWEEN HOST AND MASTER PIC
2 ====================================
3
4 9600 8N1 over the serial port.  The PIC must obey the host's flow
5 control line, so that if the host gets backed up none of the PICs
6 messages can get lost.  (If this is too hard, then the PIC should
7 attempt to buffer some data while the host is busy but if the PIC's
8 buffer gets too full it should panic.)
9
10 Each message consists of a number of 8-bit bytes.  The top bit of each
11 byte is 1 iff there is another byte in the message.
12
13  First       Second      ASCII  Message   Brief
14   Byte        byte etc.  or hex  name      description
15
16 From host to PIC:
17
18  > 1 0100 TTT  0 TTTTTTT  (a0)  POINT     Point T fire
19  > 1 1111 111  ....       (ff)  NMRADATA  NMRA data
20  > 1 0001 XXX  0 XXXXXXX  (88+) PING      Ping `X' (please Pong `X')
21  > 1 0010 RRR  E RRR...   (90+) POLARITY  Set polarity
22  > 1 0011 000  0 MMMMMMM  (98+) WATCHDOG  W'dog reset, t/o <M*16>ms from now
23  > 0 0010 001             (11)  ON        Power on
24  > 0 0010 000             (10)  OFF       Power off
25
26  > 00000000                     CRASHED   Acknowledge panic, go to readout mode
27
28 ; In crash readout mode:
29 ;
30 ;       00000000  MS    Select crash readout mode if not already
31 ;                       Reset crash readout pointer to 0
32 ;
33 ;       00001000        Acknowledge RS232 framing error or overrun
34 ;       00001001        Reboot
35 ;
36 ;       1vvvvvvv  M     Prepare byte 0vvvvvvv for transmission to the slave
37 ;
38 ;       00000nnn  M     (n>0) prepare to receive nnnn bytes from slave
39 ;       0001nnnn  M     (n>0) transmit nnnn bytes of our own from the
40 ;                         readout pointer
41 ;
42 ;       001sssss  M     Select slave S^0x10.  Then:
43 ;                        After 1vvvvvvv
44 ;                         Transmit just 0vvvvvvv to slave
45 ;                         and then send some some unspecified byte to host
46 ;                        After 0000nnnn
47 ;                         Receive nnnn bytes, forwarding each one
48 ;                         to the host.
49 ;                        After the transaction is complete, 1vvvvvvv
50 ;                         or 0000nnnn must be specified again before
51 ;                         001sssss is repeated.
52 ;
53 ;       01bbbbbb  MS    Supply 6 bits for crash readout pointer
54 ;                        (crash readout mode only)
55 ;                        Effect is   FSR << 6; FSR |= bbbbbb
56
57 From PIC to host:
58
59  < 1 001Y SSS  0 SSSSSSS  (9?)  DETECT    Train is (Y=1) or is not (Y=0) at S
60  < 1 0001 XXX  0 XXXXXXX  (88+) PONG      Pong `X' (reply to Ping `X')
61  < 0 000 1001             (HT)  HELLO     I am booted
62  < 0 000 1011             (VT)  AAARGH    Followed by debug chars (only)
63  < 0 000 1101             (CR)  WATCHDOG  Timeout happened
64  < 0 000 0111             (BEL) FAULT     Fault exists
65  < 0 000 0110             (ACK) FIXED     Fault now fixed
66  < 0 0100 PPP             (20+) POINTED   Point change done using capacitor P
67  < 0 0101 PPP             (28+) CHARGED   Point capacitor P is now charged
68  < 0 00000 FF                   NMRADONE  Have processed F NMRADATA message(s)
69
70  < 0000 1010              (LF)  } debugging output        0x0a (newline) and
71  < 001C CCCC                    } (works with terminal      0x20-0x7e
72  < 01CC CCCC except 0111 1111   }  emulator, or host logs)  (printing ASCII)
73
74 (These are all shown big-endian, and all of the numerical
75 representations are big-endian too.  Where a number is split across
76 two or more bytes, the relevant bits are to be concatenated, in the
77 order shown, ie bits from the MS byte first, into a larger number.)
78
79
80 HELLO, AAARGH and debugging output
81 ----------------------------------
82
83 When the master PIC starts up and has confirmed that all is well (all
84 of the other PICs are there, etc), it should send HELLO once.
85
86 If the host makes a mistake (eg, sends an unknown command, or does
87 something else wrong) or something goes horribly wrong, the master PIC
88 should send AAARGH.
89
90 The PIC may always send printing ASCII characters and spaces and
91 newlines (ie, bytes 0x0a, 0x20-0x7e).  These will print out nicely in
92 a terminal emulator, if that's what's running on the host.  If the
93 host is running the real software, that software will put the
94 characters sent in its log or somewhere else nicely accessible.
95
96 Apart from debugging output, the PIC should send nothing before HELLO
97 and nothing after AAARGH.
98
99
100 POWER AND FAULT
101 ---------------
102
103 The host can send ON and OFF to turn the track (and various other
104 stuff) on and off.  After ON, the track power should be enabled and
105 transmitting NMRA idle, and the CDU should be enabled.
106
107 If the power is ON, and a track power short circuit is detected, the
108 PIC should send FAULT.  When the short circuit is removed, the PIC
109 should send FIXED but not fully reenable track power; track power
110 should be reenabled when the host transmits ON.
111
112
113        Track and CDU                     Track and CDU
114         disabled      -------ON------->   enabled
115                 .
116                /|\                           |
117                 |                            |Short circuit detected
118                  \                           |
119                   \FIXED                   FAULT
120                    \                         |
121                     \__________________      V
122                         operator       `
123                     fixes the short     Short circuit
124                                       (User Fault indicator lit)
125
126
127
128 POINTS and CDU
129 --------------
130
131 The ON command should cause the CDU to be enabled (and of course all
132 point motor outputs should be disabled first - see README.circuitry).
133
134 Following ON the host must wait until it receives CHARGED before
135 attempting to change a point.  After CHARGED it may send POINT, to
136 activate the point and direction specified by T.  The PICs will report
137 POINTED when the point has stopped moving, and CHARGED when the CDU is
138 ready to change another point (the host may not send POINT for a point
139 on the same CDU until then).
140
141 Currently there is only one CDU so P is always 0 (but the PICs need
142 not check that the received P value is 0; they may simply assume it).
143
144
145     ----ON-----> CDU is  ------CHARGED---> CDU is charged
146                  charging              _.  and ready
147                                        /|
148                         ,----CHARGED--'       |
149                        /                      |POINT
150                       /                       |
151            Point has '                        V
152          changed; CDU
153         is recharging  <----POINTED----  Point is changing
154
155
156
157 PING and PONG
158 -------------
159
160 The host may send PING at any time; the PIC should reply with PONG
161 with the same X as was in the PING message.  The host may not send
162 another PING until the first one's PONG has come back.
163
164
165 POLARITY and POLARISED
166 ----------------------
167
168 The POLARITY command may be sent whether the track power is enabled or
169 disabled.  The polarity of each segment is `unreversed' after ON; it
170 remains constant until from then on except as modified by POLARITY.
171
172 The command is of variable length (but at least two bytes):
173
174  > 1 0010 RRR  E RRR...         POLARITY  Set polarity
175
176 Each byte after the first contains 7 more R bits.  The first R bit
177 (most significant R bit in the first byte) corresponds to track
178 reversal segment 1; The next bit (2nd most significant bit in the
179 first byte) corresponds to track reversal segment 2; and so on.
180
181 Bits which do not correspond to defined reversal segments will be
182 ignored by the PICs.  The host must send exactly as many bytes as are
183 necessary to include all of the reversal segments for each reversers
184 board (for every potential reversal segment, regardless of whether
185 that segment is a defined segment corresponding to some actual track).
186
187 For example, if there are 14 reversible segments (numbered 1 to 14)
188 then the following message
189    1 0010 000    1 000 1000    0 111 1010     Actual message
190   (E      RRR)  (E RRR RRRR)  (E RRR R---)    } helpful annotations
191                           1      111 1111     }  and commentary
192           123      456 7890      123 4567     }
193 specifies to reverse segments 7 and 11 to 14.  The trailing bits are
194 for segments 15 to 17 and are ignored.  (Note that the assignment of
195 physical segments to segment numbers is complex due to bit-twiddling.
196 see detpic/reverse.asm and layout/data2safety.)
197
198 The PIC will reply to POLARITY with POLARISED when the polarity change
199 is complete.  The host must not send another POLARITY until then.
200
201
202 NMRADATA and NMRAFULL
203 ---------------------
204
205 The data bits in all of the bytes of the NMRADATA command (including
206 the first) are simply transmitted as NMRA data to the track (most
207 significant bit first).  The top `end of packet' bit is not
208 transmitted, though.
209
210 The first 14 data bits in the NMRA packet should be 1s.  (i.e. the
211 first two complete bytes should be 11111111 11111111).  Packets
212 beginning with a different first byte are reserved for other commands
213 to the PIC and the 14 idle bits are a requirement of the NMRA
214 specification.
215
216 The maximum NMRA message length is 15 bytes each carrying 7 bits of
217 actual NMRA data (i.e. 105 bits).
218
219 Up to three NMRADATA commands may be supplied by the host to the
220 master PIC, and their will be transmitted in sequence.  After each
221 NMRADATA is completed, the PIC will send an NMRAFULL message to the
222 host.  In the NMRAFULL message, F is the number of completely-received
223 NMRADATA commands awaiting transmission to the track.
224
225 If the PIC runs out of NMRA data, it will transmit an NMRA idle
226 stream.  It is an error for the host to try to have more than three
227 outstanding NMRADATA commands.
228
229
230 DETECT
231 ------
232
233 The DETECT command indicates to the host whether there is currently a
234 train being detected at a specific location.  The PIC must send a
235 DETECT with Y=1 when a train is detected in a location where there was
236 previously none, and with Y=0 when a train ceases to be detectable for
237 more than a small amount of time.
238
239 At HELLO, the host will assume that no trains are being detected.
240
241
242 RAM (data) memory map
243 =====================
244
245 The data memory map (for PIC18F458) looks like this:
246
247  0x000-0x05f    Access bank RAM - RAM locations accessible via
248                  access bank instructions; also form part of
249                  RAM page 0
250  0x060-0x0ff    Remainder of RAM page 0, accessible only via correct
251                  BSR setting (ie, BSR==0), INDF, etc.
252
253  0x100-0x1ff    RAM page 1, accessible only via bank switching etc.
254  0x200-0x2ff    RAM page 2, accessible only via bank switching etc.
255  0x300-0x3ff    RAM page 3, accessible only via bank switching etc.
256  0x400-0x4ff    RAM page 4, accessible only via bank switching etc.
257  0x500-0x5ff    RAM page 5, accessible only via bank switching etc.
258
259  0x600-0xeff    Nothing here, don't try to access.
260
261  0xf00-0xf5f    SFR's (memory-mapped peripherals etc.) accessible
262                  only via correct BSR, INDF, etc - but these are only
263                  the CAN SFR's and we do not use the CAN controller.
264  0xf60-0xfff    SFR's accessible via access bank (also form part
265                  of RAM page 15).
266
267
268 See common.inc for actual uses of the RAM areas.
269
270
271 Program (flash etc.) memory map
272 ===============================
273
274 Program memory map (for PIC18F458) looks like this:
275
276   0x00 0000-    Program memory
277   0x00 7fff      Contains actual program instructions and can also
278                  contain preprogrammed data provided via special .asm
279                  files.  Notable contents and addresses:
280                    0x00 0000  reset vector
281                    0x00 0008  high-priority interrupt vector
282                    0x00 0018  low-priority interrupt vector
283                  See common.inc for some special tables in here, for
284                  morse messages, pin/hardware-object definitions, etc.
285
286   0x20 0000-    ID locations
287   0x20 0007      Programming which varies per PIC.  Programmed by
288                  idlocs*.asm which are made by make-idlocs and
289                  included in perpic*.hex.  Contents:
290
291                 0x20 0000
292                   bits 7-5 = 000
293                   bits 4-0 = PIC number (guaranteed to be
294                              in the range 0..31 inclusive)
295                 0x20 0001
296                   bit 7     = 1 for the main PIC (#0)
297                               0 otherwise
298                   bit 6     = 1 for Reversers board, 0 for Detectors
299                   bits 0-5  = currently unused, set to 0
300
301                 0x20 0002-  } not currently used,
302                 0x20 0007   }  may contain anything
303
304   0x30 0000-    Hardware configuration
305   0x30 000f      Defines (clock source, WDT operation, etc.)
306                  Probably best not to touch.  `config.asm' provides
307                  correct contents, which is included in *-withcfg.hex
308                  and perpic*.hex.
309
310   0x3f fffe-    Hardware device ID
311   0x3f ffff      Fixed at manufacturing time; can be read to discover
312                  hardware type and version (probably not very useful)
313
314   0xf0 0000-    EEPROM data area
315   0xf0 00ff      Not currently used by us
316
317   0x01 0000-    } These locations, not listed above,
318   0x1f ffff     }   do not correspond to anything - there
319   0x20 0008-    }   is no hardware or memory in the chip
320   0x2f ffff     }   at these locations.
321   0x30 0010-    }
322   0x3f fffd     } Accessing them isn't useful
323   0x40 0000-    }   and should probably be avoided.
324   0xef ffff     }
325
326
327 (Buffer page 50 0000h reserved for NMRA)    XXXX these look wrong
328 (Buffer page 40 0000h reserved for i2c)     XXXX   -iwj
329
330
331
332 I2C
333 ===
334 (slave addresses will be 10xxxxx where xxxxx=PIC number above)