Chief Delphi - Scripting Setup and the Camera + Serial Port Drivers

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)

- - Scripting Setup and the Camera + Serial Port Drivers (http://www.chiefdelphi.com/forums/showthread.php?t=32538)

Scripting Setup and the Camera + Serial Port Drivers

I have not had a chance to e-mail Mr. Watson yet, however, trying to integrate the Camera control system into the scripting code is becoming a real nightmare. The difficulty is in the serial port driver. The problem as I see it is thus:

1) There are really three different serial port drivers, they are:

a) usr_SerialDrv.c

b) serial_ports.c

c) PicSerialDrv.c

"a" is the defaut FRC driver, no need to worry about it just delete it. "b" is Mr. Watson's serial port driver, allowing LCD screens and printf functions from the FRC controller. "c" is the serial port driver which comes with the camera. "b" and "c" really do most of the same things, put are not intrinsically compatible. My immediate solution is to call some parts of "b" from within "c," thereby leaving the camera driver intact and just adding certain functionality from the seril ports driver. Problem is, in even limited testing on the controller it has been doing some really weird things.

2) What the is the "Dynamic Debug Tool?" This phrase was included in the camera software. In the PicSerialDrv.c file there was this comment:

Quote:

This file contains an unsupported serial device driver for the 18F8520 micro. It was designed to be used with the Dynamic Debug Tool (DDT). The DDT is now apart of the IFI Loader (ver 1.8 or later) under the 'Options' menu. The DDT can be used to directly read and modify memory locations and registers of the user processor dynamically.

The camera quick start guide specifies the the PicSerialDrv.c as a required file. Furthermore, the PicSerialDrv.c specifies that :

Quote:

You can put your own callback routine inside CheckUartInts. This will allow you to parse data from another device in real time.

So, in fact, this is where I called Mr. Watsons code. The problem is, that the two drivers seem to be trying to do different things with the ports.

3) While trying to use interrupts (a switch attached to one of the digital ports) and the camera software at the same time, the controller keeps resetting itself, for no reason which I can identify.

4) Building on #3, the camera has what is esentially a state machine servicer (for lack of a better term) built into it; that is, calling camera_track_update() will tell you whether or not the camera has been successful in updating and tracking to a new position. To my mind, this should be handled almost like an interrupt, that is, when it returns 1, the camera track code is executed, but in the code provided, it sits in user_routines_fast in the sutonomous section, and simply says:

Quote:

if(camera_track_update()==1)
tracking = 1;
trakcing code
else
tracking = 0;

So, if I understand it correctly, what it is really doing is sitting in the autonomous space and waiting for an update. Is this really the best way to do this?

5) Finally, the camera needs to be calibrated before use. This is done by hooking a PC up to the camera and running a JAVA script program to get exposure values. You then have to send these values to the camera in "User_Initialization()" by including the line

Quote:

camera_init ( yellow exposure, green exposure, red exposure )

The drawback to this is that it requires re-compiling and loading the code. Is there a way to set it so that you could use onboard switches to change the state of the exposure values without having to re-load the code? My only thouught so far was to have a pair of pushbuttons attached to the operator interface, and after pressing some button combination, the display byte gets set to the currently selected value and then the two buttons increment it up and down.