by helmutforren »
Eli,
I sincerely appreciate your persueing this.
The needed ioctl() include ioctl(intr_fd,TIOCMGET,&l_status), ioctl(intr_fd,TIOCMSET,&l_status), and ioctl(intr_fd, TIOCMIWAIT, TIOCM_CTS). Note that the last of those is blocking and is used to respond quickly to an event, as if one would respond to an interrupt. These calls are in fact for watching for an external event signaled by the DCD serial line. In addition, other code that uses the port for serial communications calls tcsetattr() and tcgetattr().
My best understanding of how to handle this with pty's is to have my user-space program open not only the master side of a pty, but also the same slave side as the application code above. This is because the TERMIOS data related to tcsetattr() and tcgetattr() doesn't get through the pty to the master side. (And I had not yet even considered those specific ioctl's when I built this understanding.) However, I don't know of a way to make my user-space program react immediately to the tcsetattr(), for baud rate setting for example, without polling. I'd prefer not to poll. Furthermore, my cohort at work who's in charge of the application (long term company IP) wants to be able to use more and more of what I find at both man pages IOCTL_TTY(2) and TERMIOS(3). Well, I understand how to work on a character device loadable kernel module, I even have my own model. I understand how to expand or adapt it to respond to all these things. But I do not understand how to get the info and timeliness across the pty. If you can clarify that, then maybe I'll like the pty solution again...
Now, you mentioned copying existing pty sources. Are those for kernel space or user space? Note I do have an existing kernel space driver that was written for our previous gen product that had similar FPGA peripheral devices but not Xillybus.
(This time I'm logged in and see the fourth checkbox to notify me. I guess I got timed out, and most places you can't post when not logged in and therefore get prompted to log in.)
Eli,
I sincerely appreciate your persueing this.
The needed ioctl() include ioctl(intr_fd,TIOCMGET,&l_status), ioctl(intr_fd,TIOCMSET,&l_status), and ioctl(intr_fd, TIOCMIWAIT, TIOCM_CTS). Note that the last of those is blocking and is used to respond quickly to an event, as if one would respond to an interrupt. These calls are in fact for watching for an external event signaled by the DCD serial line. In addition, other code that uses the port for serial communications calls tcsetattr() and tcgetattr().
My best understanding of how to handle this with pty's is to have my user-space program open not only the master side of a pty, but also the same slave side as the application code above. This is because the TERMIOS data related to tcsetattr() and tcgetattr() doesn't get through the pty to the master side. (And I had not yet even considered those specific ioctl's when I built this understanding.) However, I don't know of a way to make my user-space program react immediately to the tcsetattr(), for baud rate setting for example, without polling. I'd prefer not to poll. Furthermore, my cohort at work who's in charge of the application (long term company IP) wants to be able to use more and more of what I find at both man pages IOCTL_TTY(2) and TERMIOS(3). Well, I understand how to work on a character device loadable kernel module, I even have my own model. I understand how to expand or adapt it to respond to all these things. But I do not understand how to get the info and timeliness across the pty. If you can clarify that, then maybe I'll like the pty solution again...
Now, you mentioned copying existing pty sources. Are those for kernel space or user space? Note I do have an existing kernel space driver that was written for our previous gen product that had similar FPGA peripheral devices but not Xillybus.
(This time I'm logged in and see the fourth checkbox to notify me. I guess I got timed out, and most places you can't post when not logged in and therefore get prompted to log in.)