C: циклический FIFO буфер пакетов

Либо я чего то не понял, либо это пишется за 5 минут.

> Либо я чего то не понял, либо это пишется за 5 минут.
Нельзя пользоваться динамической памятью.

Вобщем, написать несложно, но по опыту, такие конструкции отлаживать долго.

>> Либо я чего то не понял, либо это пишется за 5 минут.

>Нельзя пользоваться динамической памятью.

а создать большой статический массив?

У меня сомнение, что это "велосипед". Вряд ли есть реализации без использования динамической памяти, они редко бывают нужны. А уж если ты пишешь для микроконтроллера, то тем более рекомендую реализовывать самому, ибо время реализации меньше либо равно времени гугления по данному вопросу + прикручиванию того, что ты там нагуглишь.

> Вряд ли есть реализации без использования динамической памяти

Почему? По своей постановке эта задача требует только одного непрерывного куска памяти -- так что нет особой разницы откуда он взялся.

Да, именно про непрерывный кусок памяти я и думал.
И в итоговой программе он будет статическим (слишком велики расходы, юзать malloc`и).

про malloc я не понял: разве время выполнения malloc не будет амортизировано? его же один раз запускают.

> про malloc я не понял: разве время выполнения malloc не будет амортизировано? его же один раз запускают.

Если его запускают один раз за выполнение работы - то почему бы не заменить его статическим массивом?

А вообще malloc не подходит, потомучто код, который его должен былбы вызывать, выполняется на контроллере из прерывания, а там недопустима такая потенциально долгая операция, как поиск свободной памяти. Тем более, что там памяти мало.

статический массив в .bss
при необходимости вызов brk() для его увеличения 

static unsigned long size;
static char fifo[SIZE];
static void init() {
    size = ((unsigned long)_end + PAGE_SIZE) & ~PAGE_SIZE - (unsigned long)fifo;
}

Непонятно, это откуда код, что за .bss? Чnото он не с начала и не до конца!

.bss - секция неинициализированных данных в структуре файлов формата ELF
код полный
init() вызывается перед началом работы с fifo для определения его полного размера
если в процессе работы size станет нулевым, вызываем brk() для увеличения размера fifo

_end определяет линейный адрес последнего байта сегмента данных
значение brk при вызове main() равно (_end + 4096) & ~4095
оно определяет адрес начала кучи, где можно резервировать память посредством brk()

Уф.. написать всеже проще оказалось. http://store.ierton.homelinux.net/tmp/fw/packet_buffer.h http://store.ierton.homelinux.net/tmp/fw/packet_buffer.c

Всеравно, спасибо за поддержку)

> Уф.. написать всеже проще оказалось. http://store.ierton.homelinux.net/tmp/fw/packet_buffer.h http://store.ierton.homelinux.net/tmp/fw/packet_buffer.c

"нужно ли расстреливать на месте без суда и следствия за комментарии в коде на русском?" впрочем, вопрос скорее риторический.

// wbr

в команде есть люди, у которых с английским неважно

> в команде есть люди, у которых с английским неважно

вспоминается один достаточно толстый проект, которым приходилось активно пользоваться при этом автор то-же был не в ладах с английским [или с головой]. как следствие, весь код был обильно увешан комментариями на французском. вот была прелесть в этом копаться, скажу я вам..

// wbr

ps: впрочем, к самой технической реализации это отношения не имеет. в конце-концов, работает и ладно.

// wbr