|Summary:||devel/arduino18 sends constant resets to attached boards|
|Product:||Ports & Packages||Reporter:||Christopher Hall <hsw>|
|Component:||Individual Port(s)||Assignee:||Kyle Evans <kevans>|
|Severity:||Affects Only Me||CC:||bsam, emaste, kevans|
|Bug Depends on:||230843|
Description Christopher Hall 2018-01-27 03:31:10 UTC
I installed devel/arduino18 (1.8.2_2) on TrueOS/unstable FreeBSD 12.0-CURRENT #13 5085b9023(trueos-master) I am encountering two problems. 1) The arduino18 IDE does program both Uno and Mega1280 but the sketch does not run; the boards are getting continuously reset. It appears to be caused by the Arduino IDE constantly opening and closing files in /dev/usb - I expect it is trying to determine which USB devices are serial ports. 2) The Leonardo does not program and the programmer times out. The Leonardo uses AVR with on-chip USB so I expect the reset causes its USB stack to restart and then FreeBSD kernel must scan the USB bus again. Some times it will change fro cuaU0 to cuaU1. I just found a work around for problem 1 - keep the serial monitor window open as this appears to stop the IDE scanning this port, and it can be left open even when programming. On the same machine Arch Linux programs all three board types successfully, so I do not think there is any hardware problems, though it is a slightly newer version of the IDE: 1.8.5. Is anyone running this successfully on other FreeBSD versions?
Comment 1 Kyle Evans 2018-01-27 04:42:30 UTC
Hi, Crap, sorry, I knew about this problem and forgot to get back to it. =( Your diagnosis is correct. I need to get with bsam@ and figure out the proper way to solve it. It doesn't show up on Linux because libserialport separates Linux, Windows, and BSD. On Linux, it enumerates serial devices and only opens them if they're from a specific driver. On Windows, it enumerates them based on the registry so it knows what's OK. On FreeBSD, it opens all cuaU* devices it finds. I'm tempted to just cut that behavior out completely. There's no way to prevent open from frobulating DTR (I believe it was DTR at least), even with .lock/.init nodes. I'm not yet sure if we can find a common solution to this for libserialport or if we need to just create an Arduino libserialport that doesn't do this anymore.
Comment 2 Kyle Evans 2018-07-17 13:47:51 UTC
Created attachment 195195 [details] svn(1) diff against devel/libserialport Hi, Sorry for the delay. Please try the attached patch against devel/libserialport- it changes its battery of tests to just an eaccess(2) call that won't assert DTR on the serial line. I intend to submit this to upstream ASAP.