Collins:Network
My second job at Rockwell Collins was to write the network (communications) between the two processors.
~ Aristotle Sabouni
Created: 2022-03-06 |
The communications between the two processors was further behind than other projects, so they gave it to me. I think it was initially shit jobs to the young kid, but it was also lowest level programming (machine code), and I seemed to go down lower than most. (I had more hardware design and digital electronics background).
There are two halves to the terminal (two separate processors), one for the secure data, and one for the insecure data. My next job was to make the two halves communicate. They thought I had to write a simple serial driver to get the two processors talking (the previous guy had tried and given up... which is why it was behind). I came on, and after a few days, quickly figured out that something wasn't quite right. (It wasn't working reliably at all). I hit the same roadblock he had. The serial driver I recreated wasn't working either.
Sherlock Holmes said, "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth."
Well, my code wasn't the problem, so it must be the hardware.
You have to understand in software, new programmers always think it's the hardware, and are virtually always wrong -- so most programmers learn to believe that it's never the hardware. And programmer that says, "it's the hardware" is mocked. But I brought in my own Continuity Testers and validated that the cable was designed wrong: the lines that put a throttle on sending data wasn't wired up right -- so flow control could never work. It's why the prior engineers had never figured out how to get it to work.
| 🗒️ Note: |
|---|
| The way flow control works is that the transmitter sets, "Clear to send"?... and the receiver raises the, "request to send", which tells the sender to send a character. Then they both reset, and you repeat. It lets the receiver control the flow of data -- and make sure every character is acknowledged before the next character is sent. So characters can get overwritten/lost.
This cable hadn't run the wire from the receiver to transmitter, they just looped it back on itself so the transmitter was ALWAYS ready to send data, even if the other side hadn't acknowledged it had gotten it. And the receiver was looped back on itself so it was ALWAYS acknowledge that the character had been sent. What this means is that the transmitter would send as fast as it could, and faster than the receiver could get data. And if the receiver was ever faster, it would get the same character twice -- meaning the data sent and the data recieved had many errors. Since the transmitter had transmitted it all, and the receiver was waiting for more, forever, it would be stuck waiting for data that was never to come / had already been sent. |
I tried to push back on the design and explain proper RS-232 to the hardware guys (by showing them the specifications, what was wrong, and the implications of doing it wrong), but they said, "we're not fixing the cable -- it's a software problem", so a simple serial driver, became me having to write my own network protocol (stack) from the ground up (packeted protocols, timeouts, protect against overwrites and so on) all to get around someone not knowing how to design a cable right.
It was way more complex than I was supposed to have to do... but as long as I delivered on time (on something that was already way behind schedule), no one cared how I fixed it. So I delivered on time.
My glee at my own cleverness of figuring this out, and fixing it was magnified by the engineer(s) before me that hadn't figured it out, and many months after I left, 4 other consultants tried to redo what I'd done, and they failed to figure it out. But I'm getting ahead of myself.
🔗 More
| |
