crayzeewulf / libserial Goto Github PK

Reported by locutusofborg1 on 2015-03-12 12:54 UTC
this patch makes the tests build on debian (I'm currently packaging the latest snapshot)

I don't run them, but at least I can check if a sample program builds correctly

--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -1,6 +1,6 @@
AM_CXXFLAGS = -Weffc++

-#noinst_PROGRAMS = unit_tests
+noinst_PROGRAMS = unit_tests

lib_LTLIBRARIES = libserial.la

@@ -9,7 +9,7 @@ include_HEADERS = SerialStreamBuf.h SerialStream.h SerialPort.h
libserial_la_SOURCES = SerialStreamBuf.cc SerialStreamBuf.h SerialStream.cc
SerialStream.h SerialPort.cpp SerialPort.h PosixSignalDispatcher.cpp

-#unit_tests_SOURCES = unit_tests.cpp
-#unit_tests_LDADD = libserial.la -lboost_unit_test_framework-mt
+unit_tests_SOURCES = unit_tests.cpp
+unit_tests_LDADD = libserial.la -lboost_unit_test_framework

noinst_HEADERS = PosixSignalDispatcher.h PosixSignalHandler.h

Reported by wedesoft on 2005-07-30 14:52 UTC
One would be able to check for availability of input
using 's.rdbuf()->in_avail() > 0', if the method
'SerialStreamBuf::showmanyc()' is implemented:

std::streamsize SerialStreamBuf::showmanyc() {

int retval = -1;

if ( -1 == mFileDescriptor ) {
return -1;
};

if ( mPutbackAvailable ) {

// We still have a character left in the buffer.
retval = 1;

} else {

// Switch to non-blocking read.
int flags = fcntl(this->mFileDescriptor, F_GETFL, 0) ;
if( -1 == fcntl( this->mFileDescriptor,
F_SETFL,
flags | O_NONBLOCK ) ) {
return -1;
}

// Try to read a character.
retval = read(mFileDescriptor, &mPutbackChar, 1);

if ( retval == 1 ) {
mPutbackAvailable = true;
} else
retval = 0;

// Switch back to blocking read.
if( -1 == fcntl( this->mFileDescriptor,
F_SETFL,
flags ) ) {
return -1;
}
};
return retval;

}

The patch furthermore fixes the missing
return-statement in 'SerialStreamBuf::open'.

Reported by nyrk on 2009-03-18 22:19 UTC
in libserial 0.5.2, doxygen returns some warnings, such as:

Warning: Tag `CGI_NAME' at line 573 of file doxygen.conf has become obsolete.
To avoid this warning please update your configuration file using "doxygen -u"

It should be easy obtain a new version of doxygen.conf using:
doxygen -u doxygen.conf

Reported by oschwa2s on 2013-11-25 14:05 UTC
Hello,
I'm currently using libSerial 0.6.0rc1 to communicate with an embedded system at 460800 baud.

First of all, I noticed that SerialStreams cannot be used with this baud rate, as the corresponding defines are missing within "SerialStreamBuf.cc". I added those missing defines.

Then, I experienced random segfaults that occur after about 2-45 minutes runtime of my program, which is constantly receiving data at 2.6kB/s. I noticed the unfinished code in PosixSignalDispatcherImpl::SigactionHandler, where currently all incoming signals are passed. I just added a little check at the start of the method to ensure that only IO-signals are processed. Since then I got no segfaults anymore.

BTW, I also made some changes to get rid of some warnings that occur during compilation.

I just generated a patch to apply my changes to the src folder of version 0.6.0rc1. Please have a look!

Best regards,
oschwa2m

*Reported by anonymous on 2006-06-14 21:34 UTC
All I did was put one line in my code:
#include <SerialStream.h>

and on make I get:

i686-pc-linux-gnu-g++ -o X10 main.o X10.o
edit_database.o options.o edit_sensors.o moc_X10.o
moc_edit_database.o moc_options.o moc_edit_sensors.o
-L/usr/qt/3/lib -L/usr/X11R6/lib -L/usr/lib
-L/usr/qt/3/plugins/sqldrivers/libmysqlclient.so
-L/usr/qt/3/plugins/sqldrivers/libqmysql.so -lqt-mt
-lXext -lX11 -lm
X10.o:(.gnu.linkonce.r._ZTVN9LibSerial15SerialStreamBufE+0x24):
undefined reference to
LibSerial::SerialStreamBuf::showmanyc()' X10.o:(.gnu.linkonce.r._ZTVN9LibSerial15SerialStreamBufE+0x28): undefined reference to LibSerial::SerialStreamBuf::xsgetn(char*, int)'
X10.o:(.gnu.linkonce.r._ZTVN9LibSerial15SerialStreamBufE+0x2c):
undefined reference to
LibSerial::SerialStreamBuf::underflow()' X10.o:(.gnu.linkonce.r._ZTVN9LibSerial15SerialStreamBufE+0x34): undefined reference to LibSerial::SerialStreamBuf::pbackfail(int)'
X10.o:(.gnu.linkonce.r._ZTVN9LibSerial15SerialStreamBufE+0x38):
undefined reference to
LibSerial::SerialStreamBuf::xsputn(char const*, int)' X10.o:(.gnu.linkonce.r._ZTVN9LibSerial15SerialStreamBufE+0x3c): undefined reference to LibSerial::SerialStreamBuf::overflow(int)'
collect2: ld returned 1 exit status
make: *** [X10] Error 1

What did I do!? There is little to no installation
guide for this, I would really like to see one because
I bet these errors are because I didnt install it
correctly... that or they are bugs.

Reported by nicost on 2005-10-13 06:09 UTC
When using the example program writeport (which had to
be modifed to allow for input of serial port location),
program execution hangs for ever at the
serial_port.Open call.

I traced this down to line 177 in SerialStreamBuf.cc
(this->mFileDescriptor = ::open(filename.data(), flags)
;).

Input at this point seems OK: filename.data()=
"/dev/tty.USA19H3b1P1.1" (which is the correct
filename) flags=2.

Any ideas? Where does mFileDescriptor come from? What
open command is being called here?

Reported by shtrom on 2013-05-29 05:04 UTC
Compiling src/SerialPort.cpp with -Wall -Werror raises some errors about standard libc functions not being defined in that scope.

This is due to som headers not being included in that file: sys/types.h sys/stat.h unistd.h.

Including them at the top fixes the issue.

Reported by locutusofborg1 on 2015-03-12 12:54 UTC
this patch makes the tests build on debian (I'm currently packaging the latest snapshot)

I don't run them, but at least I can check if a sample program builds correctly

--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -1,6 +1,6 @@
AM_CXXFLAGS = -Weffc++

-#noinst_PROGRAMS = unit_tests
+noinst_PROGRAMS = unit_tests

lib_LTLIBRARIES = libserial.la

@@ -9,7 +9,7 @@ include_HEADERS = SerialStreamBuf.h SerialStream.h SerialPort.h
libserial_la_SOURCES = SerialStreamBuf.cc SerialStreamBuf.h SerialStream.cc
SerialStream.h SerialPort.cpp SerialPort.h PosixSignalDispatcher.cpp

-#unit_tests_SOURCES = unit_tests.cpp
-#unit_tests_LDADD = libserial.la -lboost_unit_test_framework-mt
+unit_tests_SOURCES = unit_tests.cpp
+unit_tests_LDADD = libserial.la -lboost_unit_test_framework

noinst_HEADERS = PosixSignalDispatcher.h PosixSignalHandler.h

Reported by fgerlits on 2007-01-23 17:29 UTC
In the SerialStream.h and SerialStreamBuf.h header files there is a semicolon after the namespace declaration, which gcc complains about if run in crotchety mode.

The attached patch removes these semicolons.

Reported by nicost on 2005-10-13 06:09 UTC
When using the example program writeport (which had to
be modifed to allow for input of serial port location),
program execution hangs for ever at the
serial_port.Open call.

I traced this down to line 177 in SerialStreamBuf.cc
(this->mFileDescriptor = ::open(filename.data(), flags)
;).

Input at this point seems OK: filename.data()=
"/dev/tty.USA19H3b1P1.1" (which is the correct
filename) flags=2.

Any ideas? Where does mFileDescriptor come from? What
open command is being called here?

Reported by spdawson on 2013-04-23 14:48 UTC
Build error (gcc 4.7.3, cross-compiling for ARM):

SerialPort.cpp: In member function 'void SerialPort::SerialPortImpl::Open()':
SerialPort.cpp:643:24: error: 'getpid' was not declared in this scope
SerialPort.cpp: In member function 'void SerialPort::SerialPortImpl::Close()':
SerialPort.cpp:748:26: error: 'close' was not declared in this scope
SerialPort.cpp: In member function 'unsigned char SerialPort::SerialPortImpl::ReadByte(unsigned int)':
SerialPort.cpp:1246:37: error: 'usleep' was not declared in this scope
SerialPort.cpp: In member function 'void SerialPort::SerialPortImpl::Write(const unsigned char*, unsigned int)':
SerialPort.cpp:1427:50: error: 'write' was not declared in this scope
SerialPort.cpp: In member function 'virtual void SerialPort::SerialPortImpl::HandlePosixSignal(int)':

Reported by wit3k on 2008-10-06 17:07 UTC
I think about something like System.IO.Ports.SerialPort.GetPortNames() in Mono. But I think that funtion outputting array (or for the best STL`s vector) is not enought. There should be inner vector that user would not be forced to create his own.

