caxapa.ru :: Похоже, я таки наговнокодил. Исходные данные: МК GD32VF103 (RV32IMAC), тулчейн от klen'a, оптимизация -Os. Проблема заключается в некорректной работе функции подсчета crc с использованием аппаратного блока. Листинги кода и ассемблерный дамп в приложенном файле

evgeniy1294 (05.01.2021 21:51, просмотров: 7124)

Похоже, я таки наговнокодил. Исходные данные: МК GD32VF103 (RV32IMAC), тулчейн от klen'a, оптимизация -Os. Проблема заключается в некорректной работе функции подсчета crc с использованием аппаратного блока. Листинги кода и ассемблерный дамп в приложенном файле listing.txt

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

Ответить

- Я вижу тут много проблем. VladislavS.(1209 знак., 06.01.2021 09:07)
  - 1. Есть такое, да. На cortex-m0 можно словить HardFault, так как он не умеет невыровненный доступ. На этот случай, а также для быстрой обработки небольших пакетов, написана отдельная функция: evgeniy1294(2361 знак., 06.01.2021 10:22)
    - Интересно. Хотя итераторы массива и вектора скорее всего являются обёртками указателей, они не приводятся к указателям ни неявно, ни с помощью static_cast. По крайней мере, в VS19 и IAR. Чтобы из итератора получить указатель, проходится использовать ~~безумную~~ конструкцию &*. - йцyкeн(06.01.2021 16:32)
      - Как я понял это следствие implementation defined природы итераторов и работает только на gcc. Так что это говнокод, буду исправлять. - evgeniy1294(06.01.2021 21:27)
        
        Переделал интерфейс, теперь вместо указателя end нужно передать size. evgeniy1294(48 знак., 07.01.2021 05:47, ссылка, ссылка)
        
        Зачем тащить (CRC_TypeDef* crc) в интерфейс каждого метода? Шаблоны так шаблоны. Пример. VladislavS.(706 знак., 07.01.2021 08:41)
        
        Crc в этом плане уникален, он может использоваться разной периферией с разными моделями. Дополнительно, хардварных калькуляторов может быть 2 или 3. Поэтому, чтобы не делать лишние using-и, тем самым сократив описание, сделано вот так. evgeniy1294(370 знак., 07.01.2021 15:22)
        
        Кто кроме вас может что-то по ошибке запихнуть? Библиотека написана, из неё торчит интерфейс, который не подразумевает запихивания в него чего-либо. Зачем пользователь полезет в кишки? - VladislavS.(07.01.2021 15:28)
        
        Все равно это требует отдельного описания под каждый чип внутри библиотеки. Лишнего кода будет много, да, он будет только в библиотеке, но ошибиться и я могу. Я думаю над это проблемой, потом все "специальное" перетащу в основной заголовочник, тогда можно будет сократить писанину. - evgeniy1294(07.01.2021 15:45)
    - Словить hardfault по невыровненному доступу можно даже на Cortex-M4. Так что, лучше в принципе не делать таких опасных вещей. VladislavS.(924 знак., 06.01.2021 10:27)
      - Самый быстрый вариант, который у меня получился: evgeniy1294(1570 знак., 06.01.2021 15:23)
        
        У вас на RISC-V пример с невыровненным доступом был, я соответственно так же и написал. Если на Cortex-M0, то конечно, надо как у вас. - VladislavS.(06.01.2021 16:10)
        
        Для RISC-V я тоже либу поправил, зарезав все потенциально опасное. - evgeniy1294(06.01.2021 16:13)
        
        Чота я не понял, что тут дают плюсы кроме жуткого головняка. Почему бы не наваять на голых сях? - SciFi(06.01.2021 15:25)
        
        На голых сях тот же самый головняк с выравниваниями. Ну будет вместо reinterpret_cast обычное приведение типов через (), в остальном тоже самое. - evgeniy1294(06.01.2021 15:28)
        
        Букофф меньше будет без потери смысла. Ящетаю, это будет чистый вин-вин. Плюсовые зануды опечалятся, конечно, но предлагаю их мнение игнорировать :-) - SciFi(06.01.2021 15:33)
        
        Я согласен с тем, что С++ очень многословен, а всякие reinterpret_cast<>, на мой взгляд, отвратительные решения в языке. Можно было бы сделать как-нибудь покороче сделать. - evgeniy1294(06.01.2021 15:37)
        
        Пока плюсы поддерживают старые способы приведения типов, то применение вместо них reinterpret_cast<> это настоящее мозго@бство. Ни одного преимущества от этого код не получает. Только нечитаемым становится. - VladislavS.(06.01.2021 16:13)
        
        Статические анализаторы уже ругаются матом на old-style cast. - evgeniy1294(06.01.2021 16:15)
        
        Да и хрен с ним. Программист для анализатора или анализатор для программиста? Поддержку никогда не уберут. - VladislavS.(06.01.2021 16:42)
      - Без кода такой косяк поймать можно: проц STM32L151, рядом GSM модем на плате, при работе на передачу - хард фаулт был пока антенну на 90 градусов не развернул. А программисты то, да в шоке были. - Visitor(06.01.2021 14:13)

Средства и методы разработки