Software serial within other Lib

JBSAFF · November 4, 2015, 10:23am

Hi,

I’m working on a wireless sensor network project.

For this project after using “pre-made” arduino compatible boards (ITEAD G-Board Pro) I started to design my own board based on 1284P and following “maniacbug” tutorial.

I need 3 serials : 1 for Xbee, 1 for GPRS (GPRSBEE) and 1 for debug.

I want to use the 2 harware serials for Xbee and Gprs and have a Software serial for Debug.

I manage to use sotware serial without problems.

The situation I now face is that inside the Library I use for GPRS connection i want to use software serial prints for debuging.

When doing so I get an error at the compilation with a message that says dans the software serial object is not declared, and if I try to declare it… it says that there is a multiple declaration…

Thanks,

JB

system · November 4, 2015, 12:13pm

When doing so

In a way I'm not going to show you...

I get an error at the compilation with a message that says

something that might have been vaguely like...

dans the software serial object is not declared

I don't think that that is even remotely like the message that you saw.

it says that there is a multiple declaration...

Bummer.

Now that you are done whining, post your code and the EXACT error messages, and we can help you.

JBSAFF · November 4, 2015, 1:45pm

Hi,

No whining involved, English not being my mother tongue I guess there’s been a bit of misunderstanding.

I obviously don’t expect to be shown exactly how to do it, I’d just like to know in which direction to search.

The declaration is done with these lines in the main code :

#include <SoftwareSerial.h>

//SOFT SERIAL PINS
uint8_t ssRX = 12;
uint8_t ssTX = 13;
SoftwareSerial nss(ssRX, ssTX);

The setup() call :

nss.begin(115200);

and the call I try to get working in the library is :

nss.println("Test");

This line works when called from the main program but not from within the GPRS library the message I get is :
“nss not declared in this scope”

the scope being the library.

JB

system · November 4, 2015, 1:49pm

Perhaps a visit to the fine folks at http://snippets-r-us.com would be useful, to get help with your snippets.

system · November 4, 2015, 2:08pm

JBSAFF:
Hi,

No whining involved, English not being my mother tongue I guess there’s been a bit of misunderstanding.

I obviously don’t expect to be shown exactly how to do it, I’d just like to know in which direction to search.

The declaration is done with these lines in the main code :

Where is #include GPRS ( or whatever the real library name is )? Is it before SoftwareSerial or after?
Are you aware that “Serial” - not SoftwareSerial - is physically and in core software “wired” / attached to COM monitor? If you are going to use “print” for debugging you have to use plain “Serial”.

#include <SoftwareSerial.h>

//SOFT SERIAL PINS
uint8_t ssRX = 12;
uint8_t ssTX = 13;
SoftwareSerial nss(ssRX, ssTX);

The setup() call :

nss.begin(115200);

and the call I try to get working in the library is :

nss.println(“Test”);

This line works when called from the main program but not from within the GPRS library the message I get is :
“nss not declared in this scope”

the scope being the library.

JB

JBSAFF · November 4, 2015, 2:21pm

Hi,

Here’s the full libary include block :

#include <XBee.h>
#include <SoftwareSerial.h>
#include "LowPower.h"
#include <avr/wdt.h>

//SOFT SERIAL PINS
uint8_t ssRX = 12;
uint8_t ssTX = 13;
SoftwareSerial nss(ssRX, ssTX);


#include <GPRSBEE.h>

it was originaly :

#include <XBee.h>
#include <GPRSBEE.h>
#include <SoftwareSerial.h>
#include "LowPower.h"
#include <avr/wdt.h>

//SOFT SERIAL PINS
uint8_t ssRX = 12;
uint8_t ssTX = 13;
SoftwareSerial nss(ssRX, ssTX);

I have a prototype that works with this serial port allocation :
Serial => Gprsbee
Serial1 => prog + debug
Software Seral => Xbee

I thought it was better practice to have the most important devices on “Hardware” serial and use the Software serial for debugging purposes.

I now program with the AVR ISP through MISO/MOSI/SCK etc…

I hope to get more reliable performance with this setup mostly on interrupts and Serial buffer size

dev_1 · November 4, 2015, 2:24pm

I just experienced this problem with NeoGPS. The IDE does not add the include path for SoftwareSerial in “some” cases. For me, it happened when the include statement was in an included file (nested includes). I just moved the include to the outer-level include files.

Maybe you could add the “-I/libraries/SoftwareSerial” flag to the compiler switches. This is what’s really missing. Definitely an IDE problem.

