Q&A: Embedded Systems Consultant

Elecia White is an embedded systems engineer, consultant, author, and innovator. She has worked on a variety of projects: DNA scanners, health-care monitors, learning toys, and fingerprint recognition.—Nan Price, Associate Editor

 

NAN: Tell us about your company Logical Elegance. When and why did you start the company? What types of services do you provide?

ELECIA: Logical Elegance is a small San Jose, CA-based consulting firm specializing in embedded systems. We do system analysis, architecture, and software implementation for a variety of devices.

Elecia White

Elecia White

I started the company in 2004, after leaving a job I liked for a job that turned out to be horrible. Afterward, I wasn’t ready to commit to another full-time job; I wanted to dip my toe in before becoming permanent again.

I did eventually take another full-time job at ShotSpotter, where I made a gunshot location system. Logical Elegance continued when my husband, Chris, took it over. After ShotSpotter, I returned to join him. While we have incorporated and may take on a summer intern, for the most part Logical Elegance is only my husband and me.

I like consulting, it lets me balance my life better with my career. It also gives me time to work on my own projects: writing a book and articles, playing with new devices, learning new technologies. On the other hand, I could not have started consulting without spending some time at traditional companies. Almost all of our work comes from people we’ve worked with in the past, either people we met at companies where we worked full time or people who worked for past clients.

Here is Elecia’s home lab bench. She conveniently provided notes.

Here is Elecia’s home lab bench. She conveniently provided notes.

NAN: Logical Elegance has a diverse portfolio. Your clients have ranged from Cisco Systems to LeapFrog Enterprises. Tell us about some of your more interesting projects.

ELECIA: We are incredibly fortunate that embedded systems are diverse, yet based on similar bedrock. Once you can work with control loops and signal processing, the applications are endless. Understanding methodologies for concepts such as state machines, interrupts, circular buffers, and working with peripherals allows us to put the building blocks together a different way to suit a particular product’s need.

For example, for a while there, it seemed like some of my early work learning how to optimize systems to make big algorithms work on little processors would fall to the depths of unnecessary knowledge. Processors kept getting more and more powerful. However, as I work on wearables, with their need to optimize cycles to extend their battery life, it all is relevant again.

We’ve had many interesting projects. Chris is an expert in optical coherence tomography (OCT). Imagine a camera that can go on the end of a catheter to help a doctor remove plaque from a clogged artery or to aid in eye surgery. Chris is also the networking expert. He works on networking protocols such as Locator/ID Separation Protocol (LISP) and multicast.

I’m currently working for a tiny company that hopes to build an exoskeleton to help stroke patients relearn how to walk. I am incredibly enthusiastic about both the application and the technology.

That has been a theme in my career, which is how I’ve got this list of awesome things I’ve worked on: DNA scanners, race cars and airplanes, children’s toys, and a gunshot location system. The things I leave off the list are more difficult to describe but no less interesting to have worked on: a chemical database that used hydrophobicity to model uptake rates, a medical device for the operating room and ICU, and methods for deterring fraud using fingerprint recognition on a credit card.

Elecia says one of the great things about the explosion of boards and kits available is being able to quickly build a system. However, she explains, once the components work together, it is time to spin a board. (This system may be past that point.)

Elecia says one of the great things about the explosion of boards and kits available is being able to quickly build a system. However, she explains, once the components work together, it is time to spin a board. (This system may be past that point.)

In the last few years, Chris and I have both worked for Fitbit on different projects. If you have a One pedometer, you have some of my bits in your pocket.

The feeling of people using my code is wonderful. I get a big kick seeing my products on store shelves. I enjoyed working with Fitbit. When I started, it was a small company expanding its market; definitely the underdog. Now it is a success story for the entire microelectromechanical systems (MEMS) industry.

Not everything is rosy all the time though. For one start-up, the algorithms were neat, the people were great, and the technology was a little clunky but still interesting. However, the client failed and didn’t pay me (and a bunch of other people).

When I started consulting, I asked a more experienced friend about the most important part. I expected to hear that I’d have to make myself more extroverted, that I’d have to be able to find more contracts and do marketing, and that I’d be involved in the drudgery of accounting. The answer I got was the truth: the most important part of consulting is accounts receivable. Working for myself—especially with small companies—is great fun, but there is a risk.

