Latency: Time between when there is a request for service

Latency: Time between when there is a request for service
Evaluating I/O Methods –
Latency: Time between when there is a request for service (i.e. a device has a new piece of data that needs
to be read, or is ready to receive a new piece of data) and when the service is actually provided.
Software Overhead: Time spent executing instructions not directly related to I/O
Amount of hardware needed
Latency
Programmed I/O
Single Vector Interrupt
Multi-vector Interrupt
Multi-vector Interrupt
with FIFOs
DMA
Software Overhead
Needed hardware
Programmed I/O (Polling): One Device
lui
lw
loop: andi
beq
lw
lw
.
.
.
j
lw
v1,
t0,
t0,
t0,
t0,
0xbf80
0x6010(v1) // Read device A status.
$t0, 1
// Is it ready?
zero, loop // If not, poll again.
0x6010(v1)
t0, 0x6030(v1) // Else, get data (provide service)
loop
t0, 0x6010(v1) // Read device A status
Programmed I/O (Polling): Multiple Devices
lui
lw
loop: andi
bne
lw
andi
bne
.
.
.
.
lw
andi
beq
lw
v1,
t0,
t0,
t0,
t0,
t0,
t0,
0xbf80
0x6010(v1)
$t0, 1
zero, svcA
0x6210(v1)
$t0, 1
zero, svcB
//
//
//
//
//
//
Read device A status.
Is it ready?
If so, go service it.
Read device B status.
Is it ready?
If so, go service it.
t0,
t0,
t0,
t0,
0x5810(v1)
$t0, 1
zero, svcB
0x6010(v1)
//
//
//
//
Read device Z status.
Is it ready?
If not go check device A.
Read device A status.
svcZ: lw
.
.
j
lw
t0, 0x5820(v1) // Else get data from Z (provide service)
svcA: lw
.
.
j
lw
t0, 0x6030(v1) // Get data from A (provide service)
svcB: lw
.
.
j
lw
t0, 0x6230(v1) // Get data from B (provide service)
loop
t0, 0x6010(v1) // Read device A status.
loop
t0, 0x6010(v1) // Read device A status.
loop
t0, 0x6010(v1) // Read device A status.
Programmed I/O (Polling): Multiple Devices and/or doing “something else”
lui
lw
loop: andi
bne
lw
andi
bne
nop
.
.
.
.
.
j
lw
v1,
t0,
t0,
t0,
t0,
t0,
t0,
0xbf80
0x6010(v1)
$t0, 1
zero, svcA
0x6210(v1)
$t0, 1
zero, svcB
svcZ: lw
.
.
j
lw
t0, 0x5820(v1) // Else get data from Z (provide service)
svcA: lw
.
.
j
lw
t0, 0x6030(v1) // Get data from A (provide service)
svcB: lw
.
.
j
lw
t0, 0x6230(v1) // Get data from B (provide service)
//
//
//
//
//
//
Read device A status.
Is it ready?
If so, go service it.
Read device B status.
Is it ready?
If so, go service it.
// Do some non I/O related
// processing here
// Every so often,
loop
// go see if any device needs service.
t0, 0x6010(v1) // Read device A status.
loop
t0, 0x6010(v1) // Read device A status.
loop
t0, 0x6010(v1) // Read device A status.
loop
t0, 0x6010(v1) // Read device A status.
Latency
Programmed I/O
Single Vector Interrupt
Multi-vector Interrupt
Multi-vector Interrupt
with FIFOs
DMA
Possibly very low - depends on
the number of devices being
managed and the amount of
other non-I/O processing that
must be done.
Software Overhead
Highest - we poll many many
times between when a device
needs service.
Needed hardware
Low - processor and ports
Latency
Software Overhead
Needed hardware
Programmed I/O
Possibly very low - depends on
the number of devices being
managed and the amount of
other non-I/O processing that
must be done.
Highest - we poll many many
times between when a device
needs service.
Low - processor and ports
Single Vector Interrupt
Highest - need to complete
current instruction or critical
section, then EIC latency, then
ISR prolog, (possibly poll to)
find source of interrupt and
switch to appropriate handler.
Less than Programmed I/O poll only when a device needs
service. We have prolog, epilog
switch to handler and other ISR
overhead with each interrupt.
More - additionally need an
interrupt controller
Multi-vector Interrupt
Multi-vector Interrupt
with FIFOs
DMA
Latency
Software Overhead
Needed hardware
Programmed I/O
Possibly very low - depends on
the number of devices being
managed and the amount of
other non-I/O processing that
must be done.
Highest - we poll many many
times between when a device
needs service.
Low - processor and ports
Single Vector Interrupt
Highest - need to complete
current instruction or critical
section, then EIC latency, then
ISR prolog, (possibly poll to)
find source of interrupt and
switch to appropriate handler.
Less than Programmed I/O poll only when a device needs
service. We have prolog, epilog
switch to handler and other ISR
overhead with each interrupt.
More - additionally need an
interrupt controller
A bit less than Single Vector no need to poll or switch to
appropriate handler.
Less than Single Vector Int - No
need to poll or switch to
appropriate handler.
More - need a vector based
interrupt controller
Multi-vector Interrupt
Multi-vector Interrupt
with FIFOs
DMA
Latency
Software Overhead
Needed hardware
Programmed I/O
Possibly very low - depends on
the number of devices being
managed and the amount of
other non-I/O processing that
must be done.
Highest - we poll many many
times between when a device
needs service.
Low - processor and ports
Single Vector Interrupt
Highest - need to complete
current instruction or critical
section, then EIC latency, then
ISR prolog, (possibly poll to)
find source of interrupt and
switch to appropriate handler.
Less than Programmed I/O poll only when a device needs
service. We have prolog, epilog
switch to handler and other ISR
overhead with each interrupt.
More - additionally need an
interrupt controller
Multi-vector Interrupt
A bit less than Single Vector no need to poll or switch to
appropriate handler.
Less than Single Vector Int - No
need to poll or switch to
appropriate handler.
More - need a vector based
interrupt controller
Multi-vector Interrupt
with FIFOs
Same as Multi-vector.
Less than Multi-vector interrupt overhead incurred only
once per k items in the FIFO.
More - need I/O device with a
FIFO.
DMA
Latency
Software Overhead
Needed hardware
Programmed I/O
Possibly very low - depends on
the number of devices being
managed and the amount of
other non-I/O processing that
must be done.
Highest - we poll many many
times between when a device
needs service.
Low - processor and ports
Single Vector Interrupt
Highest - need to complete
current instruction or critical
section, then EIC latency, then
ISR prolog, (possibly poll to)
find source of interrupt and
switch to appropriate handler.
Less than Programmed I/O poll only when a device needs
service. We have prolog, epilog
switch to handler and other ISR
overhead with each interrupt.
More - additionally need an
interrupt controller
Multi-vector Interrupt
A bit less than Single Vector no need to poll or switch to
appropriate handler.
Less than Single Vector Int - No
need to poll or switch to
appropriate handler.
More - need a vector based
interrupt controller
Multi-vector Interrupt
with FIFOs
Same as Multi-vector.
Less than Multi-vector interrupt overhead incurred only
once per k items in the FIFO.
More - need I/O device with a
FIFO.
Lowest - need to wait for arbiter
to give access to the bus and
then do the transfer.
Likely less than using FIFO interrupt overhead incurred only
once per n items in a block and
n can be > k.
More - additionally need a DMA
controller
DMA
9-bit mode and Multi-drop Asynchronous Serial Communication
Tx Rx
Master
Tx Rx
Slave
Tx Rx
Slave
...
Tx Rx
Slave
9-bit communication is covered in section 21.7 of the reference manual
In 9-bit communication:
Ÿ when the master transmits with the 9th bit set, the lower 8 bits represent an address.
Ÿ all slaves compare this address against their own address
Ÿ subsequent data transmissions with the 9th bit clear are processed only by the addressed slave. Other slaves
ignore these transmissions.
Ÿ only addressed slaves can transmit.
The PIC32MX provides some additional support for 9-bit mode -The UxSTA.ADDEN bit, when set will cause a 9-bit Slave not to interrupt or buffer data for receptions where the
9th bit is 0. To use this, the addressed slave would clear its ADDEN bit while the other slaves would set theirs.
Ÿ Note that a transmission with the 9th bit set always causes an interrupt.
Ÿ Also, this interrupt occurs regardless of the current receive buffer level (i.e. independent of RXISEL ).
Automatic Address Detect:
When UxSTA.ADM_EN is set (we may also need ADDEN set), a reception with the 9th bit set is compared against
the UxSTA.ADDR field.
If the address char matches UxSTA.ADDR:
Ÿ the received address char is discarded
Ÿ subsequent data chars are saved in the buffer (ADDEN may be cleared)
Ÿ interrupts are generated according to RXISEL
If the address char doesn’t match UxSTA.ADDR:
Ÿ subsequent data chars are ignored (ADDEN may be set)
Figure 21-11:
Automatic Baud Rate Calculation
After ABAUD set, fBRG set to fPB / (8 x 16) so tBRG = tPB x 8 x 16
BRG Counter
XXXXh
0000h
UxRX
001Ch
Edge #1
bit 0 bit 1
Start
Edge #2
bit 2 bit 3
Edge #3
bit 4 bit 5
Edge #4
bit 6 bit 7
Edge #5
Stop bit
0x55 = “U”
BRG Clock
resets count
Set by User
ABAUD bit
Auto-Cleared
n x tPB x 8 x 16
UxRXIF
count n moved to BRG
XXXXh
BRG Register
001Ch
n x tPB x 8 x 16
8
= n x tPB x 16
Average bit time =
1
so the actual Baud = n x tPB x 16
=
fPB
n x 16
fPB
With n in BRG,the generated Baud = (n + 1) x 16
The actual Baud must be within range of BRG and fPB
The Transmitter cannot be used during Autobaud
DS61107D-page 21-38
© 2008 Microchip Technology Inc.
Figure 21-22: Auto-Wake-up Bit (WAKE) Timings During Normal Operation
OSC1
WAKE Bit (1)
Bit Set by User
Auto-Cleared
break
UxRX
UxRXIF
if WAKE, RXIF comes at start
Note 1: UART state machine is held in IDLE while WAKE bit is active.
Figure 21-23: Auto-Wake-up Bit (WAKE) Timings During SLEEP
OSC1
WAKE bit (2)
UxRX
Bit Set by User
Auto-Cleared
(1)
UxRXIF
SLEEP
Note 1: If the wake-up event requires long oscillator warm-up time, the auto-clear of the WAKE bit can occur while the
system clocks are still active. This sequence should not depend on the presence of Q clocks.
2: UART state machine is held in IDLE while WAKE bit is active.
Note:
The Sync Break (or Wake-up Signal) character must be of sufficient length to allow time for the selected oscillator to start and provide proper initialization of the UART. To ensure that the part woke up in time, the user
should read the value of the WAKE bit. If it is clear, it is possible that the UART was not ready in time to receive
the next character and the module might need to be resynchronized to the bus.
DS61107D-page 21-49
© 2008 Microchip Technology Inc.
Note:
If the WAKE bit is set with the ABAUD bit, auto-baud rate detection occurs on the byte following the Break
character. The user must ensure that the incoming character baud rate is within the range of the selected
UxBRG clock source, considering the baud rate possible with the given clock.
i.e. WAKE has priority over ABAUD
Figure 21-12: Break Detect Followed by Auto-Baud Sequence
Q1
break
UxRX
Start
Set by User
bit 0
bit 7
Stop
Auto-Cleared
WAKE bit
Auto-Cleared
Set by User
ABAUD bit
Synchronization
Synchronization
UxRXIF
UART Mode IDLE
DS61107D-page 21-39
Break Detect
Auto-Baud Rate Detect
IDLE
© 2008 Microchip Technology Inc.
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising