Datasheet
• The Rx MediaLB Device responds in the same physical channel by shifting out its status response (RxStatus)
onto the MLBS line after the Tx Device’
s Command. The RxStatus reports the status of the receiving Device to
the sender. For asynchronous, control and isochronous (non-broadcast) transmissions, the data sent is
accepted if the receiver presents a status response of ReceiverReady or rejected if the receiver presents a
status response of ReceiverBusy. For synchronous and isochronous (broadcast) transmissions, the receiving
Device must not drive any RxStatus, thereby defaulting to ReceiverReady. Synchronous (and some
isochronous) data is sent in a broadcast fashion and supports multiple receiving Devices.
Figure 48-4. 3-pin MediaLB Data Structure
Controller:
ChannelAddress
Tx Device:
Command
Rx
Device:
RxStatus
Tx
Device:
Data
Tx
Device:
Data
Tx
Device:
Data
Tx
Device:
Data
4-byte
delay
(1 quadlet = 1 physical
channel)
(1 quadlet = 1 physical channel)
Controller grants
the
Transmitting
Device
access to the
logical
channel associated
with
the
ChannelAddress
.
Transmitting Device
sends
its
Command
and
associated
Data
on
the
logical channel
associated
with the
ChannelAddress
.
Receiving Device
accepts or rejects the
Data
using the
RxStatus
field.
MLBS
MLBD
During normal operation, the MediaLB Controller initiates a transfer by sending out the ChannelAddress on the MLBS
line, and then stops driving (high-impedance) the MLBS line. When a MediaLB Device recognizes the
ChannelAddress as related to one of its channels, the Tx Device will generate the Command on the MLBS line and
place the data on the MLBD line. The Rx Device will generate the RxStatus on the MLBS line, after the Command.
Both Command and RxStatus are output in the second quadlet after the matching ChannelAddress occurred. If the
Rx Device reports a status response of ReceiverBusy
, then the Tx Device must retransmit the Command and Data in
the next physical channel assigned to that same ChannelAddress (next quadlet in the logical channel). If the Tx
Device transmits the NoData command, the Rx Device ignores the data on the MLBD line.
This results in the following scheme:
Controller: ChannelAddress → Tx Device: Command → Rx Device: RxStatus
Since for synchronous data transmission (SyncData) the status response must always be ReceiverReady (bus
default when signal not driven), synchronous data supports broadcast transmission to multiple Rx Devices.
After the Tx Device outputs Command, it must stop driving the MLBS line to allow the Rx Device to output RxStatus.
At the end of the physical channel, the Tx Device must also stop driving the MLBD line unless the ChannelAddress
for the next physical channel is also assigned to it. Likewise, after the Rx Device outputs RxStatus, it must stop
driving the MLBS line to allow the Controller to output another ChannelAddress.
Figure 48-5 illustrates which Device is driving the MediaLB signal and data lines, using the 256Fs speed as an
example. Depending on the number of physical channels that are grouped into logical channels, fewer unique
ChannelAddresses may be seen in the frame. In Figure 48-5, each logical channel is one quadlet (one physical
channel), mapping to seven ChannelAddresses (B through H). If one logical channel consisted of two quadlets and
another consisted of three quadlets, then only four unique ChannelAddresses would be seen on MediaLB (B through
E).
For MediaLB synchronization purposes, ChannelAddress 0x01FE is defined as the FRAMESYNC pattern. The
MediaLB Controller generates this pattern once per MOST Network frame on the MLBS line. The MediaLB link layer
is designed to ensure that this bit pattern is unique on the bus.
All MediaLB Devices must synchronize their byte boundary and their physical channel boundary upon receiving the
FRAMESYNC pattern. The end of the FRAMESYNC pattern also indicates that four bytes later is the start of the
MediaLB frame (PC0), and the System Channel. The actual number of physical channels supported is determined by
the MediaLB clock speed. the following table illustrates the number of available quadlets and physical channels per
frame for 3-pin MediaLB speed modes.
Table 48-7. 3-pin MediaLB Valid Physical Channels
MediaLB Speed Physical Channels
per Frame
Available Physical Channels per Frame (see Note)
256×Fs 8 7 (PC1–PC7)
SAM E70/S70/V70/V71 Family
Media Local Bus (MLB)
© 2019 Microchip T
echnology Inc.
Datasheet
DS60001527D-page 1336