caxapa.ru :: Я вижу тут много проблем.

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

Я вижу тут много проблем.

1. Упаковка и невыровненый доступ. Вот тут *pu32 вы всенепременно когда-нибудь да огребёте. Даже если процессор умеет невыровненый доступ. Лучше соберите слово из четырёх (или меньше в хвосте) байт. Компилятор допетрит сам как это оптимально сделать.

2. TestSequence.data() это (uint8_t *). TestSequence.end() это std::_Array_iterator<uint8_t, 9U>. Не знаю почему компилятор такое молча пропускает, я бы на его месте обиделся.

std::array<std::uint8_t, 9> TestSequence;

template< typename T >

static std::uint32_t CalculateEther( const T* first, const T* last );

HardwareLogic::CalculateEther(TestSequence.data(), TestSequence.end());

3. Всё равно с ЛЮБЫМ типом этот код работать не будет. По хорошему, надо обкладывать его концептами, которые будут отсекать неподобающие типы. Так зачем их тянуть внутрь функции расчёта CRC? Для её работы нужен адрес (uint8_t *) и размер в байтах. Тогда будет работать железобетонно, если с невыровненым доступом не накосячить. Все вопросы преобразования типов и упаковки данных надо решать извне.

static std::uint32_t CalculateEther(const std::uint8_t *data, const std::uint32_t size);

Всё что сможет, компилятор и так оптимизирует.

Ответить

- 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)

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