Problems with Serial Interupt routines in ADA on MSDOS

[tmoran@bix.com]

>locks up the CPU every now and then.
  So the problem is probably not in the initialization code (the
first 300 lines of your 700 line message).

>context switching by the dos extender
  Can it reliably do all of what's necessary, plus your substantial
processing, in 500 microseconds (19200 baud) on your hardware, in the
presence of other (timer, disk, etc) interrupts?

>  invoke RTKERNEL.RTK_SAVE_REGS_AND_RESTORE_CONTEXT
>  invoke RTKERNEL.RTK_SWITCH_STACK
>  invoke RTKERNEL.RTK_DISABLE_INTERRUPTS
>     process
>  invoke RTKERNEL.ENABLE_INTERRUPTS
>  invoke RTKERNEL.RTK_RESTORE_STACK
>  invoke RTKERNEL.RTK_RESTORE_REGS_AND_IRET

  Presumably if you are handling an interrupt, they are already disabled,
no?  And if interrupts are enabled while you are restoring stacks, is
that safe?  Interrupt enable/disable and context switching is also often
only approximately emulated in dos extenders.
  You might consider a loop inside your interrupt processing, since it's
quite possible a second byte might arrive, or you may be able to xmit
a second byte, before you've left the ISR.  If you test and process
you'll save interrupt handling overhead in those cases.  That design
will also upgrade more easily to a 16550 (buffering) chip.
  You don't say what else is going on.  If not much else during
transmission of a block, and the interrupt overhead is preventing
reliable 19200 operation, then you might consider polling instead
of interrupts.

> BAUD  : integer := 19200;
Shouldn't that be 'integer range 2 .. 115200', since any value outside
that range will not work and your code will silently do the wrong thing.

>   in_char := COM_PORT.MCR_set_DTR +
               COM_PORT.MCR_set_out2;   -- clear RTS = line
  Which do you want, DTR or RTS?  The comment disagrees with the code.
BTW, how long does a PORT.OUT_BYTE take on your system?  Do you really
need to keep setting DTR after every byte received?