Go to Post Tell someone familiar with FIRST that you won a regional and they will congratulate you, tell them you won a chairmans award and they will celebrate you. - Brandon Holley [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Closed Thread
 
Thread Tools Rate Thread Display Modes
  #1   Spotlight this post!  
Unread 20-01-2003, 13:37
kmcclary's Avatar
kmcclary kmcclary is offline
Founder 830/1015;Mentor 66/470/1502
FRC #0470 (Alpha Omega Robotics)
Team Role: Engineer
 
Join Date: Aug 2001
Rookie Year: 1994
Location: Ann Arbor, MI
Posts: 491
kmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond reputekmcclary has a reputation beyond repute
Data Valid

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
__________________
Keith McClary - Organizer/Mentor/Sponsor - Ann Arbor MI area FIRST teams
ACTI - Automation Computer Technologies, Inc. (Sponsoring FIRST teams since 2001!)
MI Robot Club (Trainer) / GO-Tech Maker's Club / RepRap-Michigan) / SEMI CNC Club
"Certifiably Insane": Started FIVE FRC teams & many robot clubs (so far)!
2002: 830 "Rat Pack" | 2003-5;14: 1015;1076 "Pi Hi Samurai" | 2005-6: 1549 "Washtenuts"/"Fire Traxx"
2005-(on): 1502 "Technical Difficulties" | 2006-(on): FIRST Volunteer!
2009-(on): 470 "Alpha Omega" | WAFL | Sponsor & "Floating Engineer" for MI Dist 13 (Washtenaw Cnty)
2011: 3638 "Tigertrons" | 2013-(on): 4395 "ViBots" | 2014-(on) 66 "Grizzlies"
"Home" Teams: 66, 470, 1076, 1502, 4395
Local FIRST alumni at or coming to Ann Arbor (UM/EMU/WCC/Cleary)?
...We Want YOU as a Mentor! Please email me for info!
Support CDF Reputation - If a posting helped, thank 'em with rep points!
"It must be FRC build season when your spouse and children become 'Action Items 8 & 9'..."

Last edited by kmcclary : 20-01-2003 at 13:41.
Closed Thread


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
How to access other Digital inputs on OI? DougHogg Electrical 2 12-03-2003 13:57
Serial Port and Custom Circuit Ryan Meador Programming 40 06-02-2003 11:34
Specs full of errors??? Simon G Motors 1 20-01-2003 12:53
Analog vs Digital inputs? f22flyboy Programming 8 08-11-2002 22:18
making speed controller digital CharlieWilken Electrical 4 01-03-2002 20:15


All times are GMT -5. The time now is 22:06.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi