Last week I decided to restart the Thor software design, this time built up to be more professional. With Professional I mean, adding comments, structured naming conventions, prepare it for full blown professional design.

As I was commenting the code I ended up at my Debug LED part and started to wonder about debugging the software.

The initial design was actually programmed for an Arduino Nano. I did not have a logic analyzer yet and I wanted to test the concepts of the interrupt based pulses. I used the Debug LED to visually see if the code actually worked. I could slow the step motor pulse to any speed I wanted even step per step.

The Arduino Nano is so easy to hook up to your PC, no wiring, no real mechanical parts and it forced you to develop code wiring an even more constraint space.

---

Months later, I had issues with the compiled code. I had code that would perfectly work on a Windows PC but for some reason it failed. So I extended the debug LED code to blink at setup(). I used the debug LED blinks to find where the code stopped functioning.

I can only conclude that it had to be some compiler bug. Rewriting my code made it goes away. But that blinking LED was vital for finding a workable solution.

The Debug LED was of no more use... or so I thought....

---

Yesterday I found that debug LED code, decided to clean it up even though I had no use for it anymore. Went to bed and suddenly start to realize that this debug LED is very vital for my Thor controller!

This single tiny LED is always on the Arduino controller, it never fails and can give vital feedback of the state of the software even if there is no display connected to it!

It can display the initialization stage, it can display the diagnostic stage, it can display the running stage... Just by blinking.

The key to all this is how you blink.

Ideas are:

• Initialization stage: blink when it goes to the next stage. Since every initialization stage will be different in duration, the debug LED pattern will flash in a predictable pattern.
• Running could be a regular repetitive blinking.
• Critical error could be a fast blinking state, or all on or off when the software crashed.
• Starting an operation could be a 1 second LED on followed by a second off as a warning that something is happening.
• Short blinks could indicate a command received from the display.
• Repetitive morse code could tell you an error code.

All this means is that my debug LED code will be extended dramatically.