[Dave Flowerday]

Originally posted by kmcclary
DV method:

Whenever the data is about to change, drop DV, toss in a few NOPs (No Operation opcodes) in the micro's program to let the ringing stop, THEN change the value, wait a few NOPs again, then raise the DV line. Now you're GUARANTEED that data will NEVER be changing while the DV line is high.

Actually, this is only guaranteed to work if all the data in lines are latched at the same time. We've convinced ourselves that this is not the case. We did have a "data valid" flag last year to guard our data and it did not work. We found it is entirely possible to sense the data valid signal and still have corrupted data at the inputs.

Handshake method:

Create a line pair between the black box and the RC, "request" and "valid". Both are low initially. RC raises "request". Black box puts data on and raises Valid. Once RC has it, it drops Request. Box drops Valid. This is ALWAYS guaranteed to work.

Again, this only works if the data is clocked in at the same time. Now there's just an added mechanism for the RC to request when data is sent.

Pulse Sync method:

You can synchronize your updates to the loop time "heartbeat". RC has a "Pulse Request" line toward the black box. The RC *toggles* this line every loop at the TOP of the loop (you'll need a SECOND SEROUT statement to get that out. Use old values from the last loop for everything else). The Black Box has a one value Queue inside of it.

FYI, I'm trying the Pulse Sync method first.

Our method this year will be similar to this as well. We're testing it now to see if it meets our needs.

The reason the first two methods cannot be guaranteed to work when the data is not latched at the same time is this: suppose that some of the black box data lines are latched first. They're still showing the old values. Now the black box data changes. Then the next set of inputs are latched, which contains the rest of the BB data lines which are now showing new values. OK, so now the RC has read bad data. Unfortunately, the BB data valid flag changes before the last set of inputs are latched (and the DV is connected to the last set of digital ins). Now the RC has invalid data but a valid flag. Oops. The only way to overcome that would be to delay after setting the data bits but before setting the valid flag. However, one needs to know how long to delay. If you don't know this number and instead just guess, you can probably get it to be reliable. You can't guarantee it though until you know precisely the time it takes the RC to latch all the digital inputs.