[Kevin Sevcik]

A lot of the basics have been covered by my colleagues here, so I'll just throw out some links and try to answer a few of your specific questions. First, you can look through the following pages for several presentations about programming and the control system in general:




Make no mistake, you will need at least a cursory knowledge of the rest of the control system to program effectively. At the very least so you'll know differences in function and purpose of the speed controllers vs. relays, etc. And you'll also be better able to tell if your program is doing something wrong or if one of the mechanical students has unkindly dumping a load of metal shavings into your the electronics.

That said, on to some of your more specific questions:
The Master source code isn't available for various reasons. I've considered doing disassembly on it out of sheer curiosity, but my brief examination of the binary files we're given to load seem to show jumps to memory areas not included in the dumps we load, so I suspect it'd be fruitless anyways. The good news is that you need to know very very little about that to program successfully. In fact, it is enough to mere know that you receive a data packet from the master every 24ms and that you HAVE to send a packet back for each of those or a watchdog on the master times out and your robot dies. The packets themselves are structs defined in one of the .h files.

All those acronyms and their uses are defined in great and painstaking detail in the PIC18F8722 datasheet and the PIC18 reference document. Luckily, you don't need to know a thing about those particular ones to have a successful robot.

Code written for in the standard Vex template would not even be source compatible with the standard FRC code. The two systems use different communication protocols between the master and user processor, primarily because of the vastly different IO peripherals and the different controllers. The variable names and aliases are also different for these reasons. You would certainly be able to replicate the algorithms between the systems, but copying code from one to another wouldn't work unless you defined some of your own aliases to map the Vex-specific variable names to FRC specific ones.

Finally, since you're an old hand at assembly and code optimization on older, slower processors, a word of warning. If you're thinking of using Fixed Point/Q-Math to speed up calculations on the PIC, be warned that bitwise right shifts are always unsigned, so if you're trying to shift signed variable, you'll either need to offset them into positive numbers or simply divide by the appropriate power of two. I imagine others on here think it odd that I often mention this, but hunting down this particular bug in some code one year was incredibly frustrating.