Responder Packet Timing issue

[berntd]

Hi again

I have just concluded the following:

The controller timing has to allow 2.8ms for a responder to answer.

Interpreting that, any controller must thus wait 2.8ms to recieve a response. If our responder thus uses a timeout of 2.1ms, it will work with all controllers.

What say you?

Regards
Bernt

[ericthegeek]

Originally Posted by berntd

Interpreting that, any controller must thus wait 2.8ms to recieve a response. If our responder thus uses a timeout of 2.1ms, it will work with all controllers.

Unfortunately, no. The 2.8ms time includes time for transmission delay. Transparent Inline Devices (hubs, splitters, etc.) are allowed to delay the signal by up to 88us each way. The timing values given in the standard allow for up to 4 transparent inline devices, which gives a round-trip delay of 704us. See E1.20-2010 Section 4.2.2.

The other problem you're going to run into is that if you wait until the end of the response time to get the DMA interrupt and start processing the packet, you'll have no time left to process the request and send the response before the controller gives up and assumes the response was lost.

[berntd]

Originally Posted by ericthegeek

Unfortunately, no. The 2.8ms time includes time for transmission delay. Transparent Inline Devices (hubs, splitters, etc.) are allowed to delay the signal by up to 88us each way. The timing values given in the standard allow for up to 4 transparent inline devices, which gives a round-trip delay of 704us. See E1.20-2010 Section 4.2.2.

The other problem you're going to run into is that if you wait until the end of the response time to get the DMA interrupt and start processing the packet, you'll have no time left to process the request and send the response before the controller gives up and assumes the response was lost.

Eric, I know.

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.

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.

Regards
Bernt

[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.

[berntd]

Great minds think alike.

as I type this, our porgrammer is trying to split the reception into to DMA transfers.
First after 3 bytes to get the length and then another transfer for the rest.

Let's see how that goes.

Regards
Bernt

[sblair]

Looks like I'm a little late to the party tonight but I was going to suggest the same thing it looks like you've already arrived at.

I've used DMA in some of my implementations and I do as suggested, I get the first few bytes so I can get the packet length info and then set my DMA routine to trigger me again once I've gotten them all and that has worked well. It is really the ONLY way you can use any kind of DMA routine.

As Eric mentioned, the critical factor in the timings was in maintaining DMX Null Start Code performance so using timeouts just really wouldn't have worked without a more serious impact.