LabVIEW from National Instruments (NI) is a renowned PC-based instrumentation system, specialized in signal analysis and measurement. LabVIEW became available on the Windows PC platform in 1992.
Since then it pervades the academic world, generating plenty R&D applications as spin-offs.
Many universities and tech schools impose LabVIEW tutorials to their students.
Back in 1992, an average PC was clocked at 33 MHz or so. One year later, thanks to the first i486 cores clocked at 3 times the external bus speed, the Windows PC performance got a big boost – when running on cache. Back in those times, a PC was capable of playing sound, but was incapable of processing it like applying filters in realtime or doing a short FFT in real time. Winamp (the famous MP3 player) came five years later, in 1997, only running smooth on PCs powered by Pentium II processors (233 MHz and above).
In such context, came the idea of adding a DSP sub-assembly to the PC, managed from within LabVIEW. Most of the time a PCI slot was used to connect the DSP board.
Just to give an idea, back in 1992 the Atari Falcon had a Motorola 68030 CPU (16 MHz), a Motorola DSP56001 (32 MHz), and an optional Motorola 68882 FPU, all on a single motherboard without any daughterboard.
The LabVIEW approach, adding a DSP board on PCI needed to be significantly more powerful than the Atari Falcon used and abused by music experimenters.
As consequence, most DSP boards designed to be compatible with LabVIEW were relying on powerful DSP chips like Analog Devices SHARC, helped by vast amounts of fast local RAM on-board. In such context, LabVIEW gained a solid reputation.
A few years later, PCI went replaced by USB2. NI is currently listing the following external DSP boards, dealing with Digital Audio:
There are other possibilities like miniracks, where you can plug a DSP-based module. On NI website, there is question of a module featuring a FPGA, of course reprogrammable, to be used as digital filter. 
LabVIEW is still evolving. We are in the GHz-class Windows PCs era. We have fast interfaces like USB2. Nowadays, for processing audio, everybody would say that an external DSP is not required anymore. National Instruments would reply to you that if you do so, you depart from the NI philosophy. The NI philosophy is to decouple the PC, only asking the PC to measure, analyse, and graph signals. Of course they need continuing selling their own ADCs and DACs instead of allowing you to connect any Audio-USB gear supported by a MS Windows driver, or ASIO.
Imagine what would happen if NI allows connecting standard USB-audio devices. Imagine a Windows PC equipped with a motherboard having an HDAudio 7.1 chip on board. Can LabVIEW access it ? Read the S/PDIF-in ? If this is not the case, what about attaching a 7.1 USB-audio box like the Sweex SC016 ? Or any other 7.1 USB audio gear ? Possibly 24-bits and 96 kHz ? Are there examples, or is it impossible because of the philosophy ? Ask a NI dealer …
Propelled by my DIY Audio tropism, I went looking on NI website, and I found no NI board dealing with S/PDIF-in. I could find a few ADC boards designed for audio, to connect on a PC using USB. However I could not find boards featuring 8 high quality audio outputs.
Or yes, you can deliver multichannel sound, but it becomes a completely different project, with NI LabVIEW acting as DSP compiler, sending code to a target board hosting a DSP, feeding a multichannel Codec.
Introduced around year 2005, LabVIEW DSP module is an all-in-one package easily purchased by academic environments. There is also question of a Digital Filter Design Toolkit. Reading the description, you realize that such software package is again designed for sending DSP code to an external target, as rapid prototyping tool, with the possibility to recompile for other targets.
Clearly, thanks to the expertise gained with external DSP hardware, LabVIEW has also become a DSP programming tool, aiming at rapid prototyping. If you target a particular application (like a sound cancellation system for a car maybe), using LabVIEW you can try many different algorithms on a DSP target board (Analog Devices SHARC and T.I. C671x seem to be supported). The important point here is that you can persuade LabVIEW to keep an eye within your DSP application, like graphing internal signals using various modalities. Currently, you need a USB2 connection between the target and the PC for streaming the digital data to the PC. But wait a minute, do not confuse this with a normal USB-audio link, multichannel. I bet LabVIEW is using a special protocol, carefully designed to remain incompatible with off-the-shelf USB-audio gear, a special protocol carefully designed to force you to obey the philosophy.
Actually, something really interesting is happening within NI (National Instruments).
There are clues that NI is going to introduce something radically new on the market (possibly named SocVIEW) allowing you to graphically design signal processing software for ARM Cortex targets, still relying on LabVIEW for graphing signals, even if they are embedded in the SoC.
As prerequisite, you need Keil ULINK-PRO.
Your target board gets loaded and eventually Flashed by Keil ULINK-PRO like if you were running Keil µVision IDE, and pressing the buttons. The link on the UNLINK-PRO is the Cortex Debug+ETM squatting the good old 2 x 10 pin 0.10 inch JTAG connectivity. This way the PC running LabVIEW gets access to your internal signals, with Keil ULINK in between. The target remains lightweight and low cost. The target doesn’t even require USB, from Keil and NI perspectives.
Keil ULINK-PRO, quite old now, is not obeying the most recent ARM specification. It uses the JTAG connectivity, with the 0.10 inch pitch.
ARM specifies the Cortex Debug as a 2 x 5 pin mini connector featuring a 0.05 inch pitch
ARM specifies the Cortex Debug+ETM as a 2 x 10 pin mini connector featuring a 0.05 inch pitch
With the +ETM variant comes the possibility to stream the instructions at very high speed. This enables auditing the full instruction sequence, off line. This is not used by NI for graphing a signal.
All ARM Cortex chips feature Debug Modules inside. Tomas Hedqvist (IAR Systems) did a great job in explaining how any ARM Cortex-M4 (or M3) manages to stream data out of the chip using the Cortex Debug (2 x 5 pin), without impacting the application.
Tomas Hedqvist (IAR Systems) : ”The Instrumentation Trace Macrocell (ITM) is a central part of the debug logic. It is a lightweight trace that provides selected trace data over a low speed access port. The good thing is that you do not need the Cortex Debug+ETM probe (20 pin) to use it, most Cortex Debug (10 pin) probes can handle the trace functionality available in the ITM. So, what do we mean by a lightweight trace? In itself, the ITM provides 32 channels for software trace that can be used by the software to generate packets to the ITM for distribution to the debugger over SWO. This can be used for instrumentation of the code with very little overhead as the core does not need to stop to output the message or data. All that is needed is a single write operation to one of the 32 ITM stimulus registers. The ITM also takes care of trace events triggered by another unit, the DWT. The role of the ITM in this case is to format these events and packetize them. Optionally it can also timestamp each package it sends away.”
Basing on this, NI (National Instruments) adds value to your prototyping job in two crucial areas :
- SocVIEW is the graphical DSP compiler, sending automated source code to Keil compiler, executed by the ARM.
- LabVIEW is the signal plotter, with some processing done by the PC before actually plotting.
Deeply embedded signals can be graphed because LabVIEW communicates in realtime with SocVIEW.
At the moment, we are talking about no less than 260 different microcontrollers in the ARM Cortex-M3, ARM7 and ARM9 families. The Cortex-M4 family should be added on the list now, and the Cortex M0-plus (still to be launched) will follow. Within a few month, this will form a panel of nearly 1,000 microcontrollers coming from nearly all silicon vendors, clocked from 40 MHz to more than 1 GHz. Asymetric dualcore chips like the T.I. Omap and Sitara families (featuring an ARM Cortex-A8 and a C671x DSP inside) will be on the list. This way you still can access a T.I. C671x DSP. Worrying about the Analog Devices SHARC.
Keil, recently acquired by ARM, is sitting on top of a tremendous market with LabVIEW.
A low cost debug probe like the Keil ULINK-ME (with the new 2 x 5 pin 0.05 inch Cortex Debug connector) may work also, albeit not featuring the extra fast data streaming capability. In such case the debugger cost is lower than $50. China entrepreneurs are on the starting blocks, ready to produce copies at $30 each. Now that Keil got acquired by ARM, I guess that ARM does’t care about counterfeit ULINK-ME and ULINK-PRO. All they care is to sell ARM architectures to silicon vendors. For remaining appealing, they need to display inexpensive debug tools that can be reused on many different microcontrollers. Provided Keil gets financed by ARM, they will maintain their position as leaders in ARM debug probes and IDEs. China may mass-produce copies of the debug probe. No impact on Keil income I guess. The more debug probes in circulation, the best for ARM. The essential for Keil it to maintain the quality of the ULINK debug probes, get them updated, maintain the µVision IDE quality, while supporting more ARM processors, from more vendors. Which could ask for regular firmware upgrades in the debug probe. That a China-made counterfeit probe may not accept. Better stay away from them would you say. Peace.
On the above picture, NI is only displaying the Keil ULINK debug probe. Currently there are other ARM Cortex-M4 debug probes available from other vendors like Segger J-Link, IAR J-Link, CodeRed RedProbe+, etc … Currently they all feature the old 2×20 pin 0.10 inch pitch connectivity dating back from the JTAG era. There should be revised models coming, extremely low cost (say $99) when outputting the genuine Cortex Debug (2 x 5 pin 0.05 inch), and a little bit more expensive (say $199) when outputting the genuine Cortex Debug+ETM (2 x 10 pin 0.05 inch pitch). Worth keeping in mind is that none of them feature galvanic isolation between the target and the PC.
Did you know about the NXP LPC4330 ? This is NXP first Cortex-M4 family member. Now it gets really available.
Consequently, we now have the NGX Technologies LPC4330 Xplorer. This is an interesting LPC4330 carrierboard.
This can serve as mySCP, a student-owned SoC Prototyping.
Like myDAQ on the NI catalog, a student-owned Data AcQuisition. Just an idea.
There is an onboard stereo Codec, fully wired thanks stereo cinch-in and stereo cinch-out.
The 2 x 27 pin header allows routing many SGPIO for emulating a 4-lane I2S. We’ll try hooking an external multichannel Audio Codec like Wolfson WM8580 or WM8581.
From a diyAudio perspective, I fundamentally adhere to NI philosophy. With the availability of the NGX LPC4330 Xplorer priced $57, equipped with the latest NXP LPC4330 chip featuring a 204 MHz Cortex-M4, a Cortex-M0 as coprocessor, an on-board stereo Codec, I can start experimenting with audio. Without introducing a PC in the loop, apart from letting him compile the software naturally. This makes me both happy and confident.
From a diyAudio perspective, I woud only sleep on my two ears after having checked the source code generated by NI SocVIEW. You better do so in case you are prototyping DSP software to be used in cars, planes, lifts etc. What’s NI attitude about this ? Will they allow this ?
