DEVICE MONITORING STUDIO USED ON WINDOWS TO WATCH THE COM PORT
The Free Device Monitoring Studio installed filters (shims) on the virtual COM ports on my Windows 10 laptop. It can intercept and record all the data and control commands issued to them even when other programs are in control of the port. I made good use of it to watch what was happening on the link.
CARDREAD PROGRAM SENDS BUT DOES NOT RECEIVE DATA
When I fire up Brian Knittel's CARDREAD.EXE program I see it sending the character 'R' repeatedly and I can see the Arduino receive it based on the blinking LED, but I never see any return traffic which means the program never gets its expected response.
I do see his program request both DTR and RTS handshaking, but whether I set up Windows for hardware handshaking or not, the result is the same. No return data. I don't know why yet.
ARDUINO USE OF DTR SIGNAL ADDS TO THE MESS
The Arduino system has overloaded the meaning of DTR, so that when it drops to logical false, the Arduino does a reset. This is useful both for uploading code and to ensure that the code starts fresh when a link is established. Unfortunately, that interacts with the Windows com driver practice of dropping DTR during the open of a COM port, which is how the reset is triggered.
RANDOM DATA SEEMS TO ARRIVE AT ARDUINO RESET
Regardless of the program I use to connect to the Arduino, when it restarts and opens the serial connection, something happens to the input buffer logic. The Serial.available() function sees waiting data, that triggers my code to read a byte and parse it as a command. It is not a valid command thus the code returns the character '?' without the calling computer or application having sent any command characters.
If the CARDREAD.EXE program was actually receiving the output of my Arduino code, it would have iterated sending the 'R' until it got a good response, overcoming the one time garbled transmission. That is what happens when I use terminal emulation programs such as PUTTY or the Arduino IDE serial monitor.
TWO PROBLEMS TO OVERCOME
First, I need to get to the bottom of the issue blocking the CARDREAD program from receiving serial traffic. If I get that working properly I can live with the second problem.
Second, I have to figure out why I am getting the garbage results on opening a serial link over USB. This is a problem that has plagued me in prior projects (on this Windows system) so its resolution will have wider benefits that simply cleaning up this reader interface behavior.
No comments:
Post a Comment