distributed / sers

Serial port access for the Go programming language.
MIT License
38 stars 7 forks source link

Baudrate can not be changed under Linux #2

Closed dh1tw closed 8 years ago

dh1tw commented 8 years ago

Hey Michael,

thanks for the swift response on the example!

I've set up sers and it seems to work - however the baud rate is fixed at 38400. Whatever baudrate I specify (e.g. 9600, 19200.... or a custom one 69500) it remains at 38400 bit/s.

err = mySerialPort.SetMode(19200, 8, sers.N, 1, sers.NO_HANDSHAKE)

I'm writing the code on a Raspberry Pi / Raspbian (Debian Jessie) and I'm using the UART which is located on the GPIO pins.

In order to verify the mentioned behaviour, I write the same character in a endless loop to the UART while monitoring it on my Oscilloscope (which is able to decode RS232 on the fly).

Writing a small test program in Python verified also that an arbitrary baudrate can be set on the Raspi's UART.

I would very much appreciate if you could give me a hint or maybe fix this. Your library is very valuable, since it seems to be the only on in Golang to support arbitrary baudrates.

Thanks!

distributed commented 8 years ago

No problem!

It sounds a bit like Linux isn't accepting the custom baudrate. In order to set custom baudrates, you need to set the rate to 38400 and also set some magic bits. This is of course, what my library should do for you.

I have a Raspberry Pi 1 B and an oscilloscope. Can you please provide a minimum example showing the problem, including instructions on how you build?

I'm glad that you find my library useful. Custom baud rates are basically the only reason I wrote it and as an electronics enthusiast I find it very useful. I hope this functionality will be included in the upcoming x/term repo: https://github.com/golang/go/issues/13104

dh1tw commented 8 years ago

Hi Michael,

thanks for the swift reply!

here is s minimalistic example I use to reproduce the problem:

package main

import (
        "github.com/distributed/sers"
    "fat"
    "time"
)

func main() {

    head,err := sers.Open("/dev/ttyAMA0")
    if err != nil {
        fmt.Println(err)
    }
    err = head.SetMode(57600, 8, sers.N, 1, sers.NO_HANDSHAKE)
    if err != nil {
        fmt.Println(err)
        fmt.Println("not working")
    }
    _ = head.SetReadParams(1, 0.01)
    for {
        _, _ = head.Write([]byte{144})
        time.Sleep(time.Millisecond*10)
    }
    head.Close()
}

if this package is located at github.com/dh1tw/mySerialPort

I just build it with the following command:

go install github.com/dh1tw/mySerialPort

I'm using a Raspberry Pi 2, however I think there are no differences concerning the UART on Raspi 1 and Raspi 2.

distributed commented 8 years ago

Thank you for the repro case. Can you please also provide your Python program so I can cross check? :) I'll get back to you when I had a chance to run it on my Raspberry Pi.

dh1tw commented 8 years ago

Hi Michael,

sure - here is the python code:

import serial
from time import sleep

head = serial.Serial("/dev/ttyAMA0", 9600, timeout=0.01)

while True:
    head.write('\x90')
    sleep(0.010)

You need the pyserial library (pip install pyserial).

Thanks a lot!

distributed commented 8 years ago

Thanks.

I was able to reproduce the problem you described - but only using /dev/ttyAMA0, the built in UART. When I attached an FTDI USB-to-serial converter, sers worked as I expected. In fact, this is how I tested sers under Linux ;)

I created a new branch issue2, please check it out. In this branch I'm using struct termios2, supposedly the new way of setting arbitrary baud rates under Linux. Now baud rate settings take effect for both /dev/ttyAMA0 and the FTDI chip.

I also checked in your repro cases. I have taken the liberty of slightly rewriting the Go program to use flags (compiles on the Pi are sllloooowwwww) and to bail out on every error. It's really useful to not miss returned errors.

Does the fix work for you?

dh1tw commented 8 years ago

Ok - it seems we overlapped. Apparently we found the same solution :-)

I just checked out your branch "issue2" and I can confirm that the problem is solved. So you can disregard my pull request.

Thanks!

distributed commented 8 years ago

I have rebased the changes into master.