CC 25th Anniversary Issue: The Past, Present, and Future of Embedded Design

In celebration of Circuit Cellar’s 25th year of publishing electrical engineering articles, we’ll release a special edition magazine around the start of 2013. The issue’s theme will be the past, present, and future of embedded electronics. World-renowned engineers, innovators, academics, and corporate leaders will provide essays, interviews, and projects on embedded design-related topics such as mixed-signal designs, the future of 8-bit chips, rapid prototyping, FPGAs, graphical user interfaces, embedded security, and much more.

Here are some of the essay topics that will appear in the issue:

  • The history of Circuit Cellar — Steve Ciarcia (Founder, Circuit Cellar, Engineer)
  • Do small-RAM devices have a future? — by John Regehr (Professor, University of Utah)
  • A review of embedded security risks — by Patrick Schaumont (Professor, Virginia Tech)
  • The DIY electronics revolution — by Limor Fried (Founder, Adafruit Industries)
  • The future of rapid prototyping — by Simon Ford (ARM mbed, Engineer)
  • Robust design — by George Novacek (Engineer, Retired Aerospace Executive)
  • Twenty-five essential embedded system design principles — by Bob Japenga (Embedded Systems Engineer, Co-Founder, Microtools Inc.)
  • Mixed-signal designs: the 25 errors you’ll make at least once — by Robert Lacoste (Founder, Alciom; Engineer)
  • User interface tips for embedded designers — by Curt Twillinger (Engineer)
  • Thinking in terms of hardware platforms, not chips — by Clemens Valens (Engineer, Elektor)
  • The future of FPGAs — by Colin O’Flynn (Engineer)
  • The future of e-learning for engineers and programmers — by Marty Hauff (e-Learning Specialist, Altium)
  • And more!

Interviews

We’ll feature interviews with embedded industry leaders and forward-thinking embedded design engineers and programmers such as:

More Content

In addition to the essays and interviews listed above, the issue will also include:

  • PROJECTS will be available via QR codes
  • INFOGRAPHICS depicting tech-related likes, dislikes, and ideas of hundreds of engineers.
  • And a few surprises!

Who Gets It?

All Circuit Cellar subscribers will receive the 25th Anniversary issue. Additionally, the magazine will be available online and promoted by Circuit Cellar’s parent company, Elektor International Media.

Get Involved

Want to get involved? Sponsorship and advertising opportunities are still available. Find out more by contacting Peter Wostrel at Strategic Media Marketing at 978-281-7708 (ext. 100) or peter@smmarketing.us. Inquire about editorial opportunities by contacting the editorial department.

About Circuit Cellar

Steve Ciarcia launched Circuit Cellar magazine in 1988. From its beginning as “Ciarcia’s Circuit Cellar,” a popular, long-running column in BYTE magazine, Ciarcia leveraged his engineering knowledge and passion for writing about it by launching his own publication. Since then, tens of thousands of readers around the world have come to regard Circuit Cellar as the #1 source for need-to-know information about embedded electronics, design, and programming.

Debugging USB Firmware

You’ve written firmware for your USB device and are ready to test it. You attach the device to a PC and the hardware wizard announces: “The device didn’t start.” Or, the device installs but doesn’t send or receive data. Or, data is being dropped, the throughput is low, or some other problem presents itself. What do you do?

This article explores tools and techniques to debug the USB devices you design. The focus is on USB 2.0 devices, but much of the information also applies to developing USB 3.0 (SuperSpeed) devices and USB hosts for embedded systems.

VIEWING BUS TRAFFIC

If you do anything beyond a small amount of USB developing, a USB protocol analyzer will save you time and trouble. Analyzers cost less than they used to and are well worth the investment.

A hardware-based analyzer connects in a cable segment upstream from the device under test (see Photo 1).

Photo 1: The device under test connects to the analyzer, which
captures the data and passes it unchanged to the device’s host. The
cable on the back of the analyzer carries the captured data to the
analyzer’s host PC for display.

You can view the data down to each packet’s individual bytes and see exactly what the host and device did and didn’t send (see Photo 2).

Photo 2: This bus capture shows the host’s request for a configuration
descriptor and the bytes the device sent in response. Because the endpoint’s
maximum packet size is eight, the device sends the first 8 bytes in one
transaction and the final byte in a second transaction.

An analyzer can also decode data to show standard USB requests and class-specific data (see Photo 3).

Photo 3: This display decodes a received configuration descriptor and its subordinate descriptors.

To avoid corrupted data caused by the electrical effects of the analyzer’s connectors and circuits, use short cables (e.g., 3’ or less) to connect the analyzer to the device under test.

