Softwareserial

Forum 2005-2010 (read only) Software Syntax & Programs
1

Every time I try to bring softwareserial into my code I get this error:

In function 'void setup()':
error: expected unqualified-id before '.' token

I've searched the forum and references and cann't figure out what I'm doing wrong. thanks

my code looks like this:
#include <SoftwareSerial.h>

int val = 0;
char code [10];
int byteread = 0;
int EnPin = 2;

void setup()
{
Serial.begin(2400);
pinMode(2,OUTPUT);
SoftwareSerial(7,8);
SoftwareSerial.begin(9600);

}

void loop()
{

digitalWrite(EnPin,LOW);
if (Serial.available()>0)
{
if((val = Serial.read()) == 10)
{
byteread=0;
while (byteread < 10)
{
if (Serial.available()>0)
{
val = Serial.read();
if ((val == 10) || (val == 13))
{
break;
}
code[byteread]=val;
byteread++;
}
}
if (byteread==10)
{
Serial.print("Tag code is ");
Serial.println(code);
}
digitalWrite(EnPin,HIGH);
delay(500);
}
}
}

2

SoftwareSerial doesn't work quite the same way as the regular Serial. You need to declare an instance of it, then call begin(), etc. on that instance not on SoftwareSerial. See the example at: Arduino - Home

3

I'm still having problems with this. Everything works until I try to begin the software serial. The program compiles but does not run. If I comment it out everything works perfectly.

#include <SoftwareSerial.h>

int val=0;
char card[10];
int byteread=0;
#define RFIDEN 2
#define rxPin 5
#define txPin 6

SoftwareSerial mySerial = SoftwareSerial(rxPin, txPin);

void setup()
{
pinMode(RFIDEN,OUTPUT);
Serial.begin(2400);
pinMode(rxPin, INPUT);
pinMode(txPin, OUTPUT);
// mySerial.begin(9600);
}

void loop()
{
GetRFID();
mySerial.println(card);
}

4

The program compiles but does not run.

hi

Do you mean that it compiles and you can upload it, but it doesn't appear to work?

D

5

Yep

6

SoftwareSerial has some timing issues. It doesn't push the tx pin high when started, that can ruin the first character, but you can work around that by setting it high when you set the pinmode for it.

Worse, the rather expensive math operation to compute the bit delay gets shuffled into an unfortunate code path and makes the start bit be about 1.5 bit times long ensuring that your bits are sampled on the edges instead of the centers

Still, I wouldn't expect you to get nothing from that. I'd expect you to get a few percent of your characters garbled, or all of them, depending on the timing of your receiver's uart.

(Patches are in the works for 0008 software serial to stabilize it.)

SoftwareSerial::begin() just stores your bit rate in an instance variable. It seems unlikely that could cause a problem directly unless you have run out of SRAM. If you don't do a ::begin() you will get a divide by zero error in print. I don't know what that does.

7

Interesting to see that someone came across a similar problem.

I am currently using the Arduino Mini to read data from an RFID reader and send it through the serial. To communicate with the RFID reader (which also talks through serial, 9600 baud rate) I need to use a SoftwareSerial.

Whenever a call to SoftwareeSerial.read() is made I get some character printed out on the USB Serial (usually 'b') even if I don'call any printing function; and then the Mini resets :-?

This is exactly the same behaviour that I get if I don't have anything plugged onto my designated software serial ports.

I have previously connected the RFID reader directly to the Arduino USB and I am sure that it is working. I also have tried programming the Mini so that the RFID reader is connected to the hardware serial pors and the USB to the software ones. The result is the same, the Mini keeps on resetting.

Code follows:

#include <SoftwareSerial.h>

#define rxPin 3
#define txPin 2
#define ledPin 13

// set up a soft serial port
SoftwareSerial mySerial(rxPin, txPin);

void setup() {

// define pin modes for tx, rx, led pins:
pinMode(rxPin, INPUT);
pinMode(txPin, OUTPUT);
pinMode(ledPin, OUTPUT);

// set txPin high (as recommended in forum)
digitalWrite(txPin, HIGH);

// set the data rate for the serial ports
mySerial.begin(9600);
Serial.begin(9600);

// say something
Serial.println("Hello World!");

}

void loop() {

char someChar = '0';
someChar = mySerial.read();

// print out the character:
Serial.print(someChar, DEC);

// toggle an LED just so you see the thing's alive.
// this LED will go on with every OTHER character received:
toggle(13);

}

So does SoftwareSerial implement the whole serial protocol or should I be sending some character to start the serial communication? Altough the reset thing is quite strange....

Cheers!
TMSM

8

it's interesting i'm having trouble implementing softwareserial also. i am just trying to use the basic example at the arduino.cc site to see how it works - Arduino - Home - but it does not run properly. i've also tried some of the suggestions here (setting tx high in setup) but that has had no effect. has anybody run this successfully?

9

hi

in order for use to give you a good answer you need to give us more detail.. code, pictures, videos, text description. Unfortunately most of us failed our courses on mind-reading at school. :slight_smile:

D

10

hi

in order for use to give you a good answer you need to give us more detail.. code, pictures, videos, text description. Unfortunately most of us failed our courses on mind-reading at school. :slight_smile:

D

i'm not sure what additional information you would need. i am using the exact same code used in the softwareserial example - http://www.arduino.cc/en/Reference/SoftwareSerialExample - with no modifications or changes. i wanted to see first if the example would actually work. i have an arduino NG i am running the latest version (0007). in the example serial data is sent through pins 2 and 3 - again as described in the example which i have not modified.

