Calling C libraries in labview embedded for ARM

Hello,
I wish to use the library
functions written by Luminary micro for their cortex-m3
controllers. If i wish to use these libraries written in C language in
Labview, what i should do? There are large number of libraries
available in their websites, if used in labview embedded, would be very helpfull and make programming very easy. If any one has implemented these libraries
in labview please write to me.
Nabhiraj

You can use the Call Library Function node.
study here and here
Start your work. Post if you stuck up anywhere. People here will help you a lot.
All the Best.
Mathan
Message Edited by mathan on 04-02-2009 02:52 AM

Similar Messages

How to use USB interface with LabVIEW Embedded for ARM

Hi everybody.
I am developing an application based on the "LabVIEW Embedded for
ARM". Now I am doing various tests using
the evaluation board 2300 (with NXP LPC2378), but soon I will
dedicate to program the micro used in my project (NXP
LPC2148).
During the tests, I have seen that "default" LabVIEW interface allows the use
of CAN, I2C and SPI interfaces of the micro. I want to know how can I also use the
USB interface that is on the micros -both LPC2148 and LPC2378- (pin USB_D + / D-, USB_UP_LED,
USB_CONNECT, VBUS).
Thanks in advance for your suggestions

@chueco85
If you've created an application in LabVIEW for ARM and you build it.
you can go to tools >> ARM Module >> Show Keil uVision
then go to he build options.
the hex file will be created when you do a build.
with flash magic :http://www.flashmagictool.com/
you can program your device.
Wouter.
"LabVIEW for ARM guru and bug destroyer"

LabView Embedded for BF537 and FGPA EZ-Extender

Hello,
I would like to know is it possible programming FGPA EZ-EXTENDER by usign LabView Embedded module - now we have BF-537 EZ-KIT and it works perfect, but now we woluld like to order FGPA Extender (or Bluettoth), but I have to know can I create programs for this module in LabView
Best regards,
Pawel Blaszczyk

Hi
Unfortunatelly, this daughter card is not supported neither by LV Embedded for Blackfin nor by LV FPGA. So you have to use the standard method of working with it, as described in VisualDSP++ documentation.
If you want to have similar functionality directly from LabVIEW (embedded system with FPGA), consider CompacRIO or SingleboardRIO.
Regards
Best regards,
Maciej Antonik
National Instruments Poland

LabVIEW Embedded/ARM with password = Crash to Desktop

Hi,
I just installed the LabVIEW Embedded for ARM evaluation kit with the LM3S8962.
A basic project will compile and download perfectly. (Amazing how well this works!)
However, as I'm primarily a SW dev, I am a firm believer in GOOP and other OO technologies. I can create the class and call it in the main VI, but when I go to compile the project, the compiler asks me for the password to a deeply embedded VI (which I do not have) and, after failing to validate or canceling, LabVIEW will just disappear.
If I create and use a native LVOOP class, it'll compile and run, however pass-by-value is simply not an option.
Test Cases:
1) Naked Main VI: compiles, runs OK
2) Main VI calling protected VI: will not compile if VI remains locked ('cancel' button or invalid password entered) and will sometimes CTD
3) Main VI calling LVOOP class: comples, runs OK
4) Main VI calling GOOP class: CTD after OK/Cancel in password dialog
Versions:
Windows XP 32bit Professional SP3
LabVIEW 2009 9.0f1 Evaluation
Endevo GDS 3.51
This really looks like an issue with password-protected VIs.
Has anyone seen this sort of problem before?
Thanks,
Tony
P.S. Will try to attach to another post since the forums keeps giving me an error when posting with attachment...

Claire,
I understand why the builder asks for the password.
I also understand that the LabVIEW Application Builder does not ask for the password, it instead compiles the VI into the Runtime bytecode whether password protected or not.
If this is indeed the case, then the LabVIEW Application Builder generated bytecode could then be used to "expose the functionality of the VI."
However, that's just not the case.
If you've ever looked at the C code generated from a single VI, then you might understand that the C code is in no way understandable or recognizable as to what is really happening in the VI.
I guess if you personally worked on or made great contributions to the LabVIEW runtime engine you might possibly - with no small amount of time and effort - be able to gain some small understanding of what's going on in the generated C code. However, for the average (or even advanced) C programmer, it's obfuscated to the point of incomprehensibility.
I've attached the C code generated from the Naked VI for reference. It's 45Kb of structures, lookup tables, and functions that - while they do perform what the VI does - are in no way recognizable as a while loop, a couple shift registers, addition nodes, split/join number nodes, and VI calls.
While, on the surface, that answer seems plausible, I'm afraid it is indeed nonsensical. Perhaps I could have a chat with the person making this decision?
Thanks for your time,
Tony
Attachments:
Main_VI___Naked.c ‏45 KB