Software-only protocol analyzers, which run entirely on the device’s host PC, can also be useful. But, this kind of analyzer only shows data at the host-driver level, not the complete packets on the bus.

DEVELOPMENT STRATEGIES

The first rule for developing USB device firmware is to remember that the host computer controls the bus. Devices just need to respond to received data and events. Device firmware shouldn’t make assumptions about what the host will do next.

For example, some flash drives work under Windows but break when attached to a host with an OS that sends different USB requests or mass-storage commands, sends commands in a different order, or detects errors Windows ignores. This problem is so common that Linux has a file, unusual_devs.h, with fixes for dozens of misbehaving drives.

The first line of defense in writing USB firmware is the free USB-IF Test Suite from the USB Implementers Forum (USB-IF), the trade group that publishes the USB specifications. During testing, the suite replaces the host’s USB driver with a special test driver. The suite’s USB Command Verifier tool checks for errors (e.g., malformed descriptors, invalid responses to standard USB requests, responses to Suspend and Resume signaling, etc.). The suite also provides tests for devices in some USB classes, such as human interface devices (HID), mass storage, and video.

Running the tests will usually reveal issues that need attention. Passing the tests is a requirement for the right to display the USB-IF’s Certified USB logo.

LAYERED COMMUNICATIONS

Like networks, USB communications have layers that isolate different logical functions (see Table 1).

Table 1: USB communications use layers, which are each responsible for a
specific logical function.

The USB protocol layer manages USB transactions, which carry data packets to and from device endpoints. A device endpoint is a buffer that is a source or sink of data at the device. The host sends data to Out endpoints and receives data from In endpoints. (Even though endpoints are on devices, In and Out are defined from the host’s perspective.)

The device layer manages USB transfers, with each transfer moving a chunk of data consisting of one or more transactions. To meet the needs of different peripherals, the USB 2.0 specification defines four transfer types: control, interrupt, bulk, and isochronous.

The function layer manages protocols specific to a device’s function (e.g., mouse, printer, or drive). The function protocols may be a combination of USB class, industry, and vendor-defined protocols.

CONTROLLER ARCHITECTURES

The layers supported by device firmware vary with the device hardware. At one end of the spectrum, a Future Technology Devices International (FTDI) FT232R USB UART controller handles all the USB protocols in hardware. The chip has a USB device port that connects to a host computer and a UART port that connects to an asynchronous serial port on the device.

Device firmware reads and writes data on the serial port, and the FT232R converts it between the USB and UART protocols. The device firmware doesn’t have to know anything about USB. This feature has made the FT232R and similar chips popular!

An example of a chip that is more flexible but requires more firmware support is Microchip Technology’s PIC18F4550 microcontroller, which has an on-chip, full-speed USB device controller. In return for greater firmware complexity, the PIC18F4550 isn’t limited to a particular host driver and can support any USB class or function.

Each of the PIC18F4550’s USB endpoints has a series of registers—called a buffer descriptor table (BDT)—that store the endpoint buffer’s address, the number of bytes to send or receive, and the endpoint’s status. One of the BDT’s status bits determines the BDT’s ownership. When the CPU owns the BDT, firmware can write to the registers to prepare to send data or to retrieve received data. When the USB module owns the BDT, the endpoint can send or receive data on the bus.

To send a data packet from an In endpoint, firmware stores the bytes’ starting address to send and the number of bytes and sets a register bit to transfer ownership of the BDT to the USB module. The USB module sends the data in response to a received In token packet on the endpoint and returns BDT ownership to the CPU so firmware can set up the endpoint to send another packet.

To receive a packet on an Out endpoint, firmware stores the buffer’s starting address for received bytes and the maximum number of bytes to receive and transfers ownership of the BDT to the USB module. When data arrives, the USB module returns BDT ownership to the CPU so firmware can retrieve the data and transfer ownership of the BDT back to the USB module to enable the receipt of another packet.

Other USB controllers have different architectures and different ways of managing USB communications. Consult your controller chip’s datasheet and programming guide for details. Example code from the chip vendor or other sources can be helpful.

DEBUGGING TRANSACTIONS

A USB 2.0 transaction consists of a token packet and, as needed, a data packet and a handshake packet. The token packet identifies the packet’s type (e.g., In or Out), the destination device and endpoint, and the data packet direction.

The data packet, when present, contains data sent by the host or device. The handshake packet, when present, indicates the transaction’s success or failure.

The data and handshake packets must transmit quickly after the previous packet, with only a brief inter-packet delay and bus turnaround time, if needed. Thus, device hardware typically manages the receiving and sending of packets within a transaction.

