WHAT S FIRMWARE?

In electronic systems and computing, firmware is a tangible electronic component with embedded software instructions, such as a BIOS. Typically, those software instructions are used to tell an electronic device how to operate. As of 2013, most firmware can be updated. Typical examples of devices containing firmware are embedded systems (such as traffic lights, consumer appliances, and digital watches), computers, computer peripherals, mobile phones, and digital cameras. The firmware contained in these devices provides the control program for the device.

Firmware is held in non-volatile memory devices such as ROM, EPROM, or flash memory. Changing the firmware of a device may rarely or never be done during its economic lifetime; some firmware memory devices are permanently installed and cannot be changed after manufacture. Common reasons for updating firmware include fixing bugs or adding features to the device. This may require ROM integrated circuits to be physically replaced, or flash memory to be reprogrammed through a special procedure. Firmware such as the ROM BIOS of a personal computer may contain only elementary basic functions of a device and may only provide services to higher-level software. Firmware such as the program of an embedded system may be the only program that will run on the system and provide all of its functions.

What is firmware used for?

Firmware, which is added at the time of manufacturing, is used to run user programs on the device and can be thought of as the software that allows hardware to run.

TYPES OF FIRMWARE

Types of firmware

BIOSThe first thing to come to life after the computer is powered on is BIOS. It can interact with the hardware and check for any unknown errors. It then signals another program called bootloader which does the job of waking up the operating system sleeping inside the hard drive and put it in the random access memory. So, BIOS is primarily responsible for handling your computer’s hardware components and ensure that they function properly. Although good, the low-level software has remained almost unchanged for the last two decades, and because of this, it is now becoming outdated and un-supportive of modern technologies. For instance, BIOS still uses 16-bit code while most laptops and PCs run 32 and 64-Bit code.

EFI

EFI, the abbreviated form of Extensible Firmware Interface is a specification for a new generation of system firmware that provides the first instructions used by the CPU to startup hardware and passes the control to the bootloader. EFI, sometimes also referred to as Unified Extensible Firmware Interface(UEFI) has certain advantages over BIOS. For instance, it helps ensure that your PC boots using only software that is trusted by the PC manufacturer, i.e., it supports a feature called ‘Secure Boot’ to improve security.

Knowing your computer’s BIOS version can help you find if you have the most up-to-date version of the firmware. On Windows computers, you can get the firmware version information using the Command Prompt. Alternatively, you can use an upgrade assistant for your device.

Generally speaking, to see the firmware version of any hardware, you can open Devices Manager, expand the category, select the hardware, right-click on it, and click Properties. Now under the Details tab, from the Property drop-down menu, select Hardware Ids. Here in the Value table, you should see the firmware version.

Firmware vs. Software difference

Often, the word Firmware and software are used interchangeably, i.e., single or a collection of computer programs assigned with some task to do on the machine. But in reality, it’s the work that defines the roots of these categories (firmware and software) in which we put them.

For example, software is virtual so it can be Copied, Changed, and Destroyed. It is often stored in memory that is easily accessible and even replaceable by the user. But in the case of firmware, the memory that it stores is often embedded in the device itself and is not replaceable by the user. This is done deliberately to prevent any tampering or removing as it is critical for the device to run and can cause serious consequences if removed.

Also, software is often upgraded, and so the information stored in it is often modified/altered with each execution of the application. In contrast, the firmware does not really change much unless you modify the settings very often. There is also very little or no requirement to change the firmware of a device.

Details on Firmware Features:

100 times faster than standard Lego supplied firmware

Replacement firmware is up to 100 times faster than the Lego supplied firmware. Lego firmware typically takes 3.2 milliseconds per opcode. In enhanced firmware (100X version), a no-op (opcode 0x10) opcode takes less than 10 microseconds to execute! New firmware interprets 16-bit add or subtract opcodes in under 30 microseconds. 16-bit conditional branch opcodes take 50 – 80 microseconds. Real-life measurements taken from live firmware. Time for opcode execution includes all operating system overhead (scheduler, sensor handling, LCD updates, interrupts, etc).

Typical performance appears to be 20,000 – 35,000 interpreter opcodes executed per second; these are actual measurements from a variety of sample programs. Standard Lego firmware does just over 300.

The performance improvements come from:

• Standard Lego firmware appears to use multiple levels of data abstraction to “hide” data between different modules. Overkill for this small application and lots of real time loss through procedure calls to get at data that could be stored in an “extern” variable.
• Selective coding of a few high-runner routines in hand-optimized assembler to get the best performance. The critical routine is the one that converts interpreter variables into actual values.
• Extremely efficient task scheduler compared to standard firmware. Standard firmware interpreter executes one opcode and then relinquishes control to other OS tasks. When opcode interpreter is given next time slice, it moves to next task and tries to execute one opcode; it ‘burns’ a time slice to every task even if that task is inactive. I’m guessing over 2/3 of the time spent executing an opcode is in the scheduling overhead. Enhanced firmware (10X) can be configured to interpret several opcodes in a single task timeslice; it does not ‘waste’ timeslices on interpreter tasks not able to run.
• Use of the Hitachi / Renesas tool chain for development. I found these tools to be far more efficient than GCC and others in both the size of generated code and its real time performance.

