caxapa.ru :: Кстати в любой функции оперирующей с указателями на данные доступными из нескольких потоков (тот же ring buffer) можно запросто нарваться на перестановку порядка обращения к переменным. И volatile не поможет: gcc все эти volatile аккуратненько вынесет в конец функции и там запишет в том же порядке. Я на когда такое впервые увидел, чуть не рехнулся пока баг разгадывал. Поэтому после изменения указателей или после записи данных перед продвижением указателя нужно обязательно

fk0, легенда (17.05.2020 13:09, просмотров: 765) ответил RxTx на Я пока что в командировке, так что "решено" это условно, временно. Я к тому так написал чтобы не ломали голову из-за меня, как бы не тратили энергию. Но если есть какие-то мысли, конечно пишите. Приеду домой, буду разбираться, трассировать времянки итд. "Решено" так: сделал код прерывания как можно более коротким, просто запись в ring buffer. Об этом писал здесь: и один из UART'ов у меня уже был так построен. Этот (отладочную консоль) я перевел, остался еще один,

Кстати в любой функции оперирующей с указателями на данные доступными из нескольких потоков (тот же ring buffer) можно запросто нарваться на перестановку порядка обращения к переменным. И volatile не поможет: gcc все эти volatile аккуратненько вынесет в конец функции и там запишет в том же порядке. Я на когда такое впервые увидел, чуть не рехнулся пока баг разгадывал. Поэтому после изменения указателей или после записи данных перед продвижением указателя нужно обязательно

вставлять ручками memory barrier. На многоядерных системах ещё нужно память между ядрами насильно синхронизировать через спец. инструкцию процессора. Барьером (для одноядерных) в принципе является вызов любой функции и это наверное оптимальный вариант для кроссплатформенности. Либо писать asm volatile("": : :"memory") , либо __sync_synchronize(), но это уже компиляторо-специфично.

[ZX]

Ответить

- "нарваться на перестановку порядка обращения" и "запишет в том же порядке". Ты уж определись. - SciFi(17.05.2020 13:18)
  - volatile-указатели на данные записывались в конце функции, в том порядке, как они писались в функции. Но данные писались независимо в теле функции. Т.е. данные писались, указатели не двигались. А потом на выходе подвинулись указатели, ровно так как они должны были бы подвинуться пока писались данные. Идея в том, что gcc не пишет volatile переменные, а пишет их значения в регистры (коих у мипса дофига). А потом перед выходом эти регистры натурально записывает в память. - fk0(17.05.2020 14:01)
    - То есть забыли добавить volatile в объявление "uint8_t fifo[];"? Расплата вполне заслуженная. - SciFi(17.05.2020 14:05)
      - Если добавлять volatile для всей памяти -- это будет треш, угар и содомия (при просмотре дизассемблера -- крайне неоптимальный код). Так делать не нужно. Потом возникает другая проблема -- вся область памяти становится несовместимой (без постоянных reinterpret_cast'ов) с обычными указателями и всеми интерфейсами в программе. Вообще volatile не нужен. Достаточно вставлять memory barrier. В случае кольцевого буфера: после записи данных и перед измененим указателя записи, и fk0(392 знак., 17.05.2020 14:20, ссылка)

ARM, RISC-V контроллеры