[kmcclary]

You have a "race condition" when your data is changing. Well known problem.

First off, you should use a high current bus driver between the micro and the RC, to insure that the line capacitance isn't slowing the bit changes.

Second, on some micros rewriting a its output with the same number CAN cause microglitches in the outputs. Therefore avoid rewriting the SAME value to your black box outputs if it has NOT changed. Queue new value in the Black Box, and compare with the current value presented. ONLY rewrite the output leads if the data has changed.

Third, you need ONE OF:

A "data valid" (DV) line to the RC,
*OR*
A handshake line pair between the black box micro and the RC,
*OR*
A single Request Pulse Sync line from the RC.

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.

Now in the RC, read the port and the DV into TEMP VARIABLES. (NEVER overwrite the last known good one in your program until you're SURE it is good). If the DV line is high, you KNOW the data are good, and transfer it into your real variables. If DV is low, KEEP the last good value(s) intact (toss out the temp values) and try again next time around. ONLY update the real variable in the RC program when you're SURE you have a valid input, and that's guaranteed to be when DV is high.

ADVANTAGE: NORMALLY you have only one loop time latency for data transfer.
PROBLEM: If your micro's update rate is EXACTLY some multiple of the loop time, you COULD get into the rare problem of "Beat Frequency". The RC could never see a high DV, because you're always updating it at the time the RC reads it.

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.
DISADVANTAGE: It takes a few loops times to run the protocol, limiting your bandwidth (unless you have more than one SERIN/SEROUT in your loop).

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.

You know the RC will be busy immediately after togging the Sync line, so Black box updates the data lines immediately after sensing a toggle (again it has a one value Queue inside it). The data now never changes except when the RC is busy, and it'll be stable by the time the RC gets around to its next SERIN. If the black box micro choice is right, you simply tie Pulse to the interrupt line on the micro. The Interrupt Service Routine (ISR) can figure out the proper way to "clear" the interrupt so that the next transition triggers it again. If the ISR can't read the interrupt's hi/low status directly to properly "clear" the interrupt so it's ready for the next transition, simply tie the signal to another input pin as well so it CAN read it.

Hopefully, this should guarantee valid data on EVERY loop.

Please let me know if you implement one of these before I do. I'm not at that point yet because I've been out with pretty serious Pneumonia so I'm about a 1.5 weeks behind in MY black box work.

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

- Keith