u/Ecstatic_Lavishness1

When I moved to Albuquerque, I started a job working in a lab where the primary job was testing new product ideas. Of course, we had regular product design and engineering departments and all that too – but we were the ones trying all the new, fun stuff. All RFID related. It was obvious that the regular engineering software manager disliked me as he was always trying somehow to trip me up. (Fortunately for me, my bosses were the R&D lab manager and the CTO.) I think this guy felt threatened by the fact that I didn’t have a four-year degree, but he was a very conservative EE guy. Sure, he had a few articles published in Embedded System Computing, but he had very strange peeves. He considered a statement of the style of

A ?  B : C ;

to be fancy-pants nonsense and non obvious code (Go figure.)  Anyway, I was working on a parking lot RFID reader system and the powers that be decided they wanted to be able to hook several of them up together over a single twisted pair. These were originally RS-422 devices and so the intent was to modify them to use RS-485 half-duplex and design a super simple poll-select protocol for them. RS-485 is ideal for noisy industrial communications and lets a daisy chain connect everything together with single twisted pair line. A single PC application could easily serve as a master controller and collect data from all the parking lot readers. (This project was an easy, no-brainer slam dunk for me – I had done plenty of this type of stuff before at other jobs and before.)

The Software Engineering Dept. bossman – who wasn’t MY actual boss made plenty of noise about how I needed to choose an auto converting RS232/RS-485 adapter for this application. I nodded a bit, then promptly forgot about it. I modified the firmware on a couple of test readers to use their line drivers in tri-state mode and modified the firmware to use a simple poll-select serial protocol by simply encapsulating the existing serial-based command structure. It was easy enough to do – I barely needed to touch the existing firmware code at all! Next up it was to time write a simple desktop application to exercise it all as a proof of concept. Instead of one of those auto-switching  232/485 PC serial driver devices, I selected one which used the RTS pin to switch line direction. The reason I made this choice was that those damns auto-switching devices need to have (at least) one character delay, often more in which to sense when to switch line direction. By using RTS – I control when the line changes direction – and I wouldn’t have to build in some silly delay to let the device change direction – it would slow things down and besides I would have to select a worse case delay to handle any variances too, Of course – switching line direction manually means you need to know exactly when that last character has been transmitted – which you can get from the UART in your interrupt handler if you know what your doing. Anyway - like I mentioned it was all a slam dunk and everything worked perfectly and everyone body was happy happy! Except one guy...

When SWE bossman found out I used a non-auto-switching 485 driver, he threw a major fit. It was only much later that I found out why. Some year or so later, I was given a desktop program that needed some modification to work with one of our products. It used RS-232 and ran as a DOS program under windows and controlled several older reader devices. It worked fine but would go off in the weeds under heavy loads. Sure enough, it was losing interrupts and the interrupt handler code was the strangest thing I’d ever seen. You see, when you handle an interrupt on a pc, you usually first mask cpu interrupts, then you mask your interrupt on the 8259 PIC handler chip, and then you may reenable interrupts on the cpu and take care of your business. (You could even mask at the UART too, but the PIC was sufficient) Well, this guy simply masked ALL of the interrupts on the entire 8259. WTF? Why mash the entire thing?

I’m sure this all managed to work under old DOS – but under Windows-16  (which is what was the times) that 8259 is emulated! You really don’t want to mess with anybody else’s interrupts but your own on the PIC in this situation – you have no idea what’s going on elsewhere.

Guess who originally wrote that application and its gnarly serial interrupt handler? Yep – you guessed it – that same SWE bossman. So, it dawned on me that this was one that got past him and he never ever figured why his application buckled under load when run under windows.

How dare some whipper snapper 2-year degree guy fix something that that evaded a guy who published articles on SCSI in a respected industry magazine? From that day on – I never doubted myself. People have varying levels of skill, nobody’s perfect – nothing wrong with that. But don’t be a poser – someone just might pull the curtain sometime. Better to be humble. People can accept humble.

PS. Way, way back in the early 80’s when I was teaching myself C I wrote my own serial interrupt-based drivers – mainly because I wanted to avail myself of the new-at-the-time 16550 buffered UART, which was needed if your were going to do anything over 9600 baud on the PC in those days. In my later engineering career – this kind of serial stuff was like a familiar old friend.

“He don’t know me vewy well – do he?”