32-bit and floating opcodes are much slower. Floating point opcodes typically take 200+ microseconds each. This is because the H8 CPU is only an 8/16 bit CPU; arithmetic operations on ‘floats’ and ‘longs’ are done by software subroutines.

Backwards compatible with Lego™ standard firmware

The objective was to provide backwards compatibility with standard Lego firmware. This has been substantially achieved. See separate section providing more details.

256 total global variables (16 bit)

Standard Lego firmware supports 32 global variables and 16 variables per task. Replacement firmware expands support to 256 global variables.

Task variables are overlaid on the global variables 32 to 191.

New opcodes and intrinsic variables have been added to the firmware to support the expanded variable address space.

32-bit integer variables

New opcodes and intrinsic variables have been added to firmware to support 32-bit long integers. Each long integer occupies the space of two consecutive 16-bit integers.

Floating point variables

New opcodes and intrinsic variables have been added to firmware to support 32-bit float variables. Each long integer occupies the space of two consecutive 16-bit integers.

One millisecond resolution on timers

New firmware implements a single high-resolution (32-bit) clock variable with a one-millisecond period. Four Lego firmware compatible timers are then implemented using this clock variable.

New opcodes and intrinsic variables are implemented to provide full access to these timers. This includes variables that provide 1, 10 and 100-millisecond resolution; and new wait1Msec opcode to perform program waits using one millisecond resolution.

“Perfect” rotation counter support

The Lego rotation counters are wonderful sensors. Internally they have a fan blade interrupting two optical transmitter/receiver pairs. This provides 16 counts per revolution; there are four states for the optical T/R as each of the four fan blades rotates through them. However the sensor frequently provide spurious readings as each fan blade transitions under a optical T/R. Depending on rotation speed, error rates range from 0.05% (very fast speed) to over 60% (very slow).

New firmware provides a powerful software state machine to (hopefully) provide perfect rotation counter support. The state machine filters and eliminates transient readings.

Standard Lego firmware scans rotation sensor every three milliseconds leading to a theoretical maximum speed of 333 counts per second. However, the asymmetrical nature of the fan blade – the gap is different size from the blade – reduces the maximum speed to about 220 counts. RobotC supports maximum speed of ~1,300 counts per second; six times the capacity of the standard Lego firmware.

New firmware allows customization of the sensor scan rate through a new intrinsic variable. A one-byte value holds the number of milliseconds in the scan interval. A value of zero indicates a 0.5 millisecond scan rate. Of course, as the scan rate is reduced, less CPU time is available for user programs; at 0.5 millisecond rate, the byte code interpreter is about twice as slow as the ‘standard’ 3 millisecond rate.

Firmware resets the scan rate to 3 milliseconds on RCX power up.

Powerful debugging functions

New firmware has been designed for tight integration with a new IDE providing powerful debugging capabilities from the PC. New opcodes and capabilities have been implemented for debugging support including:

• The byte code interpreter can be suspended or resumed under PC IDE control.
• Opcodes are provided to allow the IDE to single step the byte code interpreter. Single step is provided for either a single instruction or single ‘C’ statement level (i.e. step for ‘n’ opcodes or until a instruction branch occurs).
• An ‘ASSERT’ opcode is provided to check for user programmed exceptions.
• Opcodes that provide very efficient upload of data to an IDE’s debugging windows (variable watchers, call stack display, task status, etc). Current firmware provides upload of some of these variables, but it is one variable at a time leading to slow updates and lots of IR messaging. New opcodes are provided to upload a block of variables in one message.
• Exception handling support in the interpreter (e.g. for stack underflow/overflow). Interpreter halts on exception with audible sound and LCD display. Optionally, an unsolicited message can be sent to the PC detailing the exception.

Current programming environments do not support these new capabilities. A new IDE is required and one has been written that is currently in Alpha testing.

Enhanced infrared messaging support

New firmware allows infrared messaging to be optionally configured to operate over four times faster than the standard Lego supplied firmware. This has value in two applications: [1] faster IR communication in multi-RCX applications and [2] faster communication between RCX and PC development environments.

