LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Programming (https://www.linuxquestions.org/questions/programming-9/)
-   -   Linux serial port programming clash (https://www.linuxquestions.org/questions/programming-9/linux-serial-port-programming-clash-224769/)

Onyx^ 08-31-2004 08:17 AM
Linux serial port programming clash
 
Hi there,

I have a Linux system that includes a touchscreen runs a program to monitor com2 for touchscreen comms.

I have also written a custom program that communicates over the serial ports. Both programs work independantly fine, but if I run my program it *breaks* the touchscreen. I assume this is because my signal handler on the comm ports in my custom program is grabbing the IO that is intented for the touchscreen...

Is there a way to block the signal handler from grabbing comms from a specific com port? (sa_mask? status in signal handler?)

Here is my current code where I install the signal handler & the signal handler itself.
Code:
struct sigaction saio;

void signal_handler_IO(int status)
{
    wait_flag = FALSE;  // for thread communication.
}

...

saio.sa_handler = signal_handler_IO;
//saio.sa_mask = 0;
saio.sa_flags = 0;
saio.sa_restorer = NULL;
sigaction(SIGIO,&saio,NULL);

Stor_G 08-31-2004 08:38 AM
one small question: do the program you wrote and the touch screen work on the same serial port?
maybe if your program could listen on another serial port if you have one on your system.

if not, i don't see a way your program could wait for serial data when the screen is connected anyway.
if you could explain how you can use the screen and another program on the same serial line and get data for each of them maybe i'll be able to help you...

Onyx^ 08-31-2004 08:41 AM
Nope, my program communicates on com1, com3, and com4

The touchscreen communicates on com2...

Stor_G 08-31-2004 08:52 AM
ohh i understand
the signal tells you when there's incoming data on a serial line. but it doesn't specify which.

is this correct?
if it is, have you considered using a select call?
try to read it up in the man if you don't know it.

Code:
man select
or
man select_tut
basically it allows you to monitor several file descriptors so u can monitor specifically the file descriptors related to Com 1 3 and 4 and ignore Com 2.

Onyx^ 08-31-2004 09:17 AM
yes i am using select along with a fdset to just monitor com1, com3 and com4 within my program.

However even ignoring com2 within my program it is still interfering with the touchscreen drivers
:rolleyes:

Stor_G 08-31-2004 09:24 AM
Quote:
Code:
struct sigaction saio;

void signal_handler_IO(int status)
{
    wait_flag = FALSE;  // for thread communication.
}

...

saio.sa_handler = signal_handler_IO;
//saio.sa_mask = 0;
saio.sa_flags = 0;
saio.sa_restorer = NULL;
sigaction(SIGIO,&saio,NULL);
in what part of your program do you have this code above?

Onyx^ 08-31-2004 09:56 AM
the signal handler is installed once at the beginning of execution of my program.

The signal handler code itself sets a flag to false. In the main while loop of my program this flag is examined, and if it has been triggered it knows to go ahead process the information from the serial port (using a select call to find which com port the data has arrived on).

Hope this information is helpful...

bruce ford 08-31-2004 02:18 PM
Hi,

I think the select() part of your program would be more interesting for investigations about this problem. Why do you use signal driven i/o at all?
I have a program that monitors 128 network connections AND 128 serial ports using select() in a single thread without using any signals.

so long...
bruce

Stor_G 08-31-2004 11:00 PM
Quote:
I think the select() part of your program would be more interesting for investigations about this problem. Why do you use signal driven i/o at all?
i tend to agree with this approach.
you can create a thread that blocks on select indefinately or until woken/interrupted without registering the IO signal.
However, before doing that, i recommend commenting out the part in your code that handles the signal and see if it has any affect on the touchscreen.
if it has, return the signal handler code, and comment out all other code that relates to serial access (select, read, write etc...) to make sure that it's the signal capturing that causes the problem.

that way you can be sure that you know what the problem is and you won't spend hours/days (depending on system complexity) making adjustments that eventually won't advance you at all towards a complete stable system.

Onyx^ 09-01-2004 04:16 AM
ah yes, thanks for the advice so far stor_g / bruce_ford

I will try removing the signal handler (although this will mean that the the serial ports are only initialised but never checked) to see if I still have a problem. Narrowing down what is causing it is a definate next step.

I am using the signal handler because of the unique structure of the program which has been ported from a rabbit microprocessor to linux.

Stor_G 09-01-2004 05:15 AM
keep us posted about how it goes
:)


All times are GMT -5. The time now is 12:05 AM.