Mail Archives: djgpp/2009/05/15/04:45:39
"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 -