Survey: LabVIEW Embedded experiences

[vitoi]

My work colleague and I have been evaluation LabVIEW Embedded for ARM for an upcoming project. I’ve got two days left in the evaluation period!

Personally, I’ve found it very easy to use (as expected from LabVIEW ). However the current Tier 1 boards, when used with LabVIEW Embedded, are pretty lacklustre in performance.

My question to the LabVIEW Embedded community is, what do you think of LabVIEW Embedded?

Specifically:

1) Did you only get as far as evaluation LabVIEW Embedded?

2) How many projects have you done with LabVIEW Embedded?

3) Are you still using LabVIEW Embedded?

4) If you switched from LabVIEW Embedded, what microcontroller development environment are you using?

5) If you switched from LabVIEW Embedded, what microcontroller development board are you using as a base?

6) If you had free reign to use any development environment and microcontroller development board, what would you use?

I’m also interested in how many active LabVIEW Embedded programmers there are. Is LabVIEW Embedded being used by a dozen people or hundreds of people? I’d really like to know!

So, if you’ve ever used LabVIEW embedded, even just to have a look at it, I’d be interested to hear your comments.

[Peter_B]

Does anybody actually read this LabVIEW Embedded forum ?  I'm beginning to wonder if LabVIEW Embedded for ARM (LVEA) is actually used by more than a handful of people.  Community support is an important factor when deciding to adopt a new development environment.

[Scott_A]

Hey all,

I know I've worked with a large number of users of LabVIEW Embedded for ARM, I'm not sure why more of them are not posting on the forums.  I tend to see a good mix of applications in Academia and Industry.

Anyway I hope you get some more responses to your questions and good luck on your development!

[Peter_B]

Hi Scott, thanks for chiming in.

Could you give me an idea roughly how many people (either in the US or around the world) would be actively using LVEA ?  Or if you don't know that, then roughly how many LVEA licenses would NI sell per year (not incl. the evaluation kits).  Is it in the tens or the hundreds ?

I'm currently evaluating the MCB2300 board to see if LVEA will meet our needs now and in the future.   I'll probably start another thread with my findings.  

One main concern I have is that NI haven't invested any R&D into new Tier 1 boards in the past 5+ years.  Five years is a long time in this industry as things change/improve so rapidly.  Without continued R&D in a product, it will be more and more fruitless for me as an Engineer to invest my time and my company's money pursuing something without much of a future.  The sbRIO offers nowhere near the kind of flexibility a fully custom design would using LVEA.  It also can't be purchased in small quantites.  As I wrote in this thread,  I think both products can co-exist without NI fearing LVEA will cannabilise the RIO family to NI's detriment.

With NI's current strategy, how many LabVIEW programmers wanting to progam uCs might you lose to other dev environments like the .NET Micro Framework for example ?  That is open source and very current.  As much as I love graphical programming, the Dev Environment making the most business sense to me is probably not LVEA..

rgds

[vitoi]

---

@Scott A wrote:

Hey all,

I know I've worked with a large number of users of LabVIEW Embedded for ARM, I'm not sure why more of them are not posting on the forums.  I tend to see a good mix of applications in Academia and Industry.

Anyway I hope you get some more responses to your questions and good luck on your development!

---

Scott, I suspect that the problem is that although LabVIEW Embedded was introduced over 5 years ago, no new Tier 1 boards have been introduced in over 5 years. Lot's a long time in the microcontroller world. Many modern and exciting microcontroller development boards cannot be used with LabVIEW Embedded.

Also, 80% of the CPU is consumed in LabVIEW/OS overhead. There’s not many MIPS left over to do something truly useful with. Assuming a constant overhead, just using a new modern microcontroller with twice the MIPS could give 6 times the performance.

So, although there may have been a flurry of activity with LabVIEW Embedded a few years ago, the lack of progress has probably dissuaded people. I doubt many are using it actively at the moment. There is activity here from people using the evaluating software, but very few seem to go on and use it for real development.

My own evaluation of LabVIEW Embedded has been frustrating. I’m trying to persuade NI to introduce a new Tier 1 board, but that does not look promising.

From the response to my question here, I assume there currently are less than 10 people actively developing with LabVIEW Embedded for ARM.

Imagine how many people would be using it if a new Tier 1 board was introduced now and a new one every 2 years.

[w0utje]

Hi there,

