From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4497 invoked by alias); 12 Jun 2012 16:56:03 -0000 Received: (qmail 4479 invoked by uid 22791); 12 Jun 2012 16:55:59 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from gw.kuantic.com (HELO gw.kuantic.com) (213.244.28.44) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 12 Jun 2012 16:55:45 +0000 Received: from [10.0.0.43] (gw2.kuantic.com [213.244.28.45]) (authenticated bits=0) by gw.kuantic.com (8.14.5/8.14.4) with ESMTP id q5CGte11005135 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 12 Jun 2012 18:55:41 +0200 Message-ID: <4FD7748C.1000707@kuantic.com> Date: Tue, 12 Jun 2012 16:56:00 -0000 From: =?ISO-8859-1?Q?Bernard_Fouch=E9?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Nick Garnett CC: "" , stano@meduna.org Subject: Re: Handling RTS with an UART that doesn't directly drives the RTS pin References: <4FD7374A.1090602@kuantic.com> <4FD7410D.5060105@calivar.com> In-Reply-To: <4FD7410D.5060105@calivar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2012-06/txt/msg00003.txt.bz2 Le 12/06/2012 15:15, Nick Garnett a écrit : > On 12/06/12 13:34, Bernard Fouché wrote: > >> I'm about to : >> >> - add definitions for CYGNUM_SERIAL_STATUS_THROTTLE_RX and >> CYGNUM_SERIAL_STATUS_RESTART_RX >> - add a cdl option to have the line status callback function, which is >> user defined, to be called with the corresponding value if >> throttle_rx()/restart_rx() are called within serial.c . >> - hence the user defined callback can handle RTS (or any other flow >> control pin) the way it wants >> >> Do I break some convention doing this or is it okay? > I don't think hacking this into the generic code is the right way to do > this. In the past, when I have had to do the same and use GPIO pins for > this, I have added it to the underlying serial driver. Of course this > was for devices that had no other notion of hardware flow control. But > you could define your own variant of the 16x5x driver that did the right > thing. Modifying the 16x5x driver would mean to add a cdl option to specify a function name (what function to call to change RTS) since there is no GPIO infrastructure in the 'public' eCos version. For the same reason, sending to the driver the information related to CTS pin state has to be done from application level (but the infrastructure already exists thanks to CYG_IO_SET_CONFIG_SERIAL_FLOW_CONTROL_FORCE, which is used by TERMIO btw). But if such a change is made into ser_16x5x.c, anyone having the same need with a different hardware driver will have to re-invent the wheel. > However, a better approach is to avoid hacking on either the generic > code or the 16x5x driver and make use of the driver stacking mechanism. > Create a serial driver that passes all calls through to the underlying > driver, except for the throttle and flow config options, which do the > right things with the GPIO lines. Take a look at the TTY and TERMIO > drivers for how to set this up. RTS is the real problem: only serial.c knows when it's time to change the pin state because it's related to the use of the RX buffer, which is visible only to serial.c (please correct me if I'm wrong!). AFAIK there is nothing making the RX throttling information to reach higher levels since these higher levels are unaware of the buffering details underneath. Another solution would be to add config keys to get/set the pointers of the low level functions of a serial channel which are exposed by a hardware driver and then one could insert any kind of middle level driver (like hooks): this would be more comfortable in the long run, it could help for debug or statistics. The xxx_serial_channelN definition ends in .data so I guess this is possible. > Note that while RTS is a simple output level, CTS really needs to be > driven by a GPIO line that can interrupt and which will then call the > indicate_status() callback in its DSR. That should then drive the > generic serial transmit engine. This I already have. The line_status callback change in serial.c is very simple: only a few lines of conditional compilation in throttle_rx() and restart_rx() are needed. Adding config keys to get/set the function pointers should be not too difficult also. Le 12/06/2012 15:12, Stanislav Meduna a écrit : > On 12.06.2012 14:34, Bernard Fouché wrote: > >> I think the change is to be done in serial.c, since it's the part of the >> code that takes the decision to call throttle_rx() or restart_rx() > Is this the correct place at all? As far as I can tell the > flow-control here depends on channel buffer watermarks. It does > not protect you from overflowing the 16x5x FIFO; it does not > even know how deep it is. > > I do not know what UART speeds, UART FIFO sizes and maximum > guaranteed DSR latency do you have in your system, but in case > you want to protect against UART FIFO overflow I'm afraid > the only reliable way is to modify the low level driver's ISR. I don't have problems with the 16x5x hardware FIFO overflow condition: as you write this depends on the whole system characteristics. I consider my DSR latency good enoug to empty the hardware FIFO in time (thanks to the patches of bug 1001456 the system does not lose time ;-) ), and if not, I have to lower the value of CYGPKG_IO_SERIAL_GENERIC_16X5X_FIFO_RX_THRESHOLD. With a 16 bytes FIFO and a threshold of 8, I have more than 8 characters to have the DSR to empty the FIFO. At 115200bps (I don't go faster), that's 694µs: even when clocking very slowly there is time for many thousands of instructions. My problem has never been (yet) the hardware FIFO but serial flow control since the consuming threads are less reactive than DSR, and I don't know what will do the device connected to the RS232 port. Bernard