Reported by crayzeewulf on 2008-10-03 23:12 UTC
See the following message for a full description:

https://sourceforge.net/forum/message.php?msg\_id=5363412

By: raywilhe

In tracking down program crashes, I think I might have found a bug in the libserial
read code.

From what I can tell, serial port reads happen through a signal handler function
which fills a stl queue with data. The SerialPort::Read() functions then pull
data from that stl queue.

The stl queue that passes information between the SignalHandler and the
SerialPort::Read() functions has no protections (e.g. mutex) to prevent simultaneous
access to the stl queue.

Since the SIGIO signal can interrupt the user's thread at anytime, this can
cause problems if you are lucky enough to have the folllowing happen:

1. User Calls SerialPort::ReadByte()
2. In the middle of executing the mInputBuffer.pop() function call
   the SIGIO signal is raised and the SerialPort::HandlePosixSignal()
   gets immediately called
3. In the SerialPort::HandlePosixSignal() function, the mInputBuffer.push()
   function is called
4. Execution returns back to SerialPort::ReadByte(), and the mInputBuffer.pop()
   finishes
5. Now the stl queue is corrupted and the random crashes start.....

Please let me know if anybody can confirm/deny that this is a problem. This
is my first time looking at the internals of libSerial, but thus far I am fairly
sure the above described problem is the smoking gun in my case.