For example, if an endpoint’s buffer has room to accept a data packet, the endpoint stores the received data and returns ACK in the handshake packet. Device firmware can then retrieve the data from the buffer. If the buffer is full because firmware didn’t retrieve previously received data, the endpoint returns NAK, requiring the host to try again. In a similar way, an In endpoint will NAK transactions until firmware has loaded the endpoint’s buffer with data to send.

Fine tuning the firmware to quickly write and retrieve data can improve data throughput by reducing or eliminating NAKs. Some device controllers support ping-pong buffers that enable an endpoint to store multiple packets, alternating between the buffers, as needed.

LOST DATA

In all but isochronous transfers, a data-toggle value in the data packet’s packet identification (PID) field guards against missed or duplicate data packets. If you’re debugging a device where data is transmitting on the bus and the receiver is returning ACK but ignoring or discarding the data, chances are good that the device isn’t sending or expecting the correct data-toggle value. Some device controllers handle the data toggles completely in hardware, while others require some firmware control.

Each endpoint maintains its own data toggle. The values are DATA0 (0011B) and DATA1 (1011B). Upon detecting an incoming data packet, the receiver compares its data toggle’s state with the received data toggle. If the values match, the receiver toggles its value and returns ACK, causing the sender to toggle its value for the next transaction.

The next received packet should contain the opposite data toggle, and again the receiver toggles its bit and returns ACK. Except for control transfers, the data toggle on each end continues to alternate in each transaction. (Control transfers always use DATA0 in the Setup stage, toggle the value for each transaction in the Data stage, and use DATA1 in the Status stage.)

If the receiver returns NAK or no response, the sender doesn’t toggle its bit and tries again with the same data and data toggle. If a receiver returns ACK, but for some reason the sender doesn’t see the ACK, the sender thinks the receiver didn’t receive the data and tries again using the same data and data toggle. In this case, the repeated data receiver ignores the data, doesn’t toggle the data toggle, and returns ACK, resynchronizing the data toggles. If the sender mistakenly sends two packets in a row with the same data-toggle value, upon receiving the second packet, the receiver ignores the data, doesn’t toggle its value, and returns ACK.

DEFINING A TRANSFER

All USB devices must support control transfers and may support other transfer types. Control transfers provide a structure for sending requests but have no guaranteed delivery time. Interrupt transfers have a guaranteed maximum latency (i.e., delay) between transactions, but the host permits less bandwidth for interrupt transfers compared to other transfer types. Bulk transfers are the fastest on an otherwise idle bus, but they have no guaranteed delivery time, and thus can be slow on a busy bus. Isochronous transfers have guaranteed delivery time but no built-in error correction.

A transfer’s amount of data depends in part on the higher-level protocol that determines the data packets’ contents. For example, a keyboard sends keystroke data in an interrupt transfer that consists of one transaction with 8 data bytes. To send a large file to a drive, the host typically uses one or more large transfers consisting of multiple transactions. For a high-speed drive, each transaction, except possibly the last one, has 512 data bytes, which is the maximum-allowed packet size for high-speed bulk endpoints.

What determines a transfer’s end varies with the USB class or vendor protocol. In many cases, a transfer ends with a short packet, which is a packet that contains less than the packet’s maximum-allowed data bytes. If the transfer has an even multiple of the packet’s maximum-allowed bytes, the sender may indicate the end of the transfer with a zero-length packet (ZLP), which is a data packet with a PID and error-checking bits but no data.

For example, USB virtual serial-port devices in the USB communications device class use short packets to indicate the transfer’s end. If a device has sent data that is an exact multiple of the endpoint’s maximum packet size and the host sends another In token packet, the endpoint should return a ZLP to indicate the data’s end.

DEBUGGING ENUMERATION

Upon device attachment, in a process called enumeration, the host learns about the device by requesting a series of data structures called descriptors. The host uses the descriptors’ information to assign a driver to the device.

If enumeration doesn’t complete, the device doesn’t have an assigned driver, and it can’t perform its function with the host. When Windows fails to find an appropriate driver, the setupapi.dev.log file in Windowsinf (for Windows 7) can offer clues about what went wrong. A protocol analyzer shows if the device returned all requested descriptors and reveals mistakes in the descriptors.

During device development, you may need to change the descriptors (e.g., add, remove, or edit an endpoint descriptor). Windows has the bad habit of remembering a device’s previous descriptors on the assumption that a device will never change its descriptors. To force Windows to use new descriptors, uninstall then physically remove and reattach the device from Windows Device Manager. Another option is to change the device descriptor’s product ID to make the device appear as a different device.

