Hi,

Tx is not usually so critical, <i>as you're in control<i/>

Humm, was thinking about the situation where a processor is in control of sending the bits, but not of when it may send the bits.

Example: A master processor with multiple slaves, the master tries to ensure each slave has a chance to communicate information/events by sending a "conch/token" to each slave in turn [using mode 2 comms on an 8052 derivative quite possibly]. The conch/token indicates which slave may transmit. The slave has to send the conch/token back, either as a 'Nothing to report' message or as part of a 'Here is some data' message. A slave may not send until it recieves the conch/token; so while a slave is controlling the transmission of the bits of the messages, it is not controlling when it may send the message, possibly causing the need to buffer messages. Of course a slave may indicate that it has more messages to send as a 'Oh, and there is more to come' clause of a 'Here is some data' message and the master may then favour the slave by sending the conch/token to it more frequently.

If the 8052 derivative is the master then it controls Tx/Rx, otherwise it may not necessarily send messages whenever it has them to send, which means it depends on the application :)

Also, a single event may cause several messages in quick succession, and if the first is long, and the second and subsequent are short it is possible to generate more messages than can be sent. That's real time systems for you :(

As an aside, in the original question point (2) suggests <I>"But work overhead is high"</i>. Do not understand the use of 'high'. More code is written (an interrupt routine) but why this is considered to be 'high' overhead, for the developer or the processor ?

Oh, apologies this got so long.

Luccus