EEWeb Pulse - Volume 6

PULSE EEWeb.comIssue 6

August 9, 2011

Laura Bica NASA Ground Station Software and Hardware

Electrical Engineering Community

EEWeb

Contact Us For Advertising Opportunities

[email protected]

www.eeweb.com/advertising

Electrical Engineering CommunityEEWeb

Digi-Key is an authorized distributor for all supplier partners. New products added daily. © 2011 Digi-Key Corporation, 701 Brooks Ave. South, Thief River Falls, MN 56701, USADigi-Key is an authorized distributor for all supplier partners. New products added daily.

www.digikey.com/techxchange

It’s all about connections.

The user-to-user forum is for everyone, from design engineers to hobbyists, to discuss technology, products, designs and more. Join the discussions that match your interest or offer your expertise to others.

Join the discussion now at:

discussions

hobbyists

engineers

industry experts

resourceslinks

technical documentswhite papers

reference designs

application notes

community

power

microcontroller

lighting

wireless

sensor

students

http://bit.ly/kDYHm7

EEWeb | Electrical Engineering Community Visit www.eeweb.com 3

TABLE O

F CO

NTEN

TSTABLE OF CONTENTS

Laura Bica 4COMPUTER ENGINEERING GRADUATE STUDENT, SANTA CLARA UNIVERSITY Interview with Laura Bica, Intern in the Cisco Systems, Inc. Wireless Business Unit

The Most Powerful Debugging Tool Ever - The LED BY PAUL CLARKE WITH EMB-PAPST

When Software Stinks 10BY DAVE LACEY WITH XMOS

RTZ - Return to Zero Comic 13

The importance of the blinking LED is commonly underestimated. Think ahead and add LEDs to your next design for a great debugging tool.

Fast real-time processing has its challenges. Lacey discusses a solution that combines the benefits of software with the real-time performance of hardware solutions.

8


INTERVIEWFEA

TURED IN

TERVIEW

Laura BicaNASA Ground Station Software and HardwareHow did you get into electronics/engineering and when did you start?

I grew up in a home that fostered my interest in technology. My dad is an engineer and from what I remember I’ve always had some amount of fascination with what he does. When I was really young, my sister and I would play with the big satellite phones that he would bring home from work for testing, so in a way I guess I’ve been interested in and involved with engineering for a long time.

I also went to a high school called High Tech High in San Diego, California which promoted my interest in technology even further. Through my school I was able to get a year-long internship with SPAWAR’s robotics department during my junior year. During my internship I got to work with a robot that utilized a Segway platform, and program it to do interesting things (at least for a high school student) like following me around the company’s campus. That internship also piqued my interest in soldering. When I started at Santa Clara and got involved with the school’s robotics lab, I knew that I had chosen the right major and school to be able to pursue my interests in technology.

What are your favorite hardware tools that you use?

Definitely soldering irons. That is not to say that I’m any good at soldering or that I solder often, but for some reason I really enjoy it. When I worked at SPAWAR I always wanted to help the tech with her soldering jobs, and would proceed to get “Use more flux!” yelled at me for the next hour. I even told my parents I was going to become a professional solderer and start a business dedicated to it. Luckily they convinced me to go to college first.

What are your favorite software tools that you use?

That varies day to day. This past school year I learned how interesting and powerful MATLAB can be, and enjoyed learning how to use it in conjunction with my senior project. Until this past academic year, I was under the impression that MATLAB was an easy way out of programming for non-computer programmers, but I’ve become especially impressed with its ability to allow programmers to import Java libraries. I’ve been able to enable some useful database and SSH functionality for my project by doing this. If I’m in a more web-based mindset, a combination of Photoshop and Dreamweaver tends to be my software of choice.

Laura Bica- Graduate Student in Computer Engineering at Santa Clara University


INTERVIEWFEA

TURED IN

TERVIEW

What is the hardest/trickiest bug you have ever fixed?