Or, you might be able to declare a global Stream type variable, extern it in the problem CPP and use it for debug prints. In the INO, include SoftwareSerial.h, create the SoftwareSerial variable and assign it to the global Stream variable:

x.ino

#include <SoftwareSerial.h>
Stream debug_output = SoftwareSerial( rx, tx );

y.cpp

extern Stream debug_output;

void foo()
{
  debug_output.print( F("Hello world!") );
}

That’s if the Stream type gets correctly included… It’s in the normal include path instead of being down in a library subdirectory, so you may be able to include <Stream.h> without problems.

Cheers,
/dev

system · November 4, 2015, 2:28pm

Header files need include guards, to prevent the problems you are seeing.

#ifndef SomeNotLikelyToBeRepeatedName_H
#define SomeNotLikelyToBeRepeatedName_H

// The rest of your stuff goes here

#endif

Header files do NOT value variables. They ONLY declare them.

Source files value variables.

system · November 4, 2015, 2:47pm

I thought it was better practice to have the most important devices on “Hardware” serial and use the Software serial for debugging purposes.

I now program with the AVR ISP through MISO/MOSI/SCK etc…

So you “new” version has no #include <GPRSBEE.h> at all? How can it work?

I don’t think sharing the hardware / Serial will work unless you make provisions in code to do that.

AVR ISP through MISO/MOSI/SCK - so apparently you cannot use “standard” COM port for debugging, right?

Ether way - seems complicated way to run things, but that is your choice.

My suggestion is to test your code using only one hardware device at a time , not all of them at once.
I would start with “print” first , than you have a tool to debug the rest of the code.

JBSAFF · November 4, 2015, 3:07pm

Hi,

Vaclav:
So you “new” version has no #include <GPRSBEE.h> at all? How can it work?

Ether way - seems complicated way to run things, but that is your choice.

My suggestion is to test your code using only one hardware device at a time , not all of them at once.
I would start with “print” first , than you have a tool to debug the rest of the code.

I work on this for a long time and of course I built the code one piece at the time. The system works fine but the problem I have is that with my “new” serials allocation I can’t get debugging messages from within the GprsBee library.

Of course I have #include <GPRSBEE.h>.

I’m sorry if I’m not clear enough.

On the 1284P I have 2 hardware serial, I have now wired and coded for :

Serial number 1 : Xbee
Serial number 2 : GPRSBEE

I use an FTDI adapter linked to the Software Serial Pins to get my debug messages.

I have now “commented” the lines of Gprsbee.cpp that were used for debugging purposes.
Everything works fine (only I can’t get the debugging messages from the GPRSBEE.CPP code).

Anyways, I thank you for your answers I have now plenty of things to try.

I’ll get back ASAP with the final word.

Sorry for the poor formatting.

JB

system · November 4, 2015, 3:24pm

JBSAFF:
Hi,

I work on this for a long time and of course I built the code one piece at the time. The system works fine but the problem I have is that with my “new” serials allocation I can’t get debugging messages from within the GprsBee library.

Of course I have #include <GPRSBEE.h>.

I’m sorry if I’m not clear enough.

On the 1284P I have 2 hardware serial, I have now wired and coded for :

Serial number 1 : Xbee
Serial number 2 : GPRSBEE

I use an FTDI adapter linked to the Software Serial Pins to get my debug messages.

I have now “commented” the lines of Gprsbee.cpp that were used for debugging purposes.
Everything works fine (only I can’t get the debugging messages from the GPRSBEE.CPP code).

Anyways, I thank you for your answers I have now plenty of things to try.

I’ll get back ASAP with the final word.

Sorry for the poor formatting.

JB

No problem, your original post was pretty clear what the issue is, just your next to last post thru me off.
No worries about formatting - as they say - do not worry about small stuff.
Good luck.

Addendum
Of course I have #include <GPRSBEE.h>.
Sorry, my fault I missed the last line in you "new’ code.

jboyton · November 4, 2015, 3:50pm

For software serial debugging output I use a transmit-only version (attached below) so I don’t have to waste a pin on RX or screw around with code to disable it. The transmit-only software serial is just a cut down copy of the one from the core (1.6.x). Since it has a different name you just put it in your libraries folder like any other third party library.

#include <tSoftSerial.h>

tSoftSerial ss(DEBUG_TX_PIN); // optional second parameter for inverse logic

ss.begin(9600);
ss.print(F(“Hello world”));

tSoftSerial.cpp (2.39 KB)

tSoftSerial.h (1.33 KB)

dev_1 · November 4, 2015, 4:27pm

