From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Serial comm, binary or text?

Solved!
Go to solution

I have two microcontrollers the computer with LV need to comm with using SPI. I think I going to use a USB-to-SPI converter. 

Should the serial data be in binary format or text format? Pros and cons? Is the only advantage with binary format that it is less data to transfer?

I'm worried about if there is something I missing.

 

Text data has \r\n in the end gives it a clear end. On the other hand, I can tell LV to receive x number of bytes and then proceed.  

0 Kudos
Message 1 of 13
(2,437 Views)
Solution
Accepted by topic author Haddock01

Text:  Pros:  Human readable, you can use termination characters to tell when it ends.  Cons:  Takes up more space if you are sending numerical values as strings.  You probably lose precision in numerical data

 

Binary:  Pros:  Most compact, exactly represents the data as it exists in memory.  So think of how you'd image data would appear in binary format.  There really is no "text" equivalent.  Cons:  Any byte is valid, so you can't use termination characters.  You will need fixed length data, or preface it with how many bytes follow

 

Note you could also send it has data in a semi-binary format.  Instead of sending a byte, send it as two character for a hex formatted as strings.  So if you wanted to send a byte value of 127decimal (7F hex),  you could send two characters as "7" and "F".  Pro:  Lets you treat binary data as text and use the advantages of text data.  Con:  Takes up twice as much data space a true text string.

 

The comments you have said it on your post are pretty fitting.  I'm just reiterating them and giving some other ways of looking at it.  Decide what data is you are sending, and how it would look with each method.

 

 

 

 

0 Kudos
Message 2 of 13
(2,424 Views)

All that was said so far is very true, but you want to talk SPI so that part is always binary in nature. The USB-SPI converter will need whatever protocol it requires on the PC side. Are you going to develop that yourself? Why?

Rolf Kalbermatter
My Blog
0 Kudos
Message 3 of 13
(2,410 Views)

" Are you going to develop that yourself? Why?"

 

I suppose. I haven't used any SPI-support LV have. I thinking of USB-8451. 

The microcontroller needs an easy and small protocol. I have used similar method in other projects. LV send a command. Microcontroller sends back cmd+crc+data.

 

 

0 Kudos
Message 4 of 13
(2,395 Views)

@rolfk wrote:

but you want to talk SPI so that part is always binary in nature.


Exactly.  Use a binary/hex/raw data format.  SPI doesn't need to worry about termination characters as the protocol takes care of the message size.

 

The USB-8451 is a good device.  I have only needed to use it once for SPI and used the USB-8452 for I2C quite a bit on one project.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 5 of 13
(2,369 Views)

Ok. On more, perhaps a newbee question. Should I look at VISA-examples? Is using VISA a correct way to build a stable comm.function?

 

I have used LV since 2005 (I think) starting with Labview 6i. Have built about 20 rather big projects in LV but I have never came across VISA (and not much of serial comm). Why? Haven't had the time even read about VISA because of my work situation. 

0 Kudos
Message 6 of 13
(2,357 Views)

Yes.  Look at the VISA examples.  And take them with a grain of salt as they are not the best.  The one that is most commonly used as the basis for code also happens to use the Bytes at Port property node.  Many of us have been asking NI for years to get rid of that example or rewrite it.  Bytes at Port should not be used in 99.9% of the time.

 

Crossrulz created a presentation earlier this year that would be a better thing to view and learn from.    VI Week presentation

0 Kudos
Message 7 of 13
(2,353 Views)

Yes. I have read about this you talk about. Since I haven't look into VISA yet but I think some of the read-function has "read x no of bytes" should be correct way. 

1) I send a command. 2) I (think) I wait for an event and then deals with the response from the microprocessor. I'm not sure how to use the "event" structure in serial but I think I can find some example somewhere or figure it out for my self. 

Thanx anyway for leading me into right direction. 

0 Kudos
Message 8 of 13
(2,342 Views)

@Haddock01 wrote:

Should I look at VISA-examples? Is using VISA a correct way to build a stable comm.function?


If you were using RS-232, RS-422, RS485, raw USB, or instrument communications with Ethernet, then I would highly recommend using VISA.  But you are using SPI.  If you use the USB-8451, then download the drivers and look at the examples that come with it.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 9 of 13
(2,326 Views)

I looked at the examples. Nothing that surprise me. Thanx.

I forgot that the computer are Master and the periperials are slaves. The slaves never initate a comm with the application! It makes my life easier. That means that I need two loops. The first main-loop contains a statemachine that takes care of the overall process. The other loop contains a event which initiates a communication with a specific unit. This "comm-loop" gets commands from the main-loop. 

Is this model a way to deal with this? (perhaps I should start a new thread about this ..)

0 Kudos
Message 10 of 13
(2,292 Views)