To help my overloaded brain ... when folks refer to "the Prolific problem" ... is that a reference to the usb/serial cable? or to a chip on the Windows machine?
Tom M. On Fri, Apr 5, 2019 at 2:56 PM Brian K. White <[email protected]> wrote: > I've actually never had a problem with a Prolific based adapter either, > but I know that it is a real problem anyway. > > Pick any random cable purchased off amazon or ebay, and it might or > might not be garbage, until you prove it by actually using it. > I've bought probably 20 or more if you count both work and hobby stuff > over the last 15-20 years, and they've all actually worked ok, but that > is just luck. The bad ones do actually exist, and they look just like > the good ones, unless you stick to a few name brands. > > And it's also a real thing that even when you have a "good" one where > the chip isn't counterfeit, the chip and the driver even at their best, > still lacks certain features that matter. > John Hogerhuis has explained before (maybe on the fb list instead of > here) that the Prolific interface doesn't allow you to avoid a certain > amount of usb buffering, which can screw up the timing of signals, and > can prevent flow control from actually working, because the flow control > signal itself is queued up and sent only when the next packet is full > and ready, and by then you may have already overrun the M100's receive > buffer etc. > > That's the kind of problem that isn't disproved by simply having the > good luck to not have hit it yet. > It's still there and will still hit someone else under some other > condition, or may still hit you tomorrow even if it never has before, > because it's dependent on variables and variable conditions and usage > pattern. > > In the specific case of TPDD emulation, I think you can actually get > away with Prolific, and a total lack of flow control, because of the way > the TPDD protocol happens to work. It works in fixed small size packets, > where the entire packet fits inside the M100 receive buffer, and, you > only ever get one packet at a time because the TPDD doesn't send a new > packet until after the M100 sends an ack after ingesting the previous > packet. So the tpdd protocol implements a flow control itself, instead > of relying on the underlying serial channel to be doing that right. So > it's another way you can think there is no problem when there still is. > Or, there is no problem *only* as long as you only keep using it for > exactly that one purpose which happens to work. > > -- > bkw > > > On 4/5/19 12:31 PM, Jonathan Yuen wrote: > > Hello All, > > > > I've used a prolific usb-serial cable to connect my laptop to a > raspberry pi and it didn't have any handshaking at all, just tx, rx, gnd, > and a constant 5V to power whatever (like the pi itself). This wasn't real > rs-232, just the ttl level serial commmunication, but the pi wanted ttl, > not real rs-232. > > > > [email protected] > > --- > > När du skickar e-post till SLU så innebär detta att SLU behandlar dina > personuppgifter. För att läsa mer om hur detta går till, klicka här < > https://www.slu.se/om-slu/kontakta-slu/personuppgifter/> > > E-mailing SLU will result in SLU processing your personal data. For more > information on how this is done, click here < > https://www.slu.se/en/about-slu/contact-slu/personal-data/> > >