DEBUGGING TRANSFERS

Unlike the other transfer types, control transfers have multiple stages: setup, (optional) data, and status. Devices must accept all error-free data packets that follow a Setup token packet and return ACK. If the device is in the middle of another control transfer and the host sends a new Setup packet, the device must abandon the first transfer and begin the new one. The data packet in the Setup stage contains important information firmware should completely decode (see Table 2).

Table 2: Device firmware should fully decode the data received in a control transfer’s Setup stage. (Source: USB Implementers Forum, Inc.)

The wLength field specifies how many bytes the host wants to receive. A device shouldn’t assume how much data the host wants but should check wLength and send no more than the requested number of bytes.

For example, a request for a configuration descriptor is actually a request for the configuration descriptor and all of its subordinate descriptors. But, in the first request for a device’s configuration descriptor, the host typically sets the wLength field to 9 to request only the configuration descriptor. The descriptor contains a wTotalLength value that holds the number of bytes in the configuration descriptor and its subordinate descriptors. The host then resends the request setting wLength to wTotalLength or a larger value (e.g., FFh). The device returns the requested descriptor set up to wTotalLength. (Don’t assume the host will do it this way. Always check wLength!)

Each Setup packet also has a bmRequestType field. This field specifies the data transfer direction (if any), whether the recipient is the device or an interface or endpoint, and whether the request is a standard USB request, a USB class request, or a vendor-defined request. Firmware should completely decode this field to correctly identify received requests.

A composite device has multiple interfaces that function independently. For example, a printer might have a printer interface, a mass-storage interface for storing files, and a vendor-specific interface to support vendor-defined capabilities. For requests targeted to an interface, the wIndex field typically specifies which interface applies to the request.

INTERRUPT TRANSFER TIMING

For interrupt endpoints, the endpoint descriptor contains a bInterval value that specifies the endpoint’s maximum latency. This value is the longest delay a host should use between transaction attempts.

A host can use the bInterval delay time or a shorter period. For example, if a full-speed In endpoint has a bInterval value of 10, the host can poll the endpoint every 1 to 10 ms. Host controllers typically use predictable values, but a design shouldn’t rely on transactions occurring more frequently than the bInterval value.

Also, the host controller reserves bandwidth for interrupt endpoints, but the host can’t send data until a class or vendor driver provides something to send. When an application requests data to be sent or received, the transfer’s first transaction may be delayed due to passing the request to the driver and scheduling the transfer.

Once the host controller has scheduled the transfer, any additional transaction attempts within the transfer should occur on time, as defined by the endpoint’s maximum latency. For this reason, sending a large data block in a single transfer with multiple transactions can be more efficient than using multiple transfers with a portion of the data in each transfer.

DEVICE FUNCTIONS

Most devices’ functions fit a defined USB class (e.g., mass storage, printer, audio, etc.). The USB-IF’s class specifications define protocols for devices in the classes.

For example, devices in the HID class must send and receive all data in data structures called reports. The supported report’s length and the meaning of its data (e.g., keypresses, mouse movements, etc.) are defined in a class-specific report descriptor.

If your HID-class device is sending data but the host application isn’t seeing the data, verify the number of bytes the device is sending matches the number of bytes in a defined report. The device should prepend a report-ID byte to the data only if the HID supports report IDs other than the zero default value.

In many devices, class specifications define class-specific requests or other requirements. For example, a mass storage device that uses the bulk-only protocol must provide a unique serial number in a string descriptor. Carefully read and heed any class specifications that apply to your device!

Many devices also support industry protocols to perform higher-level functions. Printers typically support one or more printer-control languages (e.g., PCL and Postscript). Mass-storage devices support SCSI commands to transfer data blocks and a file system (e.g., FAT32) to define a directory structure.

The higher-level industry protocols don’t depend on a particular hardware interface, so there is little about debugging them that is USB-specific. But, because these protocols can be complicated, example code for your device can be helpful.

In the end, much about debugging USB firmware is like debugging any hardware or software. A good understanding of how the communications should work provides a head start on writing good firmware and finding the source of any problems that may appear.

Jan Axelson is the author of USB Embedded Hosts, USB Complete, and Serial Port Complete. Jan’s PORTS web forum is available at www.lvr.com.

RESOURCES

Jan Axelson’s Lakeview Research, “USB Development Tools: Protocol analyzers,” www.lvr.com/development_tools.htm#analyzers.

This article appears in Circuit Cellar 268 (November 2012).

CC268: The History of Embedded Tech

