Re: Background COM port task very slow

Tasks vs. Threads -- no, not suggesting that is the problem, but a =
better way to go. FYI, TASK allocates a minimum of 16,384. I don't =
think priority is the problem.

-----Original Message-----
From: Pedro Monteiro [mailto:pm_at_entropylock.com]
Sent: Thursday, June 26, 2003 1:32 PM
To: sftalk_at_forth.com
Subject: [sftalk] Re: Background COM port task very slow

The background task had a Sleep in it, but I removed it when things were
running slowly, and relied instead upon the PAUSE inside (COM-KEY). It
seems to have not made a difference.

Yes, I am running this from the console, and I do plan to port it to a
turnkey app. On your suggestion, I am looking into using threads instead
of tasks.=20

Are you suggesting that a Thread will run faster than a TASK? Why is the
task so slow? Did I overlook something, or are TASKs this slow by
default, and I must use some mystery words to speed my TASK up (e.g.
change the thread priority)?

Thanks for your help,
Pedro

-----Original Message-----
From: sftalk-bounce_at_forth.com [mailto:sftalk-bounce_at_forth.com] On Behalf
Of Bob Nash
Sent: Thursday, June 26, 2003 3:48 PM
To: sftalk_at_forth.com
Subject: [sftalk] Re: Background COM port task very slow

I assume GET-1GPS-REC in the background task has a sleep (or a timed =3D
character wait with a sleep) in it. You are running this from the =3D
console, right? Suggest using forks> and TerminateThread for turnkeyed
=3D app.

-----Original Message-----
From: Pedro Monteiro [mailto:pm_at_entropylock.com]
Sent: Thursday, June 26, 2003 11:56 AM
To: sftalk_at_forth.com
Subject: [sftalk] Background COM port task very slow

Problem:
TASK runs too slowly in background, but runs fine in foreground. I will
be grateful for any advice.

I have a background task that monitors the COM port for GPS data, and
parses it into variables. When I run the parser in the foreground, the
variables are updated as they become available on the COM port. However,
when I run the same parser code in the background, the variables are
updated once every two or three seconds. The serial buffer then grows in
size, filling up with a backlog of COM port data that the GPS sent once
per second.

If I instead run the parser in the foreground, it quickly reads the
backlogged COM port data, catching up to the real-time GPS records.

- The GPS data is less than 400 bytes, sent at 9,600 baud, once each
second.
- SwiftForth 2.2.2.9 07May2001
- Windows 2000
- Reading COM port with COM-KEY from SIO.F
- Processor usage is around 5% with background parser running.
- A foreground task that prints the parsed variables to the SwiftForth
console raises to 100%, when the parser is running in the FOREGROUND.
- A foreground task that prints the parsed variables to the SwiftForth
console varies between 70-100%, when the parser is running in the
BACKGROUND.
- While the foreground process is not running, the background process
should catch up to the data with no display semaphores to possibly slow
it down. In any case, commenting out the semaphores did not change the
update rate.=3D20

The code below shows that both the foreground word (GFR)=3D20
and the background word (START-GPS-MONITOR)=3D20
call the same GPS parser code (GET1GPS-REC).

Could the Windows process priority be set too low? How do I change
it?=3D20 How do I get GPS-MONITOR to be listed in Windows Task Manager?

Any advice will be greatly appreciated. Thanks,
- Pedro

----------------------------------------------------------
: GFR ( -- ) \ get GPS record then print until key pressed
  ZERO-COUNTERS
  BEGIN
    GET1GPS-REC
    .GPS-RECS
  EKEY? UNTIL
; \ GPS-FIND-REC

8192 TASK GPS-MONITOR \ set up a background task

: START-GPS-MONITOR ( -- ) \ parse each record from GPS into vars until
killed
  ZERO-COUNTERS
  GPS-MONITOR ACTIVATE=3D20
  BEGIN
    GET1GPS-REC
  AGAIN
; \ START-GPS-MONITOR=3D20

: .GPS ( -- ) \ getting GPS record in background. Now print until key
pressed
  0 GPSUPDATE# !
  BEGIN
    .GPS-RECS
    GPSUPDATE# @ 1+ DUP CR . GPSUPDATE# !
    200 Sleep DROP
    EKEY? UNTIL
;

----------------------------------------------------------------------
sftalk_at_forth.com The SwiftForth programming discussion email list
To unsubscribe, send subject "unsubscribe" to sftalk-request_at_forth.com
For list command help, send subject "help" to sftalk-request_at_forth.com
Message archives are located at http://www.forth.com/archive/sftalk
----------------------------------------------------------------------
This list is a forum for SwiftForth users. For product support and bug=20
reports, please send email to support_at_forth.com
----------------------------------------------------------------------

----------------------------------------------------------------------
sftalk_at_forth.com The SwiftForth programming discussion email list
To unsubscribe, send subject "unsubscribe" to sftalk-request_at_forth.com
For list command help, send subject "help" to sftalk-request_at_forth.com
Message archives are located at http://www.forth.com/archive/sftalk
----------------------------------------------------------------------
This list is a forum for SwiftForth users. For product support and bug
reports, please send email to support_at_forth.com
----------------------------------------------------------------------
Received on Thu Jun 26 2003 - 13:48:24 PDT