Ideas in Wiring

Engineering our future

2008-06-18T12:49:00.000-07:00

As engineers and scientists, we're trying to make the world a better place. In addition to our day jobs, there are things we can do off-hours too. If you can take two hours a week from whatever else you are doing and instead continue to be an engineer, I have a suggestion for you. Please be a mentor. You can be the inspiration to an entire classroom of elementary school students to become engineers and scientists when they grow up. In addition, you get a chance to be a kid and even play with toys - engineering toys.

One way is to be a mentor for a FIRST Lego League (FLL) team. Every fall, teams of 4-10 elementary and middle school students get a big box of LEGO pieces and a challenge. By December, they need to have built a fully autonomous robot that will complete as many challenges as possible as well as a presentation on the challenge topic. This year, over 2000 teams participated in regional, national, and international competitions culminating in the FIRST World Festival in Atlanta, Georgia. It's fun to watch how the kids grow through their participation. The shy learn to speak up, the dominant learn to share, and they all get to experience some fun that they may not normally get in their school day.

(image taken from usfirst.org website - yes, the trophy is made of LEGO pieces)

If you want to work with high-schoolers, FIRST also has two other competitions: FIRST Tech Challenge and FIRST Robotics Competition. While the FLL robots are small and plastic, the FTC and FRC robots get heavier and more powerful. FTC robots are around 24" cubes that weigh 5 pounds and the FRC robots get up to 120 pounds and the size of a refrigerator.

(image from usfirst.org website)

40% of FRC participants end up going to engineering school in college. At the FRC finals in Atlanta, I saw 20 colleges with information booths. Athletes aren't the only way to get scholarships now - some schools are giving them out to FRC participants.

Inspire an engineer - get involved. You won't regret it.

Some days you just have to shake your head

2007-10-04T08:28:00.001-07:00

The Power.org organization just met in Austin and one of their conversations was on multi-core programming. Some days, I just feel sorry for programmers stuck in the traditional embedded world. This is from an EE-times article:

"The inability of C/C++ code to parallelize coupled with its ubiquity throughout the embedded market is a major issue for multi-core going forward," Heikkila wrote in a follow up email to EE Times. "Any alternative parallel programming languages certainly won't materialize in the embedded market, but instead will more likely gain momentum in a more mainstream computing market before making its way into embedded applications," he added.

And more bad news for current developers

So far, engineers are giving embedded software a low grade of just 2.06 out of five in terms of its readiness for multi-core.

One day, they'll use LabVIEW....

Profiling Multi-Core Applications

2007-07-31T14:18:00.000-07:00

A while ago, I wrote an article about writing parallel programs. The next question is: how do you optimize them?

Note: if you are writing multi-core programs and are coming to NIWeek, please email me (email address on the right). I'd like to talk to you about this topic further. But I digress...

Typically, when optimizing an application, you are trying to make it faster. "Faster" usually means "reduce the time the user observes the task to take". We sometimes call that "wall clock time". Occasionally, there is no outside observer. Instead, you want your task to be less of a disruption on other applications. In that case, you are purely concerned with how much of the resources of the computer, typically the CPU, are being consumed. This consumption could be called "CPU time".

When optimizing for wall clock time, you quickly run into some difficulties.

1) Most profilers give you time of operation in CPU time. A function that goes to sleep for 10 minutes has a CPU time of nearly nothing but a wall clock time of 10 minutes.

For example, if you run this VI with the LabVIEW profiler enabled, it will show that it uses a whopping 46.9 milliseconds

So, you think. Wow, my application took 10 seconds and this function only took 47 milliseconds, I guess my slowdown is elsewhere. And, of course, you would be wrong. Now, this example is pretty silly. No one just adds a sleep for the heck of it. Normally, you'll find "sleep time" in a couple of different places

Pausing because you need to synchronize with other event. Maybe you go to sleep for 1 second until some external piece of hardware has responded.
Calls into the OS. Reading from disk and writing from disk occurs in the OS. The CPU time returned by the profiler doesn't normally show time spent in the OS, even though it is consuming CPU cycles.
Calls into a driver. Some driver calls do their work inside the OS so they are a case of #2. Or, sometimes they get implemented as a LabVIEW sleep, and so they also don't get counted.
Task swaps. The OS might decide to give some other application some time. This hurts the wall clock time of your application but your profiler won't tell you.

If you want wall to measure wall clock time, you should instead get the tick count of the machine before and after the operation occurs. A tick count uses wall clock time to give you the results. My profiling article shows you how to get the tick count to profile an operation.

2) Things get a bit weirder when you want to try and optimize on a multi-core computer. On a single core machine, you can make your program run faster by either reducing wait time like you saw in #1 or by reducing the CPU time. On a multi core machine, a task can have a shorter wall clock time even though the CPU time and wait time are the same. If you split the CPU work (i.e. CPU time) evenly across two processors, your wall clock time goes down by a factor of 2 but your CPU time is the same.

You can observe this with the Windows task manager. If you have two cores, the task manager will show two graphs of CPU utilization, one for each CPU. You can also use the windows application "perfmon" which gives you a bit more flexible way to observe this.

(the CPU Usage History shows 2 graphs, one for each processor)

