Userspace serial communication, cleanup using comp

More
07 Jul 2014 16:52 #48481 by DaBit
I did an initial effort to create a userspace HAL component to control a Danfoss VLT5000 series VFD .

It works, but it needs a few improvements, there are a few bugs left and it could use some cleanup.
I am not really comfortable with Linux programming, so I do have a few questions. Not all LinuxCNC related, I hope you guys don't mind.

1) Serial port programming.

I open the port this way:
/* Open the serial port with device 'serialdevice', 9600 baud, 8 databits, 1 stopbit and even parity */
	fd = open(MODEMDEVICE, O_RDWR | O_NOCTTY);
	if (fd < 0)
	{
		perror(MODEMDEVICE);
		exit(-1);  
	}
	
	tios.c_cflag = B9600 | CS8 | PARENB | CLOCAL | CREAD;
	tios.c_iflag = IGNPAR;
	tios.c_oflag = 0;
	tios.c_lflag = 0;       //ICANON;
	tios.c_cc[VMIN]=1;
	tios.c_cc[VTIME]=1;
	if (tcflush(fd, TCIFLUSH)) { perror(MODEMDEVICE); exit(-1); }
	if (tcsetattr(fd,TCSANOW,&tios)) { perror(MODEMDEVICE); exit(-2); }

where MODEMDEVICE is /dev/ttyUSB1, an FTDI FT232R based USB->RS485 module.
I want blocking I/O with a small timeout, which I intended to set with 'tios.c_cc[VTIME]=1'.

Now, as long as communications work like it should, this is OK. But I have seen something going wrong somewhere, and then write(fd, ...) and read(fd, ...) calls block indefinitely. Reading the documentation better also reveals that termios.c_cc[VTIME] is the inter-character timeout, and it doesn't affect the waiting time for the first character to arrive.

How do I setup the serial port in such a way that read() and write() always return after some timeout? I suppose I could switch to nonblocking mode (either 'real' or by setting VMIN = 0 and VTIME = 0), but I suspect that there is an option to have read() return '0 bytes read' after some timeout?


2) Cleanup in comp.
In a userspace HAL component I do have a userinit() function. But where do I perform cleanup such as closing file descriptors when the component is terminated?

Please Log in or Create an account to join the conversation.

More
07 Jul 2014 17:12 #48483 by ArcEye
Hi

For what it is worth here is a test serial component I wrote whilst playing with an arduino.

It certainly answers your query No 2) in the EXTRA_SETUP and EXTRA_CLEANUP macros in comp

I have probably forgotten more than I remember about why I set it up this way, but VTIME = 0 worked for my purposes

regards

/********************************************************************************

*********************************************************************************/

component arduinoserial3             "Testing serial comms within hal";

// pins are numbered to reflect actual pin number on Duemilonove board
pin io bit digital2 = false;
pin in bit digital3 = false;
pin in bit digital4 = false;
pin in bit digital5 = false;
pin in bit digital6 = false;
pin in bit digital7 = false;

pin in bit digital8 = false;
pin in bit digital9 = false;
pin in bit digital10 = false;
pin in bit digital11 = false;
pin in bit digital12 = false;
pin in bit digital13 = false;

pin in bit digital14 = false;  // pins 14 -19 are analog 0 - 5
pin in bit digital15 = false;
pin in bit digital16 = false;
pin in bit digital17 = false;
pin in bit digital18 = false;
pin in bit digital19 = false;



option singleton yes;               // makes no sense to have more than one of these components running 
option extra_setup yes;             // use this to open port
option extra_cleanup yes;           // use this to close port

author "ArcEye";
license "GPL";
;;

#include <stdio.h>    /* Standard input/output definitions */
#include <stdlib.h> 
#include <stdint.h>   /* Standard types */
#include <string.h>   /* String function definitions */
#include <unistd.h>   /* UNIX standard function definitions */
#include <fcntl.h>    /* File control definitions */
#include <errno.h>    /* Error number definitions */
#include <termios.h>  /* POSIX terminal control definitions */
#include <sys/ioctl.h>
#include <sys/signal.h>
#include <sys/types.h>

