Announcement

**Aldo Cavini** · 28 Mar 2001, 11:40 PM

Russ,

It seems you need a real-time application... I think Windows is not the best (at least, easiest) OS to develop it.

The simplest solution is to set up a timer. Theorically a standard 10 ms timer could be good to monitor the signal. You must be careful on using it: Windows don't guarantee the execution of the timer procedure at the exact time-out expiration. Some kernel function, or some other-application task can lock the timer for a longer time.

May be the only good solution is to direct access the UART. 16550 UARTs can be programmed to send an IRQ on CDC state changes - the problem is to set-up this non-standard function and intercept the interrupt (I'm not so expert on the PC hardware to tell you why to do it, may be you'll find other guys on this forum...).

------------------

**Russ Srole** · 29 Mar 2001, 04:54 AM

Aldo,

I'm using a 1ms timer now and checking the state before deciding
what to do. It actually works better then I thought it would.
Your second idea is what I really want to do. I know how to do
this in DOS, but windows is not DOS so it's like starting over.

Looking through the Win32 help there is a function called CreateEvent,
but that appears to be part ot the threading mechanism.

Anyone else had to do this sort of thing?

------------------

**Fred Oxenby** · 29 Mar 2001, 05:51 AM

If the event is targeted another application (your code) on the same
physical Pc, then register a Windowmessage, and broadcast this.

Code:

MyMsg& = RegisterWindowMessage("RLSD_Change")
  
---
In your "CreateEvent procedure",  You can use Post/Sendmessage
   
  PostMessage %HWND_Broadcast,MyMsg&,RLSD_Status&,Byval AnOtherValue&
----   
In your "HandleEventProcedure" in other app
   
Callback Function MainWin_Proc
Static RLSD_CHANGE&
  
  Select case CbwMsg  
   Case %INITDIALOG
    RLSD_CHANGE& = RegisterWindowMessage("RLSD_Change")
    .....
   Case RLSD_CHANGE&
    RLSD_Status = CbwParam
    ...handle the event...
   Case else
  End select
End Function

------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se

[This message has been edited by Fred Oxenby (edited March 29, 2001).]

**Russ Srole** · 29 Mar 2001, 08:32 AM

Fred,

You're heading me in the right direction. It will not be another
application. What I'd like it to be is like an old fashioned
Dos interrupt. When ever the RLSD line changes, the background
routine checks to see the state and sets one global variable to
reflect the current state and increments another global variable.
Is the code you posted correct for that or are there any modifications?

In the meantime I'll read up on the commands you've posted.

Thanks for the help,
Russ Srole

------------------

**Fred Oxenby** · 29 Mar 2001, 09:17 AM

Russ, when it comes to programming Com-port/Modems I am out in the dark,
RLSD for me is CD (carrier detect)
There are some good examples (in C ofcourse) in MSDN
Read up on API (you will probably need a background thread)
"WaitCommEvent"
"GetCommModemStatus"

------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se

**Russ Srole** · 29 Mar 2001, 04:51 PM

Fred,

The two function you mention are the key, however it seems that
the handle they require is not the handle you get from freefile
when you wish to open the port. So I have some more research to
do.

By the way the Poffs utility is a really great help. I just
downloaded it. Once I have this beat, I'll post the answer.

Russ

------------------

**Lance Edmonds** · 29 Mar 2001, 09:18 PM

You can use the PowerBASIC FileAttr() function to get the O/S handle to use it with the API calls... I'm not at my DEV PC, but I think its:

Code:

OSHandle& = FILEATTR(PBHandle&,-2)

Double check in the manual...

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**Aldo Cavini** · 29 Mar 2001, 10:37 PM

Russ, Fred --

What can generate some headaches is the time execution of a polling-based application. Functions like WaitCommEvent will stop-and-go your thread, but the question is: when will it restart? I think this way is not so different from a timer-based polling.

Your timings (less than 16 ms) are short. The problem is not to lose an event!

Aldo

------------------

**Fred Oxenby** · 29 Mar 2001, 11:39 PM

This is not my home-field, so I would not know the hidden gotchas
in COMM-programming.

Code:

  hFile& = CreateFile("COM2",%GENERIC_READ or %GENERIC_WRITE, _ 
                       0, 0, %OPEN_EXISTING, 0, 0)
  If hFile& = %INVALID_HANDLE_VALUE Then Function = %False:Exit Function
  
  SetCommMask hFile&, %EV_RLSD
  