*Reported by anonymous on 2007-04-21 22:11 UTC
#define bzero(b,n) memset(b,0,n)
#define bcopy(b1,b2,n) memcpy(b2,b1,n)
#define bcmp(b1,b2,n) memcmp(b1,b2,n)

Adding those will fix need for non-existant bzero under solaris, but FASYNC and FIONREAD don't seem to exist either- so compiling has stalled at that part. Can you work around FASYNC and FIONREAD for solaris?

*Reported by anonymous on 2000-12-20 09:47 UTC

*Reported by anonymous on 2006-06-14 21:34 UTC
All I did was put one line in my code:
#include <SerialStream.h>

and on make I get:

i686-pc-linux-gnu-g++ -o X10 main.o X10.o
edit_database.o options.o edit_sensors.o moc_X10.o
moc_edit_database.o moc_options.o moc_edit_sensors.o
-L/usr/qt/3/lib -L/usr/X11R6/lib -L/usr/lib
-L/usr/qt/3/plugins/sqldrivers/libmysqlclient.so
-L/usr/qt/3/plugins/sqldrivers/libqmysql.so -lqt-mt
-lXext -lX11 -lm
X10.o:(.gnu.linkonce.r._ZTVN9LibSerial15SerialStreamBufE+0x24):
undefined reference to
LibSerial::SerialStreamBuf::showmanyc()' X10.o:(.gnu.linkonce.r._ZTVN9LibSerial15SerialStreamBufE+0x28): undefined reference to LibSerial::SerialStreamBuf::xsgetn(char*, int)'
X10.o:(.gnu.linkonce.r._ZTVN9LibSerial15SerialStreamBufE+0x2c):
undefined reference to
LibSerial::SerialStreamBuf::underflow()' X10.o:(.gnu.linkonce.r._ZTVN9LibSerial15SerialStreamBufE+0x34): undefined reference to LibSerial::SerialStreamBuf::pbackfail(int)'
X10.o:(.gnu.linkonce.r._ZTVN9LibSerial15SerialStreamBufE+0x38):
undefined reference to
LibSerial::SerialStreamBuf::xsputn(char const*, int)' X10.o:(.gnu.linkonce.r._ZTVN9LibSerial15SerialStreamBufE+0x3c): undefined reference to LibSerial::SerialStreamBuf::overflow(int)'
collect2: ld returned 1 exit status
make: *** [X10] Error 1

What did I do!? There is little to no installation
guide for this, I would really like to see one because
I bet these errors are because I didnt install it
correctly... that or they are bugs.

Reported by wedesoft on 2005-07-30 14:52 UTC
One would be able to check for availability of input
using 's.rdbuf()->in_avail() > 0', if the method
'SerialStreamBuf::showmanyc()' is implemented:

