Computing setup, hardware focused

Since I work from home the majority of the time and my job involves writing software and firmware for multiple small embedded ARM based devices, my computing setup tends to be a bit more complicated than normal.  I'm also cheap so I've gotten almost everything on sale.

 

The picture above shows some of the equipment at home which makes it easier for me to switch between the many devices I need to use both for work and my personal computing needs.  The red surface everything rests upon is a grounded anti-static mat which is a necessity as I often need to use bare circuit boards for easy access to JTAG connectors.

• Philips 4k monitor.  I often have ssh sessions with anywhere between 2 and 5 Linux systems simultaneously.  That many terminal windows take up a lot of screen space so the fact that a 4k monitor has 4 times as many pixels as the HD monitor I'm stuck using at the office has made working so much easier.  I got this at a good price thanks to a Black Friday sale 3 years ago.
• IOGear KVM switch.  I usually switch between my work laptop, my Mac Mini which is mostly for home use, and a Raspberry Pi 5.  Since this is a 4 port KVM switch, that leaves an extra set of cables to connect to other devices as needed.  I had a cheaper KVM but the move to a 4k monitor forced me to upgrade to one which supported the higher resolution.
• Mechanical keyboard.  I opted for a cheap mechanical gaming keyboard with a PC key layout and which uses Outemu Blue switches (Cherry MX Blue clone).  I find it much easier to use a PC style keyboard on a Mac than the other way around.  Since I often connect to Linux and Windows machines, it just makes more sense for me.
• Technical Pro rack mount power supply.  This allows me to easily power on or off any individual device in my setup as needed. 
• Raspberry Pi 5.  This is a great development device as there are much better free development tools available for Linux than there are for Mac or Windows.  That provides me with a lot of flexibility in my development and debugging tasks.  It's my favorite computer to work with.
• Anavi Macropad 10.  This device comes with CircuitPython installed which makes it very easy to configure the key codes it can to send to my Mac.  I like this one because it's also got a rotary encoder (which can be used to easily change the volume) with a button on top to pause the music.  I often use my Mac Mini to play background music while I'm working.  Being able to pause music playback, skip to the next song in the playlist, rewind to the previous song, or adjust the volume on the Mac while my keyboard and monitor are switched to my work laptop via the KVM is very handy.  The situation which this keypad helps with most is when I get a call from someone at work and need to quickly pause the music in order to take the call.
• Canon PIXMA G6020 All-in-One Megatank Printer - It's affordable, reasonably fast at printing, doesn't use proprietary ink cartridges, and has copying and scanning capabilities as well.  We've had it a year and are still on the original ink bottles supplied with the printer.  I think we've been through about 6 reams of paper during that time, most of it double-sided.

 

The picture above is an EDID (Extended Display Identification Data) HDMI adapter.  It causes the computer which it's plugged into to continue thinking that the 4k monitor is still plugged into the computer when it's actually switched to another computer via the KVM switch.  The EDID HDMI adapter shown above is connected to my work laptop.  I've got another one plugged into my Mac Mini.  This prevents the windows on whichever machine from being rearranged when the monitor configuration changes via the KVM switch.  More expensive KVM switches sometimes include this capability without requiring an external adapter like this.

 

 

Things which make C/C++ source code easier to understand

I end up reading a lot of C/C++ source code from various sources in my role as an embedded firmware engineer.  There are a few rules I try to follow to make my code easier for others to decipher.

