Chris,
Quote:
|
Originally Posted by Chris Orimoto
I somehow believe that the search/track functions can be bogged down by other code when more complex functions are added.
|
This shouldn't be the case because the same amount of camera and tracking code is guaranteed to execute every 26 milliseconds. It's very consistant.
Quote:
|
Originally Posted by Chris Orimoto
My only concern is that the menus completely halts the current code, which could be problematic depending on other functions that should be executed.
|
Actually, it doesn't. As people get into and understand the code, they'll realize that the camera code implements a real (cooperative) multitasking system. Every 26 ms loop, a little piece of camera code and tracking code executes giving the appearance of multitasking. This is exactly how your single processor PC makes it appear as though many applications are running at once. Getting back to the menus, you'll notice the camera still tracks when you invoke the camera menu. Well this happens because I just add the camera_menu() task to the other three tasks that are running. When the camera_menu() code sets a flag indicating it's finished, I remove it from the task list. On the other hand, when you invoke the tracking menu, the tracking stops, giving the appearance that everything else has stopped. Actually, this is by design because while you're in the tracking menu, the user might invoke the interactive PWM sub-menu, which needs control of the servos. BTW, the "scheduler" is located in Process_Data_From_Master_uP() if you're interested in taking a peek.
Quote:
|
Originally Posted by Chris Orimoto
In the end though, I hope to find absolute settings (that can be loaded through the header file).
|
Check out the streamlined version of the code, which gets its configuration from camera.h and tracking.h.
Quote:
|
Originally Posted by Chris Orimoto
One question for everyone though...since the camera is interrupt driven, how does it affect other interrupting encoders?
|
It's not interrupt driven, it's message driven. The only interrupts that are firing off are about 120 serial port interrupts per second to handle the camera telemetry, which is easilly handled.
Quote:
|
Originally Posted by Chris Orimoto
Does anyone know how many interrupting devices the new PIC can handle?
|
It has more to do with how much time you're spending in the interrupt service routines. As a data point, my ADC code will generate up to 12,800 interrupts per second at the highest sample rate.
-Kevin