Computer

NOTE: Work In Progress

Computer

In embedded engineering, a computer is needed for every step of the process:

• Design.

• Development.

• Deployment.

The following lists are not exhaustive. They focus on 95% of the work I do. Most of my hands on development has been in embedded platform code. My other roles have been architecture of embedded systems. My needs are typical of an embedded engineer leaning into the firmware side. Software engineers working on GUI and application layers will have different needs.

The key software packages I run on my computer are:

• Web browser.

• PDF reader.

• Text Editor.

  • VIM

  • Notepad++

• Compiler/assembler.

• Flash programmer.

• Debugger.

• Protocol Analyzers.

• Software based oscilloscopes.

• IDE.

  • VSCode

  • Sublime

  • SlickEdit

• Serial console.

• Word processor.

• Spread sheet.

• Version control tool.

• Schematic/layout viewer.

• Drawing packages.

At times I also use:

• Virtual machines.

• Remote GUI access.

• SSH terminals.

• Calculator.

• VISA based tool GUIs.

  • Power supplies

  • Digital Multi Meters

  • Oscilloscopes

• Bespoke evaluation tools.

  • TI radio module HDK

For the most part, the most important features of a PC for me are:

• Screen size and resolution.

• Network stability and speed.

• RAM.

• CPU.

• USB ports.

• Mass storage speed.

And, on occasion:

• PCIE card slots

• Serial ports (native)

Unlike many users, I am not as concerned about:

• GPU.

• Mass storage size.

You will need to know the requirements of the software you are using to be able to determine how much computer you will need.

Driving factors on Computer Requirements

Compile time

For an embedded engineer, indeed any engineer using a compiled language, compile time becomes critical.

Compilation will cause several temporary files to be created for each source code file. Depending on your compiler these files may only be created in RAM, but you always have options to keep all the interim files. A fast hard drive, and plenty of RAM is needed for the compilation of a project. Compilation is traditionally CPU work, not GPU.

My last few work laptops have been SSD based for speed, and had the best CPU available, and the most and fastest RAM offered.

I also have taken the smaller drive option, 2TB on a MacBook, and 1TB on a Dell Windows 10 system. In both cases, for work I have used about 500GB as the upper limit disk utilization, even with several clones of the repositories and all the interim files from a build.

Of course, who knows what compilers will look like soon. There may be a break from tradition, especially with machine learning and AI. The GPU may become an important part of the equation for these methods, or a new AI co-processor may come into existence.

Screen size

I must admit I'm all over the place on this. I really like a dual monitor set up. This allows side by side viewing for

• datasheets

• source code editor/debugger

• serial console/terminal

• schematics

Yes, you can switch between applications to see these things sequentially. I find it better to have a few things available concurrently.

When I diff code, I prefer a side by side view. This is just a personal preference. Since source code typically is limited to 80 or 120 characters per line, a display that can support about 250 characters reduces the amount of wrapping in a diff. I still write with an 80 character limit, that means 180 characters.

A side by side diff is not the only time I like this width. Markdown editors often allow composition in a source code pane, and have a live preview pane alongside. I write most of my documentation in Markdown now as it works well for blogs, GitHub, and Pandoc. Allowing multiple panes is common in IDEs and text editors, allowing you to see multiple files. You can work on implementation while looking at the header file for example.

Ports

We seem to be getting to a world where the number of physical ports on a laptop is dropping to just a couple if USB Type C or Lightening ports. If we are lucky, these are straight off of the CPU, but more often they are already on an internal hub. For most uses, with USB 3.1 speeds, this is not a big issue.

There are some ports that change their personality subtly when they are USB connected. Serial ports used to run smoothly with the driver responding to shallow FIFOs. Now the serial ports are serviced by a USB driver. The endpoints are fetched periodically, round robin. Data throughput is fine, and latency typically low. A problem unique to embedded engineers is that we sometimes use a serial port to monitor a live system. Serial protocol analyzers running on a modern PC timestamp the serial data with the USB activity time stamp. This looses some key timing information about the physical bus we are monitoring.

USB re-enumerates on device connection and removal. Adding a device, such as a thumb drive, will trigger enumeration. During enumeration, our data streams are not being serviced.

There are ways to manage this, but having all ports on a PC be on one single internal hub can lead to unanticipated behaviors.