THE TYPE A ASSIGNMENT
A type A assignment has a fixed form, as described below. It has two parts. In the first part, you are asked to complete some specific tasks, which are intended to introduce you to certain issues which are important in real-time systems. In the second part, you will probably review an assignment report from a previous year, which might ( or might not ) introduce you to an interesting topic, and give you some insight into how to write a good report of your own.
Both these parts are there for reasons which we have abstracted from years of experience with 473. ( Soon it'll be 773, but not yet. ) First, students with little or no previous experience of real-time systems commonly underestimate the difficulty of making them work, and undertake type B assignments which are much too complicated. Second, many students have been unable to choose an assignment at the beginning of the course because they've had no idea what was involved in any of the topics, and have therefore wasted many weeks in fruitless guesswork. We therefore recommend that any student who hasn't any demonstrable previous experience of working with real-time systems in one form or another should begin with a type A assignment.
This assignment has two parts, ingeniously called 1 and 2, which have equal weight in the assessment. ( Parts 1 and 2 are not to be confused with assignments 1 and 2. ) You should undertake two tasks from part 1, and one from part 2.
Avoid spending more than seven or eight hours per task on part 1, and do not be surprised if you find this time insufficient. I expect that you will be able to get a significant amount of work done in the time available, but it's fairly tight. Notice that, even if you don't complete the practical work, you should still get most of the benefit from the assignment if you've studied the machinery and know how it works.
If you run out of time, write up what you intended to do, and what you managed to do, and tell me why it took so long. The conclusion you should draw in this case is that seemingly innocent tasks can be surprisingly demanding in detail, and you should reduce your expectations of what you are likely to achieve in subsequent projects, or increase your expectations of the time it is likely to take you.
It is recommended that you devote around eight hours of the remaining time to part 2.
Carry out two of the following tasks. BBC software required is built in as ROM ( Basic, which includes the assembler ), or available on the disc labelled "473 demos". You can read some information about the BBC if you wish.
| NOTICE !!! As we have, in effect, started three weeks late this year, you are asked to carry out only ONE of the tasks below. As there will still be examination questions about the tasks, though, it will be wise to have a look at all of them. |
Write a BBC BASIC ( or 6502 assembly language ) programme to count pulses from a switch connected to a user port control line, debouncing the switch in software.
This is a simple, but realistic, problem in interrupt handling and using an interface adapter chip. ( The user port is controlled by a VIA chip. ) "Debouncing" is the operation of ignoring very rapid on-off-on transitions which commonly occur when a contact is being made or broken. The switch should be in the laboratory; look for an old clunky switch attached to a grey ribbon cable and connected/connectable to a BBC user port. ( We tried some prettier new switches, but they were too good - they didn't bounce enough. ) When switched on, it connects the user port's +5V line to the PB6 and CB2 lines.
Write a programme which performs some harmless background task, but which can be interrupted by a signal from the switch to count the transitions ( both on-off and off-on ) during the bounce and to display the number of transitions after each such event.
Use the BBC documentation and the book 6502 Assembly Language Programming ( if you can find it ). You'll have to find out how the VIA works; try the New Advanced User Guide and the 6522 data sheet. There's a demonstration programme called BOUNCE on the "473 demos" disc, but that isn't the programme you're supposed to write. It's worth making sure that you know how BOUNCE works - make sure that you undertand every line. Read the specifications carefully ! Your programme should produce output ( other than that connected with its harmless activities ) which might look something like this :
Starting...
Switch is ON (13 transitions)
Switch is OFF (17 transitions)
Switch is ON (5 transitions)
Switch is OFF (13 transitions)
.
. (7 lines omitted)
.
Switch is OFF (15 transitions)
Interrupted by character being typed.
Switch was actually switched 12 times
Questions :
It is common nowadays for machines in a production plant to communicate using serial lines, usually in some sort of ASCII. To minimise setting up procedures, it is helpful if devices can automatically determine the characteristics of the communications signal used. This experiment illustrates the problems, and possibly even some feasible methods.
Using the cable supplied, connect a serial port of a Macintosh to the serial port of a BBC. On the BBC, run the programme SERIAL ( on the "473 demos" disc ). About every 100 seconds, this programme selects a random set of communications settings; at the end of the 100 seconds, it displays the settings on the screen and chooses a new set. Also, each time it receives anything which it thinks is a character through the serial port, it returns the character followed by the string "OK" terminated with a carriage return character ( ASCII 13 ). For example, if x is received, then xOK<CR> will be transmitted by the BBC. The 100-second cycle is divided into ten 10-second intervals; if no character is received in a 10-second gap, ?OK<CR> will be transmitted.
Use the terminal emulation programme MacTerminal 2.2 on the Macintosh to send characters to the BBC, and try to determine the communications settings it is using, before the BBC announces what was in use, and changes them. ( Hint : write down the binary representation of the characters received. ) You might find it helpful to write a programme on the BBC with which you can easily set the serial port characteristics and send or receive indivdual characters; use SERIAL as a model - but if you want to patch it, take a copy to play with !
It might also be illuminating to look at the serial signals with the oscilloscope. There's a serial port plug connected to a small break-out panel, with which you can easily inspect the signals on the different conductors of the serial port. Connect the oscilloscope between the ground and transmit ( or Tx ) lines, and adjust it to give a fastish scan - 2V/division and 0.1mS/division are the right sort of numbers. Then execute a programme which sends a character repeatedly through the serial port. ( There's one called ASTREAM on the 473 disc. ) Apart from a constant voltage, nothing happens; you get some characters on the screen, but they stop. That's because the BBC isn't receiving a clear-to-send ( CTS ) signal from anywhere, though it is sending a request-to-send ( RTS ). Connect the RTS output to the CTS input, and all should be well.
You will probably see two fairly wobbly horizontal lines on the oscilloscope, one each for the mark and space voltages of the serial signal. If you set the transmit rate to 4800 baud ( look it up, or work it out from MACBBC ), you should be able to use the trigger mechanism to stabilise the trace on the oscilloscope and see what is actually transmitted. ( Set the source of the trigger to CH1, and adjust the LEVEL. ) Experiment by changing data rates and other signal characteristics, as in MACBBC - make sure that you know what's happenng and why in all cases.
A copy of the relevant Macintosh serial communications documentation is available in the 773 laboratory ( or you can check Inside Macintosh directly if you prefer ). You will note that it does not seem to support 150 and 75 baud operation. Clearly MacTerminal does support these data rates, and so the Macintosh must be capable of supporting them. You will have to invent some appropriate numbers to produce 75 and 150 baud rates, if you determine that it is necessary.
Questions :
Is it possible to determine :
the transmission speed,
If not, why not ? If so, demonstrate it in a ( C or Pascal ? ) programme on the Macintosh which automatically determines the communications settings as far as possible.
What must the remote device be able to do if your method is to work ?
We have the analogue computers to serve as a simulation of real continuous machines. There's a limit ( very close to zero ) to the amount and variety of real machinery we can sensibly provide, but as most real machinery behaves according to differential equations, an analogue computer which can simulate the elaboration of a differential equation with time is a reasonable substitute. This experiment introduces the analogue computers, and also illustrates some of the topics which turn up in control theory.
Use an analogue computer to display the solutions of second-order ordinary differential equations on the oscilloscope, and investigate how the behaviour of the solutions is determined by the parameters.
This exercise is intended to give you some idea of the behaviour of simple machines, which can often be approximated by linear ordinary differential equations. It's also good oscilloscope practice. Look for convergence, divergence, and oscillation.
Use the analogue computer manual and 773 notes on analogue computers. There should also be a reprint from a book of a passage about analogue computers somewhere. There are some WWW notes about the analogue computers and the oscilloscope.
A stepper motor is an electric motor which is so constructed that it can be made to move just one step of constant size for each input action. This makes it useful for controlling the position of mechanical devices, for one need only count the steps to know how far the motor has moved and no sensory feedback is necessary. Of course, to work this clever trick, the motor is significantly more complicated than a conventional DC motor, and correspondingly harder to drive.
This exercise is about the design of a driver for a stepper motor; that's the device which generates the sequences of signals which must be sent to the motor to make it work as required. Think of it as a box with a number of input signals ( identified below ) and four outputs which are connected to the motor. The box can be regarded as a finite-state machine which changes state as its inputs change, and which produces a specific set of outputs ( not necessarily all different ! ) in each state. Your task is to design a state diagram for the box.
( You might care to recall that a state diagram summarises how a system behaves in response to incoming events. Each state in a state diagram is a collection of statements about what can happen next - so, if the motor driver is in some specific state, its response to any event ( that is, any change in input ) should be defined. )
Produce a state diagram which specifies the four phases ( power inputs ) of a stepper motor given the following binary control parameters ( bits in a control byte ) :
Controls :
Your solution should take both these into account.
The CLK signal is used to make the stepper motor driver make the transition from one output pattern to the next output pattern. The high-low-high transition in the GO signal required to make the next single step possible is independent of the clock ( that is, the GO signal is not just sampled at the rising CLK edge, but is always active ).
Apart from the sign, there is very little difference between INH and GO ( except for the high-low-high trick, which must be done with GO ). In order for the motor to turn at all, GO must be 1 and INH must be 0. This is a safety precaution. When you turn any item of hardware on, it's likely that everything will start up in a 0 state, or everything will be in a 1 state. 50% of the time this could lead to the hardware doing something undesirable. ( For example, when you turn on a Mentor robot, sometimes all the joints move back to a zero position which could endanger it depending on how it is positioned. This is just bad, but cheap, design. ) If you have two things which must be in opposite states in order for things to function, then you vastly reduce the chances of anything untoward happening. A controller using the stepper motor driver could therefore set INH to 0 then use GO to control whether the motor turns or not, or it could set GO to 1 and use INH to control whether the motor turns or not, or it could use both simultaneously. If you prefer, you can use a compound variable called TURN ( GO and ~ INH ) ) in most of your answer.
TURN gives permission for the motor to turn, but one or other of two conditions must be satisfied before an appropriate state change can be made : either STEP must be zero, in which case continuous motion is expected, with one step or half-step at each clock signal; or single-step motion is required, and GO must have been turned to 0 and back to 1 since the previous step.
There is another safety precaution : when running in single-step mode, each active output state must be separated by a non-outputting state ( that is, with all four outputs zero ) from the next active output state, and the transition into the next active state must not take place until the first active clock edge after the GO bit has gone to 0 state and returned to 1 ( i.e. ensure only one step per asserting GO = 1 ). The reason for this is that the clock is set at a speed sufficient for the stepper motor to make a step during one clock period. If an active phase output is applied for more than one clock period, the extra energy does not go into turning the motor ( it has already turned to the position identified by that output pattern in the first clock period ) and gets transformed into heat, which is not very good for the motor.
In half-step mode, there is a cycle of eight different active output states. In full-step mode, there is a cycle of four. The cycles of output states ( which may be numbered arbitrarily ) are as follows :
| State | Half Step Mode | State | Full Step Mode | ||||||
| P4 | P3 | P2 | P1 | P4 | P3 | P2 | P1 | ||
| N+0 | 0 | 1 | 0 | 1 | N+0 | 0 | 1 | 0 | 1 |
| N+1 | 0 | 1 | 0 | 0 | |||||
| N+2 | 0 | 1 | 1 | 0 | N+1 | 0 | 1 | 1 | 0 |
| N+3 | 0 | 0 | 1 | 0 | |||||
| N+4 | 1 | 0 | 1 | 0 | N+2 | 1 | 0 | 1 | 0 |
| N+5 | 1 | 0 | 0 | 0 | |||||
| N+6 | 1 | 0 | 0 | 1 | N+3 | 1 | 0 | 0 | 1 |
| N+7 | 0 | 0 | 0 | 1 | |||||
| N+8 ( 0 ) | 0 | 1 | 0 | 1 | N+4 ( 0 ) | 0 | 1 | 0 | 1 |
| N+9 ( 1 ) | 0 | 1 | 0 | 0 | |||||
Though it is tempting in some cases, you are not allowed to invent additional circuitry to cook the inputs ( apart from the derivation of FULL from INH and GO specified in the question ). As this exercise is perhaps a little less obviously practical than some of the others, it might be worth remarking that this constraint isn't just pedantry; it's a real problem. It turned up when trying to programme a programmable logic array ( PLA ) to drive a stepper motor in response to a set of input signals according to the specifications given in the question. The PLA can be set up to work much as a finite-state automaton, and the intention was to eliminate other hard-wired circuitry as much as possible in the interests of economy, ease of construction, and reliability.
Questions :
Carry out one of the following tasks.
The review should include comment on the comprehensibility of the report, its organisation, its coherence, its layout, and any other features which you thought helped or hindered in its presentation of the subject matter. Was the aim clearly stated ? Were the results critically evaluated ? And so on. You may also comment on the organisation of the experimental work ( if any ) : was it appropriate to the problem set, are there obvious omissions, is the experiment carefully designed ? Bear in mind that what you are reviewing is an assignment report, not a user's manual ( though you might recommend that one be provided ), or a newspaper article, or a novel. It is intended to describe what someone did, in fiddly detail if necessary, and why; does it do so, does it convince you that the decisions taken were sensible, and could you follow the report to repeat the experiments ? You might find it helpful to look at the type B assignment marking sheet I use.
Take some care in choosing the report for review. Generally, pick something that looks about average in size, complexity, and any other qualities you can think of. If you choose something too big, it will take too long, and you won't be able to cover it properly; if you choose something too small, there won't be much to review, and there are likely to be obvious errors. Anything extreme is going to have extreme errors ( or, just possibly, but less probably, virtues - see below ) which most people avoid easily enough; I want you to think about the more subtle errors of form, layout, expression, and so on which are less easy to get right, but which can make a great deal of difference to the reader. Some suggestions ( and one instruction ) :
( One student, after choosing a very short report for review - before I added this note to the specification - wrote : "... at just over 3 pages of typed text, it was likely to have some serious deficiencies that could be commented on ( or a superbly concise writing style, which could be suitably praised )" ( Steve Salmond, 1997 ). He guessed right first time. )
Please hand in the report you reviewed with your review; I do read it as part of the marking !
Consider what is involved in producing an item of equipment which will serve the interests of 773 students in years to come. Take into account the costs of purchasing or producing the item, maintaining it, and generally making it useful. More important than monetary costs, estimate labour required and propose a division between staff and student labour in terms of 773 projects, project papers or thesis projects. Refer to books or research articles which demonstrate the principles of the item's operation, or outline ( in sufficient detail to establish their viability ) new methods or algorithms if required. Leave no stone unturned : present a compelling case why ( or why not ) such an item should ( or shouldn't ) be considered for the 773 Laboratory.
These assignments are not really well suited to specimen answers and marking schemes, as they're sufficiently unspecific that different people do things in different ways, and might even do quite different things which result in equally good answers. I expect that graduate students will want to probe further than the basic experiment, so a complete answer to the question as asked will get you 70% to 80%; to get more, show me that you've been thinking for yourself.
I try to stick to the spirit of these guidelines :
The spirit is all I can manage, because answers don't in fact fall into those categories. What do I do with an excellent answer showing lots of initiative with one glaring logical mistake ? - or a goodish answer, not quite adequate, except for one part done brilliantly ? Well, I try to interpolate. Think of fuzzy control systems.
Alan Creak,
March, 1998.