I have a project that I would like to use the USB to collect datalogged data. I also would like to be able to update the firmware image in this way.
My understanding was that it's the DTR/DSR handshake that triggers the reset, so I downloaded PuTTY (whose logfile function would allow me to capture the datalog data) but I set its serial interface (directed to the same COM port as the Mega is plugged into) to use NONE for flow control. However, it still resets the Mega when I connect.
I am aware there is a hardware approach to place a 10 uf cap across the reset line, but then I have to do the reset manually via a series switch on the cap. (I cannot get to the on board Mega reset switch due to a shield.)
Anyone come up with a way to do what I need to do? Is there another terminal emulator known to work?
If it is worth the extra expense you could use a USB-TTL cable (aka FTDI cable) to connect the PC directly to the Rx Tx and Gnd pins and not use the Arduino USB connector.
But that would not allow you to upload code without pressing RESET. I guess you could disconnect the FTDI cable from the PC and use the regular USB cable to if you need to upload code.
Another option, of course, is to wire a remote reset button and just disable the auto reset.
It resets when you plug in the USB. So what? This would only interrupt your data-logging function for that brief moment - what is so critical about the data that such a brief interruption would matter?
It resets when you plug in the USB. So what? This would only interrupt your data-logging function for that brief moment - what is so critical about the data that such a brief interruption would matter?
Probably because the data is stored in ram and gets lost when it resets....?
I think the reset is when the com port is opened. and its the com port driver on windows that sends the reset.
Yes you could rewrite the firmware on the USB to serial chip (Arduinos have stoped using FTDI's) or you could use a Leonardo or Yun, but then you get the pain of the reset.
holmes4:
I think the reset is when the com port is opened. and its the com port driver on windows that sends the reset.
Mark
Is it not, then, the DTR/DSR handshake as reported in other threads here that sends the reset? On my 8.1 machine the "com port driver" is the virtual com port USB driver provided by FTDI, shown here.
You make a good point, but there is a display screen with a graph full of data on it that I wanted to avoid a somewhat tricky save and restore after a reset.
revwarguy:
You make a good point, but there is a display screen with a graph full of data on it that I wanted to avoid a somewhat tricky save and restore after a reset.
You said in your original post that you know about the method of disabling the auto-reset feature but your objection to that is the (my assumption) occasional need to press the reset button which would not be accessible. As I said in Reply #3 it would be an easy matter to wire up an accessible reset button. I also suggested other, more complex/expensive solutions.
So ... what exactly is the problem?
Modifying the USB driver would be a complete waste of time - even if you know how.