Fix CDC write() when DTR is not set

[NicoHood]

Fix #1182

This should not give any disadvantage. You still can check via while(!Serial); if the Serial port is opened. If you write to a not opened port this should not cause any problems. This is how other firmwares like lufa handle it. Also you dont need to set a DTR state to co0mmunicate with the device. This enables more options.

https://github.com/abcminiuser/lufa/blob/master/Projects/USBtoSerial/USBtoSerial.c#L197
https://github.com/abcminiuser/lufa/blob/master/LUFA/Drivers/USB/Class/Device/CDCClassDevice.c#L193

We could also check the baud info, but since it is set to 57600 by default this doesnt make sense. Maybe we should change this as well?
https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/cores/arduino/CDC.cpp#L34

TODO (from peter)

• Could you also modify the Due core? Will test it if needed.
• Could you also adapt the comment, it does not hold anymore
• The configured flag is not cleared upon disconnection, but that might not be that important right now.

[NicoHood]

@matthijskooijman build this please

[cmaglie]

@ArduinoBot build this please

[ArduinoBot]

Build successful. Please test this code using one of the following:
http://downloads.arduino.cc/javaide/pull_requests/arduino-PR-3839-BUILD-398-linux32.tar.xz
http://downloads.arduino.cc/javaide/pull_requests/arduino-PR-3839-BUILD-398-linux64.tar.xz
http://downloads.arduino.cc/javaide/pull_requests/arduino-PR-3839-BUILD-398-windows.zip
http://downloads.arduino.cc/javaide/pull_requests/arduino-PR-3839-BUILD-398-macosx.zip

[NicoHood]

The PR like this does not work for me I've noticed. If the host is not listening my RawHID dev sketch will block for a long time. I tried to check for baud() but this also didnt help (set the value default to zero of course).

But adding && availableForWrite() helped.

I will add this to the patch. The only thing we could also add would be baud() but that was not needed in this case. Tested under linux 64 bit elementary os.

[PeterVH]

I think testing for availableForWrite() inside write() is not correct. It looses the automatic flow control USB provides: if the process on the host temporarily does not catch up with the data you send it, the write method should block till data is sent. If this is not acceptable for an application, it should call availableForWrite() by itself.

It is not cleared on disconnect? Where do we have to handle this? (this is very important)

Just consulted the datasheet. The VBUSTI irq fires upon connect/disconnect. The VBUS status bit in USBSTA tells you the current state. Did not try this though.

[NicoHood]

Without the writeavailable my device locked up. Have to check this again. Feel free to also test it, I will not have time to debug this in the next days.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}