Xref: news2.mv.net comp.lang.ada:24920 comp.os.msdos.djgpp:7953 From: Greg Bond Newsgroups: comp.lang.ada,comp.os.msdos.djgpp Subject: Re: GNAT and interrupts with DJGPP and CWSPR0 Date: Mon, 19 Aug 1996 14:26:06 -0700 Organization: Dept. of Electrical Eng., UBC Lines: 40 Message-ID: <3218DBEE.3988@ee.ubc.ca> References: <32110129 DOT 3C6E AT ee DOT ubc DOT ca> NNTP-Posting-Host: bug.ee.ubc.ca Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit CC: jerry AT jvdsys DOT nextjk DOT stuyts DOT nl To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Jerry van Dijk wrote: > > As my news seems to get out and my last post was not really of > examplary clarity, lets try an example: > > ----------------------------------------------------------------- > -- Chains a GNAT procedure into the DOS timer interrupt -- > -- and displays the current time in the upper right corner -- > -- of the screen. -- > -- Note that this demo assumes that virtual memory is disabled -- > -- and that there is enough space on the interrupt stack! -- > ----------------------------------------------------------------- While Jerry has shown with his sample code that it is relatively straightforward to chain interrupt handlers in DJGPP, this is only a partial solution for me. When I teach real-time, I stress that the bulk of interrupt processing should be performed by an interrupt task, not an interrupt handler (in order to avoid priority inversion). Unfortunately, most of the GNAT ports, including DJGPP, do not support interrupt tasks (i.e. using an interrupt handler to signal a task via a protected object as described in the Ada95 rationale). The only workarounds that I can think of are either performing all the itnerrupt processing in the handler itself (poor practice), or having the interrupt handlers set flags, and poll the flags from Ada tasks (poor practice again). Any other suggestions? I'm currently considering moving to ObjectAda which should support interrupt tasks, however the new challenge will be to avoid all the non-real-time aspects of Win95 (not that DPMI servers don't come with their own hidden real-time overhead)... -- * Greg Bond * Dept. of Electrical Eng. * email: bond AT ee DOT ubc DOT ca * Univ. of British Columbia * voice: (604) 822 0899 * 2356 Main Mall * fax: (604) 822 5949 * Vancouver, BC * web: http://www.ee.ubc.ca/~bond * Canada, V6T 1Z4