Talk:Multiple autonomous modes

From FIRSTwiki

Any reason to use a macro? It's kinda bad practice to utilize the preproccesor too much. It creates room for problems that a debugger can't find. The fact that the default code already contains such a huge number of #define's doesnt help. If they are read in the wrong order, trouble can easily arise. (I think the variables in your macro would actually be #defined 3 times from the original PIC registers.) --Max 12:38, 5 Jun 2004 (EDT)

Concerning my recent edit ... I agree with Max about the macro thing. Personally, we used a simple switch that was either on or off, so the choice was easier ... but we also implemented a pot select, where we called a "step" function that would return a certain value for a given range. I think something like that would be best ... but of course, it all depends, as there's a wide variety of selecting mechanisms out there. To the point, though, I kept your way of doing it, namely

   #define SELECT_AUTO_MODE (char)((p4_sw_trig<<3) | (p4_sw_top<<2) |  \
     (p4_sw_aux1<<1) | p4_sw_aux2)

But I believe you should explain what this does. It is by no means the simplest (and IMO would only confuse new people looking at it), but if you want to keep it, at least explain in words what it does.

I did change the macro name, however. I felt OI_AutoChoice was a bad name, because it doesn't insulate the user from the implementation. If you should change the selector from the OI to the RC, so long as it returns a number in the right range, why should the user care where it came from? Also, by most sensible styles, macro names are all capped. I did a few other minor edits ... hopefully nothing controversial. Though, I'll try to add my code for selecting multiple autons, since we put a switch on the RC it should offer a nice contrast and cover the issue more fully (I don't have the code with me ... recently cleaned up my computer). --Mrawls 12:53, 5 Jun 2004 (EDT)

Thank you for your comments, and I will try to implement them when I have time. :rolleyes: Also, It makes the macro far more readable if i use p4_sw_trig then if I had used rxdata.oi_swB_byte.bitselect.bit4. (And in the actual code, I had one more #define: OI_Auto_Bit1) --Astronouth7303 13:36, 5 Jun 2004 (EDT)

I wasn't saying that you shouldn't use the aliased names, I was saying that you shouldn't use a macro, rather, use a function. As I said before, macro's don't get debugged, only the final code that gets compiled can be debugged. Macros also introduce new kinds of problems because the order in which they are included matters while regular code doesn't matter (as long as function declarations come before their first usage.) --Max 15:19, 5 Jun 2004 (EDT)

Nothing wrong with too many #defines, so far as I know, so long as they do their job -- i.e., aid in abstraction and only have to change something once, instead of many times, etc. I just felt that a function might be more appropriate as a general solution to offer teams. (Maybe Max could explain why this constitutes excessive use of the preprocessor.) But as far as your description,

 What this example does is it takes each bit, bit-shifts it up the appropriate amount, and ORs it with the other bits, generating a number (in this case, 0 to 15 (2^4 - 1).

Yes, this explains what the code does, and that is a good thing (I imagine we should have some bit-wise operator pages) ... but it doesn't explain how the user would actually use the code. I.e., what would the operator press to get mode 13 activated, for instance. I assume it's a joystick you are connecting to the port, ... so I'd explain the sequence of button pushes, or at least a few examples of them. (Oh, and this seems like a good article to put on FIRSTwiki:Featured article candidates. Putting there now ...) --Mrawls 14:32, 5 Jun 2004 (EDT)