Добрый вечер
Что имеем: 8 битный проц, программа в прерывании читает из кольцевого буфера, указатель чтения -просто индекс массива, двухбайтное число. В основном теле мне приходит поток байт, который я контролирую (запускаю/останавливаю поток) и размещаю байты в этом же кольцевом буфере по другому указателю -указателю записи (тоже индекс массива). До этих пор все замечательно, но чтобы управлять потоком мне нужно знать сколько байт содержится в буфере, для этого я беру разницу между указателями записи и чтения и побитно умножаю ее на (размер_массива - 1). Эту разницу приходится брать в нескольких местах программы, при этом на время вычисления нужно блокировать прерывание, поскольку операция не атомарная, а одна из переменных модифицируется в прерывании. Если этого не делать происходит глюк, если делать -появляется задержка обработки прерывания, а это нехорошо, т.к в нем происходит формирования аудио сигнала. Да и некрасиво это и неудобно -следить какую перменную обрабатываю, нужно или нет блокировать прерывание, ну и поскольку кольцевой буфер используется в различных прерываниях нужно еще и учитывать какое именно прерывание блокировать
Может это както по-другому можно делать, подскажите.

Заведите переменную "количество байт в буфере" и обновляйте её вместе с изменением указателей чтения и записи.

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

Значит, можно сделать порог кратным 256 и ограничиться сравнением одного старшего байта.
Да и вообще, логично начинать сравнение со старшего байта, а не с младшего, а младшие сравнивать только в случае равенства старших...

Сообщение отредактировал gerber - Oct 3 2015, 20:07

Разделите свой большой буфер на N маленьких и оперируйте буферами, а не байтами.

поддерживаю. при работе с аудиовыводом делал набор простых буферов: вычисляет быстро, запись и чтение разделены в одно время по разным буферам.

Примечик

Ну да, это получается примерно одно и тоже, старший байт по сути будет являться номером буфера.

Конечно не нужно никаких "количеств байт". Достаточно двух указателей (чтения/записи). И достаточно операции чтения/записи этих указателей сделать атомарными. И для вычисления кол-ва байт достаточно найти разность указателей (с учётом их цикличности), не нужно никаких "побитных умножений".
Неужто запрет прерывания на пару команд так влияет на выполнение алгоритма??? Тогда у Вас вероятно неправильно построен алгоритм.

можно проверку делать с учетом неатомарности, поскольку указатели в данном случае readonly
100500 раз об этом говорили, но давно, лет 6-7 назад. Пора обновлять
например.

если оптимизатор выкидывает - dsc должен быть volatile, наверное

Сообщение отредактировал _Pasha - Oct 4 2015, 11:28

Запрет прерывания на пару команд не повлияет я так думаю, но вычисление разницы двухбайтных чисел с последующим умножением на маску это всё же не 2 операции, с другой стороны как я уже писал, проблема не в этом, а в том, что при каждом таком обращении нужно добавлять запрет и разрешение прерывания, либо оборачивать это в функцию, плюс нужно следить -если изменил прерывание например с АЦП на UART, то нужно переписывать функции чтения переменной, а также чтения/записи в буфер.
А вот сделать чтение двухбайтного указателя атомарной операцией невозможно, поскольку ядро 8-разрядное Ну и до кучи объясните как сделать это
Допустим есть буфер, он занимает пространство от 0 до 2047, указатель есно двухбайтный, если мы возьмем разницу двух указателей например как "0"-"1" (значит в буфере 2047 байт данных) получим 0xFFFF, хотя должно быть 2047.


Поясните пожалуйста, что значит readonly если я как читаю указатель, так и пишу его (инкрементирую)
И что делает эта строчка К сожалению не читал обсуждение темы, о которой Вы говорите, если есть ссылочка прошу направить в нужном направлении

ЗАЧЕМ????


Сделать чтение двухбайтового числа на 8-разрядном процессоре атомарным (при отсутствии в нём команды чтения 16-разрядных чисел), элементарно:
u16 i;
__disable_interrupt();
i = var;
__enable_interrupt();
всё!




Это классика.
Если операции чтения/записи wpos, rpos в данном CPU атомарны, то можно использовать read(), write() в разных процессах/ISR как есть, без запретов прерываний.
Только обязательно read() и write() каждая должна вызываться только из одного процесса!
Если чтение/запись указателей неатомарны, то необходимо сделать их таковыми с помощью например запретов прерываний. В процессе, вызывающем read(), запрет прерываний необходим
при чтении wpos и записи rpos. Для write() - наоборот. Для occupy() и free() - аналогично - запрет прерываний для чтения того указателя, который модифицируется в другом процессе.


Это то же самое, что просто запрет прерывания на время чтения *dsc. Никакого преимущества не даёт по сранению с обычным запретом прерываний.
По скорости может быть как медленнее так и быстрее запрета - в зависимости от CPU.

<РУКАЛИЦО> Я так и делаю (см.первый пост) и уже дважды объяснил почему мне не нравится этот метод.

Вот об этом и речь -прикиньте, сколько таких мест, где нужно локально блокирова/разрешать прерывание. Можно конечно проще -блокировать прерывание перед вызовом функции read/write/free, но тогда задержка обработки прерывания станет недопустимо большой. Есть у меня идея использовать теневые регистры, которые будут обновляться в прерывании в том случае, если в основном теле к ним не производится обращение, но это уже в другой раз, пока что обошелся локальной блокировкой прерываний.
Посмотрел Ваш код, в принципе у меня примерно также, только не понял зачем Вы копируете глобальные rpos, wpos в локальные ir,iw ведь можно работать непосредственно с глобальными?
Да, к слову, указатели не использую, слишком медленно они обрабатываются в 8051: сначала ф-я чтения по указателю должна определить какую область памяти адресует указатель, а затем перейти к соответствующей команде чтения (там вроде как 4 варианта обращения к памяти и соответственно 4 разные ассемблерные команды) , с массивом такой ерунды не происходит -компилятор уже на этапе компиляции знает к какому типу памяти мы обращаемся поэутому все делается очень быстро.

Прикинул. От одного до двух мест в каждой моей функции. Разве это критично?


Потому что rpos и wpos объявлены с volatile и если написать i = rpos - wpos, то компилятор выдаст варнинг и будет прав.
К тому-же в варианте с копированием легко сделать нужное чтение атомарным с помощью запрета прерывания или так как предложил _Pasha.


У меня там и нет указателей.

Все три известные мне компилятора для x51 (Кейл, Иар и SDCC) позволяли объявлять указатель на конкретный тип памяти. Такие указатели и меньше места занимают и работают без этого ветвления. Посмотрите документацию на свой компилятор, наверняка они там есть.

И что значит "работать с глобальными"? Там где они модифицируются, можно делать только так, как я написал. А не напрямую глобальные.
Если Вы этого не поняли, значит не поняли ничего в моих функциях.