Do you guys find it annoying that you need to close the serial port before uploading a sketch? The IDE does this automatically but it's still annoying.
LUFA actually has a dual virtual serial port example, so why not adapt that and use two virtual serial ports so the "debug" port can remain open while the "upload" port is working?
Because the ATmega328 only has one serial port, too? Or did you mean only for the MEGA? (the 8u still only has a single serial port as well, even if LUFA is capable of supporting more...)
I've been wondering if it would have made sense to use a larger chip for things like the ethernet/uno combo. You might be able to put the SD Card interface and ethernet on pins that wouldn't interfere with the normal D0..13 and A0..5
Though that would destroy compatibility, I guess...
I think you don't understand.
Physically there will still be only one serial port
Virtually, the Arduino Uno will show up as two serial ports
Both of the virtual serial ports will still operate the single physical port
But, the computer will only require one of the two virtual serial ports to be closed before uploading, while a second serial terminal can remain open
frank26080115:
Virtually, the Arduino Uno will show up as two serial ports
Why not use some means of interprocess communication (IDE to Monitor) and have serial monitor close/reopen the port before/after upload rather than force a close of the monitor application?
I envison this would be a fairly simple extension to program and would also be backwards compatible with the older FTDI designs.
BenF:
frank26080115:
Virtually, the Arduino Uno will show up as two serial portsWhy not use some means of interprocess communication (IDE to Monitor) and have serial monitor close/reopen the port before/after upload rather than force a close of the monitor application?
I envison this would be a fairly simple extension to program and would also be backwards compatible with the older FTDI designs.
That will only solve the problem for the Arduino IDE, which I do not use
People use terminals such as RealTerm or Tera Term, how would you handle creating interprocess communication between all the different possible terminal software and the IDE?
The dual virtual serial port solution will not have such a problem
There's a small challenge to solve
When avrdude finishes uploading, there needs to be a way for the baud rate to be set back to whatever it was before avrdude was used.
The firmware does not really have indication of which serial port is used for normal use (I'll refer to this as the "application") and which one is used for bootloading, it needs to know this in order to switch baud rates correctly
It's easy to remember both baud rates and switch them right before the transmission, but when the bootloader is finished, the baud rate should switch back to the application baud rate in order to start listening from the ATmega328P, this is the challenge
The best solution is to check which virtual port is open, the problem is that I do not know how to do this
One possible solution is to assume all baud rates that is not 115200 (used by optiboot) to be "application", and switch to listening on the "application" baud rate whenever the "Q" character is received, as "Q" is the command to exit the bootloader. 99% of the time, this should work. For that 1% edge case, a simple closing-then-reopening of the port is required.
I'm assuming this method would not work for those "applications" that use a baud rate of 115200?
it would, if both baud rates are 115200, then it'll just stay the way it is
in fact, using 115200 is encouraged