STM32F0xxx USB без HAL Опции

[alexf]

Делаю устройство на STM32F070. Сгенерировал код с USB CDC на кубе, и USB работает (пока) без нареканий. А вот попытки использовать HAL для других целей, скажем USART, создают больше проблем, чем решают. Для меня. Наверное, пользоваться не умею. В результате мешанина из HAL с прямыми обращениями к регистрам. Боюсь это меня рано или поздно узусит за задницу.

Так вот вопрос. Есть ли пример USB CDC без HAL? На F103 легко находится. Уже давно использовал. А для F0? Много ли надо менять, если нет готового кода?

[johnshadow]

Пример CDC для F072 можно подсмотреть в форке kuldeepdhaka/libopencm3-examples в ветке example/pwm/stm32f07.
под stm32f0xx пришлось в паре мест слегка поправить, т.к. получал hardfault по доступу к невыравненным данным.
типа такого:

Код

diff --git a/libopencm3/usb/usb_standard.c b/libopencm3/usb/usb_standard.c
index d94ceed..da47391 100644
--- a/libopencm3/usb/usb_standard.c
+++ b/libopencm3/usb/usb_standard.c
@@ -130,7 +130,9 @@ static uint16_t build_config_descriptor(usbd_device *usbd_dev,
    }

    /* Fill in wTotalLength. */
-    *(uint16_t *)(tmpbuf + 2) = totallen;
+    //*(uint16_t *)(tmpbuf + 2) = totallen;
+    *(tmpbuf + 2) = totallen & 0xFF;
+    *(tmpbuf + 3) = totallen >> 8;

    return total;
}

я так и не понял почему компилятор не обрабатывает такие ситуации сам (gcc-arm-embedded 5.4 2016q2). может кто из местных объяснит.

[Сергей Борщ]

я так и не понял почему компилятор не обрабатывает такие ситуации сам

Потому что не обязан. Вы же хотите, чтобы ваши программы были маленькими и быстрыми. Используете явное приведение типов - вся ответственность на вас.

[johnshadow]

Потому что не обязан. Вы же хотите, чтобы ваши программы были маленькими и быстрыми. Используете явное приведение типов - вся ответственность на вас.

Я просто думал, что для cortex-m0 компилятор генерирует безопасный код в тех случаях когда адрес переменной на момент компиляции не известен. Тогда мне не ясно назначение опции -mno-unaligned-access. Ладно бы hardfault возникал при оптимизациях Os или O3,
где побайтовый доступ потенциально приводил бы к раздутию кода или снижению производительности.

2Allregia: Нет, на IAR\KEil не проверял.

Кстати патч на мой вкус не очень. В таких случая лучше либо использовать memcpy (в релизе его соптимизируют в инлайн), либо код вроде такого:
...
В вашем решении много битовых операций на ровном месте.

memcpy при оптимизациях Os\O3 меня уже пару раз подводила. решение со структурой действительно потенциально быстрее, но
не будет ли генерироваться ассемблерный код, который будет вылетать при невыровненном доступе?

[Сергей Борщ]

memcpy при оптимизациях Os\O3 меня уже пару раз подводила.

Интересно. Когда подведет еще раз - выложите сюда, вероятнее всего вы просто не умеете ее готовить.