NAN: How did you get from “Point A” to Logical Elegance?

ELECIA: ”Point A” was Harvey Mudd College in Claremont, CA. While there, I worked as a UNIX system administrator, then later worked with a chemistry professor on his computational software. After graduation, I went to Hewlett Packard (HP), doing standard software, then a little management. I was lured to another division to do embedded software (though we called it firmware).

Next, a start-up let me learn how to be a tech lead and architect in the standard start-up sink-or-swim methodology. A mid-size company gave me exposure to consumer products and a taste for seeing my devices on retailer’s shelves.

From there, I tried out consulting, learned to run a small business, and wrote a Circuit Cellar Ink article “Open Source Code Guide” (Issue 175, 2005). I joined another tiny start-up where I did embedded software, architecture, management, and even directorship before burning out. Now, I’m happy to be an embedded software consultant, author, and podcast host.

NAN: You wrote Making Embedded Systems: Design Patterns for Great Software (O’Reilly Media, 2011). What can readers expect to learn from the book?

ELECIA: While having some industry experience in hardware or software will make my book easier to understand, it is also suitable for a computer science or electrical engineering college student.

It is a technical book for software engineers who want to get closer to the hardware or electrical engineers who want to write good software. It covers many types of embedded information: hardware, software design patterns, interview questions, and a lot of real-world wisdom about shipping products.

Elecia White's BookMaking Embedded Systems is intended for engineers who are in transition: the hardware engineer who ends up writing software or the software engineer who suddenly needs to understand how the embedded world is different from pure software.

Unfortunately, most college degrees are either computer science or electrical engineering. Neither truly prepares for the half-and-half world of an embedded software engineer. Computer science teaches algorithms and software design methodology. Electrical engineering misses both of those topics but provides a practical tool kit for doing low-level development on small processors. Whichever collegiate (or early career) path, an embedded software engineer needs to have familiarity with both.

I did a non-traditional major that was a combination of computer science and engineering systems. I was prepared for all sorts of math (e.g., control systems and signal processing) and plenty of programming. All in all, I learned about half of the skills I needed to do firmware. I was never quite sure what was correct and what I was making up as I went along.

As a manager, I found most everyone was in the same boat: solid foundations on one side and shaky stilts on the other. The goal of the book is to take whichever foundation you have and cantilever a good groundwork to the other half. It shouldn’t be 100% new information. In addition to the information presented, I’m hoping most people walk away with more confidence about what they know (and what they don’t know).

Elecia was a judge at the MEMS Elevator Pitch Session at the 2013 MEMS Executive Congress in Napa, CA.

Elecia was a judge at the MEMS Elevator Pitch Session at the 2013 MEMS Executive Congress in Napa, CA.

NAN: How long have you been designing embedded systems? When did you become interested?

ELECIA: I was a software engineer at the NetServer division at HP. I kept doing lower-level software, drivers mostly, but for big OSes: WinNT, OS/2, Novell NetWare, and SCO UNIX (a list that dates my time there).

HP kept trying to put me in management but I wasn’t ready for that path, so I went to HP Labs’s newly spun-out HP BioScience to make DNA scanners, figuring the application would be more interesting. I had no idea.

I lit a board on fire on my very first day as an embedded software engineer. Soon after, a motor moved because my code told it to. I was hooked. That edge of software, where the software touches the physical, captured my imagination and I’ve never looked back.

NAN: Tell us about the first embedded system you designed. Where were you at the time? What did you learn from the project?

ELECIA: Wow, this one is hard. The first embedded system I designed depends on your definition of “designed.” Going from designing subsystems to the whole system to the whole product was a very gradual shift, coinciding with going to smaller and smaller companies until suddenly I was part of the team not only choosing processors but choosing users as well.

After I left the cushy world of HP Labs with a team of firmware engineers, several electrical engineers, and a large team of software engineers who were willing to help design and debug, I went to a start-up with fewer than 50 people. There was no electrical engineer (except for the EE who followed from HP). There was a brilliant algorithms guy but his software skills were more MATLAB-based than embedded C. I was the only software/firmware engineer. This was the sort of company that didn’t have source version control (until after my first day). It was terrifying being on my own and working without a net.

