а может просто код посмотреть ?
1. http://c.learncodethehardway.org/book/ex44.html
2. https://code.mythtv.org/doxygen/ringbuffer_8c_source.html
и еще примерно 5000000 примеров

Сообщение отредактировал x893 - Jun 5 2014, 09:15

Сознаюсь что ступил.
Диапазон адресов и правда будет 0x0010FF - 0x001000
В этом случае маску адресов не надо сдвигать на 12 бит.
Она должна быть 0x001000 | 0xFF т.е. равна максимальному адресу 0x0010FF
Всё остальное остаётся в силе - при наложении маски адрес автоматически закольцуется при превышении границы буффера.

топикстартеру
Может быть Вам стоит пересмотреть организацию буффера и сделать его по типу FIFO.
Тогда в этих извращениях не будет необходимости и подпрограмма считывания данных будет извлекать данные до опустошения буффера, а контролем перехода через границу буффера будет заниматься процедура извлечения байта/слова данных.

Да в них и так нет необходимости. Что все прицепились к этим маскам, выгоды никакой.

Видать Вы не программировали микроконтроллеры.
Например, в обработчике прерывания необходимо выполнить работу как можно быстрее. Использование маски приводит к меньшему количеству кода и более быстрому выполнению.

Далеко не всегда даже в микроконтроллерах на счету каждый такт или байт. Зачастую сопровождаемый код или некратный степени двойки размер перевешивают.

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

Я не сую везде, и размеры буфера в основном степени двойки.
Конечно зависит от задачи, но программист должен представлять в какие инструкции, хотя бы примерно, будет компилироваться его код и к чему это приведет.
Обработка по маске - это всегда одинаковое постоянное время обработки данного участка кода. Длительность обработки по условию меняется в зависимости от ветки по которой пройдет исполнение.

Как раз таки я прекрасно представляю, что будет в моем случае (ARM). В случае использования маски получиться одна инструкция AND, в случае использования условия мы получим CMP, IT и MOV, это если у нас Thumb2. Если же у нас ARM набор инструкций, то IT не будет. Выходит для распространенных МК на базе Cortex-M и ARM7 использование условия в худшем случае увеличит время исполнения на два такта, при этом время выполнения в обоих случаях будет постоянным. Так вот, какие бы оптимизации мы не пытались сделать, два такта - это НИЧТО. Они потонут в тактах, требуемых на вызов функции, на работу со стеком, на обращение к переменной в RAM. В конце-концов у нас тут не DSP, где пару тактов может и сделали бы погоду. Более простые МК на базе других архитектур могут сгенерировать на месте условия какой-нибудь условный переход. Да, в этом случае тактов будет больше, но опять же не настолько больше, чтобы на это обращать внимание.

Это называется переоптимизация. Я сам раньше грешил этим, но теперь отношусь к таким вещам попроще. В конце концов, если от увеличения времени исполнения участка кода всего на пару тактов программа перестает работать, или работает не правильно - то это явные архитектурные проблемы, означающие, что вы рассматриваете микробов через молоток. Нужны такты - есть всякие FPGA и DSP.

Недавно решал такую же проблему, только "заворот" указателя при использовании данных был недопустимым по потерям производительности.
В результате родился такой код с двойным размером буфера и дублированием данных - где всегда есть непрерывная область отсчётов.
Оптимизатор современных версий GCC очень качественно разворачивает такие конструкции.


Сообщение отредактировал Genadi Zawidowski - Jun 12 2014, 20:43