Getting garbled text in Windows serial port

[johnlauer]

Hi there,

I'm using this library via Faccinm's version for the Arduino.cc Web IDE Bridge which is actually using Serial Port JSON Server. However, since I've moved to this library I'm getting garbled text on Windows. On Linux I don't get any problems. Have you seen this problem before or am I blazing new territory here such that I'm the first to see it?

The project using your code is: https://github.com/arduino/serial-port-json-server

My project is: https://github.com/johnlauer/serial-port-json-server

I used to use this serial library. https://github.com/johnlauer/goserial

The old serial lib did have port closing problems and your library doesn't, which is awesome, but I never got garbled text with the other library. Is it possible just default settings are off? I've tried lots of tweaking to parity and stop bits to no avail.

Thanks, John

[cmaglie]

John,

sorry for the long delay.

I never experienced the garbled contents you're getting, may you provide a small code snippet to reproduce the issue?

[johnlauer]

Sure. Just install this .hex file below onto an Uno and you'll see what happens. This is the popular Grbl for open source CNC control. I have a ton of users who use this and they're all complaining that the new serial library has broken everything but only on Windows. Linux and Mac users using this serial library are having no issues, so it does show that this is a Windows only bug.

https://raw.githubusercontent.com/grbl/grbl-builds/master/builds/grbl_v0_9i_atmega328p_16mhz_115200.hex

[cmaglie]

Thanks, I guess I'll be able to try this out on a Windows box tomorrow.

I never tried GRBL before, shall I send some particular commands to the Arduino to get the "problematic" output?

[johnlauer]

In my screenshot above, the lines with the checkmark are commands I'm sending to it. So, yes, trying sending just a $ or a $$. Those are the typical "give me my settings" commands and you'll see when it sends back things are all mangled. If you try this from Linux or Mac on the same Arduino Uno things will be just fine.

[cmaglie]

I'm sorry to say that it's working for me:

the test I've used is this one:

package main

import "go.bug.st/serial"
import "fmt"
import "log"
import "time"

func main() {
    ports, err := serial.GetPortsList()
    if err != nil {
        log.Fatal(err)
    }
    if len(ports) == 0 {
        log.Fatal("No serial ports found!")
    }
    // List com ports
    for _, port := range ports {
        fmt.Printf("Found port: %v\n", port)
    }

    mode := &serial.Mode{
        BaudRate: 115200,
        Parity:   serial.PARITY_NONE,
        DataBits: 8,
        StopBits: serial.STOPBITS_ONE,
    }
    port, err := serial.OpenPort("COM33", mode)
    if err != nil {
        log.Fatal(err)
    }

    // Wait for grbl prompt
    time.Sleep(100 * time.Millisecond)

    n, err := port.Write([]byte("$\n$$\n"))
    if err != nil {
        log.Fatal(err)
    }
    fmt.Printf("Sent %v bytes\n", n)

    buff := make([]byte, 100)
    for {
        n, err := port.Read(buff)
        if err != nil {
            log.Fatal(err)
            break
        }
        fmt.Printf("%v", string(buff[:n]))
    }
}

can you confirm that? may the problem be due to some processing you do on your side? what happens if you try to print in console the buffer returned by Read without further processing?

[johnlauer]

Oh boy. I will do further testing. That's super odd. Thank you for running the test. I am baffled over here because I ran a bunch of tests and I have gotten perfectly fine output on the Uno except with the Grbl firmware.

[cmaglie]

@johnlauer I don't know if this issue is still valid/interesting for you (I don't even know if you still use this library :-)), so for now I'm closing it.

If you want to investigate further, feel free to open another issue!