> > > Do we really benefit from having this in kernel ? > > The problem that can come up when executing this feature in user-land > > (though not exactly common) is when the hardware on the other end > > responds to your message faster than your user app was able to detect > > that the UART is finished and then toggle RTS. When this happens both > > ends are trying to drive the line and you have bus contention, lost data > > and possibly damage to the driver chips themselves. > > The chips are quite safe. Can we stick to real reasons. > > In terms of performance you can manage RTS with a real time application > if need be and that will give you very close to kernel side response time. > > Alan I apologize if this is a duplicate to anyone, but I've been trying to get my response through to the board and kept getting rejected, I think this one will make it through... The chips may or may not be safe, that isn't the point. There are real world applications where response time is an issue and meeting these criteria is sometimes impossible from a user application. Switching to an RTOS is certainly an option, it would very likely allow you to manage RTS withing spec. However this might not be very practical for many users. I suppose another option is to switch to a serial card that uses a UART that has this capability built in. I don't want to sound like an advertisement, but several of my line of Fastcom serial cards have this feature, where the RS485 gating signal is governed autonomously by the UART itself. Matt Schulte Commtech, Inc. -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
