LabVIEW Embedded

Showing results for 
Search instead for 
Did you mean: 

Use LabVIEW Embedded Module for ARM Microcontrollers to read data from SPI interface



Thanks for the response.  I was probably a little harsh with the comment about the NI support, but I was quite frustrated.  I don't understand how a basic operation like reading and writing registers do not work in software designed to support controllers!  Did NI ship this product and just not notice?


Anyway, I've tentatively started trying to implement the code in C.  I've been able to configure the SPI and send data to it.  I can't get data back from the ARM however, and I can't get the interrupts to work, so I'm not sure if this approach is going to work out.  We have committed to this technology for a product we need to ship in June, so I'm more than a little worried. 


NI support had suggested using inline C nodes to for capability not directly supported.  But I can't get anything to compile when using them.  Are there any examples of this?  Also one other question about support for interrupts in LV.  The vi allows you to enable interrupts, but you can't configure them?  How do you define an ISR for the interrupt?



Bill F

0 Kudos
Message 21 of 55

Hi Bill,


If you're looking for more information on how to implement an ISR (Interrupt Service Routine) in LabVIEW, I recommend this article:

Interrupt Driven Programming for ARM Microcontrollers using LabVIEW


From what you've said, you're implementing your code in C.  When you talk about reading to and writing from registers in LabVIEW, are you referring to the peek and poke VIs or some other VI altogether?



Kevin S.

Applications Engineer

National Instruments

0 Kudos
Message 22 of 55

Kevin -


I feel your pain, I really do. I have become numb to it all. I have found that the ARM Embedded module is still under development. LVE 1.1 was a big hit around here but still fell short of the promises the dev kits offer (regardless of what they tell you). We also have committed ourselves to this technology and have been scratching at the wall ever since. Depending on your application you will have to expand the amount of RAM you have - compared to C, LVE is very hungry; due to having an OS of course.


In regards to the SPI 'driver' for the ARM embedded, we had to change our ARM_SPI.c file so we could communicate with an ATMEL flash chip. The previous version of this driver (before me) was sending only one byte length message/s before waiting for a reply. With a flash chip you need to send an op code of at least 3 bytes before receiving a reply; so we changed this to look a little like that below:


switch (chipSelect) {
    case 0:
      PCONP   |=  (1 << 8);                              // enable power for SPI
      PINSEL0 &= ~0xC0000000;                            // clear pin settings
      PINSEL1 &= ~0x0000003C;                            // clear pin settings
      PINSEL0 |=  0xC0000000;                            // P0.15 (SCK) is SPI pin
      PINSEL1 |=  0x0000003C;                            // P0.16..18 (MISO, MOSI, SSEL) are SPI pins.

     S0SPCCR = (0x38);  //SPI_CLK / (clockRate * 1000UL);          // set clock rate - Run as fast as possible
  S0SPCR = 0;           // Clear the setup register
  S0SPCR = (( clockPhase    & 1) << 3)              // set clock phase
       |  (clockPolarity << 4)              // set clock polarity
       | (1 << 5)                                 // set master mode
              //| (1 << 6)                        // LSB trans. first ****** Require MSB first for DataFlash memory
              | (1 << 11);                       // set 8 bit data
    #endif /* SPI_INTERFACE_IN_USE(0) */



In regards to GPIO port registers - elemental I/O nodes just do not work. Also, some of the fast GPIO ports do not work. There wasn't an issue in LVE 1.0; come LVE 1.1 all this changed. I would also check the Register Addresses in the appropriate header file (*.h). We are using a LPC23xx series controller and would be adjusting the LPC23xx.h file (i'm sure there are various issues between controllers and manufacturers).


The GPIO issue is a significant fault that has a work-around that uses the legacy registers within an in-line C-node, within a while loop.




Well, I hope that helps, at least for somebody. We now have a good looking piece of firmware that has been completely written in LVE (excluding our personal touches/fixes) that is capable of communicating on various comms networks; including memory management (a very poor option provided by NI - hah! I had to get that in) and a data input line. So, as painful as it is, it is possible. Here's hoping that NI can find the resources necessary to put pen to paper and offer some transparency in their product.


Let me know how that goes.






0 Kudos
Message 23 of 55

Hi David,


Thank you very much for your feedback.  I've already notified R&D of the information in your post.  We value information like this in order to determine what functionality is being used and what functionality is desired for future releases.


Kevin S.

Applications Engineer

National Instruments

0 Kudos
Message 24 of 55




We too have had tremendous problems with LVE.  We have committed to the technology as well, but are resorting to C becuase we can't get anything to work with LVE.  I would love to use LVE, but anything above the most trivial applications will not compile.  The built in support for making lights blink etc work, but try to do anything useful - forget it.  I simply can't afford to wait for NI to figure it out.  Having to resort to inline C nodes is not acceptable.  I had been using peek and poke functions vice the elemental I/O, but now I learn that doesn't work either - Great!


Frankly, LVE is useful as a toy for HS students, but not much else.  If I were NI, I would be embarressed to sell it in its current state - especially since they charge $8K for it


Bill F

0 Kudos
Message 25 of 55

Hi Bill,


Please let us know if you're having trouble.  There is a lot of functionality in the LabVIEW for ARM module, but I do agree that there are also some bugs as well.  You may have already committed to C code development for your current project, but if you still have LabVIEW questions, ask.  I see you had a few statement above, but when I asked further questions, you never answered.  Let us help you.


