Custom hardware and the ARM module

[Perreijn]

Hi everyone,

Our company is in the early stages of the design of a custom measurement device. In the past we used microcontrollers from Microchip (PIC16 and 18), a simple IDE and a C compiler, but for the new generation of devices we plan to use ARM microcontrollers from Luminary Micro. Since we're also LabVIEW users, the choice for the LabVIEW embedded module for ARM seems logical. I have read a lot of NI documentation and watched the tutorials, but I'm still uncertain about what we can and can't do with the module. Before we buy eval-kits and the module, I need to have some facts.

1. The 'heart' of our circuit is a LM3S1968 microcontroller, this MCU is ARM Cortex-M3 based. It's listed in Keil's device database (http://www.keil.com/dd/), so is it also a LabVIEW 'Tier 1'-device (http://zone.ni.com/devzone/cda/tut/p/id/7066)?
2. Do I have to add the MCU manually to the project as described in http://zone.ni.com/devzone/cda/tut/p/id/7152, or can I just select it from a menu?
3. We already have a LM3S1968 evaluation kit (http://www.luminarymicro.com/products/lm3s1968_evaluation_kits.html) and a JTAG-programming device. Can we use these hardware components to evaluate the LabVIEW ARM module or do we have to buy a complete NI kit (including dev board)?
4. Is a JTAG connector on our device and a connection to a JTAG debugger, all I need for debugging the device with LabVIEW?
5. Does the NI evaluation kit (http://sine.ni.com/nips/cds/view/p/lang/en/nid/205040) include the pictured Keil ULink2 JTAG-adapter?
6. We want to connect the MCU to an A/D converter, the AD7738 from Analog Devices (http://www.analog.com/en/analog-to-digital-converters/ad-converters/ad7738/products/product.html). We'll use the SPI-bus for communication and I know what codes to send to get a basic readout. Do I have to use the SPI-subVI and send hexadecimal codes or can I use a predefined 'AD7738' subVI from a device drivers CD?

I appologize in advance for the number of questions, it's just that using LabVIEW for hardware development is completely new to me 

Thanks in advance for your help.

Paul

[Jimmie_A. · Accepted solution]

 

Hello Paul!

I will try to answer your questions and hopefully someone else can add more information if needed.

1. The 'heart' of our circuit is a LM3S1968 microcontroller, this MCU is ARM Cortex-M3 based. It's listed in Keil's device database (http://www.keil.com/dd/), so is it also a LabVIEW 'Tier 1'-device (http://zone.ni.com/devzone/cda/tut/p/id/7066)?

Answer: No, it would be a Tier2 device, we offer three Tier1 devices today and information about these can be found on the link you provided.

1. Do I have to add the MCU manually to the project as described in http://zone.ni.com/devzone/cda/tut/p/id/7152, or can I just select it from a menu?

Answer: You need to add it yourself as described in the link you provided.

1. We already have a LM3S1968 evaluation kit (http://www.luminarymicro.com/products/lm3s1968_evaluation_kits.html) and a JTAG-programming device. Can we use these hardware components to evaluate the LabVIEW ARM module or do we have to buy a complete NI kit (including dev board)?

Answer: This one is trickier, LV Embedded Module for ARM in evaluation mode will have some limitations (size of applications, can open the development environment a certain amount of days and so on), but it shouldn't have any limitations when it comes to port it to other targets as described in the links you have provided already. When it comes to the JTAG interface I would really recommend using the Keil ULINK2 USB-JTAG.  

1. Is a JTAG connector on our device and a connection to a JTAG debugger, all I need for debugging the device with LabVIEW?

Answer: I would make use of the Keil ULINK2 USB-JTAG adapter for debugging and we use this to download code to the targets. Actually it is the only way we can download code on ARM, but one can make use of a serial port / TCP in addition to JTAG when debugging.

1. Does the NI evaluation kit (http://sine.ni.com/nips/cds/view/p/lang/en/nid/205040) include the pictured Keil ULink2 JTAG-adapter?

Answer: Yes.

1. We want to connect the MCU to an A/D converter, the AD7738 from Analog Devices (http://www.analog.com/en/analog-to-digital-converters/ad-converters/ad7738/products/product.html). We'll use the SPI-bus for communication and I know what codes to send to get a basic readout. Do I have to use the SPI-subVI and send hexadecimal codes or can I use a predefined 'AD7738' subVI from a device drivers CD?

Answer: I/O would be implemented using the Elemental I/O layer we provide as described here:

http://zone.ni.com/devzone/cda/tut/p/id/7119

http://zone.ni.com/devzone/cda/tut/p/id/7144

Hope this helps!

[Perreijn]

Hi Jimmie,

Thanks for your reply, this clears up a lot of confusion. It looks like we'll buy a NI evaluation kit to avoid possible problems with 'non-Keil' JTAG-debuggers. It's a shame there are only three tier one devices, but I guess that I can use NI's LM3S8962 hardware board drivers as a basis for my own drivers for the L3MS1968. Just a matter of using the elemental I/O layer to make the two SPI interfaces available to LabVIEW, right?

Just one additional question though; are there any known problems with the evaluation kit and Windows Vista? The reason I ask is because of numerous ARM c compiler crashes in the Keil evaluation kit that was included with my Luminary L3MS1968 evaluation kit. As soon as I start uVision 3, I often get errors. Since uVision and the compiler are parts of the NI module, I would like to know if there are any know issues. Thanks in advance.

Paul

[Jimmie_A.]

Hello Paul,

Elemental I/O should not cause any issues - you have lots of templates that are done for the Tier1 devices and you can copy and modify these accordingly. What you need to know is the register-level programming necessary to configure and access peripherals and the I/O hardware that you make use of.

SPI - is another story since these VIs are actually blank i.e. they just contain some controls / indicators and no actual code and the function call is instead implemented as a C-function call.

But you have the source code for this so one can look at how it is implemented for the Tier1 devices and the copy and modify as needed.

Do not know any issues more than the 64 bit version of Vista is not supported. I haven't tried it out myself though, currently using XP SP3.

Didn't find any issues reported either on issues related to Vista.

Hope this helps!

[Michael.Phillips]

Hi Paul,

We do not have any known Vista specific issues. However, there is a known Cortex-M3 compiler bug in the version of the uVision compiler shipped with LabVIEW. The issue relates to the optimization, so if you reduce the optimization to –O0 (in the build specification) you will most likely be able to compile successfully.

It would be beneficial if we could reproduce the crash you are seeing. To do this, we need the following information, which can be obtained by opening uVision from LabVIEW (right-click on the ARM target in the LabVIEW Project and select "Show uVision" ) :

-The compiler options (uVision->Project->Options for Target->C/C++->Compiler control string) – Copy/Paste into a post
-The pre-processor output for the file (xyz.c) that causes the crash… 

• uVision->Project->Options for Target->Listing->C Preprocessor Listing – Tick this box
• Build project
• Attach the file xyz.i file from the folder indicated in the Listing tab to your post.

With this information we can reproduce the crash / and check that we have resolved it in the latest compiler that will be released with a future version of LabVIEW for ARM.

Message Edited by Michael P on 12-03-2008 08:17 AM

[Perreijn]

Hi Michael,

I've resolved the compiler crash issue in Windows Vista; I'm glad to report that the crashes had nothing to do with Vista nor uVision in general. I reinstalled uVision from another evaluation CD and the crashes were gone. Seems the CD I originally used was bad and caused a corrupted installation

I'll keep the Cortex-M3-compiler bug workaround in mind once I've received the NI kit. Thanks for the tip.

Paul