recieving 3 value in uart

[DataMiser]

It is a carraige return linefeed combo as would typically be at the end of a line.

Hex 0D 0A
Dec 13 10

[feitanx]

If I send it through this format:

345
235
453

How to do it?

[DataMiser]

if that is what you are going to be getting everytime e.g. 3 values each 3 digits long and each on a new line you could simply check the length and then use the mid() function.

Something like this

Private Sub MSComm1_OnComm()
  Static a$
  dim b$,c$,d$
  a$ = a$ + MSComm1.Input
  If Len(a$) = 15 Then
     b$=mid(a$,1,3)
     c$=mid(a$,6,3)
     d$=mid(a$,11,3)
     a$=""
  End If
End Sub

[WoF]

Yes, but this does not synchronize. If you mis one of the first characters, all of the following received values'd wbe wrong.

Have you any influence of how you send the numbers? Can you modify the C-code in the microprocessor as to determine how the numbers are sent?

[DataMiser]

True, but that gives a general idea. Personally I would use handshaking where the PC responds to the connected device telling it that everything is fine or that it should resend or some other such thing.

I would also use US and RS [e.g. CHR(31) and CHR(30) ] characters in the datastring rather than CR+LF

Assuming of course that the code on the other device can be modified.

[feitanx]

yes I have influence,
so the horizontal format like 124/563/452 is better?

I could put a carriage return in the end. Would it be enough?

[feitanx]

I would also use US and RS [e.g. CHR(31) and CHR(30) ] characters in the datastring

What do you mean by this?

[DataMiser]

They are just standard characters used for formatting

CHR(31)= Unit Seperator character.
CHR(30)=Record Seperator character.

In your sample of data above the US would be where the / is and the RS would be at the end of the group.

Of course the / and a CR will work just fine

[WoF]

Yes. I'd prefer the "/" and Cr ore better Cr Lf sequence, because you can put that literally in any textbox to get a readable display, or being debug.printed for control purposes without problem.
US and RS have often no visible correspondence.

I advise to use "/" to separate numbers and Cr Lf to terminate the record.
Then you can easily split it up as I showed before.

[DataMiser]

I would use just the CR rather than CRLF.

btw the reason for using US and RS is that they will never be typed from the keyboard and as a result will not occur in most data streams where as , / CRLF are all common place. This is one reason why these characters were assigned this purpose in the ASCII standard.

[dglienna]

/ can be part of a date, so I always use \

[WoF]

Yes, which can be part of a pathname.
You could also use comma, colon, semicolon or any other character which you are sure will never be part of a number.
If you might get decimal numbers you should not use dor or comma.
If you are sure the numbers are never a date you can use "/" no problem.

In many cases it makes no difference to use Cr or Cr-Lf, only that when printed out the Cr-Lf is a standard sequence to advance to a new line. If you would receive records from your hardware with, say, hyperterm, it will always write to the same line again, because Cr only jumps backt to the beginning of the line. The Lf, however advances the cursor to the next line.

That's why I would prefer Cr-Lf. If in doubt you can receive your data with Hyperterm (which is a standard windows gimmick) to see if the sender provides valid data.

[DataMiser]

Yep all of this is true. This is also the major reason I have standardized my programs to use US,RS,EOT. Typically the only time you will run into these characters is during a binary transfer for which I use a different method.

I used to use comma a lot as well as CR. I also used Tab ~ | > and others

IMO the CRLF is just 1 additional character to transmit and process, limits your options for parsing the incoming data and requires a tiny bit more processing. Not a biggie for sure.

btw not sure about hyperterm but most terminal programs can be set to advance to the next line on a CR or a LF or a CRLF.

I rarely use hyperterm as I have written my own terminal program many years ago which works like a champ with many features that hyperterm does not have.

[feitanx]

If you are able to send this format
234/345/456
123/345/678
everything is rather easy, provided you send complete lines with 3 numbers each.
After the third number a vbCrLf must be sent to definitely delimit a group of 3 numbers.
In OnComm you can do then:

Private Num1%, Num2%, Num3%
Private RLine$
Private Sub MSComm1_OnComm()
  RLine = RLine + MSComm1.Input
  If Len(RLine>2) Then
     If Right(RLine,2) = vbCrLf Then ' a complete record with three numbers has been received now
        dim a$()
        a = Split(RLine, "/") 'split the line into the three numbers
        Num1 = a(0) 'get first number
        Num2 = a(1) 'get second number
        Num3 = a(2) 'get third number
        RLine = "" 'reset the receiver variable for the next line
     End If
  End If
End Sub

I'm receiving from a source that's keep on sending, would this code be still valid?

[DataMiser]

Depends on how fast it is sending, It there is a pause between sends of 1 second or more then you would likely not have much problem. If the pause it shorter then the chance of an issue increases and if no noticable pause then quite likely to have a major problem as is,

You would need to first check for the terminator as above but not by using the Right() function. Instead you would use instr() to see in the terminator is present and where in the string it appears. You could then use Mid() to pull out the data up to the terminator and process it. You would also need to check to see if there was more data after the terminator if so this data needs to be saved for the next cycle and that data processed needs to be removed.

In my case I normally set up a public variable for a receivebuffer. Any data which arrives gets appended to this variable. I would then check to see if my terminator character is present. If so then I would pull the data from the buffervar up to that position and place it in another var for processing. I would also check the len of the buffer var to see if it is longer than my data + the terminator(s). If not more data then I set the buffervar="" if more data then I use mid again to pick up the data after the terminator.

I then process the data in the local processing var and loop back to the top of my terminator test routine to see if there is another group of data already in the buffer. If so then the process above is repeated if not then the routine would exit and wait for more data to come into the port.