In the last week I have spent time going through the standard framework working to understood what each part does and deciding at this point if it something I need or not. I now have a setup that has 3 code files (main.c, user_routines.c, and vex_startup.c), 3 header files (user_routine.h, vex_aliases.h and vex_library.h) and the vex_library.lib library. MPLAB C adds 18F8520.h at compile time.
Once I have had some time to shake the bugs out of it and document it better I will post it for others to look at/use.
I have user routines for motors, digital port input, and digital port output. I would like to get my current robot platform up and running on this framework. To do that I need to develop a driver for the old style optical encoders.
You all have been quite good to me so far and I was hoping I could get some more ideas/help.
Does anyone have or know of example code that supports or could be adapted to support the older optical encoders using digital ports rather than an interupt port? I am having trouble getting started…
It appears that the source for the master code is not released. Given this is anyone aware of any documentation for the V7 code? Digging through header files and looking at source I am getting an idea of how it does what it does but it would sure help to have some documentation.
I think I understand the concept of autonomous mode from a competition standpoint. However, after spending an hour figuring out why I couldn’t get motors to work I would like to understand how it comes into play from the vex software perspective. The problem turned out to be that I was not putting the master processor in autonomous mode and it was ignoring the values I was setting for the pwm ports.
The Purpose of using the Interrupt Port, is to know exactly when the Encoder has reached the next Encoding Point, with minimal use of Processor Time.
Using a regular Digital Input Port, will require lots of your Processor Time, Polling for that next Encoding Point.
The Interrupt Port, (when properlly configured) will Trigger when the next Encoding Point is reached, saving you Processing Time.
[FONT=Verdana]Thanks I had found your post previously. The code has figured prominently in my quest to better understand the Vex Software Architecture. [/FONT]
[FONT=Verdana]I have modified a copy of vex_library where I have incorporated the Getdata and Putdata routines into the Handle_Spi_Int routine which has so far allowed me to code without having to loop through the statusflag.NEW_SPI_DATA check each 18.5 ms.[/FONT]
[FONT=Verdana]MarkO,[/FONT]
[FONT=Verdana]I am using the single wire older Vex Optical Encoders. Your point regarding using interrupts to minimize the load on the processor is good. I guess I was looking to see if I could find a way that didn’t load the processor down too much and also didn’t use up two (one for each drive wheel) of the interupts.[/FONT]
[FONT=Verdana]I have read the Timers White Paper on Timers and found it very helpful. The pointer to the Vex Sensor Test was great. I had seen it but not thought of it as a resource in this instance. Now I have more code to pull apart.[/FONT]