So, to optimize your application, the trick is to max out both processors. In effect, you are trying to INCREASE the CPU time for the second processor by shifting the processing from CPU 1 to CPU2. It's odd to think of optimizing as increasing processor time, but that's what you are doing.

The problem with using this approach is that increasing the CPU time on the second processor doesn't necessarily reduce wall clock time. Your efforts to make your application more parallel might add CPU work, such as forcing memory copies, that negate the benefit of parallelism.

As an example, the old LabVIEW queue primitives used to copy data into and out of the queues. If you put a big array in a queue, it would spend a lot of time copying the array into the queue and then a lot of time copying it out. To make my application more parallel, I split it into loops and used queues to pass the data between the loops. My CPU utilization was great, 100% on both cores, but my wall clock time was slower because it spent a long time simply copying data around. Fortunately, we learned from that experience and the primitives don't make copies of arrays & clusters any more.

Unfortunately, there's not a really good way to look at this effect right now. Use tick counts to measure your wall clock time and use the profiler to establish a baseline. Then, as you are making changes, make sure the wall clock time is going down and the CPU time is remaining at least constant or only going up slightly.

Physics of a Radar System

2007-07-28T19:49:00.001-07:00

If you ever wanted to know how a military radar transmission works, there's a pretty good overview that you can find in this Tektronix Application Note on pages 2-6 It talks about what a radar pulse looks like and why you might modulate the pulse in order to get better performance.

They skipped the most basic type of radar system but Mattel has utilized it to make a really neat and cheap radar gun.

