Hi, One of the really nice features of the Arduino IDE is that the serial monitor can be used on the same port used to program the target board.
I am targeting the Fubarino-SD and am not able to open the Serial Terminal on the programming com port - the IDE reports 'port already open'. There must be a way that the serial port can be switched between the two tasks.
Why is this so useful? Well every sketch that I have seen makes use of Serial.begin() and talks back up the programming port. Sure they can be changed, but not every board has a Serial0 (which would then require a USB to Serial conversion to use).
So, are there plans to allow such functionality?
On a related issue (probably should post this under the ChipKIT section): Of course, the Fubarino (and others) have a bootloader that is entered (deliberately) at reset time with the PROG switch. This probably means that the functions in the bootloader that support the serial communications can not be accessed in run mode. Are you aware of an equivalent serial driver that would support Serial.print() in run mode?
Or maybe I have missed a trick somewhere!
I have never come across that kind of problem before. Pretty much all the boards I use and make are of the same style as the Fubarino - a CDC/ACM bootloader and CDC/ACM for the USB serial communications in the sketch.
Of course, the bootloader and sketch communications are separate and always will be. On Windows it is common for the bootloader to use a different COM port to the "run mode" as you call it - and that is windows's problem. It is possible to edit one of the USB devices to change which COM port is assigned to it so that the two match up, which can simplify things a little since they are then both seen as the same thing.
None of this, however, has anything to do with UECIDE. What is puzzling though is the "port already open" message you are getting. If you have selected the bootloader COM port and that COM port is no longer there because you are in "run mode" with the COM port associated with that then I can see there may be a problem - you just need to select the right COM port and it should open.
Port already open sound like a common message under windows. In contrast to Linux, windows is handling ports very badly. If you have opened a serial monitor and then flashed the device, the process that opened tha port will become a zombie. The only way to recover from that state is to disconnect the board and reconnect (that is why I have a USB hub with on/off switch for each port) There is nothing that can be done on UECIDE side. It is a windows issue
If there is some other process or thread holding the port open when it should be closed it would be very interesting to know what it is. It may be a timing issue with Windows not releasing the port fast enough from a previous operation (maybe
pic32prog after programming?) and adding a period of retrying with the opening in UECIDE may work around the problem.
Also the problem in Windows of the COM port being different depending on your sketch is only going to get worse. We have a new USB stack with flexible interface combinations on the way and each pre-defined combination of interfaces (CDC/ACM, Keyboard, Mouse, etc) will have its own VID/PID combination, so depending on what profile you have selected will determine the COM port you get handed when running. So you will have to make good use of the port name changing option in the device manager to map them all to something sensible.
The whole way windows handles port names and "special" devices has always been a bone of contention amongst power users. I haven't tried in Windows 10, but certainly up until windows 7 there were certain words that could never appear in filenames because Windows assumed they were port names. Even when it was blatantly obvious when they are filenames. All because Microsoft decided that the
: should be optional. Trying to treat a device like a file when that device is not part of the filesystem really was one of the most idiotic things they ever did back in the DOS days.
Hi, I am not sure I understand fully the replies, or how they help my situation. I'll try restating the problem as I see it and that may be helpful.
With the Arduino IDE I set the port to (say) COM5. This port is then used for both the programmer and the serial monitor - it switches seemlessly between them so that I can leave the monitor open while programming.
I am not able to do this with the Fubarino-SD IDE - I set the port, it is used for programming, and I cannot open the Serial Terminal. It would be very nice if the UECIDE could behave the same as the Arduino IDE in this regard. From where I sit this does not seem to be so.
Maybe it is related to the Fubarino(-SD) board as it requires a user press of buttons to enter programming mode which is not required for Arduino boards.So perhaps what is needed first is to accurately determine if it is board or operating system related. From that we may be able to define a way to resolve it.
I have been looking at ways of detecting the change of a COM port and auto switching between "run" and "program" modes. I have, in the latest release, included some test code that can be integrated into a programmer to wait for the programming COM port to appear.
However it doesn't help with the likes of the Fubarino with the program button, since it relies on the "run" mode COM port being there at the beginning of programming and the IDE switching the board into "program" mode and watching the list of COM ports to see what vanishes and appears at that time. Windows is a problem with that though - all I can do is look for new COM ports, not pair them up with a USB VID/PID pair to make sure it's the right device.
Personally I don't like CDC/ACM based bootloaders and would rather use a HID one (such as AN1388) that doesn't give a COM port at all for programming - it's all identified through the VID/PID combination.
I am wondering if there may be a way I can select two COM ports at once in the IDE - one for programming and one for serial comms. Maybe separate out the Serial Terminal from the "port" in the IDE so it can use its own selector for which COM port to use.
Oh, and the new USB stack for chipKIT that I have been working on also includes the 1200 baud reset-to-bootloader method that Arduino boards like the Leonardo use. It makes it more fluid for programming and helps with the COM port detection.
Ok, I have released an experimental new programmer plugin for you to try.
It requires 0.8.9-pre17 to work. If it works. I can't test it on Windows at the moment.
Keep the board in RUN mode and select the COM port. Go to program the board - it will tell you to press RESET + PROG at the right time, and try to find the right COM port when you do. It should then program, and go back to RUN mode with the COM port you had already selected before.
Let me know what mileage (if any) you get from it.
I have gone through the Plugin Manager but don't see any entry for Experimental.
I did install the 1200baud programmer and the Manager reports I have two PIC32 programmers being 'PIC32prog' + 'PIC32prog 1200 baud' - each has a green tick beside it.
Having done the above, plus restarting the IDE, it only reports a single programmer with a message: 'upload to ChipKIT board via pic32prog'.
Have I missed a step?
Did you refresh the contents of the plugin manager?
I presumed that the Plugin Manager would refresh itself automatically when opened but refreshing did show the new programmer.
This was installed but using the experimental programmer displays: "Uploading firmware... • Uploading with STK500v2 protocol ? Press RESET + PROG now! 1"
The last character is a '1' and the board remains in programming mode (fast LED flash).
And have you upgraded to 0.8.9-pre17?
... It requires 0.8.9-pre17 to work. If it works. I can't test it on Windows at the moment. ...
Actually I see the same problem. It's not the programmer, it's the board.
You need to modify the board.txt for your board to include the VID and PID of the board when it's in programming mode.
Another option is to create a file
sketch.cfg in your sketch and add the lines to that. That will have the same effect as editing the board (anything put in there overrides the board, core, and compiler settings).
Hi Matt, I can confirm that I am running 0.8.9-pre17 and I added the vid/pid lines to the sketch.cfg. Following the prompt on screen the system picked up the board and fully programmed it.
However, even from a fresh start of the IDE I cannot activate the Serial Terminal. Error: Port name - COM17; Method name - openPort(); Exception type - Port not found.
What is COM17? Is that the programming COM port?
You are right - Windows identifies the board as COM17 and that is what the programmer detects and uses.
Serial Terminal is also attempting to use this port.
Ok, so maybe my port detection code is remembering the programming port as the default port after it has been used for programming... I'll have to look at how to get around that. I thought I was only setting it for the duration of the programming script, but maybe it's keeping it for the editor session as well (which means it's getting stored in preferences against that board).