> Harold Hallikainen escreveu:
>> struct FifoStruct{
>>   uint8_t buffer[FifoSize];
>>   uint16_t IndexIn;  // Put next byte at this index, then increment
>>   uint16_t IndexOut; // take next byte from this index, then increment
>>   uint16_t BytesInBuf;// how many bytes we have in the fifo
>>   uint16_t BytesFree;// how many bytes we have left
>> };
>>
>
> I think it would be better to keep the buffer itself as the last member
> of the struct. This way it would be easier to make generic functions to
> deal with FIFOs of different physical lengths (physical length could be
> a field also). Just pass a pointer to the FIFO struct to the functions
> Insert and Remove and the same functions may work on several different
> FIFOs.

I agree that it'd be good to put the buffer at the end. I did this in some
other code. I then had assembly routines that were used interrupts. It was
easy to find the appropriate stuff when the buffer was at the end.

> I always try to use FIFO lengths of powers of two, it is easier to cope
> with wrap-around and you don't need to keep Insertion index, Remotion
> index and Length.

Good idea, but I like the flexibility of the variable FIFO size. In some
implementations, I've put the FIFO size at the top of the structure (along
with indices and counts). I then look for rollover using that value
instead of a constant. Initialization sets this size.

>
> For FIFOs where the interrupt inserts and the application removes I use
> only the Insert index and length, and for FIFOs where the interrupt
> removes and the application inserts I use Remove index and length. This
> way the interrupt code deals with the simpler (faster) operations
> (inserting in a FIFO with insertion index and length, or removing from a
> FIFO with remotion index and length).
>

I think that having both put and get functions deal with their appropriate
index and BytesInBuf and BytesFree. BytesFree and BytesInBuf only need an
increment or decrement. Index needs and increment and check to see if we
went off the end. Not a whole lot of code...

THANKS for the comments!

Harold




-- 
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist