delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2001/03/30/18:18:36.2

From: Eduardo TUDA Lorenzetti Pellini <dochell AT MailAndNews DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: Real time commitment and IRQ 0
Date: Fri, 30 Mar 2001 17:34:13 -0500
Organization: Posted via Supernews, http://www.supernews.com
Message-ID: <3AD28D44@MailAndNews.com>
X-InterChange-Posted-By: dochell AT MailAndNews DOT com
Sender: Eduardo TUDA Lorenzetti Pellini <dochell AT MailAndNews DOT com>
X-EXP32-SerialNo: 50000000
Mime-Version: 1.0
X-Newsreader: InterChange (Hydra) News v3.61.08
X-Complaints-To: newsabuse AT supernews DOT com
Lines: 62
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Hi friends,
 I'm developing a real time application to acquire some data with a data 
acquisition board using DJGPP over plain & clear MS-DOS 7.X. My problem is 
that my loop acquisition routine must run every 50 MICROSECONDS (not 
MILLISEC 
!).
 Nowadays i already stablished a good loop routine using the 64 bit TSC 
counter to measure the real-time process. The program loop only makes some 
port I/O (pooling), waits some time (polling the Pentium TSC counter) and 
starts again. Everything works fine, with a good and 'almost' constant 
acquisition period.
 But analysing the data, I noticed some holes along the time. I didn't know 
why, but periodicaly the computer wasn't executing my loop routine on the 
appropriate time. All code and variables were locked on the memory to avoid 
paging to disk. There were no reasons for this kind of thing to be 
happening...
I started to suspect of some IRQ routine that was happening behind my 
program 
and stealing CPU time.
 After a long time analysing the program i realised that IRQ 0 (system 
timer) 
was eating, periodicaly, more than 300 USEC of CPU time during its 
execution. 
If i disable IRQ 0 (through a mask on the PIC-1)... everything runs fine.
Checking some BIOS and MSDOS specs, i found that the only thing made inside 
the BIOS ISR for the System Timer Interrupt is the update of the timer and 
the 
execution of the INT 1C software interrupt. Is it right ? I suspect that the 
INT 8 ISR do much more than that to spend so much time.
 Actualy i'm deactivating IRQ 0 for more than an hour. The only problem i 
see 
is that the system timer is frozen during this time. As i don't have any 
device driver loaded (m$-win98 safe MS-DOS prompt) are there any other 
problems to the system ? Does MS-DOS hook INT 8 or INT 1C for any reason ?
 After enabling back IRQ0, is there any method to copy back the RTC (real 
time 
clock) day/time to refresh the system timer ? Anyone can post me some 
example 
using DJGPP ?

PS: This real time application is giving me so much headache that I'm 
planing 
not to use MS-DOS anymore. I started to think about using Real Time Linux, 
QNX 
and some stuff like that, just to get rid of the problems with the code 
timming and CPU dedication.


 Thank you in advance for your help and sorry for the big message.

 Eduardo 'TUDA DocHell' Lorenzetti Pellini
 epellini AT pea DOT usp DOT br


------------------------------------------------------------
 Get your FREE web-based e-mail and newsgroup access at:
                http://MailAndNews.com

 Create a new mailbox, or access your existing IMAP4 or
 POP3 mailbox from anywhere with just a web browser.
------------------------------------------------------------

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019