[WIP] Rework serial ports handling #4482
Conversation
Replaces arduino#4280, only checks for the bootloader once Tested with Hoodloader2, should work with every LUFA-derived bootloader released after 2014 (.apitable_signatures section must be placed at end of the flash) BootloaderAPITable.S : .global BootloaderAPI_Signatures BootloaderAPI_Signatures: .long BOOT_START_ADDR ; Start address of the bootloader .word 0xDF00 ; Signature for the CDC class bootloader .word 0xDCFB ; Signature for a LUFA class bootloader makefile: BOOT_API_LD_FLAGS += $(call BOOT_SECTION_LD_FLAG, .apitable_signatures, BootloaderAPI_Signatures, 8)
Disable Compile/Run buttons as they get press, and reenable only on function exit. The launched upload process has now a 2minutes timeout before being terminated forcefully. 10 second after pressing "Upload" the button comes pressable again, but this time the previous upload command gets killed explicitely
This commit introduces the concept of stateful board list (vs. original stateless) and board serial number. The board is now an "entity" composed by the triplet port/vid/pid. These informations come from libListSerial "light" function. When the board list changes, it triggers a request for the additional infos to libListSerial. These information contains the serial number of the boards. These brings a lighter and faster scanning process. Some logic has been introduced to handle a board with the S/N only exposed in the bootloader (like 32u4). In this case the disappearing port acquires the bootloader's S/N A menu (under Ports menu) shows the currently connected port info and can be used for bugreporting
|
Will the new bootloader just fix what we suggested or be totally different? I mean I see no difference regarding the bootloader for the serial port access. Just that its time to do it ;) |
|
Hi Nico, |
|
Uhm I want to mention a few things: 16u2 usb-serial
32u4 Bootloader
So there are some things that I'd improve. If you want to chat with me about that outside github, for a faster communication, feel free to add me on tox. It would be nice to know what you are planning, maybe I can help you to give ideas/suggestions. |
|
Hi Nico,
BTW, I couldn't find you on tox, but I'd really enjoy some chatting about these things! |
|
You might want to try the tox ID, not the short name. It worked for a lot of people before. |
|
Are you planning to add the double tab reset? |
The current method of reporting upload errors is based on an exoteric combination of exceptions which makes return error code useless The Uploader.java message() implementation is too avrdude-dependant to allow easy portability since the upload tools are becoming a lot and very different With this commit we try to avoid exceptions and only use the external uploader's exit code to decide the status bar message. The message can be: - the last line containing "error" string (any case) or - the usual avrdude message parsing (to keep compatibility with translations) Needs testing with all platform and all supported upload tools
by doing so, runtime variable are resolved by using the board specific tools
real life example:
- Intel i585 defines sketchUploader (version 1.6.2)
- Intel arc32 defines sketchUploader (version 1.6.4)
- runtime.tools.sketchUploader.path gets the value of the last one processed
with this PR
runtime.tools.sketchUploader.path.Intel.arc32 and runtime.tools.sketchUploader.path.Intel.i586 get created
when resolving {runtime.tools.sketchUploader}, the routine searches for a key runtime.tools.sketchUploader.Vendor.Architecture
If found, the value is obtained by {runtime.tools.sketchUploader.Vendor.Architecture}.getKey(), which always contains the required value.
If no value is found, the old methos is applied
OS X 10.11 seems to be slower, increasing timeout to 5s on all platforms to keep things simple.
…source busy" errors on open
This reverts commit a86176d.
If a sketch contains a link to http://librarymanager/${dropdown}#${filter} or http://boardmanager/${dropdown}#${filter} (for example http://librarymanager/All#OneWire) Library or Board manager will be opened applying the secified filters
facchinm
force-pushed
the
iserial2_complete
branch
from
8326236 to
d1516f6
Compare
facchinm
force-pushed
the
iserial2_complete
branch
from
2c564e6 to
02a4200
Compare
|
✅ Build completed. Please test this code using one of the following: ⬇️ http://downloads.arduino.cc/javaide/pull_requests/arduino-PR-4482-BUILD-531-linux32.tar.xz ℹ️ The |
|
No difference here. I was directed this way from http://forum.arduino.cc/index.php?topic=388498.msg2681245#new - that hopefully this pull is related to the 1.6.8 bug that causes all serial ports to be constantly open/closed. That issue is still present with the above auto-build version, now confirmed on multiple PCs with different OSes (first was W7 x64, this time is W10 x64). Because Arduino is opening the port (at all, in any way/shape/form), it toggles DTR pin and resets the Arduino board once/second. This is unique to Windows, as it's a "feature" of the FTDI driver that avrdude relies on for auto-resetting boards. Opening the ports constantly also ends up with a 50/50 chance that when I try uploading a sketch or open Serial Monitor, it'll run into the port scanning in process and will give "access denied" against the already-open port used by Arduino. I'm working with the Arduino Pro Mini (5V/16MHz) and FTDI Basic Breakout board from TinySine. Can we completely avoid opening the serial ports? |
|
@FalconFour , thanks a lot for reporting this. |
from listSerialsj library 1.0.8 the serial polling is executed using the listComPorts method (which is much more cpu intensive than the previous one) to avoid bug arduino#4700. The 3 second poll rate is needed to avoid cpu hogging
facchinm
force-pushed
the
iserial2_complete
branch
from
70d6643 to
dfe75e8
Compare
|
✅ Build completed. Please test this code using one of the following: ⬇️ http://downloads.arduino.cc/javaide/pull_requests/arduino-PR-4482-BUILD-533-linux32.tar.xz ℹ️ The |
Following the work with the native jni library for serial discovery and preparing for the new bootloaders release (#2474, we are stressing them really hard 😄 ) , this commit introduces a new concept (stateful ports) and fixes a number of existing bugs.
The most important patch (91b94c8) needs to be reviewed by a Java expert to check if there is any huuuuge mistake I probably made somewhere (scopes, static or things like that).
Comments appreciated 😉
@cmaglie @matthijskooijman @NicoHood @PaulStoffregen