is there any other code elsewhere in the standard firmata code instead that i can modify to change its initial state?
What's wrong with what you are doing?
I would think it would be better to leave the standard firmata sketch alone, and ensure that the application that is talking to the Arduino tell the Arduino to turn the appropriate pins HIGH.
because with my method, upon powering up-
-all the pins will alternate to LOW first, (switching on all my attached relays from a 8 relay board i bought)
-and then go to HIGH with my function (switching them off again, as they should be in their resting state, when no power (usb) is plugged in at all).
this creates an alternating effect that i would like to avoid. if the firmata default state was high, no alternation would take place and the problem would be solved.
There is still going to be a time before the setup() function sets the pins HIGH where they are LOW.
Why do your relays come on with a LOW pin? Since the default state of the pin is LOW, I'd think the relay should activated only when the pin goes HIGH.
I found this topic on google so I will post a brief summary what I did.
I have same kind of relay card that switches on with LOW pins. The solution was to connect the +5V power input of the relay card to one digital output pin of my arduino. Relay power can be seperated in my relay card, so it is connected to external power of course.
So when I boot my arduino I can first set all relay pins to HIGH and then the relay card power to HIGH and relays won't switch on until I want them to.
It would seem you are right. If I understood the source correctly, Firmata initializes all digital pins as OUTPUT LOW. Hard to believe, as this seems like a silly thing to do... My understanding is that:
setup() calls systemResetCallback() in order to set the initial pin configuration (line 779)
systemResetCallback() loops over all pins and calls setPinModeCallback(i, OUTPUT) for every pin i that is not an analog pin (line 732)
setPinModeCallback() calls pinMode() to set the pin to OUTPUT (line 325).
If my understanding is correct, then the simplest solution would seem to patch systemResetCallback() and replace OUTPUT by INPUT on line 732.