Where is the Programmer's Guide for ARM?

[PrismGreg]

I just purchased the evaluation kit for NI LabVIEW Embedded Module for ARM Microcontrollers.  The official included board was a MCB2300 and off to the side a separate purchase was made for Luminary EK-LM3S8962 kit.  These are both Tier 1 boards and the demos work fine. 

However, the intent of the purchase was for proof of concept.  There were 2 main goals for my proof of concept:  Shared variables and targeting any of the hundreds of Tier 2 devices.  As it turns out, I can't do either.

The shared variable issue is DOA since a single shared variable dropped onto the block diagram exceeds the demo limits for compiled size.

That leaves the mystery of targeting a Tier 2 device.  The Luminary kit came with a separate daughter board to demo CAN communication with the main board.  The daughter board contains a LM3S2110.  I have not figured out how to compile a demo for this even without trying to implement any elemental IO.  I have read the porting tutorials, edited the TargetConfig.ini and TgtSupp.ini files, edited the Kiel project settings in the template\project folder, passed in preprocessor symbols as described elsewhere, etc...  Still I can't get it to work.

OK, so assuming I can figure out the Tier 2 target someday I tried to figure out how elemental IO is implemented.  At first glance it seems straightforward.  You need to create the functions at the vi level (which call functions at the C level) the define them using the eio wizard.  Following along the examples of the Tier 1 devices, I found what VIs were assigned to the eio functions.  For example, one points to a MCB2300 LED Write vi which contains a MCB2300 Turn On LED vi.  Here comes another roadblock...  through the magic of LabVIEW, there is nothing on the block diagram other that a note which reads  "To increase performance, this VI is implemented using a C function call", what is going on here?  Also, there are a bunch of vis in the eio folder which are password protected, what's up with that?

So as you can see, my proof of concept failed across the board.  I don't think this development environment lives up to its promise (other than showing how easy it is to use the Tier 1 development board as is).  Am I missing something?  Where is the official LabVIEW for ARM Programmer's Guide the lays out all the structure, requirements, and functionality.  Even the tutorial isn't good enough because it leaves out interrupts, how the communication functions of overloaded, etc...  It is even too old as it refers to the need for the Microprocessor SDK to use some sort of Target Editor (another $12K, I don't think so).  Also, why does the LabVIEW for ARM Resource Kit zip file contain nothing other than 4 links back to the internet?  These same links and more are already on the download page where the kit came from.

For reference, I do know C and can get there boards up and running using just the demo compiler.  It is the LabVIEW compatibility layer that is the issue, can it really require this much effort?

I hope I am just missing something and would appreciate any help,

Greg

[LaRisa_M]

Hi Greg,

Can you tell us more specifically what problems you're running into porting to the LM3S2110, errors you're getting along the way, etc? You won't need the Microprocessor SDK if you use this tutorial: http://zone.ni.com/devzone/cda/tut/p/id/7152

[Jaidev]

Hi Greg,

Let me address some of your concerns here:

1. The eval version of LabVIEW Embedded Module comes with a development license for the Keil uVision toolchain. The 128K application size limit in Eval mode is one of their stipulations. Infact, through special agreements, Keil agreed to increase the limit to 128K from 16K, which I believe is their default. Most other toolchains that you will find out there will have the same 16 - 32K application size limit. At any rate, the point of Eval mode is limited functionality. We made sure that all our shipping examples could be compiled and built in Eval mode.

2. It might be possible to build a simple shared variable in eval mode. I built something simple like this:

 

The map file in uVision shows the size of this app as:

I believe this should work on the Eval version. At any rate, you can send me the application that you tried, there might be some things we can try to make it fit in eval mode. Reducing your Heap size is one such way. This KB should tell you how to.

3. Porting to Tier 2 devices is a non trivial process and the procedure changes from target to target. I can help you with the process if you can give me more specific information about what exactly did not work.

4. Being a C programmer yourself, you have no doubt noticed that LabVIEW apps tend to be larger,

a. because we include RTX, a Real Time OS in with your app. It gives us the ability to introduce multi threading, semaphores etc.

b. we are auto generating C code. While this is way more reliable than hand written C code, it can never be as efficient (size-wise) as it.

So, given this larger size, we recommend that LabVIEW targets have at least ~64KB RAM. You will notice then that the LM3S2110 is not a suitable target (only 16KB RAM). I don't recommend porting to it.

5. EIO is not the only way of implementing IO. Infact, it one of the more involved ways of doing it with the obvious advantage being the simplicity of use for an end user. You can implement IO very efficiently using only the Inline C nodes and register level programming. 

6. When you see VIs with no code in the Block Diagram, we are using a mechanism called "Funclists" to implement them. This again is an advanced feature that we don't expect many users to play with. But I can send you all the details of the implementation if you want.

7. The reason we do not have a detailed programmers guide (showing internals of the product) for the ARM module is because it was intended to be a easy to use product, with an intuitive out-of-the-box experience for people who do not want to worry about the internals but rather get up and running as fast as possible. However, I can provide you with any of the internal details that you need for your project.

Let us find a way to communicate personally and I will have more specific answers to your questions.

Thank you,

Jaidev Amrite 

[rales]

Jaidev Amrite mentioned not using Elemental IO rather use simple C register operations.  Can you send me an example of how to do this with my target, a Tier 1 LPC2378?

You are not kidding LV is not very effient C coder.  The memory usage for a simple While(1) vi with nothing eles is:

     Total RO  Size (Code + RO Data)                14852 (  14.50kB)    Total RW  Size (RW Data + ZI Data)             24660 (  24.08kB)    Total ROM Size (Code + RO Data + RW Data)      14988 (  14.64kB)

However add 3 DI, 5 AI and 11 DO as Elemental IO controls (and nothing else) the memory usage jumps to:

    Total RO  Size (Code + RO Data)               154556 ( 150.93kB)    Total RW  Size (RW Data + ZI Data)             37112 (  36.24kB)    Total ROM Size (Code + RO Data + RW Data)     155312 ( 151.67kB)   So I have burrned more than 20% of my memory resources and have not done a single useful task. Let me know if I'm missing something? Thanks,Rick