Can LabVIEW Embedded for ARM work with any evaluation board or just with the few predefined (MCB2300, MCB2400 and EK-LM3S8962)? I ask this because even if I choose "another processor" when defining the new project the only 3 options are the corresponding ARMs from Phillips and LuminaryMicro.
Thanks in advance,
Solved! Go to Solution.
additionally, does the uProocessor SDK "cover" ARMs as well in the newer LV versions (2009+)?
LabVIEW for ARM supports the Tier 1 targets functionality (the evaluation board to mention) following this outline:
But you can port over many other ARMs if you follow this porting guide:
The uProcesser SDK is meant to port to other non-ARM targets (32-bit, of course) and technically does cover ARM as well. Alternatively, there is the LabVIEW C Code Generator: http://sine.ni.com/nips/cds/view/p/lang/en/nid/209
Thanks for your reply.
My colleague and I are evaluating two Tier 1 LabVIEW embedded evaluation kits (Cortex-M3 and ARM7). We are putting them through their paces to see if they can meet our requirements. It has been touch and go as we discover how to optimise the code and the compilation.
It would be great if it proved relatively easy to port to any ARM9 or even ARM11 architecture (using the guide you linked to here http://zone.ni.com/devzone/cda/tut/p/id/6994
So here are my questions:
We would support you with targetting a Tier 1 or Tier 2 device. In terms of adapting a Tier 1 device to a Tier 2 device, it may be more difficult to port. We have VIs that implement a lot of functionality in Tier 1 devices such as I/O, communication buses, device interfacing. If you wanted to port to a Tier 2 device, you would have to have enough knowledge of the functionality and ARM hardware to rewrite the functionality. Porting to different ARM families shouldn't be any more difficult if it's a Tier 1 device.
Other problems with porting to another ARM microcontroller would be dependant on whether or not the a RTX Real-Time Kernel and Real-Time Agent module already exists for the device. If it does, then you can follow this procedure. Otherwise, you'll have to follow the porting guide, where it will be more difficult to port.
To clarify Che's post:
First and foremost you need to make sure that your target supports the RTX operating system. A List of supported devices can be found here:
If your device does not currently support the RTX operating system you would have to port the OS to your hardware. NI offers no support for this since we do not make the OS or the hardware.
If your device already supports RTX, but is not one of the Tier 1 devices you can follow the porting guide to use the device with LabVIEW Embedded for ARM.
The porting process basically involves telling the Keil Tool Chain and LabVIEW how your device's peripherals work. Porting to an ARM target can be challenging and you will need to know a lot of information about your hardware (but everything should be available in the devices data sheet).
When porting it is up to you how much functionality you want to implement. At a minimum you will have to setup the Keil tool chain to work with LabVIEW and your target. You can decide if you want to implement all of the boards peripherals or just the ones you need, so its hard to give an estimate of how long the porting process will take.
I would say if you are comfortable with LabVIEW and have experience with the hardware (ie already used it and many of its peripherals in C) the porting process may only a day or two. If you have never used the hardware you will have a bit of reading ahead of you and could spend many days depending on your embedded systems / microcontroller experience level.
Sorry I couldn't give you a definite answer but I hope this helps.
HI Che and Sam,
Thank you for your replies. It puts the porting process in perspective for me.
It appears that micros in the following family do not run the Keil RTX OS (well at least they can't be programmed using the Keil MDK).
ARM10, ARM11, Cortex-A5, Cortex-A8, Cortex-A9, & Cortex-A15
Ideally we would like to port to a Cortex-A8. and configure access to a QVGA display,USB,TCP/IP, A&D in/out. Is that even possible to achieve in a reasonable time frame (say 1-2 weeks) assuming somebody with the right skills did the job and they had access to all the necessary documentation ?
The Cortex-A8 supports high level OS such as Linux, Windows CE and Android. Would it be simpler just to purchse LaVIEW for Linux to achieve this ?
If LabVIEW Embedded isn't easily able to be ported to the recent and latest generation micros, what is the product road-map for LabVIEW Embedded to prevent it fading away ?
Unfortunately, there are no plans to add support for the Cortex-A8 to LabVIEW for Embedded for ARM. Our technology is built for the lower-end Microcontroller class of processors, and we use the Keil tools and the RTX operating system as the base of LabVIEW for ARM. Neither of these support any A8 processors.
In addition using the desktop version of LabVIEW on the Cortex-A8 device is not an option because LabVIEW for Linux currently only supports x86 architecture.
Please let us know if you have any other questions about the options for your project. If you prefer to speak directly with an engineer I suggest creating a service request through www.ni.com/support and reference this post.
Thank you Sam. We will probably now identify a suitable ARM9 chip supported by Keil. We might even use a couple of them in the one product if necessary
What is on the product road-map for LabVIEW Embedded to prevent the current offering becomming more and more obsolete ?
At this point we are still supporting LabVIEW Embedded for ARM but we do not have a defined roadmap for future development. Since we depend on the RTX operating system and Keil toolchain we will support any ARM targets that Keil supports RTX on.
Since the future of the product is uncertain at this point we tyically offer the following guidelines:
If the current features of the module meets your needs and you are working on a relativly short term project (~1 year) we recommed using LabVIEW Embedded for ARM.
If you are working on a long term, multi year project, or the current features of the toolkit do not meet your needs we can suggest alternatives (hardware and/or software).
One option for an alternative would be the LabVIEW C Generator to generate arbitrary C code from a LabVIEW Block Diagram. This C code can then be included in any C project in any IDE.
Alternatly for hardware alternatives we generally recommend the Single Board RIO.
The more we know about your application the better we can advise you. I highly recommend you create a service request with our applications engineers via ni.com/support to discuss your options.
Please let us know if you have more questions for us. We are here to help.