next topic »

[on:]

This sketch just sends out some ascii one's as a test stream - it's running on a breadboarded 168

Code:

#include <NewSoftSerial.h>
#define rxPin 18
#define txPin 19
NewSoftSerial mySerial(rxPin, txPin);
void setup() {
  mySerial.begin(9600);
  mySerial.print("1111111111");
}
void loop(void) {
}

This code catches the software serial stream and passes it to the PC over the hardware uart & USB - it's on a diecimilia 328.

Code:

#include <NewSoftSerial.h>

#define rxPin 2
#define txPin 3

// set up a new serial port
NewSoftSerial mySerial(rxPin, txPin); //(rx,tx)

void setup()  {
  // define pin modes for tx, rx, led pins:
  pinMode(rxPin, INPUT);
  pinMode(txPin, OUTPUT);
  // set the data rate for the SoftwareSerial port
  mySerial.begin(9600);
  Serial.begin(9600); //start the hardware UART as well
  Serial.println("Software Serial to Hardware Serial Relay");
}
void loop() {
  // listen for new serial coming in:
  if (mySerial.available()){ //if there's new data in
      char someChar = mySerial.read();
      Serial.print(someChar); //send it to the PC
  }
}

By the time it gets to windows the characters are mangled insead of ascii "1"s I'm getting someling like hex C5 C5 8A 8A 8A 8A 8A 8A 8A 8A FE

The only thing I can think of is that the internal timing of the breadboard processor is too sloppy but before I start ripping the hardware up I thought I'd ask if anyone can see something else I've goobered.  I know I've used software serial before at higher data rates on a breadboard with no problem.

[Reply #1 on:]

This sketch just sends out some ascii one's as a test stream - it's running on a breadboarded 168

Code:

#define rxPin 18
#define txPin 19

Why are you not using digital pins?

Code:

  pinMode(rxPin, INPUT);
  pinMode(txPin, OUTPUT);
  // set the data rate for the SoftwareSerial port
  mySerial.begin(9600);

You want software serial to control the pins, right? Don't go mucking with the pin mode, then.

Is your breadboarded 168 using a 16MHz crystal/resonator?

[Reply #2 on:]

Why are you not using digital pins?

19  was what I had left!  I can try one of the standard digital pins if you think it matters. 18 was floating by the way which I suppose might matter.

You want software serial to control the pins, right? Don't go mucking with the pin mode, then.

I've seen examples with and without the pinModes and I've tried it with and without - and with and without external pullups.

Is your breadboarded 168 using a 16MHz crystal/resonator?

No! that's why sloppy timing is a suspect.  I'm pulling the hardware apart now to add a crystal controlled board.  I'll just be kicking myself if the problem is still there.

[Reply #3 on:]

18 was floating by the way which I suppose might matter.

How could it be floating is SoftwareSerial was controlling it?

No! that's why sloppy timing is a suspect.

What frequency are you using? Are you specifying the correct rate in the boards.txt file?

[Reply #4 on:]

18 was floating by the way which I suppose might matter.

How could it be floating is SoftwareSerial was controlling it?

No! that's why sloppy timing is a suspect.

What frequency are you using? Are you specifying the correct rate in the boards.txt file?

the breadboard is running at 8mhz on the internal timer - it's selected as a lilypad 168 in tools/board.  I'm pretty sure that's right and i have tested its hardware serial - not lately I have to admit.

18 was floating in that it's not connected externally.

I'm now swapping in a crystal controlled board and i'll see what happens.

[Reply #5 on:]

ok, hard to be sure because I had to rearrange and redo a bunch of wiring but I think the problem was cured by using a crystal controlled chip.

Thanks PaulS

Most importantly, by doing the rewiring I found the misconnection that was driving me to want the double serial connection in the first place!