Hello,
Is it possible to send AND receive data between two arduinos?
I am getting and processing data (20 sensors) on one, and have another coupled with ethernet shield that populates database and getting input from web page. I would need so send a lot of data for web representation and debugging to the second board, but also be able to send commands from web to the first one..
Welcome, yes it is possible. Lots of communication protocols available. Ask a moderator to move your thread to a more appropriate section using the flag icon
Very possible - consider a NRF24 for example.
Welcome to the forum
Your topic was MOVED to its current forum category as it is more suitable than the original
It has nothing to do with Installation and Troubleshooting of the IDE
Yes, sorry, i am natural blond,
Thank you for creaning after my fault.
Thks
TK
I suggest you start here: Serial Input Basics - updated
No, it must be serial. i have all taken - spi, onewire etc First board has more wires than monk's head has hair.
I don't trust wireless,
have rx/tx free
Actually the question is for serial communication and is global and is not explicitly answered on internet.
Can a board be master and slave? How to do it if yes.
1 Like
Which type of boards are you using ?
Due
I can't help with that - not a lot of experience with this. I prefer wireless for myself.
There is no 'master' or 'slave' with serial, other than what you define in your code. You just send stuff on Tx and the other board receives it on its Rx. If you want to make one board the master you can, but that has nothing to do with how serial works. I suggest you study the tutorial, write some code and come back to this topic* if you get stuck.
*Please don't start another topic, the context of what has been said here will be useful in providing more help if you need it.
Where are you stuck ?
Connect the 2 boards with Rx and Tx crossed, Serial.print() or Serial.write() from one and when data is available on the other one read it, parse it and act on it
What have you tried so far ?
You will need to invent your own data protocol so that you can parse the data received on the second board
See Serial input basics - updated for some ideas
You have fallen into a common trap: it would be a mistake use two Arduinos. If you used only one, you would not need to be concerned about how to communicate between the two Arduinos, and this would make your code easier and more bug-free.
There will be ways to connect everything to a single Arduino, and this is what you should be asking for help with
2 Likes
Ok, i'll try
I gave a clear answer in post 2. Yes it is possible.
The following answers give you some information about how you might do it and then why you might chose a different route.
If you don’t get the answers you feel you want maybe rephrase the question
Yes.
Thanks, true, you said it.
How to do it will be a natural consequent question 
I will try to learn about serial communication, will take me a while
Thought of encapsulating sending data and receiving data in separate functions, but how to "time"it togerther without stopping the rest of the code (300 lines..)
many questions..
Look into using millis() for timing and read about state machines.
The Due, like the Mega, has three spare Serial ports
There is a Serial comms example in the IDE for the Mega (Serial <> Serial1), which might also work for the Due.
Why a 3.3volt-logic Due.
Are all your sensors 3.3volt-logic
He might have that wisdom from all the others before you trying to use two processors.
You basically only do that when there is some distance between them.
Otherwise port expanders (if you run out of pins) is the way to go.
You did mention one-wire (only one pin for many sensors) and SPI (a bus that you can share with other sensors). Please explain why you even need to use a Due.
Leo..
Take @UKHeliBob's advice and hook up a serial port on each Arduino. The simplest example I've seen to get started is transmitting single characters. Send an 'H' and the other Due lights up it's built in LED. Send 'L' to turn it off.
That'll be your introduction to parsing. Your real protocol will of course be significantly more complex.