You can use RADAR (technically it's an acronym so it should be capitalized) to tell a number of things about object it's aimed at. The Mattel radar gun gives you the most basic information, speed. It transmits a microwave signal and observes the reflections (if any) that come back from the object. If the object is moving toward or away from the gun, the reflected signal will have a Doppler shift. The amount of frequency shift is proportional to the speed.

Now if you remember your music theory, when you mix two waves of slightly different frequencies together, you get a signal with both frequencies as well as a "beat". The frequency of the beat is the frequency difference between the signals.

Taking advantage of this, the Mattel gun combines the signal it sends and the signal it receives to get the resultant signal, filters out the microwave signals and is left with the beat signal. Get the frequency of the beat signal and it's some simple math to get the velocity of the object.

All this for $30 retail.

Now, notice that the gun doesn't give you position. Radar systems figure out how far the target is away by measuring how long it takes for the signal to reach the target and come back. To do this, they send a pulse and wait for the return and then time the return. The Mattel gun sends a continuous signal rather than a pulse so it has no way of measuring time of flight. That processing would probably also cost a bit more to implement.

Why did I even bother to read this article? Well, I'm seeing some of our customers testing radar systems by simulating return pulses with hardware such as the R-series plug in boards or our Vector Signal Generators and wanted to know a little more about what they were really doing.

Streaming Processing

2007-07-23T19:46:00.001-07:00

A device such as a digital oscilloscope uses a high speed a/d converter to acquire the desired signal for some very short duration of time at a very high sampling rate, this acquired data is then transferred through a signal processing engine that may perform some sort of analysis on the data at that point such as an RMS calculation, and then the data is transferred to the main display engine for more math (such as calculating a cursor value) and finally displayed on the screen. So the flow is simple, acquire the data, analyze it to make the measurement, and present the result to the user. For 20 years, NI has used the phrase "acquire, analyze, present" to describe virtual instrumentation. A virtual instrumentation system allowed you to create that oscilloscope yourself out of a PC, a digitizer, and LabVIEW and allowed you to write your own measurement.

However, the phrase "acquire, analyze, present" may misleadingly imply that the phases are discrete when in fact they can be continuous. Why might this be continuous? One example is the processing to perform a trigger. If a scope is going to trigger when the signal exceeds a voltage level, acquisition and analysis must run continuously to digitize the signal and perform some very simple math (comparison) to look for the threshold to be met.

As with all engineering problems, the devil is taking the simple concept and applying it to a need that our customers have. Creating that trigger is subject to two fundamental limitations: the speed at which the trigger criteria can be evaluated and the rate at which the data can be sent from the a/d unit to the trigger computation circuitry. Triggering is typically a hardware operation because it needs to run at a megasample or gigasample rate and it is performed "close" to the a/d converter to handle the data rate of hundreds of megabytes or multiple gigabytes per second being generated.

The march of technology provides some interesting opportunities on the horizon that have been alluded to in past posts. The architecture of a software defined radio (SDR) and an oscilloscope are not that different. The FPGA technology and wideband A/D technology driving SDR is beneficial in T&M applications. The biggest difference is the audience. Whereas the SDR design team consists of C and VHDL programmers working for 12 months on a highly specified design in a high process development environment, the T&M system design team is a few people who know LabVIEW trying to keep up with the changing specs being thrown over the wall and trying to avoid the end product being late even when the design team is late.

The next generation of test equipment will be leveraging the technological power available in the SDR architecture but the ease of use you expect from a T&M instrument to get those difficult measurements made. Imagine the possibilities:

Write your own math computation for that trigger, compile it, and have it run at the full rate of the hardware.
Perform calculations on the data at full speed. Need a hundred kilohertz RMS calculation to decode a LVDT? You've got it. Filter or demodulate a 20 MHz communication signal? No problem.
Take that test that you wrote but have part of it run on an FPGA to speed it up. When that's not good enough, take the whole thing and move it down to the FPGA.

All of these tasks are possible today but some aren't as easy as they could be. The technology is there to accomplish the task, the trick is to expose that power to you. NIWeek is coming up in just over two weeks. I look forward to discussing the possibilities with you there.

University of Maryland's PRAM Computer

2007-06-28T19:12:00.000-07:00

In breathless language, the University of Maryland announced "New Era of "Desktop Supercomputing" Made Possible
with Parallel Processing Power on a Single Chip". If you read the article, you will find no hint of substance whatsoever about why this is so revolutionary and that's a shame because they might actually have something.

The presentation they made at the Symposium on Parallelism in Algorithms and Architectures is similarly light on detail except for one term I was unfamiliar with so I googled it, a "PRAM Machine". This machine appears to be a simple (but ill-documented) concept

(From Wellesley CS331 Notes)
A PRAM uses p identical processors ... and [is] able to perform the usual computation of [a typical processor] that is equipped
with a finite amount of local memory. The processors communicate through some shared global memory to which all are connected. The shared memory contains a finite number of memory cells. There is a global clock that sets the pace of the machine executon. In one time-unit period each processor can perform, if so wishes, any or all of the following three
steps:
1. Read from a memory location, global or local;
2. Execute a single RAM operation, and
3. Write to a memory location, global or local.

So really, the only difference between it and a multicore Pentium is that there are probably more than 4 CPUs and that all of the CPUs share a global clock. Interesting but I think the better question is - why did they build it?

It looks like there's a whole set of theory that goes into how to extract parallelism out of algorithms and a PRAM execution model allows the task to be expressed simply.

For example, suppose you wanted to increment the contents of every element of an array by 1. This type of machine would simply have every processor load one element, increment it, and store it back. If you had the same number of processors as array elements, that operation would take place in exactly one time unit. Perfect parallelization. That particular operation is also found in "SIMD" machines. Again, the importance is not that a PRAM can implement this operation, it's because there have been languages developed that allow all of this business of scheduling all of the instructions across processors to be abstracted from the programmer.

Interestingly, it looks like we could use these same concepts to schedule LabVIEW code without having to change the diagram at all. Hmm.

Reasons for personal source code control

2007-06-19T15:18:00.001-07:00

In Jim Kring's top 5 bad excuses for not using source code control post, someone commented

Perhaps another top five is needed - “reasons a single LabVIEW developer should use scc software” - then we could decide for ourselves how our manual methods stack up.

So here's my top 5

1. It forces you to document what you changed

Each time I check in/commit a set of VIs, the SCC program (+ LabVIEW if I enable it) asks me to describe my changes. It's invaluable to have a running history of the changes you made to your code, both what you said you changed and what VIs actually were different. Here's an example from one of my personal projects

#1 - "Initial version"
#2 - "Fixed link to Open URL in Browser. It isn't in vi.lib so the paths get all messed up as soon as you move this llb somewhere else"
#3 - "Changed name of LLB and help directory. Added quoting to the URL sent to OpenURL"
#4 - "Added flashing of dots on refresh. Enhanced the help slightly. Will add to the help in the next changelist"
#5 - "Added examples and 2 more pictures to the docs"
#6 - "Completed help and examples - pre final review"

That code was written in November 2001 and by looking at that brief history, it takes me back through what I was doing.

2. It tracks code in multiple areas with ease

Code that spans multiple folder hierarchies on disk can be a problem for the "make a copy as a backup" technique. Good source code management systems can track code spread across your disk. Did you put code in user.lib and in your documents & settings area? No problem. As soon as you have code in more than one directory, I question how meticulous you will be about copying "everything". Instead, you'll start getting lazy which takes us to #3.

3. You can always revert to a good (or at least known) state

If something goes horribly wrong, I do a "save" rather than "save as..." and nuke a VI, I can always recover to something known. It can be accomplished in 3 mouse clicks rather than searching around on the hard drive. For SCM systems that are "changelist" based (such as CVS, Subversion, and Perforce), you can pull from a particular known good state. "Give me what I submitted on 5/21/2007" and you know those VIs actually work together. That's why one of the "good scm practices" is to put EVERYTHING that could change under SCM.

4. You can get everything back 6 months from now

This is another version of #2 & #3. Suppose your nifty user.lib extension changes 4 months from now. Can you rebuild your nice little utility that used an older version? Do you even have that older version of the extension any more? Keep everything that could change under SCM, including the OpenG tools that you get from Jim and you can always roll your environment back to the way it was 6 months ago and have a clean rebuild. We put our C++ compiler under SCM here at NI so if we need to rebuild LabVIEW 8.0.1 for some reason, we can make sure we are using the exact same build environment as when we first built it.

5. Allows you to track your components

You got those nifty OpenG tools and you (gasp) modified a VI! How do you keep track of those changes? What happens when they upgrade those components? How do you make sure you go re-modify the source with your changes? Manual record-keeping is not your friend here.

6. More disk efficient

Maybe in this age of big hard drives, this isn't an issue. But how many times are you going to make a duplicate of a 30 meg folder hierarchy because you changed one VI. Do you stop and say "maybe not, I'll do it later". That goes through my head.

Hear me on a TechOnline roundtable with respected experts

2007-06-13T10:16:00.001-07:00

Embedded systems are getting more complicated and harder to program. What can be done about it? You can come hear a panel of experts (+ me) talk about the challenges of embedded systems programming and a risk of programmer shortage in the future.

The round table participants are all current or former editors of Embedded Systems Design magazine and are folks I've read for a long time. I've been reading Jack Ganssle's column since 1994 when I was at Motorola Semiconductor and Dan Saks's articles when I was still programming in C++ on LabVIEW so it's neat to share the virtual stage with them.

This web-cast came about because the current editor in chief of Embedded Systems Design magazine, Rich Nash, wrote an article postulating that there was an emerging coding crisis. It generated more letters to the editor than anything else he had done. You can see them in the online comments to the article as well as a follow up reader response article.

So, if you're not going to be busy on June 19th, please sign up and listen in. There will be a Q&A section at the end if you want to ask follow-ups or you can post questions to me here if you want.

There are some trends I'm especially interested in discussing such as high level programming tool adoption, difficulties programming multicore processors, and how FPGAs might change things.

Code Reviews

2007-05-10T08:32:00.000-07:00

A recent post on Embedded.com about Peer Code Reviews got me thinking about the process we use in the LabVIEW team for checking in code. It came about many many years ago and is, in my opinion, the most effective process I've seen. We call it "buddying", but a lightweight peer code review is probably the technical term.

It can be summarized quickly as: No code gets checked into the main branch unless the changes have been reviewed by a second person.

The practical process is
1) The programmer makes the code changes. These changes may be checked in to a private branch in source control or may be just sitting on his/her hard drive.
2) If the changes are in the 100-line or fewer area (which is a majority of submissions), the programmer goes and "gets a buddy". The buddy is typically a senior level programmer who is already familiar with that code area but that's not a hard rule.
3) The author walks through each line of the changes with the buddy and explains the changes. The buddy points out any stylistic problems, double checks for off-by-zero or null pointer handling code, and reminds the author about any gotchas that may be in that area.
4) If the buddy is satisfied with the code, it gets checked in to the source code control system and the author & buddy's names are noted.