I recently did a podcast about how to deal with code problems that feel insurmountable. While the examples were all from recent work, the memories of how to push through when there is no one else who can help came from this job.

Elecia is shown recording a Making Embedded Systems episode with the founders of electronics educational start-up Light Up. From left to right: Elecia’s husband and producer Christopher White, host Elecia White, and guests Josh Chan and Tarun Pondicherry.

Elecia is shown recording a Making Embedded Systems episode with the founders of electronics educational start-up Light Up. From left to right: Elecia’s husband and producer Christopher White, host Elecia White, and guests Josh Chan and Tarun Pondicherry.

NAN: Are you currently working on or planning any projects?

ELECIA: I have a few personal projects I’m working on: a T-shirt that monitors my posture and a stuffed animal that sends me a “check on Lois” text if an elderly neighbor doesn’t pat it every day. These don’t get nearly enough of my attention these days as I’ve been very focused on my podcast: Making Embedded Systems on iTunes, Instacast, Stitcher, or direct from http://embedded.fm.

The podcast started as a way to learn something new. I was going to do a half-dozen shows so I could understand how recording worked. It was a replacement for my normal community center classes on stained glass, soldering, clay, hula hooping, laser cutting, woodshop, bookbinding, and so forth.

However, we’re way beyond six shows and I find I quite enjoy it. I like engineering and building things. I want other people to come and play in this lovely sandbox. I do the show because people continue to share their passion, enthusiasm, amusement, happiness, spark of ingenuity, whatever it is, with me.

To sum up why I do a podcast, in order of importance: to talk to people who love their jobs, to share my passion for engineering, to promote the visibility of women in engineering, and to advertise for Logical Elegance (this reason is just in case our accountant reads this since we keep writing off expenses).

NAN: What are your go-to embedded platforms? Do you have favorites, or do you use a variety of different products?

ELECIA: I suppose I do have favorites but I have a lot of favorites. At any given time, my current favorite is the one that is sitting on my desk. (Hint!)

I love Arduino although I don’t use it much except to get other people excited. I appreciate that at the heart of this beginner’s board (and development system) is a wonderful, useful processor that I’m happy to work on.

I like having a few Arduino boards around, figuring that I can always get rid of the bootloader and use the Atmel ATmega328 on its own. In the meantime, I can give them to people who have an idea they want to try out.

For beginners, I think mbed’s boards are the next step after Arduino. I like them but they still have training wheels: nice, whizzy training wheels but still training wheels. I have a few of those around for when friends’ projects grow out of Arduinos. While I’ve used them for my own projects, their price precludes the small-scale production I usually want to do.

Professionally, I spend a lot of time with Cortex-M3s, especially those from STMicroelectronics and NXP Semiconductors. They seem ubiquitous right now. These are processors that are definitely big enough to run an RTOS but small enough that you don’t have to. I keep hearing that Cortex-M0s are coming but the price-to-performance-to-power ratio means my clients keep going to the M3s.

Finally, I suppose I’ll always have a soft spot for Texas Instruments’s C2000 line, which is currently in the Piccolo and Delfino incarnations. The 16-bit byte is horrible (especially if you need to port code to another processor), but somehow everything else about the DSP does just what I want. Although, it may not be about the processor itself: if I’m using a DSP, I must be doing something mathy and I like math.

NAN: Do you have any predictions for upcoming “hot topics?”

ELECIA: I’m most excited about health monitoring. I’m surprised that Star Trek and other science fiction sources got tricorders right but missed the constant health monitoring we are heading toward with the rise of wearables and the interest in quantified self.
I’m most concerned about connectivity. The Internet of Things (IoT) is definitely coming, but many of these devices seem to be more about applying technology to any device that can stand the price hit, whether it makes sense or not.

