LabVIEW Embedded

cancel
Showing results for 
Search instead for 
Did you mean: 

How do you deal with button interrupts on the 537 ez-lite

Solved!
Go to solution

Sorry for the newbee question, but I am just getting familiar with the ex-lite 537 board.  I want to use the buttons to cause an interrupt and then service that interrupt with some code.  Do I have to write a seperate VI to handle the interupt, or can I put it in an event structure in the vi I am writing...?  I would eventually like to be able to write an event driven state machine into the blackfin...In the attached file, I can scan the button and make it light up an led, but I would like to use the enable interrupt, and get button number as an event / case pair to do the same thing...how???

 

Thanks for any suggestions.

 

Hummer1

0 Kudos
Message 1 of 16
(7,742 Views)

Hummer1,

 

     The Event Structure won't natively see a hardware button update. It's been built up to see Windows OS events. You might be able to do it if you use Dynamic Event Registration. I would first look at the shipping examples called BF537 Button - callback.lvproj and BF537 Pushbutton - polling.lvproj. Callback uses another VI to act as an interrupt when buttons are pressed and Polling uses architecture like your Tutorial.VI. I find it easy to visibly understand code when using Polling architecture but both are proper methods. Hope this helps!

0 Kudos
Message 2 of 16
(7,728 Views)

Thanks...BUT...There is a library function written in C that is in the interrupt handler that pulls the button number ...  Why would you need to do that if there are any ez-lite blackfin functions that would do it.

 

???  The examples may work, but how they work is hidden and that sucks.

0 Kudos
Message 3 of 16
(7,722 Views)
Solution
Accepted by Hummer1

Hummer1,

 

         The Call Library Function Node (CLFN) that is configured to work with the dll is working with functionality that sees what button has been pushed on the BF537. You can double click that and see what dll it is pointing to and what function it is interacting with. Since deploying to embedded targets means that you have to compile LV code to C and then to machine code using a 3rd party compiler, this is just doing the C generation work for you. You could probably build up the functionality yourself using just the VIs provided but taping into these support libraries is better since you don't have to reinvent the wheel and a lot of the VIs that you would end up using are actually just wrappers for other dlls.

0 Kudos
Message 4 of 16
(7,719 Views)

Thanks, but NONE of the example discussions on the forum mention the use of the dll lib...I didn't see it in the list of dependencies until I ran the example and saved it.  It is not mentioned in the documentation delivered with the board.  I have waisted 2 days with this and am not happy.

 

Give me a minute to cool down and I'll tell you what I really thing...which is basically, that I like the package and am interested in seeing how fast I can learn to use it...

 

Hummer1

0 Kudos
Message 5 of 16
(7,717 Views)

Hummer1,

 

          I totally understand your frustration. Without the shipping examples I wouldn't have even known that the dll and the function existed. Does that functionality work for you though?

0 Kudos
Message 6 of 16
(7,713 Views)

can't find the dll in my distribution.  Where is it...or can I save it from the example and use it elsewhere?  The example is 0.2 silicon and my system is 0.3...does that matter?

 

It shouldn't be this hard.

0 Kudos
Message 7 of 16
(7,711 Views)

Hummer1,

 

         To change the silicon revision you just need to go into the LabVIEW project and right-click on the embedded target name (Analog Devices ADSP-BF537) and choose "Configure Target". It's in the Target Settings tab. You should be able to run the code on your 0.3 revision as well just by changing that setting and rebuilding the application in the Build Specifications.

 

As far as the dll, it is located at "C:\Program Files\National Instruments\LabVIEW 2009\vi.lib\Embedded\vdk\DeviceStub\Debug\DeviceStub.dll". You can find this path by double left clicking on the Call Library Function Node in the callback.VI. You shouldn't have to do anything with it though because it is already included in your dependencies under vi.lib. The dependencies get included when you build/deploy your code. If you use the Call Library Function Node in a different VI in a different project and point to that dll, it will automatically be added to the build as well.

 

If you run into any other issues, just let me know because I am here to help!

0 Kudos
Message 8 of 16
(7,709 Views)

Thanks Grant.

 

I'm sure there is a simple explanation ... however ...

 

I have built a project.  It has two vi's ... one is designated a interupt service vi the other is the main.

 

I can find no  way to drag, copy, move or otherwise get anything to connect to the path that is the .dll stub thing.

 

Where do you go to pull that into the vi?  I just simply don't understand where you GET it from in the menus/ files/ or whatever.  It is just a path...What do you connect it to so that the interrupt service performs the function that it does in the example  (callback example.)?

 

We're getting close...I can feel it.

 

Hummer1

0 Kudos
Message 9 of 16
(7,699 Views)

Hummer1,

 

      It's when you configure the Call Library Fuction Node. This is the structure that LabVIEW uses to call a dll and point to a specific function within that. I highly suggest taking a look at this article (http://decibel.ni.com/content/docs/DOC-9069) which goes through how to do that.

0 Kudos
Message 10 of 16
(7,659 Views)