That's it. It adds about 10 minutes to each code submission and keeps a lot of "doh!" errors out of the code. If you don't have a system like this now, I recommend you try it. We find it invaluable.

Manipulating Data Files

2007-04-26T11:15:00.000-07:00

Jim Kring posted techniques in his blog future-proofing data files by adding schema and version information to the file. Over the years, we’ve added some file formats to LabVIEW that make it hard for customers to follow his rules and that can cause problems.

I’ve seen folks hang themselves with the Datalog file by writing a file with one particular type definition (i.e. cluster) and then can’t read the file any more when they change clusters without understanding it will affect backward compatibility.

The newer file formats in LabVIEW like .TDM datalog files are much more maintainable because they store the type definition (typically called a ’schema’) in the data file so you can’t lose it and so it can be browsed by an external application.

Technorati tags: LabVIEW, DataStorage

Writing Stylish Code

2007-04-25T11:42:00.000-07:00

Working on a codebase that is authored by a lot of people has given me a new appreciation for writing consistently styled code. Even having 10 programmers all writing in a different way makes it hard to go in and modify or fix code written by someone else. In the C/C++ community, there are constant wars about indention or variable naming. In the end, it's not really important which convention you pick, it's more important that you pick one and stick to it.

LabVIEW is no different and it may be a bit more difficult because we give you 2 dimensions (X and Y) in which to place your code rather than just one. I just saw an announcement for a new LabVIEW book and thought I'd pass it along.

The LabVIEW Style Book - Peter A Blume

Best-Practice Style Rules and Standards for Developing Quality LabVIEW Software
Drawing on the experiences of a world-class LabVIEW development organization, The LabVIEW Style Book is the definitive guide to best practices in LabVIEW development.
Leading LabVIEW development manager Peter A. Blume presents practical guidelines or "rules" for optimizing every facet of your applications: ease of use, efficiency, readability, simplicity, performance, maintainability, and robustness. Blume explains each style rule thoroughly, presenting realistic examples and illustrations. He even presents "nonconforming" examples that show what not to do-and why not.

I like that he mentions a tool that we release and use internally for our own G code reviews

Code reviews: Enforcing a style convention using a checklist, the LabVIEW VI Analyzer Toolkit, and peer reviews

Check it out.

Technorati tags: LabVIEW, CodingStyle

Tracing Software During Hardware Test

2007-02-15T09:00:00.000-08:00

In my last post, I mentioned a need to find software faults in microprocessor-controlled embedded systems. Since I'm a software guy, I'm curious about this angle and started doing some reasearch.

1) The faults that were mentioned (timing, memory leaks, crashes) are basically software domain problems but they may only be triggered by certain I/O inputs the system receives (and the sw ends up dealing with). So, it looks like the main tools to diagnose the fault will need to be ones that deal with the software domain but the system may need to be driven from the hardware I/O domain.

2) These challenges are similar to those found in other applications that use microprocessor-driven control systems. For example, NI makes hardware that can be used for real-time process control (such as controlling valves in a paper mill). The controllers need to run 24x7, just like a radio, and the entire system is controlled by the microprocessor. NI needs to make those controllers robust and therefore we need to test them extensively.

