Team 166 Has Open Sourced Its Code

[Eric Finn]

Thank you for the info about the code we don't own or have the right to redistribute being on the project. All code has been temporarily taken down and we are going to repost *our* code soon.

EDIT: Our chopshop library (CHOPSHOP.C and CHOPSHOP.H) has been uploaded. This library contains our code from previous years (EEPROM, drive algorithms, etc.) that we keep from year to year. More current code will be uploaded once the writers believe that it's ready to release. Again, thank you for notifying us of the licensing issues.

[ay2b]

Originally Posted by Eric Finn

EDIT: Our chopshop library (CHOPSHOP.C and CHOPSHOP.H) has been uploaded. This library contains our code from previous years (EEPROM, drive algorithms, etc.) that we keep from year to year. More current code will be uploaded once the writers believe that it's ready to release. Again, thank you for notifying us of the licensing issues.

Be careful with this one too. You are not permitted to directly reuse code from previous years, just as you are not permitted to directly reuse hardware components from previous years. You are, however, permitted to use the designs, ideas and algorithms from past years, but your implementation is supposed to be new each year, implemented during the build season (and fix-it windows).

Any code which is published publicly, in a location widely recognized by FIRST teams, is considered COTS and is permitted to be used directly, as per the COTS rules. This allows the use of Kevin's code, or IFI's code, and allows them to update it outside the build season, and all teams to use any version of it.

It is my interpretation of this rule, that if you were to have published your code from past years on CD, or on sourceforge and announced it on CD, then that code would also be considered COTS and would be permitted. It is not clear to me: if you were to develop something prior to the build season, and then publish it during the build season, would that still be considered COTS?

Unfortunately, in my quick perusal of the rules, I am unable to find the exact rules at this time in order to quote them here. Hopefully someone else can help me out, find them and post them.

[dcbrown]

Compilers, not programmers, should do optimizations

Correct. Too bad we don't have a decent optimizing compiler available.

But is it better to have code that reads:

    for (samples_recieved=0; samples_recieved<10; samples_recieved++)
    {
           :

Or code?

    for (samples_left_to_receive=10; --samples_left_to_recieve !=0; )
    {

Both do equivalent things, the best optimizing compiler won't turn one into the other and yet the 2nd is much more efficient in that the change in control variable also will set status/results for testing and avoid a second comparison operation. With the PIC18F, the above is 3x+ times more efficient due to a programmer choosing a different but equivalent method.

Does this really matter? In most cases, no. But if the code happens to be executing at interrupt level or is executed thousands of time per second then generally yes it does matter. A few changes like this usually can reduce the interrupt code footprint to 1/2 to 1/3 of what it was. Typically I scrutinize only about 10% of the code I write for efficiency, yet the run-time impact can be huge.

Knowing the underlying architecture of a processor you're working on also can impact which code constructs you choose to utilize. Yeah, it would be great if the compiler figured out this stuff for you... but often it doesn't or like above can't. On the PIC, for example, computing ram addresses isn't exactly efficient. In some cases if makes sense to unroll "for(...)" loops. For example:

    for(ndx=0; ndx<10; ndx++)
    {
          sample[ndx] = 0;
    }

is terribly inefficient. It takes 14-16 instructions to calculate the ram address plus the overhead of ~13 instructions to manage the loop variable. Choosing to unroll the loop in the above case into the following is a huge win as the code execution is on average 10x times faster with little change in code size.

    sample[0] = 0;
    sample[1] = 0;
    :
    sample[9] = 0;

Anyway my point is a programmer should care about how code constructs map to the underlying architecture. If they didn't, then the way to go would be to just change everything to extended floating point precision and do all calculations that way -- the "smarts" in the compiler would figure out when we needed integers vs floats and 8 bit values vs 32 bit values and hide all that nonsense from the programmer.

PS
Another common trick/practice on the PIC when dealing with loading data from h/w such as:

379:               	timer_count = TMR1H;
380:               	timer_count <<= 8;
381:               	timer_count += TMR1L;
382:               	timer_count -= offset;

 06730    50CF     MOVF 0xfcf, W, ACCESS
 06732    6F17     MOVWF 0x17, BANKED
 06734    6B18     CLRF 0x18, BANKED

 06736    C517     MOVFF 0x517, 0x518
 06738    F518     NOP
 0673A    6B17     CLRF 0x17, BANKED

 0673C    50CE     MOVF 0xfce, W, ACCESS
 0673E    6E2B     MOVWF 0x2b, ACCESS
 06740    6A2C     CLRF 0x2c, ACCESS
 06742    502B     MOVF 0x2b, W, ACCESS
 06744    2717     ADDWF 0x17, F, BANKED
 06746    502C     MOVF 0x2c, W, ACCESS
 06748    2318     ADDWFC 0x18, F, BANKED

 0674A    5119     MOVF 0x19, W, BANKED
 0674C    5F17     SUBWF 0x17, F, BANKED
 0674E    511A     MOVF 0x1a, W, BANKED
 06750    5B18     SUBWFB 0x18, F, BANKED

A simple change can result in much more efficient code by using an anonymous union structure:

typedef union u_U16
{
	unsigned int data;
	struct {
		unsigned char b0;
		unsigned char b1;
	};
} u_U16;

u_U16 timer_drift;


384:               	timer_drift.b1 = TMR1H;
385:               	timer_drift.b0 = TMR1L;
386:               	timer_drift.data -= offset;

 06752    CFCF     MOVFF 0xfcf, 0x516
 06754    F516     NOP

 06756    CFCE     MOVFF 0xfce, 0x515
 06758    F515     NOP

 0675A    5119     MOVF 0x19, W, BANKED
 0675C    5F15     SUBWF 0x15, F, BANKED
 0675E    511A     MOVF 0x1a, W, BANKED
 06760    5B16     SUBWFB 0x16, F, BANKED

Another quick 3x increase in code size and execution efficiency.