The compiler that we had to build in my compilers class last quarter was probably one of the toughest projects that I have ever worked on, and with it came some of the toughest bugs I’ve ever had to fix. I don’t know if I can come up with anything specific, but the majority of our class spent some long hours in the computer lab last quarter trying to make our compiler compile. By the end, we sort of took shifts—one person would finish his or her project and then stay to help until the next person finished, who would stay until the next person finished, and so on.

What is on your bookshelf?

Quite literally the things that are on my bookshelf at this very moment are my compilers book from last quarter (which gives me chills just thinking about it), Essentials of Software Engineering by Tsui Karam, O’Reilley’s 802.11 Wireless Networks—the Definitive Guide, Programming the World Wide Web by Sebesta, Unmasking the Gender Effect in the Engineering Workplace, The Art of Computer Systems Performance Analysis by Raj Jain, Content Networking by Hofmann and Beaumont, Beginner’s Guide to Text Editing (which I just noticed has a copyright from before I was born), a Dilbert book called Always Postpone Meetings with Time-Wasting Morons, some coloring books, Hitchhiker’s Guide to the Galaxy (which I’m embarrassed to admit I still haven’t read, but I do know the significance of 42!), and my cat has conveniently placed himself on the bottom shelf, probably for the sake of this interview.

Do you have any tricks up your sleeve?

Well, right now most of my “tricks” are associated with helping me in my classes. As of last quarter I have decided that imagining technical problems as non-technical pictures, shapes, or processes is a great way to understand concepts. For example, when converting regular expressions to finite automata, I started thinking of everything in terms of spaceships: A regex that allows for 0 or more would look like a spaceship with a top and a bottom, whereas a regex that allows for 1 or more of something looks like a spaceship with only the top completed. To understand assembly code, I actually imagine each of the instructions happening; a person actually has to physically move a value from one register to another, for example, shift the bits to the left. I think that imagining each instruction as a task being performed by an actual person makes me more conscious of whether or not I’ll be able to get the desired outcome with my code. I’m realizing how crazy all of this sounds as I’m saying it, though. Another skill that I’ve been using a lot this year is pair programming, where one person programs and another looks over the programmer’s shoulder to quickly catch mistakes and typos. I’m also a strong supporter of using caffeine (in the form of coffee) to promote productivity, if you want to consider that a trick.

What has been your favorite project?

I got to participate in some really interesting activities during my time with the robotics lab on campus.

The lab is responsible for operating multiple NASA spacecraft, which opened up a lot of interesting opportunities for the student-run mission operations team. Some of the things that I got to participate in with regard to satellite mission operations were actually operating and communicating with the satellite from the lab’s in-house built ground station, helping with the creation and maintenance of mission dashboards, as well as other mission-related tasks. Getting to be involved with such a large-scale project like that was a really unique and exciting experience for me.

Do you have any note-worthy engineering experiences?

When I worked at SPAWAR, one of the first projects I worked on was programming the Segway RMP robot to follow me. My mentor convinced me that there was no way, given my program, that the robot would get within five feet of me during testing. So I stood there and waited for the robot to detect and start following me. It found me, but I guess I didn’t make the importance of the five foot boundary very clear, because it ran right into me a couple seconds later.

Also, when I first started taking electrical engineering classes at Santa Clara I was actually determined to start a fire. I never managed, and I guess that explains why TAs for those classes always watched me a little more closely than everyone else. But, a couple years ago I decided that at the end of one of my electrical engineering labs I would start pulling components out of the proto board


INTERVIEWFEA

TURED IN

TERVIEW

while it was still powered, which definitely resulted in getting a nice little zap.

What are you currently working on?

Right now I am interning at Cisco Systems in the Wireless Networking Business Unit for the summer. The team I was placed with works on a network management system and my project is to create a mobile application that incorporates data from the computer-based system into smaller tasks that can be accomplished using an Android phone. The application is currently intended to be a device finder, so users of the network management system will be able to map the locations of devices like access points, clients, and interferers in their building by using this app. In addition, users will be able to see where they are on the map in relation to the device they are searching for, so the app will help to guide them to the device they wish to find. This is my first time working on mobile application development, so I’m learning a lot!