At the end of September 2012, an enthusiastic crew of electrical engineers and journalists (and significant others) traveled to Portsmouth, NH, from locations as far apart as San Luis Obispo, CA,  and Paris, France, to celebrate Circuit Cellar’s 25th anniversary. Attendees included Don Akkermans (Director, Elektor International Media), Steve Ciarcia (Founder, Circuit Cellar), the current magazine staff, and several well-known engineers, editors, and columnists. The event marked the beginning of the next chapter in the history of this long-revered publication. As you’d expect, contributors and staffers both reminisced about the past and shared ideas about its future. And in many instances, the conversations turned to the content in this issue, which was at that time entering the final phase of production. Why? We purposely designed this issue (and next month’s) to feature a diversity of content that would represent the breadth of coverage we’ve come to deliver during the past quarter century. A quick look at this issue’s topics gives you an idea of how far embedded technology has come. The topics also point to the fact that some of the most popular ’80s-era engineering concerns are as relevant as ever. Let’s review.

In the earliest issues of Circuit Cellar, home control was one of the hottest topics. Today, inventive DIY home control projects are highly coveted by professional engineers and newbies alike. On page 16, Scott Weber presents an interesting GPS-based time server for lighting control applications. An MCU extracts time from GPS data and transmits it to networked devices.

The time-broadcasting device includes a circuit board that’s attached to a GPS module. (Source: S. Weber, CC268)

Thiadmer Riemersma’s DIY automated component dispenser is a contemporary solution to a problem that has frustrated engineers for decades (p. 26). The MCU-based design simplifies component management and will be a welcome addition to any workbench.

The DIY automated component dispenser. (Source: T. Riemersma, CC268)

USB technology started becoming relevant in the mid-to-late 1990s, and since then has become the go-to connection option for designers and end users alike. Turn to page 30 for Jan Axelson’s  tips about debugging USB firmware. Axelson covers controller architectures and details devices such as the FTDI FT232R USB UART controller and Microchip Technology’s PIC18F4550 microcontroller.

Debugging USB firmware (Source: J. Axelson, CC268)

Electrical engineers have been trying to “control time” in various ways since the earliest innovators began studying and experimenting with electric charge. Contemporary timing control systems are implemented in a amazing ways. For instance, Richard Lord built a digital camera controller that enables him to photograph the movement of high-speed objects (p. 36).

Security and product reliability are topics that have been on the minds of engineers for decades. Whether you’re working on aerospace electronics or a compact embedded system for your workbench (p. 52), you’ll want to ensure your data is protected and that you’ve gone through the necessary steps to predict your project’s likely reliability (p. 60).

The issue’s last two articles detail how to use contemporary electronics to improve older mechanical systems. On page 64 George Martin presents a tachometer design you can implement immediately in a machine shop. And lastly, on page 70, Jeff Bachiochi wraps up his series “Mechanical Gyroscope Replacement.” The goal is to transmit reliable data to motor controllers. The photo below shows the Pololu MinIMU-9.

The Pololu MinIMU-9′s sensor axes are aligned with the mechanical gyro so the x and y output pitch and roll, respectively. (Source: J. Bachiochi, CC268)

Autonomous Mobile Robot (Part 1): Overview & Hardware

Welcome to “Robot Boot Camp.” In this two-part article series, I’ll explain what you can do with a basic mobile machine, a few sensors, and behavioral programming techniques. Behavioral programming provides distinct advantages over other programming techniques. It is independent of any environmental model, and it is more robust in the face of sensor error, and the behaviors can be stacked and run concurrently.

My objectives for my recent robot design were fairly modest. I wanted to build a robot that could cruise on its own, avoid obstacles, escape from inadvertent collisions, and track a light source. I knew that if I could meet such objective other more complex behaviors would be possible (e.g., self-docking on low power). There certainly many commercial robots on the market that could have met my requirements. But I decided that my best bet would be to roll my own. I wanted to keep things simple, and I wanted to fully understand the sensors and controls for behavioral autonomous operation. The TOMBOT is the fruit of that labor (see Photo 1a). A colleague came up with the name TOMBOT in honor of its inventor, and the name kind of stuck.

Photo 1a—The complete TOMBOT design. b—The graphics display is nice feature.

In this series of articles, I’ll present lessons learned and describe the hardware/software design process. The series will detail TOMBOT-style robot hardware and assembly, as well as behavior programming techniques using C code. By the end of the series, I’ll have covered a complete behavior programming library and API, which will be available for experimentation.

DESIGN BASICS

