LabVIEW Embedded

cancel
Showing results for 
Search instead for 
Did you mean: 

Can LabVIEW Embedded for ARM work with any board or just with the few predefined?

Solved!
Go to solution

LabVIEW Embedded – Performance Effect of Adding a Second Loop

 

The following tests use LabVIEW Embedded compiler options selected for maximum execution speed. It has been identified that the compiler options that give the best speed performance are as follows:

 

Enable debugging: off

Generate guard code: off

Disable parallel execution: on

Use stack variables: on

Enable expression folding: on

Generate C function calls: on

Optimize for time: on

Enable cross-module optimization: on

Optimize heap size: on

Use MicroLib: off

 

Testing

 

Test 1 performs some mathematical operations as show below:

 

Test 1.png 

 

Using the abovementioned compiler options, 1000 loops take 134 ms.

 

Test 2 splits the single loop into two parallel loops such that the total operations are identical as shown below:

 

 Test 2.png

 

Due to “Disable parallel execution” being turned off, the compiler options “Use stack variables”, “Enable expression folding” and “Generate C function calls” are no longer available. The effect is that the 1000 loops now takes 718 ms. That is, 5.4 times as long.

 

Performance

 

So, moving from single loop operation with the best compiler options for speed to dual loop operation with the best compiler options for speed results in a 80% loss of performance. So, the 60 DMIPS ARM Cortex M3 processor is now effectively a 12 DMIPS processor (this puts it below some 8 bit processors – a PIC18 can do 16 DMIPS!).

 

Where is the Performance Going?

 

So, where is 80% of the CPU capacity going? It would appear that certain parts of the operating system that allow multi threaded operation are adding an overhead.

 

Implications

 

Using typical LabVIEW programming techniques rob 80% of a 50 MHz ARM Cortex 3 processor (LM3S8962 Evaluation Board). The question is, is there a constant 48 DMIPS load (in which case all is not lost) or is it a percentage of CPU resources? It would be logical to assume it is a constant load. If so, moving to say a processor with 256 DMIPS performance would result in 208 DMIPS of useable CPU resource versus the 12 DMIPS available with current Tier 1 development boards. That is a 17 times increase in application performance!

 

The MCBTMS570 Development Board ( www.keil.com/mcbtms570 ) offers 256 DMIPS of power versus the 60 DMIPS currently available.  The MCBTM570 board runs Keil RTX OS, so it should be relatively easy to establish a Tier 1 board. From what I understand it would only take NI about 2 months to create such a Tier 1 board. This would be a breath of fresh air for LabVIEW Embedded for ARM programmers and inject new life into the product. I can guarantee additional LabVIEW Embedded sales.

 

The way forward

 

LabVIEW Embedded is a great concept. Unfortunately there are only 2 Tier 1 boards and their performance makes them only marginally viable. And no new boards have been introduced for over 5 years. There are much more capable development boards now available. Ideally the MCBTM570 Development Board would be introduced now and a new Tier 1 board introduced every 2 years. This would keep LabVIEW Embedded for ARM viable and make it an attractive proposition.

0 Kudos
Message 21 of 21
(3,343 Views)