Desperate questios on RS232 Communication

[win2suse]

Hallo johnsold,

The device is a pic p16f876a chip which I use to realise A/D converter and send the conversion results into pc thru this ongoing labview interface. In order to start sampling signal, from pc a value is ought to be sent to the chip where the burned code judges whether the value is equal to "1" or not, if it is true, then the a/d converter is initiated, and the results are continuously sent back to pc for the signal of concern is time-varying.

Every conversion results in a corresponding 10-bit digital number which is sent in two bytes one, the lower significant bits, after the other, the higher significant bits with bit7~bit2 at "0". On that note, I have concatenate two consequentially coming bytes, then convert the 16-bit data to a floating value which is displayed in the chart and saved in an excel.

How could I concatenate these two bytes which come one after another? Are there any similar samples where could be recommended from you?

[win2suse]

Hallo Dennis Knutson,

After enlarging the fields of "read string" and "string to write", I have seen all the hidden characters. I have cleaned up the block diagram, and now go further to achieve my final goal which is described in the above post.

Since the judge is made by the chip rather than labview, I guess this while loop is sufficient for my project.In the burned code in the chip, there is no termination byte sent back to the computer. I attempt to concatenate two bytes, then convert it to a float format which I understand, but so far I have no idea which functions can realize this target. If it is not that easy to carry out such concatenation and conversion without a termination byte, I could re-burn my code in the chip. Kindly let me know your advice.

win2s

Message Edited by win2suse on 04-20-2007 05:57 AM

Message Edited by win2suse on 04-20-2007 06:02 AM

[johnsold]

win2s,

OK since you send a "convert" command to the remote device and it always sends back exactly two characters, you should have no problems. I would read any available bytes from the serial port before you send the commmand. That clears any "junk" characters which might be in the receive buffer.

Send the convert command. Wait long enough for the device to decode the command, do the conversion, and send the reply. Check Bytes at Port. If it is 0 or 1, wait a short time and check again. If it is 2, read the bytes and convert them to the desired data format. If the nummber of bytes is >2, then some kind of error has occurred. After a non-error write and read cycle, repeat as needed.

Lynn

[win2suse]

Hallo Lynn,

thanks for your immediate reply.

My above description on the algorithm of the code in the chip might be not exact. I'd love to add more:
As the signal of interest is continuously changing, the chip is also continuously sampling, converting, and sending digital signal back to the pc.
The labview is expected to behave like an oscilloscope except that at the beginning it sends the 'convert' command which user types to the chip to start up the sampling, conversion and sending data.
For every sampled analog signal results in a 10-bit digital signal contained in 2 bytes after conversion in chip.

According to your suggestion, it's my understanding that in order to get the continuous results the 'convert' signal has to be sent repeatedly. Is it possible to send the command only once at the beginning, then the results which contain a throng of such two-byte results are correctly truncated and converted into decimal float for display and save?

win2s

Message Edited by win2suse on 04-20-2007 08:48 AM

[johnsold]

win2s,

I may have misunderstood about the continuous conversion.

Certainly you can continuously read data. The tricky part is making sure that the pairs stay matched up. If you ever lose a byte, then the next pair is in reverse order and parts of two different conversions. Since the most significant byte always has 6 bits of 0, that can help. But if you lose synchronization at a time when the data is 00000010 00000001, you cannot tell that you are misinterpretting the result. Serial systems are notorious for ooccasionally losing a byte.

I would read bytes in pairs and do a quality check. Any time a conversion produced a value outside the range that is possible for your 10-bit converter, attempt to resynchronize by shifting one byte.

This synchronization issue is why a termination character or the command/response idea of my earlier post are often used. You have to decide how much overhead your system can tolerate compared to the "cost" of errors and the benefit of faster response.

You indicate that you are displaying the data in a chart so updates faster than 5-10 times per second are meaningless to the human operator. Sending three bytes (one command,two response) at 9600 baud takes just over 3 milliseconds. If your decoding and conversion on the remote device takes 100 milliseconds, you can still do 9.7 updates per second to your chart with the command/response method.

Lynn

[win2suse]

I agree with your analysis.
Could you recommend me a loop structure or an example for the command/response strategy? The condition of next iteration is based on the succesful conversion of current turn. Or I simply make use of my present design with a properly adjusted sample rate of the while loop?
As for processing the coming two-bytes, it seems that a buffer required. I find that there is one type of buffer available, VISA Flush I/O Buffer. Is it the recommended type?
have a nice weekend.

[johnsold]

I have modified your VI to write a command followed by reading a two-byte response. I think the notes I added will explain most of what I did. I did not put in any conversion from string to 16-bit numeric. Also the Wait function in the case statement (Sample Rate) should be changed to a Wait Until Next ms Multiple for better timing. Look at the context help for an explanation of the differences.

If the conversion subVI detects an error, you can set the set the error cluster and stop or try to resynchronize.

Lynn

[marten]

Hi,

I'm also struggeling with communication between the pic16F876a and Labview..

Sending and receiving in labview (pin 2 and 3 short circuited) is possible but sending with the PIC isn't succesfull, but I do see the signal on the osscilloscoop...

May i see youre assembly code (register settings), i'm struggeling with this problem a long time.... I use a max232 to convert the signal, and the signallevel +9V and -9V.

I hope you will answer, I know i don't help you with this qeustion....

[win2suse]

Thanks very much for your model. I shall try my hand with it.

wins

[win2suse]

Following is my settings:
BSF STATUS,RP0 ;Bank1
movlw 0xc0
movwf TRISC ;tx, rx should be inputs
MOVLW 0x20 ;Sender: RS232
MOVWF TXSTA
BCF STATUS,RP0 ;Bank 0
MOVLW 0x90 ;Receiver: RS232
MOVWF RCSTA
;Define USART Baud rate
BSF STATUS,RP0 ;Bank1
MOVLW D'15' ;Set Baud rate 19,2 kBPS at 20 MHz
MOVWF SPBRG
BCF STATUS,RP0 ;Bank 0
;Interrupts preparation
BSF INTCON,GIE ;Enable generel interrupts
BSF INTCON,PEIE ;Enable peripheral interrupts
BSF STATUS,RP0 ;Bank1
BSF PIE1,RCIE ;Enable receive interrupts
BCF STATUS,RP0 ;Bank 0
BSF STATUS,RP0 ;Bank1
movlw 0x8E ;Set TAD = 32 TOSC togather with ADCON0<7,6> ; PORTA,0 = analoge input
movwf ADCON1
banksel ADCON0
movlw 0x81
movwf ADCON0
BSF STATUS,RP0 ;Bank1
movlw 0x01 ;Initialize the TRISA
movwf TRISA
BCF STATUS,RP0 ;Bank 0
CLRF PORTA ;Initialize the PORTA