09-15-2010 05:08 AM
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?
09-16-2010 07:16 AM
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.
09-21-2010 09:09 AM
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.
09-21-2010 11:30 AM
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.
10-14-2010 08:13 AM
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.
01-15-2012 09:53 PM
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
01-16-2012 04:00 AM
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.
01-16-2012 05:12 PM
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.
Thanks in advance.
regards
01-16-2012 07:23 PM
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
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
Regards,
Vito
01-24-2012 11:59 AM
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.