Работа с переменными в прерывании и основном теле, жутко неудобно выходит Опции

[Alexashka]

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

[ViKo]

Так зачем "чутка освободится..."? Сделайте 2 буфера. В один принимаете, из другого кидаете в ШИМ. Когда в том, что в ШИМ, данные закончатся, переключаетесь на тот, в который принимали. Он уже будет весь забит. И т.д. По-моему, это называется "двойная буферизация". А принимайте тоже по прерыванию, только приоритет задайте ниже, чем у таймера выкидывания. И... это, зачем большие буфера?

[Alexashka]

Так зачем "чутка освободится..."? Сделайте 2 буфера. В один принимаете, из другого кидаете в ШИМ. Когда в том, что в ШИМ, данные закончатся, переключаетесь на тот, в который принимали. Он уже будет весь забит. И т.д. По-моему, это называется "двойная буферизация". А принимайте тоже по прерыванию, только приоритет задайте ниже, чем у таймера выкидывания. И... это, зачем большие буфера?

Это не будет работать. Если один источник пишет быстрее, чем другой читает, то рано или поздно (сколько бы у вас ни было буферов) произойдет переполнение буфера. Скорости обоих процессов должны быть в среднем одинаковы.
А по поводу прерывания. Если приоритеты обоих одинаковы, то получаем джиттер в виде задержки входа в прерывание ШИМ равное по времени выполнению прерывания UART.
В случае если прерывание UART имеет меньший приоритет по сравнению с ШИМ, то будет тоже самое в плане критических секций - придется в прерывании UART временно блокировать прерывание ШИМ.

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

Именно поэтому использую почти всю встроенную память, а чего ее жалеть ради хорошего дела

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

Но тогда это будет работать также, как если UART будет в основном теле.

Тогда есть два варианта. Можно аккуратно работать с указатем записи (кратковременный запрет прерываний) - но это джиттер, хоть и малый.

Сейчас так и делаю. Причем что интересно полностью избежать запрета прерываний нельзя - его можно избежать когда в основном теле читаем переменную, изменяемую в прерывании -тут помогает метод двух чтений, который предложил Pasha. А вот в случае когда в прерывании читается переменная, изменяемая в основном теле (это нужно чтобы определить не нагнало ли чтение запись) этот метод не поможет.

А можно и без запрета прерываний.
...
Периодически происходит синхронизация этих указателей в старшем прерывании - для определения остатка свободного места в буфере.
...
Для синхронизации, младшее прерывание меняет свой указатель поэтапно, каждый раз выставляя и снимая бит валидности в отдельной переменной.
Т.е., перед изменением оно сначала снимает бит валидности, затем меняет указатель, затем ставит бит валидности. Это можно делать и для каждого байта по отдельности.
Старший приоритет синхронизирует свой указатель только если стоит бит валидности.
Это, практически, критическая секция, но специфическая, с пропуском, но без зависания.
...Аналогичное взаимодействие можно организовать и между main loop и прерыванием считывания.

Посмотрите, что я писал в сообщении #27, но то мое предложение оплевали и посоветовали выкинуть в утиль .
Это не сложно, но опять-таки не универсальное решение, потому как требует персональной корректировки функций по работе с кольцевым буфером под конкретную задачу.

Какие компоненты в систему заложишь, так она и поплывет.

PC + восьмибитник + требование к джиттеру = бульк

Не согласен с Вами. Восьмибитник отлично справляется, да у него нет канала DMA который можно накрутить в ШИМ имея какойнибудь Кортекс, но для моей задачи вполне хватает. И потом эта работа -мое хобби, а мне 8-битники нравятся гораздо больше, чем 32разрядные монстры с DMA контроллерами, ускорителями памяти и прочим и прочим.
Имеющихся аппаратных возможностей контроллера более чем достаточно для этой задачи.

[ViKo]

Это не будет работать. Если один источник пишет быстрее, чем другой читает, то рано или поздно (сколько бы у вас ни было буферов) произойдет переполнение буфера. Скорости обоих процессов должны быть в среднем одинаковы.

Так вы порциями (размером с целый буфер) выкидывайте с PC, по команде от вашего устройства. Как только один буфер использовали, переходите на другой, и давайте команду PC передавать данных на целый буфер (в который только что освободился). И не надо ломать голову, когда притормаживать, когда "газовать".
И сравнивать указатели, кто кого догоняет, не придется. Просто проходите по буферу от начала до конца. Один указатель записи, бежит по одному буферу, другой указатель чтения, бежит по другому. Красиво? Указатель записи дойдет до конца раньше и притихнет (в это время его можно на начало другого буфера переключить, но писать пока нечего). Когда указатель чтения дойдет до конца, переключаете его на другой буфер, и даете команду компьютеру выдать новую порцию.

[Alexashka]

Красиво?

Да, качели из двух буферов тоже вариант. Но переделывать сильно много надо, теперь уже не буду, возможно в следующий раз так и сделаю.

Вот Вы уже (и другие...) потратили на это обсуждение столько времени, что его цена многократно перекрывает разницу в цене между монстром и достаточным контроллером. Если бы Вы планировали миллионную серию, это имело бы смысл. А так - нет.

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

[Tanya]

Жаль если Вы этого не понимаете.

Понимаю, что Вам не результат нужен, а процесс борьбы.

[Alexashka]

Понимаю, что Вам не результат нужен, а процесс борьбы.

Таня, общение с профессионалами это всегда борьба полезно, я много для себя почерпнул. Наверное все варианты решения уже озвучены (и самый яркий из них -поменять контроллер ). Лично мне больше нравится простой и надежный как автомат Калашникова вариант с двумя буферами предложенный Viko. Думаю вопрос можно считать решенным.
Еще раз всем спасибо за обсуждение!