caxapa.ru :: К чему это? Я именно так и считываю 1 байт данных. Другое дело - я не могу очистить FIFO от мусора перед тем, как считать нужные данные. Даже если сделать 100 раз вызов (void)SPI2->DR, получим 0 в RXNE, но лишние нули в FIFO!

Eddy_Em (11.05.2023 16:59, просмотров: 168) ответил Costic на Регистры, конечно, для крутых программистов, но ими надо уметь пользоваться.

К чему это? Я именно так и считываю 1 байт данных. Другое дело - я не могу очистить FIFO от мусора перед тем, как считать нужные данные. Даже если сделать 100 раз вызов (void)SPI2->DR, получим 0 в RXNE, но лишние нули в FIFO!

eddy-em.livejournal.com github.com/eddyem

Ответить

- Вызов SPI2->DR считывает 16 бит, чтобы считать только 8 бит надо указать это явно компилятору. - Costic(11.05.2023 19:22)
  - А мне не нужно считывать 8 бит: мне сначала нужно очистить принимающий FIFO! Eddy_Em(35 знак., 11.05.2023 19:30)
    - Кстати, да. Почему бы не заменить (void)SPI2->DR на (void)*(uint8_t volatile*)&SPI2->DR ? А вдруг? - SciFi(11.05.2023 20:03)
      - я в стм-ах не силён. но если в описании регистра указана его разрядность - то чтение/запись АППАРАТНО в(из) него производится именно с "этой" разрядностью ВСЕГДА. В моём случае (какоето ядро арм) все регистры 32бит (периферии) (и отсутствует байтный доступ аппаратно). А вот приведение типа в сторону уменьшения может привести к злостным побочным эффектам. уж лучше читать/писать полностью регистр, а модифицировать в отдельных переменных. (это общее правило, из которого может Zoro(17 знак., 11.05.2023 23:37)
        
        Архитектура ARM позволяет к одной и той же области памяти (к области ввода вывода периферии в частности) обращаться с разной разрядностью. Для некоторых регистров особо оговариваются условия разрядность доступа, а к некоторым (к большинству?) можно обращаться как угодно. Всё зависит от реализации периферийного модуля - как он реагирует на сигналы шины, к которой подключён. Так что доступ возможен с любой разрядностью, а вот реакция периферии на этот доступ зависит от Nikolay_Po(21 знак., 11.05.2023 23:49)
        
        Тут можно пример привести не из АРМ... POV(512 знак., 11.05.2023 23:55)
        
        не без этого. у 51 периферия регистры 8 бит, а по смыслу пару регистров образует "единый регистр " и тут (бывает) важен порядок чтения/записи. Но зачем искать приключения там где можно "тупо" считать целиком регистр модифицировать значение и записать обратно ? накой ляд приводить тип данных/регистра разной размерности? - Zoro(12.05.2023 00:37)
        
        Способ, порядок, момент записи могут иметь значение для модуля периферии. А приведение типа к другому размеру как раз меняет способ доступа. Был (volatile uint16_t) - доступ выполнялся ассемблерной командой доступа к слову, с выравниванием 16 бит. Переопределили тип в (volatile uint8_t) - компилятор, для того же адреса, использует другую команду ассемблера - для доступа к байту, с байтовым выравниванием. - Nikolay_Po(12.05.2023 00:46)
      - Так я тоже пробовал - но при этом же считывается лишь один байт, а не два. Eddy_Em(145 знак., 11.05.2023 20:39)
        
        Сие есть неправда. При приведении типа volatile отваливается, поэтому его нужно прилеплять заново. - SciFi(11.05.2023 20:43)
        
        Ну, на этот счет нужно будет проверить. - Eddy_Em(11.05.2023 20:49)
        
        Тут есть хотя бы интуитивный аргумент: если volatile не отваливается при явном приведении типа, как же от него избавиться? Неявным приведением? И кто сказал, что если не отваливается при явном, то отваливается при неявном? Короче, фигня какая-то получится. Или вот про const, но суть та же: SciFi(1 знак., 11.05.2023 21:04, ссылка)
        
        Я глянул листинг - не отваливается у меня volatile при приведении типов. Да и чего бы ей отвалиться? Eddy_Em(654 знак., 11.05.2023 21:07)
        
        Каким образом листинг может доказать, что volatile не отваливается? Правильно, никаким. Потому что в будущей версии шибко умного компилятора может появиться оптимизация, которая всё поломает. Скажете, невозможно? Это происходит почти каждый день! - SciFi(11.05.2023 21:16)
        
        Да элементарно же: у меня в листинге есть чтение из SPI2->DR - вот и доказательство, что волатильность не отвалилась! Иначе этого чтения не было бы (т.к. компилятор выкинул бы бессмысленную конструкцию). - Eddy_Em(11.05.2023 21:26)
        
        Не откажу себе в удовольствии ткнуть мордой. На -O1 VladislavS.(1 знак., 12.05.2023 07:14, картинка)
        
        Только очистить буфер перед приемом DMA это почему-то не помогает. Вот перед блокирующим приемом - да, очищает... Eddy_Em(888 знак., 12.05.2023 14:49)
        
        Ну ни хрена себе... - Eddy_Em(12.05.2023 08:12)
        
        С нулевой оптимизацией не выкинет. А с ненулевой никто не обязывает компилятор делать волшебные штуки, которые вы придумали. Он живёт своей жизнью. - SciFi(11.05.2023 21:29 - 21:31)
        
        Еще раз: у меня -O2, ничего не выкинул. Если сделать аналогичное с не-волатильной переменной - выкинет. - Eddy_Em(11.05.2023 21:31)
        
        А если -O3 --flto? Я только так и собираю проекты для МК с GCC. - Nikolay_Po(11.05.2023 21:54)
        
        -O3 - слишком круто. А -flto я только в release режиме включаю. В любом случае, волатильные переменные никуда не "убегут". Eddy_Em(300 знак., 11.05.2023 22:42)
        
        Перед запуском DMA барьер воткнуть не забыли? __DSB() - LightElf(12.05.2023 01:37)
        
        Никогда не втыкал и работало... - Eddy_Em(12.05.2023 08:12)
        
        DMA и SPI, емнип, на разных шинах висят. Есть шанс, что у вас DMA стартует раньше, чем завершается программное вычитывание мусора из SPI. - LightElf(12.05.2023 11:48)
        
        Не оправдание! Nikolay_Po(252 знак., 12.05.2023 09:36)
        
        Жесть просто какая-то! Eddy_Em(689 знак., 11.05.2023 23:08)
        
        Он чем-то от СПи в Ф1хх отличается? СПИ на Ф103 у меня только в путь. С ДМА и без оного. Даже намёка на проблемы не было.. ах да, я ж SPL использую.. а это неспортивно. - POV(11.05.2023 23:12)
        
        Ага: там гребаного FIFO нет на RX/Tx. А здесь на Tx трехбайтный FIFO, а на RX - четырехбайтный. И пляши с этим, как хочешь. Eddy_Em(463 знак., 11.05.2023 23:55, youtube)
        
        Ну, кстати да, у Ф1 нет в хедере spi никакого упоминания fifo. - POV(12.05.2023 00:03)
        
        Офигеть. Плясать с бубном вокруг GCC. И кто-то что-то рассказывал про 21 век :-( - SciFi(11.05.2023 21:57)
        
        В смысле плясать? Включил максимальную оптимизацию и работай! Никаких плясок. Это ТС не пользуется всеми прелестями компилятора и, поэтому, может не замечать упущенных volatile. - Nikolay_Po(11.05.2023 22:36)
        
        Я-то не пользуюсь? Eddy_Em(487 знак., 12.05.2023 00:02)
        
        Ну, я о том же. Вы просто не застали - я из раза в раз повторяю: "Хочешь писать качественный код - всегда включай полную оптимизацию и LTO! Так больше шансов сразу увидеть баг в коде до того, как он вылезет потом, по мере усложнения проекта". Нет у компилятора чрезмерной оптимизации, если не включать флаги быстрой, но неточной математики и ещё там по мелочи, по умолчанию выключенные. Зато есть недостаточно тщательно проработанный код. Nikolay_Po(530 знак., 12.05.2023 00:27, ссылка)
        
        Бывает и проблема при использовании сторонних header-only библиотек. Кажись, в ранней версии nuklear я на такой косяк при -О3 натыкался. Eddy_Em(187 знак., 12.05.2023 00:34)
        
        Нет, там по условиям портирования, в документации, функции этого файла должны по указателю на функцию из прерывания таймера вызываться. Просто человек, готовивший порт много лет назад, не использовал оптимизацию в полной мере. И даже у меня в этот код какое-то время, на начальном этапе, работал, а потом перестал. Стал копать почему - и нашёл. - Nikolay_Po(12.05.2023 00:38)
        
        Думаю, тому разработчику STM8 или пики понравились бы: под них есть только SDCC, а у этой заразы с оптимизацией совсем плохо... - Eddy_Em(12.05.2023 00:41)
        
        Ну, я для AVR использую AVR-GCC-12. С оптимизациями там порядок, я так не соптимизирую. И косяки кода становятся явными. Так что корректная работа кода в полной оптимизации, с LTO - один из признаков качества. Nikolay_Po(1 знак., 12.05.2023 00:51, ссылка)
        
        Вот, только что решил таки проверить: а что будет, если собрать не с -O2, а с -O3? Размер прошивки с 35кБ вырос аж до 44кБ!!! Вот так мне gcc наоптимизировал (видимо, все, что только можно, позаинлайнил). Eddy_Em(545 знак., 14.05.2023 12:17)
        
        По моему, debug, при использовании LTO, не имеет смысла. Разве что повезет, в массив какой заглянуть или конфигурацию регистров периферии глянуть. Остальное - практически без шансов. - Nikolay_Po(14.05.2023 13:18)
        
        Не только инлайнит, но и циклы разматывает. - SciFi(14.05.2023 12:19)
        
        Вам виднее. - SciFi(11.05.2023 22:38)
        
        Вам виднее. Но список предрассудков пополняется. Оставайтесь на линии, будем пытаться лечить. Но это быстро не получится :-) - SciFi(11.05.2023 21:32)

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