I want to use LV embedded for ARM7 LPC2119, what first i want to do,and how to do it?

i want to port labview program to my target LPC2100,such as LPC2119.But i do not know what i should do first,and how to do it? second,third.......please give me some help.

The LPC2119 and LPC2103 processors full under the Tier 2 category of supported devices. Keil's uVision toolchain does support these targets (you can confirm that from this list, http://www.keil.com/dd/) but there is some additional porting steps that need to be taken in order to program these devices using the LabVIEW Embedded for ARM module.
The steps you need to take are explained starting on this document,
LabVIEW Embedded for ARM Porting Guide - Chapter 1: Introduction
http://www.ni.com/white-paper/6994/en
And continues for a total of 5 chapters. Please note, this is not a short process and the process is even longer if you are not familiar with microprocess programming and software development.
Tim A.
National Instruments

Creating a Labview VI for controlling an Atmel at32uc3a1512 device.

I have a custom device that has a USB port and an ethernet port,
This device (and it's USB port) are controlled by an atmel at32uc3a1512.
I have an old version of Labview (V8.2) nd I would like to create a VI to communicate and pass data
back and forth with an Atmel at32uc3a1512 but I am not sure how to create a driver for this with the MAX utility.
The device shows up in my Windows XP control panel as a USBLib device...
Any direction, suggestions, or links to examples or whitepapers on this is appreciated
thanks

Hello Japper,
If you would like to attempt to communicate to the Atmel at32uc3a1512 as a device using USB, then the following tutorial should be useful. This details how to use NI-VISA to communicate with a USB device, however this requires detailed knowledge on how the device sends, receives, and processes data.
USB Instrument Control Tutorial:
http://www.ni.com/white-paper/4478/en
If you are attempting to write LabVIEW code that will be deployed to the Atmel at32uc3a1512 as a target then that is a whole different set of needs. This device is not an officially supported target, and would require a significant amount of modification and tweaking in order to get this to work, if it is possible. The best resource that I can provide for that would be this guide on how to port LabVIEW to ARM devices. I understand that the Amtel at32uc3a1512 is not an ARM device, however this would be the closest guide that we have for porting LabVIEW as a target VI.
LabVIEW Embedded for ARM Porting Guide - Chapter 1: Introduction:
http://www.ni.com/white-paper/6994/en
Let me know which method you are attempting to use the Amtel at32uc3a1512 as; either a target, or a device.
Thanks,
Joel
Motion PSE
National Instruments

LabVIEW Embedded - Performance Testing - Different Platforms

Hi all,
I've done some performance testing of LabVIEW on various microcontroller development boards (LabVIEW Embedded for ARM) as well as on a cRIO 9122 Real-time Controller (LabVIEW Real-time) and a Dell Optiplex 790 (LabVIEW desktop). You may find the results interesting. The full report is attached and the final page of the report is reproduced below.
Test Summary
µC MIPS
Single Loop
Effective MIPS
Single Loop
Efficiency
Dual Loop
Effective MIPS
Dual Loop
Efficiency
MCB2300
65
    31.8
49%
      4.1
6%
LM3S8962
60
    50.0
83%
      9.5
16%
LPC1788
120
    80.9
56%
    12.0
8%
cRIO 9122
760
152.4
20%
223.0
29%
Optiplex 790
6114
5533.7
91%
5655.0
92%
Analysis
For microcontrollers, single loop programming can retain almost 100% of the processing power. Such programming would require that all I/O is non-blocking as well as use of interrupts. Multiple loop programming is not recommended, except for simple applications running at loop rates less than 200 Hz, since the vast majority of the processing power is taken by LabVIEW/OS overhead.
For cRIO, there is much more processing power available, however approximately 70 to 80% of it is lost to LabVIEW/OS overhead. The end result is that what can be achieved is limiting.
For the Desktop, we get the best of both worlds; extraordinary processing power and high efficiency.
Speculation on why LabVIEW Embedded for ARM and LabVIEW Real-time performance is so poor puts the blame on excessive context switch. Each context switch typically takes 150 to 200 machine cycles and these appear to be inserted for each loop iteration. This means that tight loops (fast with not much computation) consume enormous amounts of processing power. If this is the case, an option to force a context switch every Nth loop iteration would be useful.
Conclusion
LabVIEW Embedded
for ARM
LabVIEW Real-time for cRIO/sbRIO
LabVIEW Desktop for Windows
Development Environment Cost
High
Reasonable
Reasonable
Execution Platform Cost
Very low
Very High / High
Low
Processing Power
Low (current Tier 1)
Medium
Enormous
LabVIEW/OS efficiency
Low
Low
High
OEM friendly
Yes+
No
Yes
LabVIEW Desktop has many attractive features. This explain why LabVIEW Desktop is so successful and is the vast majority of National Instruments’ software sales (and consequently results in the vast majority of hardware sales). It is National Instruments’ flagship product and is the precursor to the other LabVIEW offerings. The execution platform is powerful, available in various form factors from various sources and is competitively priced.
LabVIEW Real-time on a cRIO/sb-RIO is a lot less attractive. To make this platform attractive the execution platform cost needs to be vastly decreased while increasing the raw processing power. It would also be beneficial to examine why the LabVIEW/OS overhead is so high. A single plug-in board no larger than 75 x 50 mm (3” x 2”) with a single unit price under $180 would certainly make the sb-RIO a viable execution platform. The peripheral connectors would not be part of the board and would be accessible via a connector. A developer mother board could house the various connectors, but these are not needed when incorporated into the final product. The recently released Xilinx Zynq would be a great chip to use ($15 in volume, 2 x ARM Cortex A9 at 800 MHz (4,000 MIPS), FPGA fabric and lots more).
LabVIEW Embedded for ARM is very OEM friendly with development boards that are open source with circuit diagrams available. To make this platform attractive, new more capable Tier 1 boards will need to be introduced, mainly to counter the large LabVIEW/OS overhead. As before, these target boards would come from microcontroller manufacturers, thereby making them inexpensive and open source. It would also be beneficial to examine why the LabVIEW/OS overhead is so high. What is required now is another Tier 1 boards (eg. DK-LM3S9D96 (ARM Cortex M3 80 MHz/96 MIPS)). Further Tier 1 boards should be targeted every two years (eg. BeagleBoard-xM (ARM Cortex A8 1000 MHz/2000 MIPS board)) to keep LabVIEW Embedded for ARM relevant.
Attachments:
LabVIEW Embedded - Performance Testing - Different Platforms.pdf ‏307 KB

I've got to say though, it would really be good if NI could further develop the ARM embedded toolkit.
In the industry I'm in, and probably many others, control algorithm development and testing oocurs in labview. If you have a good LV developer or team, you'll end up with fairly solid, stable and tested code. But what happens now, once the concept is validated, is that all this is thrown away and the C programmers create the embedded code that will go into the real product.
The development cycle starts from scratch.
It would be amazing if you could strip down that code and deploy it onto ARM and expect it to not be too inefficient. Development costs and time to market go way down.. BUT, but especially in the industry I presently work in, the final product's COST is extremely important. (These being consumer products, chaper micro cheaper product) .
These concerns weight HEAVILY. I didn't get a warm fuzzy about the ARM toolkit for my application. I'm sure it's got its niches, but just imagine what could happen if some more work went into it to make it truly appealing to wider market...

LabVIEW Embedded - Support for device: NXP (ex. Philips) LPC2146 Microcontroller (ARM7)

Hi,
I would like to write some code in 'LabVIEW embedded' 8.5 for the NXP LPC2146 microcontroller (ARM7).
http://www.standardics.nxp.com/products/lpc2000/lpc214x/
The 2146 device is used within one of our main 'volume' products and I would like to write some special test code for the product in LV Embedded. I have the full NI development suite at 8.5 level.
The question is, does LV embedded suport this microcontroller fully?
I have found this info but still not sure: http://zone.ni.com/devzone/cda/tut/p/id/6207
Many thanks in antisipation of a reply.
Andrew V

Hi Andrew,
Using the LabVIEW Microprocessor SDK, you can "port" LabVIEW to build applications for any 32-bit microprocessor. The LabVIEW Microprocessor SDK Porting Guide describes the steps involved in the porting process.
The amount of effort involved depends on these factors:
How similar your target is to one of the example targets that are included in the LabVIEW Microprocessor SDK. As you can see in the article you linked, the SDK contains an example target with a Philips ARM and an eCos BSP. If your target is similar to this one (especially if the OS is the same), the porting process might take less than a week.
Familiarity with LabVIEW and embedded domain expertise. The porting process involves writing "plug-in" VIs in LabVIEW and building C run-time libraries for your target. However, once the porting process is complete, your target can be programmed solely in LabVIEW by someone with no embedded expertise whatsoever.
Target selection. We recommend a target have the following characteristics: 32-bit processor, OS/microkernel (not "bare metal"), and 256 KB RAM. Also, if you plan to make use of the LabVIEW Advanced Analysis libraries, a floating point unit is recommended.
Michael P
National Instruments

LV Embedded with Keil toolchain for ARM 7 series

Hello,
has anybody use LV Embedded with Keil toolchain for ARM processors? We have this development tools in the company ( used by C group of programmers ) and I would like to hook LV Embedded to this toolchain. We also have Phytec phyCORE-LPC2294 development kit.
Any suggestions where to start?
Regards,
Romp

Hi,
There is a way to hook LabVIEW into MicroVision. It has a TCP/IP interface called UVSock. I am attaching documentation on the interface to this message.
Michael P
National Instruments
Attachments:
UVSock.zip ‏19 KB

LabView for ARM - MCB2300 Audio

Hi, and thanks for reading!
  My name is Chuck and I'm an undergrad ME student taking a mechatronics course. We were asked to create a proximity alarm with the MCB2300 and an IR proximity sensor. I have the entire program running correctly, but this lab has brought up a couple questions about how to better implement audio with the LabView for ARM processors.
  I understand how interrupts work, and I've seen a couple examples online of using an interrupt with a timed loop, but I believe the current version of LabView (2010) doesn't support that feature any more. I had a couple questions about how to get a feature similar to this to work with LV 2010.
  I was thinking I could have the proximity trigger enable an interrupt that I could use to generate higher quality audio than I am already making with a While - Timer loop. However, I'm not sure how to make an increment in the interrupt VI without using some form of a loop. The solution I'm thinking of at the moment is to make a For loop run once and to have an incrementing integer separate from the loop iteration (which would only go from 0 to 1) that stores its most recent value in the shift register.
  My other question is about playing a sound file through the MCB2300. I wrote a VI that reads a .wav file and writes each sample as the output needed to drive a speaker, but that decompression turns a 10KB .wav file into a 300KB text file. I also don't have a way to really load the text file onto the board. Is there any reasonable way to go about this? I found an example online that processes audio data using the MicroVision software, but I don't want to learn a new language to implement this.
  Sorry for such a long post, I just had a couple questions and was looking for some feedback. Any help would be greatly appreciated.
Thanks so much!

charlestrep91 wrote:
Hi everyone,
I just got my Labview for ARM cortex M3 evaluation kit and I can't download a simple program to the target. I'm using the Keil ULink 2 programmer and I get this error when compiling/downloading:
[4:23:16 PM] Status: Error
SWD Communication Failure
Error: Flash Download failed - Target DLL has been cancelled
Detail: [UVSC_PRJ_FLASH_DOWNLOAD, MSG: 0X100A, STATUS: Ex.] (1)
Status: FLASH download error.
I have read about this error and NI simply refers to Ulink2 user's guide which has this description for this error:
Serial Wire Debug communication is corrupted. The target SWD interface is not working properly. Mainly caused by the target: debug block not powered or clocked properly. Avoid Deep-Sleep modes while debugging. Lower the Max Clock frequency in the ULINK USB-JTAG/SWD Adapter section.
I have tried to "Lower the Max Clock frequency in the ULINK USB-JTAG/SWD Adapter section" but it didn't resolve the problem.
I have also tried to download the program using the usb port on the dev board but instead I get this error:
[4:51:22 PM] Status: ErrorUnexpected error occurred.
[Source: Target is in debug mode
Detail: [UVSC_PRJ_ADD_GROUP, MSG: 0x1002,
STATUS: 0xA] Code: 10]
What am I supposed to do with that?? I'm wondering if the dev board is defective. And this was supposed to be plug and play...
Any help is greatly appreciated!
I'll ask the obvious question, are you intending to use SWD or just download through the JTAG. Check your settings. I have not used the ARM with LV, but can you download anything using the Keil software? Give that a try. That may tell us where the problem lies. Try to duplicate your settings in LV from the Keil sw.
Reese, (former CLAD, future CLD)
Some people call me the Space Cowboy!
Some call me the gangster of love.
Some people call me MoReese!
...I'm right here baby, right here, right here, right here at home

LabVIEW for ARM 2009 Read from text file bug

Hello,
If you use the read from text file vi for reading text files from a sdcard there is a bug when you select the option "read lines"
you cannot select how many lines you want to read, it always reads the whole file, which cause a memory fault if you read big files!
I fixed this in the code (but the software doesn't recognize a EOF anymore..) in CCGByteStreamFileSupport.c
at row 709 the memory is allocated but it tries to allocate to much (since u only want to read lines).
looking at the codes it looks like it supposed to allocated 256 for a string:
Boolean bReadEntireLine = (linemode && (cnt == 0));
if(bReadEntireLine && !cnt) {
  cnt = BUFINCR;    //BUFINCR=256
but cnt is never false since if you select read lines this is the size of the file!
the variable linemode is also the size of the file.. STRANGE!
my solution:
Boolean bReadEntireLine = (linemode && (cnt > 0)); // ==
if(bReadEntireLine) {    //if(bReadEntireLine && !cnt) {
  cnt = BUFINCR;
and now the read line option does work, and reads one line until he sees CR or LF or if the count of 256 is done.
maybe the code is good but the data link of the vi's to the variables may be not, (cnt and linemode are the size of the file!)
count should be the number of lines, like chars in char mode.
linemode should be 0 or 1.
Hope someone can fix this in the new version!
greets,
Wouter
Wouter.
"LabVIEW for ARM guru and bug destroyer"

I have another solution, the EOF works with this one.
the cnt is the bytes that are not read yet, so the first time it tries to read (and allocate 4 MB).
you only want to say that if it's in line mode and cnt > 256 (BUFINCR) cnt = BUFINCR
the next time cnt is the value of the bytes that are not read yet, so the old value minus the line (until CR LF) or if cnt (256) is reached.
with this solution the program does not try to allocate the whole file but for the max of 256.
in CCGByteStreamFileSupprt.c row 705
if(linemode && (cnt>BUFINCR)){
cnt = BUFINCR;
don't use the count input when using the vi in line mode. count does not make sense, cnt will be the total file size. also the output will be an array.
linemode seems to be the value of the file size but I checked this and it is just 0 or 1, so this is good
update: damn it doesn't work!
Wouter.
"LabVIEW for ARM guru and bug destroyer"

Can I target the STM32 Primer2 hardware with LabVIEW for ARM

The STM32 Primer2 hardware looks very cool. Can LabVIEW for Arm target this hardware? From looking at the list of ARM devices supported by LabVIEW, this would appears to be a Tier 2 device (ARM Cortex-M3) with no support for TCP/IP or IO.
Can anyone tell me the feasibility or effort required to get TCP/IP, IO, and maybe even display support for this device?
Message Edited by Jim Kring on 09-11-2009 10:46 AM

Have you ever said something you wish you could take back after having time to reflect upon it? Another forum I like, http://newsbusters.org lets the author edit his posts for a short time. Maybe NI could to that and I would not be pulling out my foot so often.
Well, perhaps I was a bit more "colorful" than I meant to be. Frustration does that to me sometimes. Still the idea of a strong rope covered with disgusting risks does get the point across magnificently. I just wish I had saved it for something more suitable.
Let me think back to some of the problems I've had in which I've lost hours trying to figure out...
1. Can't use the Wait ms function. It halts the program. Express wait works fine. It was sprinkled throughout which made it hard to isolate.
2. Some sub VIs don't run unless they are checked as inline code. I don't yet understand why.
3. At the beginning of my main vi there was a small cluster in which I filled the data from an SD card file. I used a constant of the cluster on the input of the Bundle function, but because my program and variable sizes were near the max I changed a number of variable representations to save memory. ...But I didn't replace the constant. The program started exhibiting really strange behaviors. I couldn't even get a simple state machine to run. I was reduced to commenting out (disable structure) sections to find the problem before noticing the coercion dot on the input to the bundle (The dot against the red string color doesn't stand out very strongly which is why I missed it). Apparently it overwrote memory since the older cluster was significantly larger than the new.
4. Spent a lot of time trying to get the SD card to work with SPI functions. Even though I read that 2009 supported SD card file services I didn't intuitively understand how to wire up since the Open/Create/Replace function has a ref num output which actually connects to the file(use dialog) input of the read and write functions.
5. Had a problem with breakpoints and probes not working. That apparently was caused by item #3.
6. Typo bug in the Arm_irq.c file LM3Sxxxx_GPIOCAHandlerP to LM3Sxxxx_GPIOCHandlerP
Some of these are of the rope variety. A few are actual bugs. All probably could have been solved in moments had I a local guru. Anyway, I've spent hours and my hands hurt. I hope to have this little project working on the LM3s8962 today and after some hardware changes will port it over to the Primer2... Hopefully...
This forum has been a real help... especially your quick responses.
regards to all,
David

Labview Embedded module for blackfin processor

hi
i want ot know that, Labview Embedded module for blackfin processor full development kit is essentail for detecting Blackfin Board.
I have all the software to detect the board but only Labview Embedded module for blackfin processor is Evaluation version.
so is that a resion for not detecting the Board
Regards
mithun patil

Just to be clear: The version of VisualDSP++ you need is not just VisualDSP++4.0, but VisualDSP++ 4.0 for LabVIEW Embedded. It is a special version created especially for use with LabVIEW Embedded. Go to the Help>About window in VDSP and verify that this is the product name. The evaluation version should not matter as long as the evaluation period has not expired.
Message Edited by Michael P on 08-07-2006 11:26 PM
Michael P
National Instruments
Attachments:
vdsp.JPG ‏28 KB

Accessing Onboard ADC with LabVIEW for ARM

I am working with the LM3S9062 Evaluation board and LabView for ARM system, and want to measure an analog voltage using the ADC, however I cannot determine which of the Digital Inputs is linked to the ADC. I need to know how the gpio mapping corresponds to the pinout of the Device. Any thoughts?

Do you mean the LM3s8962 evaluation board? If so, the pins should be labeled accordingly on the board - ADC0, ADC1, ADC2, etc.
Drop an EIO node with the same name as the pin and it should work fine from there.
Here are the schamtics : http://www.realview.com.cn/UploadFile/2008111510295067433.pdf

Can I use my custom board with LPC2378 processor with ULINK2 on Embedded module for ARM and LV.

Issues in ARM and LV
Can I use my custom board with LPC2378 processor with ULINK2 on Embedded module for ARM and LV.How can I create my elemental I/O vis or I have to use the existing Keil board vis. Confused. Please help.
I have LV8.6. Which ver of embedded module for ARM should I buy. Website shows combined price for ARM module and LV. But I already have LV8.6 so what is the cost of module.
Regards
Shradha

          If the processor of your development board is the cortex-M3 core, I think you do not have to buy keil board. Now, there are a lot of OS and emulator suitable for Cortex-M3.
          Operating system I am referring to is the real time operating system such as keil RTX,uCOS,FreeRTOS,CooCox CoOS and so on. CooCox CoOS is very new, you can get more information from http://coocox.org/ .
          Emulator or debugging tools such as ULINK2,st-link,Jlink,CooCox Colink and so on. CooCox Colink is also very new. You can download the Colink Plugin from here Colink Plugin .

Calling C libraries in labview embedded for ARM

Similar Messages

Maybe you are looking for