LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Where to start with ARM embedded?

Hello,

I have only informative knowledge about embedded in general and almost nothing on ARM technologies. Yet I need a quick introducement to the ARM architecture and how to use it with the LV ARM Embedded Module - what programming/OS/hardware prerequisites are required? Most important is whether this module can work with any development boardor just those from NI?

Any information is wellcome and valuable.

Thanks in advance,

Roman

0 Kudos
Message 1 of 7
(4,465 Views)

Hi Roman,

 

I'll try to give you some information, and if it's not enough, keep those questions coming.  This is where I would recommend starting to understand the LabVIEW Embedded Module for ARM Microcontrollers (LabVIEW ARM module):

1) Software needed: LabVIEW + LabVIEW ARM module

2) Hardware needed: a supported chipset.  The Web site here lists all ARM chipsets compatible with LabVIEW.  (If a chip is supported by the "RL-ARM Real-Time Library" then LabVIEW is compatible with it.)

3) There are only 3 evaluation boards that are supported "out-of-the-box" - tier 1 targets.  Here is a list of them.  For all the other chipsets listed in the above article, some development work needs to be done in order to "port" the module over to your tier 2 target..

4) You can download an evaluation version of LabVIEW and the LabVIEW ARM module here.  You have the option to download your code to a simulated target, so no actual hardware is needed.

5) The LabVIEW ARM module was designed such that you can practice first on a tier 1 evaluation board.  You can then port the module over to a different tier 2 chipset (potentially integrated into your own custom printed circuit board) as needed in order to customize your application further.  Detailed instructions on how to port the module to a tier 2 device is listed here.

6) As a side note - National Instruments doesn't currently fabricate any ARM microcontrollers.  The LabVIEW ARM module is designed such that it can target a variety of chips made by multiple manufacturers.  Thus, if you want a list of hardware specific features, you will have to consult the datasheet made available by the manufacturer of the chip you are wishing to use.  One of the best searches I have found is located here.  The link listed at the top - Parametric Search - allows you to identify which chipsets have which features.

 

If you would like someone from National Instruments to contact you regarding this information, please let me know.  (I know it's a lot.) 

 

Enjoy!

Kevin S.

Applications Engineer

National Instruments

Message Edited by Kevin_S on 04-27-2009 02:40 PM
Message Edited by Kevin_S on 04-27-2009 02:42 PM
Message Edited by Kevin_S on 04-27-2009 02:44 PM
Message 2 of 7
(4,423 Views)

Kevin,

 

Thank you very much for the prompt support! I now have the following couple of questions (assuming that "tier" is a vendor or chip-name):

 

1.
Basically, if I am not sure for a development board I am considering, I can just contact you (NI) and ask if "this board with this chipset" is compatible with LabVIEW? Does this compatibility mean there are no connectivity issues (compatible boards work immediately via COM or USB)?

2.
Where is the OS (RTOS) implemented - in the ARM MPU itself? I gues I access the AIO, DIO, CTR etc. via this OS, or is it purely hardware (register based)?

 

Thanks in advance,

 

Roman

0 Kudos
Message 3 of 7
(4,406 Views)

BTW, where in this "story" fits in the LabVIEW Microprocessor SDK?

I am very confused by all this Embedded options.

 

Roman

0 Kudos
Message 4 of 7
(4,402 Views)

Hi Roman,

 

1) "Tier 1" or "Tier 2" is a status.  In order for you to write all of your code in LabVIEW and then download it to your ARM chip, the "LabVIEW Embedded Module for ARM Microcontrollers" (LabVIEW for ARM module) needs to have been "ported" to your target.  When I say "ported" I mean that underlying code has been written for the module such that LabVIEW drivers now exist for the peripherals on your chip.  (You can't access any analog inputs in LabVIEW if you don't tell the LabVIEW module that analog inputs exist.)  With this in mind, know that National Instruments R&D has written many LabVIEW drivers for certain ARM chips.  These are refered to as Tier 1 targets.  Tier 2 targets don't have preexisting LabVIEW drivers.  A LabVIEW developer would need to create these.  (The "porting guide" in my previous post refers to the manual that outlines the process of how to do this.)  Currently, there are 3 Tier 1 targets: ARM Devices Supported by LabVIEW

 