Worse, the methods for getting devices connected keeps fracturing as the drive toward low-cost and high functionality leads the industry in different directions. And even worse, the ongoing battle between security and ease of use manages to give us things that are neither usable nor secure. There isn’t a good solution (yet). To make progress we need to consider the application, the user, and what they need instead of applying what we have and hoping for the best.

A Trace Tool for Embedded Systems

Tracing tools monitor what is going in a program’s execution by logging low-level and frequent events. Thus tracing can detect and help debug performance issues in embedded system applications.

In Circuit Cellar’s April issue, Thiadmer Riemersma describes his DIY tracing setup for small embedded systems. His system comprises three parts: a set of macros to include in the source files of a device under test (DUT), a PC workstation viewer that displays retrieved trace data, and a USB dongle that interfaces the DUT with the workstation.

Small embedded devices typically have limited-performance microcontrollers and scarce interfaces, so Riemersma’s tracing system uses only a single I/O pin on the microcontroller.

Designing a serial protocol that keeps data compact is also important. Riemersma, who develops embedded software for the products of his Netherlands-based company, CompuPhase, explains why:

Compactness of the information transferred from the embedded system to the workstation [which decodes and formats the trace information] is important because the I/O interface that is used for the transfer will probably be the bottleneck. Assuming you are transmitting trace messages bit by bit over a single pin using standard wire and 5- or 3.3-V logic levels, the transfer rate may be limited to roughly 100 Kbps.

My proposed trace protocol achieves compactness by sending numbers in binary, rather than as human-readable text. Common phrases can be sent as numeric message IDs. The trace viewer (or trace ‘listener’) can translate these message IDs back to the human-readable strings.

One important part of the system is the hardware interface—the trace dongle. Since many microcontrollers are designed with only those interfaces used for specific application needs, Riemersma says, typically the first step is finding a spare I/0 pin that can be used to implement the trace protocol.

In the following article excerpt, Riemersma describes his trace dongle and implementation requiring a single I/O pin on the microcontroller:

This is the trace dongle.

This is the trace dongle.

Photo 1 shows the trace dongle. To transmit serial data over a single pin, you need to use an asynchronous protocol. Instead of using a kind of (bit-banged) RS-232, I chose biphase encoding. Biphase encoding has the advantage of being a self-clocking and self-synchronizing protocol. This means that biphase encoding is simple to implement because timing is not critical. The RS-232 protocol requires timing to stay within a 3% error margin; however, biphase encoding is tolerant to timing errors of up to 20% per bit. And, since the protocol resynchronizes on each bit, error accumulation is not an issue.

Figure 1 shows the transitions to transmit an arbitrary binary value in biphase encoding—to be more specific, this variant is biphase mark coding. In the biphase encoding scheme, there is a transition at the start of each bit.

Figure 1: This is an example of a binary value transferred in biphase mark coding.

Figure 1: This is an example of a binary value transferred in biphase mark coding.

For a 1 bit there is also a transition halfway through the clock period. With a 0 bit, there is no extra transition. The absolute levels in biphase encoding are irrelevant, only the changes in the output line are important. In the previous example, the transmission starts with the idle state at a high logic level but ends in an idle state at a low logic level.

Listing 1 shows an example implementation to transmit a byte in biphase encoding over a single I/O pin. The listing refers to the trace_delay() and toggle_pin() functions (or macros). These system-dependent functions must be implemented on the DUT. The trace_delay() function should create a short delay, but not shorter than 5 µs (and not longer than 50 ms). The toggle_pin() function must toggle the output pin from low to high or from high to low.

For each bit, the function in Listing 1 inverts the pin and invokes trace_delay() twice. However, if the bit is a 1, it inverts the pin again between the two delay periods. Therefore, a bit’s clock cycle takes two basic “delay periods.”

Listing 1: Transmitting a byte in biphase encoding, based on a function to toggle an I/O pin, is shown.

Listing 1: Transmitting a byte in biphase encoding, based on a function to toggle an I/O pin, is shown.

The biphase encoding signal goes from the DUT to a trace dongle. The dongle decodes the signal and forwards it as serial data from a virtual RS-232 port to the workstation (see Photo 2 and the circuit in Figure 2).

Photo 2: The trace dongle is inserted into a laptop and connected to the DUT.