pins 2, 3 are connected to a FTDI rs232 usb-serial adapter. using the regular serial commands it works just fine. when i switch the code over to use softwareserial it does not work.

the only thing changed in this setup is the addition of the softwareserial declaration and changing the instances of send.serial(), read.serial(), etc. to the softwareserial command detailed in the example.

so i'm still wondering what the problem might be.

just wondering, has anybody implemented the example successfully?

11

Does it keep on resetting like mine? This is the thing I find most weird... :o

12

hi

Software serial is going to be a lot more finicky than the regular hardware serial. This is because hardware serial on pins 0 and 1 have a dedicated UART that sits there all the time, dealing with the data coming in and out. If the processor is busy, the hardware serial port can still receive data, until its buffer is full.

Software serial, by contrast, is only going to work if the processor is executing commands related to software serial. This means it is possible to miss incoming data, as you might be off blinking an LED or something else when it arrives. I have used sws for non-critical applications like sending data to an LCD, but I wouldn't use it for Arduino-host communication for the above reasons.

D

13

hi
I have used sws for non-critical applications like sending data to an LCD, but I wouldn't use it for Arduino-host communication for the above reasons.
D

well i have been trying to test softwareserial by sending the data to hyperterm from pins 2 and 3 connected to an FTDI re232 serial/usb converter. i also tried modifying the sample code so that the arduino sends data continuously figuring that something would get through - but to no avail. it does not work at all.

any suggestions? i eventually want to send data to a serial controlled mp3 player. i do not need complicated call and response - in fact i don't even really need serial.read() - but i seem to have trouble getting even a basic system working.

14

hi

sending to hyperterm is actually not the best way to test it... there may be some handshaking or similar between the RS232-USB chip and the computer.

Now that you mention it, one other problem may be the RS232 itself. What kind of converter amodule are you using?

Any time I have used SWS it has been to send data to a TTL serial connection (0/5V), rather than an RS-232 connection (+/- 3 to 15V).

If your 232-USB converter needs 'real' RS-232 levels, you will have to provide a real RS232 voltage swing, and possibly also inverted data form the TTL pin. If you look at the original Arduino schematic they show you how to achieve this with a couple of transistors.

D

15

i have been using this module - SparkFun USB to Serial Breakout - FT232RL - BOB-12731 - SparkFun Electronics - the FT232RL USB to Serial breakout board, but set for 5v instead of 3.3v.

it's funny because the mp3 player i have is TTL serial. i've been using the FT232RL USB to Serial breakout board to communicate with the player through hyperterm, which works perfectly so i know it can take TTL level signals.

i have also tried interfacing directly to the mp3 player, but that has not yet worked. i was hoping to test anyway with something else since the mp3 player is the only one i currently have.

any suggestions?

16

I just wrote a simple program that creates a software serial and just keeps printing the ASCII character T.

My Mini and USB are connected as shown in: http://www.arduino.cc/en/uploads/Guide/ArduinoMiniBreadboardPhoto.jpg

I programmed my Mini using the Mini USB, disconnected the whole thing, connected the Mini USB to the SoftwareSerial ports, powered it up and monitored the USB (using the Arduino IDE). It didn't work and once more the Mini flashes the LED 3 times every 5 seconds or so.

Code follows:

#include <SoftwareSerial.h>

#define rxPin 10
#define txPin 11
#define ledPin 13

// set up a new serial port
SoftwareSerial mySerial(rxPin, txPin);
byte pinState = 0;

void setup() {
// define pin modes for tx, rx, led pins:
pinMode(rxPin, INPUT);
pinMode(txPin, OUTPUT);
pinMode(ledPin, OUTPUT);
// set the data rate for the SoftwareSerial port
mySerial.begin(9600);
}

void loop() {
// print 'T'
mySerial.print(84, BYTE);
// show that I'm alive
toggle(13);
// take a break
delay(500);
}

void toggle(int pinNum) {
// set the LED pin using the pinState variable:
digitalWrite(pinNum, pinState);
// if pinState = 0, set it to 1, and vice versa:
pinState = !pinState;
}

It is so simple that there should be no reason for it not to be working. Any thoughts on this?

17

I've used the software serial library to send characters via the Mini USB to the computer. It works.

tmsm: it sounds like you have a more general problem. If the LED flashes 3 times every 5 seconds or so it means that the bootloader is restarting over and over again, meaning that there's no program on your Arduino. Does the same thing happen no matter what program you upload (e.g. the LED blink)?

18

No, I've also been interfacing with an Hitachi H48C accelerometer module and an Hitachi HM55B compass module (both from Parallax) through shifting in and out and this works fine.

Also in previous attempts to use SoftwareSerial, this rebooting does not happen if I never get to call SoftwareSerial.read() or SoftwareSerial.write(). If I do, however, the program executes just fine until the call, at which point the Mini reboots.

If the fact that the bootloader keeps on restarting means that there is no program, then what does it mean if it restarts during the exectution of a program? That somewhere the program itself is somehow corrupted? :-?

I am wondering if there might be something wrong with the library itself in my installation of Arduino 7.

19

...and howcome using the function SWprint copied from

actually manages to send something (altough not exactly the character I tell ito send), while a properly set up SoftwareSerial reboots at the print() call?

Geez, FFS...!

20

The problem is that Arduino 0007 doesn't recompile your libraries when you switch from the ATmega8 (which is the default) to the ATmega168 (which should be the default, since all new boards come with it). You need to go in the lib/targets/libraries/SoftwareSerial sub-directory of your Arduino application directory and delete SoftwareSerial.o. Then re-upload your sketch and it should work.

This is fixed in Arduino 0008, which should come out soon.