more Arduino silliness.

TO ALL this is my take on everything.: 

it was a typeo.. should have been RST_2 12

this one is rather small but my code for my sim has hundreds of #defines. 

here is the new file with IDE 2.0.3

//Pin Names
#define RST_1 13
#define RST_2 12
#define CE_1 11
#define CE_2 10
#define CLK_1 9
#define CLK_2 8
#define RD_1 7
#define RD_2 6
#define SCL 3
#define SDA 2
#define txPin 1
#define rxPin 0

//Pin Modes
pinMode(rxPin, INPUT);
pinMode(txPin, OUTPUT);
// Digital Ports
pinMode(RST_1, OUTPUT);
pinMode(RST_2, OUTPUT);
pinMode(CE_1, OUTPUT);
pinMode(CE_2, OUTPUT);
pinMode(CLK_1, OUTPUT);
pinMode(CLK_2, OUTPUT);
pinMode(RD_1, OUTPUT);
pinMode(RD_2, OUTPUT);

here are the first few lines of the .ino file
#include <SoftwareSerial.h>
#include <Wire.h>
// #include "Adafruit_MCP23017.h"
#include "pins.h"
#include "Fuel.LoadSelector.h"
BTW a few things to know ---- 

#define is supported by the language.  it takes no ram space and the pre-processor changes the define name to the defined value. Once you #define it, it a value that can be used anywhere in the code body. 
also ntewinkel the thing that is called 'void setup()' is very nutty. ie prohibition of executable code.  it should have been called init() and most likely have a return! in this chuck of code I must have rs-232 link up before I can continue.  part of the problem is with C++ which this is written in has the most rigid scoping rules. so for shits and giggles, my code base looks like this which fails and bitches about scoping rules of rxPin & txPin and other wonderfulness. :

#include <SoftwareSerial.h>
#include <Wire.h>
#include "pins.h" // remember this is GLOBAL where all of my pins are not the pinMode() 

int init(){} // Now this is where the pinModes() live.
int initSerial(){
int ret= 0;
Serial.begin(9600);
SoftwareSerial(rxPin, txPin); //rx & tx are defined in pins.h
Serial.begin(9600);
while (serial.availbe() > ) {
char buffer = serialread();
if (buffer = 0x0a ) ret = 1;
else ret = -1;
break;}
return( ret ) ; }

AND SO IT GOES.. 

the supper crud about loop() and setup()  are macros see this page and are NOT required. Amen. 

BTW It looks a if my code works when you use the eclipse tools with the AVR tool chain. 

THEREFORE either the definition of pinMode(pin, mode); LIES where pin MUST be a value. which I don't believe THEN  AND I DO BELEIVE the #define is not being substituted at compile time. !!!!!

AFTERMATH I really want to see the "railroad tracks" for this language!!!

phoenixcomm said:

THEREFORE either the definition of pinMode(pin, mode); LIES where pin MUST be a value. which I don't believe THEN  AND I DO BELEIVE the #define is not being substituted at compile time. !!!!!

I have never had a problem with a #define macro in a .h file and pinMode() called in setup() or any other function using those macros.

However, you can never have pinMode() outside of a function call.

So, if you're calling pinMode() -- which is a function -- from inside of a function, then the #define macro should be replaced during pre-processing. If not, something else is going on. And in that case, it is starting to feel like our old friend: code snippets rarely contain the actual problem.

phoenixcomm said:

THEREFORE either the definition of pinMode(pin, mode); LIES where pin MUST be a value. which I don't believe THEN  AND I DO BELEIVE the #define is not being substituted at compile time. !!!!!

I have never had a problem with a #define macro in a .h file and pinMode() called in setup() or any other function using those macros.

However, you can never have pinMode() outside of a function call.

So, if you're calling pinMode() -- which is a function -- from inside of a function, then the #define macro should be replaced during pre-processing. If not, something else is going on. And in that case, it is starting to feel like our old friend: code snippets rarely contain the actual problem.

bald engineer said: "

baldengineer said:

However, you can never have pinMode() outside of a function call.

which in my heart of hearts say this is idiotic as pinMode() by itself is a function... so why have a function in a function duh.... and where does it say this.

and you can get rid of loop and setup:

take a look at this: www.youtube.com/watch

here is my current code which  runs..

void setup() {
  //Pin Modes
pinMode(rxPin, INPUT);
pinMode(txPin, OUTPUT);
// Digital Ports
pinMode(RST_1, OUTPUT);
pinMode(RST_2, OUTPUT);
pinMode(CE_1, OUTPUT);
pinMode(CE_2, OUTPUT);
pinMode(CLK_1, OUTPUT);
pinMode(CLK_2, OUTPUT);
pinMode(RD_1, OUTPUT);
pinMode(RD_2, OUTPUT);  

// Setup & Open serial communications and wait for port to open:
  Serial.begin(115200);
// I2C setup 
// port A - DATA BUS
  Wire.beginTransmission(0x20);
  Wire.write(0x00); // IODIRA register
  Wire.write(0x00); // set all of port A to outputs
  Wire.endTransmission();
// port B - ADDRESS BUS
  Wire.beginTransmission(0x20);
  Wire.write(0x01); // IODIRB register
  Wire.write(0x00); // set all of port B to outputs
  Wire.endTransmission();  
}
int main() {

}

and I am using my own: main function. 

phoenixcomm said:

here is my current code which  runs..

But there you call pinMode() from within the setup() function.

phoenixcomm said:

which in my heart of hearts say this is idiotic as pinMode() by itself is a function... so why have a function in a function duh.... and where does it say this.

 This line is executable code, it calls the pinMode function with a few parameters:
    pinMode(rxPin, INPUT);

 baldengineer  suggested that you should be calling that pinMode() function only from within a function. You're not creating or defining the pinMode function, in which case then yes you'd put the new function definition wherever you want it.

I'm pretty sure it says that in the standard C rules - you can't run executable code outside of a function, except (maybe?) when initializing global variables. Or at least, you shouldn't really be doing that. I think most compilers will throw errors for that case.

When you #include a header file, you essentially copy all of that file into that spot in the file that is including it, so your first example, including pins.h does something like this, which places the executable code (the pinMode function call) outside of any function:

// start of file
#define rxPin 0

pinMode(rxPin, INPUT);  // <- this is not valid

setup() {

}

loop() {

}

I'm pretty sure that's standard C, not specific to Arduino. In any case, if it was allowed by the compiler, it would not be clear when that line of code would be run, and as Shabaz mentioned below, when you start depending on compiler-specific details like that, the code becomes less portable to other platforms, and less readable to other programmers.

I know Arduino adds a few twists with the execution start point being hidden and then calling setup() and loop() from that hidden area, and I don't know what else it's doing - maybe there's some general board-specific setup it does. I'm happy enough to keep that black-boxed out of sight
I find just living within those game rules the rest of it makes sense enough. Anyone wanting to get more control would probably be better off using the professional tools instead.

I hope that helps