3) The automotive industry also uses microprocessor-based high speed control systems, especially to control the "powertrain" (engine & transmission). They use a technique called Hardware in the loop testing. The real controller (ECM) that is to be mounted in the car is hooked to a "simulator". The ECM sends out real output signals using a real wiring harness to the simulator, the simulator then looks at the outputs from the ECM and calculates what the real engine would do and then sends signals back to the ECM that make it think it is talking to a real engine. You then "drive" the ECM as if you were driving the car through various scenarios and the simulator checks to make sure all of the outputs from the ECM are valid. At the same time as the simulator is running, they monitor the software running on the ECM to verify that it is operating properly. If the ECM crashes, they have tools to tell them what happened in the software. It would seem like you could do exactly the same thing with software defined radio test.

4) In the auto industry, they typically don't have an OS and they do the tracing at a low level. In the old days, this was done with a chip emulator. The emulator (or logic analyzer) would snoop the address and data bus to monitor execution. Now that caches are so prevalent, the external bus is not a good place to monitor. Chips that Freescale makes for automotive such as the MPC565 have a port called NEXUS. This port works in conjunction with information coming out on the address/data bus to spit out information while the processor is running that gives visibility into the processor pipeline. You can tell that a branch was taken, not taken, etc.. even if the instruction stream is all in the cache. There are boxes such as the Lauterbach ICD Trace that hook up to the chip for this purpose. Their tools can then show the full execution history, what led up to the processor crash, etc. WindRiver, GreenHills, and other emulator vendors also have this capability.

It would seem like this concept could be applied to Software Defined Radio. A Radio Emulator could drive the radio under test while the radio is being monitored with a tool like this. In the automotive case, I don't know how much this trace data ends up getting synchronized to the operation of the HIL emulator. It might be critical to share control or timing information between the radio emulator and the trace tool so that you can correlate the waveform signals precisely to the line of code being executed. This is where I think LabVIEW would come in. HIL simulators provided by NI partners use LabVIEW as their base and are open to be modified by the end user. LabVIEW has the ability to work with other software tools via ActiveX and other interfaces. It should be relatively easy to get LabVIEW to control both the HIL simulator and the trace tool.

5) Since SDRs typically run high function OSes like GreenHills Integrity or WindRiver VxWorks, there are some additional tools that would be useful during debug. WindRiver has a tool called MemScope that will monitor the heap so you can see memory leaks. LabVIEW could control this tool also. GreenHills has a leak checker but I haven't had any luck finding out more details on what it does.

I'm looking into setting up this type of system in our lab. We have a reliability lab here for testing our real time controllers and we're looking at adding a tool like MemScope (since we use VxWorks in our controllers) to our testing arsenal. We may add on a trace tool as the next step after that.

Testing Software Radios

2007-02-06T13:27:00.000-08:00

In my visit to the SDR Forum Test Workshop, I observed something interesting. The presentations given by instrumentation vendors focused on verifying the analog and digital performance of the RF subsystem. These vendors all have very nice equipment, such as spectrum analyzers, to do this testing.

However, some of the questions from the audience during the round-table discussion asked about issues that had nothing to do with the RF subsystem. Those questions were about frustrations in testing the software in a software-based electronic system. One question was on how to get a PC to talk to the radio over the Ethernet interface. JTRS radios are typically controlled via SNMP and a user was looking for a toolkit (I found one here) to talk to their radio.

Two other attendees needed to trace a device failure to a software condition such as a stack overflow or a priority inversion, both software bugs that expose themselves as if they are hardware failures. The worst part about these bugs is that they are typically hard to reproduce and can take a long time to track down. This makes them expensive to track down because in test, time is money.

What's A Software Defined Radio?

2007-01-17T16:27:00.000-08:00

RF Test is one of the largest areas of the test market. Somewhere around 1/3rd of all test equipment purchases are for RF test. I've been looking into this market for the past 6 months or so to see we need to be doing in LabVIEW (Desktop, RT, Embedded, FPGA) to better serve people testing RF with the NI platform.

One interesting area of RF development is in "Software Defined Radio". The term is most specifically applied to the JTRS (Joint Tactical Radio System) program in the military but really applies to the way in which radio design is changing. Historically, radios were implemented in "hardware": either in chips from various silicon vendors or in discrete components on a board. You may have bought a science kit when you were 10 to make an AM radio that consisted of a transistor or vacuum tube and some other electronic components.

The design of radios is changing. The first migration was moving the signal manipulations that used to take place in the analog domain to the digital domain. A DSL modem has chips inside that use digital signal processing to convert the analog signal that travels down the copper wire into bits that become Ethernet packets.

The second migration was to perform these signal processing operations in a re-programmable device. When the 33.6 KBit modems came out, they were implemented using "standard" digital signal processors from Motorola Semiconductor (now Freescale), Rockwell, or others. Using a reprogrammable processor allowed the device to support multiple standards or to be upgradeable when new versions of the standard were released. Now, you are seeing the same thing happen with more 'exotic' radios that broadcast in the RF range rather than just ones that transmit over phone lines. The JTRS program envisions a radio that can run more than 30 different standards with the same hardware. These radios use a combination of processors and FPGAs to perform the signal processing needed to pull this off. There is still some very complex analog circuitry in the radio to pull this all off but, as some attendees of a conference I just went to noted, "the bits are getting much closer to the antenna".

