more Arduino silliness.

Hi Cris,

It might be because the first line is defining RST_1, but the second line is defining it a second time, i.e. it states RST_1 on the second line too, where it should be RST_2 I guess.

However, the error text doesn't help as much as it could.

Incidentally, some IDEs will detect this as it is typed, and flag it as an error before compilation. With CLion, if I try to do that, I see this:

It automatically shades the second 'BOB' to indicate an issue. If I hover over it, then it states the reason, sometimes in a better way than a compiler:

I guess Arduino code could be typed in CLion first, and then copy-pasted into the Arduino IDE, or perhaps it allows a different editor to be used.

CLion is not free unfortunately though, so this isn't an option always, but just mentioning it in case there are other IDEs with this sort of capability too, that people may be aware of.

Love Abbott & Costello!

I believe NexGen is trying to find a convient way to set the pinmode in a header file, Im not sure of the answer...

Right, you can't (or at least shouldn't) be running executable code in a header file.

So in addition to the RST_1 being defined twice, maybe the goal is to also #define the pinmode() calls to reduce it down?

Hi phoenixcomm ,

As shabaz pointed out, RST_1 is double defined, but in addition, if this is all in the .h file, then you shouldn't have the pinMode calls directly there.

If the goal is to shorten the calls into a define, you'd have to #define it the same way, something like:
#define SETUP_RST_1 pinMode(RST_1, OUTPUT)

and then in setup() you'd call it as follows:

setup() {
   SETUP_RST_1;
}

However, I don't think that really cleans up your setup() function much, and it's a bit hokey. And you end up typing more stuff overall.
I would recommend not using #define for that purpose. Maybe use a second C file to hold the setup commands? Or just put those pinMode functions down lower in the main sketch file in a separate function. Then your setup function would look more like:

setup() {
   setup_all_pins();
}

(I also recommend a better name - one that matches the purpose of those pins a bit better.)

If you like even cleaner code, I think object oriented might be worth a look. Encapsulate all the functionality of a given thing into a separate file, and then from the main file just initialize it and call functions on it that do only what you need in the main sketch.

For example, consider my thermistors sample. The attached zip file contains the sketch (for a Wemos D1 Mini), with the Thermistor object.
I keep the thermistor object in the separate Thermistor.cpp and Thermistor.h files, and in the main sketch I just set up each thermistor with a single line as follows:

            //    pin, R_nom, Nom_temp, Beta, divider_resistor
Thermistor therm6(A0, 5000, 25.0, 3892, 10000);

And to grab the temperature in the loop() of the sketch, it’s also just one line:
   float temp6 = therm6.getTemperature();

And it’s easy to repeat as often as you like - each is a separate object that takes care of its own variables, its own setup, its own pin handling, its own math... so you don’t even have to keep all of that straight in your main sketch - ie, no arrays of numbers upon arrays of numbers for all of their settings. No carrying of extra functions to do all the thermistor-specific math. Once you have the object built and tested, the rest is just neatly tucked out of sight. And reusability becomes trivial - just copy and paste the object files.

its a typo.

Oh, I missed that bit of the question. I can't think of better options than what Nico suggests either. Either a nice setup() or init() type of function, or the OO method with each defined class implementing its own initialization code. Technically the latter in C++ allows the code to reside in the header file if that's really desired, but whether that is good practice or not for this scenario, is another issue (personally I would put it in the C file).

Ntewinkel is right.  Another way of looking at it, depending upon where in your C file you include that header, is you are trying to run code outside of a function, whether that is setup(), loop(), main(), anoFunction().  You can put code in an include file, along with the pin definitions as long as the include statement is placed inside a function.  HOWEVER, you must be aware of the ordering of code when the compiler processes all this: if it finds a reference to RST_1 before it has been included it will throw an error.

That's what I normally do, though the my setup function ends up being a monster having to deal with input versus output, pullups, analog select, peripheral mapping, interrupts, clocks, etc etc but the Arduino environment takes care of most of that for you. Microchip provides structs with bitwise access for all their peripherals the same could be done on any mcu platform for example

typedef struct tagPORTABITS {
  uint16_t RA0:1;
  uint16_t RA1:1;
  uint16_t RA2:1;
  uint16_t RA3:1;
  uint16_t RA4:1;
} PORTABITS;
extern volatile PORTABITS PORTAbits __attribute__((__sfr__));

/* PORTA */
#define _RA0 PORTAbits.RA0
#define _RA1 PORTAbits.RA1

So to write to a gpio pin,

_LATA0 = 1; // of course you can add a custom define for _LATA0...

If its an input you would read from the port input, if its an output you would write to the output latch

andrew j yes but the #define #typedef and the such are handled be the PRE-PROCESSOR which means If my defines are in global space EVERYBODY see them.  I understand compiles / interpreters very well as I have written a few in my time. pleas see my next comment you'll like it.