Overview
Features
Download
Documentation
Community
Add-Ons & Services

Poco::IO::Serial

Please post support and help requests here.

Poco::IO::Serial

Postby WITTROCK » 20 Oct 2008, 14:57

Sorry if this isn't the right forum for this question as this refers to the Poco::IO library which is currently in the sandbox.

I need to add serial support for a cross platform application in which I am already using Poco. The Poco::IO library seemed like a good place to start. Does someone have some information on the status of the IO library?

A specific problem I have run into is that if I use a SerialChannel, everything works, but when the SerialChannel is destroyed, I get an exception:
Code: Select all
System exception: cannot lock mutex


Following is the simple main for a test application to produce the problem.
Code: Select all

int test::main(const std::vector& args)
{
   if (_helpRequested)   { return  Application::EXIT_OK; }

   Poco::AutoPtr<SerialChannel> pSerial = new SerialChannel(new SerialConfig(
      "/dev/ttyS0",
      SerialConfig::BPS_115200,
      SerialConfig::DATA_BITS_EIGHT,
      'N',
      SerialConfig::START_ONE,
      SerialConfig::STOP_ONE,
      SerialConfig::FLOW_CTRL_SOFTWARE,
      0,//xOn
      0,//xOff
      true,//use EOF
      SerialConfig::DEFAULT_EOF,//EOF
      10,//buffer size
      1000));//timeout

   pSerial->write("hello world");

   return Application::EXIT_OK;
}


After poking around a bit, I notice the following in SerialChannel.cpp
Code: Select all

SerialChannel::SerialChannel(SerialConfig* pConfig):
   Channel(pConfig),
   SerialChannelImpl(static_cast<SerialConfigImpl*>(pConfig))
{
   open();
}


The SerialChannel constructor is passing both ancestors (Channel and SerialChannelImpl) a pointer to the SerialConfig. Both of these classes take ownership of pConfig, so when the SerialChannel is destroyed, both Channel and SerialChannelImpl are attempting to free pConfig.
Just toying around by only passing the pointer to SerialChannelImpl prevented the exception, though I have not looked at the implications of doing this.
I hope that makes sense.

Again, I realize this is from the sandbox, so I'm not expecting things to "work out of the box". I was just wondering if someone might have some pointers on what parts of the IO library might be unfinished at this point. I'd would be happy to help out with the IO library, but as I am still getting my feet wet with Poco, I'm not sure how much value my help will be (:rolleyes:).

Thanks,

-Jeff

As a side note. For now, I modified the SerialChannelImpl classes to just share the _pConfig pointer instead of taking ownership. As the SerialChannelImpl classes are never instantiated on their own but always as an ancestor of SerialChannel, I guess this is O.K.? Unfortunately multiple inheritance is not my thing (:confused:).
WITTROCK
 
Posts: 10
Joined: 06 Dec 2007, 22:29
Location: United_States

Re: Poco::IO::Serial

Postby alex » 20 Oct 2008, 17:14

> Again, I realize this is from the sandbox, so I'm not expecting things to "work out of the box". I was just wondering if someone might have some pointers on what parts of the IO library might be unfinished at this point. I'd would be happy to help out with the IO library, but as I am still getting my feet wet with Poco, I'm not sure how much value my help will be.

The status is that all tests pass on Windows for both Serial and SocketChannel. POSIX just compiles (I fixed few Solaris quirks in the most recent commit) but SerialChannel was not tested at all on any POSIX platform. So any help there is definitely welcome

> As a side note. For now, I modified the SerialChannelImpl classes to just share the _pConfig pointer instead of taking ownership. As the SerialChannelImpl classes are never instantiated on their own but always as an ancestor of SerialChannel, I guess this is O.K.? Unfortunately multiple inheritance is not my thing.

You've got away with it because SerialChannel does not call Channel::config(). SocketChannel, however, does. I'm with you on multiple inheritance. That being said, it is kindof hard to squeeze many different targets behind same interface, so an unbiased review is definitely welcome.

I have added duplicate() calls in all classes owning config pointer, so that should take care of your problem. Another thing I noticed in your code is software control with xon and xoff characters being both zero. On windows that will throw, I don't think I have put that check on POSIX.
alex
 
Posts: 1086
Joined: 11 Jul 2006, 16:27
Location: United_States

Re: Poco::IO::Serial

Postby WITTROCK » 20 Oct 2008, 18:39

Thanks Alex,

I am currently running on Linux and Windows, so if I do nothing else of use, I can at least test.

>I have added duplicate() calls in all classes owning config pointer
When I was toying around here, I did the same thing, only just to the SerialChannelImpl classes as I thought the intent was to have the channel take ownership of the config. When a class should take ownership, and when it should share something like the config is something I'm not very clear on, and I imagine it depends mostly on what the usage will most often be.

For the application I am working on, I also need to be able to manipulate the hardware modem control signals (DTR, RTS, and BREAK), so I added a modemControl() function to the SerialChannel and SerialChannelImpl classes. This is specific to the SerialChannel and does not fit into the Channel base, so I'm not sure it is the best way to handle it. I would be happy to run it past you when it is done in case it is something that is of use, though having to manually control the flow control signals is probably not so common.

Thanks,

-Jeff
WITTROCK
 
Posts: 10
Joined: 06 Dec 2007, 22:29
Location: United_States

Re: Re: Poco::IO::Serial

Postby alex » 20 Oct 2008, 21:04

Jeff,

> I am currently running on Linux and Windows, so if I do nothing else of use, I can at least test.

That would certainly help, thank you.

When a class should take ownership, and when it should share something like the config is something I'm not very clear on, and I imagine it depends mostly on what the usage will most often be.

The sharing is between ConfigImpl and Config. Unfortunately, due to the very different nature of communication channels, it is impossible to put everything behind same interface. For example, since we arunning on top of Net library, SocketChannel uses ChannelConfig directly, whereas SerialChannel must use implementations because we are on top of OS.

> For the application I am working on, I also need to be able to manipulate the hardware modem control signals (DTR, RTS, and BREAK), so I added a modemControl() function to the SerialChannel and SerialChannelImpl classes. This is specific to the SerialChannel and does not fit into the Channel base, so I'm not sure it is the best way to handle it. I would be happy to run it past you when it is done in case it is something that is of use, though having to manually control the flow control signals is probably not so common.

I think the cleanest design would be to have Modem class that uses SerialChannel for its communication. That way, it would also be simpler to contribute your code to the base. We'd certainly appreciate contribution, but quite frankly, I'm currently very tight with time for reviewing. If you want SVN write access, email me: at(aleskx, dot(gmail, com))

IMPORTANT:I have renamed IO to DeviceIO. We decided that long time ago - now that someone is using it besides myself, it was time to do it. Code is in sandbox.

Alex
alex
 
Posts: 1086
Joined: 11 Jul 2006, 16:27
Location: United_States

Re: Re: Re: Poco::IO::Serial

Postby alex » 21 Oct 2008, 03:00

> When a class should take ownership, and when it should share something like the config is something I'm not very clear on, and I imagine it depends mostly on what the usage will most often be.

> The sharing is between ConfigImpl and Config.

Just to clarify, what I meant to say is that, as things currently stand in SVN, you are the owner and config classes share the pointer you pass in.

Since library is still in the sandbox, I definitely welcome a discussion on what is the most appropriate way to design it.
alex
 
Posts: 1086
Joined: 11 Jul 2006, 16:27
Location: United_States


Return to Support

Who is online

Users browsing this forum: No registered users and 2 guests

cron