As of June I graduated from my undergraduate program, which included finishing my senior design project, which was in conjunction with the Robotic Systems Laboratory on campus that I had been working with since freshman year. Given the lab’s involvement with spacecraft missions, there are many different responsibilities, from creating ground station software and hardware, communicating with the satellites regularly, to maintaining public web-based mission dashboards for each mission.

My senior design project aimed to improve the system used for creating and maintaining the mission dashboard. The original dashboard design was a static HTML page that displayed values that change frequently. Because the lab is involved with so many tasks related to the mission, maintaining and updating the dashboard doesn’t always happen as often as it should. I created scripts that automate the updating process, so that the data displayed on the dashboard is always up to

date. I also incorporated some of the lab’s anomaly detection data and automated the production of plots displayed on the page to make the new version of the dashboard even more useful as a data dissemination mechanism than the original version.

What direction do you see yourself heading in the next few years?

After the summer I’ll be going on to graduate school at Santa Clara for a master’s in computer engineering for a year. I’m planning on taking the networking track for my degree, as I’m really interested in the computer engineering side of networks and I think that it is a constantly evolving topic in the technological world right now. Once I’m done with graduate school, I’m hoping to get a full time job in the industry, somewhere in California if possible. ■

EEWebElectrical Engineering Community

Join Todaywww.eeweb.com/register

http://bit.ly/jd6Wcw

Avago Technologies AEDR-850x three channel reflective encoders integrate an LED light source, photo detector and interpolator circuitry.

It is best suited to applications where small size and space matters!

Applications include medical hand held devices, camera phones, wheel chairs, actuator, vending machine applications, just to name a few.

www.avagotech.com/motioncontrol

© 2011 Avago Technologies. All rights reserved.

Avago Technologies Motion Control Solutions

World’s Smallest Miniature Reflective 3-channel Encoder

To request a free sample go to:

Features Advantages Benefits

3-channel encoding (AB and I)

Index Signal “I” No need for separate components to generate the index signal

Miniature size Surface mount leadless package: 3.95 mm (L) x 3.4mm (W) x 0.95mm H)

Ability to fit into miniature motor designs

304 LPI High encoding resolution Various CPR capable by adjusting to the matching ROP of the codewheel

Built in Interpolator of 1x, 2x, and 4x

1x, 2x and 4x via external pinouts

Base CPR resolution can be interpolated by end user

High operating frequencies: 55 kHz at 1x interpolation

Operating frequencies can be increased by external interpolator pinouts by maximum of 4x

Corresponding high RPM performance with increased frequencies

Index gating Options available for both gated and ungated versions

Catering for various user gating requirements

-20°C to 85°C Industrial application capable

Covering consumer, commercial and industrial applications

http://bit.ly/jpn9V5


There was a time when debugging was not easy. I want to share some of the stuff I used to do to debug code and hardware—the hard way.

Going back to when I started out in the 80s, there were few fancy debugging tools, and the ones that were around were expensive. In my first job we used Z80 processors, which was good because I’d used them when playing around with my ZX81 and ZX-Spectrum. Getting a board to work the first time was not easy. Current micros can be loaded with code, but a processor needs, among other things, RAM and ROM to get you started.

So once the first board was made, I put some basic code in it to just loop. To test it was working, I would disconnect the clock and run it from a 555 timer at about 3Hz. That’s right, very slow! I would have LEDs hanging off the Data Bus and Address Line. In fact, I had a header that would fit between the CPU and the board. This way I could see the lines of code running and check. After that I would progress to getting an I/O line working, slowly adding more and more code, testing each part of the board bit by bit.

Over time we got a working CPU board that would run

code and address RAM and ROM correctly. It was not a massive task to test and develop but was important to get right early on. After this and getting an I/O port working, you get to the point where we are today with current micros and can have a blinking LED—the first universal debugging tool!

Many of my designs still have a place for a LED on an I/O pin. This is normally used as a heart beat indicator. That is, every time the code loops around, you toggle the LED and can see that the board and micro is still running.

The blinking LED is, however, a very important debug tool that I think people forget about today, even with modern circuit debugging tools. Consider this: the faster your LED blinks, the quicker your code is looping! Now hook this to an oscilloscope and you can monitor your loop time for the micro and detect when big step changes happen during events.

