I need one Arduino to tell another Arduino to do something. Both are Mega 2560 boards. I know that SDA and SCL pins are to be used for this purpose, but one of the boards already have them in use with an Adafruit servo driver. I need only three digital pins.
I know the master board should use those pins as OUTPUT and set them to HIGH or LOW accordingly. But what about the "slave pins"?
If the slave pins are set to INPUT_PULLUP, they will be HIGH unless I put them to ground, how to do it from another Arduino?
Should I set them just as INPUT? Will they be LOW or HIGH matching the master pins to which they will be hooked?
rva1945:
I know that SDA and SCL pins are to be used for this purpose, but one of the boards already have them in use with an Adafruit servo driver.
That's not a problem if it's the master Arduino that already uses them. Simply also connect it to the other Arduino and set it up for I2C slave with a different address then the servo driver.
rva1945:
If the slave pins are set to INPUT_PULLUP, they will be HIGH unless I put them to ground, how to do it from another Arduino?
digitalWrite(pin, LOW)....
rva1945:
Should I set them just as INPUT? Will they be LOW or HIGH matching the master pins to which they will be hooked?
If you are 100% sure they will be hooked to each other all the the time INPUT of INPUT_PULLUP doesn't matter. Otherwise INPUT_PULLUP (with the pin begin HIGH meaning "do nothing") would be a saver option.
But I would add a series resistor of around 10k to stop phantom powering the other Arduino and in case you accidentally set the pin to OUTPUT on both Arduino's.
rva1945:
SCL and SDA pns are in use in the slave, that's why I can't use them.
Still possible but it is indeed a little bit harder. It's called multi master
rva1945:
So if he slave pins are set to INPUT_PULLUP and already hooked to master pins from the other board, they wll have the same state as the slaves'?
Yeah, of course. That's the whole idea of a input (set to INPUT or INPUT_PULLUP). If you apply a voltage the pin has the corresponding state.
But don't forget about the advice about a resistor
rva1945:
But isn't the resistor necessary only if the pins are set as INPUT, which leaves them in an unstable state with its high impedance?
I said in series, not as a pull up/down resistor
rva1945:
I can be sure I will not set both pins (master & slave) as OUTPUT, but what happens at power-up, even for a fraction of a second?
But, can you be sure both slave and master always turn on at the same time? That's the other reason for the resistor.
And on start up, that's why I said INPUT_PULLUP is more save. If the master didn't start yet this will pull the line to a known state HIGH and you say HIGH mean do nothing. And while you didn't set INPUT_PULLUP yet (at start up) you are also not going to read it so the state doesn't matter
Anyway, I keep track of the state change in order to avoid doing the same task when not needed, so regardless of the pin state, HIGH or LOW, I know what to do inside the code.
The master board controls 4 locomotives in a DCC layout. The other (slave) board reads 14 switches and controls the turnouts. What I want is that, in AUTO mode, the master will read 4 magnetic sensors (reed relays) and decide what to do with two specific locos, while at the same time "telling" the slave to drive two turnouts accordinglyto avoid crashes. That is all.
rva1945:
Anyway, I keep track of the state change in order to avoid doing the same task when not needed, so regardless of the pin state, HIGH or LOW, I know what to do inside the code.
But that's once it's running. It has to start in some state. If you use a pull up (being it external or internal) you know it starts high when no master is "talking".
Hehe, I'm a train guy as well (A). But it sounds a bit prone to extending it So I think you're better of with some sort of real communication. Am I correct to say the master (that controls the DCC) needs to get some info from the slave (that reads the switches)? And that master or the slave that has the servo driver?
If it's the slave that has the servo driver and that slave needs to give info to the master you can still use I2C. Just make the slave a I2C master and the master a I2c slave (whaa, almost confusing) and send that data from slave to master periodically (let's say once or twice a second) and the master now can save it for when it needs it
And even when the master needs to talk back, the slave can just ask the master with the same interval if the master wants to say something back.
I'm not sure if I can use serial communication as it depends on the internal clocks (or am I wrong?).
And in one of the Arduinos I'm running a code that "hacks" the clocks for producing a specific signal (DCC in model trains world), so for example delay() gives different time lenghts.
rva1945:
I'm not sure if I can use serial communication as it depends on the internal clocks (or am I wrong?).
Yeah so? Biggest disadvantage of Serial is that it's also used by the connection to the pc (for both programming and debug/serial monitor).
rva1945:
... I'm running a code that "hacks" the clocks
No you don't You use the timers in the Arduino to make the DCC signal. And the timers are driven by the system clock. The system clock is set by the (external) crystal (/resonator) on the Arduino. (and some registers if you want to use the internal resonator). But you don't change the clock
But do you really need all 6!!! timers on the Mega to make the DCC signal?
septillion:
Yeah so? Biggest disadvantage of Serial is that it's also used by the connection to the pc (for both programming and debug/serial monitor).
No you don't You use the timers in the Arduino to make the DCC signal. And the timers are driven by the system clock. The system clock is set by the (external) crystal (/resonator) on the Arduino. (and some registers if you want to use the internal resonator). But you don't change the clock
But do you really need all 6!!! timers on the Mega to make the DCC signal?
Well maybe "hacking" was an exaggeration by my side, didn't mean that!
I think it uses only two timers to make the DCC signal. Ok, so? I find reference on how to send/receive serial data but nothing about how it is affected by altered timers. Anyway the impossibility of debugging as serial is used by the connection to the pc makes me think twice.
The work hacking wasn't the problem. It was about you confusing the clock with the [/b]timer/counters[/b]
And if you only use 2, why do you use timer0? That's the only timer that's by default doing stuff (other then PWM). It is the timer responsible for millis() and delays() (on which Serial does NOT rely). The other 5 timers are absolutely free. So if you switch the task you now do with timer0 you get all the timing functionality back
rva1945:
but nothing about how it is affected by altered timers.
It's not, it's affected by the system clock that's use so affects it.
rva1945:
Anyway the impossibility of debugging as serial is used by the connection to the pc makes me think twice.
Mm, not completely. Because in my last answer I forgot about you using Mega's. Those have 4 serial ports of which only one is used by the pc. Leaves you with 3 you can use
And you still have the I2C and SPI options as well
septillion:
Yeah so? Biggest disadvantage of Serial is that it's also used by the connection to the pc (for both programming and debug/serial monitor).