The set_directions function will use the low order bits of the third parameter to set the bits defined in the first two parameters. In this case it will use the 6 least significant bits. You can use -1, 0b111111, 0x3f, 63, 0xffff, or any value that has ones in the 6 least significant bits. A value of -1 has all 32 bits set to 1.
The 0b is equivalent to the % prefix in Spin. It is used to define a binary constant. 0b is a Gnu extension to C, and is not part of standard C. If you want to be 100% standard C you should avoid using 0b, and use hex, octal or decimal instead. Here are the various ways you can write the Spin constant %111111 in C:
The 0x prefix is used to define a hexadecimal number. It is equivalent to the $ prefix used in Spin.
The octal format is a bit strange. Any number in C that is prefixed by a zero is treated as octal. Beware of this. This has caught me a few times where I intended to write a decimal number, but because I added a leading zero it was treated as octal instead.
-1 as a hex number is 0xffffffff. It's basically programmer shorthand for "all bits on".
It works very much like decimal, with borrow - If you take the number 10000 and subtract one, you get 9999. If you only have 4 positive digits to represent the number, then 0000 - 1 = 9999 too, because it wraps around like an odometer. Replace the 0's and 9's with 0's and 1's, and you've got binary.
I originally thought perhaps it was set(low, high, value), but the header says it's the other way around, IE high-pin, low-pin, then value. According to the docs, that should be right.
Are there any other cores running code that might be outputting to those pins? That would mess you up.
When you declare button1 as an int and set it equal to input(21) it only reads the input once at the beginning of the program. You could use #define to make button1 equivalent to input(21). Somewhere at the top of your program put
It's best not to use defines because they obscure the code. On the Prop it doesn't matter much, but in "real world" code having functional stuff in defines makes it hard to debug.
You could do this instead:
int Button( int index )
{
return input(20 + index);
}
Then elsewhere in your code:
while(1)
{
while( Button(2) == 0 )
{
...and so on. I realize this is a relatively trivial thing, but #defines don't do type-checking, and they can make compiler warnings and errors more difficult to track down as well. An optimizing compiler will likely translate both versions into exactly the same code.
#define can be used to obfuscate code, but in this case I think it makes it more readable. Now if you put the #define in a header file it might make it a little more difficult to trace through the code, but I don't see a problem with putting it in your main program file.
Jason's suggestion is good also. However, you may want to just use input(21) and avoid using button1 or Button(1) entirely. It might be good to add a comment that says that input(21) is button1. Personally, I think #define would be fine in this situation.
You can make it obvious to someone reading the code that the value of button1 can change by making it look like a function call (note the empty parentheses):
The biggest reason I dislike these, is that a mistake in the body of the define will show up on the line where it's used, not the define itself.
For example, if you mis-typed this as:
#define button1() (inputs(21))
The compiler would complain here:
while( button1() == 0 )
...telling you "no matching function for void inputs(int) found" or something like that. Anyone reading that line of code would wonder what the compiler was smoking, since that line says nothing of the sort. Like I said, in this case it's small and harmless, but bad habits start this way so I was suggesting an alternative.
Comments
0b111111 // Gnu binary extension
0x3f // Hexadecimal
63 // Decimal
077 // Octal
The 0x prefix is used to define a hexadecimal number. It is equivalent to the $ prefix used in Spin.
The octal format is a bit strange. Any number in C that is prefixed by a zero is treated as octal. Beware of this. This has caught me a few times where I intended to write a decimal number, but because I added a leading zero it was treated as octal instead.
It works very much like decimal, with borrow - If you take the number 10000 and subtract one, you get 9999. If you only have 4 positive digits to represent the number, then 0000 - 1 = 9999 too, because it wraps around like an odometer. Replace the 0's and 9's with 0's and 1's, and you've got binary.
/* 3 button calculator */ #include "simpletools.h" // Include simple tools int main() // Main function { set_directions(9,4,0b111111); // Output Lights set_directions(23,21,000); // Input Buttons while(1) { int a = 0; while(input(22) == 0) // Enter first operand { if (input(21) == 1) { set_outputs(9,4,1 + get_outputs(9,4)); pause(300); } } a = get_outputs(9,4); set_outputs(9,4,0); while(input(23) == 0) // Enter second operand { if (input(21) == 1) { set_outputs(9,4,1 + get_outputs(9,4)); pause(300); } set_outputs(9,4,a + get_outputs(9,4)); } while(input(22) == 0) //Clear when button 2 pushed { } } }Any Idea why set_outputs(9,4,0) does everything but clear outputs 9 through 4?
I originally thought perhaps it was set(low, high, value), but the header says it's the other way around, IE high-pin, low-pin, then value. According to the docs, that should be right.
Are there any other cores running code that might be outputting to those pins? That would mess you up.
make button1 a variable
define button1 to equal input(21)
/* 3 button calculator */ #include "simpletools.h" // Include simple tools int main() // Main function { set_directions(9,4,0b111111); // Output Lights set_directions(23,21,000); // Input Buttons static char a; int button1 = input(21); int button2 = input(22); int button3 = input(23); while(1) { while(button2 == 0) // Enter first operand { if (button1 == 1) { set_outputs(9,4,1 + get_outputs(9,4)); pause(300); } } a = get_outputs(9,4); set_outputs(9,4,0); while(button3 == 0) // Enter second operand { if (button1 == 1) { set_outputs(9,4,1 + get_outputs(9,4)); pause(300); } } set_outputs(9,4,a + get_outputs(9,4)); } }Or why didn't this work?
You could do this instead:
int Button( int index ) { return input(20 + index); }Then elsewhere in your code:
while(1) { while( Button(2) == 0 ) {...and so on. I realize this is a relatively trivial thing, but #defines don't do type-checking, and they can make compiler warnings and errors more difficult to track down as well. An optimizing compiler will likely translate both versions into exactly the same code.
Jason's suggestion is good also. However, you may want to just use input(21) and avoid using button1 or Button(1) entirely. It might be good to add a comment that says that input(21) is button1. Personally, I think #define would be fine in this situation.
For example, if you mis-typed this as:
The compiler would complain here:
...telling you "no matching function for void inputs(int) found" or something like that. Anyone reading that line of code would wonder what the compiler was smoking, since that line says nothing of the sort. Like I said, in this case it's small and harmless, but bad habits start this way so I was suggesting an alternative.