|
Re: Printf has just entirely failed to do anything
Quote:
Originally Posted by Mark McLeod
Kevin has a good point.
Although calling CAL_Update() from the fast loop (via Process_Data_From_Local_IO) would only prevent the camera from working properly.
It wouldn't lockup the controller or disable printfs. The camera code doesn't take very long to execute.
P.S.
Your autonomous code should also execute in a slow loop. It doesn't help to execute faster than you can deliver instructions to the pwms. If you check the IFI default code you'll see the autonomous section in user_routines_fast.c is really a slow loop by virtue of the line:
Code:
if (statusflag.NEW_SPI_DATA) /* 26.2ms loop area */
You just need to add your camera calls within that slow loop.
I'd advise you to pull all your autonomous code out of the user_routines_fast.c file anyway. The name of that file only confuses the issue and your freshmen programmers, since it's not true for the autonomous code.
|
Mark,
You're right about the camera code executing quickly, but I think that might be where the problem lies. The initialization process fires off atleast a few packets to the camera. If Debug is on, it will also fire several long strings to the terminal. If all of this is in the fast loop... Well I just think the most likely culprit is all of these serial writes stacking up and possibly overflowing queues and generally making a mess of things.
__________________
The difficult we do today; the impossible we do tomorrow. Miracles by appointment only.
Lone Star Regional Troubleshooter
|