description of debugging UNO with serial connection

docs/manual.md

@@ -229,9 +229,9 @@ ATtiny pin# | Arduino UNO pin | component
 
 <a name="section452"></a>
 
-#### 4.5.2 Debugging an UNO
+#### 4.2.2 Debugging an UNO
 
-If instead of an ATtiny85, you want to debug an UNO board, everything said above applies here as well. The Fritzing sketch below shows you the connections. Here, the series resistor for the system LED is soldered to the LED cathode so that we do not need a breadboard at all. 
+If instead of an ATtiny85, you want to debug an UNO board, everything said above applies here as well. The Fritzing sketch below shows you the connections. Here, the series resistor for the system LED is soldered to the LED cathode so that we do not need a breadboard at all. The hardware debugger needs a USB connection to your host, but the target should not be connected by a USB cable to the host! Otherwise the automatic power-cycling will not work (but see below).
 
 Remember to cut the `RESET EN` solder bridge on the target board (see [Section 3.3](#section33))! When you first establish a connection with the UNO as a target, the target will be completely erased (including the boot loader), because the lock bits have to be cleared.
 
@@ -243,10 +243,18 @@ When after a debugging session you want to restore the target so that it behaves
 2. Reestablish the `RESET EN` connection by putting a solder blob on the connection.
 3. Burn the bootloader into the UNO again. This means that you need to select the `Arduino UNO` again as the target board in the `Tools` menu, select `AVR ISP` as the `Programmer` , and choose `Burn Bootloader` from the `Tools` menu. As mentioned in Section 1, since version 2.2.0, the hardware debugger can also act as programmer!
 
-We are now good to go and 'only' need to install the additional debugging software on the host. Before we do that, let us have a look, in which states the hardware debugger can be and how it signals that using the system LED.
+<a name="section423"></a>
+
+#### 4.2.3 Debugging an UNO that needs a serial connection to the host
+
+If you want to debug an Arduino UNO that needs a serial connection to the host, special considerations are necessary. You may just plug in a USB cable into the target and open up a terminal connection to the target, using e.g., cu, screen, PuTTY, HTerm or any other program that can establish a serial connection. The disadvantage is that now automatic power-cycling does not work any longer. So, when the system LED signals that you should power-cycle (0.1 sec flash every second), you need to disconnect and reconnect the USB-cable to the target.
+
+A more elegant solution is to use a USB-to-serial converter and plug the TX, RX, and GND connections into the appropriate sockets on the target. Or you can use a [USB power blocker](https://spacehuhn.store/products/usb-power-blocker), something you can also find on Amazon under the name [PortaPow USB Power Blocker](https://www.amazon.de/PortaPow-USB-Power-Blocker/dp/B094FYL9QT/). Such a blocker cuts off the power line so that automatic power-cycling can work its magic.
 
 ### 4.3 States of the hardware debugger
 
+We are now good to go and 'only' need to install the additional debugging software on the host. Before we do that, let us have a look, in which states the hardware debugger can be and how it signals that using the system LED.
+
 There are five states the debugger can be in and each is signaled by a different blink pattern of the system LED:
 
 * not connected (LED is off),
@@ -632,7 +640,7 @@ For down shifting, we use the output pins of the hardware debugger in an open dr
 
 ![KiCad-Schematic](pics/dw-link-probe-V3.1-sch.png)
 
-The pin mapping is a bit different from the basic design described above. It is controlled by pin D5, which is tied to ground in order to signal that the more complex pin mapping is used. The additional pins are all in italics.
+The pin mapping is a bit different from the basic design described above. The change from the basic mapping is controlled by pin D5, which is tied to ground in order to signal that the more complex pin mapping is used. The additional pins are all in italics.
 
 | Arduino pin | ISP pin  | Function                                                     |
 | ----------- | -------- | ------------------------------------------------------------ |
@@ -652,11 +660,11 @@ The pin mapping is a bit different from the basic design described above. It is
 
 
 
-And here is the breadboard prototype, which works beautifully.
+And here is the early breadboard prototype, which worked beautifully. It contains a bug, though. Can you spot it?
 
 ![V2-prototype](pics/dw-probe-V3.jpg)
 
-I have turned that into a PCB, which you can buy [at Tindie](https://www.tindie.com/products/31798/).
+I have turned the modified prototype into a PCB, which you can buy [at Tindie](https://www.tindie.com/products/31798/).
 
 Before you start, you have to set three jumpers. Then you are all set and can start debugging. 
 
@@ -1048,4 +1056,5 @@ Initial version
 * Disabling automatic mode switching (Section 2)
 * Lowest frequency is now 4kHz (Section 8.7)
 * Number of breakpoints reduced from 33 to 25 because of stability problems (when debugging was on)
-* New dw-link probe
+* New dw-link probe
+* Debugging UNO with an active serial connection to the host

docs/wishlist.md

@@ -1,12 +1,27 @@
 # Wish list for dw-link
 
+* write/design setup for UNO debugging with connected USB cable
+
+* write a short debug description for PIO
+
+* produce short youtube video to promote dw-link probe
+
+* use "blink modes" in order to highlight embedded programming, perhaps in a video?
+
+* try to use seer GUI again
+
+* clean up Gede interface
+
+  * no multiple main breaks oints
+  * reloading files in GUI when reloading files
+
+* Implement SCK500v2 protocol
+
 * try integration of tool into IDE 2.0 again
 
 * debug tiny13 problem, perhaps by reverting back to the version in
   2022, when it seemed to work
 
-* rewrite compile-time conditionals so that they do not show up as errors in PIO
-
 * reorganize BP management: have a list of stored and a list of new BPs, which would save us 3 bytes per BP, i.e., we could easily go from 25 to 30 BPs -- but be careful!
 
 * maybe have a variable length break, dependent on the speed of ISP?
@@ -28,6 +43,8 @@
 
 #### List of tasks done:
 
+* rewrite compile-time conditionals so that they do not show up as errors in PIO
+
 * use DEBTX pin (if TXODEBUG is not defined) as a sensing pin to disable automatic DWEN programming, i.e., you have to use mo dw +/- by yourself.
 
 * optimize ispTransfer so that higher ISP rates are possible (currently, 50 kHz is max)

examples/blinkmodes/blinkmodes.ino

@@ -1,26 +1,26 @@
 // This is an example sketch to demonstrate embedded debugging
+
 // It is a modified blink sketch. It has four different modes:
 // off, on, slow blinking, fast blinking. You can cycle through these
-// modes by pressing a button, which is read using an interrupt.
-// Parallel to that, we prcess an ASCII input stream inverting the case of each
+// modes by pressing a button, which is recognized using an interrupt.
+// Parallel to that, we process an ASCII input stream inverting the case of each
 // character before sending it out.
-//
-// In order to keep external components
-// at minimum, we use the builtin LED and a single button.
-// The blinking is implemented by using the "Timer/Counter0 Compare Match A"
-// interrupt.
+
+// In order to keep external components at a minimum, we use the builtin LED
+// and a single button.  The blinking is implemented by using the
+// "Timer/Counter0 Compare Match A" interrupt.
 
 #include <ctype.h>
 
 #define LEDPIN LED_BUILTIN
 #define BUTTON 2
 #define BUTTONGND 4
 
-byte counter = 0;                   // the counter for blinking, it counts ms
-byte mode = 0;                      // the mode of the b linker
-unsigned long lastpress = 0;        // when was button pressed last?
+volatile byte counter = 0;           // the counter for blinking, it counts ms
+volatile byte mode = 0;              // the mode of the b linker
+volatile unsigned long lastpress = 0;// when was button pressed last?
 
-const byte debounce_ms = 100;       // the debounce time in ms
+const byte debounce_ms = 100;        // the debounce time in ms
 
 void setup() {
   Serial.begin(19200);
@@ -38,9 +38,8 @@ void loop() {
 
   if (Serial.available()) {
     c = Serial.read();
-    if (isupper(c)) Serial.print(tolower(c));
-    else Serial.println(toupper(c));
-
+    if (isupper(c)) Serial.write(tolower(c));
+    else Serial.write(toupper(c));
   }
 }