The TOMBOT robot is certainly minimal, no frills: two continuous-rotation, variable-speed control servos; two IR (850 nm) analog distance measurement sensors (4- to 30-cm range); two CdS photoconductive cells with good lux response in visible spectrum; and, finally, a front bumper (switch-activated) for collision detection. The platform is simple: servos and sensors on the left and right side of two level platforms. The bottom platform houses bumper, batteries, and servos. The top platform houses sensors and microcontroller electronics. The back part of the bottom platform uses a central skid for balance between the two servos (see Photo 1).

Given my background as a Microchip Developer and Academic Partner, I used a Microchip Technology PIC32 microcontroller, a PICkit 3 programmer/debugger, and a free Microchip IDE and 32-bit complier for TOMBOT. (Refer to the TOMBOT components list at the end of this article.)

It was a real thrill to design and build a minimal capability robot that can—with stacking programming behaviors—emulate some “intelligence.” TOMBOT is still a work in progress, but I recently had the privilege of demoing it to a first grade class in El Segundo, CA, as part of a Science Technology Engineering and Mathematics (STEM) initiative. The results were very rewarding, but more on that later.

BEHAVIORAL PROGRAMMING

A control system for a completely autonomous mobile robot must perform many complex information-processing tasks in real time, even for simple applications. The traditional method to building control systems for such robots is to separate the problem into a series of sequential functional components. An alternative approach is to use behavioral programming. The technique was introduced by Rodney Brooks out of the MIT Robotics Lab, and it has been very successful in the implementation of a lot of commercial robots, such as the popular Roomba vacuuming. It was even adopted for space applications like NASA’s Mars Rover and military seekers.

Programming a robot according to behavior-based principles makes the program inherently parallel, enabling the robot to attend simultaneously to all hazards it may encounter as well as any serendipitous opportunities that may arise. Each behavior functions independently through sensor registration, perception, and action. In the end, all behavior requests are prioritized and arbitrated before action is taken. By stacking the appropriate behaviors, using arbitrated software techniques, the robot appears to show (broadly speaking) “increasing intelligence.” The TOMBOT modestly achieves this objective using selective compile configurations to emulate a series of robot behaviors (i.e., Cruise, Home, Escape, Avoid, and Low Power). Figure 1 is a simple model illustration of a behavior program.

Figure 1: Behavior program

Joseph Jones’s Robot Programming: A Practical Guide to Behavior-Based Robotics (TAB Electronics, 2003) is a great reference book that helped guide me in this effort. It turns out that Jones was part of the design team for the Roomba product.

Debugging a mobile platform that is executing a series of concurrent behaviors can be daunting task. So, to make things easier, I implemented a complete remote control using a wireless link between the robot and a PC. With this link, I can enable or disable autonomous behavior, retrieve the robot sensor status and mode of operations, and curtail and avoid potential robot hazard. In addition to this, I implemented some additional operator feedback using a small graphics display, LEDs, and a simple sound buzzer. Note the TOMBOT’s power-up display in Photo 1b. We take Robot Boot Camp very seriously.

Minimalist System

As you can see in the robot’s block diagram (see Figure 2), the TOMBOT is very much a minimalist system with just enough components to demonstrate autonomous behaviors: Cruise, Escape, Avoid, and Home. All these behaviors require the use of left and right servos for autonomous maneuverability.

Figure 2: The TOMBOT system

The Cruise behavior just keeps the robot in motion in lieu of any stimulus. The Escape behavior uses the bumper to sense a collision and then 180° spin with reverse. The Avoid behavior makes use of continuous forward-looking IR sensors to veer left or right upon approaching a close obstacle. The Home behavior utilizes the front optical photocells to provide robot self-guidance to a strong light highly directional source. It all should add up to some very distinct “intelligent” operation. Figure 3 depicts the basic sensor and electronic layout.

Figure 3: Basic sensor and electronic layout

TOMBOT Assembly

The TOMBOT uses the low-cost robot platform (ArBot Chassis) and wheel set (X-Wheel assembly) from Budget Robotics (see Figure 4).

Figure 4: The platform and wheel set

A picture is worth a thousand words. Photo 2 shows two views of the TOMBOT prototype.

Photo 2a: The TOMBOT’s Sharp IR sensors, photo assembly, and more. b: The battery pack, right servo, and more.

