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