next topic »

[on:]

I m trying to use it on a GPS on a Pro Mini and it wasn't working with a simple test (code below) so I tried looping back pin 2 to 3 to see if got anything. I did not. I added a diagnostic to echo it it back and that works when I enable it so the Serial is working.

Code:

#include <NewSoftSerial.h>
#define rxPin 2
#define txPin 3
#define ledPin 13

boolean ledState = false;
int counter = 255;            // To slow down the LED blinking
byte incomingByte = 0;

NewSoftSerial nss(rxPin, txPin);

void setup()                    // run once, when the sketch starts
{
  Serial.begin(9600);
  nss.begin(9600);
  pinMode(ledPin, OUTPUT);      // sets the digital pin as output
  digitalWrite(ledPin,ledState);
  delay(2000);
}

void loop()                     // run over and over again
{
  
// Blink the LED on pin 13 just to show we're alive

  if (counter > 0) {
    counter-=1;
  } else {
    ledState = ! ledState;
    digitalWrite(ledPin,ledState);
    counter=255;
  }

// Read from the hardware UART.
// If any data is available, write it out through the software serial

  if (Serial.available() > 0) {
    incomingByte = Serial.read();
   //Serial.print( incomingByte, BYTE);
    nss.print(incomingByte);
  }

// Read from software serial.
// If any data is available, write it out through the hardware UART
  
  if (nss.available() > 0) {
    incomingByte = nss.read();
    Serial.print(incomingByte);
  }

  delay(1);                  
}
 

[Reply #1 on:]

It's not possible for any Software Serial to send and receive at the same time.

[Reply #2 on:]

I wondered about that. I thought NewSoftSerial used interrupts and hoped it would get samples while sending.

[Reply #3 on:]

Nope.  It can do one or the other but not both at the same time.

[Reply #4 on:]

In the old days we would have decribed it as half-duplex only Vs full-duplex capablity. There I go showing off my age again, do get off my lawn.  ;D

Lefty

[Reply #5 on:]

I think a lot of what I like about the Arduino is nostalgic. I did a lot of firmware in the early 80s. I dealt with the duplex issue and parity and all that nonsense. I had one project where we used parity in SDLC because we could slow the transmission rate slightly instead of cutting it in half. The processor could not keep up at full speed, but half speed wouldn't do the job.

That acronym showed my age not long ago when I was interviewing a young guy and he had SDLC mentioned as something he had used on his resume. I asked him about it. It turns out he did not mean Synchronous Data Link Control, he meant Software Design Life Cycle.

While I was checking voltages, I accidentally caused a little grabage to get sent to pin 2 and it was recieved and sent to Serial, so I think I just don't have the GPS sending.

[Reply #6 on:]

A bit of explanation might be useful here.

The way NewSoftSerial works is that when you want to transmit a byte, the processor wiggles the TX pin according to a very precisely timed pattern.  Similarly, when the interrupt signals the start of a received byte on RX, the processor loops at full speed timing the incoming wave form.

Since both RX and TX are so sensitive to timing, interrupts are disabled for the duration of the entire byte in both cases.  This means that even if for no other reason, software serial loopback can't work because by the time interrupts are re-enabled after the byte is completely transmitted, it is far too late for the receiver to process the RX interrupt.  The bits are long gone.

Mikal

[Reply #7 on:]

Thanks for that. I have things working, and NewSoftSerial had nothing to do with the trouble I had. But knowing how it works changes my perception of how I should use it. I avoided using it with a 9600 baud GPS, choosing a 4800 instead. It seems I  would be better off with the 9600 as it would have interrupts off for less time.