Photo 2: The trace dongle is inserted into a laptop and connected to the DUT.

This trace dongle interprets biphase encoding.

Figure 2: This trace dongle interprets biphase encoding.

The buffer is there to protect the microcontroller’s input pin from spikes and to translate the DUT’s logic levels to 5-V TTL levels. I wanted the trace dongle to work whether the DUT used 3-, 3.3-, or 5-V logic. I used a buffer with a Schmitt trigger to avoid the “output high” level of the DUT at 3-V logic, plus noise picked up by the test cable would fall in the undefined area of 5-V TTL input.

Regarding the inductor, the USB interface provides 5 V and the electronics run at 5 V. There isn’t room for a voltage regulator. Since the USB power comes from a PC, I assumed it might not be a “clean” voltage. I used the LC filter to reduce noise on the power line.

The trace dongle uses a Future Technology Devices International (FTDI) FT232RL USB-to-RS-232 converter and a Microchip Technology PIC16F1824 microcontroller. The main reason I chose the FT232RL converter is FTDI’s excellent drivers for multiple OSes. True, your favorite OS already comes with a driver for virtual serial ports, but it is adequate at best. The FTDI drivers offer lower latency and a flexible API. With these drivers, the timestamps displayed in the trace viewers are as accurate as what can be achieved with the USB protocol, typically within 2 ms.

I chose the PIC microcontroller for its low cost and low pin count. I selected the PIC16F1824 because I had used it in an earlier project and I had several on hand. The microcontroller runs on a 12-MHz clock that is provided by the FTDI chip.

The pins to connect to the DUT are a ground and a data line. The data line is terminated at 120 Ω to match the impedance of the wire between the dongle and the DUT.

The cable between the DUT and the trace dongle may be fairly long; therefore signal reflections in the cable should be considered even for relatively low transmission speeds of roughly 250 kHz. That cable is typically just loose wire. The impedance of loose wire varies, but 120 Ω is a good approximate value.

The data line can handle 3-to-5-V logic voltages. Voltages up to 9 V do not harm the dongle because it is protected with a Zener diode (the 9-V limit is due to the selected Zener diode’s maximum power dissipation). The data line has a 10-kΩ to 5-V pull-up, so you can use it on an open-collector output.

The last item of interest in the circuit is a bicolor LED that is simply an indicator for the trace dongle’s status and activity. The LED illuminates red when the dongle is “idle” (i.e., it has been enumerated by the OS). It illuminates green when biphase encoded data is being received.

After the dongle is built, it must be programmed. First, the FT232RL must be programmed (with FTDI’s “FT Prog” program) to provide a 12-MHz clock on Pin C0. The “Product Description” in the USB string descriptors should be set to “tracedongle” so the trace viewers can find the dongle among other FTDI devices (if any). To avoid the dongle being listed as a serial port, I also set the option to only load the FTDI D2XX drivers.

To upload the firmware in the PIC microcontroller, you need a programmer (e.g., Microchip Technology’s PICkit) and a Tag-Connect cable, which eliminates the need for a six-pin header on the PCB, so it saves board space and cost.

The rest of the article provides details of how to create the dongle firmware, how to add trace statements to the DUT software being monitored, and how to use the GUI version of the trace viewer.

The tracing system is complete, but it can be enhanced, Riemersma says. “Future improvements to the tracing system would include the ability to draw graphs (e.g., for task switches or queue capacity) or a way to get higher precision timestamps of received trace packets,” he says.

For Riemersma’s full article, refer to our April issue now available for membership download or single-issue purchase.

Serial Carrier Card with Flexible I/O and Serial Technology

New 3U CompactPCI Serial Carrier Card from MEN Micro IntegratesThe G204 is a 3U CompactPCI Serial carrier card with an M-Module slot that combines fast CompactPCI Serial technology with flexible I/O options. The card serves as the basis for powerful 19″-based system solutions for transportation and industrial applications (e.g., data acquisition, process control, automation and vehicle control, robotics or instrumentation).