PaulS:
Header files need include guards, to prevent the problems you are seeing.

Wha-whaaat? SoftwareSerial.h does have guards, and my nested include had a guard, but not of that form. Why would the including file need that form? Investigating...

[Edit] ~~Indeed, it works with that form. Weird!~~ See later reply...

Header files do NOT value variables. They ONLY declare them.

Source files value variables.

Do you mean "define variables" vs. declare variables? Definitions can have an optional initial value, if that's what you're talking about.

Cheers,
/dev

system · November 4, 2015, 5:24pm

jboyton:
For software serial debugging output I use a transmit-only version (attached below) so I don’t have to waste a pin on RX or screw around with code to disable it. The transmit-only software serial is just a cut down copy of the one from the core (1.6.x). Since it has a different name you just put it in your libraries folder like any other third party library.

#include <tSoftSerial.h>

tSoftSerial ss(DEBUG_TX_PIN); // optional second parameter for inverse logic

ss.begin(9600);
ss.print(F(“Hello world”));

I am not sure I follow your logic. .
How will replacing SoftwareSerial with tSoftwareSerial help?

The issue is accessing SofwareSerial.

Probably the old Nemesis of IDE messing up #includes.
I usually copy the “library” files ( from Github) to my own header file ( local copy sort of) which is always controllable than letting IDE including or ( as in this case) not including files.

jboyton · November 4, 2015, 5:33pm

Vaclav:
I am not sure I follow your logic. .
How will replacing SoftwareSerial with tSoftwareSerial help?

The issue is accessing SofwareSerial.

It will help because then you won't have to figure out why the IDE won't let you access SoftwareSerial. As a bonus it frees up a pin.

I thought the goal was to have debug output. If you're more interested in understanding the IDE issue then you're right, it won't help.

dev_1 · November 4, 2015, 8:59pm

jboyton:
For software serial debugging output I use a transmit-only version (attached below)

Cute! You can also pass an invalid pin number for the RX pin. When it tries to lookup the control and mask registers, it fails and skips the rest. I just pass pin 0xFF.

Kludgey, I know...
/dev

jboyton · November 4, 2015, 9:05pm

That is a cute trick.

But SoftwareSerial also grabs all of the pin change interrupt vectors. That can be pretty annoying when you want to use one of them for another purpose at the same time. The transmit side doesn't use interrupts.

dev_1 · November 4, 2015, 10:36pm

PaulS:
Header files need include guards, to prevent the problems you are seeing.

Ok, I thought this fixed the problem, but I was mistaken. Here’s a short example:

includeTest.INO

#include "A.h"

SoftwareSerial ss( 4, 3 );

void setup() {}

void loop() {}

A.h

#ifndef A_h
#define A_h

#include <SoftwareSerial.h>

#endif

The build log

D:\Program Files\Arduino\1.0.5-ERW\hardware\tools\avr\bin\avr-g++ -c -g -Os -Wall 
-fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega2560 -DF_CPU=16000000L 
-MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=105 
-ID:\Program Files\Arduino\1.0.5-ERW\hardware\arduino\cores\arduino 
-ID:\Program Files\Arduino\1.0.5-ERW\hardware\arduino\variants\mega 
C:\Users\SlashDev\AppData\Local\Temp\build2991499811398485666.tmp\includeTest.cpp
-o C:\Users\SlashDev\AppData\Local\Temp\build2991499811398485666.tmp\includeTest.cpp.o 
In file included from includeTest.ino:1:
/A.h:4:28: warning: SoftwareSerial.h: No such file or directory
includeTest:3: error: 'SoftwareSerial' does not name a type

:’( The include works if it is in includeTest.ino.

A.h (65 Bytes)

includeTest.ino (81 Bytes)

dev_1 · November 4, 2015, 10:49pm

jboyton:
SoftwareSerial also grabs all of the pin change interrupt vectors. That can be pretty annoying when you want to use one of them for another purpose

Yep. Cosa got this part right because it treats the PCInts as a Global resource.

Cheers,
/dev

system · November 4, 2015, 11:49pm

The include works if it is in includeTest.ino.

Which is exactly what I suggested ( include as "new" tab / local file in x.ino file) to do to bypass Arduino IDE #include problem.
This long outstanding problem is nothing new and to my knowledge has not been seriously addressed by IDE "team" developers.
And I am not going to check released 1.6.6 to find out if it is still a problem. I do not like to be a tester, mainly because the developers do not appreciate feedback and I have a hack to fix it in my code.
So call me selfish.