std::streamsize SerialStreamBuf::showmanyc() {

int retval = -1;

if ( -1 == mFileDescriptor ) {
return -1;
};

if ( mPutbackAvailable ) {

// We still have a character left in the buffer.
retval = 1;

} else {

// Switch to non-blocking read.
int flags = fcntl(this->mFileDescriptor, F_GETFL, 0) ;
if( -1 == fcntl( this->mFileDescriptor,
F_SETFL,
flags | O_NONBLOCK ) ) {
return -1;
}

// Try to read a character.
retval = read(mFileDescriptor, &mPutbackChar, 1);

if ( retval == 1 ) {
mPutbackAvailable = true;
} else
retval = 0;

// Switch back to blocking read.
if( -1 == fcntl( this->mFileDescriptor,
F_SETFL,
flags ) ) {
return -1;
}
};
return retval;

}

The patch furthermore fixes the missing
return-statement in 'SerialStreamBuf::open'.

Reported by nicost on 2005-10-08 21:29 UTC
Compilation on Mac OS X 10.3.9 gives the following
errors, which all can be easily fixed by commenting out
the offending line:

SerialStreamBuf.cc:193: error: 'struct termios' has no
member named 'c_line'
//tio.c_line

In file included from SerialPort.cpp:21:
SerialPort.h:68: error: B460800' was not declared in this scope SerialPort.h:68: error: enumerator value for BAUD_460800' not integer constant
//BAUD_460800

PosixSignalDispatcher.cpp: In member function `void

<unnamed>::PosixSignalDispatcherImpl::AttachHandler(int,
PosixSignalHandler&)':
PosixSignalDispatcher.cpp:170: error: 'struct
sigaction' has no member named '
sa_restorer'
//sigaction_info.sa_restorer = NULL ;

No doubt due to different version of termio.h and
another POSIX header file. Any way to check for these
in the autoconf file?

Reported by jack-kelly on 2011-06-15 14:04 UTC
Hi there,

Great work with this project - it's exactly what I was looking for!

I could be wrong but I believe I've found a small bug. SerialStreamBuf.h currently contains the following enum:

enum BaudRateEnum {
BAUD_50 = SerialPort::BAUD_50,
...
BAUD_115200 = SerialPort::BAUD_115200,
BAUD_230400 = SerialPort::BAUD_230400,
BAUD_DEFAULT = SerialPort::BAUD_DEFAULT,
BAUD_INVALID
} ;

The problem is that this enum sets BAUD_INVALID to 4098 (because BAUD_DEFAULT==4097). But BAUD_115200 also equals 4098! So, in other words, BAUD_INVALID==BAUD_115200. So if you try setting the baud rate to 115200, the code wrongly decides to set the bad bit after line 78 of SerialStream.cc:

if( SerialStreamBuf::BAUD_INVALID ==
my_buffer->SetBaudRate(baudRate) )
{
setstate(badbit) ;
}

My simple (but probably ugly fix) is to change line 85 of SerialStreamBuf.h from "BAUD_INVALID" to "BAUD_INVALID = 999".

Reported by locutusofborg1 on 2015-03-12 15:46 UTC
Can you please provide a getter for mFileDescriptor?

We would like to put the read from serial in a select/poll code, but the library doesn't return the open file descriptor

" mImpl->mFileDescriptor = ::open(filename.c_str(), flags) ;"

this feature I think would be really useful to us, we can provide a patch if needed!

thanks

*Reported by anonymous on 2008-07-27 05:44 UTC
I want to use the library with RFCOMM (serial over bluetooth).

In that case, a C file descriptor is provided to communicate with the device.

There is a really simple example on this page:
http://people.csail.mit.edu/albert/bluez-intro/x502.html
(see the example 4-3 for instance).

Would it be possible to add a constructor to LibSerialStream to be able to construct the object from a file descriptor?

Thanks.

Reported by oschwa2s on 2013-11-25 14:05 UTC
Hello,
I'm currently using libSerial 0.6.0rc1 to communicate with an embedded system at 460800 baud.

First of all, I noticed that SerialStreams cannot be used with this baud rate, as the corresponding defines are missing within "SerialStreamBuf.cc". I added those missing defines.

Then, I experienced random segfaults that occur after about 2-45 minutes runtime of my program, which is constantly receiving data at 2.6kB/s. I noticed the unfinished code in PosixSignalDispatcherImpl::SigactionHandler, where currently all incoming signals are passed. I just added a little check at the start of the method to ensure that only IO-signals are processed. Since then I got no segfaults anymore.

BTW, I also made some changes to get rid of some warnings that occur during compilation.

I just generated a patch to apply my changes to the src folder of version 0.6.0rc1. Please have a look!

Best regards,
oschwa2m

Reported by shtrom on 2013-05-29 05:04 UTC
Compiling src/SerialPort.cpp with -Wall -Werror raises some errors about standard libc functions not being defined in that scope.

This is due to som headers not being included in that file: sys/types.h sys/stat.h unistd.h.

Including them at the top fixes the issue.

Reported by nyrk on 2009-03-18 22:19 UTC
in libserial 0.5.2, doxygen returns some warnings, such as:

Warning: Tag `CGI_NAME' at line 573 of file doxygen.conf has become obsolete.
To avoid this warning please update your configuration file using "doxygen -u"