2) There are hundreds of ARM chips that will work with the LabVIEW for ARM module.  In order to know if your chip will work, it needs to have "RL-ARM Real-Time Library" support files.  Either these support files have already been created, or someone can contact Keil with a request for them to be created.  That is what is required for LabVIEW to be compatible.  Keil keeps an up-to-date list of all processors for which it has created these library files: RL-ARM Real-Time Library

 

3) As far as the actual hardware circuitry needed in order to run the chip, that is specific to each chip.  You will need to either contact Keil or the chip manufacturer to determine what specific hardware circuitry is needed in order to integrate the physical chip into a custom printed circuit board such that the chip can run the "RL-ARM Real-Time Library".

 

4) As far as a real-time operating system running on the ARM chip itself, it's called RTX.  See the below article for more information.  When building the actual LabVIEW drivers (implementing the Elemental I/O), yes - a knowledge of register-level programming is useful and sometimes needed.  Chapter 3 of the porting guide shows some examples of how these drivers are built.

LabVIEW Embedded for ARM Porting Guide - Chapter 3: Implementing Elemental I/O Part 1/2

 

5) I understand that there are MANY embedded topics when it comes to LabVIEW, ARM, Blackfin, and the Microprocessor SDK.  I will try to explain their relations in general terms.  The Microprocessor SDK is very generic.  It can be "ported" to essentially any 32-bit processor/microcontroller.  However, the amount of work needed to "port" to a target is fairly extensive (because the module is so generic).  R&D basically took the Microprocessor SDK and performed an extensive amount of "porting" work such that it could target any ARM microcontroller that specifically utilizes the "RL-ARM Real-Time Library".  This R&D project was named "The LabVIEW Embedded Module for ARM Microcontrollers."  Likewise, R&D also took the Microprocessor SDK and performed an extensive amount of "porting" work such that it could target a wide variety of Blackfin processors (manufactured by Analog Devices).  This R&D project was named "The LabVIEW Embedded Module for Blackfin Processors."  Now, I hope you see the correlation between the Microprocessor SDK and both of the NI-developed embedded modules.

 

I completely agree that there is room for confusion without some background knowledge.  Please keep those questions coming, and I'll try to help.

 

Regards,

Kevin S.

Applications Engineer

National Instruments

Message 5 of 7
(4,381 Views)

Kevin,

 

I need to be sure I understand the concept correct:

 

1. RTX

This RTOS is already inside the ARM MPU and it takes care of my business - execution of downloaded compiled code and all IO and COMM on the deployment board?

 

2. RL-ARM Real-Time Library

My very ARM needs to be listed in this library, meaning corresponding support files need to be available for LabVIEW to be able to compile code for download? (something lice #include)

 

3. Tier-1 drivers

Are these drivers for the ICs of the surrounding circuitry (AD converters, etc) to be used with my very ARM, or only LabVIEW needs them for parameter definition in my LV diagram?

 

Sorry for the inconveniance but I need a stable ground before I go on.

Sincerely,

 

Roman

0 Kudos
Message 6 of 7
(4,364 Views)

Hi Roman,

 

1) Yes, the ARM chip runs the RTX real-time operating system (RTOS).  Everytime code is downloaded to the chip, the RTX kernel is also downloaded (through the JTAG interface).  More information about the RTX RTOS can be found here: RTX Real-Time Kernel

 

2) Yes, since The LabVIEW Embedded Module for ARM Microcontrollers utilizes the RL-ARM Real-Time Library in order to run compiled LabVIEW code, the RL-ARM Real-Time Library files need to exist for your specific ARM microcontroller.  (If they don't exist, you're welcome to contact Keil in order to see if it is being developed or to potentially request their development.)  I don't know exactly what you mean in drawing an analogy to "#include".  You could view the real-time library as the support needed for LabVIEW code to interact and run on the real-time operating system.  The correlation between the real-time library and the real-time kernel can be viewed here: Product Overview

 

3) Tier 1 status means that the profile of that specific target has been prebuilt.  For example, the MCB2300, MCB2400, and EK-LM3S8962 target profiles already exist.  (These are Tier 1 targets.)  Without any development work, you can target and download code to each of these evaluation boards.  This doesn't mean that all peripherals on the evaluation boards have been integrated into VIs (even though a fair number of them have been).  Again, in order to give you a better picture of what is available with the current Tier 1 targets, I recommend that you download and play around with the evaluation version of the software.  (When you build the underlying code such that you create the target profile in LabVIEW for that target, you have created another Tier 1 target.)

 

Kevin S.

Applications Engineer

National Instruments

Message 7 of 7
(4,331 Views)