I have been unable to find a solution to reset an Uno with the same protocol used on the serial port when uploading code. I know that the DTR line from the serial interface chip is the control for this, and I would like to be able to reset the device from the terminal directly. I do not want to implement a watchdog, and it is common practice to avoid using its own GPIO to pulse ~RESET low.
The UNO already has AUTORESET on upload. (at least with the USB port). What do mean by serial ? Do you mean using pins 0 & 1 ?
I would like to mimic whatever is sent via USB to initiate the UNO to autoreset. That way if my host PC is unable to communicate with the device over the USB port due to the UNO hanging, I can reset the device with a software command instead of implementing a hardware solution. In the final setup, I will not be able to initiate autoreset on upload.
Ideally, there should be some prompt I can send via COM port terminal to the USB port that instructs the device to autoreset just as it does when uploading code. Its just a matter of pulling DTR low (the ATMEGA8 pin 13).
pfosk:
I would like to mimic whatever is sent via USB to initiate the UNO to autoreset. That way if my host PC is unable to communicate with the device over the USB port due to the UNO hanging, I can reset the device with a software command instead of implementing a hardware solution. In the final setup, I will not be able to initiate autoreset on upload.Ideally, there should be some prompt I can send via COM port terminal to the USB port that instructs the device to autoreset just as it does when uploading code. Its just a matter of pulling DTR low (the ATMEGA8 pin 13).
The way to reset an attached arduino via a COM port is to toggle either the DTR or RTS control signal on then off, the arduino board will handle the rest as it does when the IDE uploads a new sketch. The COM port in any PC has a way that any attached application program can access and control the serial control signals just as the IDE does. On many PCs just closing and opening the COM port causes a arduino board reset if it's connected to the PC.
Lefty
I think he's trying to ask for the name of the command and syntax. I don't know the answer.
pfosk:
send via COM port terminal
You need to toggle the RTS signal. The COM port client should enable you to do this sort of thing, but precisely how you do it will depend what client you're using. For example, using Realterm you can control the signals directly via the GUI. If it's an application you're writing yourself, you can use an ioctl operation to read and modify the signal states.
PeterH:
You need to toggle the RTS signal.
Not necessarily.
RTS and DTR are not the same.
You will need to toggle which ever signal is wired up to the autoreset circuitry on your board.
When the FTDI serial cable is used, RTS is connected to the auto reset circuitry.
On the Uno boards, DTR was wired up when FTDI chips were used.
Now with the Atmel chip that replaced the FTDI chip, it is under f/w control inside
that Atmel chip, but the default code that shipped in it, looks for the virtual
DTR signal and so DTR will need to be toggled rather than RTS.
Since the Atmel chip does have the autoreset function set in firmware to pull DTR low at the initialization of the COM port, I think the best solution would indeed be to use an iocntl operation on my host pc
I would like to be able to reset the device from the terminal directly.
I'm going to interpret this slightly differently that others.
The RESET signal of the AVR is connected to the DTR output of the USB/Serial converter chip.
When the USB host computer "changes DTR" from software, it causes a USB-level "control" message to be sent to the USB device that implements the USB/Serial conversion, and it responds by changing the actual hardware signal, which causes the AVR to reset.
Since this is a "control" message, it is essentially happening on a completely separate channel than the serial data, and there is no way to cause the AVR to reset by manipulating only the RxD/TxD data that go to the AVR. You can only cause the auto-reset via the USB connection.
And as Crossroads pointed out, the USB is a slave port.