LabView Embedded and Colinux

I am going to try to get LabView embedded to run with ucLinux on a blackfin BF537 EZKit.  In doing my initial reading, it seems like the ADI toolchain is tested in Colinux but not in cygwin so I was wondering if anyone out there has tried running Colinux with LabView embedded and if so, how did it go.  I don't know if it will really make a difference, but i guess Colinux is more than just an emulator, it is actually a second kernel that runs in paralell with windows so I am not sure how this will affect the whole process.  I am new to the whole world of embedded programming andI am just trying to assemble as much information as I can before I launch into this to keep myself from wasting time on setups that aren't going to work.  Thanks for the info.
-james

Hi James,
I'm not aware of anyone running CoLinux with LabVIEW Embedded, though that certainly doesn't preclude the possibility of it working.  At the moment, we have an entire LabVIEW module prebuilt for working with the VDK operating system on the Blackfin EZ-Kits, but we don't have a pre-built uclinux target available.  If you're using the Embedded Development Module (and not the Embedded Module for Blackfin Processors), then we can make this happen by porting LV Embedded to a new uclinux target.  As part of this process, you'll need to script the build toolchain to communicate from Windows to the build tools located on your Colinux virtual machine.  One way that might work for you is to automate SSHing into the linux VM, sending it the file to compile, invoke your build tools, then send the result files back to LabVIEW on the Windows side.
Cheers,
Matt Pollock
National Instruments