Technorati Tags: SoftwareDefinedRadio, Modem, Test, JTRS

Asynchronous versus Synchronous Nodes

2006-09-05T16:16:00.000-07:00

Earlier this year, I wrote an entry about how LabVIEW's data-flow execution semantics works. There's an additional aspect of parallelism in LabVIEW that I didn't talk about: synchronous versus asynchronous nodes. A LabVIEW diagram that has parallelism in it can still appear to run in parallel on a single processor machine. The 55ms ping-pong was an example of that. Here's another example:

The top loop will run and update the indicator with the value of the loop counter while waiting for 100ms, and then repeat. The bottom loop will run and update the indicator with the value of the loop counter while waiting for 50ms, and then repeat.

The LabVIEW diagram used cooperative multithreading. LabVIEW itself didn't go to "sleep" when the top loop tried to wait for 100ms.

Instead, LabVIEW would execute the top wait for 100ms by setting a timer to go off in 100ms. Then, it would look for other parts of the diagram that could still run (like the bottom loop) and run it until that 100ms timer alarmed. When the timer went off, LabVIEW would take control back and finish executing the top diagram. The wait node was called "asynchronous" because it would let the execution system continue even though an operation (the wait) wasn't finished yet.

Well, operating systems have grown up and now we can spawn "threads". Rather than having the LabVIEW execution system use just one thread, we could allow it to use multiple threads. So when LabVIEW tried to execute a node that did block the execution system (we call those, "synchronous"), there might be another OS thread available to get work done.

You may see this when you call some C code that uses the "sleep()" call. The DLL doesn't return so the current thread is blocked but the CPU should be free to do other things. Since LabVIEW has other threads available to it, it will keep executing in the other threads.

So why continue to have asynchronous nodes at all? If you put 500 wait nodes on the diagram, we would in theory have to allocate 500 threads. Operating systems don't like that very much so we don't do that. Instead, we keep the old cooperative multitasking system but augment it by having each diagram use 4 threads. This gives LabVIEW the ability to work with external code that blocks and still have efficient execution for primtives LabVIEW knows about.

Why talk about all of this? Because sometimes we expose this to you and ask you to pick. The VISA read and VISA write nodes expose a property that let you decide whether they are synchronous or not. We even wrote an appnote on it. But, you can't read the appnote without understanding the stuff above, otherwise you'll think that asynchronous means that the node itself will return early. It won't. The setting only affects how LabVIEW internally chooses to execute the node. So why would you pick? In the words of one of our very experienced LabVIEW developers:

Frequently, VISA is used for serial I/O. If you know the instrument has data ready (e.g., you just asked for the number of bytes waiting to be read), a synchronous read will be much faster, since it won't use LabVIEW's execution scheduling mechanisms to poll the I/O.

There you have it.

Dr. T's Identity Management Method

2006-08-22T12:42:00.000-07:00

I've never seen it written down before, but this article from Joel on Software, "The Identity Management Method" really captures what it means to work at NI.

Joel says:

To be an Identity Method manager, you have to summon all the social skills you have to make your employees identify with the goals of the organization, so that they are highly motivated, then you need to give them the information they need to steer in the right direction.

Those of you who came to NIWeek probably heard Dr. T's keynote. Every year, he lays out for our customers where he thinks NI is going. Well, he doesn't just do that at the keynote. He does that pretty much every day. No matter who he's talking to and no matter what the audience, he explains his vision. Sometimes, its the very technical roadmap of the future and sometimes it's the more personal view of the various stakeholders in NI (the employees, our suppliers, our shareholders, our customers). "Sharing the vision" is an important part of our culture. It's nice to see a third party validation of it.

Well I said I wanted feedback...

2006-08-18T10:59:00.000-07:00

So now I know what it's like to be a musician, having to see a review of one of your performances broadcast widely for the whole city/state/world to see. I got mentioned in a Design News article about podcasts.

The first podcast, titled “What is Embedded?” was produced by National Instruments. It featured an interview with Joel Sumner of the LabVIEW Embedded Group. Overall I think the 16:58 minute interview fulfilled its promise, but I found my attention straying at times. Conversely, I found Sumner giving short shrift to some of the more potentially interesting topics.

The title of the post was even worse: "Listen to This Boring Podcast". Ouch. The other podcast she reviewed in the article (from another company) also got panned so at least I'm not alone.

Oh well, that was the first one I had ever done and it was part of the first 4 NI had ever done. I guess I/we have a bit of learning to do before we're the NPR of the T&M podcast world.

So, give it to me straight guys, did it suck? Too long? Right level of detail? Wrong level of detail? We've got a tremendous amount of knowledge locked up in these walls and we're willing to share, we just don't want to put you to sleep.

Technorati Tags: Podcast

NIWeek Recap

2006-08-17T06:55:00.000-07:00

NIWeek is over. Ok, it ended a whole week ago but I haven't made it to the end of my "to do list" so it won't really be over for another week or two. Last year, my team's big project, LV Embedded, launched to great fanfare. This year, another project that I was involved with, the Lego NXT, made it's NIWeek splash. I can't tell you how cool it is to see something you worked on sitting on the shelves of Best Buy or Frys.

