тоже... ткнулся наугад

и сразу же вопрос: а нафига, если есть RCC?

Сейчас не могу найти док, но как то читал code style разрабов, они там довольно резко написали, что-то типа "мы используем GCC, если вам нравится другой тулчейн, мучайтесь с портированием сами, мы таким не страдаем".
Что, в целом, разумно, ибо:
1) пора переходить на ГЦЦ
2) если неохота, можно собрать либу в объектник с помощью ГЦЦ и цеплять тем же ИАРом. Я, пожалуй, в свободное время так и поступлю

Сообщение отредактировал drozel - Nov 6 2015, 17:33

непонятно к чему эти рассуждения.
там нет шаблонов готовых проектов Кейл. только и всего. Т.е. чтобы собрать либу (именно либу а не таскать с собой килограмм любимых исходников) - нужно притащить в кейловский проект все что нужно
выясняется что же нужно командой make -n
мэйк вывалит те команды, которые он собирается выполнять. Оттуда понять, какие файлы куда и сделать один большой мультитаргет, потом собрать все что необходимо в либу - и энджой.
никаких там мифических директив GCC и в помине нету.
и непортируемых фишек а-ля winAVR там не найдете.

Возможно,
и множество других - и не директивы GCC, но в ИАРе они не компилируются

Где там packed(4)? Вот grep'ом прошелся - нигде и близко такого нету

__attribute__((packed)) понимается кейлом с полуслова. И при чем тут ИАР если речь про кейл.


А вот про always_inline - кейл его просто игнорирует
Вот асмовые вставки надо пересмотреть, то да.

Ну мы немного про разное думаем)
Я в ответ на это

начал мыслить в сторону ИАРа, которым пользуюсь, а вы в сторону кейла, хотя, не спорю, конкретики было больше про кейл.
Кстати, не знал, что он понимает __attribute.
А packed(4) был в одной из вложенных структур в USB

Не скажете, что за стиль писать объявлять структуры без typedef у разрабов? Есть какие-то подводные камни?[/code]

Сообщение отредактировал drozel - Nov 7 2015, 13:17

Это же плюсы, там структура это тоже класс, никаких typedef не надо, имя структуры можно сразу использовать для объявления переменных и без слова struct.

Поясните? Вроде, объявлять без struct можно как раз тогда, когда определена она как

Писал на эту тему недавно:
http://electronix.ru/forum/index.php?s=&am...t&p=1326899
Ваш пример на C++ можно переписать так:

libopencm3 - это си без плюсов.

это я с stm32plus перепутал, а в libopencm3 (посмотрел сейчас) конструкция typedef struct присутствует в изрядных количествах.
По большому счёту, объявления typedef struct не являются совершенно необходимыми, можно и без них обойтись, просто писанины чуть больше.
Если где-то их не оказалось - это не криминал, тут больше вопрос вопрос о читабельности и единстве стиля.

Я и не агитирую за неё, просто _моему_ глазу приятнее смотрится, чем куб и иже с ним (структурированность и кодестайл).
Многое я бы реализовал иначе.
Что касается УАРТа, то у меня он свой собственный без каких бы то ни было библиотек, так что ничем помочь не могу...

Подскажите бывалые, а есть возможность использовать libopencm3 в проекте уже напиленом на HAL, с keil-RTX? сосуществование возможно или вообще никак?

Извиняюсь за вопрос не по теме (ну не совсем по теме), но тут много писали про работу с UART.
Понятно, что передавать проще всего через DMA. А вот с приемом через DMA - проблема, пока решаю ее приемом по прерываниям, что накладно.

Если принимать по DMA, то что будет с ошибками? Что сделает DMA при наличии ошибок типа parity error или frame error? Положит в буфер фуфловое значение или даст ошибку DMA (что неправильно) или пропустит этот байт? Как это определить по данным в буфере DMA или FIFO? Прерывания приемника по ошибке можно сделать, но, при работе по DMA, это мало что даст. Вот если бы в буфер писался бы еще и байт статуса...

В описаниях STM32(f207) не нашел подробностей, может кто подскажет как решается эта проблема?

Какой смысл работать с UART по DMA, если там скорости никакущие?