serial communication in linux with C++?

[Red Squirrel]

Anyone know of a good tutorial on this? I'm finding some stuff on google but it seems more complicated than I expected. I would assume this is very similar to network sockets, but just different functions/classes.

 

[postmortemIA]

Reading/writing to a serial port is pretty much like reading/writing to a file. And this is so low level that you will interface with system libraries defined in C, not C++.

 

[Modelworks]

It is nothing more than reading and writing to ttys0 or whatever your port is called. There is no default protocol because it is just an interface so if you want to use it for other things you will need to handle that in your software.

Steps I use are:
initialize the port with your settings, 9600 baud, 8, N, 1
allocate some buffers for the port
open the port
send / receive data
flush buffers
close port

 

[Red Squirrel]

Yeah but HOW do I do that? What are the functions/classes I use etc? Files I need to include?

Do I actually use fstream?

 

[Nothinman]

Yeah but HOW do I do that? What are the functions/classes I use etc? Files I need to include?

Do I actually use fstream?

Yes, they work just like files. Why don't you grab the source from something like minicom, gtkterm, etc and see how they do it?

 

[Cogman]

http://embedded.seattle.intel-research.net/wiki/index.php?title=Using_other_UARTs_in_Linux

You might find this useful.

 

[degibson]

Yeah but HOW do I do that? What are the functions/classes I use etc? Files I need to include?

Do I actually use fstream?

If you want to roll your own layer, I recommend you use the native system call interfaces rather than any buffered I/O.

#include <unistd.h>
man 2 read
man 2 write
man 2 open

 

[Red Squirrel]

Thanks that's what I was looking for, I'll take a look at those functions.

 

[Nothinman]

Thanks that's what I was looking for, I'll take a look at those functions.

Those are the standard C file operation instructions, how do you not know about them?

 

[Red Squirrel]

Never did serial communication before. For files I use fstream. I've used functions called that, but it was for tcp/ip networking.

 

[Nothinman]

Never did serial communication before. For files I use fstream. I've used functions called that, but it was for tcp/ip networking.

Technically you should be able to use fstream for serial access as well, as long as you make sure it's doing unbuffered I/O. I don't know if there's any other gotchas with that though. That's why I recommended taking a working OSS app for serial access and seeing how it works as an example.

 

[Red Squirrel]

Between some online research and looking at the source of picocom, I figured it out.

Just in case it ever helps someone in the future, this is my app:

#include <iostream>
#include <fstream>

#include <fcntl.h>

using namespace std;


#include "includes.h"
#include "sources.h"


int main()
{
	cout<<endl;
	
	
	
	int fd1;

	int fd2;

	char * buff = new char[2];

	int wr,rd,nbytes,tries;	
	
	
	fcntl(fd1, F_SETFL, O_NONBLOCK);
	
	fd1=open("/dev/ttyACM0", O_RDWR | O_NONBLOCK);
	
	
	
	
	if (fd1 == -1 )
	{
		cout<<"Error connnecting";
	}
	else
	{
		fcntl(fd1, F_SETFL,0);
		
		
		
		wr=write(fd1,"\r\nch2.gettemp\r\n",15);
		
		
		
		wr=write(fd1,"\r\nrels.get\r\n",12);
		
		
		//read a bunch of lines
		for(int i=0;i<10;i++)
		{
			
			//read a single line:
			
			string data="";
			
			rd=0;
			int bytes=0;
			do
			{
				bytes= read(fd1,buff,1);
				
				if(buff[0]=='\r')
				{
					read(fd1,buff,1);//read the following char which should be \n
					break;
				}
				else
				{			
					data.append(1,buff[0]);  
				}
			}while(bytes>0);
			
			
			
			cout<<endl<<"buff: "<<data<<endl;
		}
		
		
		
	
	
	}
	
	
	close(fd1);
	
	
	

	cout<<endl;
	return 0;
}

It does not do much, just a prototype, but it's all together in a single program so it's easy to follow. It really does seem to be as easy as treating it like a file, though the only difference is the ability to read and write to it at the same time.


For the actual usability I will be reading first to ensure I'm at the prompt, then send the command, and then read the output and then wait for the prompt again etc... It seems it also echos back whatever is sent so I have to ensure I handle that properly. This probably depends on the device though, some may echo while others wont.