I am working with LabVIEW for ARM for over 2 years now.

I've did multiple projects with it.

The main goal of LabVIEW for ARM is to generate code that you can easily develop with LV, therefor the Tier 1 devices are present.

You can use LV for ARM with other microcontrollers, but then you've must spend more time on developing the targets for LV.

Since the documentation is not very usefull about creating a target, this is a big step to do.

I think that LV for ARM is very usefull to quickly develop an embedded application that is not too big.

If you want to develop bigger applications, you must notice that LabVIEW for ARM has a very big overhead of LabVIEW code.

I've created two targets for LabVIEW for ARM.

- LPC1758

- LPC1788

Basicly I've all my peripherals working, with LabVIEW code like:

- UART

- SPI

- I2C

- ADC/DAC

- Watchdog

- GPIO

- Ethernet (in LabVIEW and TCP stack of TCPNet, HTTP server, TFTP server, UDP multicast)

- Interrupts (in LabVIEW)

- External memory controller (also to place the stack/heap of LabVIEW on the external RAM)

- SDcard ( MCI driver)

- USB (CDC serial and mass storage device)

I also managed to make my own bootloader that can flash and run my LV for ARM applications on an random address.

You can do a lot with LV for ARM.

The only thing you have to do is to understand how LV for ARM works. (look at the C code in KEIL uVision)

LV for ARM expects some functions to work with.

for example the UART vi's:

you can look in a target at ARM_Serial.c

My opinion is:

If you've been creating a target yourself,

you can create a target for every supported microcontroller in KEIL uVision.

Also there are some bugs in LV for ARM and RL-ARM library's

Like the UDP 55 ms wait, Vitoi knows what I mean 😉

LV for ARM won't get new features, maybe some bugfixes.

But at this moment you can do a lot with LV for ARM, so it won't be necessary.

If you wan't to develop LV for ARM for devices that are not supported by KEIL uVision (standard) you won't have support by NI.

KEIL uVision can be used for ARM7, Cortex-M and Cortex-R, but not for Cortex-A

I don't know if you can make it work for Cortex-A in some way...

Maybe you can use the eclipse feature of LV microprocessor SDK (but this one is dead)

last but not least:

In LV for ARM you must know what you can and what you should not do.

Just know what you do when programming for ARM.

[akonni]

We actually purchased a copy of the LV for ARM, and has pretty good experience with it.  We have a fairly complex project using 2 LM3S8962 targets, that controls multiple actuators, pumps, heater, stepper motor, dc motors and etc.  We definitely struggled a bit to get some of the features working, especially the CAN interface.  But once we figured out the tricks, the LV for ARM works very well.

I would recommended reading the RL-ARM library from Keil, as that's where LV got the libraries to implement the LV for ARM code.  After reading the Keil documentation, the LV for ARM definitely makes more sense.

We also ditto on the lack of new tier 1 board.  It would be great if NI can support newere microcontrollers such as the Cortex M4 (LM4F230 series).

[vitoi]

Hi w0utje and akonni,

It's great to finally get a response to my survey. Together with JohnGrove, you two are the only people that I know of that are using LabVIEW Embedded for ARM. Do either of you know any other users?

My current estimate is that there are less than 10 current active (non-academic) users of LabVIEW Embedded for ARM worldwide. I’ll revise that estimate as time goes on.

w0utje, you appear to be the most advanced of the users, having done a Tier 1 port to the LPC1758 and LPC1788. These are interesting microcontrollers since they have about double the processing power of the current two Tier 1 targets from NI. I have a couple of questions for you if I may:

1) Roughly how many days did it take you to do a “Tier 1” port for the first target you did, including elemental I/O and the peripherals?

2) I notice that for the LM3S8962 that when I enable parallel loop operation, I lose 80% of the CPU resources. I’m hoping that any LabVIEW/RTOS overhead is fairly constant in which case the LPC1758 should operate about 5 times faster than the LM3S8962 for purely computational multiple loop operation despite it only having a twice as powerful a CPU. You can see the timing VIs I used in this post http://forums.ni.com/t5/LabVIEW-Embedded/Can-LabVIEW-Embedded-for-ARM-work-with-any-board-or-just-wi... What sort of effective processing power decrease are you seeing under dual loop operation (80% or 50%)?

My work colleague, Peter, and I are looking into what embedded programming environment we’ll use for out next project and for our future developments for the next 5 or so years. We are looking at:

