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