From 8ef6a2fb30adeedc972b685cb56c4d9897872b9e Mon Sep 17 00:00:00 2001 From: ian Date: Sun, 16 Jan 2005 01:50:17 +0000 Subject: [PATCH] documented the current plans --- cebpic/README.circuitry | 171 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 171 insertions(+) diff --git a/cebpic/README.circuitry b/cebpic/README.circuitry index 7a58958..f123060 100644 --- a/cebpic/README.circuitry +++ b/cebpic/README.circuitry @@ -10,6 +10,7 @@ serial port and other currently-implemented one-off peripherals. It is wired according to REVERSERS, left-hand entry for variant pins. + BOOSTER ======= @@ -105,3 +106,173 @@ has not yet been rectified by the user. When a fault is present, the PIC should occasionally attempt to reapply track power, so that it can indicate to the user when the fault has been fixed. + + + +SERIAL PORT +=========== + +The RS232 serial connection to the host arrives at PIC 0, on the pins +indicated. + + + +PER-PIC LED +=========== + +One pin of each PIC (the corresponding pin on each) drives the per-PIC +LEDs, of which there are two per PIC: + + Output pin Orange LED Blue LED + H off ON + Z off off + L ON off + + +TRACK LAYOUT OBJECTS +==================== + +The physical relationship between track objects (detection segments, +reversal segments, point motors, etc.) is not known to the PICs. The +host protocol should name these objects by number in some +representation convenient for the PICs. + +However, each PIC must be aware of which pin is connected to which +kind of peripheral and must prevent the host from accessing one kind +of peripheral as if it were another. Otherwise the host could send +instructions which would cause the PIC to try to treat an output as an +input, or do other things which might damage the PIC or circuitry. + +Therefore, each PIC must have configuration information (either stored +in the PIC's ID locations along with its address, identity, etc., or +compiled into the PICs' common firmware and indexed by its identity) +which lets it know what peripherals are connected. + +README.protocol should specify how this information is to be provided +by the build system to the PICs (eg, in a file on the host during the +build? programmed into the PIC's ID locations?, and what the format +should be. + +The first classification of PICs is into those on DETECTORS boards and +those on REVERSERS boards. In the final plan there are 3 REVERSERS +(including the master board with PIC 0) and 5 DETECTORS. + + + +POINTS AND CDU +============== + +Each point has two point motors, each controlled by one PIC pin. +These two motors are treated as two separate objects by the PICs. +Power for operating the point motors is supplied by the single CDU. + +While the CDU is enabled and no point motor is activated, the CDU +charges up until it has enough energy to switch one point. This takes +approximately 500ms. (The PIC program should be written so that this +period can be adjusted fairly easily from around 200ms to 1000ms in +relatively coarse steps.) + +When the CDU is charged, a point may be switched by activating the +relevant output. The point motor output should be active for at least +100ms. After the point has moved, the relevant point motor output +should be disabled again so that the CDU may recharge. + +The PICs should not attempt to activate more than point motor at once, +nor to activate a point motor when there may be insufficient energy, +since doing so leaves the point in an unknown state. The PICs should +not assume that the CDU remains charged if it is disabled. + +There is no need to disable the CDU while switching a set of points. +While the CDU is disabled, it gradually discharges. + + Point N pin Effect + H Activated - point changes if CDU charged + L Not activated + Z Results not defined, do not use + + CDU Enable pin Effect + H CDU is enabled (and charges up) + Z CDU is disabled (and discharges) + L CDU is disabled (and discharges) + +Suggested behaviour: the CDU could be enabled whenever track power is +provided. The host will need control over the timing of point +changes, so while the PICs should prevent the host from activating a +point when the CDU is not ready, they should not delay the point +change for this reason - instead, they should reject it. The host +will also need to know when the point has been changed, and would +probably also like to know when it can ask to change another. + + +BLOCK SENSE +=========== + +Each track section is equipped with a circuit for sensing the presence +of current-drawing rolling stock. This circuit is only effective +during one of the two track polarities (see Booster, above) - while +the track current is the other way, the block sensor does not detect a +train. + +Furthermore, due to intermittent poor contact, a train may `disappear' +briefly - usually for a few ms, but exceptionally for a few tens of +ms. This means that reporting every change in the set of detectable +trains to the host would exceed the capacity of the serial link. + +The requirements are: + + * The host must be informed quickly if a train is spotted where the + host has been told that there is no train. 10ms would be good; + 100ms would be very marginal. + + * The host should be informed reasonably quickly if a train ceases + to be perceptible. 100ms would be fine for this, although sooner + would be better. + + * The currently envisaged PCBs can support up to 123 detection + segments. + +The SENSE pins should always be configured as inputs (Z state); +otherwise damage to the detection circuitry may occur. When a train +is detected, the input will be L; otherwise it will be H. + + +TRACK POLARITY +============== + +Some track sections have reversible polarity. The host needs to have +timely control over the polarity of these sections, and needs to be +able to switch several of them simultaneously (to avoid short +circuits). + +The polarity states are + + Reverse pin Effect + H segment polarity reversed + L segment polarity not reversed + Z undefined, do not apply track power + +Changing takes 1-10ms. + +*** PROVISIONAL: *** +It may prove necessary to temporarily disable track power during +certain polarity changes. + + + +FUTURE DIRECTIONS +================= + +In the future some PICs may be also asked to control the following: + + * Turntable: outputs to select stop, clockwise or anticlockwise; + inputs: probably some binary optoreflective inputs which may + need some decoding to establish the turntable's orientation + + * Uncoupler (probably a simple binary choice) + + * Tipper wagon actuator (probably a simple binary choice) + + * Signals (this may involve many more PICs) + + * Scenery lighting or displays - either one global item, or perhaps + many outputs -- 2.30.2