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

[Alexashka]

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

[ViKo]

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

[rudy_b]

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

Все так, но не нужно два буфера - нужен только один - кольцевой.
И, как и предложено, и принимать и считывать по прерываниям. Если они одного уровня - друг друга прерывать не будут, обычно на 8-ми битках так сделано. Приоритет работает только при одновременном возникновении двух запросов - вот тогда первым будет более приоритетный.
Т.е. при работе с указателями вообще никаких проблем не будет.

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

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

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

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

Заморочно, конечно, но джиттер будет минимален.

Аналогичное взаимодействие можно организовать и между main loop и прерыванием считывания. Тогда будет только одно прерывание и джиттер будет меньше.

[Dog Pawlowa]

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

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

Извините за ОФФ.