#define BAUDRATE B9600
#define DEVICE "/dev/ttyUSB0"
#define _POSIX_SOURCE 1 /* POSIX compliant source */
// standard serial comms defs
#define START '\x02'
#define END '\x03' 
#define ACK '\x06'       
#define NAK '\x15'


#define bitRead(value, bit) (((value) >> (bit)) & 0x01)
#define bitSet(value, bit) ((value) |= (1UL << (bit)))
#define bitClear(value, bit) ((value) &= ~(1UL << (bit)))
#define bitWrite(value, bit, bitvalue) (bitvalue ? bitSet(value, bit) : bitClear(value, bit))


int fd;                             // file descriptor
struct termios oldtio,newtio;       // new and saved old port setup
unsigned char digital_bits[18];

int setupSerialPort()       
{
      fd = open(DEVICE, O_RDWR | O_NOCTTY ); 
        if (fd <0)
            {
            perror(DEVICE); 
            exit(-1); 
            }
        
        tcgetattr(fd,&oldtio); /* save current port settings */
        
        bzero(&newtio, sizeof(newtio));
        newtio.c_cflag = BAUDRATE | CRTSCTS | CS8 | CLOCAL | CREAD;
        newtio.c_iflag = IGNPAR;
        newtio.c_oflag = 0;
        
        /* set input mode (non-canonical, no echo,...) */
        newtio.c_lflag = 0;
         
        newtio.c_cc[VTIME]    = 0;   /* inter-character timer unused */
        newtio.c_cc[VMIN]     = 5;   /* blocking read until 5 chars received */
        
        tcflush(fd, TCIFLUSH);
        return( tcsetattr(fd,TCSANOW,&newtio) ); // -1 for error 0 is OK

}

// 3 byte packet, first 6 bits of each contain bit values

void user_mainloop(void)
{
int i, x;
char ch;
       
    
    while (fd != -1) 
       {
       
       usleep(1000000);//approx 1 sec
       
       FOR_ALL_INSTS()
            {
            x = 0;
            for (i = 0; i < 3; i++)                 
                {
                read(fd,&ch,1); 
                for (i = 0; i < 6; i++)
                    {
                    digital_bits[x++] =  bitRead(ch, i);
                    }
                }
                
            for (i = 0, x = 0; i < 18; i ++)
                fprintf(stderr,"DIGITAL%d = %s\n", x,digital_bits[x]);
            }
       }
    fprintf(stderr, "Exiting");
    exit(0);
         
}



EXTRA_SETUP()
{
     if(setupSerialPort() == -1)
        {
        fprintf(stderr,"Error opening ttyUSB0");
        }
//     digital_bits[0]= digital2; digital_bits[1]= digital3; digital_bits[2]= digital4; digital_bits[3]= digital5; digital_bits[4]= digital6;
//     digital_bits[5]= digital7; 
//     digital_bits[6]= digital8; digital_bits[7]= digital9; digital_bits[8]= digital10; digital_bits[9]= digital11; digital_bits[10]= digital12; 
//     digital_bits[11]= digital13; 
//     digital_bits[12]= digital14; digital_bits[13]= digital15; digital_bits[14]= digital16; digital_bits[15]= digital17; digital_bits[16]= digital18; 
//     digital_bits[17]= digital19; 
}

EXTRA_CLEANUP()
{
    tcsetattr(fd, TCSANOW, &oldtio);
    close(fd);
    fprintf(stderr,"All cleaned up");
}

Please Log in or Create an account to join the conversation.

More
07 Jul 2014 19:00 #48488 by DaBit
Thanks!

Probably you didn't mind whether the serial I/O blocked or not; only one instance is allowed anyway (option singleton yes).

In my case one can have more than one VFD on the bus so serial I/O that blocks indefinitely because it waits for a status packet that is not going to come is impractical. Probably I should switch to nonblocking I/O and do the timeouts myself.

Please Log in or Create an account to join the conversation.

More
07 Jul 2014 19:54 #48489 by ArcEye
You are right, there was only one device so only one source of data, so blocking was not an issue

Looking at my notes from the time when I was writing the serial comp, the best way I found to to make it non blocking was to have the line