• The standard Lego firmware uses a fixed 2,400-baud infrared messaging. Every message data byte is also followed with a complement byte. Standard firmware allows modification of transmit parameters for a one-time user program generated message. In addition to this functionality, new firmware allows complete customization of the IR messaging parameters (2,400 or 4,800 baud; enable/disable complement byte) for both transmit and receive directions for normal operation.
• There are many fast firmware downloading programs that operate at quad speed (4,800 baud and no complement bytes). However, end user byte code programs are always downloaded at the slower standard rate. The expanded infrared messaging in the new firmware enables programming environments to provide quad speed downloading of end user programs.
• Standard Lego firmware prefixes every message with a three byte (0x55, 0xFF, 0x00) preamble. The preamble has minimal benefit; if a corrupted value of one of the preamble bytes is received, then the complete message will be incorrectly received. The new firmware allows customization of the preamble size from zero to three bytes. RCX message reception is flexible and will always accommodate any size preamble.
• A quirk in the standard Lego firmware appears to require a 30-millisecond delay between transmission of last byte of a reply message from the RCX and reception of the first byte of a new message. The new firmware does not emulate this quirk!

On RCX power up, the messaging is always reset to the “standard” 2,400-baud values.

The new IDE currently in Alpha testing takes full advantage of the enhanced IR messaging. Features include:

• RCX is configured to use quad speed communication with the PC enabling faster download of user programs.
• An incremental downloading function where only the tasks and subroutines that have changed since the last download are retransmitted to the RCX.
• Quad speed and bulk variable upload are used to provide rapid update of PC debugging windows.

Note: The Lego remote control only operates at the slow 2,400-baud speed. It is incompatible with the optional ability to configure RCX to operate at faster IR rates.

Fine motor control

Three new enhancements to the motor control.

• Up to 128 power levels.
• Programmable delay period when switching direction. Motor is ‘braked’ during the delay. Standard firmware inserts a fixed 100-millisecond delay.
• Option to replace un-powered PWM cycles with ‘brake’ instead of ‘float’ for finer control over motor power and speed.

Standard Lego firmware provides eight levels of motor power levels. New firmware provides support for 128 levels of control. New opcodes and intrinsic variables are provided to provide full access to this expanded range. User programs can use either format at the power level is internally stored in the 128 level format and conversion to 8 level is provided when accessing this format.

Standard Lego firmware provides a 100-millisecond delay when changing powered motor direction to “prevent wear and tear on the motor gears”. The implementation appears to have a few software errors, as it doesn’t appear to always work. New firmware provides a clean implementation. The actual delay period is customizable from 0 to 255 milliseconds; a new intrinsic variable provides control over the interval.

There is a complicated relationship between power level and motor speed related to the actual load on the motor. It is not a linear relationship! Normally, the PWM (Pulse Wave Modulation) algorithm used to control motor provides periods of ‘power’ and ‘float’ to the motor; at higher power levels, there are more frequent ‘power’ intervals. A technique borrowed from Steve Hassenplug’s Legway is to replace the ‘float’ periods with ‘brake’. This provides a more linear relationship power level and speed; however, the motors become very noisy (grinding gears?). New firmware provides a new intrinsic variable for use of ‘brake’ for users who want to explore this functionality and perhaps wear out their motors faster.

Memory stacks for each task

New firmware implements a stack for each task. The stack is used to store subroutine return addresses and (future) local procedure variables and parameters. This functionality enables nested subroutine calls.

A new intrinsic variable allows customization of the size of task stack. The task stack is allocated when a task is first run. The stack remains allocated until the task is deleted.

It would be a relatively easy extension in the future to provide storage for procedure variables on the task. This would eliminate restrictions on running out of variables.

Nested subroutine calls

Standard Lego firmware supports only one level of subroutine call. New firmware supports nested subroutine calls. The number of nested subroutines is limited by the size of the allocated task stack; four bytes are used for each call. Default task size is four bytes.

Native support for function return values

New firmware includes a new intrinsic variable to store function return values. Usage of this feature will require changes to existing programming environments.

Expanded sound features

RobotC firmware provides expanded sound features.

• Standard firmware provides no way to determine how many sound items are currently queued. If the queue is full, new sound items are simply discarded. The enhanced firmware provides a new intrinsic variable to interrogate the size of the queue. It’s now easy to implement a wait loop until there is space in queue before a call to PlayTone or PlaySound.
• Standard firmware plays tones with a square wave using a 50/50 on/off duty cycle. New firmware provides end user control of the duty cycle with 16 steps. This provides a primitive volume control. Unfortunately the mechanical characteristics of the speaker are such that the results are not linear and do not provide a consistent volume control.

Tunable Operating System Parameters

New firmware provides several new intrinsic variables to tune the performance of the operating system. These include parameters like:

