Re: [avr-gcc-list] Struct problem

[Eric Fu]

Thanks David. I agree with what you said. What you suggested actually was my
original design. It has been proved being the shortest implementation,
although it is not flexible to assign different buffer size for different
UART that uses the same struct type. After all this, I understand the pros
and cons of each implementation better.

Thanks for help.

Eric Fu
----- Original Message ----- 
From: "David Brown" <address@hidden>
To: <address@hidden>
Sent: Monday, February 02, 2004 6:40 PM
Subject: Re: [avr-gcc-list] Struct problem


>
>
> > Thanks for the tip.
> > The buffers need to be Global, since it needs to be accessible in
> different
> > modules. My understanding is that malloc is for allocating dynamic
memory.
> > Anyway, I will read my C book for clue. Thanks for pointing the
direction.
> >
> > Eric Fu
>
> As others have said, you can use malloc for allocating a globally
accessible
> lump of memory - basically you keep a pointer to it in your structure, and
> if other modules can see the pointer, they can access the memory it points
> to.  However, there are two rules regarding dynamic memory in small
embedded
> systems - 1) Don't use dynamic memory in small embedded systems, and 2) if
> you really do have to use dynamic memory in small embedded systems, don't
> use malloc() and free(), but write your own system.
>
>
> The most common way to handle structures like your one is to have:
>
> #define txBuffSize 16
> #define rxBuffSize 16
> typedef struct UART
> {
>     volatile byte RxHead;
>     volatile byte RxTail;
>     volatile byte TxHead;
>     volatile byte TxTail;
>     byte TxBuf[txBuffSize];
>     byte RxBuf[rxBuffSize];
> } UART;
>
>
> You need a *very* good reason for an avr-based system to start needing
> variable-sized buffers.
>
> David
>
>
>
> >
> >
> > ----- Original Message -----
> > From: "Brian Cuthie" <address@hidden>
> > To: "'Eric Fu'" <address@hidden>; <address@hidden>
> > Sent: Saturday, January 31, 2004 12:22 PM
> > Subject: RE: [avr-gcc-list] Struct problem
> >
> >
> > >
> > > The problem, quite simply, is that because the size of TxBuf[] isn't
> > > specified, the offset within the struct to RxBuf[] can't be computed
at
> > > compile time (which it needs to be).
> > >
> > > To do what you want you'll need to change the struct so that instead
of
> > > arrays, TxBuf and RxBuf are pointers. Then malloc the memory you need
> and
> > > store the addresses in TxBuf and RxBuf respectively.
> > >
> > > You might want to re-read a few chapters in your C book.
> > >
> > > -brian
> > >
> > > > -----Original Message-----
> > > > From: address@hidden
> > > > [mailto:address@hidden On Behalf Of Eric Fu
> > > > Sent: Friday, January 30, 2004 8:05 PM
> > > > To: address@hidden
> > > > Subject: [avr-gcc-list] Struct problem
> > > >
> > > > Hi All,
> > > >
> > > > I'm trying to declare a Structure for UART, so that it can be
> > > > used for more than one UARTs such as:
> > > > typedef struct UART
> > > > {
> > > >  volatile byte RxHead;
> > > >  volatile byte RxTail;
> > > >  volatile byte TxHead;
> > > >  volatile byte TxTail;
> > > >  byte TxBuf[],RxBuf[];
> > > > }UART;
> > > > extern UART uart0;
> > > > extern UART uart1;
> > > >
> > > > By doing this way, I can assign different buffer size to
> > > > different UART such as:
> > > > byte uart0.RxBuf[RX_BUFFER_SIZE0];
> > > > byte uart0.TxBuf[RX_BUFFER_SIZE0];
> > > > byte uart1.RxBuf[RX_BUFFER_SIZE1];
> > > > byte uart1.TxBuf[RX_BUFFER_SIZE1];
> > > >
> > > > However, I get the following compile error:
> > > > UART.h:47: error: flexible array member not at end of struct
> > > >
> > > > Could anyone give me a hint on How to tell the compiler to do this?
> > > > Thanks
> > > >
> > > > Eric Fu
> > > > _______________________________________________
> > > > avr-gcc-list mailing list
> > > > address@hidden
> > > > http://www.avr1.org/mailman/listinfo/avr-gcc-list
> > > >
> > >
> > >
> >
> >
> >
> > _______________________________________________
> > avr-gcc-list mailing list
> > address@hidden
> > http://www.avr1.org/mailman/listinfo/avr-gcc-list
> >
>
>
>
> _______________________________________________
> avr-gcc-list mailing list
> address@hidden
> http://www.avr1.org/mailman/listinfo/avr-gcc-list