fcntl(fd, F_SETFL, FNDELAY);

after the port is opened.

The FNDELAY makes a read() return 0 if no data is present and prevents blocking
Just have to write the routine a bit differently to cater for 0 returns.

regards

Please Log in or Create an account to join the conversation.

More
10 Jul 2014 05:40 #48598 by DaBit
I switched to c_cc[VTIME] =0 and c_cc[VMIN] =0; this is basically nonblocking I/O. read() return 0 when no bytes are available, and I do the timeout myself. This works far better.

Now I still do have a problem, but that's Linux-related I guess: when I reboot the computer with the USB->serial device attached I cannot communicate. Probably there is no valid data sent over the line.since I do not see the receive status-LED on the converter lighting up, but I do see the transmit LED light up.

When I plug in the device after Linux has booted, everything is fine.

So Linux does something with /dev/ttyUSB1. What, and how do I turn that off?

Please Log in or Create an account to join the conversation.

More
10 Jul 2014 15:22 #48605 by ArcEye
Hi

What does dmesg show during the boot for that port and usb devices generally?

How does that differ from what tail -f /var/log/messages shows you when you plug in after boot has finished?

I would guess it is something to do with udev, but not just simply that it does not recognise the device, if it does so after boot

I have had problems myself booting with switched on usb devices attached, a multi-function printer used to play havoc with the boot, it would hang trying to resolve the device (which was actually 5 devices, printer, scanner and 3 card readers)
Attach it after boot was complete and no problem.

regards

Please Log in or Create an account to join the conversation.

More
10 Jul 2014 16:35 #48607 by DaBit
Some preliminary info through an SSH connection. for more useful information I need physical access to the PC.

