|P is for Practical|
Yes and no. Yes, in the docs they are listed as seperate lines. No, that is not the way it is actually working.
Yes, that appears to be the action of the converter.
Yes, that would be the logical way for it to be wired, and is quite what I was expecting. But there is not a single unused line that you can cycle to get the desired behavior. Using an RS-232 breakout box, I tried all the lines... only by turning off and restoring RD would the hardware respond in the way that is described for when the SEND line is toggled.
$PortObj->pulse_break_on() doesn't do anything for me. First of all, as the docs specify, you can't get exact timing out of it. Second, that plays with TD (pin 2) not RD (pin 3), and the hardware doesn't blink. Actually, I wrote a strober to try all the pulse methods before I tried manually playing with the voltages via breakout box. Closest I can get that way is to throw ACCEPT_ENABLE(DTR) around, which makes it burp but not finish processing any events or state changes.
With all the means available for doing this right, there just isn't any excuse for kludging the hardware in the manner you describe.Yes, and considering your sollution contains errors, and also doesn't work at all, there is even less excuse for your attitude than for my kludge. If I thought I had the ideal sollution, I would have posted in CUFP instead of Seekers. On the bright side, since it's for my own company I only need it to accept the customers money and credit them; nobody is going to ask what it's "excuse" for working is.
Snazzy tagline here