I recommend that if you have SPI functionality questions, post to this thread, but if you have new questions altogether (not related to SPI communication), please start a new thread - specifically for that issue.


Kevin S.

Applications Engineer

National Instruments

Message Edited by Kevin_S on 04-14-2009 10:49 AM
0 Kudos
Message 26 of 55



We are currently 6-8 months behind our project deliverable deadline due to the many issues we have had to overcome. The cost and high risk that was associated with the initial development was a little difficult to swallow but we were committed. As a result of all our issues we have our sales rep forward a list of issues we are experiencing directly to NI/Texas to resolve these issues, and he is heading that resolution (Les is awesome!). Kevin - any extra help would be appreciative :).


In short, there is a relatively high risk in the product. A few months back NI began to realise the importance of the product and have quickly added more people to the melting pot (to join that bloke down in the basement, I presume!). I have noticed that there is more (just a little) information floating around on how to do various things with LVE. Of course, there isn't much in the way of examples hereabouts. Due to the lack of paper-work there are a few things you may need to adjust in your (their C) code to handle your type of micro-controller. The PlatSerial.h file for instance, will need to adjusted to handle the number of serial ports you have. We have 4 and our code would not compile because the value of 2 was present (according to the dev kit requirements) - VERY VERY VERY time consuming and frustrating to resolve this little gem. Also, you have to keep an eye on how much stack and heap RAM space you are using. If you are using up too much stack and don't have enough heap then it won't compile or run properly (generally stops running after a short moment). You can change the heap space allocation (only) in the LPC2300.s file (for us - look in the KEIL compiler file listing for your project. It will be at the top in the first folder), line #100 - decrease the hex value to increase the stack (to get your program on if it doesn't fit - program is bigger if you have large unallocated arrays) or increase the heap if you need more memory. There is a tight balance if you are at the cusp of your resources.


If you need help I can also provide what direction you may need. We have learnt that development using embedded technologies will never be on par with PC LabVIEW, simply because of the level of interaction with the hardware - if it is possible, there is a long way to go! You will always be interacting with the hardware on a relatively basic level. The advantages of using LVE over C are, thread manipulation; timing control; and of course the graphical view.


Given the vast range of ARM controllers out there, LVE is bound to be buggy and un-supportive to most of them (even if they say it is - stick with the dev boards and you will be safer). For us, we have custom hardware using an ARM7. Some of our difficulties have stemmed from this design but only in a small part. The major drama that NI is having is the interaction with 3rd party software and resolving the agreements between them. As you can imagine, this reduces support. Also, NI will not support custom hardware due to the variability out there - as you can imagine. Are you using a dev kit or custom hardware ?


If you have the resources then it would be best to develop your project in C, in parallel. We had considered this as an option but simply don't have the resources or time. We are fairly confident in what we can do with LVE and I would be happy to help where I can.




0 Kudos
Message 27 of 55

Kevin - a wish list: Smiley Very Happy

There are a number of functional requirements we need to have fulfilled, as promised by the ARM7 Development Kit. These, and other areas of concern regarding the ARM7 module, are:

·         the availability of drivers;

·         flexibility in changing “C” code for customisation of the VI’s;

·         roadmap/ability to create our own VI’s using “C” we have written;

·         instructions and manuals that describe the set-up process

o   need to know how to modify code for set-up process (is an exhausting process) and ARM variability. It was found that the drivers and template that was set up for our current configuration did not port over when the ARM7 module was upgraded from 1.0 to 1.1. Because we’ve been through the process of setting up 1.0 the process was relatively straight-forward.

o   ARM7 module needs to be easily updated with updates in KEIL

o   Knowing how to change the settings specific to the micro-controller is not made available;

§  For example: when using the LPC2368 ARM7 we needed to change the second line of code in the “PlatSerial.h” file to the following: (the original was 2 – suitable for the dev kit)

§  Trying to find the spot to change the above took a ‘very long time’.

o   The ARM Porting Guide was helpful with many useful directions but offered examples that were too specific to one particular ARM microcontroller. This left the reader confused in applying the porting guide to various ARM microcontrollers; for example, knowing which file that is used to define the number of available serial ports in the microcontroller (see point above).

·         Memory management:

o   Need a forced ‘garbage collector’ to remove unwanted arrays, data, etc;

o   Generally, a better understanding of the background workings and use of memory performed by LabVIEW and KEIL compiler would be extremely helpful.

§  There are various VI’s that are not recommended due to their ‘memory hungry’ nature. A visual and transparent view on how memory use (RAM in particular) is utilised would be a benefit – as the balance between stack and heap can be a tight one.

·         An upgrade of the ARM7 module to include the RealVIEW real-time library;

o   Benefits of this would be the Flash File System, for example.

·         Have TargetEditor installed in ARM7 module instead of having to install Microprocessor SDK;

We find that the Microprocessor SDK was required to install 1.0 and 1.1 but the software itself is not required. A better integration of functionality of LabVIEW products into one LVE module would be largely accepted.


0 Kudos
Message 28 of 55

Hi David,


I can ask R&D about many of the issues in your "wish list". 


Can you create a new discussion forum thread for each new topic?  (This involves more people in the research as well as making it easier to segment topics.)  SPI communication topics can remain in this thread.


If you do start new threads, put a link at the end of this thread so that we can follow you.


Kevin S.

Applications Engineer

National Instruments

0 Kudos
Message 29 of 55