Re: Greenspring rs422 support

["Joseph P. Sullivan" <sullivan@aps.anl.gov>]

Ok, there were two things. 

The first fix _was_ in the transmit ISR logic. The code was wrong to only
check the status registers's TxRDY bit before executing the TX logic. The
interrupt mask register's (IMR) TxRDY bit needed to be checked also to assure
that a TX request had been made. The SR's TxRDY bit is going to be on
most of the time, whether it caused an interrupt or not. 

HiDEOS code segment...

void* OctualUartTask::ifunc(void *v)
{
.
.
	  // a byte needs to be sent
	  // if(sr&0x04) - original code. 
	  if ((qt->imr[st->block]&st->imr) && (sr&0x04))  
	  {
		// Start of TX logic 
.
.
}

Second, interrupts were not being masked out when the IMR's TxRDY bit was
set during the user's WRITE function. That left open a window when the
UART's data structure did not match the state of the chip. 

int OctalUartTask::Write(StringMsg* m)
{
.
.
>>>  lockKey = IntLockGet();	
   quad_table->imr[block]|=imr; // activate Tx interrupt
   regs->u.w.imr=quad_table->imr[block];	// enable Tx interrupt
>>>  IntLockRelease(lockKey);
.
.
}

We also decided it was safer not to output the first character from
the Write function. 


> Yes. Even though my driver had been signicantly restuctured - for example
> the multiple delimiter logic got moved into a programmer supplied
> drvSerial input framing routine. Most of what is common is the ISR logic
> and the UART configuration sections.


-Joe