Another use of our Blinky LED is for interrupts. Turn the LED on when entering an interrupt and off again when you exit. From a visual point of view, the more your LED is on, the more time you are spending inside your interrupt

Paul ClarkeElectronics Design Engineer

The MostPowerfulDebuggingTool Ever

THELED


TECHN

ICA

L ARTIC

LETECHNICAL ARTICLE

code, resulting in less time running normal functions. On a scope you can monitor what percentage of time your code is spent inside the interrupt code and if external events affect it. All this from an I/O pin output!

After the LED, we used to hook up a Display or a UART for serial communication to a PC. This then allowed for

visual monitoring of values inside the chip and software. Today, this can be done with in-circuit debugging tools connected directly to dedicated code or hardware in the chip. At one point in time I even designed my own in-circuit debugging tool for a Z80 CPU that allowed single stepping of code. However, I still feel that a single I/O pin and a blinking LED is, by far, the most usefully debugging tool.

About the Author:

Paul Clarke is a digital electronics engineer with strong software skills in assembly and C for embedded systems. At ebm-papst, he develops embedded electronics for thermal management control solutions for the air movement industry. He is responsible for the entire development cycle, from working with customers on requirement specifications to circuit and PCB design, developing the software, release of drawings, and production support. ■

Figure 1: Green LEDs

EEWebElectrical Engineering Community

Contact Us For Advertising Opportunities

[email protected]

www.eeweb.com/advertising

http://bit.ly/l6u6Cx


Software is an amazing thing. Programming languages are immensely expressive,

compilation is quick, there are lots of abstractions and tools for development, and it is quick and easy to update the function of a device. This means that any part in your system driven by software is the most flexible thing in your system—a wonder part.

However, there is one place that software really stinks: fast real-time processing. This is the kind of processing when a task must be completed before some external event, for example, manipulating image data between screen refreshes of a display, or supplying data to external I/O pins based on some fast clock.

Of course, software can be used for this, but all the wonderful ease of use and flexibility seems to fall away. Software development becomes hard and difficult to maintain.

The Problems

So, why does software have problems when faced with real-time or interface-driven applications? The problems can be characterized into categories:

Problem 1: Multi-tasking

Naturally, a processor is likely to be trying to do more than one task, even for the simplest problem. However, processors cannot generally do more than one thing at once. Even multi-core processors with traditional architectures may

only be able to do two or four things at once in hardware.

The problem is that multi-tasking on a naturally single-threaded processor involves the software scheduling tasks in and out of the processor in chunks. From the viewpoint of a single task, scheduling means you do not know when you are in and when you are out, making it hard to meet real-time constraints.

Problem 2: Interrupts

Even for a “single-threaded” application, the processor is likely to be doing more than one thing at a time. Interrupts provide an implicit form of multitasking. An interrupt firing (to service an I/O handler for example) is the same as a scheduler

Dave LaceyTechnical Director of Software Tools


TECHN

ICA

L ARTIC

LETECHNICAL ARTICLE

switching out a task. See figure 1.

Problem 3: Lack of Predictability

It seems that software really lacks predictability with regard to timing. You need a task to run in a certain number of microseconds but you cannot be sure it will. Scheduling and interrupts are only part of the problem. Some microprocessors have a cache for memory access and the time a memory access takes varies depending on the state of that cache. Also, some microprocessors are superscalar so each instruction takes a variable amount of time to execute. This all means that you cannot just count the number of instructions and know how long that instruction sequence is going to take.

Problem 4: Lack of resources

When real-time software is used in embedded applications there tends to be another problem: lack of resources. Memory and clock cycles cost money so there is a drive to get as much as possible from low-resource devices. This is a problem for modern software abstractions that tend to view resources as plentiful, for example, memory as an infinite resource.

Solutions

One option to avoid the problems of real-time software is to implement it in a hardware solution. If a fixed function part exists with the functionality you want, there is really nothing to do. Alternatively, a re-programmable hardware part like an FPGA may do, providing you have the skills to program it.

