Can I target the STM32 Primer2 hardware with LabVIEW for ARM

[Jim_Kring]

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

[David-n-MO]

Jim,

I agree it does look cool... And I've bought a few with the intent of developing a project on a Luminary LM3s8962 and porting it over after learning the ropes.  Unfortunately I've found those ropes covered with feces and medical waste and frankly don't know how much higher my boss will allow me to climb.

Still, the device is cool with touch screen, accelerometer,  joy stick, USB and sound circuitry AND battery all in a nice, if a bit chincy case.  A prototyper's dream actually.. And only about $75 at Digikey.  Circuit Cellar ink gave it a nice mention a couple of issues back should anyone care to look.

I  hope who ever is first to acknoledge working with it will make the hardware mapping available to the rest of us.

David 

[Jim_Kring]

Hi David,

What sort of issues (that you reference so colorfully :)) have you had while trying to "learn the ropes" with the Luminary LM3s8962 board.  This board is supposed to be one of those officially supported (Tier 1 with all IO support), right?

Thanks,

[David-n-MO]

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 

[Jim_Kring]

Hi David,

Thanks for the explanation of the issues you've faced.  This info will be useful as we start playing with things.  Certainly, I'll post here with any progress updates, and hope you will too.

Regarding rants, I've posted many emotional rants here in the forums, too.  The thing I try to be aware of is that a lot of the NI R&D team members participate actively in these forums, which is an incredible resource for us, the users of the products.  If we say things that might hurt the feelings (or kill the morale) of the NI R&D teams, then they won't feel like participating here in the forums.  It's worth mentioning that I've learned this lesson the hard way, after saying some things that I've later learned hurt the feelings of some NI R&D team members.  Now, I try very hard to make my feedback constructive, rather than just complaining.  For example, your last post with a list of problem you encountered adds tremendous value to this conversation and I'm sure that whoever reads this thread will appreciate it 🙂

Cheers, 

[Kevin_S]

Hi Jim,

Yes, constructive feedback is appreciated (more than the feedback that does nothing). 

I have some information for you with regards to TCP/IP functionality.  There are basically 4 different Keil libraries that can be "plugged" into the Keil RL-ARM Real-Time Library.  (TCP/IP, Read/Write to Flash, CAN, USB)  For Tier 1 targets, the TCP/IP, Flash, and CAN libraries are included.  (You don't have to purchase them separately from Keil in order to use them for Tier 1 targets.)  Note that in order to use the USB library even for a Tier 1 target, you would have to purchase this from Keil.  However, for Tier 2 targets, you have to purchase the CAN, Flash, and USB libraries.  You DO NOT have to purchase the TCP/IP library for Tier 1 or 2 targets.  The source code is included with the LabVIEW for ARM module.  You just need to simply recompile the code for your new target. 

The TCP/IP source files are located here on your computer: 

C:\Program Files\National Instruments\LabVIEW 2009\Targets\Keil\Embedded\RealView\Drivers\RL-ARM\TCP

I hope this helps,

Kevin S.

Applications Engineer

National Instruments

[Kevin_S]

David-n-MO,

Just to let you know, yes - you can edit your posting on NI's discussion forums for a few minutes after you post.  All you have to do is select the "Options" link in the upper right of your post.  There will be an edit link available for ~5 minutes (if I remember right), and after that time, no changes can be made.

Kevin S.

Applications Engineer

National Instruments