LabVIEW Embedded

cancel
Showing results for 
Search instead for 
Did you mean: 

Will it be possible to program an ARM Cortex-R4 device using LabVIEW Embedded for ARM?

I'm currently evaluating LabVIEW Embedded for ARM using the Keil MCB2300 ARM-7 board, but it appears not to have enough resource, particularly RAM, for the amount of processing that we need to perform.

 

For our application, which is mainly automotive, the most important features are capacity, performance and connectivity, so the ARM Cortex-R4 looks very attractive. Keil have an evaluation board that uses a Texas Instruments Cortex-R4 processor (TMS570LS20216), available here:

 

http://www.keil.com/arm/mcbtms570/

 

This is supported by Keil Microvision, except that it requires a different JTAG linker from Segger, details here:

 

http://www.segger.com/cms/jlink.html

 

So the question is simply, will it be possible to port LabVIEW Embedded for ARM to the TI Cortex-R4, and program it via Keil Microvision and the Segger J-link?

Message 1 of 20
(9,251 Views)

Hi John,

 

From what I can tell by looking at the link below, it is not currently possible to port LabVIEW Embedded for ARM to the TI Cortex-R4.

 

http://sine.ni.com/nips/cds/view/p/lang/en/nid/205040

 

As the link states, it only works with many ARM7, ARM9 and Cortex-M3 Microcontrollers.

 

 

Im will continue looking into this and try and see if there is any other possible ways of doing it.

Kind Regards

Michael
NIUK Application Engineer
0 Kudos
Message 2 of 20
(9,232 Views)

Hi John,

 

I have done more research into this and it would appear that you can port LabVIEW ARM tools to the TI Cortex R4.

The Segger J-Link can be used with Keil Microvision. However, when programming it you will need to configure your project so it uses the Segger J-Link instead of the ULINK from Keil.

 

I hope this helps.

Kind Regards

Michael
NIUK Application Engineer
Message 3 of 20
(9,176 Views)

Thanks Michael, that's a start at least.

 

Am I right in thinking that the LabVIEW project build specification will be set to use ULINK as normal, and configuring the project to use the Segger J-Link is done manually in the Microvision "Options for Target" dialogue?

 

Otherwise, I guess it should be a case of following the porting guides below to create the new Cortex-R4 target?

 

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

 

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

 

I'm just wondering what will happen when we need to get the Flexray working, for example, but there are no ready made VI's for this like there are for CAN. Is it possible to access the additional peripherals using inline c-node VI's?

 

 

Regards,

 

John.

0 Kudos
Message 4 of 20
(9,174 Views)

i want ask how could i config  configure my project so I can  use the Segger J-Link instead of the ULINK from Keil?

 

thank you.

0 Kudos
Message 5 of 20
(9,046 Views)

Hi John,

 

We have the same problem as you. The current Tier 1 boards do not have the performance we require. We have also looked at the MCBTMS570 board as a good basis for our development. This way we get 256 DMIPS of performance versus about 60 DMIPS for the current Tier 1 boards (4x performance). The Tier 1 boards, per se, are quite capable. However, it's amazing how much CPU grunt is lost programming in LabVIEW. So, the solution is ... to move to a more powerful processor!

 

Did you get far in utilising this board?

 

Regards,

Vito

0 Kudos
Message 6 of 20
(8,367 Views)

Hello Vito,

 

No, we didn't get any further than asking the question, sorry.

 

We are currently building a custom hardware board based on a Tier 1 processor (LPC2388), and if that goes well we would still like to look at building something more powerful in the future.

 

I did find that being economical with the programming helped a lot - like using single precision floating point and integer maths, rather than double precision, and avoiding express VIs etc.

 

Hopefully NI will continue the development of the embedded ARM software - it would be great to see the list of tier 1 devices grow.

 

Regards,

 

John.

0 Kudos
Message 7 of 20
(8,360 Views)

HI John,

 

Vito and I are work colleagues.  I'm curious to know a few things about your experience with programming the LPC2388 with LabVIEW Embedded for ARM.  


    • Which Dev board did you use ? (was it one of the MCB2300 series ?)
    • The LPC2388 isn't on one of the existing Tier 1 boards from NI,  does that mean you had to modify the low level (C code) drivers for the peripherals/display etc to maintain all the existing Teir 1 functionality with LabVIEW?  For example USB with OTG is supported on that board which perhaps would suggest additional drivers are required.
    • Did you find that when you went from using a single loop to multiple loops that your CPU performance reduced by about 75 % as Vito has ? (refer to point (3) here )

 

Thanks in advance.

regards

 

Peter
0 Kudos
Message 8 of 20
(8,350 Views)

Hi John,

 

I'm using the evaluation version with 15 days to go. Like you I've found that it pays to be economical with the programming. This is a pity since I quickly built an application and then spend 10 times the development time shoehorning it to work with the required performance. So, what could be a rapid development system is throttled by the available Tier 1 boards. From what I understand, no new Tier 1 boards have been introduced since the product introduction in 2006 and in fact one (Blackfin) has been dropped.

 

We would also like a more capable Tier 1 board and hopefully NI will do introduced a new more capable Tier 1 board soon. My work colleague and I independently identified the MCBTMS570 to be a good candidate. So that's two of us. Hopefully NI will introduced the MCBTMS570 as a Tier 1 board.

 

From what I understand it would only take about 2 months of NI development effort to introduced a new Tier 1 board, so it's not very expensive. I guess it's Catch 22 - NI won't develop more Tier 1 boards until there are more LabVIEW Embedded for ARM sales and there won't be more sales until there is a more capable Tier 1 board Smiley Frustrated

 

They wouidl get their money back with just one additonal LabVIEW Embedded for ARM sale!

 

Keep in touch John. You never know, if NI doesn't develop a new Tier 1 board we may split the work load and target the MCBTMS570 Smiley Happy

 

Regards,

Vito

 



 

0 Kudos
Message 9 of 20
(8,344 Views)

Hello Peter,

 

Sorry for the delayed response, I've been busy building and testing the custom hardware I mentioned in the previous post.

The good news is that the custom hardware is working perfectly so far, which bodes well for the project as a whole.

 

In answer to your questions, yes we used an MCB2388, for the simple reason that although the LPC2388 processor isn't Tier 1, functionally it is exactly the same as the LPC2378, just with more RAM, so it's very easy to create a new MCB2388 or generic LPC2388 target, and tell Keil Microvision to use the correct processor and the correct amount of RAM. Effectively it then becomes Tier 1, without going anywhere near C-code.

 

For example, the MCB2300 LV CAN drivers work perfectly with custom LPC2388 hardware.

 

I get the impression that creating a new target for an entirely new processor won't be quite so easy!

 

I can't really comment on the performance of single vs multiple loops, but I did find that it seems to work well when all the top level code is contained within one flat frame structure, then you can initialise everything in the early frames, run your code somewhere in the middle and tidy things up at the end. I have run two parallel loops sitting within one frame, one of which was untimed and dealt with CAN messages, the other ran a 10ms timed loop, which performed calcs and set the outputs, and that worked perfectly.

 

The thread you linked to made interesting reading - so thanks for that.

 

We're very close now to committing to LV for ARM, on the basis that it just about stacks up for a single short term project, but the decision would be a whole lot easier if there was a steady stream of new tier 1 targets, or even the hint of a couple of new ones quite frankly. As things are, it's a decision we have to think very carefully about.

 

It's hard to believe that NI haven't developed this more, considering how popular ARM processors are....

 

Regards,

 

John.

0 Kudos
Message 10 of 20
(8,316 Views)