in PHP, I have something like
function doStuff($in, $value)
{
$var = "V_" . $in;
$$var = $value;
}
Is there a way to do something similar in C?
Basically I’m trying to figure out how to make a sort of library to make working with IO pins on an AVR easier. So for example, there would be a function to set a particular pin to an OUTPUT. That pin in the AVR is part of PORTB. Setting it to an output and giving it a value requires me to reference DDRB and PORTB constants and set their values. Rather than going through all of that, I’d like to be able to call a function such as SetMode(Pin #, Mode);. I just can’t figure out how to do that.
Your question is still a little unclear (as indicated by the assortment of interpretations in the answers). I’m assuming that you want to refer to pins by physical pin number. If this is not correct, please clarify your question so we can provide better answers.
Here’s roughly how I would do it if someone held a gun to my head:
DISCLAIMER: I have not tested this nor been particularly careful about checking documentation. The code is written for avr-gcc/avr-libc on Linux, though it may work elsewhere.
See http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_port_pass
And here’s why it’s not a good idea:
It doesn’t abstract away any meaningful behavior (it actually removes abstraction — the physical pin number is lower level than the logical port/pin). Moreover, the physical pin number is not necessarily the same for different package formats. The pins of PORTB may not be assigned to the same physical pin numbers on a QFP package as a PDIP package. So this code is actually more confusing.
It adds overhead. You have an extra function call (which costs cycles and stack) and two (or more) arrays used for lookups (which cost flash and RAM on the AVR unless you take special measures, in which case they cost extra cycles and flash or EEPROM) not to mention all the indirections (array lookups, pointer dereferencing) and the extra compare and branch. In desktop & web development you would be right to laugh at my concern over such small costs, but on AVR that waste has considerably more impact. (NOTE: You might be able to convince the compiler to optimize some of this out, but if you are using
-Osit will be difficult. And now you’re worrying about even lower level details than before…)The provided means of manipulating pins is not so complicated as to be worth hiding in this way. You should get comfortable with converting between hexadecimal and binary in your head (it’s not hard). Even if you don’t want to mess with hex, the
_BV()macro makes pin manipulations pretty easy (or just use(1 << x)which is more portable and will be recognized by more programmers).By the way,
PORTB,DDRB, etc. are not constants. They are variables that are tied to specific addresses or registers. Trying to modify a constant with something likeCONST_THINGY |= 0x03would produce a compiler error.Variable variables
C does not have the feature you described. It is a low level language (it is sometimes described as “high-level assembly”) that doesn’t provide many fancy features (by today’s standards). This is why it is the language of choice for AVR — you want to be close to the hardware, and you don’t want lots of extra overhead.
What C does have is pointers. Based on your question and comments I would guess that you aren’t very familiar with them, so here’s a quick explanation:
&operator returns a pointer to a variable, and is used like this:pointer = &variable;*actually has a couple of uses.int *pointer;Notice that you have to specify what type of variable it will point at.pointerpoints atvariable,*pointer = 42;will setvariableequal to 42, andother_var = *pointerwill setother_varto the value ofvariable.The point of all this is that you can effectively treat variables themselves like values, storing them and passing them around. You can’t really modify them in any meaningful way other than manipulating their value, but you don’t need to either.