More wrinkles with Arduino and windows serial over USB; making CARDREAD.EXE connect to Arduino

 NEW DISCOVERY ABOUT THE SPURIOUS CHARACTER ISSUE

I was foolishly satisfied that the one millisecond delay I added to my code was going to be a long term workaround for the spurious characters that arrived at startup of the Arduino sketch, in spite of doing this blindly. I had no clear understanding of the cause of the issue and nothing that suggested that a delay was related to the problem. 

I made some unrelated modifications to the sketch in an entirely different area further along in the code, after which the flaw came back. At this point I wanted to know exactly what was being received as that might give me a clue as to the agent which was sending them. 

I set up the sketch to blink out the eight bit character being received, with one clock blink followed by a second blink only when the bit was one, separating the clock-data pair by a longer interval to permit me to see the data unambiguously. 

What I found was two xF0 characters. This reminded me that I was seeing them earlier with the Arduino based 3174 controller board I was experimenting with. Those spurious characters arrived at various times during a sketch, along with an xF8, not just at startup. My workaround at that time was to 'eat' those characters. Only possible if xF0 and xF8 are not valid incoming characters to the Arduino.

NEW WORKAROUND

The protocol between the application and the card reader interface sketch sends only ASCII characters, a small set - C, P, R, S, and X - which means I can safely eat the bad characters even though I still don't know why they arrive on my laptop USB link. With that added, the sketch seems to be solid again.

QUICK RECAP ON ISSUE WITH CARDREAD.EXE

An Arduino puts a bootloader in upper memory along with the compiled user sketch. When the Arduino is reset, it runs the bootloader which listens on the port to see if the IDE is downloading a new sketch. This introduces a delay of almost 2 seconds on startup of the code. 

The reset is triggered by the DTR control line going low, which occurs every time that Windows opens a COM port. This was introduced into the Arduino system to allow sketches to be loaded without the requirement that the user push the reset button on the controller. 

The CARDREAD.EXE program opens the COM port, sends the character R to reset the controller and reads the incoming serial line for a response character. It does this send and receive ten times in quick succession, looking for a valid status character - ASCII between x40 (@) and x7F which includes the capital letters A to Z. 

The problem is that this rapid fire transmission occurs faster than the bootloader will stop, so that the program nevers sees a valid response character and the Arduino never gets through bootloader to run my actual sketch code. 

I don't know why the program doesn't block waiting for the response character. Instead, it seems to look at the incoming port even if there is no data there yet. This is a second sign that the Windows virtual COM port functionality is broken on my laptop. It is also broken on the Windows Surface Pro tablet so it is not just a Windows 10 problem. My guess is this is a compatibility issue mixed with a defect in Windows.

SOLUTION IS TO REMOVE BOOTLOADER FROM ARDUINO

If I load the sketch to the Arduino without the bootloader, it will start up immediately and look at the incoming characters. That should give us the R command and send back the response character @ fast enough so that CARDREAD.EXE is satisfied. At least, that is the plan.