No EOF on ARM

[jerbob92]

I'm using this library on ARM (Raspberry Pi), I never seem to receive an EOF.
When I tested it on my laptop it worked fine. Is there possibly a difference between the two?
(I use github.com/mitchellh/gox to cross-compile)

[xiegeo]

Can you show some minimum code that demo this? Include what you do to trigger EOF, and what hardware you use for serial connection.

I don't test for EOF in my own usage so I'm not sure how it's supposed to work, or how you are using it, but I can try reproducing it on my rpi-3 and I develop in Windows, since I'm interested in knowing and possibly eliminating any inconsistencies.

[amery]

I'm not getting EOF on intel either

https://gist.github.com/amery/eb19d400faf684fc92f677fed3eb7b86

package main

import (
        "io"
        "log"
        "time"

        "github.com/tarm/serial"
)

func read(buf []byte, f io.Reader, done chan error) {
        log.Println("Read")
        l, err := f.Read(buf)
        log.Println("Read", l, err, buf[:l])
        done <-err
}

func main() {
        tc := serial.Config{
                Name:     "/dev/ttyUSB0",
                Baud:     9600,
                Size:     8,
                Parity:   serial.ParityNone,
                StopBits: serial.Stop1,
        }

        port, err := serial.OpenPort(&tc)
        log.Println("OpenPort", &tc, port, err)

        if err == nil {
                var buf [256]byte

                done := make(chan error, 1)

                go read(buf[:], port, done)

                time.Sleep(time.Second * 2)

                err = port.Close()
                log.Println("Close", err)

                err = <-done
                log.Println("Done", err)
        }
}

but f.Read() never ends

2018/05/03 01:47:13 OpenPort &{/dev/ttyUSB0 9600 0s 8 78 1} &{0xc420096018} <nil>
2018/05/03 01:47:13 Read
2018/05/03 01:47:15 Close <nil>

[xiegeo]

Thank you @amery, I can reproduce that on rpi with a USB serial device too. I feel that the problem is from the underlining USB driver, since read and close just forward the calls to the file handler, but have not got around to isolating the problem yet.