|
RDM Timing Discussion Discussion and questions relating to the timing requirements of RDM. |
|
Thread Tools | Search this Thread | Display Modes |
March 29th, 2007 | #1 |
Junior Member
Join Date: Mar 2007
Location: Middleton, Wisconsin, USA
Posts: 4
|
Exceeding MAB time
RDM imposes a restriction on the MAB time (88 us) that is new since DMX. Some combinations of external UART and CPU may have difficulty guaranteeing that time (if, for instance, interrupt priorities are relatively fixed and a higher priority interrupt preempts and takes its sweet time.)
It seems like the restriction is based on performance considerations, to prevent the line from laying around idle for too long. In that case, exceeding the spec a bit (say for about 40 us) may not be a tragedy? I can imagine that some RDM devices could assume that the controller has gone, but I'm wondering if, in general, the extra time would go unnoticed. Dan |
March 29th, 2007 | #2 |
Task Group Member
Join Date: Jun 2006
Posts: 181
|
Dan
This is a maximum allowed time for the MAB. If you are greater than this, you are not compliant. The restrictions on times were designed to keep RDM traffic "tight" and reduce the impact on the throughput of null start code packets. If, as you suggest, your system cannot meet this time you cannot claim compliance, as the spec currently stands. What your are suggesting is that your system can have (presumably intermittently) up to 88us of intercharcter delay ... which seems unusually high. A necessary approach may be to mask interrupts accordingly to keep the MAB short, or rejig priority levels. Once you have sent the start code (and thus completed the MAB), there is more slack on interbyte time. Please dont forget RDM also places a restriction on the total packet time. Can you elaborate on your particular hardware/system that exhibits this problem ? Exceeding the spec for the extra 40us you propose WOULD be a potential tragedy, as someone else might legimately reject your packet based on receipt of what is (to them as per the spec) an illegally timed packet. Unlikely perhaps, but possible and legitimate. This was not (to my knowledge) ever flagged as an issue during public review. Peter Willis |
March 30th, 2007 | #3 |
Junior Member
Join Date: Mar 2007
Location: Middleton, Wisconsin, USA
Posts: 4
|
Thank you, Peter, this is just the kind of answer I was looking for.
We have a separate timer, with separate interrupt, that is used to handle break and MAB timing. (Separate from the UART, that is.) So the interslot time is not an issue, that's handled by the UART itself. Total packet time is also compliant. The interrupt priorities are mostly fixed (MPC852 running Vxworks,) unless I modify the OS code. The timer interrupt is being preempted by other DMX ports and the system clock. This is, indeed, an intermittent problem that occurs too often when busy and interrupts align just so. I'll bring the MAB time into spec range somehow, probably modifying the OS code to give higher priority to these particular timer interrupts, as you suggest. Thanks, Dan |
Bookmarks |
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Time between controller packets | Dan Scheurell | RDM Timing Discussion | 1 | April 1st, 2007 11:38 PM |