Re: MIDI conjunction device

On Thu, 16 Mar 2006 23:29:27 -0800, "Michael R. Kesti"
<mrkesti@xxxxxxxxxx> wrote:

Paul Keinanen wrote:

On Wed, 15 Mar 2006 23:17:07 -0800, "Michael R. Kesti"
<mrkesti@xxxxxxxxxx> wrote:

I had, earlier in this thread, said that a merger will, by its nature,
introduce a delay of the message duration plus the time it takes to
process the message. This is true only when non-overlapping messages
are being received.

I would agree on a one byte delay with UARTs, assuming the processing
delay is insignificant, with bit banging it would be even less. When
the serial stream enters the input UART shift register, typically an
interrupt is generated when the _last_ bit has been entered into the
shift register. The interrupt service moves the byte to the output
UART, which immediately starts to send the _first_ bit from the Tx
shift register. Thus, the message is delayed by a _single_ shift
register length (and additional time for the interrupt service
routine, which was assumed insignificant).

With bit banging, the delay would be only one bit time.

The delays must be related to message time rather than character time
because we must receive, queue, and deque complete messages rather than
those messges' individual characters.

Ignoring bit-banged receivers and transmitter, you are suggesting this
timing.

IN0-|stat0|dat0A|dat0B|----------------------------------------------
IN1------------------------------------------------------------------
OUT--------|stat0|dat0A|dat0B|---------------------------------------

Consider, though, what happens when overlapping messages are received
at the inputs.

IN0-|stat0|dat0A|dat0B|----------------------------------------------
IN1----|stat1|dat1A|dat1B|-------------------------------------------

If we queue each character for transmission as thery are received, then
the output timing would lokk like this.

OUT--------|stat0|stat1|dat0A|dat1A|dat0B|dat1B|---------------------

Look at my text you quoted a few lines later:

When an other message arrives, when the
previous is being processed, it must be _stored_, until the previous
_message_ has been received and forwarded adding an extra delay, which
depends on the size of the message.

Originally a flag variable InputSelected=NONE. When stat0 Rx interrupt
is processed, the byte is written to OUT UART and setting
InputSelected=IN0. When there is an interrupt IN1, it notices, that
InputSelected is not NONE and stat1 is put into a queue. When dat0A is
received, InputSelected is still IN0 and dat0A is written to OUT.
dat1A goes to queue.

When dat0B is received, it goes to OUT and sets InputSelected to NONE
(if no queued messages exists) or in this case to InputSelected=QUEUE,
which will send out the queued bytes each time the TxEmpty interrupt
from the OUT UART are activated. After the queue is empty
InputSelected=NONE.

Thus the sequence would be

IN0-|stat0|dat0A|dat0B|----------------------------------------------
IN1----|stat1|dat1A|dat1B|-------------------------------------------
OUT-------|stat0|dat0A|dat0B|stat1|dat1A|dat1B|------------

Thus, the delay for the first (or non-overlapped) message is 1 byte
time and no garbling occurs.

This should be easily handled completely in interrupt state without
any polling or timer interrupts by using IN0 and IN1 RxFull interrupt
and OUT TxEmpty interrupts.

To allow more channels and multiple queued messages, each input
channel would need a buffer capable of holding a full input message
and the OUT channel a queue of arbitrary length (even kilobytes). If
the OUT UART is free, the received bytes are immediately sent. If the
UART is in use by some other input channel, the local buffers for all
other channels are transferred to the global queue when datxB Rx
interrupt is processed. When the first message has been completely
transmitted, the global output queue is drained using TxEmpty
interrupts.

This structure has the disadvantage that if only dat0B and stat1
overlap, the transfer from IN1 local buffer to global buffer would be
delayed until dat1B is received. Thus, when OUT datxB TxEmpty
interrupt is received and the global OUT queue is empty, a check needs
to be made for all input channel to find the input channel with most
bytes in the local input buffer and select it for transmission and
empty this buffer using TxEmpty interupts.

Paul

.

Relevant Pages

  • Re: MIDI conjunction device
    ... I would agree on a one byte delay with UARTs, ... Ignoring bit-banged receivers and transmitter, ... If we queue each character for transmission as thery are received, ...
    (comp.arch.embedded)
  • Re: MIDI conjunction device
    ... InputSelected is not NONE and stat1 is put into a queue. ... which will send out the queued bytes each time the TxEmpty interrupt ... and the OUT channel a queue of arbitrary length. ... messages to be sent without their status characters (ie, ...
    (comp.arch.embedded)
  • Re: Performance Intel Pro 1000 MT (PWLA8490MT)
    ... driver changed to not use the braindamaged sk interrupt moderation. ... with small 50-60 byte UDP packets. ... when the tx queue fills up, the application should stop sending, at ... For transmission, with non-broken hardware and software, ...
    (freebsd-performance)
  • Q: wait queue weirdness in A/D device driver - 2.4.18 or 20, RH 8.0
    ... "master buffer" at interrupt time and wake up any ... it should be because the int handler has now placed data into the master ... I'm using gcc 2.95.3 for both kernel and module (due to a suggestion on ... into the queue. ...
    (comp.os.linux.development.system)
  • Re: writing ISR for UART
    ... int putpoint; ... so if the interrupt handler adds a character to the queue while ... detect whether a character is available. ...
    (comp.arch.embedded)