dmesg:
Linux version 3.4.55-rtai-2 (root@precise-x86) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #1 SMP PREEMPT Sun Dec 15 23:40:48 MST 2013
BIOS-provided physical RAM map:
..
SCSI subsystem initialized
libata version 3.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
..
Trying to unpack rootfs image as initramfs...
Freeing initrd memory: 13008k freed
..
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci_hcd 0000:00:1a.0: setting latency timer to 64
ehci_hcd 0000:00:1a.0: EHCI Host Controller
ehci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:1a.0: debug port 2
ehci_hcd 0000:00:1a.0: cache line size of 64 is not supported
ehci_hcd 0000:00:1a.0: irq 23, io mem 0xf7f18000
ehci_hcd 0000:00:1a.0: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
ehci_hcd 0000:00:1d.0: setting latency timer to 64
ehci_hcd 0000:00:1d.0: EHCI Host Controller
ehci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
ehci_hcd 0000:00:1d.0: debug port 2
ehci_hcd 0000:00:1d.0: cache line size of 64 is not supported
ehci_hcd 0000:00:1d.0: irq 23, io mem 0xf7f17000
ehci_hcd 0000:00:1d.0: USB 2.0 started, EHCI 1.00
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
uhci_hcd: USB Universal Host Controller Interface driver
xhci_hcd 0000:00:14.0: setting latency timer to 64
xhci_hcd 0000:00:14.0: xHCI Host Controller
xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 3
xhci_hcd 0000:00:14.0: cache line size of 64 is not supported
xhci_hcd 0000:00:14.0: irq 41 for MSI/MSI-X
xHCI xhci_add_endpoint called for root hub
xHCI xhci_check_bandwidth called for root hub
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 4 ports detected
xhci_hcd 0000:00:14.0: xHCI Host Controller
xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 4
xHCI xhci_add_endpoint called for root hub
xHCI xhci_check_bandwidth called for root hub
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 4 ports detected
usbcore: registered new interface driver libusual
..
usb 1-1: new high-speed USB device number 2 using ehci_hcd
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 6 ports detected
usb 2-1: new high-speed USB device number 2 using ehci_hcd
Refined TSC clocksource calibration: 2613.630 MHz.
Switching to clocksource tsc
hub 2-1:1.0: USB hub found
hub 2-1:1.0: 8 ports detected
usb 3-3: new low-speed USB device number 2 using xhci_hcd
usb 3-3: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes
usb 3-3: ep 0x82 - rounding interval to 64 microframes, ep desc says 80 microframes
usb 2-1.6: new full-speed USB device number 3 using ehci_hcd
usb 2-1.8: new full-speed USB device number 4 using ehci_hcd
..
input: NOVATEK USB Keyboard as /devices/pci0000:00/0000:00:14.0/usb3/3-3/3-3:1.0/input/input0
generic-usb 0003:0603:00F2.0001: input,hidraw0: USB HID v1.10 Keyboard [NOVATEK USB Keyboard] on usb-0000:00:14.0-3/input0
input: NOVATEK USB Keyboard as /devices/pci0000:00/0000:00:14.0/usb3/3-3/3-3:1.1/input/input1
generic-usb 0003:0603:00F2.0002: input,hiddev0,hidraw1: USB HID v1.10 Device [NOVATEK USB Keyboard] on usb-0000:00:14.0-3/input1
generic-usb 0003:10CE:EB70.0003: hiddev0,hidraw2: USB HID v1.10 Device [KTURT.LTD] on usb-0000:00:1d.0-1.8/input0
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
..
usbcore: registered new interface driver usbserial
usbcore: registered new interface driver usbserial_generic
USB Serial support registered for generic
usbserial: USB Serial Driver core
usbcore: registered new interface driver pl2303
USB Serial support registered for pl2303
pl2303 2-1.6:1.0: pl2303 converter detected
usb 2-1.6: pl2303 converter now attached to ttyUSB0
..
ip_tables: (C) 2000-2006 Netfilter Core Team
serio: Serial port ttyUSB0
input: Hampshire Serial TouchScreen as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.6/2-1.6:1.0/ttyUSB0/tty/ttyUSB0/serio2/input/input9
..
usb 2-1.5: new full-speed USB device number 5 using ehci_hcd
usbcore: registered new interface driver ftdi_sio
USB Serial support registered for FTDI USB Serial Device
ftdi_sio 2-1.5:1.0: FTDI USB Serial Device converter detected
usb 2-1.5: Detected FT232RL
usb 2-1.5: Number of endpoints 2
usb 2-1.5: Endpoint 1 MaxPacketSize 64
usb 2-1.5: Endpoint 2 MaxPacketSize 64
usb 2-1.5: Setting MaxPacketSize 64
usb 2-1.5: FTDI USB Serial Device converter now attached to ttyUSB1
ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver
..
..
..
I-pipe: head domain RTAI registered.
RTAI[hal]: compiled with gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) .
RTAI[hal]: mounted (IPIPE-NOTHREADS, IMMEDIATE (INTERNAL IRQs DISPATCHED), ISOL_CPUS_MASK: 0).
SYSINFO: CPUs 2, LINUX APIC IRQ 2312, TIM_FREQ 6283625, CLK_FREQ 2613756000, CPU_FREQ 2613756000
RTAI_APIC_TIMER_IPI: RTAI DEFINED 2314, VECTOR 2314; LINUX_APIC_TIMER_IPI: RTAI DEFINED 2312, VECTOR 2312
TIMER NAME: lapic; VARIOUSLY FOUND APIC FREQs: 6283625, 6283625, 6252000
RTAI[malloc]: global heap size = 131072 bytes, <BSD>.
, <uses LINUX SYSCALLs>, kstacks pool size = 524288 bytes.
RTAI[sched]: hard timer type/freq = APIC/6283625(Hz); default timing: periodic; linear timed lists.
RTAI[sched]: Linux timer freq = 1000 (Hz), TimeBase freq = 2613756000 hz.
RTAI[sched]: timer setup = 999 ns, resched latency = 2944 ns.
***** WARNING: GLOBAL HEAP NEITHER SHARABLE NOR USABLE FROM USER SPACE (use the vmalloc option for RTAI malloc) *****
RTAI[math]: loaded.
RTAI[math]: unloaded.
RTAI[malloc]: unloaded.
RTAI[sched]: unloaded (forced hard/soft/hard transitions: traps 0, syscalls 0).
I-pipe: head domain RTAI unregistered.
RTAI[hal]: unmounted.