It should be easy obtain a new version of doxygen.conf using:
doxygen -u doxygen.conf

*Reported by anonymous on 2011-12-28 13:46 UTC
So why do you mark this case "fixed", while in the sourceforge download it is still there??? It took me an hour to find the cause of the problem!

*Reported by anonymous on 2008-11-30 15:05 UTC
In the case that mPutbackAvailabe==true and n==1, retval is not assigned. I've been having issues using istream::readsome(). Adding an else statement to assign retval to 1 fixes my issue.

--- /tmp/libserial-0.5.2/src/SerialStreamBuf.cc 2005-10-16 17:12:52.000000000 -0700
+++ SerialStreamBuf.cc 2008-11-30 05:26:25.000000000 -0800
@@ -778,12 +778,14 @@
// one to indicate that the putback character was prepended to
// the array, s. If read failed then leave retval at -1.
//
if( retval != -1 ) {
retval ++ ;
}

•    } else {
  

•        retval = 1;
  

}
} else {
//
// If no putback character is available then we try to read n
// characters.
//

Reported by oschwa2s on 2013-11-25 14:05 UTC
Hello,
I'm currently using libSerial 0.6.0rc1 to communicate with an embedded system at 460800 baud.

First of all, I noticed that SerialStreams cannot be used with this baud rate, as the corresponding defines are missing within "SerialStreamBuf.cc". I added those missing defines.

Then, I experienced random segfaults that occur after about 2-45 minutes runtime of my program, which is constantly receiving data at 2.6kB/s. I noticed the unfinished code in PosixSignalDispatcherImpl::SigactionHandler, where currently all incoming signals are passed. I just added a little check at the start of the method to ensure that only IO-signals are processed. Since then I got no segfaults anymore.

BTW, I also made some changes to get rid of some warnings that occur during compilation.

I just generated a patch to apply my changes to the src folder of version 0.6.0rc1. Please have a look!

Best regards,
oschwa2m

Reported by montse on 2001-01-05 13:02 UTC

Reported by wedesoft on 2005-07-30 13:40 UTC
The method 'SerialStreamBuf::open' is lacking a return
statement at the end!
You should add f.e. 'return this;' at the end of the
method.
I also recommend compiling with '-Wall' and fixing all
warnings to catch similar problems in the future.

Reported by wit3k on 2008-09-30 09:50 UTC
Its nice to say in tutorial that you can make, a whole init in one line of code.

Just check uploaded file to see what I want. Its all writen, just please add next constructor to serialstream.h

Reported by crayzeewulf on 2008-10-03 23:12 UTC
See the following message for a full description:

https://sourceforge.net/forum/message.php?msg\_id=5363412

By: raywilhe

In tracking down program crashes, I think I might have found a bug in the libserial
read code.

From what I can tell, serial port reads happen through a signal handler function
which fills a stl queue with data. The SerialPort::Read() functions then pull
data from that stl queue.

The stl queue that passes information between the SignalHandler and the
SerialPort::Read() functions has no protections (e.g. mutex) to prevent simultaneous
access to the stl queue.

Since the SIGIO signal can interrupt the user's thread at anytime, this can
cause problems if you are lucky enough to have the folllowing happen:

1. User Calls SerialPort::ReadByte()
2. In the middle of executing the mInputBuffer.pop() function call
   the SIGIO signal is raised and the SerialPort::HandlePosixSignal()
   gets immediately called
3. In the SerialPort::HandlePosixSignal() function, the mInputBuffer.push()
   function is called
4. Execution returns back to SerialPort::ReadByte(), and the mInputBuffer.pop()
   finishes
5. Now the stl queue is corrupted and the random crashes start.....

Please let me know if anybody can confirm/deny that this is a problem. This
is my first time looking at the internals of libSerial, but thus far I am fairly
sure the above described problem is the smoking gun in my case.

Reported by nicost on 2005-10-08 21:29 UTC
Compilation on Mac OS X 10.3.9 gives the following
errors, which all can be easily fixed by commenting out
the offending line:

SerialStreamBuf.cc:193: error: 'struct termios' has no
member named 'c_line'
//tio.c_line

In file included from SerialPort.cpp:21:
SerialPort.h:68: error: B460800' was not declared in this scope SerialPort.h:68: error: enumerator value for BAUD_460800' not integer constant
//BAUD_460800

PosixSignalDispatcher.cpp: In member function `void

<unnamed>::PosixSignalDispatcherImpl::AttachHandler(int,
PosixSignalHandler&)':
PosixSignalDispatcher.cpp:170: error: 'struct
sigaction' has no member named '
sa_restorer'
//sigaction_info.sa_restorer = NULL ;

No doubt due to different version of termio.h and
another POSIX header file. Any way to check for these
in the autoconf file?

Reported by wedesoft on 2005-08-05 15:16 UTC
By running `minicom' or by prepending the following
piece of code, I get the port fully initialised. To
avoid side-effects, the library should do a full
initialisation of the serial port.

// Temporary hack to setup the port properly.
int fd = open( device, O_RDWR | O_NOCTTY );
MMERROR( fd>=0, mm_exception, ,
"Error opening device "" << device << "": "
<< strerror( errno ) );
struct termios tio;
tio.c_iflag = IGNBRK;
tio.c_oflag = 0;
tio.c_cflag = B19200 | CS8 | CLOCAL | CREAD;
tio.c_lflag = 0;
tio.c_line = '\0';
bzero( &tio.c_cc, sizeof(tio.c_cc) );
tio.c_cc[VTIME] = 5;
tio.c_cc[VMIN] = 1;
tcflush(fd, TCIFLUSH);
tcsetattr(fd,TCSANOW,&tio);
close( fd );

Reported by pulkomandy on 2011-06-29 20:26 UTC
I just downloaded libserial0.5.2 and noticed the config.guess and config.sub files are from 2006. These files are needed by the autotools to detect the host OS. The version from 2006 can't handle my operating system, Haiku. Please update the files to a newer version, which you can get here :

http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob\_plain;f=config.guess;hb=HEAD
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob\_plain;f=config.sub;hb=HEAD

Reported by nikhilmahale on 2012-02-04 14:09 UTC
At the outset I would like to state that I am relatively new to libserial, C++ programming and ROS, so please excuse any obvious mistakes.
I am using libserial to communicate with peripherals, in applications developed using the ROS framework (http://www.ros.org/wiki\). I was experiencing read timeouts (even for large values of timeouts), random wrong data being read from the port, std::runtime_error 's in read and write operations to ports and segmentation faults in random sections of code when using libserial as a part of ROS Nodes (applications). The same programs worked fine when I did not use any ROS components in them. Similarly programs using ROS framework without libserial worked fine.
The only difference I could find was that, programs using ROS components caused a process to spawn multiple threads while without ROS the process executed a single thread.
After some debugging I found that replacing the following code in <SerialPort::SerialPortImpl::Open>
/*

• Direct all SIGIO and SIGURG signals for the port to the current
• process.
  */
  if ( fcntl( mFileDescriptor,
  F_SETOWN,
  getpid() ) < 0 )
  {
  throw SerialPort::OpenFailed( strerror(errno) ) ;
  }

with

/*

• Direct all SIGIO and SIGURG signals for the port to the current
• thread.
  */
  struct f_owner_ex this_thread;
  this_thread.type = F_OWNER_TID;
  this_thread.pid = syscall(SYS_gettid);
  if ( fcntl( mFileDescriptor,
  F_SETOWN_EX,
  &this_thread ) < 0 )
  {
  throw SerialPort::OpenFailed( strerror(errno) ) ;
  }

has solved my problems. I have tested the applications thoroughly. Before applications would crash after running for anywhere from a couple of minutes to some hours. Now they run continuously without any of the above stated errors for as long as required.

Reported by jack-kelly on 2011-06-15 14:04 UTC
Hi there,

Great work with this project - it's exactly what I was looking for!

I could be wrong but I believe I've found a small bug. SerialStreamBuf.h currently contains the following enum:

enum BaudRateEnum {
BAUD_50 = SerialPort::BAUD_50,
...
BAUD_115200 = SerialPort::BAUD_115200,
BAUD_230400 = SerialPort::BAUD_230400,
BAUD_DEFAULT = SerialPort::BAUD_DEFAULT,
BAUD_INVALID
} ;

The problem is that this enum sets BAUD_INVALID to 4098 (because BAUD_DEFAULT==4097). But BAUD_115200 also equals 4098! So, in other words, BAUD_INVALID==BAUD_115200. So if you try setting the baud rate to 115200, the code wrongly decides to set the bad bit after line 78 of SerialStream.cc:

if( SerialStreamBuf::BAUD_INVALID ==
my_buffer->SetBaudRate(baudRate) )
{
setstate(badbit) ;
}

My simple (but probably ugly fix) is to change line 85 of SerialStreamBuf.h from "BAUD_INVALID" to "BAUD_INVALID = 999".

*Reported by anonymous on 2008-11-30 15:05 UTC
In the case that mPutbackAvailabe==true and n==1, retval is not assigned. I've been having issues using istream::readsome(). Adding an else statement to assign retval to 1 fixes my issue.

--- /tmp/libserial-0.5.2/src/SerialStreamBuf.cc 2005-10-16 17:12:52.000000000 -0700
+++ SerialStreamBuf.cc 2008-11-30 05:26:25.000000000 -0800
@@ -778,12 +778,14 @@
// one to indicate that the putback character was prepended to
// the array, s. If read failed then leave retval at -1.
//
if( retval != -1 ) {
retval ++ ;
}

•    } else {
  

•        retval = 1;
  

}
} else {
//
// If no putback character is available then we try to read n
// characters.
//

Reported by wedesoft on 2005-08-05 15:16 UTC
By running `minicom' or by prepending the following
piece of code, I get the port fully initialised. To
avoid side-effects, the library should do a full
initialisation of the serial port.

// Temporary hack to setup the port properly.
int fd = open( device, O_RDWR | O_NOCTTY );
MMERROR( fd>=0, mm_exception, ,
"Error opening device "" << device << "": "
<< strerror( errno ) );
struct termios tio;
tio.c_iflag = IGNBRK;
tio.c_oflag = 0;
tio.c_cflag = B19200 | CS8 | CLOCAL | CREAD;
tio.c_lflag = 0;
tio.c_line = '\0';
bzero( &tio.c_cc, sizeof(tio.c_cc) );
tio.c_cc[VTIME] = 5;
tio.c_cc[VMIN] = 1;
tcflush(fd, TCIFLUSH);
tcsetattr(fd,TCSANOW,&tio);
close( fd );

Reported by spdawson on 2013-04-23 14:48 UTC
Build error (gcc 4.7.3, cross-compiling for ARM):

SerialPort.cpp: In member function 'void SerialPort::SerialPortImpl::Open()':
SerialPort.cpp:643:24: error: 'getpid' was not declared in this scope
SerialPort.cpp: In member function 'void SerialPort::SerialPortImpl::Close()':
SerialPort.cpp:748:26: error: 'close' was not declared in this scope
SerialPort.cpp: In member function 'unsigned char SerialPort::SerialPortImpl::ReadByte(unsigned int)':
SerialPort.cpp:1246:37: error: 'usleep' was not declared in this scope
SerialPort.cpp: In member function 'void SerialPort::SerialPortImpl::Write(const unsigned char*, unsigned int)':
SerialPort.cpp:1427:50: error: 'write' was not declared in this scope
SerialPort.cpp: In member function 'virtual void SerialPort::SerialPortImpl::HandlePosixSignal(int)':

Reported by oschwa2s on 2013-11-28 14:55 UTC
This patch fixes bug #7.

*Reported by anonymous on 2007-08-22 18:43 UTC
hi, with your libserial, i see that in serialport.h there are several functions that i'd like to use however I can't figure out how to gain access to them. can you perhaps shed any light?

Reported by oschwa2s on 2013-11-28 14:55 UTC
This patch fixes bug #7.

Reported by wedesoft on 2005-07-30 14:52 UTC
One would be able to check for availability of input
using 's.rdbuf()->in_avail() > 0', if the method
'SerialStreamBuf::showmanyc()' is implemented:

std::streamsize SerialStreamBuf::showmanyc() {

int retval = -1;

if ( -1 == mFileDescriptor ) {
return -1;
};

if ( mPutbackAvailable ) {

// We still have a character left in the buffer.
retval = 1;

} else {

// Switch to non-blocking read.
int flags = fcntl(this->mFileDescriptor, F_GETFL, 0) ;
if( -1 == fcntl( this->mFileDescriptor,
F_SETFL,
flags | O_NONBLOCK ) ) {
return -1;
}

// Try to read a character.
retval = read(mFileDescriptor, &mPutbackChar, 1);

if ( retval == 1 ) {
mPutbackAvailable = true;
} else
retval = 0;

// Switch back to blocking read.
if( -1 == fcntl( this->mFileDescriptor,
F_SETFL,
flags ) ) {
return -1;
}
};
return retval;

}

The patch furthermore fixes the missing
return-statement in 'SerialStreamBuf::open'.

*Reported by anonymous on 2011-12-28 13:46 UTC
So why do you mark this case "fixed", while in the sourceforge download it is still there??? It took me an hour to find the cause of the problem!

Reported by wedesoft on 2005-07-30 13:40 UTC
The method 'SerialStreamBuf::open' is lacking a return
statement at the end!
You should add f.e. 'return this;' at the end of the
method.
I also recommend compiling with '-Wall' and fixing all
warnings to catch similar problems in the future.

Reported by fgerlits on 2007-01-23 17:29 UTC
In the SerialStream.h and SerialStreamBuf.h header files there is a semicolon after the namespace declaration, which gcc complains about if run in crotchety mode.

The attached patch removes these semicolons.

Reported by spdawson on 2013-04-23 14:48 UTC
Build error (gcc 4.7.3, cross-compiling for ARM):

SerialPort.cpp: In member function 'void SerialPort::SerialPortImpl::Open()':
SerialPort.cpp:643:24: error: 'getpid' was not declared in this scope
SerialPort.cpp: In member function 'void SerialPort::SerialPortImpl::Close()':
SerialPort.cpp:748:26: error: 'close' was not declared in this scope
SerialPort.cpp: In member function 'unsigned char SerialPort::SerialPortImpl::ReadByte(unsigned int)':
SerialPort.cpp:1246:37: error: 'usleep' was not declared in this scope
SerialPort.cpp: In member function 'void SerialPort::SerialPortImpl::Write(const unsigned char*, unsigned int)':
SerialPort.cpp:1427:50: error: 'write' was not declared in this scope
SerialPort.cpp: In member function 'virtual void SerialPort::SerialPortImpl::HandlePosixSignal(int)':

Reported by pulkomandy on 2011-06-29 20:26 UTC
I just downloaded libserial0.5.2 and noticed the config.guess and config.sub files are from 2006. These files are needed by the autotools to detect the host OS. The version from 2006 can't handle my operating system, Haiku. Please update the files to a newer version, which you can get here :

http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob\_plain;f=config.guess;hb=HEAD
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob\_plain;f=config.sub;hb=HEAD

Reported by oschwa2s on 2013-11-28 14:55 UTC
This patch fixes bug #7.

Reported by nikhilmahale on 2012-02-04 14:09 UTC
At the outset I would like to state that I am relatively new to libserial, C++ programming and ROS, so please excuse any obvious mistakes.
I am using libserial to communicate with peripherals, in applications developed using the ROS framework (http://www.ros.org/wiki\). I was experiencing read timeouts (even for large values of timeouts), random wrong data being read from the port, std::runtime_error 's in read and write operations to ports and segmentation faults in random sections of code when using libserial as a part of ROS Nodes (applications). The same programs worked fine when I did not use any ROS components in them. Similarly programs using ROS framework without libserial worked fine.
The only difference I could find was that, programs using ROS components caused a process to spawn multiple threads while without ROS the process executed a single thread.
After some debugging I found that replacing the following code in <SerialPort::SerialPortImpl::Open>
/*

• Direct all SIGIO and SIGURG signals for the port to the current
• process.
  */
  if ( fcntl( mFileDescriptor,
  F_SETOWN,
  getpid() ) < 0 )
  {
  throw SerialPort::OpenFailed( strerror(errno) ) ;
  }

with

/*

• Direct all SIGIO and SIGURG signals for the port to the current
• thread.
  */
  struct f_owner_ex this_thread;
  this_thread.type = F_OWNER_TID;
  this_thread.pid = syscall(SYS_gettid);
  if ( fcntl( mFileDescriptor,
  F_SETOWN_EX,
  &this_thread ) < 0 )
  {
  throw SerialPort::OpenFailed( strerror(errno) ) ;
  }

has solved my problems. I have tested the applications thoroughly. Before applications would crash after running for anywhere from a couple of minutes to some hours. Now they run continuously without any of the above stated errors for as long as required.