Responder Packet Timing issue

[ericthegeek]

Looks like we're both online and responding at the same time. Hopefully the discussion doesn't get too jumbled and hard to follow...

Originally Posted by berntd

The responder has no chance of processing the packet due to OS lag. that is why we are responding with ACK_TIMER as already discussed in another thread here.

Makes sense, I forgot about that discussion.

Originally Posted by berntd

I am not sure how we can proceed to make this work.
I guess the original spec designers never factored in that some systems need to use interslot timeouot to determine packet length. It is really a very common way to do it and the processors even cater for it with register settings and a special interrupt.

Non-Real-Time systems like Linux were discussed when the standard was written. But supporting an environment that might take >10ms, even >100ms to handle an event would have seriously compromised the performance of the protocol. This is especially true for responders, where a single poorly behaved responder can degrade the DMX/RDM throughput for everyone on the line. Up to that point, DMX had typically required interrupt response times in the 40us range, so keeping that requirement for RDM was not a major departure.


Can your DMA engine only interrupt on timeout, or can it also terminate on a byte count? Could you set it up to DMA in the first 3 bytes of the response following the break? Then, once you have the Message Length field you know how many more bytes to expect.

Does your system support chained DMA? The shortest valid request is 26 bytes. If you setup one DMA request for 3 bytes, then chain a request for 23 bytes. That would give you over 1ms (44us * 23 bytes) to take the first interrupt, read the Message Length field, then schedule a third chained DMA if the request is longer than 26 bytes.

What about timers? Does your system have hardware timer pins? You might be able to do something creative with them to detect different line conditions and timeouts.