Re: [avr-gcc-list] Problems with ATMEGA8 USART

[David Kelly]

On Aug 14, 2005, at 4:21 AM, Bob Paddock wrote:

> On Saturday 13 August 2005 08:35 pm, David Kelly wrote:
>
> > For advanced discussion one would probably wish to put the buffer and
> > its indexes into a struct so that its obvious to future generations
> > maintaining your code that the indexes and buffer belong together.
> > Doesn't make code size one iota bigger:
> >
> > struct {
> >      uint8_t tail;
> >      volatile uint8_t head, buffer[BUFFER_SIZE];
> > } uart0;
>
> On the Mega162 with two USARTs I tried it both ways.  Duplicate the  
> code for
> each USART, and using a common driver with structures.  The duplicate
> approach came out smaller in code space.  Don't recall the exact  
> number but
> it was more than a few bytes of difference.

Did that myself, partially, on an ATmega64. my_getchar() and family  
require a pointer to struct of type UART to know which buffer to  
manipulate.

The "partial" part was that I did not use common code to service the  
Tx and Rx interrupts. All "user code" (that which runs outside of IRQ  
time) was shared for both serial ports. For the very little space  
savings a very large hit occurred by referencing USART registers via  
double de-referenced pointers. Also the first thing an IRQ routine  
would have to do is figure out whether UART 0 or 1 or both needs  
attention. With separate routines one instantly and correctly knows  
which is in need of attention and register addresses are hard coded  
at link time.

The one clumsy part of code was in my_putchar() which had to reach  
directly into the hardware for the specific port to restart the Tx  
IRQ if the buffer had been empty, which causes my Tx IRQ routine to  
shut itself off. Also there was a possible race condition.

--
David Kelly N4HHE, address@hidden
========================================================================
Whom computers would destroy, they must first drive mad.