Even if you do, it is likely that some software tasks are required so you have to integrate the FPGA with a microprocessor, either on the FPGA or on a separate part. This hardware/software division gives multiple design flows and tools, and lacks the tight integration of disparate functionality that software development can provide.

Are there any solutions that provide all the benefits of software development but without the issues that occur when trying to do real-time programming?

One option is to use a real-time operating system (RTOS)—conventional operating systems with extra different features for real-time applications. Firstly, the scheduling of multiple tasks is prioritized and time-aware, so the scheduler tries to guarantee that tasks meet their timing constraint. Secondly, the OS

is designed so that the worst-case execution time of all system tasks is known, enabling you to do some worst-case execution time (WCET) analysis.

RTOSs on traditional micropro-cessors, however, provide a pretty heavyweight solution. It is trying to bend something not naturally real-time into a real-time framework. Even if the scheduling is real-time aware and WCET is performed on system tasks, the non-determinism of the processor (cache, supers-calar execution) is still there. The upshot of this is that even with a reasonably fast microprocessor, it is hard to do tasks with sub-microsec-ond constraints due to the overhead of the OS. These kinds of tasks are still traditionally handled with ASICS or FPGAs.

XMOS devices provide a brand new solution that combines the

RAM GPIO INTCInterrupts

Typical Bus Based System

CPU

CACHE

PORTCPU

RAM

Events

XMOS DeviceFigure 1: Interrupt vs. Event


TECHN

ICA

L ARTIC

LETECHNICAL ARTICLE

benefits of software with the real-time performance of hardware solutions.

XMOS – Designed for Real-Time

XMOS processors are built ground up for real-time processing with fast external I/O constraints. They are designed to combine the best of hardware design with the best of software design.

Solution 1: Hardware Multi-tasking

XMOS devices handle multi-tasking in hardware with a set of tasks running on different software threads. Every clock cycle, a different thread swaps into context in a round-robin style. This means that you do not have to worry about a scheduler—you can view each thread as an independent entity running at a set speed. It is also a naturally multi-core architecture, so adding more cores means that more independent tasks can be run.

Solution 2: Event-Driven Architecture

There is no OS layer on XMOS devices. Instead of interrupts, each thread explicitly responds to events. This approach means that there are no hidden tasks that can jump in and upset the timing of your software.

Solution 3: Predictable Execution

The lack of OS and software scheduler combined with memory that has no cache (each memory access takes one thread cycle) and

the use of independent resources for each thread, means that with XMOS, you have the predictability required for real-time applications. You know how long an instruction sequence will take statically. Furthermore, XMOS provides a Timing Analyzer (XTA) tool, which accurately gauges the worst-case execution time between two points of code (taking into account multiple paths of control flow, function calls).

Solution 4: Managed resources

XMOS devices are designed for embedded applications and, as such, are low-cost and low-resource. The key for the software programmer is managing those resources. The software development tools (standard C compiler based tools with extensions) keep track of resource usage so you know you are not going to run out at run time. If you need more memory, processing power or I/O, simply add another core, as resources are fully scalable.

The tools also ensure that each thread only uses its own resources and cannot interfere with each other.

Conclusion

This article shows the difficulties of software programming for real-time applications and the motivation behind the design of the XMOS family of devices. The next time you design a system that requires real-time processing and I/O programming, check out XMOS and see how you can combine the benefits of software development with real-time performance.

About the Author:

Dr. David Lacey works as Technical Director of Software Tools at XMOS Ltd. With over ten years of research and development in programming tools and compilation technology, he now works on the development tools for XMOS devices. As well as tools development, he has worked on application development for parallel and embedded microprocessors including work in areas such as math libraries, networking, financial simulation, and audio processing.■

http://www.xmos.com


RETURN TO

ZERORETURN TO ZERO


RETURN TO

ZERORETURN TO ZERO

Join Today

www.eeweb.com/register

Electrical Engineering CommunityEEWeb

EEWeb Pulse - Volume 6

Documents

Transcript of EEWeb Pulse - Volume 6