Go Down

Topic: Arduino to Arduino Serial Communication (Read 792 times) previous topic - next topic

Aluman000

Ok,

This seems so simple but I just can't get it to work.
I've tried buffers and subtracting '0' and looking for '/n' and about 100 other ways to get serial communication to work.
I've tried to use .print, .println, and .write.  Nothing seems to work.
I simply am stuck.
So Please, any help.

Ok, I have 2 Uno R3s connected from pin2 to pin3.
All I want to do is send a number from one to the other.
here's my code on the sending station:
Code: [Select]
#include <SoftwareSerial.h>

SoftwareSerial DirectConnect(2,3);

int i;

void setup()
{
  Serial.begin(57600);
  DirectConnect.begin(57600); 
} // Setup

void loop()
{
 
   
  for ( i = 1; i <= 100; i++)
  {
   
   DirectConnect.print(i);
   Serial.println(i);
   delay(50);
   
  }
 
} // Loop


and here's my code for the receiving station:
Code: [Select]
#include <SoftwareSerial.h>

SoftwareSerial DirectConnect(2,3);

int RecVar;
void setup()
{
  Serial.begin(57600);
  DirectConnect.begin(57600); 
} // Setup

void loop()
{
  delay(50);
   
  if(DirectConnect.available())
  {
   
    RecVar = DirectConnect.read();
   Serial.println(RecVar);
   
  }
 
} // Loop


This is vastly simplified from the functions I really want to do, but I just can't get this to go.

retrolefty

Quote
Ok, I have 2 Uno R3s connected from pin2 to pin3.


So pin 2 on one arduino wires to pin 3 on the other, then 3 to 2, that's how it has to be. Also you require a ground wire between the two arduinos.

tuxduino

I would remove those delays() and lower the softserial baud rate to 4800.
Also notice that print(i) will output 1 to three ascii chars, while read() will return just one byte at a time.

As a transmission test sketch I'd use something like this:

void loop() {
  static char ch = 'A';
  softserial.print(ch);
  ch++;
  if (ch > 'Z') {
    ch='A';
  }
]

so you can see if the receiving end misses a beat.

my 2 cents.

Nico V

This may be just me, but I'd send the data in a binary format so you know how many bytes to expect and don't have to do any parsing.

Like:
Code: [Select]
// Sender
DirectConnect.write((byte*)&i, sizeof(i));

// Receiver   
DirectConnect.readBytes((char*)&RecVar, sizeof(RecVar));

(gotta love the type inconsistencies, write takes a byte ptr, read takes a char ptr...)

If you are communicating between different kinds of devices (eg between Arduino and a PC) you need to think about the endianness but I'd still prefer binary over plain text every time. The only drawback is that the serial monitor becomes pretty useless.

But seeing as you don't seem to be getting any data whatsoever, I'd say your main problem is likely the stuff retrolefty suggests.

Aluman000

Here's what my Serial Monitor returns.
Though I don't have a ground wire between them.
How do connect that?  Just Ground to Ground? or is there a different pin + command I should use?

Code: [Select]
54
183
134
133
54
145
134
133
54
183
134
133
54
145
134
133
54
151
134
133
54
177
134
133
54
183
134
133
54

retrolefty

#5
Nov 15, 2012, 08:03 pm Last Edit: Nov 15, 2012, 08:10 pm by retrolefty Reason: 1
Quote
Here's what my Serial Monitor returns.
Though I don't have a ground wire between them.
How do connect that?  Just Ground to Ground? or is there a different pin + command I should use?


Well first you have to better describe how the two arduinos are presently wired together and powered. So as your using the serial monitor that means that one of the arduinos is hooked via a USB cable for power and hardware serial data link to the IDE serial monitor, correct? How is the other arduino being powered? What wires are you presently running between the two arduinos, pin(s) what on one board to pin(s) what on the other board? And yes wiring a common ground between the two arduinos is just a matter of having a single wire run from one of the shield ground pins to another shield ground pin on the far arduino. If however both arduino boards are wired to the same PC via their USB cables then there would be no need for a separate common ground wire to be run between the two boards.

Lefty

Aluman000

Ok, no luck really.

First my full setup.
I have a Sending Station:
Uno R3
Powered by wall plug adapter
1 wire connecting the 3 pin to the 2 pin on the Receiving Station
1 Wire connecting the GND to the GND on the Receiving Station

I have a Receiving Station:
Uno R3
Powered via USB to computer
Connections as described above

No other connections on either Station.

The new Serial Monitor output looks like this:
Quote
56
57
57
57
57
57
57
57
57
57
57
49
49
50
51
52
53
54
55
56
57
55
55
56
56
56
56
56
56
56
56
56
56
57
57
57
57
57
57
57
57
57
57
49
49
50
51
52
53
54
55
56
57
54
55
56
57
49
48
49
49
49
50
49
51
49
52
49
53
49
54
49
55
49
56
49
57
50
48
50
49
50
50
50
51
50
52
50
53
50
54
50
55
50


Different, but still doesn't look like 1-100 repeating. 
Even if it's giving the ascii equivalent of the char they don't repeat properly, I don't think. 
I would expect every 3rd value to be the 'end' value.

Nico V

Those are indeed the ascii values for the digits 0-9. You're not seeing any 'end' characters because you're not sending any. You are only sending digits in plain text form, and reading them as bytes.

If you remove the 50 ms delay on the receiving side, you'll probably get a consistent stream at least.
Right now your sending side is sending up to 3x more than the receiving side can keep up with because of that delay you put in there.

tuxduino

println(i), where i goes from 0 to 100, outputs 2 to 4 chars, depending on i value.

Nico V


println(i), where i goes from 0 to 100, outputs 2 to 4 chars, depending on i value.

It's 3-5 ;) It sends \r and \n after the digits.
But he's using print() and not println() for the software serial connection.

tuxduino



println(i), where i goes from 0 to 100, outputs 2 to 4 chars, depending on i value.

It's 3-5 ;) It sends \r and \n after the digits.


Ouch! You're right.  :smiley-roll-sweat:



But he's using print() and not println() for the software serial connection.


Damn, you're right again; println() is on the hw one...

I'd better get some sleep... :P

Go Up