X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: "Rod Pemberton" 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: References: 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" 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