Similar Messages

  • Performanc​e comparison​---using LABVIEW..b​etween Embedded and general-pu​rpose Intel's single VS multi-core CPU

    hi guys;
    kindly, can any one tell me : is it possible to use Labview installed on desktop pc to show up statistically the main performance key features between mutlicore systems and single core systems but with (two versions, embedded and general purpose CPU) . in other words: I'm trying to resemble embedded cpu with general purpose CPU so that i can only work on Desktop pc than say that the obtained results are the same for embedded multicore CPU.
    to get things more clear:...embedded multicore processors are now hitting the embedded market segments such as (small and portable devices with internet, multimedia and wimax tech. enabled that take advantage of recent multicore tech.).
    general-puroses Multicore processors: like desktop and servers based processors,
    according to what 've read, Intel is producing same processor model but with different applications : (embedded and general-purposes applications)

    Hello,
    Please look at this page which shows a new feature in LabVIEW 2009, but particularly interesting is the video which shows the performance benefits on a PC platform of single core VS multicore.
    LabVIEW doesn't have any ability to emulate a multi-core embedded processor (unless its an intel x86 processor that labVIEW supports!) so to discover the performance benefits of embedded multicore processors, you would need an external hardware board and devise a test in which labVIEW can measure the timing via an external pin toggled by a program running on the embedded processor that could utilise multiple cores (there may be other ways but this is the way that comes to my mind).
    I hope this helps you!
    Mark B
    ===If this fixes your problem, mark as solution!===

  • 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

  • Embedded labview module and blackfin 533

    I need some advice for Embedded labview program integrated with Blackfin 533 Processor. The purpose is to input a value from a GUI in labview and store in a port/location in the blackfin board. Then, upon knowing this location, i can extract the value and use it in my main program in visualDSP.
    Anyone know how to integrate them together as well as identifying where the value is stored in the blackfin? Im using blackfin 533 with Ez-Kit lite.
    thanks

    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

  • Is it possible to take a labview application and compile it to run on an embedded processor?

    Hi
    I was wondering if anybody out there knows if it is possible to take a labVIEW application and compile it to run on an embedded processor (e.g. ARM7)?
    If so does anybody know what the required capability of the target processor is (i.e. RAM, ROM etc.) and what tools I need.
    Many thanks
    Ash

    Ash,
    There is also another option for processors like the ARM7.  You can load a PDA OS on it and use the LabVIEW PDA toolkit.  The LabVIEW PDA toolkit is MUCH easier to use and is quite a bit less expensive.  You will have the problem of getting the OS correctly configured, but in the long run, it may still be cheaper and easier.  I use it quite a bit with my Dell Axim X51v which has this processor and Windows Mobile 5.  There are still problems to work out, but not nearly what there are with LabVIEW Embedded.
    If you want to go the LabVIEW Embedded route and you need some help, let us know on this forum.  There are several of us that have experience and can help to guide you.
    Hope that this helps,
    Bob Young
    Bob Young - Test Engineer - Lapsed Certified LabVIEW Developer
    DISTek Integration, Inc. - NI Alliance Member
    mailto:[email protected]

  • 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...

  • Does a method exist in order to take a labview executible and derive the source code VIs used to create it?

    Has there been any type of methodology for taking a labview executible and extrapolating the source code VIs used for creating the VI?
    Solved!
    Go to Solution.

    Officially they are embeded in the exe in an undocumented way. So you can't easily get at them. But you can always attach a remote debug session and get into the diagrams that way. That is if the diagrams were not removed during the build, which requires a conscious and extra action by the person to remove the according check mark in the build options of the project. So by default all diagrams are totally gone and are definitely not possible to get back from the executable, unless as smercurio has mentioned your name might be Carnac
    Rolf Kalbermatter
    CIT Engineering Netherlands
    a division of Test & Measurement Solutions

  • 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

  • Labview – embedded - part time (Homeworking)

    £20ph -3mc - 2 days a week - Home working
    Labview – embedded - part time
    A part time Labview, engineer is required immediately for a home working role for 2 days a week on a 3 month contract. The candidate would be required to be testing hardware using Labview so would need a good appreciation of testing environments and hardware.
    The company is an innovator in its field, creating and producing cutting edge products to be used in the science field.
    Key Skills:
    Labview
    Testing environments
    Preferably Hardware background

    It might help if you mentioned where this project is. Monthly "face to face" meeting is a little vague on an international forum.
    I might ask what is to be accomplished in a "face to face" (presumably physically face to face) that can't, in this day and age, be accomplished with GoToMeeting, WebEx or Skype video meetings? I'm currently working on projects in Asia, Europe and Latin America, without having to leave my central location in N.America, except when I have to be present for actual hardware installation/commissioning. And even that has been reduced by Remote Desk Top, DameWare or some equivalent.
    Putnam
    Certified LabVIEW Developer
    Senior Test Engineer
    Currently using LV 6.1-LabVIEW 2012, RT8.5
    LabVIEW Champion

  • 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

  • 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 courses

    HELLO!
    I am a beginner from China,I want to study LabVIEW by myself. And the introduction about "LabVIEW embedded module" is not very detailed.Who can send me some courses or examples?as simple as possible please.
    Thanks!
    My email:[email protected]
    kimgirl

    Merhaba Turgay,
    Genel bilgi olarak bu sayfayi oneririm:  http://www.nxtbook.com/nxtbooks/ni/embeddeddesignplatforms/
    Embedded icin ana portal burda:  http://www.ni.com/embedded/
    Bir kac video: 
    http://zone.ni.com/wv/app/doc/p/id/wv-1360
    http://zone.ni.com/wv/app/doc/p/id/wv-820
    http://zone.ni.com/wv/app/doc/p/id/wv-1686
    http://zone.ni.com/wv/app/doc/p/id/wv-707
    http://zone.ni.com/wv/app/doc/p/id/wv-1359
    Embedded alaninda hangi konuda bilgi almak istersiniz?  Bende yardimci olabilirim.
    NIin embedded alaninda urunleri su kategorilere ayrilabilir:
    Microprocessors/Microcontrollers
    Custom Circuit Design
    FPGA
    Industrial/Real-Time PCs
    Embedded Computers
    Gordugunuz gibi bir cok alanda bilgi var, ancak dusundugunuz bir embedded platform varsa, daha detayli bilgi verebilirim.
    Ornek program olarak LabVIEW yada LabWindows/CVI ornek programlari NI-RIO driverleri indiriseniz otomatik olarak LabVIEWe yuklenir.
    -Tolga

  • LabView Embedded edition + Blackfin

    Hello! My aim is to use LabView to generate applications and get C code as output, which I can alter before downloading to a Blackfin. It appears that the Blackfin Test addon, which I have on LabView 8, can only control Visual DSP++ and is not for developing applications; for one, I cannot see any special Blackfin Instrument Panel, as is claimed on the ADI website, where they use LabView embedded edition. Also, instrument drivers are not available for Blackfins, as such.
    I want to know whether the full Blackfin instrument set is available for the standard LabView as well, or is it exclusively for the Embedded edition.
    Thanks.
    Kumar

    For now, the BlackFin module only works with the special LabVIEW 7.1 Embedded edition.
    Ed
    Ed Dickens - Certified LabVIEW Architect - DISTek Integration, Inc. - NI Certified Alliance Partner
    Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.

  • 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

  • What are the differences between LabVIEW, LabVIEW RT and LabVIEW FPGA

    I need a comparison of LabVIEW, LabVIEW RT and LabVIEW FPGA
    Solved!
    Go to Solution.

    NI LabVIEW is a platform and development environment for a visual programming language from National Instruments.
    NI LabVIEW Run-Time Engine includes the libraries and other files necessary to run applications and shared libraries built in LabVIEW.
    NI LabVIEW FPGA Module uses LabVIEW embedded technology to extend LabVIEW graphical development and target field-programmable gate arrays (FPGAs) on NI reconfigurable I/O (RIO) hardware.
    Message Edited by My NI on 08-13-2009 10:07 AM
    Regards
    MY

Maybe you are looking for