• Time slice size. The time slice size defines the number of byte code opcodes that are executed before switching to a different task.
• Sensor refresh rate can be specified in one-millisecond increments with a value range of 1 to 255. A value of zero is a special case indicating a 0.5 millisecond scan rate. Sensor refresh in the standard firmware is fixed at a three-millisecond scan rate.
• LCD refresh interval can be specified in 100 millisecond increments. Refreshing the RCX’s LCD takes about two milliseconds of CPU time. For real time critical user applications the refresh rate can be set to zero which will disable refresh when any task is running
• No power down when powered by AC adaptor. The RCX 1.0 includes a AC adaptor jack. When this Boolean variable is set, firmware will not power off the RCX if the voltage level is above 9.8 volts.
• Several parameters to control the default IR messaging.
• Programmable transition delay period when switching powered motor direction.
• Size of task stack allowing nested subroutine calls.
• Control over sound “volume”.
• A few new formats of the LCD watch display. Current firmware format is HH:MM. New formats include MM:SS and M:SS.S
• Use ‘brake’ instead of ‘float’ during non-powered PWM pulses.
• Expand from 8 to 40 subroutines.
• Interrogate the immediate unfiltered battery level. Current firmware provides a battery level that is an average of 32 recent voltage samples.

Exception Support

Enhanced firmware provides support for over 25 different exceptions. When an exception occurs, the byte code interpreter is suspended and a special display is posted to the RCX LCD.

Optionally the RCX can be configured to generate an autonomous exception report message that can be received by a PC-based IDE. When the new IDE is in debug mode it is continuously scanning for these exception messages and will pop up a window display the exception details.

Some of the different exceptions include:

• Range check on array bounds.
• Task stack overflow / underflow.
• User program generated ASSERT failure.
• Invalid opcodes.
• Range checking on intrinsic variable parameters.
• Invalid program counter value (on branch or subroutine return)
• Attempting to write a read only intrinsic variable
• ‘long’ or ‘float’ not supported in current firmware version.

Messages expanded to 16-bits

Standard firmware only supports 8-bit message. The enhanced firmware has opcodes to support both 8-bit and 16-bit messages. 16-bit messages are useful in multi-RCX applications where 8-bit messages have inadequate bandwidth.

Why do we need firmware updates?

As firmware carries out the integral functions of hardware, firmware updates bring some alterations in the program, which are necessary to enable the corresponding devices to operate proficiently as well as to fix the bugs for better security. To update a device’s firmware, the device user just needs to install the update that is developed for his particular device.

Some of the upsides of updating to the most recent firmware are:

1. A firmware update will upgrade your device with advanced operational instructions without needing any upgradation in the hardware.
2. By updating the firmware, you will be able to explore new features that are added to the device and also have an enhanced user experience while interacting with the device.
3. A firmware update will optimize the performance of firmware or device driver, enhancing the performance of the processor.
4. It will have a significant impact on the improvement of instruction times, out of order execution, branch prediction, and speculative execution time.
5. A few issues may have developed in the system over time due to software updates; these issues can be handled with driver updates by providing service fixes.
6. Users can prevent their gears from becoming obsolete by adopting the additional functionalities and capabilities that come with the firmware update.
7. Optimizing device drivers will also help you quickly decode algorithms and thus utilize the hardware to an optimum level.
8. The logic operation of most of the appliances we use resides in EPROM (Electronically Programmable Read Only Memory), which can be easily upgraded in case of firmware update.
9. Regular firmware updates will reduce the need for expensive repairs or bug fixes.
10. After updating the microcode, all the device peripherals will work better together, eliminating the delays, and thus enhancing the overall performance.

Things to keep in mind before applying a firmware update

Before updating the firmware, you need to make sure that the update is for the exact device model that you own. If you apply an update that is intended for a similar-but-different model, your device would be at a serious risk of becoming non-operational. In such cases, the old microcode will be overwritten with the new programs that are incompatible with your device model, so installing such update will brick your device.

Updating Firmware

Firmware updates are available from the hardware manufacturers. For instance, a firmware update for a network router may be released to fix bugs, security holes or enhance its capabilities.

Some firmware updates are applied normally and just seem like a regular software update. However, others can be quite time-consuming as they might involve copying the firmware to a portable drive and then loading it onto the device manually. That said, some devices, feature a dedicated section in the administrative console that lets you apply a firmware update or a user manual for a complete reference.

It’s extremely important to make sure the device that’s receiving the firmware update does not shut down while the update is being applied. A partial firmware update leaves the firmware corrupted, which can seriously damage how the device works. So, just make sure that once you start a firmware updater, you let the update finish.

IN CONCLUSION

Digital services are undergoing frequent changes because the process of progress is a never-ending one. New products are introduced to the market and are packed with newer technologies and better functionalities. By merely updating the firmware, your existing devices will become capable enough to compete with the newer products, giving you the latest functionalities on the same hardware.