You can see a picture of some of the main developers of the software at Dick Swan's blog. He's also got pictures of some custom sensors he's created or run across for the NXT such as a video camera, a Sony Playstation controller, and probes from Vernier. You can see the Lego NXT demo in the keynote videos.

Brian Tyler did a video-blog on the whole NIWeek Experience. I think the most amusing video was an interview with Diya on what it's like to be up on stage in front of 3,000 people doing the keynote. I love the way we throw engineers who actually worked on the products they are demoing up there. It also helps if the demo doesn't quite go as planned...

You have to admit, a DAQ board isn't much of a visual treat. It just sits there like a rock. Not even blinking lights. I think that's caused us to be a bit more creative when it comes to demos. One of the demos this year involved getting a volunteer from the audience to try out a version of the game "Dance Dance Revolution" that had been completely reimplemented in NI hardware and reprogrammed in LabVIEW. The designer of the demo is Roger Dickey, a guy who loves DDR and is in the LabVIEW FPGA team. Here's the video of him competing with the, ahem, victim.

Finally, to all of the people I pestered at NIWeek, I wanted to say thanks. I know all of us at NI get a lot of satisfaction hearing how our products affect what you do every day.

Technorati Tags: LabVIEW, NIWeek, DanceDanceRevolution, Mindstorms, LEGO

Traditions and Testing

2006-08-17T06:30:00.000-07:00

On the LabVIEW team, we love sweet stuff. Heck, all programmers probably do. "The official food of the LabVIEW team" (tm) used to be Oreos but somewhere in the last few years, it became donuts - specifically Krispie Kreme donuts. Every anniversary, birthday, or just for the heck of it yields a "donuts in (some location)" email. A sugar fix is nearly guaranteed every morning.

Another tradition is to do a coding challenge as we enter final testing. LabVIEW is pretty stable at that point and we've gone through the entire testing database a few times. A coding challenge is a good way to make sure everyone is using the product in a "real way" rather than running through some script. We let a developer or group of developers write something, anything they want, in LabVIEW. There are awards given for the program that uses the most new features, coolest, most annoying, etc.. I think I won most annoying a few years ago for using the "new" (at the time) Datasocket feature along with the state machine editor to create a distributed music playing program. Every person who loaded the VI could enter some musical notes which would then be played on every other person's machine. Can you say noisy? "Annoying" was an apt title for that one.

Anyway, my favorite entry was from the LabVIEW 8.0 release. A couple folks got together and wrote a client-server application that would not only notify you of any new donuts but also show a map on the floor of where they were sitting and map a route through the cubes to show you the shortest way to get to the donuts. It had a nice installer and ran in the system tray. Of course it was all programmed in LabVIEW.

So, what are you going to build with LabVIEW 8.2?

NIWeek Sessions

2006-08-01T11:10:00.000-07:00

There are a lot of good NIWeek sessions on LabVIEW Embedded technology. Here's my cheat-sheet

LabVIEW Embedded Birds of a Feather Session - Tuesday 1pm Mezzanine 7 - hosted by me and the LV Embedded engineering team - NOTE - this is not in the conference program
Hands-On: NI LabVIEW Embedded Module for ADI Blackfin Processors - Tuesday 2:15pm, 4:45pm and Wednesday at 1pm
Introduction to the LabVIEW Embedded Development Module - Tuesday 2:15pm
Graphical Design for Multicore Processors - Tuesday 4pm
Design of the New Handy Board for Robotics - Tuesday 4:45pm
Develop Embedded Systems without Embedded Expertise - Wednesday 3:30pm
Prototype to Custom Deployment in Hours - Wednesday 4pm
Developing Optimized LabVIEW Embedded Applications - Thursday 10:30am
Developing LabVIEW Embedded Applications - Thursday 10:30am

I hope to run into some of you at those sessions.

LabVIEW Embedded Chips

2006-08-01T11:09:00.000-07:00

The LabVIEW Embedded Development Module continues to win awards. A demo with the LabVIEW running on a Freescale ColdFire processor at the Freescale Technology Forum won "Best In Class Development Tools" by a panel of 4 industry folks. Wow.

So that brings me to some interesting trivia. I made a list of the various places that the LabVIEW EDM has run on (that I know about). Some are silly, some are amazing, but I find all of it cool

