delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2009/05/15/04:45:39

X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
From: "Rod Pemberton" <do_not_have AT nohavenot DOT cmm>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: An interrupt drived uart program dead
Date: Fri, 15 May 2009 04:48:46 -0400
Organization: Aioe.org NNTP Server
Lines: 79
Message-ID: <guja2i$83o$1@aioe.org>
References: <dcff139d-32b8-4f22-ab4a-6f7e78f81324 AT c18g2000prh DOT googlegroups DOT com> <Pine DOT LNX DOT 4 DOT 60 DOT 0905150327230 DOT 1746 AT narpes DOT com>
NNTP-Posting-Host: pldq+kT97bAAp/ObDwnZyQ.user.aioe.org
X-Complaints-To: abuse AT aioe DOT org
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1933
X-Notice: Filtered by postfilter v. 0.7.9
X-Newsreader: Microsoft Outlook Express 6.00.2800.1933
Cancel-Lock: sha1:xT8ljadrqxp0oj7/XrkcITxYkcg=
X-Priority: 3
X-MSMail-Priority: Normal
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

"A. Wik" <root AT dynamite DOT narpes DOT com> wrote in message
news:Pine DOT LNX DOT 4 DOT 60 DOT 0905150327230 DOT 1746 AT narpes DOT com...
>
> Based on the code below, I presume that you're
> working in a plain DOS environment with a non-paging
> DPMI host, in which case the above locking issue is
> unlikely to be of relevance.
>

That's probably not a good assumption.  The default DPMI host used with
DJGPP, CWSDPMI.exe, is paging.  So, is the ring 0 DPMI host CWSDPR0.exe.
PMODETSR.exe, aka PMODEDJ, is non-paging.  STUBEDIT.exe can change the
default DPMI host.  Switching the DPMI host to PMODETSR is useful in finding
some DPMI problems.

> > #define LOCK_VARIABLE(x)    _go32_dpmi_lock_data((void *)&x,(long)
> > sizeof(x));
> > #define LOCK_FUNCTION(x)    _go32_dpmi_lock_code(x,(long)sizeof(x));
> [...]
> Anyway, looking further down, you don't seem to be
> calling the locking routines mentioned above.

I was hoping someone could help him (and me indirectly).  I've had so many
problems trying to create a working TSR in DJGPP that I gave up.  No matter
what I did with the locking functions, code that worked as a non-TSR would
just not work as a TSR.  I eventually concluded that code or data somewhere
in the _go32* or _dpmi* calls wasn't able to be locked.  So, today, I just
code TSR's in assembly...

> I'm not certain that the above is sufficient to declare
> an interrupt handler.  You may have to add some attribute
> that informs the compiler not to make any assumptions
> about the values of different registers upon entry to the
> procedure, and furthermore, to comply with all
> requirements applicable to an interrupt handler, such as
> saving and restoring all registers modified.

No "interrupt" or similar keyword is needed in DJGPP, AFAIK.

> Furthermore, it is important to instruct the compiler not
> to make certain optimisations, such as reordering
> statements that interact with the hardware, as that may
> produce unpredictable results.
...
> You may have to declare these data structures you're
> accessing from the interrupt handler and from normal
> code "volatile" to inform the compiler not to make
> certain assumptions that may be hazardous in the
> context of asynchronous, real-time events.

Yes, I think he'll definately need a "volatile" on queueSize, at least...
maybe txIdle too.

> > When run the program, the data has sent, but then
> > the PC halt. I can't find any bug in the program.
[...]
> >         lsr = inportb(baseAddress + OFFSET_LSR);
> >      } while((lsr & (LSR_THRE | LSR_TEMT)) != 0);

One possible guess is that this while() loop in commISR() never exits.
Writes out the data, idles, fails to exit the loop, loops forever, no EOI,
no return from interrupt... ?  Basically, you need to determine where it
hung.  I'd write a green character to the screen in asyWriteComm()'s while()
loop and a red character in commISR()'s while() loop, both to the same
screen location.  Halted on Red = hang in commISR().  Halted on Green = hang
in asyWriteComm().  If color keeps changing, something else is going on.

> One other thing: the interrupt may have to be
> acknowledged (e.g. a Specific EOI for the IRQ in
> question, or the more popular non-specific EOI).

Well, he's sending an non-specific EOI to the master PIC for IRQ 4:

> >  outportb(0x20, 0x20);


Rod Pemberton


- Raw text -


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