READ / WRITE TIMERS & PIN TPU FUNCTION (RWTPIN) =============================================== DESCRIPTION ------------ The RWTPIN TPU function enables the CPU to read both the TCR1 and TCR2 timer counters via locations in PRAM and alternatively, to selectively load TCR1 or 2 with a CPU supplied value contained in PRAM. The function also optionally allows the user to control the pin state and direction of the RWTPIN channel. A pinstate parameter is maintained in PRAM and is updated on every service request to contain one of two values representing the current pinstate regardless of whether the pin is programmed as an input or output ($8000 = pin high, $0000 = pin low). The function also receives links, and on receipt of a link will read the two TCRs into PRAM and update the pinstate parameter. After all operations, a (maskable) interrupt request to the CPU is generated. Effectively, this function allows the CPU to control the channel pin, the channel pin and the TCRs or just the TCRs. To control the pin only, the the 'read TCR' option is used and the values returned ignored. Being able to control the TCRs without effect on the pin allows this function to be run on a TPU channel whose pin is being controlled by a different function running on another channel such e.g. in the case of a slave stepper motor channel. FUNCTION CODE SIZE ------------------ The code size of a TPU function is important when assessing which combination of functions can fit into a given microcode space in ROM or emulation RAM. The code size of the RWTPIN function is:- 10 æinstructions + 8 entries = 18 long words total. CONTROL BITS ------------ HSR1 HSR0 Action ---- ---- ------ 0 0 No action. 0 1 Read TCRs & read/write pin 1 0 Write TCR1, read TCRs & read/write pin 1 1 Write TCR2, read TCRs & read/write pin HSQ1 HSQ0 Action ---- ---- ------ X X Not used. Links Accepted: YES Links Generated: NO Interrupts Generated After: All States. PARAMETERS ----------- The following sections describe the parameters used in the RWTPIN function, the location and size of each parameter being given after the name. CHAN_CONTROL Parameter 2, bits 0..8 This CPU written parameter is used to setup the direction and level of the RWTPIN channel pin. It uses the standard channel control format used by other TPU functions and shown in table 2-3 of the TPU ref. manual. Note that since there are no match or transition operations in this function then the selection of the timebase via TBS and pin action via PAC are irrelevant. The important fields are the channel direction control via TBS and the pin state control via PSC. It is possible to use the RWTPIN function and not control the channel pin, this is accomplished by setting the CHAN_CONTROL parameter to %111111111. CHAN_PINSTATE Parameter 3, bits 0..15 This TPU written parameter is used to maintain a value representing the current pin level. When the RWTPIN channel is serviced, the TPU reads the pinstate and stores $8000 in CHAN_PINSTATE if the the pin was high and $0000 if the pin was low. This operation occurs regardless of whether the channel is programmed as an input or output. TCR1_VAL Parameter 4, bits 0..15 This parameter serves two purposes and can be written by either the CPU, TPU or both as follows. When a load of TCR1 is desired then TCR1_VAL contains the CPU written value that will be loaded into TCR1 when the host service request is executed. As part of this service, TCR1 is also read by the TPU and the value written back into TCR1_VAL. When a 'TCR read' host service request or link service request is serviced, then TCR1_VAL is written by the TPU with the latest value of TCR1. TCR2_VAL Parameter 5, bits 0..15 This parameter serves two purposes and can be written by either the CPU, TPU or both as follows. When a load of TCR2 is desired then TCR2_VAL contains the CPU written value that will be loaded into TCR2 when the host service request is executed. As part of this service, TCR2 is also read by the TPU and the value written back into TCR2_VAL. When a 'TCR read' host service request or link service request is serviced, then TCR2_VAL is written by the TPU with the latest value of TCR2. HOST INITIALISATION ------------------- The CPU initialises the RWTPIN function by the following means:- 1) Disabling the channel by clearing the two channel priority bits. 2) Selecting the RWTPIN function on the channel by writing the RWTPIN function number to the function select bits. 3) Writing CHAN_CONTROL in the channel parameter RAM. 4) Writing TCR1_VAL or TCR2_VAL if a TCR write is to be made. 5) Issuing a HSR %01 to setup the pin and read the two TCRs, or, issuing a HSR %1X to write one of the two TCRS, setup the pin and then read both TCRs . 6) Enabling service by assigning H,M or L priority to the channel via the two channel priority bits. The TPU then executes the selected host state and asserts an interrupt request when finished. NOTES ON USE AND PERFORMANCE OF RWTPIN FUNCTION ------------------------------------------------ PERFORMANCE: Like all TPU functions, the performance limit of the RWTPIN function in a given application is largely dependent on the activity on other TPU channels. This is due to the operational nature of the scheduler. Where a single RWTPIN channel is being used and no other TPU channels are active, the minimum time between host service requests is 24 CPU clock cycles for reading the TCRs and 28 CPU clock cycles for writing a TCR. When more TPU channels are active, this performance will generally be degraded. However, the scheduler assures that the worst case latences in any TPU application can be calculated, so it is recommended that the guidelines given in the TPU reference manual are used to perform an analysis on any proposed TPU application that appears to approach the performance limits of the TPU. INTERRUPT TIMING: For maximum TPU code efficiency, the interrupt request from the TPU to the CPU is not asserted exactly at the end of the state. This means that there is a delay of 8 CPU clocks from the assertion of the interrupt request to the new pinstate data being valid. RETURNED VALUE WHEN WRITING A TCR: As part of the service of a TCR write, the TPU also reads both TCRs and returns their values in the TCR1_VAL and TCR2_VAL parameters. The execution time of the TPU code means that there is a delay between the TCR write and read of 4 or 8 CPU clocks (TCR1 or 2) which may result in a difference between the initial CPU written and TPU returned TCRx_VAL depending on the prescaler setting for TCRx. USING RWTPIN FOR PIN CONTROL ONLY: This is achieved by using the host service request to read the TCRs (%01). Since reading the TCRs does not affect them in any way, the pin can be controlled via CHAN_CONTROL and the results in TCR1_VAL and TCR2_VAL ignored. USING RWTPIN FOR TCR CONTROL ONLY: The user may wish to read or write the TCRs without affecting the channel pin (which may then be controlled by another channel if required), this is achieved by issuing the appropriate HSR for the TCR action required, but with CHAN_CONTROL = %111111111. WRITING ONE TCR AND READING THE OTHER: This operation is automatic:- when one TCR is written then both it and the other are read back into TCR1_VAL and TCR2_VAL. WRITING BOTH TCRs: This is a two stage operation. The user should load the desired value for one of the TCRs into PRAM and issue the appropriate HSR to write it. When the first service is complete then the second TCR value can be written into PRAM and the other 'write' HSR issued. Note the order here, if the two values were written before issuing the first HSR then the second value would be overwritten by the read of the TCRs performed as part of the first service. LINKS: Since the link request flag is negated in all states, then a link that is received just before or possibly during the execution of a host service request may be negated without being serviced. In practice, this will not be a problem as all the other states are supersets of the link state. It should be remembered that the link state (RWTPIN_LNK) also configures the channel via CHAN_CONTROL, this has two implications: i) If a regular link from another channel is being used to read the TCRs, then the pin can be controlled without using host service requests. The new pin configuration can simply be written into the CHAN_CONTROL parameter and the pin will be automatically updated on the next link service. ii) If a regular link from another channel is being used to read the TCRs and precise CPU control is required on the timing of a pin state change, then it may be necessary to temporarily disable the RWTPIN channel (or suspend links) to avoid the new pin state being inadvertently set by the link state before the CPU issues the appropriate HSR.