I cannot exactly distill from the existing /var/log/syslog.x (no messages anymore in ubuntu 12.04) what exactly happens when I plug it in, but I am fairly sure it is this:
Jul  9 23:18:32 linuxcnc kernel: usbcore: registered new interface driver ftdi_sio
Jul  9 23:18:32 linuxcnc kernel: USB Serial support registered for FTDI USB Serial Device
Jul  9 23:18:32 linuxcnc kernel: ftdi_sio 2-1.5:1.0: FTDI USB Serial Device converter detected
Jul  9 23:18:32 linuxcnc kernel: usb 2-1.5: Detected FT232RL
Jul  9 23:18:32 linuxcnc kernel: usb 2-1.5: Number of endpoints 2
Jul  9 23:18:32 linuxcnc kernel: usb 2-1.5: Endpoint 1 MaxPacketSize 64
Jul  9 23:18:32 linuxcnc kernel: usb 2-1.5: Endpoint 2 MaxPacketSize 64
Jul  9 23:18:32 linuxcnc kernel: usb 2-1.5: Setting MaxPacketSize 64
Jul  9 23:18:32 linuxcnc kernel: usb 2-1.5: FTDI USB Serial Device converter now attached to ttyUSB1
Jul  9 23:18:32 linuxcnc kernel: ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver

I did find another issue that needs solving though:
Jul  8 23:17:47 linuxcnc kernel: usbcore: registered new interface driver usbserial
Jul  8 23:17:47 linuxcnc kernel: usbcore: registered new interface driver usbserial_generic
Jul  8 23:17:47 linuxcnc kernel: USB Serial support registered for generic
Jul  8 23:17:47 linuxcnc kernel: usbserial: USB Serial Driver core
Jul  8 23:17:47 linuxcnc kernel: usbcore: registered new interface driver ftdi_sio
Jul  8 23:17:47 linuxcnc kernel: USB Serial support registered for FTDI USB Serial Device
Jul  8 23:17:47 linuxcnc kernel: ftdi_sio 2-1.5:1.0: FTDI USB Serial Device converter detected
Jul  8 23:17:47 linuxcnc kernel: usb 2-1.5: Detected FT232RL
Jul  8 23:17:47 linuxcnc kernel: usb 2-1.5: Number of endpoints 2
Jul  8 23:17:47 linuxcnc kernel: usb 2-1.5: Endpoint 1 MaxPacketSize 64
Jul  8 23:17:47 linuxcnc kernel: usb 2-1.5: Endpoint 2 MaxPacketSize 64
Jul  8 23:17:47 linuxcnc kernel: usb 2-1.5: Setting MaxPacketSize 64
Jul  8 23:17:47 linuxcnc kernel: usb 2-1.5: FTDI USB Serial Device converter now attached to ttyUSB0
Jul  8 23:17:47 linuxcnc kernel: ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver
Jul  8 23:17:47 linuxcnc kernel: usbcore: registered new interface driver pl2303
Jul  8 23:17:47 linuxcnc kernel: USB Serial support registered for pl2303
Jul  8 23:17:47 linuxcnc kernel: pl2303 2-1.6:1.0: pl2303 converter detected
Jul  8 23:17:47 linuxcnc kernel: type=1400 audit(1404854267.426:2): apparmor="STATUS" operation="profile_load" name="/sbin/dhclient" pid=785 comm="apparmor_parser"
Jul  8 23:17:47 linuxcnc kernel: type=1400 audit(1404854267.426:3): apparmor="STATUS" operation="profile_load" name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=785 comm="apparmor_parser"
Jul  8 23:17:47 linuxcnc kernel: type=1400 audit(1404854267.426:4): apparmor="STATUS" operation="profile_load" name="/usr/lib/connman/scripts/dhclient-script" pid=785 comm="apparmor_parser"
Jul  8 23:17:47 linuxcnc kernel: type=1400 audit(1404854267.427:5): apparmor="STATUS" operation="profile_replace" name="/sbin/dhclient" pid=784 comm="apparmor_parser"
Jul  8 23:17:47 linuxcnc kernel: type=1400 audit(1404854267.427:6): apparmor="STATUS" operation="profile_replace" name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=784 comm="apparmor_parser"
Jul  8 23:17:47 linuxcnc kernel: type=1400 audit(1404854267.427:7): apparmor="STATUS" operation="profile_replace" name="/usr/lib/connman/scripts/dhclient-script" pid=784 comm="apparmor_parser"
Jul  8 23:17:47 linuxcnc kernel: usb 2-1.6: pl2303 converter now attached to ttyUSB1

