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

По поводу неуловимых глюков.
Я уже писал насчёт проблемы использования внешних глобальных переменных с атрибутом volatile.
Прямое использование в функции под GCC4,8 и выше - будет давать ошибку. Например в простом выражении где А - внешняя глобальная volatile переменная.
А= (А+ В +С +Е)/2
переменная А будет физически переписана 4 раза!!! Потому что она volatile и внешняя.
Чтобы избавиться от подобного - необходимо объявить локальную переменную в пределах функции, и работать уже с ней, и уже готовый результат переписать в внешнюю А.

По этой причине большая часть кода написанного под GCC4.2 - глючит. Когда стало широко применяться внеочередное исполнение инструкций в коде ARM процессоров (GCC4.8) - вздрогнули все аурдинщики, без исключения.
Это отдельная тема, но вы должны быть в курсе.

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

Я нигде не использую глобальные переменные. Ни одной.


Я уже давно не пользую GCC, поэтому вообще не в курсе его костылей ((
А ардуино использую лишь для примитивных разовых поделок, скажем, проверить по-быстрому какой-нить новый компонент. Как макетку с мозгами.

ps А вообще при чем тут gcc?

Да ёёёё.
Кто-ж использует кольцевой буфер для физических устройств?????
Для физики все (без исключения) применяют линейный буфер: одинарный или двойной - для одного!!! направления.
Спокойно создаём сообщение, дожидаемся готовности физики, и пинаем дма.
Всё, тайминги в порядке, процессорное время свободно, мозг никто не клюёт.

Я использую, вполне успешно ))) Особенно там, где DMA нет или он не доступен для этой физики.
Но сам кольцевой буфер у меня одинаковый для всех проектов без привязки к физике, вообще ни к чему не привязан.
Не пойму, почему с физикой нельзя использовать кольцевой буфер?


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

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

Возможно, если делать это снаружи соотв. методов, а не внутри, как у меня было раньше.
Сначала запрещаются соотв. прерывания, которые могут нарушить логику работы, и уже потом оперируем данными.
Но можно реализовывать критические секции и внутри методов очереди (см. ниже enterCritical / exitCritical ).


Все поля класса Queue - закрытые, private. Вообще, во всех классах поля закрытые, только часть методов доступна владельцу объекта.
Равно как и класс имеет право обращаться лишь к некоторым методам его владельца.
Поэтому нет никакого прямого доступа к полям Queue, впрочем, как и к любому другому классу.


Все возможно, если писать под с++ используя и шаблоны )))
У меня используется шаблон очереди, а у него впрочем как у каждого объекта есть поле владельца (owner).
При создании и инициализации объекта очереди ей передается ссылка на ее владельца, уже который имеет обязательные методы enterCritical и exitCritical, доступные этому экземпляру Queue
их и вызывают соотв. методы очереди. Пока что до данного момента было так ...

зы. Предлагаю уходить в другую тему, иначе погонят не спрашивая...

Пациент неоперабелен. Только в морг...
Жизни не смыслит без критических секций, а ему запрещают. Беда...

ОТ: непристало форумеру со статусом "гуру" использовать такую терминологию по отношению к коллегам. Тот случай, когда медные трубы непроходимы?

Ага, то есть, в очереди таки ничего запрещать не надо? Ну надо же!


В любом случае, очередь не в курсе про прерывания от, например, UART. А полное запрещение прерываний не всегда желательно.
Вы, конечно, можете сказать, что owner может предоставить методы enterCritical / exitCritical, которые как раз запрещают/разрешают прерывания от UART. Но ведь вам не всегда надо разрешать, а только когда очередь не пуста. А такую функциональность в очередь уже не встроить.

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

Именно так я и скажу


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

зы Если есть еще какие вопросы, предлагаю перейти в другую тему или в личку ))

Где именно вы умудряетесь нарушить алгоритм?
1 прочитать в ЛОКАЛЬНЫЕ переменные указатели кольцевого буфера
2 обработать данные (записать или прочитать), если таковые имеются
3 переписать ОДИН указатель по ЗАВЕРШЕНИЮ работы с данными.
Прошу внимательно прочитать, и дать простой ответ под номером строки 1-2-3.

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

Прервать алгоритм можно в любом месте, например прерыванием или переключением задач. Главное корректно его восстанавливать.

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

Я именно то же самое просил у товарища несколько раз. Специально для него написал простейшую реализацию классического кольца. Просил указать в какой конкретно строке и что именно нужно сделать (согласно условиям использования изложенным мной там же) чтобы сломать. На что не получил никакого ответа

Я отвечу за Forger-а, а то он как-то невнятно объясняет.
Он описал такой случай: изначально буфер не пуст. Мы собираемся добавить туда элемент. Между 1 и 2 произойдёт прерывание, забирающее данные из буфера, опустошит буфер, и отключит прерывания на передачу, а мы потом (после пункта 2) не включим прерывания передатчика, потому что судя по нашим локальным копиям указателей буфер был не пуст.

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

Определения читайте у ARM. [CENSORED] ничего не меняют.

Сообщение отредактировал IgorKossak - Jun 19 2017, 09:49