WaitLoop: 
  If Isfalse WaitCommEvent(hFile&,WhatEvent&,%NUL) then
    Function = GetLastError:Exit function
  End If
  If Isfalse GetCommModemStatus(hFile&,WhatEvent&) Then 
    Function = GetLastError:Exit function
  End If
  glbRLSD = ((WhatEvent& And %EV_RLSD)= %EV_RLSD)
  incr Counter&
  '--perhaps send/postmessage to a windProc
  Goto WaitLoop
  ---

This is how I, as a novice, would try to solve this problem.
In a thread of its own of course.

------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se

[This message has been edited by Fred Oxenby (edited March 30, 2001).]

**Guest** · 30 Mar 2001, 12:29 AM

If your timer is of the multimedia variety you can achieve 1 ms resolution quite reliably.
Regular windows timers are not accurate and have 10ms resolution at best but usually something between 10ms-55ms
is what you will get and this depends considerably upon how busy the system is.

Using SetCommMask() and WaitCommEvent() are likely the best windows can do. Unfortunantly WaitCommEvent() is a blocking
call unless you use Overlapped file io.

You will need to use the API for your comm port handling to use overlapped io.

Be advised that the placement or timing of the SetCommMask() function call is very important and is not expressed very well
in the windows documentation. Either SetCommMask() or WaitCommEvent() must be called prior to the event(s) you are
trapping/waiting for. For example, if you are waiting for EV_CTS you must call SetCommMask() before you assert RTS in
order for WaitCommEvent() to trap the EV_CTS. I had trouble with this very thing and was polling using GetCommModemStatus()
which was not realy pretty code.

Lastly - in case you might not be aware - WaitCommEvent() only reports a change in the state of the lines you are monitoring.
To determine what state the line is in after the event is signaled, use GetCommModemStatus().

------------------

**Aldo Cavini** · 30 Mar 2001, 01:11 AM

Ron,

I already stated my doubts on the thread timings. Unless you can intercept an IRQ in the system, the time response of a thread is in the Windows hands.

You gave very useful details on the standard timer timings. May you tell us the delay we have to expect when a thread restarts after an event? As Russ stated, he needs to monitor a signal that changes its state every few ms. If the system is very busy, is there a way to be certain an event like that is not lost?

------------------

**Guest** · 30 Mar 2001, 01:48 AM

Aldo, I am 99% certain the WaitCommEvent() function is going to have a
latency comparable to the windows timer and other "Waitfor" functions (WaitForSingleObject).

This would mean something like 10ms-55ms could elapse before the thread is rescheduled once the event occurs.
This indicates a polling loop using GetCommModemStatus() to check the status of the CD signal is likely the
best windows can do short of writing a custom device driver.

Raising thread and/or process priority will help some. I am not certain but a tight loop might be the best
thing to do as long as it does not cripple windows' ability to provide timely hardware information.

**Russ Srole** · 30 Mar 2001, 03:13 AM

Guys,

This is good information. Sorry, Lance, I forgot about the fileattr
command. I don't think I've ever actually used it.

Ron & Aldo, as for the timers, I'm using Win NT (soon 2000) and the
SetTimer api command seem to be able to set a very short timer. I
haven't checked it, but I think when I get into work this morning I
will.

Can someone give me a definition of "overlap i/o"? The windows
documentation refers to it, but never really explains what they're
talking about or why it exists.

Thanks,
Russ Srole

------------------

**Guest** · 30 Mar 2001, 03:38 AM

Russ, SetTimer uses the standard window timer with the fuzzy resolution.
A multimedia timer (timeSetEvent) will provide much better resolution than the
standard windows timer (SetTimer). I use NT exclusively and iSetTimer at best
gives 10ms resolution. It is suitable for general-purpose timer use and is not
good enough for <10 ms resolution.

Overlapped Info
http://msdn.microsoft.com/library/te...sdn_serial.htm

[This message has been edited by Ron Pierce (edited March 30, 2001).]

**Russ Srole** · 30 Mar 2001, 09:02 AM

Ron,

You are right, the normal time is good to 10ms. I've been playing
with the comm issue and don't like the results. I think it's time
for a bit more external hardware including a counter chip. Some things
just work better with hardware. I'm going to play with the
mm timer some more, that looks usefull.

Thanks for everybody's input
Russ Srole

------------------

**Aldo Cavini** · 3 Apr 2001, 01:02 AM

Russ,

look at http://www.sysinternals.com/. They have an utility called PORTMON, which monitors the parallel and serial ports activity. I guess that task must work real-time... then a real-time control on a port can be done! They also have some source code and explain programming tricks.

Really I can't work on your problem now - may be I'll have this kind of problem in a future... Tell us if you find something useful.

------------------

[This message has been edited by Aldo Cavini (edited April 03, 2001).]

Announcement

Custom Event

Custom Event

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment