Serial port programming with multi-thread in C

0
votes

I am writing a gtk application (in C++) to communicate with motor controller through serial port. I am working with Linux Ubuntu and termios lib. I need advice on the best solution to do it. So here are the constraints I have: 1- when i send a request, the controler send me back a message 2- the controler can send me error notification at any time if an error occurs 3- request is ANSII characters string finished with [CR] 4- controller answer is ANSII characters string finished with [CR][NL]

Because of (3) and (4), I thought it was appropriate to configure serial port in CANONICAL mode. Because of the GUI + (2), I thought about multi-threading: a main thread who write user request on serial port and an other infinite thread to read controller answer. Do you think it is a good idea?

Second question: if I am using multi-threading I want to be able to write data when I need it so I have to find a way to stop/sleep the reading thread during writing maybe with pthread_cond_wait. Am I right? I've seen poll and select functions but I don't really understand them and I am not sure they are compatible with canonical mode.

I am getting started with multi-threading and serial port. I read lots of things on google, forum...but the large amount of information is a little overwhelming for a beginner.

Thank you for your help.

1
c++linuxserial-port
The best thing to do is start having a go at it. What you suggest sounds reasonable. When you come up against specific problems or have specific questions come back to SO. - Nick

1 Answers

0
votes

The main thing to consider here for separating the GUI from the serial port is going to be your delays. Are you ever going to be performing any actions that will cause you to need to poll the port for a specific amount of time that would be noticeable to the user? If you are just doing request/reply and the latency of those is really low your user probably wouldn't notice any of those delays. Additionally receiving those asynchronous error messages would also not cause any sort of noticeable delay I would imagine. Unless you know for a fact that there could be numerous seconds of delay after an Init message or something like that gets sent to the controller it will probably make your life much simpler to keep the application single threaded.

On the other hand if there will be those large latencies or you just want to mess around with multi thread I would just start with 1 thread that does all the GUI work and another thread that handles all the serial IO. Use message passing or event notification between those two threads for coordinating your activities and it should be pretty straight forward.