When receiving data, one segment of data is divided into two segments about serial

[paocalvi]

Excuse me, but you cannot assume that the data will arrive exactly as you send it, in term of blocks. Serial cable could be long and subject to interference, in theory. Your receiver should deal with fragmentation and reconstruct the packet at destination. Only thing that you are allowed to assum is that what is sent first, will arrive first. Well written software should deal with different timing on sending and arrival unless you have strict specification on this on trasnmitter, receiver, and cable, at physical level.

…

On Thu, May 31, 2018 at 5:58 AM, IceCreamHacker ***@***.***> wrote: Main Environment OS: win10 x64 GO env: GOARCH=amd64 ` package main import ( "fmt" "github.com/tarm/serial" "log" ) func main() { fmt.Printf("lanuch server \n") c := &serial.Config{ Name: "COM3", Baud: 115200, //ReadTimeout:time.Second *5, } s, err := serial.OpenPort(c) if err != nil { log.Fatal(err) } buf := make([]byte, 128) for{ n, err := s.Read(buf) if err != nil { log.Fatal(err) } fmt.Printf("%q", buf[:n]) } } ` [image: image] <https://user-images.githubusercontent.com/18309699/40760470-86ae176e-64c9-11e8-8a31-f00127fa6e57.png> When I send "123456 ", data is divided into two segments part A: "1" partB : "23456" — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#83>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APDv1a0V774T1NrAKru7lKlbafTgkvfFks5t32pcgaJpZM4UUYdX> .

[elegantm]

sorry,may the serial tool bug . Virtual Serial Port Driver not exactly baudrate emulation.
I test serial port with baudrate emulation.
test A: disable baudrate

test B: enable baudrate

one segment of data is divided into many segments
@paocalvi

[tarm]

With serial communication there is no "packet" like there is on Ethernet, UDP, etc. Some protocols may use a particular character as a delimiter (like '\n') but other protocols just send bytes. The serial library does not make any assumptions about the delimiter so that it can be used in different contexts.

In addition, serial is very slow by modern standards. At 115200, it might take ~1ms for 10 characters to arrive. Instead of waiting for a delimiter or waiting for a timeout before returning the buffered bytes, the serial library will immediately return as soon as there are any bytes in the buffer (even the first byte), but will block if there are no bytes waiting. With the provided serial API, you can build support for many different protocols in an efficient manner whether the protocols are newline delimited or have some other structure.

[elegantm]

@tarm @paocalvi thank you . Thank you for your guidance