Here the two converters are swapped. :(
So I need to create two udev rules to prevent this anyway. Let me google first before asking here how to do that :)

Please Log in or Create an account to join the conversation.

More
10 Jul 2014 18:13 #48609 by ArcEye
I think you are probably on the right track

I have seen a post elsewhere, where /etc/modprobe.d needed an entry with the usb device maker:model and the module to load, before it would be picked up properly at boot.
May or may not be relevant in your case

regards

Please Log in or Create an account to join the conversation.

More
11 Jul 2014 05:24 - 11 Jul 2014 05:26 #48626 by DaBit
Created some udev rules to create symlinks to the various USB-to-serial devices with unique names, so that part is solved.

Then the 'cannot communicate using the device when it was already plugged in at boottime although it seems to work normal'.
So far the only thing that works is the usbreset program. When executing sudo ./usbreset /dev/bus/usb/002/003 first I can happily communicate with the VFD.

No idea what goes wrong. It seems to transmit something; I see the Tx LED flashing. But no response from the VFD, so whatever it transmits is not what it is supposed to transmit.

- Messages in the logs are the same as posted above.
- A sudo lsof | grep USB shows /dev/ttyUSB0 being used by inputattach, but no entry for ttyUSB1, so nobody is using that.
- stty -F /dev/ttyUSB1 shows no difference between the working and nonworking cases. .

*sigh*. F**ing USB :angry:

Am I forgetting a setting? I don;t think so since stty shows no difference. But doublechecking dosn't harm: this is the 'open port' code:
/* Open the serial port with device 'serialdevice', 9600 baud, 8 databits, 1 stopbit and even parity */
	fd = open(serialdevice, O_RDWR | O_NOCTTY);
	if (fd < 0)
	{
		perror(serialdevice);
		exit(-1);  
	}
	tcgetattr(fd,&oldtio);
	memset (&tios, 0, sizeof (struct termios));
	tios.c_cflag = B9600 | CS8 | PARENB | CLOCAL | CREAD;	/* 9600 baud, 8 databits, even parity, no modem control */
	tios.c_iflag = IGNPAR;									/* ignore parity in received messages */
	tios.c_oflag = 0;
	tios.c_lflag = 0;       
	tios.c_cc[VMIN]=0;										/* Use nonblocking reads */
	tios.c_cc[VTIME]=0;
	tcflush(fd, TCIFLUSH);
	tcsetattr(fd,TCSANOW,&tios);
Last edit: 11 Jul 2014 05:26 by DaBit.

Please Log in or Create an account to join the conversation.

More
11 Jul 2014 15:50 #48642 by ArcEye
Hi

I found the finished code for that experiment. I cannot see any real difference save style, apart from one thing.

My code specifically set the port to raw data and turned software control off.
I was transmitting my own pre-defined packets, not communicating with a pre-programmed client, so that may not be suitable for you.

Whether this has any effect I doubt, but that is it.
// 8N1
    toptions.c_cflag &= ~PARENB;
    toptions.c_cflag &= ~CSTOPB;
    toptions.c_cflag &= ~CSIZE;
    toptions.c_cflag |= CS8;
    // no flow control
    toptions.c_cflag &= ~CRTSCTS;
    toptions.c_cflag |= CREAD | CLOCAL;  // turn on READ & ignore ctrl lines
    toptions.c_iflag &= ~(IXON | IXOFF | IXANY); // turn off s/w flow ctrl
    toptions.c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG); // make raw
    toptions.c_oflag &= ~OPOST; // make raw

regards

Please Log in or Create an account to join the conversation.

Time to create page: 0.542 seconds
Powered by Kunena Forum