LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

SIUSBexp C8051F320 Write Example with LabVIEW

Hi,

 

I am trying to communicate with C8051F320 which is a SiliconLabs part. I have been able to use the Function Calls to make subVI's for Open, Close, etc which work fine. However, I am having issues with the SI_Write and I was wondering if anyone would be kind enough to provide with an example of some kind for me to follow? I am getting Error 12 of which I don't know what it means. Essentially what I am just trying to do is send the commands to the C8051F320 part to enable some of the register settings and for right now I am just working in just getting one of the pins to output high. 

 

https://www.silabs.com/Support%20Documents/TechnicalDocs/an169.pdf

 

I appreciate any help on this matter thanks.

 

0 Kudos
Message 1 of 10
(3,563 Views)

Well since the attached VI will not work to show the code, I'll attach screenshots..

 

 

Download All
0 Kudos
Message 2 of 10
(3,538 Views)

This is more like it.  Several errors:

 

1) Don't pass binary byte arrays as C strings to a C function. C strings are considered terminated with a NULL character and LabVIEW takes that literally, potentially junking your string after the first zero char.

 

2) The last parameter is an overlapped pointer which is used for asynchronous operation. You don't want to use asynchronous mode here. For one LabVIEW is multithreaded and you don't gain much by trying to do asynchonous API calls, second it makes interfacing to this API A LOT more complicated. So you need to pass in a NULL pointer, which is achieved by configuring it as a pointer sized integer passed by value and connect a 0 to it.

 

SI_Write.png

Rolf Kalbermatter
My Blog
Message 3 of 10
(3,521 Views)

Thank you very much Rolf for your feedback. It's been very helpful. I do not get any errors however, it does seem to crash when it gets to writing 0x0C into register P2MDOUT which is on register 0xA6 of the part. I am unsure as to what makes Labview just not respond. Also, throughout the weekend I've been tackling the inability to read the contents of the registers after supposedly write to them. I've disabled that for now, and focusing on the issue mentioned before, but any tips you may have would be amazing. It's been rough but I'm learning.

 

Thanks

0 Kudos
Message 4 of 10
(3,478 Views)

If you want other people to help you, you really should not just post a picture. LabVIEW is graphical programming, and a picture says more than 1000 words, but it does not at all provide any clues about the details of the subVIs in your picture, nor the actual configuration and datatypes of the Call Library Node. It's analogues to send an automechanician a picture of a car and ask him to diagnose what is wrong with the motor!

 

In case you haven't noticed, my picture is a so called snippet. You can drag it to your desktop and from there into a LabVIEW diagram and it will recreate the code. In your case it would be easier to simply zip your VIs together and post it like that.

Rolf Kalbermatter
My Blog
0 Kudos
Message 5 of 10
(3,473 Views)

Well, that makes sense. I'm attaching my Vi's in zip file.

 

That's pretty slick about the snippet! Thanks for telling me 🙂

 

0 Kudos
Message 6 of 10
(3,461 Views)

Hi Merb,

 

You mention that LabVIEW crashes when writing 0x0C into register P2MDOUT, in what way does it exactly crash? Do you get an error code or message? have you tried monitoring the memory usage while you are running your application?

A. Acuna
0 Kudos
Message 7 of 10
(3,424 Views)

There's no error code or message, LAbview just literally hangs and becomes non-responsive. It gets stuck in writting block, doesn't move from there and eventually have to force shutdown labview. I am not sure why it does that always on the third byte sent. It's only writing one byte at a time through "for loop" so I don't see what could go wrong there. 

0 Kudos
Message 8 of 10
(3,422 Views)

I breifly looked at the Vis in your archive and I can't immediately spot something in there which is wrong.

 

However what you describe is definitely not a crash at all. It is a hangup caused by the fact that your DLL function doesn't return control to LabVIEW. Why it would do that is the next step to debug. There still could be errors in how some of the Call Library Nodes are setup but it could just as well be that the function somehow blocks as it can't send off the bytes you tell it to send, but doesn't detect an obvious error in accessing the device IO interface, so just keeps sitting there until the device answers positivly, which it doesn't seem to do.

 

I'm afraid that from this moment on the problem is much less LabVIEW related but rather in how you communicate with your target, which somehow doesn't seem to like something.

 

Rolf Kalbermatter
My Blog
0 Kudos
Message 9 of 10
(3,406 Views)

Ok, seems like I finally got past that hangup issue. It writes the array of registers with data. Would you agree that at my RX and my Read blocks are set right? I'm trying to read back what I wrote, but get error. 

 

thanks for looking over my vi's. I really appreciate your feedback.

 

 

0 Kudos
Message 10 of 10
(3,391 Views)