Russ,
I have good news and I have what is probably bad news that
completely overrides the good news
if it applies in your situation (which it probably
does). The good news is that I have some code that
completely handles your situation
if (the bad news) the Windows ReadFile API function works
differently for a COM: port than it does for CON: (the console)
or your device sends a cr/lf (or maybe just a carriage return or just a line feed, the second case being more likely to work) sequence at the end of any particular "group" of data. And I have some code here the that you
might be able to use to determine whether or not that is the case or whether the Windows ReadFile API function works differently for a COM: port (which I have no way to test) than it does for CON:. And here is some code you can run to check this out for yourself:
Code:
@Echo Off
SetLocal
:: Change "CON:" to whatever COM" port you are testing
Set Handle=%@FileOpen[CON:,r,b]
Set Char=%@FileRead[%Handle,1]
Set DemoCounter=0
Do While "%Char" != "**EOF**"
Set /A DemoCounter+=1
@EchoS %DemoCounter: %Char^n
Set Char=%@FileRead[%Handle,1]
EndDo
EndLocal
Quit 0
And here is what happened when I ran the above code (with input coming from the console):
Code:
[Z:\Demo]Demo
abcdef
1: a
2: b
3: c
4: d
5: e
6: f
7:
8:
^Z
[Z:\Demo]
To summarize what you are seeing above (because the "Enter" key at the end of the data I entered ("abcdef") is invisible), the TCC "@FileRead" function does not "see"
any data
until the "Enter" key is depressed and then the data is returned as a "group" and not a byte at a time (and the
same is true if you use the TCC "@FileReadB" function rather than the "@FileRead" function). And this is
not at all a TCC issue, it is a an issue related to Windows itself.
So the bottom line is this:
If your device is sends a cr/lf feed (or, again, maybe just a carriage return of just a line feed) sequence at the end of any given "run" of data (possible)
or the Windows "FileRead" API function works differently for a COM: port than it does for CON: (seems rather unlikely to me) there
is no solution to your problem (
not just in TCC but in
any "normal" Windows program that reads a COM: port)
other than finding a device driver of some kind somewhere that reads the bytes one at a time off of the COM: port and
does not buffer them but rather returns them on a byte-by-byte basis to the program that is using the device driver.
And here is the way you can test that: run the above code changing "CON:" to "COMn:" and if you get any output when your device sends any data I have a
complete solution both coded and tested that works fine
other than the behavior I am discussing above, and if you don't get any output there
is no solution in Windows (XP or 7 and possibly earlier) other than getting and using a device driver to read the COM: port(s).
And I will add that
if you can find a device driver with the above characteristic that can be used within TCC (I'm not going to bother going to "how" it can be used within TCC if at all, that depends somewhat on the "nature" of the device driver) the previously mentioned "complete solution"
does apply.
- Dan