Fixed sweep object creation hanging

[Vrong]

This bug was causing sweep object creation to hang when trying to read the returned value from serial port. ==> Issue #72

Bitrate of the serial communication was badly set during the creation of the sweep object when using the libsweep library on Linux.

cfsetispeed(...) and cfsetospeed(...) both take a termios bitrate constant and not the bitrate directly. So should the get_baud(115200) call return the B115200 value defined in termios.h.

The fix has been tested successfully and has no limitation.

Thanks.

[dcyoung]

Woops! Seems I caused this when I removed the verbose switch statement in commit 51246f731a78ccb927c79f98367ffeedb30d7a72 Thanks for the catch. I'll give the branch a try.

Any idea why the behavior would affect the RaspberryPi but not a desktop setup? And why the issue appeared intermittent? ie: the "hanging" behavior would come and go on the Raspberry Pi.

Will have to check everything still works on Mac as well. I'll do so now.

[dcyoung]

Hmmm I implemented this fix on a Raspberry Pi 3 and witnessed the same issue (still intermittent). While it may be a good idea to fix get_baud, I'm not sure it is the cause of the hanging behavior I'm witnessing.

Additionally Travis is failing because the check for the definition is missing (removed in 51246f7 for mac compatibility). We'll have to figure out a better solution for portability there.

[Vrong]

Ok I will check it again tomorrow as I don't have the lidar now. It was definitely the reason it was not working for me. (Tested on rasperry pi 3 too) The issue was "intermittent" because another tool or software was sometime setting the 115200 baud bitrate to the serial port. For example, booting the rasp and using the libsweep API first would hang, but using it after a python serial init would set it to 115200 baud so the libsweep API would work even without succeeding to set bitrate. You can check the bitrate of the port with sudo stty -F /dev/ttyUSB0 -a By default I got 9600 bauds, and you can see it's not changing when your soft using the API starts (without the fix). However the DX write operation would work and I could get the response with a third party serial app (like cutecom or minicom) but not in my software using the API. I guess it was just a lucky serial hardware strike.
After the fix, I had no single issue as far as I tested it.

Concerning the continuous integration failing, It appears that older versions of termios.h does not define bitrates up to B115200. #define B1152000 0010011 There is the line but I'm not sure that you could just use the 10011 value and pray for it to be supported. I don't use MAC and did not do more digging on the issue. Edit: Found someone that seems to be using this definition here : http://www.bsdforen.de/threads/serial-port-under-mac-os-x.24851/

That's strange you still have the issue with the fix, maybe that's not the same issue or need to make clean or something ? 0:-)

Well I'll give you more info tomorrow. Thanks a lot for the response.

[dcyoung]

Thanks for the info @Vrong ! I'll look into this more as well.

Also, what Raspbian release are you using?

[dcyoung]

@Vrong I think the intermittent behavior I was seeing can be explained by the sequence of reboots, sweep unplugs and swapping back and forth between libsweep fixes. Now that I'm explicitly checking for it, I can't seem to reproduce the issue with the fix implemented. Checking with sudo stty -F /dev/ttyUSB0 -a does seem to validate this fix!

As for the definition check... I can't remember the exact cause of the mac incompatibility. I'll have to look again, but perhaps a quick and dirty solution could be accomplished rather simply like so:

#ifdef B115200
    return B115200;
#endif
return 115200;

Edit: Added a branch with this hack... fedce13c63ce594a0824ea3e0d5e0a26c5d03bbb

This allows systems with B115200 defined to use the definition, and systems (apparently like macOS) that don't recognize B115200 to avoid error. I'm not sure why MacOS is fine using speed_t = 115200. I looked through some apple docs and it seems there are elements of the IOKit that can be used with ioctl to set non-standard baud rates... but I really don't think we should have to do this.

Currently, this hack would not still cause a hang on a hypothetical system which doesn't recognize B115200 but cannot use speed_t = 115200. Not sure what system that would be or how to look for it. Perhaps a better route would be to check for MacOS and conditionally provide speed_t = 115200, and throwing an error if B115200 is not defined on linux??

[Vrong]

Ok I messed with my repo so I created a new one to keep it clean sorry ==> #117 .