> Forgot to explain that opost calls write_room to see > if there is room to write two characters when it > wants to write "\r\n". pl2303 says sure, there is > room. opost then writes '\r' and '\n' in two > separate writes, expecting that there is room for > both, but the second write fails. > > pl2303 and similar usb serial drivers need a way > to buffer data so they can fulfill writes for as > many bytes as they advertised in write_room, even > if those bytes are written in separate write calls. > > With a write buffer like this, you would not need > to handle put_char separately.
exactly, i just finished tracing this problem down and started looking at what i could do to make this work properly. i've already begun experimenting with different solutions for this, however nothing solid yet.
> Lets try to find the root cause of these problems, > rather than just forcing OPOST off in the pl2303 driver. > If I have time and hardware that shows the problem I will > try to look into it.
agreed, my suggestion for turning off the OPOST in the driver was just a short term solution at best so that some of my legacy applications were somewhat functional.
> > Serial drivers have lots of features that might not often be > used, but some applications depend on those features.
you hit the nail on the head, if usb-rs232 is to be successful, it needs to perform in an identical manner as a standard uart/rs232. there are tons of odd POS applications that take advantage of these seldom used features.
thanks dave
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