* Microcontroller development using LABVIEW Embedded for ARM using a Tier 1 board

* Microcontroller development using LABVIEW Embedded for ARM ported to a more powerful board

* Microcontroller development using .NET Micro Framework (C# and open source)

* Microcontroller development using one of the free IDEs from NXP or Texas Instruments (using C)

* LabVIEW RT and LabVIEW FPGA on a sbRIO

* FPGA development (soft 32 bit micro + peripherals on a single FPGA) using open source tools

* FPGA development (soft 32 bit micro + peripherals on a single FPGA) using IDEs from Xilinx or Altera

So we’re considering solutions using microcontrollers and/or FPGA from National Instruments, device supplier and open source development tools. All options are possible at this stage. They all have their advantages and disadvantages.

We are willing to spend some time on this since it will set the scene for our future developments for the next 5 years. One thing’s for sure, regardless of which way we go at work, I will learn an alternative during my spare time at home (fortunately my work is also my hobby!). I think we should also commit to learning one of the alternatives at work as a backup. This way, not everything will look like a nail 🙂

Regards,

Vito

[akonni]

Hello Vitoi,

I am sure there are definitely many more users of LV ARM.  Most users simply don’t post on discussion forums.

Here is a few of my takes on LV ARM.   As for degraded performance with parallel loops, microcontrollers are designed to be single-threaded.  If you run parallel loops, you gonna get hit in performance as the RTOS has to switch context to execute different threads.  Google “context switching ARM Cortex” and you can find out the overhead of switching threads.  As matter of fact, for many embedded developer, it is a tricky business to tweak RTOS to run different parallel loops.  We have to give LV ARM credit for making it so easy to implement parallel loops, although at a high performance cost.  Also, if high through put parallel processing is your goal, then DSP or FPGA might be a better design choice than ARM microcontroller.

As for performance goes, since those LM3S8962 costs only $11 a pop, why not have a bunch of them?  We already use 2 of them in our system, connected by CAN bus.  I think with LV ARM CAN VI, you can chain up to 32 of them.  32 of those ucontrollers would probably be enough for your performance requirement.

Also, there are a lot of tricks in LV ARM that can boost performance by a huge margin.  For example, 1) use interrupt-driven to read an IO pin, instead of polling, 2) calling Stellaris function directly using in-line C-code, and many more. 

As for choosing an IDE and platform, we are happy with NI and its software/hardware.  But it is a bummer that we are not sure about future support and development of LV for ARM.   But at same time, NI is not the only game in town for rapid prototyping embedded code.  I talked to a local engineer who designed aeronautics, and they are using Matlab for automatic embedded code generation.  Furthermore, they can get Matlab generated C-code to pass software certification for aeronautics.  I guess if NI doesn’t step up its effort of LV for ARM, we might move our embedded development to Matlab, while keeping LV for user interface.

[vitoi]

Hi akonni,

LabVIEW Embedded for ARM developers must be a shy bunch :-).

I have previously had a look at articles on the web regardign RTOS context switching and they only talk about a loss of a few percent of the CPU power. They do talk about some poor settings consuming up to 50%. I’m seeing 80% loss!

I wonder if NI have chosen RTOS setting for maximum determinancy at the sacrifice of performance and gone too far. We can live with less determinacy, if we can get more power.

The big question is, is it a constant load (therefore move up to a 100 MHz processor to get 5 times the performance) or proportional (in which case all its lost).

We are already considering using two microcontrollers to get the job done. Even then I will probably spend much more time trying to get the code to the required performance rather than the actual coding. Also, if I show the other engineers my LabVIEW solution with a dozen or so microcontrollers for my handheld device, I’ll be laughed at! Not a great advertisement for LabVIEW Embedded.

Thanks for the performance tips. If I go LabVIEW Embedded for ARM I'm going to need all the tips I can get my hands on.

Matlab sounds interesting and I’ll take a look at it. The good thing is that we Matlab, .NET, C#, C, FPGA, embedded, etc experts in the company so I know I can get lots of support no matter which direction I take. I agree that other solutions are worth looking at the embedded end with LabVIEW for the desktop user interface (A bit like what happens with LabVIEW + Arduino).

Anyway, I’ll continue my search for an embedded development system with sufficient power, ease of use and popularity for our proposed hand held instrument. Keep in touch.