I have 3 software serial ports.
2 only send data.
1 only receives data.
The issue I am having is that if I write data to one of the send only serial ports, it causes garbage to show up when I am receiving on the receive only port
They are all using different pins, (3,4), (5,6), (7,8)
I understand that you can only receive on 1 software serial port at a time, and I am only issuing a listen command to the one port....
Any ideas of what is going on here?
The issue I am having is that if I write data to one of the send only serial ports, it causes garbage to show up when I am receiving on the receive only port
Any SoftwareSerial method call will make the instance that the method was called for the listening instance. Expecting some other instance, in some mysterious code, to correctly receive data is unrealistic.
WHERE IS YOUR CODE?
Is having an address byte on the start of the message not an easier idea?
Tx code is psuedo and missing loads of stuff...
byte tx1 = B00000001
byte tx2 = B00000010
byte tx3 = B00000011
Serial.print(tx1);
delay(50); //May be required...dunno.
Serial.print("Some data intended for the rx to read and place in a char array called rx1[]");
Rx code...psuedo and missing loads of stuff.
char rx1[6]; //Make an array of a known size...can always make an "unlimited" and close it with a null terminator later
if (Serial.available>0){ //If there is some data to read on the tx line
if (serial.read==B0000001){
for (int i=0; i<sizeof(rx1);i++){
rx1[i]=Serial.read;
}
}
PS. I am bad at coding...but maybe this is easier and frees up some pins?
You may need to have the Rx send some kind of "Ummm...what!?" when it gets a first byte that is not equal to B00000001, B0000011, or B00000010...like an ACK kinda idea.
PaulS:
Any SoftwareSerial method call will make the instance that the method was called for the listening instance.
I don't think that's true for the write() method.
I suspect the problem is that while you sending data SoftwareSerial has interrupts disabled 95% of the time, so it misses the incoming data. It's not a full duplex implementation. If you need that take a look at AltSoftSerial.
Also, you don't have to waste those three pins. You could do it this way:
ss1(RX_pin, TX_1_pin);
ss2(RX_pin, TX_2_pin);
Then use the second one, ss2, as the receive object and ss1 and ss2 as the two transmitters.
That's a neat idea. I will try this. Thank you!
From looking online, I had thought the only limitation was that you could only listen on one port at a time. As I am learning, it is a lot more complicated than that.
jboyton:
I don't think that's true for the write() method.I suspect the problem is that while you sending data SoftwareSerial has interrupts disabled 95% of the time, so it misses the incoming data. It's not a full duplex implementation. If you need that take a look at AltSoftSerial.
Also, you don't have to waste those three pins. You could do it this way:
ss1(RX_pin, TX_1_pin);
ss2(RX_pin, TX_2_pin);Then use the second one, ss2, as the receive object and ss1 and ss2 as the two transmitters.
The thing that the Arduino documentation doesn't go into is the "blocking" nature of SoftwareSerial. When either sending or receiving it disables interrupts for at least 95% of the time. So doing both simultaneously isn't going to work.
AltSoftSerial is a full duplex solution, but it has certain limitations as well. At some point a UART will make your life a lot simpler.
Yes, thank you for the explanation on that. I figured there had to be something more to it.
I had actually lobbied to move up to the 2560 much earlier in the project design phase so we would have room for future features, but the request was denied, and now at the last minute I have found out I need to access data from an additional new input source, so while I would love to use one of the extra hardware serial ports on the 2560, I have no choice but to use software serial on the ATMega328 (32 pin version).
jboyton:
The thing that the Arduino documentation doesn't go into is the "blocking" nature of SoftwareSerial. When either sending or receiving it disables interrupts for at least 95% of the time. So doing both simultaneously isn't going to work.AltSoftSerial is a full duplex solution, but it has certain limitations as well. At some point a UART will make your life a lot simpler.
It would have made more sense to choose a board with the components you needed. But you may still be able to get it to work. It kind of depends on what your sending/receiving and how fast.
AltSoftSerial will help. I think it only supports one TX pin although I'm not sure about that. It also uses timer1 which would be a problem if you need it for something else.
You could also use the UART of the Uno. It's a little bit of a bother since it's also used for uploading sketches and serial debugging. But those obstacles aren't insurmountable by any means.
It would be easier with a Mega.