Photo 2a shows dual Sharp IR sensors. Just below them is the photocell assembly. It is a custom board with dual CdS GL5528 photoconductive cells and 2.2-kΩ current-limiting resistors. Below this is a bumper assembly consisting of two SPDT Snap-action switches with lever (All Electronics Corp. CAT# SMS-196, left and right) fixed to a custom pre-fab plastic front bumper. Also shown is the solderless breakout board and left servo. Photo 2b shows the rechargeable battery pack that resides on the lower base platform and associated power switch. The electronics stack is visible. Here the XBee/Buzzer and graphics card modules residing on the 32-bit Experimenter. The Experimenter is plugged into a custom carrier board that allows for an interconnection to the solderless breakout to the rest of the system. Finally, note that the right servo is highlighted. The total TOMBOT package is not ideal; but remember, I’m talking about a prototype, and this particular configuration has held up nicely in several field demos.

I used Parallax (Futaba) continuous-rotation servos. They use a three-wire connector (+5 V, GND, and Control).

Figure 5 depicts a second-generation bumper assembly.  The same snap-action switches with extended levers are bent and fashioned to interconnect a bumper assembly as shown.

Figure 5: Second-generation bumper assembly

TOMBOT Electronics

A 32-bit Micro Experimenter is used as the CPU. This board is based the high-end Microchip Technology PIC32MX695F512H 64-pin TQFP with 128-KB RAM, 512-KB flash memory, and an 80-MHz clock. I did not want to skimp on this component during the prototype phase. In addition the 32-bit Experimenter supports a 102 × 64 monographic card with green/red backlight controls and LEDs. Since a full graphics library was already bundled with this Experimenter graphics card, it also represented good risk reduction during prototyping phase. Details for both cards are available on the Kiba website.

The Experimenter supports six basic board-level connections to outside world using JP1, JP2, JP3, JP4, BOT, and TOP headers.  A custom carrier board interfaces to the Experimenter via these connections and provides power and signal connection to the sensors and servos. The custom carrier accepts battery voltage and regulates it to +5 VDC. This +5 V is then further regulated by the Experimenter to its native +3.3-VDC operation. The solderless breadboard supports a resistor network to sense a +9-V battery voltage for a +3.3-V PIC processor. The breadboard also contains an LM324 quad op-amp to provide a buffer between +3.3-V logic of the processor and the required +5-V operation of the servo. Figure 6 is a detailed schematic diagram of the electronics.

Figure 6: The design’s circuitry

A custom card for the XBee radio carrier and buzzer was built that plugs into the Experimenter’s TOP and BOT connections. Photo 3 shows the modules and the carrier board. The robot uses a rechargeable 1,600-mAH battery system (typical of mid-range wireless toys) that provides hours of uninterrupted operation.

Photo 3: The modules and the carrier board

PIC32 On-Chip Peripherals

The major PIC32 peripheral connection for the Experimenter to rest of the system is shown. The TOMBOT uses PWM for servo, UART for XBee, SPI and digital for LCD, analog input channels for all the sensors, and digital for the buzzer and bumper detect. The key peripheral connection for the Experimenter to rest of the system is shown in Figure 7.

Figure 7: Peripheral usage

The PIC32 pinouts and their associated Experimenter connections are detailed in Figure 8.

Figure 8: PIC32 peripheral pinouts and EXP32 connectors

The TOMBOT Motion Basics and the PIC32 Output Compare Peripheral

Let’s review the basics for TOMBOT motor control. The servos use the Parallax (Futaba) Continuous Rotation Servos. With two-wheel control, the robot motion is controlled as per Table 1.

Table 1: Robot motion

The servos are controlled by using a 20-ms (500-Hz) pulse PWM pattern where the PWM pulse can from 1.0 ms to 2.0 ms. The effects on the servos for the different PWM are shown in Figure 9.

Figure 9: Servo PWM control

The PIC32 microcontroller (used in the Experimenter) has five Output Compare modules (OCX, where X =1 , 2, 3, 4, 5). We use two of these peripherals, specifically OC3, OC4 to generate the PWM to control the servo speed and direction. The OCX module can use either 16 Timer2 (TMR2) or 16 Timer3 (TMR3) or combined as 32-bit Timer23 as a time base and for period (PR) setting for the output pulse waveform. In our case, we are using Timer23 as a PR set to 20 ms (500 Hz). The OCXRS and OCXR registers are loaded with a 16-bit value to control width of the pulse generated during the output period. This value is compared against the Timer during each period cycle. The OCX output starts high and then when a match occurs OCX logic will generate a low on output. This will be repeated on a cycle-by-cycle basis (see Figure 10).

Figure 10: PWM generation

Next Comes Software

We set the research goals and objectives for our autonomous robot. We covered the hardware associated with this robot and in the next installment we will describe the software and operation.

Tom Kibalo holds a BSEE from City College of New York and an MSEE from the University of Maryland. He as 39 years of engineering experience with a number of companies in the Washington, DC area. Tom is an adjunct EE facility member for local community college, and he is president of Kibacorp, a Microchip Design Partner.

2012 ESC Boston: Tech from Microchip, Fujitsu, & More

The 2012 Embedded Systems Conference in Boston started September 17 and ends today. Here’s a wrap-up of the most interesting news and products.

MICROCHIP TECHNOLOGY

Microchip Technology announced Monday morning the addition of 15 new USB PIC microcontrollers to its line of full-speed USB 2.0 Device PIC MCUs. In a short presentation, Microchip product marketing manager Wayne Freeman introduced the three new 8-bit, crystal-free USB PIC families.

The PIC16F145x family (three devices) features the Microchip’s lowest-cost MCUs. The devices are available in 14- and 20-pin packages, support full-speed USB communication, don’t require external crystals, include PWM with complement generation, and more. They’re suitable for applications requiring USB connectivity and cap sense capabilities.

Microchip’s three PIC18F2x/4xK50 devices (available in 28- and 40/44-pins) enable “easy migration” from legacy PIC18 USB devices. In addition to 1.8- to 5-V operation, they feature a Charge Time Measurement Unit (CTMU) for cap-touch sensing, which makes them handy for data logging systems for tasks such as temperature and humidity measurement.

The nine devices in the PIC18F97J94 family are available in 64-, 80-, and 100-pin packages. Each device includes a 60 × 8 LCD controller and also integrates a real-time clock/calendar (RTCC) with battery back-up. Systems such as hand-held scanners and home automation panels are excellent candidates for these devices.

Several interesting designs were on display at the Microchip booth.

  • The M2M PICtail module was used in an SMS texting system.

This SMS text messaging system was featured at Microchip’s Machine-to-Machine (M2M) station. The M2M PICtail module (located on the bottom left) costs around $200.

  • Microchip featured its PIC MCU iPod Accessory Kit in glucose meter design. It was one of several healthcare-related systems that exhibitors displayed at the conference.

The interface can be an iPhone, iPad, or iPod Touch.

Visit www.microchip.com for more information.

RENESAS

As most of you know, the entry period for the Renesas RL78 Green Energy Challenge ended on August 31 and the judges are now reviewing the entries. Two particular demos on display at the Renesas booth caught my attention.

  • A lemon powering an RL78 L12 MCU:

Lemon power and the RL78

  • An R8C capacitive touch system:

Cap touch technology is on the minds of countless electrical engineers.

Go to www.am.renesas.com.

FREESCALE

I was pleased to see a reprint of Mark Pedley’s recent Circuit Cellar article, “eCompass” (August 2012), on display at Freescale’s booth. The article covers the topics of building and calibrating a tilt‐compensating electronic compass.

A Circuit Cellar reprint for attendees

Two of the more interesting projects were:

  • An Xtrinsic sensor demo:

Xtrinsic and e-compass

  • A Tower-based medical suitcase, which included a variety of boards: MED-BPM (a dev board for blood pressure monitor applications), MED-EKG (an aux board for EKG and heart rate monitoring applications), and more.

Tower System-based medical suitcase

STMicro

I stopped by the STMicro booth for a look at the STM32F3DISCOVERY kit, but I quickly became interested in the Dual Interface EEPROM station. It was the smartphone that caught my attention (again). Like other exhibitors, STMicro had a smartphone-related application on hand.

  • The Dual EEPROMs enable you to access memory via either  wired or RF interfaces. Energy harvesting is the new function STMicro is promoting. According to the documentation, “It also features an energy harvesting and RF status function.”

The Dual Interface EEPROM family has an RF and I2C interface

  • According to STMicro’s website, the DATALOG-M24LR-A PCB (the green board, top left) “features an M24LR64-R Dual Interface EEPROM IC connected to an STM8L101K3 8-bit microcontroller through an I2C bus on one side, and to a 20 mm x 40 mm 13.56 MHz etched RF antenna on the other one side. The STM8L101K3 is also interfaced with an STTS75 temperature sensor and a CR2330 coin cell battery.”

FUJITSU

I’m glad I spend a few moments at the Fujitsu booth. We rarely see Circuit Cellar authors using Fujitsu parts, so I wanted to see if there was something you’d find intriguing. Perhaps the following images will pique your interest in Fujitsu technologies.

The FM3 family, which features the ARM Cortext-M3 core, is worth checking out. FM3 connectivity demonstration

Connectivity demo

Check out Fujitsu’s System Memory site and document ion to see if its memory products and solutions suit your needs. Access speed comparison: FRAM vs. SRAM vs. EEPROM

Access speed comparison

The ESC conference site has details about the other exhibitors that had booths in the exhibition hall.