Srinivas, Top-posting is highly discouraged on most high-volume mailing lists, and the includes this one. Moving your answer to the bottom and then answering. > > Microbit_Ubuntu wrote: >> >> Hi Greg, >> >> On Thu, 2009-08-13 at 20:41 -0400, Greg Freemyer wrote: >>> On Thu, Aug 13, 2009 at 3:52 PM, >>> srinivasramana<srinivas.ramana@xxxxxxxxx> wrote: >>> > >>> > Hi All, >>> > >>> > I have been working on the feasibility of having multiple device >>> > nodes(serial type device) for a single device so that applications can >>> treat >>> > each of these device nodes as separate devices. >>> > >>> > 1. Can i write a tty driver which creates multiple nodes(i will set >>> minors >>> > to the number of nodes i need) >>> > 2. Now, If I write from user space on any of these nodes i have seen >>> that it >>> > comes to the tty drivers write call. >>> > 3. I want to know how do i link my physical driver with this tty >>> driver? >>> > 4. If mutiple applications are waiting on read on different nodes, how >>> do i >>> > wake up a particular read based on the incoming data from hardware(on >>> Rx >>> > interrupt)? >>> > >>> > please help. >>> > >>> > Thanks & Regards, >>> > -- Srinivas R >>> > >>> > >>> > >>> > srinivasramana wrote: >>> >> <snip> >>> >>> I'm going to ignore the electrical aspect of multidrop rs-232, but I >>> really don't think that works at all. >>> >>> Assuming you have somehow overcome that major hurdle, I don't >>> understand your problem. >>> >>> You start with a standard multi-port uart serial driver. Then modify >>> it such that when data comes in your driver decodes the protocol to >>> get the address/routing info and delivers the data payload to >>> appropriate device (/dev/ttyx) as if it were a multi-port device. >>> >>> On write, your driver gets data from userspace (/dev/ttyx) and wraps >>> the comm protocol around it and sends it on its way. >>> >>> >From a software perspective none of this unusual, strange, or weird in >>> any way. >>> >>> If you think about a 8-port serial card, it works exactly as you >>> describe. A single hardware driver gets the incoming data from the >>> card, decodes the cards signaling protocol and delivers the data to >>> the correct device (/dev/ttyx). And on write, it uses the cards >>> signalling protocol to tell it which port to send the data out. The >>> only difference is a hardware card uses hardware registers to control >>> the routing, where as you have it embedded in the data stream. >>> >>> Note: TCP/IP also embeds the routing info in the data stream (ie. the >>> port). It is a totally standard thing to do. >>> >>> Greg On Fri, Aug 14, 2009 at 10:31 AM, srinivasramana<srinivas.ramana@xxxxxxxxx> wrote: > > Hi Greg/Kris, > >>> you _can't_ multidrop with RS232 > Thats correct. I am not attempting to multidrop RS232. I have a micro > controller handling all my devices and that micon connects to the host over > UART. Basically, my need is to make each of those devices connected to micon > appear in linux as serial devices so that I can make use of my existing > applications.(also wide range of applications available for serial devices). > > So, i have been looking into the multiport serial card drivers. I understood > that the tty driver can create the multiple nodes required. I couldn't find > yet how to connect my tty driver to the UART driver. As per my UART driver > understanding, it happens in uart_add_one_port(). But how do I do that when > I am working top to down(tty to uart)? > Also, since i have single physical UART port, i believe interrupt handling > is just like normal serial driver. please correct me if this is wrong. > > Suppose I have 4 nodes and applications are waiting on all these 4 nodes for > read, when i do tty_flip_buffer_push() in my Rx ISR, which app thread gets > unblocked and get the data? > > Thanks & Regards, > -- Srinivas R > What I would do is find a specific multiport serial card drive that has the hardware support logic in place to talk to a hardware board with multiple of the UARTS you need to talk to. Copy it to your new driver. Now you have your very own fully functional driver that creates all the kernel / userspace relationships. The trouble is its handling of minor numbers causes hardware interactions that you need to replace with data interactions. Make those changes one at a time until suddenly you have a fully functional driver that does what you need. > Suppose I have 4 nodes and applications are waiting on all these 4 nodes for > read, when i do tty_flip_buffer_push() in my Rx ISR, which app thread gets > unblocked and get the data? In your interrupt routine you will need to a have something like static struct tty_struct *tty_rcv; // Not on the stack, for use in interrupt routine only Then I hope part of your serial stream will include address info. In your interrupt driver you need to monitor the serial data and when you see address info, set *tty_rcv to point to the correct struct for the /dev/tty you want to send future received data to. If we assume you have a one byte address field, when that byte comes in the interrupt routine reads the byte from the uart, realizes that it is an address field and causes *tty_rcv to now point to the correct tty struct. Then future data coming in from the uart is sent to where ever tty_rcv is pointing. In my simple example, the address info itself you do NOT forward to user space. The interrupt routine itself is the consumer. Only the data payload of the packets gets forwarded to user space. ie. I agree with an earlier post that this should really be handled in user space, but it is certainly not hard to do in the kernel. I would just be surprised if something like this made it into mainline. Greg -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