• Include explanations for any acronyms you use in function or variable names and even in comments.  Don't assume that everyone has the same background as you do.
• Don't ever use magic numbers.  When I'm looking for all code which writes or reads a bit within a register, I don't want to have to try to grep for every hex value which includes that bit and even worse, sometimes people define register values as decimal which makes less sense to low level programmers like me.  Just define it with a mnemonic name and use the boolean or operator "|" to define the set of bitmasks required.  Think of the poor sod who gets stuck maintaining your code.
• Start your functions with an open brace starting in column 1 after the function name/parameters.  End functions with a close brace in column 1 for the same reason.  It makes it easier to search for function names within a source file.  In an editor which uses a vi style user interface, the command "/^{" (without the quotes and followed by the Enter key will find the first instance.  Then "n" will find the next one and can be repeated as many times as desired.
• Emulate whatever indentation style you found in the code if you inherited it from someone else.  It's irritating to have a mix of tab and space characters with no hint of what tab stops the author used.

Whiteboard coding during interviews

I recently responded to a writer I follow on Mastodon and Bluesky who was looking for input for an article she was planning to write about interviews for embedded systems positions.  Since I enjoy her writing and I have loads of experience with embedded systems, I responded to her request.

The act of recalling various interview questions I had been asked or had posed to others made me remember some questions which I disliked intensely.  The type of question I dislike most is being asked to write code on a whiteboard to solve some problem.  I generally enjoy coding and the problems are often interesting but coding on a whiteboard is so different from writing code on computer using a good editor that I've grown to hate it.  I'd almost rather go back to the bad old days of using a keypunch to generate punched cards as source for my program.  When programming I like to start with an outline of the program and fill it in as ideas occur to me which is nearly impossible when stuck with a more linear coding environment such as whiteboard or a sheet of paper.

I've had two memorable experiences responding to requests to code on a whiteboard.  The first was the most absurd question I believe I have ever been asked in a job interview.  Apparently the company I was interviewing with had guidelines for technical interviews and the engineer asking the questions was hellbent on sticking to these guidelines.  He asked me to write an assembly language program for him.  I asked which assembly languages he was familiar with since I was comfortable with about 5 at the time.  Once I discovered that we had no assemblers in common, I pointed out that it made little sense for me to write a program in a language he wasn't familiar with but he insisted on me completing this task so he could check it off on his interview form.  In addition to it being ridiculous to write a program which cannot be evaluated, it's also frustrating trying to write a meaningful assembly language program on the tiny whiteboards available in cubicles since assembly programs tend to be much longer than those written in higher level languages.  Apparently I passed muster as I ended up getting the job.

The second whiteboard coding experience which came to mind ended far more positively.  I was asked to solve a problem in C but ended up needing to keep adding lines which is no problem on a computer but presents a huge obstacle when stuck using a whiteboard and marker.  I managed to come up with an incomplete and messy solution before they called time on me.  Once I got home from the interview, I was still bothered by my performance.  I was able to quickly code up the solution on my computer at home and emailed a working program to the VP of Engineering I had been interviewing with at the time.  He was so impressed that I had followed through with solving the problem that I was offered the job and ended up staying at that company for 9.5 years.  I still hated the initial request for whiteboard coding but was pleased that it resulted in me getting the job.

I'm hoping that the days of being asked to code on whiteboards are relegated to the past.  To tell the truth, since I'm at my last job before retirement. it won't have a huge impact on my life either way but I hate the thought of others being subjected to this absurd practice.

The benefits of a varied technical background

This week I helped a colleague solve a strange problem which he had encountered.  He was modifying some application level code which needed to read from and write to a device driver I had created to control two LEDs on our device.  Previously the application code had only written to the driver but the decision was made to control the two LEDs independently which required reading the old state from the driver prior to updating the LED state.  Fortunately I had included the ability to read the LED status since it improved my ability to debug the device driver.

The problem was caused by the need to interleave reads and writes to the device driver which under Linux gets treated as a file.  Unbeknownst to my colleague, any read or write to a file stream affects the file pointer which keeps track of the location within the file which will be accessed next.  A simple device driver has no need of the file pointer concept but since Linux treats devices as files, the standard library code which enables accesses to devices and files keeps track of the supposed file pointer even if it doesn't need to do so.  In a standard file access, I should have been able to do a fseek (file seek) to the current position between the read and write calls to fix this issue.  Unfortunately, since my device driver is very bare bones, I suspect there was extra call within the device driver needed to handle fseek calls.  I used a brute force fix of closing the device driver and re-opening it within the application code.

Somehow this makes me think of the common wisdom from early in my career which suggested one shouldn't change jobs too often lest one be labeled a "job hopper".  It turns out that job hopping has given me a very diverse background which has improved my chances of finding jobs.  Changing jobs more frequently has helped me escape from jobs where the work was boring or which placed me under managers which were difficult to deal with.

More machine language fun

When I first starting working as a Senior System Analyst at GEISCO (GE Information Systems) in the mid-1980s, they had us logging into mini and mainframe computers via terminals.  Several of the commands we had to use needed elevated privileges which required us to enter a password of the day.  In order to get this special password, they gave us a small script which retrieved this password and most people put a call to this script as part of their network login to automatically show the password of the day.  Being a curious sort, I wanted to know how the script to display the password worked.  Most people found it cryptic since it consisted of several groups of 12 digit numbers and none of the digits were larger than 7.  I knew this likely meant that these digits were octal numbers which require 3 bits each to represent.  Couple that with the fact that the groupings of numbers were 12 digits long told me that they represented 36 bit words.  Since I knew GE made heavy use of Honeywell mainframe computers at the time, I concluded that the script was some type of interpreted machine language program.  So I dug out my old Honeywell assembly language documentation and discovered that the script was a simple little program to issue a system call (MME - Master Mode Entry) and then print out the results.  To test my theory further, I modified the program to shift the characters of the master password so they would print out backwards.  It basically served to entertain me each time I logged in.  It's amazing the little challenges which I find amusing, huh?

While I was working at GE, a project was launched to upgrade the storage device on the CC (Central Concentrator) network node.  One of the tasks performed by the CC was to load software on the other, smaller network nodes and its original 2 MB device was deemed too small to handle network expansion.  Believe it or not, that 2 MB storage device was a magnetic drum from Vermont Research.  I had signed up for this project because the replacement storage device was originally specified as a 10 MB hard drive similar to those used on higher end PCs of that time.  I was anxious to get experience on these disk devices which were cutting edge technology at the time and writing a device driver from scratch sounded like fun.  Somehow Vermont Research found out about the project and submitted a lower bid for an upgrade to a 10 MB drum device.  So my dreams of writing a device driver became the much less interesting task of updating the old device driver to extend the addressing to accommodate the extra storage.  The only challenging part of the project was that the diagnostic program also needed to be updated and somehow the source code for the diagnostic had been lost.  So I was forced to read the punched card deck into the mainframe in order to print out the binary data the deck contained so I could disassemble it.  Then I had to figure out how to write a patch for the diagnostic program.  And finally, I had to figure out how to get the mainframe's card punch to reproduce the same punch card format used by the diagnostic.  For a few days the computer operators for the mainframe got used to me making multiple daily attempts to convert the binary file containing my patches into a format which could be punched in the same format as the diagnostic deck.  They told me that they hadn't seen anyone use the card punch in many years.  Each attempt required me to tweak my program to convert the diagnostic's binary data into a slightly different format.  It wasn't as much fun as I had hoped for but it did prove pretty challenging.

The joys of machine language programming

When I started my career as a field engineer for Honeywell mainframe computers in the late 1970s, I worked a lot of swing and midnight shifts.  While day shift was always pretty busy, the night shifts were often boring.  To entertain myself, I read the CPU manuals with the goal of being able to modify the diagnostic programs used to test the computers.  Occasionally it proved handy to load one of the diagnostics and then to patch them in memory to loop through operations which were failing.  This allowed using an oscilloscope to trace signals of interest though the 80 wire-wrap boards which made up the CPU.

Eventually writing these machine language programs became my favorite pastime on slow nights.  Part of the draw was the maintenance panel switches which made it easy to read and write memory locations.  There was a definite thrill to getting a program working and watching its progress via the flashing lights on the maintenance panel.

For those who aren't familiar with low level programming, machine language programming involves directly entering the binary encoded instructions into memory locations for later execution.  More people are familiar with assembly language programming which replaced the binary programming with mnemonic names for the instructions and any modifiers.  For example, a Honeywell mainframe had an instruction called LDA which loaded the A (or accumulator) register with some value.  In machine language programming, that LDA instruction had the opcode of octal 235.  Older mainframes often used octal encoding instead of the hexadecimal encoding which is more often used today.  The other convenience offered by using assembly language over machine language is that the assembler would calculate the addresses automatically rather than forcing you to manually calculate the address offsets by hand which was painful.

My second job was as a field engineer for DEC PDP-11 minicomputers.  These smaller machines were so much less complex than the mainframes that fixing the hardware wasn't much of a challenge.  The saving grace was the PDP-11 instruction set was simple enough to allow me to quickly come up to speed on its machine language.  When I was in Boston for training, I wrote a machine language program to determine which terminal connected to the PDP-11 had had data entered on its keyboard.  Apparently the way I approached programming was different than most people's because the instructors had trouble figuring out how my program worked.

Believe it or not, the ability to decipher machine language is still useful when I have to use gdb to debug a program.

Memories of a very dear friend

It's been a week since we got the sad news that a dear friend of ours had passed away unexpectedly.  Since that time, David has been in my thoughts a lot.  Because I had the pleasure of working with David at 5 different companies for a total of 16 years and had also enjoyed his company after work on a regular basis, I know a number of his work friends.  I tried to help share the news of David's passing.  One of our friends responded by commenting how well David and I had clicked which made me smile.

I met David in 1990 when I left a contracting position at the Washington Navy Yard for a job with Sprint International which created equipment for Sprint's packet switching network.  My boss at Sprint was a Brit I had previously worked with at GEISCO.  My boss was a firm believer in getting out of the office at lunch and arranged regular outings to various ethnic restaurants in the area, something he had also previously done at GE.  I think it was at one of those lunches where I first met David.  As we chatted, it became obvious that we had similar tastes in books and movies.  We started eating lunch together on a regular basis.  My boss was also keen on regular after work happy hours, which occasionally involved playing darts.  David and I enjoyed many of those gatherings, sometimes playing darts.

Initially at Sprint, David and I were working on different types of PADs (packet assembler/disassembler) network nodes at Sprint.  I was working on a QLLC PAD which enabled IBM equipment to connect over Sprint's X.25 network.  David worked on more traditional PADs until Sprint started developing Frame Relay, which was a hot new network technology at the time.  Frame Relay was the perfect place for David as he picked up new technologies so easily.

After a couple years, I transferred to Sprint's Operating System group which gave David and I more chances to work together.  I enjoyed that opportunity since I discovered that he and I had compatible troubleshooting approaches.  I believe that came from both of us having started out working on computer hardware, him designing it and me repairing it.  

David and I enjoyed getting together outside of work which continued after I left Sprint in 1994.  It was at one of the after work gatherings that I remember us arguing over the actor's name who had uttered a line in the movie "Cool Hand Luke".  Fortunately, there was a movie store next to the restaurant where we were.  David and I left happy hour for a few minutes so we could consult the movie guides next door to settle the argument.  Other people at happy hour laughed at us for needing to prove our geek cred that way.  That's just one of many little happy moments with David that make me smile when I remember them.

The next time we worked together was in 2000.  At the time, David was working for a startup company which was developed financial problems, as many small startup companies do.  I was happy to help him get a job at 3Com where I was working at the time.  I was developing firmware for a number of ADSL modems while David was helping the ADSL architecture group.  This was another ideal position for David since network architecture requires expertise in so many different areas and David was always eager for opportunities to learn new technologies.  3Com was challenging since the schedules were incredibly aggressive.  That was because the group we were part of sold hardware to consumers which is a rapidly changing environment.

Later in 2000, David and I were both contacted by someone we both worked with back at Sprint who had taken a management position at a new optical networking startup company called Ocular Networks.  We both took the plunge and joined within a month of each other.  Ocular gave us the chance to work closely together on a regular basis.  David initially worked on a DS1 board while I worked on a DS3 board.  These boards provided electrical network interfaces which could be concentrated over the fiber optic network cables.  Like many early stage startups, Ocular required that we work 60-70 hour weeks for the first couple of years.  Fortunately things slowed down a bit after Ocular was purchased by Tellabs.  Tellabs moved our office from Reston to Ashburn.  It wasn't long until we discovered that our new office was very close to the Old Dominion brewpub which became a favorite place for after work gatherings.

The group of engineers I had met at Ocular, many of whom I had worked with at other companies, were so nice that shortly before I left Ocular in 2004, I organized an e-mail list to make it easier to organize regular get togethers as people left for new companies.  I often think how ironic it is that someone as naturally introverted as I am ended up in the role of organizer for activities outside of work.  That's due in large part to David and a few others like him who I couldn't bear the thought of losing contact with.

After Ocular, I took a position at AOL in the e-mail server group.  David also moved to AOL shortly after that and we found a way to work together again.  Unfortunately, the group we were with disbanded before too long and despite being moved to another group together, we both ended up leaving AOL.

For the next 10 years or so, we only saw each other for lunch or for an after work happy hour but fortunately those meetings were regular enough so we didn't lose contact.

In 2015, David joined a company called FourthWall Media, where I had been working for 5 years.  We got to spend another 5 years working together before a shift in company direction resulted in both of us getting laid off.  FourthWall was fond of company outings and I have happy memories of baseball games and visits to Top Golf to unwind.

The pandemic limited our in-person get togethers for a while but since I hated the thought of losing touch with David and a few others, I started a weekly video chat call on Skype which has been something we all looked forward to each week.

Over the 35 years I've known him, David has been someone whose company I have enjoyed and whose opinions I have valued.  He was an absolute joy to work with since he's very knowledgeable and extremely easy to work with.  We've shared recommendations for books, movies, music, and beer.  In the week since I learned of his passing, I've encountered a number of things which I wanted to share with him only to remember that he's no longer available.  He will be missed more than words can express.

Here's a picture of David and me at the Lost Rhino Oktoberfest in September, 2023.  I'm at the front left and David was directly across from me, looking at his phone.  This photo makes me smile because we spent part of the day trying to answer trivia questions posed by the musician who was playing.  We were up to our old geeky tricks that day.