Go to Post I don't even care if it doesn't work as well as they would like. YOU MADE IT. You may never use it, but you made it. AWESOME. Every year there has been 1 team (sometimes 2) that has done something that really stood out. This year 1 team has done 2 things that stand out. Thanks guys. - rees2001 [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

 
 
 
Thread Tools Rate Thread Display Modes
Prev Previous Post   Next Post Next
  #14   Spotlight this post!  
Unread 03-02-2006, 11:39
nheft nheft is offline
Registered User
FTC #0533 (Psichotics)
Team Role: Engineer
 
Join Date: Jan 2006
Rookie Year: 1999
Location: Lindenhurst HS
Posts: 35
nheft is a jewel in the roughnheft is a jewel in the roughnheft is a jewel in the roughnheft is a jewel in the rough
Re: 2006 CMUcam2 Code

I tried holding the reset button while powering up. Still getting random code errors.

I sprinkled some printf's into Process_Data_From_Master_uP - one at the beginning of the module, one to print out the entire rxdata buffer, and one at the end of the module. When the code error occurs I am observing that Process_Data_From_Master_uP executes one time.

When the mis-aligned rx buffer problem occurs, it looks like it's happening from the second message on; the first rxbuffer received after initialization looks OK.

I also tried a simple delay loop before IFI_Initialization to give the oscillator a few tenths of a second to stabilize before trying to do anything. This did not help either.

Another programmer from Team 358 loaded frc_camera_s on his RC and could not find a problem. I tend to believe there is a marginal timing problem somewhere that just doesn't occur with all RC's and does not occur with IFI default code.

For now, my work-around is going to be: (1) if the LED's show a code error, cycle power and (2) if the packets get misaligned, trap on a lack of proper incrementation of packet_num and force a code error via an infinite loop, taking us back to step 1. This trap can be disabled after five consecutive good packets since the RC seems to behave OK once it gets off to a good start.

Quote:
Originally Posted by Kevin Watson
I think we can go on the assumption that it's not caused by the camera code directly. The only thing that immediately comes to mind is some kind of race condition where the processor comes out of reset before the oscillator is stabilized. If I get a chance, I'll call IFI today and see what can be done about this. As an experiment, you might try holding the processor in a reset state while powering up. Do it enough times to get real statistics.

-Kevin

Last edited by nheft : 03-02-2006 at 11:41.
 


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
Out of the Box Camera Code russell Programming 9 21-10-2009 05:28
CMUCam2 code (FRC and EDU?) Amber Programming 0 15-02-2005 22:23
Team THRUST - Kevin's Code and Camera Code Combine Chris_Elston Programming 3 31-01-2005 22:28
CMUCam2 Camera Code - Are important parts commented out? Mr. Lim Programming 4 14-01-2005 12:11
heres the code. y this not working omega Programming 16 31-03-2004 15:18


All times are GMT -5. The time now is 11:16.

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