.equ DUART_BASE, 0x7FFC00 /* assumed base address */
.equ CRA, 0x04 /* Command Register A */
.equ ACR, 0x08 /* Auxiliary Control Register */
.equ IMR, 0x0A /* Interrupt Mask Register */
.equ CTUR, 0x0C /* Counter/timer Upper Register */
.equ CTLR, 0x0E /* Counter/timer Lower Register */
.equ CRB, 0x14 /* Command Register B */
.equ IVR, 0x18 /* Interrupt Vector Register */
.equ OPCR, 0x1A /* Output Port Configuration Register */
.equ CTSTART, 0x1C /* Counter/timer start command */
.equ CTSTOP, 0x1E /* Counter/timer stop command */
DUART_TIMER_INIT:
MOVEM.L A0-A1,-(SP) /* save CPU regs */
LEA.L DUART_BASE,A0
MOVE.B #0x0A,CRA(A0) /* Disable A-side Tx and Rx */
MOVE.B #0x0A,CRB(A0) /* Disable B-side Tx and Rx */
MOVE.B #0x60,ACR(A0) /* timer mode and 3.6864 MHz clock */
MOVE.B #0x0000,CTUR(A0) /* 18432 cycles = 0x4800 cycles */
MOVE.B #0x4800,CTLR(A0) /* = 5 ms half period */
TST.B CTSTART(A0) /* restart the timer */
MOVE.B #0x04,OPCR(A0) /* connect timer output to OP3 pin */
MOVE.B #INT_VEC_NUM,IVR(A0) /* load the vector number */
MOVE.L #INT_VEC_NUM,A1
LSL.L #2,A1 /* form the vector address */
MOVE.L #DUART_TIMER_ISR,(A1) /* load the IRQ vector */
MOVE.B #0x08,IMR(A0) /* enable only timer/counter IRQs */
MOVEM.L (SP)+,A0-A1 /* restore CPU regs */
RTS
DUART_TIMER_ISR:
MOVEM.L A0-A6/D0-D7,-(SP) /* save CPU regs */
LEA.L DUART_BASE,A0
TST.B CTSTOP(A0) /* clear the timer interrupt */
/* this is timer mode, so the timer will not be stopped */
/* do here what has to be done at each timer interrupt */
MOVEM.L (SP)+,A0-A6/D0-D7 /* restore CPU regs */
RTE
The loss of a packet is detected at the transmitter when the time-out limit for receiving an acknowledgment for that packet is exceeded. Each packet does not necessarily have a separate acknowledgment. It is possible for a group of received packets to be acknowledged together. Either way, a lost packet will cause an acknowledgement message not be sent from the receiver back to the transmitter. The transmitter can then decide to resend the lost message to recover from the failure.The receiver keeps track of the sequence numbers of the arriving packets. Thus it can determine from the sequence numbers if ever a packet is received too early or too late with respect to the other received packets. If such an out-of-order packet is received, then the receiver can do one of two things: It could just discard the packet and then wait for a fresh retransmitted packet, or it could attempt to reorder the arriving sequence of packets. The second strategy is probably most appropriate since the IP layer does not guarantee the arrival order of packets and because the TCP checksum can still be used to determine if the data contents of the packet can be trusted.
Duplicate packets can be detected because they will have the same sequence number. The receiver could decide to discard the two packets, and then wait for a freshly retransmitted packet. Or it could compare two duplicate packets and then verify whether or not they contain exactly the same header and data bytes. If there is a disagreement, then one packet could be selected randomly and the other discarded, or both packets could be discarded.
With little detail provided about the motor's construction, there are several reasonable possible answers to this question. In the full-step sequences, the total amount of winding current drawn by the motor should be constant. For the half-step sequences, smaller half-size rotational steps are obtained by allowing the total winding current to vary from position to position over twice the number of different steps.
One possible full-step sequence (one winding one at a time):
Step Winding A Winding B Winding C Full-bridge inputs
#1 forward off off 100000
#2 off forward off 001000
#3 off off forward 000010
#4 reverse off off 010000
#5 off reverse off 000100
#6 off off reverse 000001
#1 forward off off 100000
Another possible full-step sequence (two windings on at a time):
Step Winding A Winding B Winding C Full-bridge inputs
#1 forward forward off 101000
#2 off forward forward 001010
#3 reverse off forward 010010
#4 reverse reverse off 010100
#5 off reverse reverse 000101
#6 forward off reverse 100001
#1 forward forward off 101000
One possible half-step sequence:
Step Winding A Winding B Winding C Full-bridge inputs
#1 forward off off 100000
#2 forward forward off 101000
#3 off forward off 001000
#4 off forward forward 001010
#5 off off forward 000010
#7 reverse off forward 010010
#8 reverse off off 010000
#8 reverse reverse off 010100
#9 off reverse off 000100
#0 off reverse reverse 000101
#11 off off reverse 000001
#12 forward off reverse 100001
#1 forward off off 100000
In a full-step sequence, the stable positions of the rotor are either aligned with the stator teeth (with either one winding energized at a time), or are aligned with the gaps between adjacent stator teeth (with two windings energized at a time). In a half-step sequence, the stable positions of the rotor include *both* the centres of the stator teeth (one winding energized) and the gaps between stator teeth (with two windings energized). The half-step sequence causes greater variations in the total stator winding current as the rotor turns through all positions, and this might be a small disadvantage compared to the full-step sequence. The control sequence for half-step sequence is twice as long as the full-step sequence, but this might not be a factor. It would not be factor in the case of the Motorola TPU since the pin memory buffer allows room for both the full and half-step control sequences.
The TCR1 clock is derived from the main system clock (e.g. 16777216 Hz) by using one of five divide factors. The divide factors are specified by bits in the TPU Module Configuration Registers as follows: PSCK TCR1P Divide TCR1 clock assuming bit 6 bits 14,13 Factor 16777216 Hz system clock 0 0 0 32 524288 Hz 0 0 1 64 262144 Hz 0 1 0 128 131072 Hz 0 1 1 256 65536 Hz 1 0 0 4 4194304 Hz 1 0 1 8 2097152 Hz 1 1 0 16 1048576 Hz 1 1 1 32 524288 Hz We will assume the TPU module that is included in the 68332 (not the alternative TPU2 module that is included in some other Motorola microcontrollers). The TCR2 clock is formed from a base clock signal that is prescaled (divided down) by one of four possible factors. The T2CG bit (bit #9) in the TPU Module Configuration Register determines the base clock. If T2CG = 0, then the base clock is supplied by an external clock source that is connected to the T2CLK pin. This clock must be no faster than nine times slower than the main system clock. If T2CG = 1, then the base clock is the system clock divided by 8 and "gated" by the signal that is applied to the T2CLK pin. Thus when the T2CLK signal is low, the base clock for TCR2 is stopped; when the T2CLK signal is high, the system clock divided by 8 is the base clock for TCR2. The actual TCR2 clock is obtained by dividing down the base clock by one of four possible factors, as selected by the TCR2P bits (bits 12 and 11) in the TPU Module Configuration Register. T2CG TCR2P Divide TCR2 clock assuming bit 9 bits 12,11 Factor 16777216 Hz system clock 0 0 0 1 Clock at T2CLK pin 0 0 1 2 (Clock at T2CLK pin)/2 0 1 0 4 (Clock at T2CLK pin)/4 0 1 1 8 (Clock at T2CLK pin)/8 1 0 0 1 2097152 Hz gated by T2CG 1 0 1 2 (2097152 Hz gated by T2CG)/2 1 1 0 4 (2097152 Hz gated by T2CG)/4 1 1 1 8 (2097152 Hz gated by T2CG)/8
The priority scheme in MicroC/OS-II is very simple. Each task has a unique priority, from 0 (highest priority) to 63 (lowest priority). The lowest priority, 63, is assigned to the idle task, which is always ready-to-run. The basic rule is that the highest-priority ready-to-run task is always the task that is allowed to execute on the CPU. The scheduler in the TPU also uses a priority scheme to determine which among several pending channel service requests should be attended to next. The channels are each assigned one of four priorities: high, medium, low, and disabled. The scheduler divides its available time into a seven-slot cycle. In four of those time slots, any pending high priority service requests are attended to first (followed by the medium and low priority requests, if no high priority service requests are pending). In two of those slots, any pending medium priority service requests are attended to first (followed by any pending high and low priority requests). In one slot, any pending low priority service requests are handled first (followed by any pending high and medium priority requests). In the TPU there is nothing equivalent to the idle task in MicroC/OS-II. If there are no pending service requests, then the scheduler just remains in the same time slot and does nothing. Within each priority level, pending TPU channel service requests are handled in order of their channel number (the lowest channel number is handled first). All pending requests at the same priority level must be serviced before any channel can be serviced again at that level.