No experience with software serial but I'm sure you can use the same principles from the Serial Input Basics thread. I also have no idea about GSM shields but I guess they
Using approach 2,
Mega receives from PS2
Mega sends to Uno
Uno sends to GSM shield
GSM shield sends to UNO
UNO sends status to Mega (success or failure).
Mega displays status
Note that if you have multiple communication paths (e.g. hardware serial and software serial), you basically need to implement buffers ('receivedChars'), flags ('newData') and functions (rcvWithEndMarker') for each of them.
sterretje:
No experience with software serial but I'm sure you can use the same principles from the Serial Input Basics thread. I also have no idea about GSM shields but I guess they
Using approach 2,
Mega receives from PS2
Mega sends to Uno
Uno sends to GSM shield
GSM shield sends to UNO
UNO sends status to Mega (success or failure).
Mega displays status
Note that if you have multiple communication paths (e.g. hardware serial and software serial), you basically need to implement buffers ('receivedChars'), flags ('newData') and functions (rcvWithEndMarker') for each of them.
Okaaaayyyy... But lets say I send receivedChars from the mega to the uno. On the uno side, do I just make a receivedChars2, and assign SoftwareSerial.read to receivedchars2, just once? (Since all the chars are comming in one buffer (recievedChars) at the same time?)
Why would you make a receivedChars2 on the Uno? The Uno is independent of the Mega so it does not know anything about the code on the Mega so you can call it receivedChars as well (receivedChars2 would indicate to most programmers that there is also another receivedChars like receivedChars1.
Or are you using receivedChars already for something else on the Uno (e.g. comms with the gsm shield)? If so, it's time to start thinking about names that make more sense.
sterretje:
Why would you make a receivedChars2 on the Uno? The Uno is independent of the Mega so it does not know anything about the code on the Mega so you can call it receivedChars as well (receivedChars2 would indicate to most programmers that there is also another receivedChars like receivedChars1.
Or are you using receivedChars already for something else on the Uno (e.g. comms with the gsm shield)? If so, it's time to start thinking about names that make more sense.
I just thought that it would be less confusing to have recievedChars2 on the uno, considering that recieveChars is already on the Mega
It's best if you re-use as much code as possible on both sides of the link. In the best case, the code is identical on both, even if they have different Arduino boards. I've got software that has a Teensy talking to a Due and it's the same exact code on both sides.
That way when you change something, they are either both using the same library or it's a simple copy-paste between the two sketches.
'receivedChars' is just a name that was convenient for the Serial Input Basics thread. If you have multiple communications paths (as you do; on the mega, PS2 and serial to Uno) you should actually rename those variables so they reflect their purpose. I usually call my receive and transmit buffers e.g. rxBufferXXX and txBufferXXX where XXX indicates the purpose.
In your Mega code, I would use rxBufferPS2 (stores characters received from keyboard) and e.g rxBufferGSM (stores characters received from Uno-GSM unit). In your Uno code, you can have a rxBufferMaster (stores characters received from the master device (Mega)) and a rxBufferGSM (stores characters received from the gsm shield).
The same applies to the flag (newData) and the functions.