Specs & Code Matter (EE Tip #136)

No matter how many engineering hours you’ve logged over the years, it’s always a good idea to keep in mind that properly focusing on specs and code can make or break a project. In 2013, Aubrey Kagan—an experienced engineer and long-time Circuit Cellar author—explained this quite well in CC25:

There was a set of BCD thumbwheel switches that I was reading into a micro. In order to reduce the number of input lines required, each 4 bits of a digit was multiplexed with the other digits and selection was made by a transistor enabling the common line of each switch in turn. This was standard industry practice. The problem was that in order to economize, I had used the spare transistors in a Darlington driver IC. Everything worked fine in the lab, but on very hot days the unit would fail in the field with very strange results.

Long story short, the saturation voltage on the Darlington transistor would increase with temperature to above the digital input threshold and the micro would read undefined switch settings and then jump to non-existing code. I learned three things: read and understand all the specifications on a datasheet, things get a lot hotter in a cabinet in the sun than the lab, and you should make sure your code can handle conditions that are not supposed to occur.—Aubrey Kagan, CC25 (2o13)

Want to share an EE tip of your own? Email our editors to share your tips and tricks.

Bit Banging

Shlomo Engelberg, an associate professor in the electronics department of the Jerusalem College of Technology, is well-versed in signal processing. As an instructor and the author of several books, including Digital Signal Processing: An Experimental Approach (Springer, 2008), he is a skilled guide to how to use the UART “protocol” to implement systems that transmit and receive data without a built-in peripheral.

Implementing serial communications using software rather than hardware is called bit-banging, the topic of his article in Circuit Cellar’s June issue.

“There is no better way to understand a protocol than to implement it yourself from scratch,” Engelberg says. “If you write code similar to what I describe in this article, you’ll have a good understanding of how signals are transmitted and received by a UART. Additionally, sometimes relatively powerful microprocessors do not have a built-in UART, and knowing how to implement one in software can save you from needing to add an external UART to your system. It can also reduce your parts count.”

In the excerpt below, he explains some UART fundamentals:

WHAT DOES “UART” MEAN?
UART stands for universal asynchronous receiver/transmitter. The last three words in the acronym are easy enough to understand. “Asynchronous” means that the transmitter and the receiver run on their own clocks. There is no need to run a wire between the transmitter and the receiver to enable them to “share” a clock (as required by certain other protocols). The receiver/transmitter part of the acronym means just what it says: the protocol tells you what signals you need to send from the transmitter and what signals you should expect to acquire at the receiver.

The first term of the acronym, “universal,” is a bit more puzzling. According to Wikipedia, the term “universal” refers to the fact that the data format and the speed of transmission are variable. My feeling has always been that the term “universal” is basically hype; someone probably figured a “universal asynchronous receiver/transmitter” would sell better than a simple “asynchronous receiver/transmitter.”

Figure 1: The waveform output by a microprocessor’s UART is shown. While “at rest,” the UART’s output is in the high state. The transmission begins with a start bit in which the UART’s output is low. The start bit is followed by eight data bits. Finally, there is a stop bit in which the UART’s output is high.

Figure 1: The waveform output by a microprocessor’s UART is shown. While “at rest,” the UART’s output is in the high state. The transmission begins with a start bit in which the UART’s output is low. The start bit is followed by eight data bits. Finally, there is a stop bit in which the UART’s output is high.

TEAMWORK NEEDED
Before you can use a UART to transfer information from device to device, the transmitter and receiver have to agree on a few things. First, they must agree on a transmission speed. They must agree that each transmitted bit will have a certain (fixed) duration, denoted TBIT. A 1/9,600-s duration is a typical choice, related to a commonly used crystal’s clock speed, but there are many other possibilities. Additionally, the transmitter and receiver have to agree about the number of data bits to be transmitted each time, the number of stop bits to be used, and the flow control (if any).

When I speak of the transmitter and receiver “agreeing” about these points, I mean that the people programming the transmitting and receiving systems must agree to use a certain data rate, for example. There is no “chicken and egg” problem here. You do not need to have an operational UART before you can use your UART; you only need a bit of teamwork.

UART TRANSMISSION
Using a UART is considered the simplest way of transmitting information. Figure 1 shows the form the transmissions must always make. The line along which the signal is transmitted is initially “high.” The transmissions begin with a single start bit during which the line is pulled low (as all UART transmissions must). They have eight data bits (neither more nor less) and a single stop bit (and not one and a half or two stop bits) during which the line is once again held high. (Flow control is not used throughout this article.)

Why must this protocol include start and stop bits? The transmitter and the receiver do not share a common clock, so how does the receiver know when a transmission has begun? It knows by realizing that the wire connecting them is held high while a transmission is not taking place, “watching” the wire connecting them, and waiting for the voltage level to transition from high to low, which it does by watching and waiting for a start bit. When the wire leaves its “rest state” and goes low, the receiver knows that a transmission has begun. The stop bit guarantees that the line returns to its “high” level at the end of each transmission.

Transmissions have a start and a stop bit, so the UART knows how to read the two words even if one transmits that data word 11111111 and follows it with 11111111. Because of the start and stop bits, when the UART is “looking at” a line on which a transmission is beginning, it sees an initial low level (the start bit), the high level repeated eight times, a ninth high level (the stop bit), and then the pattern repeats. The start bit’s presence enables the UART to determine what’s happening. If the data word being transmitted were 00000000 followed by 00000000, then the stop bit would save the day.

The type of UART connection I describe in this article only requires three wires. One wire is for transmission, one is for reception, and one connects the two systems’ grounds.

The receiver and transmitter both know that each bit in the transmission takes TBIT seconds. After seeing a voltage drop on the line, the receiver waits for TBIT/2 s and re-examines the line. If it is still low, the receiver assumes it is in the middle of the start bit. It waits TBIT seconds and resamples the line. The value it sees is then used to determine data bit 0’s value. The receiver then samples every TBIT seconds until it has sampled all the data bits and the stop bit.

Engelberg’s full article, which you can find in Circuit Cellar’s June issue, goes on to explain UART connections and how he implemented a simple transmitter and receiver. For the projects outlined in his article, he used the evaluation kit for Analog Devices’s ADuC841.

“The transmitter and the receiver are both fairly simple to write. I enjoyed writing them,” Engelberg says in wrapping up his article. “If you like playing with microprocessors and understanding the protocols with which they work, you will probably enjoy writing a transmitter and receiver too. If you do not have time to write the code yourself but you’d like to examine it, feel free to e-mail me at shlomoe@jct.ac.il. I’ll be happy to e-mail the code to you.”

Client Profile: ImageCraft Creations, Inc.

CorStarter prototyping board

CorStarter prototyping board

2625 Middlefield Road, #685,
Palo Alto, CA 94306

CONTACT: Richard Man,
richard@imagecraft.com
imagecraft.com

EMBEDDED PRODUCTS:ImageCraft Version 8 C compilers with an IDE for Atmel AVR and Cortex M devices are full-featured toolsets backed by strong support.

CorStarter-STM32 is a complete C hardware and software kit for STM32 Cortex-M3 devices. The $99 kit includes a JTAG pod for programming and debugging.

ImageCraft products offer excellent features and support within budget requisitions. ImageCraft compiler toolsets are used by professionals who demand excellent code quality, full features, and diligent support in a timely manner.

The small, fast compilers provide helpful informational messages and include an IDE with an application builder (Atmel AVR) and debugger (Cortex-M), whole-program code compression technology, and MISRA safety checks. ImageCraft offers two editions that cost $249 and $499.

The demo is fully functional for 45 days, so it is easy to test it yourself.

EXCLUSIVE OFFER: For a limited time, ImageCraft is offering Circuit Cellar readers $40 off the Standard and PRO versions of its Atmel AVR and Cortex-M compiler toolsets. To take advantage of this offer, please visit http://imagecraft.com/xyzzy.html.


 

Circuit Cellar prides itself on presenting readers with information about innovative companies, organizations, products, and services relating to embedded technologies. This space is where Circuit Cellar enables clients to present readers useful information, special deals, and more.

Peter Baston Wins the CC Code Challenge (Week 31)

We have a winner of last week’s CC Weekly Code Challenge, sponsored by IAR Systems! We posted a code snippet with an error and challenged the engineering community to find the mistake!

Congratulations to Peter Baston of Flintshire, United Kingdom for winning the CC Weekly Code Challenge for Week 31! Peter will receive a Circuit Cellar 2012 & 2011 Archive CD.

Peter’s correct answer was randomly selected from the pool of responses that correctly identified an error in the code. Peter answered:

Line 35: Should not end with semi-colon

2013_code_challenge_31_answer

You can see the complete list of weekly winners and code challenges here.

What is the CC Weekly Code Challenge?
Each week, Circuit Cellar’s technical editors purposely insert an error in a snippet of code. It could be a semantic error, a syntax error, a design error, a spelling error, or another bug the editors slip in. You are challenged to find the error. Once the submission deadline passes, Circuit Cellar will randomly select one winner from the group of respondents who submit the correct answer.

The CC Weekly Code Challenge ran from June 3rd through December 30th, 2013. Subscribe to our CC.Post newsletter to stay informed of other contests and challenges, as well as recent news, new issue availability, and more!

Gait Boxman Wins the CC Code Challenge (Week 30)

We have a winner of last week’s CC Weekly Code Challenge, sponsored by IAR Systems! We posted a code snippet with an error and challenged the engineering community to find the mistake!

Congratulations to Gait Boxman of Gelderland, Netherlands for winning the CC Weekly Code Challenge for Week 30! Gait will receive an IAR Kickstart: KSK-FM3-48PMC-USB.

Gait’s correct answer was randomly selected from the pool of responses that correctly identified an error in the code. Gait answered:

Line 31: should be digits % 3 instead of digits / 3

2013_code_challenge_30_answer

You can see the complete list of weekly winners and code challenges here.

What is the CC Weekly Code Challenge?
Each week, Circuit Cellar’s technical editors purposely insert an error in a snippet of code. It could be a semantic error, a syntax error, a design error, a spelling error, or another bug the editors slip in. You are challenged to find the error.Once the submission deadline passes, Circuit Cellar will randomly select one winner from the group of respondents who submit the correct answer.

Inspired? Want to try this week’s challenge? Get started!

Submission Deadline: The deadline for each week’s challenge is Sunday, 12 PM EST. Refer to the Rules, Terms & Conditions for information about eligibility and prizes.

Gordon Margulieux Wins the CC Code Challenge (Week 29)

We have a winner of last week’s CC Weekly Code Challenge, sponsored by IAR Systems! We posted a code snippet with an error and challenged the engineering community to find the mistake!

Congratulations to Gordon Margulieux of Oregon, United States for winning the CC Weekly Code Challenge for Week 29! Gordon will receive an Elektor 2012 & 2011 Archive DVD.

Gordon’s correct answer was randomly selected from the pool of responses that correctly identified an error in the code. Gordon answered:

Line 10: Conditional should be “if (number == 0)” instead of number < 0

2013_code_challenge_29_answer

You can see the complete list of weekly winners and code challenges here.

What is the CC Weekly Code Challenge?
Each week, Circuit Cellar’s technical editors purposely insert an error in a snippet of code. It could be a semantic error, a syntax error, a design error, a spelling error, or another bug the editors slip in. You are challenged to find the error.Once the submission deadline passes, Circuit Cellar will randomly select one winner from the group of respondents who submit the correct answer.

Inspired? Want to try this week’s challenge? Get started!

Submission Deadline: The deadline for each week’s challenge is Sunday, 12 PM EST. Refer to the Rules, Terms & Conditions for information about eligibility and prizes.

Alvin Schurman Wins the CC Code Challenge (Week 28)

We have a winner of last week’s CC Weekly Code Challenge, sponsored by IAR Systems! We posted a code snippet with an error and challenged the engineering community to find the mistake!

Congratulations to Alvin Schurman of Florida, United States for winning the CC Weekly Code Challenge for Week 27! Alvin will receive a CC T-Shirt and a one year digital subscription/renewal.

Alvin’s correct answer was randomly selected from the pool of responses that correctly identified an error in the code. Alvin answered:

Line #35: Missing “, terminate()” before “after 0 -> ok” to recursively kill all (both) processes before ending

2013_code_challenge_28_answer

You can see the complete list of weekly winners and code challenges here.

What is the CC Weekly Code Challenge?
Each week, Circuit Cellar’s technical editors purposely insert an error in a snippet of code. It could be a semantic error, a syntax error, a design error, a spelling error, or another bug the editors slip in. You are challenged to find the error.Once the submission deadline passes, Circuit Cellar will randomly select one winner from the group of respondents who submit the correct answer.

Inspired? Want to try this week’s challenge? Get started!

Submission Deadline: The deadline for each week’s challenge is Sunday, 12 PM EST. Refer to the Rules, Terms & Conditions for information about eligibility and prizes.

Brian Shewan Wins the CC Code Challenge (Week 27)

We have a winner of last week’s CC Weekly Code Challenge, sponsored by IAR Systems! We posted a code snippet with an error and challenged the engineering community to find the mistake!

Congratulations to Brian Shewan of Nova Scotia, Canadafor winning the CC Weekly Code Challenge for Week 27! Brian will receive Circuit Cellar 2011 and 2012 Archive CD.

Brian’s correct answer was randomly selected from the pool of responses that correctly identified an error in the code. Brian answered:

Line 22: Shift register won’t shift. Change to “ShiftReg_ClkB <= {ShiftReg_ClkB[1:0], clkA_Change}”

2013_code_challenge_27_answer

You can see the complete list of weekly winners and code challenges here.

What is the CC Weekly Code Challenge?
Each week, Circuit Cellar’s technical editors purposely insert an error in a snippet of code. It could be a semantic error, a syntax error, a design error, a spelling error, or another bug the editors slip in. You are challenged to find the error.Once the submission deadline passes, Circuit Cellar will randomly select one winner from the group of respondents who submit the correct answer.

Inspired? Want to try this week’s challenge? Get started!

Submission Deadline: The deadline for each week’s challenge is Sunday, 12 PM EST. Refer to the Rules, Terms & Conditions for information about eligibility and prizes.

Kang Usman Wins the CC Code Challenge (Week 26)

We have a winner of last week’s CC Weekly Code Challenge, sponsored by IAR Systems! We posted a code snippet with an error and challenged the engineering community to find the mistake!

Congratulations to Kang Usman of Jakarta, Indonesia for winning the CC Weekly Code Challenge for Week 26! Kang will receive an IAR Kickstart: KSK-FM3-48PMC-USB.

Kang’s correct answer was randomly selected from the pool of responses that correctly identified an error in the code. Kang answered:

Line 46: need [ and ]. it should be translate([0,0,2*ThreadThick])

2013_code_challenge_26_answer

You can see the complete list of weekly winners and code challenges here.

What is the CC Weekly Code Challenge?
Each week, Circuit Cellar’s technical editors purposely insert an error in a snippet of code. It could be a semantic error, a syntax error, a design error, a spelling error, or another bug the editors slip in. You are challenged to find the error.Once the submission deadline passes, Circuit Cellar will randomly select one winner from the group of respondents who submit the correct answer.

Inspired? Want to try this week’s challenge? Get started!

Submission Deadline: The deadline for each week’s challenge is Sunday, 12 PM EST. Refer to the Rules, Terms & Conditions for information about eligibility and prizes.

Guido Cargnino Wins the CC Code Challenge (Week 25)

We have a winner of last week’s CC Weekly Code Challenge, sponsored by IAR Systems! We posted a code snippet with an error and challenged the engineering community to find the mistake!

Congratulations to Guido Cargnino of Grugliasco, Turin, Italy  for winning the CC Weekly Code Challenge for Week 25! Guido will receive an Elektor 2012 & 2011 Archive DVD.

Guido’s correct answer was randomly selected from the pool of responses that correctly identified an error in the code. Guido answered:

Line #14: *p and *q must be used.

2013_code_challenge_25_answer

You can see the complete list of weekly winners and code challenges here.

What is the CC Weekly Code Challenge?
Each week, Circuit Cellar’s technical editors purposely insert an error in a snippet of code. It could be a semantic error, a syntax error, a design error, a spelling error, or another bug the editors slip in. You are challenged to find the error.Once the submission deadline passes, Circuit Cellar will randomly select one winner from the group of respondents who submit the correct answer.

Inspired? Want to try this week’s challenge? Get started!

Submission Deadline: The deadline for each week’s challenge is Sunday, 12 PM EST. Refer to the Rules, Terms & Conditions for information about eligibility and prizes.

Low-Cost SBCs Could Revolutionize Robotics Education

For my entire life, my mother has been a technology trainer for various educational institutions, so it’s probably no surprise that I ended up as an engineer with a passion for STEM education. When I heard about the Raspberry Pi, a diminutive $25 computer, my thoughts immediately turned to creating low-cost mobile computing labs. These labs could be easily and quickly loaded with a variety of programming environments, walking students through a step-by-step curriculum to teach them about computer hardware and software.

However, my time in the robotics field has made me realize that this endeavor could be so much more than a traditional computer lab. By adding actuators and sensors, these low-cost SBCs could become fully fledged robotic platforms. Leveraging the common I2C protocol, adding chains of these sensors would be incredibly easy. The SBCs could even be paired with microcontrollers to add more functionality and introduce students to embedded design.

rover_webThere are many ways to introduce students to programming robot-computers, but I believe that a web-based interface is ideal. By setting up each computer as a web server, students can easily access the interface for their robot directly though the computer itself, or remotely from any web-enabled device (e.g., a smartphone or tablet). Through a web browser, these devices provide a uniform interface for remote control and even programming robotic platforms.

A server-side language (e.g., Python or PHP) can handle direct serial/I2C communications with actuators and sensors. It can also wrap more complicated robotic concepts into easily accessible functions. For example, the server-side language could handle PID and odometry control for a small rover, then provide the user functions such as “right, “left,“ and “forward“ to move the robot. These functions could be accessed through an AJAX interface directly controlled through a web browser, enabling the robot to perform simple tasks.

This web-based approach is great for an educational environment, as students can systematically pull back programming layers to learn more. Beginning students would be able to string preprogrammed movements together to make the robot perform simple tasks. Each movement could then be dissected into more basic commands, teaching students how to make their own movements by combining, rearranging, and altering these commands.

By adding more complex commands, students can even introduce autonomous behaviors into their robotic platforms. Eventually, students can be given access to the HTML user interfaces and begin to alter and customize the user interface. This small superficial step can give students insight into what they can do, spurring them ahead into the next phase.
Students can start as end users of this robotic framework, but can eventually graduate to become its developers. By mapping different commands to different functions in the server side code, students can begin to understand the links between the web interface and the code that runs it.

Kyle Granat

Kyle Granat, who wrote this essay for Circuit Cellar,  is a hardware engineer at Trossen Robotics, headquarted in Downers Grove, IL. Kyle graduated from Purdue University with a degree in Computer Engineering. Kyle, who lives in Valparaiso, IN, specializes in embedded system design and is dedicated to STEM education.

Students will delve deeper into the server-side code, eventually directly controlling actuators and sensors. Once students begin to understand the electronics at a much more basic level, they will be able to improve this robotic infrastructure by adding more features and languages. While the Raspberry Pi is one of today’s more popular SBCs, a variety of SBCs (e.g., the BeagleBone and the pcDuino) lend themselves nicely to building educational robotic platforms. As the cost of these platforms decreases, it becomes even more feasible for advanced students to recreate the experience on many platforms.

We’re already seeing web-based interfaces (e.g., ArduinoPi and WebIOPi) lay down the beginnings of a web-based framework to interact with hardware on SBCs. As these frameworks evolve, and as the costs of hardware drops even further, I’m confident we’ll see educational robotic platforms built by the open-source community.

John Safrit Wins the CC Code Challenge (Week 24)

We have a winner of last week’s CC Weekly Code Challenge, sponsored by IAR Systems! We posted a code snippet with an error and challenged the engineering community to find the mistake!

Congratulations to John Safrit of Mebane, North Carolina, United States  for winning the CC Weekly Code Challenge for Week 24! John will receive a CC T-shirt and a one-year subscription to Circuit Cellar.

John’s correct answer was randomly selected from the pool of responses that correctly identified an error in the code. John answered:

Line#22: need to terminate space string, add: space[d]=’';

2013_code_challenge_24_answer

You can see the complete list of weekly winners and code challenges here.

What is the CC Weekly Code Challenge?
Each week, Circuit Cellar’s technical editors purposely insert an error in a snippet of code. It could be a semantic error, a syntax error, a design error, a spelling error, or another bug the editors slip in. You are challenged to find the error.Once the submission deadline passes, Circuit Cellar will randomly select one winner from the group of respondents who submit the correct answer.

Inspired? Want to try this week’s challenge? Get started!

Submission Deadline: The deadline for each week’s challenge is Sunday, 12 PM EST. Refer to the Rules, Terms & Conditions for information about eligibility and prizes.

Rob Tholl Wins the CC Code Challenge (Week 23)

We have a winner of last week’s CC Weekly Code Challenge, sponsored by IAR Systems! We posted a code snippet with an error and challenged the engineering community to find the mistake!

Congratulations to Rob Tholl of Calgary, Alberta, Canada for winning the CC Weekly Code Challenge for Week 23! Rob will receive a CCGold Issues Archive.

Rob’s correct answer was randomly selected from the pool of responses that correctly identified an error in the code. Rob answered:

Line 14: need &array[c] to write to the proper memory location

2013_code_challenge_23_answer

You can see the complete list of weekly winners and code challenges here.

What is the CC Weekly Code Challenge?
Each week, Circuit Cellar’s technical editors purposely insert an error in a snippet of code. It could be a semantic error, a syntax error, a design error, a spelling error, or another bug the editors slip in. You are challenged to find the error.Once the submission deadline passes, Circuit Cellar will randomly select one winner from the group of respondents who submit the correct answer.

Inspired? Want to try this week’s challenge? Get started!

Submission Deadline: The deadline for each week’s challenge is Sunday, 12 PM EST. Refer to the Rules, Terms & Conditions for information about eligibility and prizes.

Mike Brown Wins the CC Code Challenge (Week 22)

We have a winner of last week’s CC Weekly Code Challenge, sponsored by IAR Systems! We posted a code snippet with an error and challenged the engineering community to find the mistake!

Congratulations to Mike Brown of Meldreth Cambs, United Kingdom for winning the CC Weekly Code Challenge for Week 22! Mike will receive an IAR Kickstart: KSK-TMPM061-JL.

Mike’s correct answer was randomly selected from the pool of responses that correctly identified an error in the code. Mike answered:

Line 9: Use “div.container” to select the div class ‘container’

Note: an acceptable alternate answer was to change the “class” to “id” on line 23 as indicated in the image below.

2013_code_challenge_22_answer

You can see the complete list of weekly winners and code challenges here.

What is the CC Weekly Code Challenge?
Each week, Circuit Cellar’s technical editors purposely insert an error in a snippet of code. It could be a semantic error, a syntax error, a design error, a spelling error, or another bug the editors slip in. You are challenged to find the error.Once the submission deadline passes, Circuit Cellar will randomly select one winner from the group of respondents who submit the correct answer.

Inspired? Want to try this week’s challenge? Get started!

Submission Deadline: The deadline for each week’s challenge is Sunday, 12 PM EST. Refer to the Rules, Terms & Conditions for information about eligibility and prizes.

Brian Shewan Wins the CC Code Challenge (Week 21)

We have a winner of last week’s CC Weekly Code Challenge, sponsored by IAR Systems! We posted a code snippet with an error and challenged the engineering community to find the mistake!

Congratulations to Brian Shewan of Nova Scotia, Canada for winning the CC Weekly Code Challenge for Week 21! Brian will receive an Elektor 2012 & 2011 Archive DVD.

Brians’s correct answer was randomly selected from the pool of responses that correctly identified an error in the code. Brian answered:

Line #4 – Missing ‘.’ after ‘PROGRAM-ID’. Change to “PROGRAM-ID. JUST-A-TEST.”

2013_code_challenge_21_answer

You can see the complete list of weekly winners and code challenges here.

What is the CC Weekly Code Challenge?
Each week, Circuit Cellar’s technical editors purposely insert an error in a snippet of code. It could be a semantic error, a syntax error, a design error, a spelling error, or another bug the editors slip in. You are challenged to find the error.Once the submission deadline passes, Circuit Cellar will randomly select one winner from the group of respondents who submit the correct answer.

Inspired? Want to try this week’s challenge? Get started!

Submission Deadline: The deadline for each week’s challenge is Sunday, 12 PM EST. Refer to the Rules, Terms & Conditions for information about eligibility and prizes.