Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ Library support » U++ Library : Other (not classified elsewhere) » About RS232
Re: About RS232 [message #26981 is a reply to message #25665] Wed, 16 June 2010 16:55 Go to previous messageGo to next message
mr_ped is currently offline  mr_ped
Messages: 825
Registered: November 2005
Location: Czech Republic - Praha
Experienced Contributor
nixnixnix wrote on Sun, 07 March 2010 00:33

Ok here is what I've got. Its clumsy but it works for both Windows and Linux. I have attempted to modify Didier's code to provide a more unified interface but it could be done a lot better.

Basically it does what I need just now and like I say it works on both platforms. My main addition is to provide a common Open function as well as an IsOpen function.

Nick


Did this evolve further? The attached source code is a bit unfinished, although it works. (I mean MS Win code path)

I think it has everything I need for now, but I don't like to use unfinished code with dead variables and code, so I wonder if there's something more fresh, or I can clean it a bit and upload back here.
Re: About RS232 [message #26982 is a reply to message #3788] Wed, 16 June 2010 16:57 Go to previous messageGo to next message
mr_ped is currently offline  mr_ped
Messages: 825
Registered: November 2005
Location: Czech Republic - Praha
Experienced Contributor
And I will be very likely creating some mock object for UnitTest++ to be able to test rest of classes, I don't expect anyone of you did such mock already, but in case somebody did, please share. Smile
Re: About RS232 [message #26986 is a reply to message #26981] Wed, 16 June 2010 22:08 Go to previous messageGo to next message
Didier is currently offline  Didier
Messages: 680
Registered: November 2008
Location: France
Contributor
Hi mr_ped,

I didn't have time to make it evolve.
Feel free to make it evolve if you wan't.

But I think it's better to have enums for speed/parity/... instead of a config string like in windows version: it's easyer to use and debug.

Re: About RS232 [message #28167 is a reply to message #3788] Fri, 20 August 2010 01:30 Go to previous messageGo to next message
jeremy_c is currently offline  jeremy_c
Messages: 175
Registered: August 2007
Location: Ohio, USA
Experienced Member
Where can one find wxSerial? It seems to be hiding from me :-/

Jeremy
Re: About RS232 [message #28169 is a reply to message #28167] Fri, 20 August 2010 08:23 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3355
Registered: August 2008
Senior Veteran
jeremy_c wrote on Fri, 20 August 2010 01:30

Where can one find wxSerial? It seems to be hiding from me :-/

Jeremy

Hello Jeremy

wxSerial refers to wxWindows serial support. It cannot be used here.

I am not sure about the status of the serial support in U++. Now it seems to be:

- nixnixnix has included in Forum (in this post) a serial class for Linux and Windows
- jerson has done a class for Windows to be posted
- Mindtraveller has done a more complete class but is part of a closed source package


Best regards
Iñaki
Re: About RS232 [message #28172 is a reply to message #3788] Fri, 20 August 2010 10:00 Go to previous messageGo to next message
jerson is currently offline  jerson
Messages: 202
Registered: June 2010
Location: Bombay, India
Experienced Member

Yes, I have a working single threaded version of the serial port class and I have tested it with WinXP. Posted here http://www.ultimatepp.org/forum/index.php?t=msg&th=5401& amp;start=0&
Re: About RS232 [message #28176 is a reply to message #3788] Fri, 20 August 2010 13:58 Go to previous messageGo to next message
jeremy_c is currently offline  jeremy_c
Messages: 175
Registered: August 2007
Location: Ohio, USA
Experienced Member
Last night I grabbed a copy of libctb (https://iftools.com/opensource/ctb.en.php). I modified the source a bit and made a U++ package out of it. So now I just say Add Package, Ctb and my app has serial support.

I have not tested it yet under linux but will be doing so shortly. The only problem with what I did was I had to change several headers for the package. For example, the ctb package uses:

#include "ctb-0.15/abcdef.h"


I changed these to read:

#include <Ctb/abcdef.h>


So, with each update to libctb, that would have to be done. Is there a better way? I wanted to let U++ handle the building of the package.

I started with Serial.h/.cpp that I found here and it worked fine for some devices I was controlling but not for others. I needed the ability to set 2 stop bits, to raise the DTR and RTS states, etc...

I am not sure what is the best idea here. To keep my Ctb package or to browse it's source, learn how the Data Bits, Parity, Stop Bits and Line States are set/queried and port them to the Serial.h/Serial.cpp. I kind of liked the Serial.h/.cpp's function ReadDataWaiting(). w/Ctb you can read X number of bytes with a timeout but say you want 30 bytes, Readv(buf, 30); may result in a partial read, i.e. maybe 15 were available before the timeout occurs. You'll get the 15. With Serial.h/.cpp I could enter a loop and say:

tries = 0;
while (ReadDataWaiting() < 30) {
  tries++;
  if (tries > 3) do_fail_code();
  Sleep(50);
}


Jeremy
Re: About RS232 [message #28178 is a reply to message #28176] Fri, 20 August 2010 14:30 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3355
Registered: August 2008
Senior Veteran
Quote:

So, with each update to libctb, that would have to be done. Is there a better way? I wanted to let U++ handle the building of the package.
In "Package Organizer" you can set with "Internal Includes" additional folders to look for includes.


Best regards
Iñaki
Re: About RS232 [message #29834 is a reply to message #28178] Sun, 21 November 2010 02:17 Go to previous messageGo to next message
nlneilson is currently offline  nlneilson
Messages: 644
Registered: January 2010
Location: U.S. California. Mojave &...
Contributor
What is the current status of what is included in Upp for:
RS232, serial port, COM port, or whatever the designation or how it is wrapped.

I am currently using 2827 but could update.

I am interested in the #include and the few lines of code required to hook up to serial port.

Python uses PySerial
Java uses rxtx (note that Oracle/Sun has dropped support for comm)
Win uses System::IO::Ports;
I have good results with all of these.

Since I am not that experienced with Upp a simple complete package with an example (like those in the "examples" folder included with Upp), if there is one, would be appreciated. Otherwise I spend several hours on something very basic before getting something to compile/link.

There is info in the thread like:
jerson's CommPak.zip
Pavel's 4.zip
Didier' SerialPort.tgz
Nick's Serial.cpp, Serial.h

As mentioned an example that works with what is included in the Upp install is what is preferred, or with least addition of header files or ??.

luzr wrote on Mon, 26 June 2006 20:05

While there is no specific support, it is still regular C++, so everything you can do in C/Win32 API (or C/Posix/Linux API), you can do in U++ too...
Mirek


I try to use:
using namespace System::IO::Ports;
from my existing code that runs in MSVC that gives errors in Upp.
Re: About RS232 [message #29839 is a reply to message #29834] Sun, 21 November 2010 13:49 Go to previous messageGo to next message
nlneilson is currently offline  nlneilson
Messages: 644
Registered: January 2010
Location: U.S. California. Mojave &...
Contributor
jerson's CommPak.zip gives the info I needed.

#include "Serial.h"
and Serial.h needs to be in the package.

	if (!CommPort.Open(6,57600))
		Exclamation("Cannot open COM6");
	else
		SetTimeCallback(-100,THISBACK(CheckRxTmr), idRxTimer);


That is what I needed!

Getting the data from GPS receivers will be done in a separate thread.

The porting of my code from Java (it's later and more extensive than the MSVC code) should be straight forward.

Thanks jerson for the example.

Neil
Re: About RS232 [message #29840 is a reply to message #29839] Sun, 21 November 2010 16:21 Go to previous messageGo to next message
jerson is currently offline  jerson
Messages: 202
Registered: June 2010
Location: Bombay, India
Experienced Member

Thanks Neil. I'm glad my work has been useful to you.
Re: About RS232 [message #29846 is a reply to message #3788] Sun, 21 November 2010 22:06 Go to previous messageGo to next message
nlneilson is currently offline  nlneilson
Messages: 644
Registered: January 2010
Location: U.S. California. Mojave &...
Contributor
That was very useful!

Having an example that can be downloaded, unzipped, placed in MyApps, opened in TheIde, select execute, and have it compile/link/run is great.

For someone that is fairly new to Upp getting a few lines of code and trying to get it to run is very frustrating and takes time.

I did notice that the pull down menu in the Setup Comms box for baud rate does not include these.
115200
57600
38400
These cannot be seen/picked even though they are listed in Serial.h. I added them in main.cpp line 57:
int Port,Baud[]={1200,2400,4800,9600,19200,38400,57600,115200};


Whoever ported the code from C++ to be compatible in Upp in Serial.h and Serial.cpp did a good job.

Neil

[Updated on: Sun, 21 November 2010 22:51]

Report message to a moderator

Re: About RS232 [message #29855 is a reply to message #3788] Tue, 23 November 2010 03:50 Go to previous messageGo to next message
nlneilson is currently offline  nlneilson
Messages: 644
Registered: January 2010
Location: U.S. California. Mojave &...
Contributor
Looking at Serial.h and Serial.cpp they were not familiar to what I have previously used.

To help someone else this is what was done.
In my Python and Java code and the reason for doing it this way.
1. Loop through the ports from COM4 to COM20 (COM3 is the default for Win printer).
2. Loop through the ports to check the baud rate.
3. Open each port that returns the NMEA GPS GGA sentence that run concurrently, three is the most tried so far without threads, no problems.

Here is a snip of code to work with the Serial.h and Serial.cpp
    Thread work;

    void OpenAction() {
		if (!CommPort.Open(6,57600)) Exclamation("Cannot open COM6");
	 	Sleep(1000);
	   	work.Run(THISBACK(Work));
    }
    void Work(){
		char ch;
		char buf1[1];
		String St1;
		while (CommPort.ReadDataWaiting() ) {
			CommPort.ReadData(buf1, 1);
			ch = buf1[0];
			if(ch!='\n' || ch!='\r')St1 << ch;
			if(ch=='\n'){
				Data<<=St1;
                                ...
	 		        Sleep(980);

The COM port and baud is hard coded here, the app will find and insert these parameters.

Note the Sleep(1000); before the work thread is run and Sleep(980);, otherwise the ReadDataWaiting() is empty.
This reads a char at a time but the parameter has to be a char buf, hence the necessity for char buf1[1];

This is very basic but shows how you can get data from a serial port you can work with. There is also a lot of try/catch, if(...), continue, break, parse(...), send(...), swear(), etc..

[Updated on: Tue, 23 November 2010 05:06]

Report message to a moderator

Re: About RS232 [message #39393 is a reply to message #3788] Fri, 15 March 2013 14:40 Go to previous messageGo to next message
jibe is currently offline  jibe
Messages: 294
Registered: February 2007
Location: France
Experienced Member
Hi,

Is there something new about all that ?

There is already some good job done. If I don't forget anything, we have those works :

- Mindtraveller (Pavel) 4.ZIP Oct 12, 2008
- Didier SerialPort.tgz Feb 05, 2010
- nixnixnix (Nick) Serial.h and Serial.cpp Mar 07, 2010
- jerson CommPak.zip Aug 06, 2010

What about starting from all that to build a final package and add it to upp, at least in bazaar ?

If now PC have often no more COM ports, RS232 is still used a lot in industry. More : several USB devices have a driver allowing to use them as a COM device. Such a package would be very useful !

I could try to do it... Any help or suggestion will be appreciated, especially what is interresting or missing in every package above and how they could (or not...) be mixed together.

Re: About RS232 [message #39396 is a reply to message #3788] Fri, 15 March 2013 15:55 Go to previous messageGo to next message
jibe is currently offline  jibe
Messages: 294
Registered: February 2007
Location: France
Experienced Member
A first study of the code confirms what I was guessing reading the thread : nixnixnix and jerson codes are just enhancements of Didier's code. So, I think that the best is just to use the most recent one, that is jerson's.

Mindtraveller's code seems to be interresting, but very different and more complicated. So, I think that it's better to start from jerson's, isn't it ?

I worry why Windows part is so different from Linux part ? When I compile jerson's CommPack, I get errors with missing members !

For me, the whole structure of the class should be the same for Windows and Linux, no ? Any reason/explanation about those different members ?
Re: About RS232 [message #39397 is a reply to message #39396] Fri, 15 March 2013 16:00 Go to previous messageGo to next message
jerson is currently offline  jerson
Messages: 202
Registered: June 2010
Location: Bombay, India
Experienced Member

Hello Jibe

I am not sure what kind of errors you get. I use only the windows platform and the code works well on it. I never have used/tried a compile on Linux, so, possibly the errors are there; I don't know.

I'd like to collaborate if there is any movement on this and may also add the modbus RTU feature if prodded. Right now, I am juggling too many things and time sharing is hard.

Regards
Jerson
Re: About RS232 [message #39398 is a reply to message #39393] Fri, 15 March 2013 16:04 Go to previous messageGo to next message
Zbych is currently offline  Zbych
Messages: 325
Registered: July 2009
Senior Member
If you want I can help you with linux part of serial port implementation.

First you should tell me what interface you want.

My proposition:

1. Vector<String> ListPorts();
returns list of available ports. On windows you can use QueryDosDeviceW to get list of devices. On linux udev does similar thing.

2. bool Open(const char * port_name, enum speed, enum flow_control, enum parity)

3. void Close()

4. int Write(const void * data, int len, int timeout_ms = 5000);
5. int Write(String data, int timeout_ms = 5000);

6. String ReadUntil(int amount, int stop_byte = -1, int timeout_ms = 5000);

7. void FlushInput();
to clean input queue

8. void FlushOutput();
to clean output queue

I would like to have timeouts in every Write and Read functions, because they often depend on the command you send to device.

Things like stop_byte are useful for communication with modems.

Maybe we should also have Callbacks (when new data arrive, when usb serial device is (un)plugged)?

[Updated on: Fri, 15 March 2013 16:08]

Report message to a moderator

Re: About RS232 [message #39409 is a reply to message #39397] Fri, 15 March 2013 22:45 Go to previous messageGo to next message
jibe is currently offline  jibe
Messages: 294
Registered: February 2007
Location: France
Experienced Member
Thanks for the replies Smile

jerson wrote on Fri, 15 March 2013 16:00

I am not sure what kind of errors you get. I use only the windows platform and the code works well on it.

... And I'm almost sure that it can work with Linux as well : As I said, it's just that there is not the same methods ! I had just a quick try and did not study well all that, probably it's just different names...

I posted immediately before going further just to know if there is some good reason. If not, I'll just make so that the class is exactly the same for Linux or Windows, as far as possible.

jerson wrote on Fri, 15 March 2013 16:00

I'd like to collaborate if there is any movement on this and may also add the modbus RTU feature if prodded. Right now, I am juggling too many things and time sharing is hard.

You do as you can according to your free time. If it's possible for you, I'll let you try and eventually debug the Windows part, as I'm working only under Linux.

Zbych wrote on Fri, 15 March 2013 16:04

If you want I can help you with linux part of serial port implementation.

First you should tell me what interface you want.

Thanks Smile

But for now, I'm just beginning to discover what has been already done. I think that it will be enough for what I have to do (just read the output of an A/D converter and display the signal like an oscilloscope).

I'll see later in more details your proposition, when I'll know better jerson's package. I think it's already good, but could be better with some enhancements or additions like a more complete Open function with flow control and parity as you propose : if we make a package to add to upp, it must be some more complete.

[Updated on: Fri, 15 March 2013 22:47]

Report message to a moderator

Re: About RS232 [message #39450 is a reply to message #39409] Sat, 16 March 2013 22:40 Go to previous messageGo to next message
nlneilson is currently offline  nlneilson
Messages: 644
Registered: January 2010
Location: U.S. California. Mojave &...
Contributor
The best serial port code of all I have tried is from M$.

It is managed code and Sender Ghost was good to help on getting it to work in a U++ app.
http://www.ultimatepp.org/forum/index.php?t=msg&goto=383 03&&srch=serial#msg_38303

My use is specifically for GPS data.
If I recall it was jerson's and nixnixnix's code I tinkered with the most of all that are listed in this thread.

[Updated on: Sat, 16 March 2013 22:45]

Report message to a moderator

Re: About RS232 [message #39460 is a reply to message #39450] Sun, 17 March 2013 08:56 Go to previous messageGo to previous message
Mindtraveller is currently offline  Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.
Experienced Contributor

Let me share some thoughts on serial port communication as industrial automation developer. Critics is welcome.
First of all, the main idea behind all this functionality is sending and receiving some actual data to/from PC. The most common scenario is to send request and receive answer (PC = master, device = slave). We also must understand highly asynchronous nature of all these tasks, because at no circiumstances serial port i/o must be done in common thread (especially when it handles GUI). The next idea is crossplatform code, because our great U++ framework is crossplatfrom too. The last requirement is the ease of tuning: most of time we need to tune some parameters of serial port "on the field", and we must me able to do it without recompiling our code.
These features put together really professional-grade serial library.
Let's recollect them, dividing by levels of abstraction:

1. Port handling and I/O (lowest level).
Crossplatform code handling system-dependent serial port code.
Done with tiny library called crossplatserial with my little modifications. It has Apache license (which is the same as BSD, AFAIK).
This level creates SerialPort objects from external file or code. So if you need to tune i.e. the baudrate, you just change external file and restart your app.
I attach crossplatserial to this message and you may use it, if it is all that you want.

2. Datagramms <-> values (protocol stuff).
Actually the main code should work with data. Not with actual bytes you send through serial port. I achieved it with my BNF library which is responsible for using protocols.
That is how it works:
You have external file defining a protocol. BNF takes plain bytes and returns Vector<Value> and back. For example:
***modbus   (crc_start byte byte word_be word_be crc_end crc_modbus) 
          | (crc_start byte byte byte    word_be crc_end crc_modbus);
***icp_din_clear_request   "$" HEX:2 "C" "\0D";
***icp_din_clear_answer    (("!" arg:1 HEX:2)  | ("?" arg:0 HEX:2)) "\0D";

Ok. On this level we've left protocols behind and made possible for SerialPort to work with actual Vector<Value> (not with plain bytes). I repeat that protocol is defined in external file, so if you need to tune it, you just change protocol description in file and restart your app. Extremely useful in some cases "in the field".

3. Asynchrony (highest level).
IMO the ideal approach for asynchrony of serial i/o is using queued threads. This means each thread has it's queue and you put there this thread's callback with custom parameters. That is how threads interact, no syncronization objects needed.
This is done with bazaar/MtAlt package I wrote some time ago.
In spite of this frightening description, the actual use of this is simple. Let's look at real-world example:
class SensorNB3000: public SerialPortNotify<CallbackQueue> {/*...*/}; //creates callback queue

void SensorNB3000::RequestMeasure()
{
	Vector<Value> args;
	args << ((int) addr.GetData()) << 6 << 50 << 1;
	sensorPort->SendReceiveSleep_(PREPARE_TIMEOUT_NB3000);
	sensorPort->SendReceive_
	(
		"modbus",
		args,
		"modbus",
		RECEIVE_TIMEOUT_NB3000,
		NULL,
		Ptr<SiloSensorNB3000>(this),
		&SensorNB3000::OnMeasure
	);
}

void SensorNB3000::OnMeasure(bool result, Vector<Value> args, void *custom)
{
    //...
}

This code means: SensorNB3000 class adds some timeout to sensorPort thread queue and then requests send/receive operation with modbus protocol. Send modbus args are {addr,6,50,1} and the handling routing is OnMeasure. The SensorNB3000::OnMeasure() routine is syncroneously called in the SensorNB3000 thread (no sync is needed in your code!).

Here are the most of the concepts I propose. If you find them too comlicated, you may just use attached library. If you consider using all these levels of abstraction in U++, we may discuss it further.

[Updated on: Sun, 17 March 2013 09:00]

Report message to a moderator

Previous Topic: templated callback
Next Topic: Memory Mapped Files
Goto Forum:
  


Current Time: Thu Mar 28 17:24:58 CET 2024

Total time taken to generate the page: 0.01447 seconds