Gary Stringham

December 31, 2008

Responses to Level-triggered vs. Edge-triggered Interrupts

In the last article, I stated “I see no benefit to level-triggered interrupts. … If you believe otherwise, let me know…” and you did. First, a clarification: Your responses let me know that my use of the term “interrupt module” was the source of some confusion about last month’s article. […]
November 29, 2008

Level-triggered vs. Edge-triggered Interrupts

Inside each block in a chip is an interrupt module that monitors signals from multiple interrupt sources within the block. These interrupt sources can be from state machines, counters, combinatorial logic, external signals, or other such sources. When an interrupt source asserts, it triggers the interrupt module to latch the […]
October 31, 2008

Deactivating Optional I/O Signals

Many blocks have input and output signals connected to pins or other blocks on the chip. As needed, associated firmware will control or read the levels of those I/O signals either directly or indirectly. Some of those I/O signals are optional and whether or not they’re used in a given […]
September 30, 2008

Organizational Barriers

In one of the chapters for my forthcoming best practices book, I discuss the importance of informal collaboration between hardware and firmware engineers. When an engineer on one team has a problem, there should be very little, if any, organizational barriers to prevent going directly to a member of the […]
August 30, 2008

More on Resets

Since the last issue, I had an interesting email discussion regarding resets with one of my readers, Jay Dowling. Jay comes from a background of designing safety-critical devices for use in harsh environments and has a different perspective on resets. During our discussion, Jay brought up a useful distinction between […]
July 31, 2008

Levels of Reset

A few years ago in my search for hardware/firmware best practices, I came across a series of “Firmware Friendly” articles written by David Fechser of LSI Logic. (See Related Links on my website.) In one of his articles, “Firmware-friendly reset design,” Fechser discusses three levels of hardware reset. The following […]
June 30, 2008

Accurate Register Specifications

We have all dealt with the pain of inaccurate and out-of-date register information. Registers and bits are modified in hardware but the documents are not updated. Documents are updated but firmware is not changed. Or typos are introduced along the way. Failure to catch these problems typically results in hours […]
May 31, 2008

Sniffing I2C

While adding an I2C communication bus to an embedded power supply for a client, I recently reviewed the datasheet for an I2C bus switch, a PCA9546A by NXP. This particular switch allows one or more downstream I2C buses to be switched into one upstream I2C bus. The PCA9546A switch is […]
March 31, 2008

More on Documenting Registers

Last month’s newsletter discussed some best practices for documenting register layouts, illustrating key points with a sample register diagram. One reader, Joel Saks, noted that my register diagram did not clearly indicate whether the bits were read/write bits or read-only bits. Joel makes an excellent point and also exposes one […]
February 28, 2008

Documenting Registers

Much of firmware development focuses on interfacing with registers. Documentation plays a key role in this effort since engineers must refer to it constantly to look up register and bit details. In particular, engineers need to generate or decode hex numbers, where the value of each bit must be clearly […]