Firmware Experience

About Firmware

Firmware is the engine that powers all embedded systems. As such, designing firmware to drive client's products is the backbone of our business. Having written programs for dozens of products, we are adept at all aspects of the business: the chips, the tools, the languages, and the applications.

Throughout our careers, microprocessors and microcontrollers have evolved and our experience reflects the resultant diversity. Today's firmware tools are powerful, integrated development environments that inevitably have similarities from one chip maker's product to another. This makes it easy for us to work with the ever-changing tools and chips.

Firmware is similar to software in that it is written in a standard programming language, compiled, debugged, and executed. We work mostly in C but have also used C# and C++. We occasionally code in assembler, but the need for that is rare and we are more likely to use our assembler prowess as a debugging aid.

Program Structure

There are many ways to organize a program:

  • Our simplest designs use a round-robin scheduler. This old, reliable method has a main loop that invokes a set of tasks in fixed order, either as fast as possible or triggered at a specific rate.
  • Another structure we use is a priority-based scheduler. Instead of invoking the tasks in fixed order, it invokes the highest priority, non-idle task. This arrangement improves processing efficiency by favoring more important tasks at the expense of less important ones.
  • A more complex approach uses a real time kernel or RTOS (such as Micrium's uC/OS-II) to implement preemptive multitasking. Now the highest priority task will run as soon as it is ready, interrupting other tasks if needed.
  • Some of our designs are event-driven rather than priority based. These use messages between independent tasks or an event queue with a centralized dispatcher. Instead of prioritzing tasks, each runs only when triggered by an event it must respond to.

User Interface

Embedded systems often have limited user interface capabilities. Among our many designs are these user interfaces:

  • 4-character 7-segment LED display for measurements and limited messages plus 4 hall-effect switches for calibration and alarm acknowledgement or resets
  • VGA display with overlaid grid of 64 touch-screen buttons programmed for multiple views of the data and navigation among views
  • multiple 4-character 7-segment LED displays for measured data, about a dozen discrete LEDs to identify units, scale, and other qualifiers, 10 more LEDs driven as a bargraph, and 4 pushbuttons for navigation and setup
  • 2-line 40 character alphanumeric display, a numeric keypad for data entry, and 4 pushbuttons placed around the display and programmed as menu selectors (soft keys)
  • no user interface at all -- one of many processors in a multiprocessor design
  • 64x128 pixel graphic LCD display, 2 pushbuttons, and a reed switch programmed to display measurement tables, graphs, and to navigate among multiple screens

Communications

Communication methods abound in embedded systems. These include serial data exchange on standard buses as well as serial or parallel busses internal to the product. Virtually all our designs use one or more forms of communications:

  • Custom drivers for Modbus RTU and ASCII protocols on RS485 bus
  • Modem communications, both RS232 data and voice, in which firmware initiates calls at preset intervals or on monitored conditions, receives calls, and manages a shared phone line.
  • Custom protocols for communication between processors in a multi-processor system or to communicate with remote devices in a distributed system
  • I2C/IIC to interface to digital ports, ADCs, DACs, EEPROMs. Designs include processors with I2C engines (hardware performs framing and timing) and without (bit-banging).
  • SPI to interface to ADCs, EEPROMs, real time clock chips
  • USB for both standard PC peripherals and for custom device applications.
  • Many of our designs include a serial port as a diagnostic data stream output continuously

Inputs & Data Acquisition

Most embedded systems input and process data. Our firmware measures analog information (speed, temperature, voltage, etc.) in many ways, such as by using analog-to-digital converters (ADCs), by timing pulse widths or intervals, or by counting pulses. Digital input sources include user data, communications data, parallel data, and switches (mechanical, hall-effect, reed, etc.)

Outputs and Controls

Many embedded systems must control external devices in some way. Our list includes motors, annunciators, lights & LEDs, relays, voice playback, buzzers & beepers, analog voltages & currents, solenoids, log files, diagnostic files, and more.

Not all outputs are devices. We also store gathered or processed data as log files or diagnostic files, or output it via communications or display.