A Linksys WRT54G Router (Broadcom MIPS/Linux) - my first little project. It did everything, build, run, debug and even TCP/IP I/O. I got it to control a GPIB-Enet box and a scope.
Intel IXP425 Eval Board (Intel XScale 425/VxWorks) - one of the shipping examples
Axiom CMD565 (Freescale PowerPC 565/eCos) - one of the shipping examples
Axiom CMD565 (Freescale PowerPC 565/VxWorks) - one of the shipping examples
Axiom CMD566 (PowerPC 566/VxWorks) - This board has Ethernet so we use it for training
Xilinx ML403 Eval Board - (PowerPC/VxWorks) - This was demoed at NIWeek last year. It uses the PowerPC hard core inside a Xilinx Virtex II Pro.
Embedded Planet EP405 board - (PowerPC405/Linux) - This was in the embedded planet booth at NIWeek last year
Freescale HC08 Eval Board (HC08/no os) - One of our engineers did a power window controller for a car door. He integrated the Freescale ProcessorExpert for I/O and had it all working in a couple k of code (2k?). It didn't debug, do any arrays, or anything fancy but it was neat to see how small we could go.
Freescale HC12 Eval Board (HC12/no os) - Look for this at NIWeek this year. Get some M&Ms in the process
Altera NIOS II Dev Kit - (NIOS/eCos) - NIOS is a soft processor that runs in an Altera FPGA
Phytec LPC229x (ARM7/eCos) - A new example target
TI DSK6713 (TI TMS320C6713/DSP BIOS) - A university professor tried it first but we went and did it again as a new example target for those of you who want to program a DSP
Nintendo Gameboy (Linux) - this was the robot from Charmed Labs that you saw on stage at NIWeek two years ago.
PC Motherboard (80486/QNX) - your standard PC, but running the QNX operating system. It even can support an M-series DAQ card. Look for it in an NIWeek presentation.
A Linksys WRT54G Router (Broadcom MIPS/Linux) - my first little project. It did everything, build, run, debug and even TCP/IP I/O. I got it to control a GPIB-Enet box and a scope.
Intel IXP425 Eval Board (Intel XScale 425/VxWorks) - one of the shipping examples
Axiom CMD565 (Freescale PowerPC 565/eCos) - one of the shipping examples
Axiom CMD565 (Freescale PowerPC 565/VxWorks) - one of the shipping examples
Axiom CMD566 (PowerPC 566/VxWorks) - This board has Ethernet so we use it for training
EP405 (PowerPC405/MontaVista Linux) - Same board as before but running MontaVista Hard Hat Linux rather than the non-deterministic standard Linux distro.
PC Motherboard (80486/MontaVista Linux) - Once you have Linux running, LV Embedded works pretty well on any CPU.
Freescale MCF523x (Coldfire/no os) - A customer wanted to give this a try
Freescale MCF5329 Eval Board (ColdFire 5329/uCLinux) - The winning demo at Freescale Technology Forum.
Freescale 5200LITE (PowerPC/Linux) - A customer had one of these kicking around to try.
Renesas SH7751 (SH4/QNX) - another experiment with our friends at QNX
Atmel ATMega 128/no os - Details are sketchy but an academic customer put this together and is writing a paper on it.
The Bluetechnix tinyboard, the HandyBoard, Scmidt Engineering Z-Brain, and the ADI EZ Kits using the LabVIEW Embedded Blackfin module.

Whew. I'll bet there are others kicking around that I forgot or I don't yet know about. The breadth is fantastic, from 8-bit to 32-bit. From no-os to Linux.

Doings

2006-08-01T10:23:00.000-07:00

I know I've been a bad blogger and left you hanging for the last three weeks. It's only two weeks in work time due to a week long vacation in Prague in the Czech Republic. Prague is a beautiful city that was not bombed during World War II. You see interesting adornments on the building wherever you go. Everything is cheap by European standards. It was easily half the price of a vacation in London.

But I digress.. Last week was the Design Automation Conference. That conference is for people who make computer chips, the kind that take 10 weeks to bake in the fab before you get them back. It's a completely different world where they have to simulate everything up front because there is no possibility of even doing a component level prototype in the real world. Imagine it costing you a million dollars to fix a bug that you found in your code after your first build. That's the world they live in. However, it is an analog world at the bottom of it and LabVIEW does provide ways to help validate those designs, both in the simulation world and once the chip comes out.

NIWeek is coming

2006-07-11T11:03:00.000-07:00

In four weeks, NIWeek will be here. A post on the LAVA blogs has some good ideas on how to get the best out of NIWeek.

If you spot me at NIWeek, stop by and say hi. I'd love to chat about Embedded, FPGA, PDA, DSP, and other LabVIEW stuff (assuming I'm not already late to something). If you want to play "where's Joel", I'm publishing my NIWeek Calendar. Drop me an email if you want to chat and I'll try and set something up as my schedule firms.

See you there

Mourning the passing of LabVIEW Technical Resource

2006-07-10T13:45:00.000-07:00

This isn't particularly timely but I wanted to belatedly express my gratitude to Karen Pape from the "LabVIEW Technical Resource" magazine. They closed their doors last year and their site no longer works. It was a great, no advertisements, periodical jam-packed with LabVIEW techniques from experienced LabVIEW developers. If you ever run across a copy laying on someone's desk, pick it up. You'll probably learn something.

You can still find some of the articles floating around the Internet.
* NI's site has some articles. Go to DeveloperZone and search for "labview technical resource"
* There is a CD for sale with 9 years of articles
* Many articles have been mirrored on the sites of their representative authors

Language Challenges for Multi-Core Processors

2006-06-13T15:26:00.000-07:00

In Jim Turley's recent Silicon Insider, he talked about multi-core processors.

But new compilers and debuggers won't be enough. We're facing a change to new programming languages. Current languages like C don't express parallelism well. Compilers can identify threads of execution or independent constructs and extract some small amounts of parallelism here and there, but the language itself prevents large-scale parallelism. If we're to exploit these new multi-processor chips, we're going to have to swallow hard, roll up our sleeves, and tackle a truly Herculean task.

Hmm. Languages that express parallelism well. I wonder where I can find one of those?

Technorati Tags: Parallelism , Multicore