Re: Win32Forth Serial I/O Issue
- From: Richard Owlett <rowlett@xxxxxxxxxxxx>
- Date: Wed, 16 Mar 2011 06:49:51 -0500
rickman wrote:
On Mar 14, 9:34 pm, Richard Owlett<rowl...@xxxxxxxxxxxx> wrote:rickman wrote:I am using the file winser.f to use the serial port comms under
Vista. It seems to be working except for one issue. I am sending out
command strings to a device and the return message ends with a CR/LF
pair. My code to read the response loops waits up to 15 ms for each
character and returns what it has read when it times out. The serial
rate is 19200 bps or about 2 char per ms.
The problem I see is that after it works just fine for a while, it
eventually does not get the final LF at the end of the response. That
is ok as the code does not require it to work correctly. But the LF
shows up as the first char of the next response and does mess up my
parsing.
I've manually exercised this problem and once it gets into this mode,
the final LF is always missing. I can manually send a command out the
serial port using the Forth command line and get back the response and
it will always be missing the LF from the end and will always have a
LF at the start. I manually run ComKey? and get a false. It is as if
the final LF is received by the UART and/or driver, but is not being
flagged to the code as available until something else pushes it out.
I'm pretty confident that this is not a fault of the hardware unit
being controlled. That hardware (and I mean hardware, it's an FPGA)
is too dumb to mess up in this way. Besides, reinitializing the Forth
software is enough to get it working again. The hardware unit does
not need to be reset.
Anyone using winser.f for serial comms? Had any problems with it?
I suppose I could be messing up a pointer or something. Rather than
start serious debugging on this I thought I would ask if anyone else
has seen this. Also, I likely don't have the facility to dig too
deeply into the source for serial I/O. It is only a thin layer and
then goes into a Windows call.
Rick
Reminds me of symptoms observed back in days of using a mixture
of 20 mA and RS232 devices in a product line. We had problems
missing characters sent to mechanical printers - at 1200 Baud
they wouldn't have time to physically do a CR. RS232 printers
were becoming cheaper but many applications required 20 mA loops
for various reasons. We would "cheat" a LO being GND and a HI
being 5V which could source 20 mA. We didn't use any of the hand
shaking lines. If operating at> 300 Baud, just stuffed
appropriate number of NULLs at end of line.
I don't have winser.f available so I don't know how it's
constructed. Could it a problem with Windows latency in serving a
low priority interrupt -- i.e. resembling a printer that cannot
do a CR in time?
Winser.f is pretty simple. They just use Windows calls like
Call CreateFile
and
Com1Hndl read-file
If Windows were off doing something that it couldn't process the UART
interrupt, wouldn't that also mean it can't run the Forth code that
checks for a character? The timeout loop is in my code. I wait for
one ms before checking for a char and repeat this 15 times. Since the
chars are half a ms long, this is certainly overkill. No?
Rick
I don't know.
It's been almost 30 years since I had to deal with the system I described. Dealing with interrupt latency of Windows is also from way in the past, Win95 at the latest and probably Windows 3.1.
What raised all the red flags was just how similar your symptom description was. I was a hardware guy (component level) who occasionally programmed.
.
- References:
- Win32Forth Serial I/O Issue
- From: rickman
- Re: Win32Forth Serial I/O Issue
- From: Richard Owlett
- Re: Win32Forth Serial I/O Issue
- From: rickman
- Win32Forth Serial I/O Issue
- Prev by Date: Re: Win32Forth Serial I/O Issue
- Next by Date: Re: please translate this program into forth
- Previous by thread: Re: Win32Forth Serial I/O Issue
- Next by thread: Re: Win32Forth Serial I/O Issue
- Index(es):
Relevant Pages
|