M-Modules are modular I/O extensions for industrial computers (e.g., embedded systems and high-end workstations). The M-Module slot enables users to interchange more than 30 I/O functions within a system. The M-Module, which needs only one CompactPCI Serial slot, is screwed tightly onto the G204 and does not require a separately mounted transition panel.

The G204 modular mezzanine card operates in a –40°C to 85°C extended temperature range for harsh environments and costs $483.

MEN Micro Inc.
www.menmicro.com

Open-Source Guide for Embedded Systems Developers (EE Tip #114)

What comes to mind when you hear the term “open source”? Hopefully, it means more to you than just a software application running on a PC.

As an embedded systems developer, you should familiarize yourself with the wide range of open-source programs, programming tools, and hardware platforms currently available. In addition to saving yourself the costs of pricey user licenses, you’ll find that open-source community forums helpful, informative, and engaging.

Open-source software offers a number of advantages. The product is independent of a particular manufacturer and there aren’t license costs. Plus, the product is usually high quality because it is often supported by a large active community of users. When a program’s source code is available, you have the chance to fix errors, change its behavior, and even add new features.

The aforementioned advantages should be good enough reasons for any designer of microcontroller applications to work with open-source software. PC tools such as editors, documentation programs, toolchains (for the vast majority of microcontrollers), operating systems, and libraries are widely available with open-source code.

On the hardware side, open-source microcontroller boards are gaining popularity among serious engineers. The circuits, PCBs, and CAD files are available so you can modify them, improve them, and add more features to meet the demands of your applications. It’s an added benefit that open-source hardware is always supported by software code and libraries that enable you to get up and running fairly quickly.

Since we couldn’t include in the space provided all the open-source resources currently available, we simply list several open-source projects that Elektor and Circuit Cellar engineers and editors recommend.

Below we provide the following lists: hardware; libraries and run-time tools; PC tools, and GNU toolchains. By no means are the lists complete. Still, they’re helpful starting points.

Download your Arduino Uno poster

Click image to download a free Arduino Uno poster

Arduino—This popular platform offers a range of simple microcontroller and development boards that you can purchase from several suppliers. The Arduino website has an active forum and the wide range of software examples will ensure that you are up and running in minimum time.

Openmoko—It’s a complete software stack for a smart. The Neo FreeRunner mobile phone is the target hardware platform. Development and debug boards are also available.

GNU Radio & Universal Software Radio Peripheral—The GNU Radio project is a software toolkit to produce a software-defined radio. The open-source hardware for this project is the Universal Software Radio Peripheral (USRPBoard), which is based on an FPGA.

KiCAD—One of the best-known suites of CAD programs for hardware production, KiCAD includes tools for generating circuit diagrams and PCBs. You can view 3-D representations of the finished board.

Fab Lab—This interesting project offers 3-D laser cutters, 3-D printers, and other machines for use by the general public. It’s a handy resource for making robot parts and art objects.

uIP/lwIP—Two outstanding network stacks, the first is for 8-bit microcontrollers. lwIP is a development of the first and more suited to medium sized controllers. The uIP licence is not so strict allowing the stack to be used in commercial products.

LUFA (formally MyUSB)—A large library of applications for interfacing (both Host and Device) USB enabled AVR controllers. The demonstration applications allow an AVR controller for example to emulate a keyboard and many other devices (mass storage device, audio I/O etc.)OpenSource2

Crypto-avr-lib—It’s a library of optimized cryptographic routines for the Atmel ATmega controller. Issued under the GPL Version 3 licence. Contact the author for other types of licence.

FreeRTOS—FreeRTOS is a lightweight Real Time kernel which can run on many controller families. It can be used in commercial applications and allows the use of closed-source software.

U-Boot—Universal bootloader with a large range of routines for memory, UART interface, SD card, network and USB etc. Conceived originally as a bootloader but now through comprehensive hardware support can be used as the basis of a C code module.

Embedded Filesystems Library—A useful (FAT) file format, when you are short of memory. The GPL licence includes a clause allowing static linking to the library without public disclosure of your code.

.NET Micro Framework—Now open source this very compact, trimmed down .NET Framework running on diverse ARM platforms. Programmable using the object orientated C variant C#; lots of resources including support for I2C, Ethernet and many more. Helps reduce development time.

Eclipse—This is a good development environment. It has a modular structure which makes it very easy to configure. There are around 1,000 plug-in modules (both open source and commercial) for a range of program languages and target systems.

Kdevelop—Kdevelop is an integrated development environment which should satisfy most power-user needs. Runs in MS Windows, Mac OsX, Linux, Solaris and FreeBSD. Plug-in expandable.

Programmer’s Notepad—A lightweight but efficient editor for writing source code. Allows fast, simple and comfortable program production. Can be expanded with plug-ins.

Doxygen—An intelligent tool which can automatically generate code documentation (C, C++, Java etc.). The programmer provides tags in the source file; Doxygen generates the comprehensive documentation in PDF or HTML format. It can also extract the code structure from undocumented source files.

WinMerge—A good tool for code comparison and code synchronization. The program can also compare the contents of folders/files and display the results in a visual text format that makes it easy to understand.

Tera Term—A terminal program to access COM ports, supports Telnet communication Protocol. A debugging tool to eavesdrop on serial communications.

Note: Toolchains for GNU projects are available most processor architectures AVR, Coldfire, ARM, MIPS, PowerPC and Intel x86. The GNU-toolchain includes not only compilers for C, C++ and in most cases also Java (GCC = GNU Compiler Collection), but also Linkers, Assemblers and Debuggers together with C libraries (libc = C library). The tools are used from within other-open source projects, like WinAVR, which provides a familiar user interface to speed up program development.

One Desk Serves Two Roles for Professor and Designer

Chris Coulston, head of the Computer Science and Software Engineering department at Penn State Erie, The Behrend College, has a broad range of technical interests, including embedded systems, computer graphics algorithms, and sensor design.

Since 2005, he has submitted five articles for publication in Circuit Cellar, on projects and topics ranging from DIY motion-controlled gaming to a design for a “smart” jewelry pendant utilizing RGB LEDs.

We asked him to share photos and a description of the workspace in his Erie, PA, home. His office desk (see Photo 1) has something of an alter ego. When need and invention arise, he reconfigures it into an “embedded workstation.”

Coulston's workspace configured as an office desk

Photo 1: Coulston’s workspace configured as an office desk

When working on my projects, my embedded workstation contains only the essential equipment that I need to complete my project (see Photo 2).  What it lacks in quantity I’ve tried to make up for in quality instrumentation; a Tektronix TDS 3012B oscilloscope, a Fluke 87-V digital multimeter, and a Weller WS40 soldering iron.  While my workstation lacks a function generator and power supply, most of my projects are digital and have modest power requirements.

Coulston can reconfigure his desk into the embedded workstation pictured here.

Photo 2: Coulston can reconfigure his desk into the embedded workstation pictured here.

Coulston says his workspace must function as a “typical office desk” 80 percent of the time and electronics station 20 percent of the time.

It must do this while maintaining some semblance of being presentable—my wife shares a desk in the same space. The foundation of my workstation is a recycled desk with a heavy plywood backing on which I attached shelving. Being a bit clumsy, I’ve tried to screw down anything that could be knocked over—speakers, lights, bulletin board, power strip, cable modem, and routers.

The head of a university department has different needs in a workspace than does an electronics designer. So how does Coulston make his single office desk suffice for both his professional and personal interests? It’s definitely not a messy solution.

My role as department chair and professor means that I spend a lot time grading, writing, and planning. For this work, there is no substitute for uncluttered square footage—getting all the equipment off the working surface. However, when it’s time to play with the circuits, I need to easily reconfigure this space.

I have found organization to be key to successfully realize this goal. Common parts are organized in a parts case, parts for each project are put in their own bag, the active project is stored in the top draw, frequently used tools, jumper wires, and DMM are stored in the next draw. All other equipment is stored in a nearby closet.

I’ve looked at some of the professional-looking workspaces in Circuit Cellar and must admit that I am a bit jealous. However, when it comes to operating under the constraints of a busy professional life, I have found that my reconfigurable space is a practical compromise.

To learn more about Coulston and his technical interests, check out our Member Profile posted earlier this year.

 

Chris Coulston

Chris Coulston