Last time in the realm of bitbanging an RS-232-compatible data-stream to dump my scavenged-parts-bin FLASH chip's unknown contents for probably no use whatsoever, but just-in-case...

I managed a serial Tx/Rx loopback from my computer's Tx, through a USB-Serial adapter, through a DB-9 rewire, through the blacklink cable, through the 3-wire cable into the calculator, through my assembly program, then back through that whole mess back to the computer's Rx.

That particular assembly program was merely reading the Rx pin's logic level and duplicating it to Tx, with no awareness of the datastream, start-bits, syncing, etc...

I wrote up the next version, which actually is supposed to be aware of all that, so that the next-next version would be a simple matter of replacing the incoming data-bits (0xAA = 10101010 transmited by the computer as a clock for the calculator) with its own data to be sent to the computer. (Thus, the calculator's serial stream is clocked by the computer, since it doesn't have an internal clock I can find to generate its own baudrate.)

But, therein, my program was too large to diagnose assembly errors... so I broke it up into many smaller include files, then went to re-test the /original/ loopbackRaw, now based on these new include files, to find that it no longer works. 

Of course, the first assumption was I screwed it up.

But after a bit of stepping back I discovered that my (somewhat-hacked) USB-Serial adapter is apparently the culprit.

This thing I've used for devel of various projects for well over a decade... and, just prior to the failed loopback test I'd even used it, sans external DB-9 rewire, to back up all that hard work... but, now, somehow, it decided to kaput.

I mean, this is weird.

Granted, it is full of dangling bodge-wires and questionable solder joints... and granted, it's been open for a week somewhat exposing that ratsnest to the elements, which are numerous in this life"style"...

but from what I see, the failure is in a bodge on the /underside/ of the board, which was not at all exposed.

Hah! How could this be?

Further, frankly, that particular bodge shouldn't have any effect, as I recall, because I'm using the /actual/ RS-232 signals (via something like a Max232) instead of disabling the Max232-alike (via a switch) and tapping into the 3.3V logic signals. That particular wire is responsible for pulling up a Max-232-alike output to the PL2303 /when/ the max232-alike is disabled. Which it's not in this case.

And further further still, the particular malfunctionality... well, frankly, I can't imagine how it /could/ malfunction in such a way.

So, now, i'm at a loss.

Like I said, I did that bodgery well over a decade ago, and frankly it's near miraculous it's functioned this long without something getting snagged and ripped-up, etc...

I don't recall the purposes of all those bodges, so I'll probably be reverse-engineering my handiwork again, soon.

... not at all in the mood to do that... I've got code ready to be tested!

...

8 hours later.... alright! Apparently the problem was that echo was on?! Naw, this dun make sense, do it?

I fixed the broken connection in the USB thing... nothing else seemed wrong. In fact, I'm pretty impressed with how stable all those solfer joints are, especially the one soldered to a tiny trace between two pins on a surfacemount IC. It looks ugly, but it's actually really strong... (been working for over a decade). But, the broken connection was apparently a cold-solder to a via, the copper was visible. That happened to be a pull-up resistor to DSR, which, from what I can tell, isn't even used in linux, unless explicitly programmed to, in whatever software you're using. So, really, that wasn't it. Right? Plausibly a loose wire might've bumped things nearby, but nothing there seems related to the issue I encountered.

Of which, actually, there were two.

First it wasn't getting any data via the loopback at the DB-9, /nor/ via the TTL-level serial interface I added. Flipping the switch did nothing. Then suddenly it started acting /totally/ different, no explanation... my output was a single byte every half second, but when Tx and Rx were shorted, it suddenly started transmitting tons of data, as seen both by my logic probe /and/ in the quickly increasing filesize of the receive-log.

So, now, after fixing something which frankly probably has been broken for years without an effect, i plugged it in, tried a loopback, and got back exactly what I sent countless times. Echo...? Turned it off, and perfect loopback.

Now, seriously, how does this make sense? I used the exact same stty arguments as the prior loopback tests a weekish ago... Exactly. How do I know? Because I "Up-arrowed" to it in my bash history.

Same with the send/receive commands.

And I'm absolutely certain I never turned echo off previously in this project.

It worked, during loopback, as expected... which is what encouraged the writing of the next big chunk of code... then it, the part that worked as expected, didn't work as expected when I came back to it a week+ later due to a setting I never fiddled with?!

So, fine... echo got enabled somehow... are you seriously trying to tell me that echo is a feature of the serial port driver itself? That seems weird. Because, again, my receive program was simply: 'cat /dev/ttyUSB0'... so, then, somewhere between the driver and the PL-2303, echo gets jammed into the receive buffer?! Weird.

Fine, let's say I believed that... now, we're sending via another simple command on another commandline... 'printf "hello" > /dev/ttyUSB0' (in a while loop every half second). What I got back wasn't "hhhheeeelllloooo" or whatnot, as would be expected with echoing each transmitted character, I got back "hellohellohello" repeating endlessly until I broke the loopback. 

Stty was set "raw", so it shouldn't be waiting for carriage returns... maybe USB packets have something to do with it, sending blocks of buffered data in packets, rather than reading one byte at a time. Fine.

Then echo via stty isn't echo what you send, but echo to the sender... fine. So, the printf sends hello to the loopback, the computer receives it then transmits it again... ok.

Again, why have I never run into this before? And not just this project, yahknow, a weekish ago, but many projects over well more than a decade...? And who the heck would expect e.g. a modem or printer to want echo? No, so now it's like I'm connecting a dumb terminal to my computer, the compter's acting more like a modem, or a server. Fine, I can buy that kinda makes sense, being stty and all... and tty referring to terminals, which might want the server to echo... but, again... never ran into this before.

... nevermind the fact that the initial "no longer working" was that /nothing/ was coming through the loopback. Yahthink I didn't do every step of the troubleshooting process during /that/ problem? Dang thing "fixed" itself /after/ I determined there to be no electrical faults in/related-to the loop. Was that DSR pull-up wire shorting something, when there's nothing related nearby to short? Was it somehow /also/ reconfigured to actually pay attention to DSR /this/ time, when it wasn't /last/ time?! And even if it was, again, the detached pull-up was /irrelevant/ to this case, because the Max232-alike was /not/ disabled!

GAH! Soon as I determine it's not electrical, it goes into this "working /too well/," instead. Fine. Software hiccup, dunno where/why. Note to self, *now* /explicitly/ disable echo via stty.

....

Anyhow. My old loopback test program worked, again, after disabling echo. No explanation for why it didn't work prior to the echo problem.

And after some babysteps I tried out the serial-frame-synchronized loopback test... which also worked. And after a bit of headbanging trying to figure out weird sporadic data, even the modification to the frame-synced loopback--to replace the data bits with data transmitted from the calculator, being /the/ goal--works. 

The weird sporadic data was a result of LSB instead of MSB-first... the compy needs to send 0x55, not 0xAA, as a serial-frame clock, and the calc needs to send bit0 first instead of bit 7. I'd kinda figured I might run into those issues. Easy fix.

Now the calculator sends data to the RS-232 Rx pin... I changed it from "Hello" to "Howdy." I think my last test was 9600bps. 

[I should be /way/ more excited about this, it's been /weeks/ in the making!]

Next, i guess i need to think twice about receiving binary data (the FLASH dump) via the commandline... my less-simple receiver shellscript seems to be trying to receive Unicode, or something, multibyte "characters."

...another day.