With an Arduino Uno, the sketch restarts whenever the Serial Monitor's window is opened or reopened. This ensures that all serial communication is captured. On other platforms, including the emonTx, this is not the case.
Having written various sketches which involve interaction with the user, it's a pretty fundamental problem when the up-front display and the first user-prompt get lost. In particular, this problem affects "Tallymode", which is the built-in calibration routine for my Mk2 PV Router designs. If users are to be encouraged to use the standard OEM sensor board, then some easy means of not losing Serial data needs to be found.
Pin1 of the Atmega chip is its reset line, and this can be pulled low to restart the sketch. From the emonTx layout diagram on Solderpad, it can be seen that this line is routed to pin 5 of the SPI/ISP connector, which is conveniently opposite a Ground pin. A simple switch between those two points would therefore provide a convenient hardware reset facility.
Via a capacitor, the same reset line is also taken to the FTDI connector which is where the in-line programming board is attached. This begs the question, 'Why can't a reset command be issued via the programmer?". Maybe it can ...
Another workaround might be to connect a spare digital pin to the reset line in some convenient way. The sketch would then have some means of restarting itself when necessary. The user could simply type 'z', or whatever, to restart the sketch at any occasion when a user-input is being sought. If SIL header strips were fitted, the relevant pins could be joined by a plug-on jumper lead.
Or an individual socket could be soldered to each of the relevant pins, with a jumper lead simply plugged between them.
Re: Resetting the processor
Another workaround might be to connect a spare digital pin to the reset line in some convenient way. The sketch would then have some means of restarting itself when necessary.
I think you'd need some external h/w assistance there. Once that GPIO pin yanks /RESET low that pin can no longer be relied on to keep /RESET low (it's in the process of becoming tri-stated), so you can't guarantee the minimum pulse required to ensure a clean reset.
You could try jumping to 0. That will start your sketch over, but won't issue a h/w reset. That could be problematic if the code relies on h/w registers being in a known state as a result of a hard reset.
Using the watchdog could be another option. One of my projects has a command that tells it to stop patting the watchdog, and that results in a clean hard reset. That of course assumes your particular AVR processor includes a watchdog, and that your bootloader has been coded to cope with it being enabled.
Re: Resetting the processor
Via a capacitor, the same reset line is also taken to the FTDI connector which is where the in-line programming board is attached. This begs the question, 'Why can't a reset command be issued via the programmer?". Maybe it can ...
That pin is typically connected to DTR (or maybe RTS?) on the USB->Serial dongle. That way the host computer can force a reset (by toggling DTR) before it attempts to download a new image to the bootloader.
Re: Resetting the processor
I'm currently building up an emonTx, and am at the stage of seeing whether the processor is working - which it thankfully is.
As mentioned at the top of this thread, I've soldered a couple of wires to the SPI/ISP connector. These can be touched together as an easy way of re-starting the sketch. Works a treat.
Slightly off-topic, but ...
For the user-interface to behave as expected, the Serial Monitor needs to be set to "no line ending", near the baud speed selector. The sketch that I'm using is my FlickerDemo_Multiload_2. Typing 'g' followed by [CR] releases the code from its pause state, just as when running the sketch on a Uno.
Only two sensors have been equipped, for CT3 and the AC voltage. Running my MinMaxAndRangeChecker tool shows that these two sensors look OK (with no AC present), results attached. These are the two middle columns, on analog pins 1 and 2. The other two current sensors are not fitted so those analog input pins are floating. Although those readings appear to be fairly close to the ADC's mid point, this is presumably due to parasitic effects within the Atmega chip.