STM32 новичку в ARM что к чему

azhel12

[uquote="VladislavS",url="/forum/viewtopic.php?p=4351769#p4351769"]Не всё равно, в какой порт какой бит писать надо вычислить. При сильном замесе кода будет много.[/uquote]
Конечно, не спорю. И раз уж речь зашла, хотел бы узнать, как вы это делаете, может, у меня менее оптимально и получится улучшить.

[uquote="VladislavS",url="/forum/viewtopic.php?p=4351769#p4351769"]Есть, конечно. Конкретную задачу завсегда можно решить эффективней специальным кодом, нежели универсальным.[/uquote]
Разумеется, имел ввиду универсальную (библиотечную) реализацию.

Реклама

VladislavS

[uquote="azhel12",url="/forum/viewtopic.php?p=4351774#p4351774"]И раз уж речь зашла, хотел бы узнать, как вы это делаете,[/uquote]Недавно выкладывал для AVR. Если интересна добавка для других контроллеров - стучите в личку.

Реклама

azhel12

[uquote="VladislavS",url="/forum/viewtopic.php?p=4351780#p4351780"]Недавно выкладывал для AVR.[/uquote]
Ага, глобально так же, но у вас красивее за счет использования constexpr/consteval, с которыми код больше похож на классический плюсовый, у меня вышло чисто на шаблонах (по заветам Александреску, по сути), поэтому читается сложнее. Если будут силы, то стащу у вас наработки и переделаю на обычные const-методы, можно?

P.S. Не в тему, но интересно: это в личных проектах такой подход используете или где-то в коммерческой командной разработке такая красота? Может, есть вакансии открытые?

Eddy_Em

[uquote="VladislavS",url="/forum/viewtopic.php?p=4351769#p4351769"]Конкретную задачу завсегда можно решить эффективней специальным кодом, нежели универсальным.[/uquote]
Но когда хочется хоть немножко универсальности (мне, например, лень под каждую железяку переделывать обработчик кнопок), приходится городить всякие массивы. Ну и в результате выходит несколько больше тактов на один раз, т.к. приходится сначала брать нужный индекс массива, а потом уж проверять IDR/ODR или менять BSRR…
Помню, кстати, как меня еще Серега (selevo) доставал с перегрузкой функционала пинов на STM8 (типа, и кнопочку туда, и экранчик). Ну, вполне это можно сделать в режиме открытого стока: держим пин в 1, да проверяем: если он в 0 (т.е. его кнопочкой через резистор в 47к к земле прижали), то юзер нажал кнопку; как надо зажечь элемент индикатора, придавливаем к нулю (индикатор должен быть в этом случае с общим анодом).

Кстати, вот интересно: в более свежих моделях появилась наконец-то возможность делать открытый сток в режиме верхнего плеча? Иной раз вполне даже нужная функция. А то в этих G0 столько всего нагородили, а вот про это забыли совершенно (ну, по крайней мере, хоть верхняя и нижняя подтяжки не зависят от режима работы порта, в отличие от древнего F103)!

Реклама

COKPOWEHEU

[uquote="ARV",url="/forum/viewtopic.php?p=4351766#p4351766"]я вам как бы намекнул, что КА мне осиливать не нужно, т.к. я его давно прожевал, переварил и высрал.[/uquote]
Фух. Прошу прощения если так.

azhel12 писал(а):[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4351756#p4351756"]Кстати, и ваши шаблоны не будут столь эффективны, если решать именно ту задачу, что вам дали - последовательный перебор ножек.[/uquote]
Позволю себе встрять в дискуссию, шаблонам абсолютно все равно, в каком порядке ножки, потому что при компиляции запись в такой виртуальный порт разворачивается в запись значения в регистр конкретного порта (пусть в BSRR), так что эффективнее, наверно, уже некуда.

Проблема только в том, что номер ножки задается из переменной, значение которой известно только в рантайме. Ровно та же проблема, которую попытались решить в ардуине.

VladislavS писал(а):Таки да, или функционал не реализован (нет)? И можно сразу весь список "ненужных задач"?

Чем подменять понятия, лучше бы ответили на вопрос. Часто ли у вас возникает необходимость менять назначение ножек в рантайме? А то пока выглядит будто вы выбрали ардуинскую реализацию за эталон и называете все остальные неполноценными.

VladislavS писал(а):А главное, от программиста потребуется просто указать список и всё. Остальное - дело компилятора.

Ну то есть разница по сравнению с ардуинской реализацией будет несущественной. Для данной задачи.
В общем случае, естественно, ваш подход лучше: можно назначить несколько независимых списков ног, можно их подстраивать под трассировку, да и для констант получается прямая запись в BSRR.

Реклама

Eddy_Em

Я вот намедни с убогим SHT30 наткнулся на то, что он любит "подвешивать" I2C, если ему что-то не понравилось (скажем, ты попросил неправильный регистр). И сбросить можно это, лишь сбросив питание этой хрени (ну или дергая ногу reset, что бесполезно, если кроме этой фигни на шине еще куча всего, что тоже может зависнуть). А чтобы не было паразитного питания, отключив 3.3В питания устройств на шине I2C, нужно еще и выключить I2C, перевести в режим PP или OD ноги SCL и SDA, да выставить их в нуль.

Реклама

КРАМ

[uquote="Eddy_Em",url="/forum/viewtopic.php?p=4351796#p4351796"]ну или дергая ногу reset, что бесполезно, если кроме этой фигни на шине еще куча всего, что тоже может зависнуть[/uquote]
Все ресеты этой кучи объединяем и тянем в мастер.

VladislavS

[uquote="azhel12",url="/forum/viewtopic.php?p=4351785#p4351785"](по заветам Александреску, по сути), поэтому читается сложнее.[/uquote]Ну какой Александреску, 23 год на календаре!

[uquote="azhel12",url="/forum/viewtopic.php?p=4351785#p4351785"]Если будут силы, то стащу у вас наработки и переделаю на обычные const-методы, можно?

[/uquote]Выложено, значит можно. У меня нет иллюзий, что какие-то лицензии могут на что-то влиять. Что нельзя просто не выложено.

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4351795#p4351795"]А то пока выглядит будто вы выбрали ардуинскую реализацию за эталон и называете все остальные неполноценными.[/uquote]Заметьте, это не я предложил макрос как альтернативу digitalWrite, которой он даже близко не является.

Eddy_Em

КРАМ, не у всех I2Cшных датчиков есть reset. Но многие из них любят убивать линию по всяким пустякам.

Reflector

[uquote="VladislavS",url="/forum/viewtopic.php?p=4351809#p4351809"]Ну какой Александреску, 23 год на календаре![/uquote]
Для С++26 есть предложение внести работу со списками типов в стандартную библиотеку и помимо этого с достаточно большой вероятностью можно будет что-то типа такого писать:

Код: Выделить всё

template<typename... Ts>
struct TypeList
{
    using... types = Ts;
    using last  = types...[-1];
    using slice = types...[1:3];
};

После эпидемического застоя комитет развернул бурную деятельность

azhel12

[uquote="Reflector",url="/forum/viewtopic.php?p=4351865#p4351865"]можно будет что-то типа такого писать[/uquote]
ИМХО это перебор (я про types...[-1]), вообще лично мне в целом текущий подход нравится - в сам язык (компилятор) добавлять поменьше, а остальное реализовывать на уровне стандартной библиотеки. Те же списки типов, включая операции с ними (поиск, взятие типа по индексу, сортировка и т.д.) сейчас решается средствами самого языка, так что дополнить type_traits и норм.
Так же, например, жду стандартной реализации основных примитивов для корутин, их поддержку (а для программиста это, по сути, ключевые слова co_await, co_yield, co_return) подвезли, но хотелось бы стандартных типов генераторов, заданий и т.п.

КРАМ

[uquote="Eddy_Em",url="/forum/viewtopic.php?p=4351861#p4351861"]КРАМ, не у всех I2Cшных датчиков есть reset. Но многие из них любят убивать линию по всяким пустякам.[/uquote]
Есть две разные истории.
Первая состоит в том, что слейв линию не вешает, а просто уходит в неопределенное для мастера состояние и до него невозможно достучаться. И другая история - это стрейчинг. То есть слейв уходит в ожидание готовности и удерживает линию. Тогда нужно разбираться с причинами такого зависания слейва.
При наличии в коде мастера ожидания ответа из неопределенного состояния (первый случай), линия не висит, но обмен по ней зависает по вине кода мастера. И тогда сброс слейва решает проблему.

VladislavS

[uquote="azhel12",url="/forum/viewtopic.php?p=4351871#p4351871"]вообще лично мне в целом текущий подход нравится - в сам язык (компилятор) добавлять поменьше, а остальное реализовывать на уровне стандартной библиотеки.[/uquote]Нет. Чтобы работать со списками типов нужно, во-первых, много метакода со стороны программиста, а во-вторых, очень много работы компилятора по порождению этих типов. Чтобы какой-то упорядоченный или отфильтрованный список типов создать надо породить на порядок больше типов. А потом у нас компиляторы тормозят. Если будет механизм работы со списками типов в стандарте, то компилятору будет сильно проще это делать не порождая огромного количества вспомогательных типов по сложным метапрограммам. Да что далеко ходить, сравните код Александреску и современный. Уже на порядок проще, а можно ещё лучше.

azhel12

[uquote="VladislavS",url="/forum/viewtopic.php?p=4351915#p4351915"]нужно, во-первых, много метакода со стороны программиста, а во-вторых, очень много работы компилятора по порождению этих типов.[/uquote]Но ведь работает, а если этот же метакод поместить в стандартную библиотеку, то какая разница?

По поводу компилятора соглашусь, однако тоже вопрос: можно ли не изменяя интерфейс (стандарт) ускорить эти моменты? Кстати, у меня так более насущная проблема с компиляцией шаблонов - нечитаемые сообщения об ошибках, была даже идея предложить в стандарт подставлять вместо развернутого шаблона его Alias, если таковой в программе объявлен.

Reflector

[uquote="azhel12",url="/forum/viewtopic.php?p=4351871#p4351871"]ИМХО это перебор (я про types...[-1]), вообще лично мне в целом текущий подход нравится - в сам язык (компилятор) добавлять поменьше, а остальное реализовывать на уровне стандартной библиотеки.[/uquote]
Для примера, допустим нужно для списка типов реализовать get(), это тянет за собой довольно много не самого понятного кода:

Спойлер

Код: Выделить всё

template<typename... Ts>
class TypeList
{
	template<typename Is>
	struct GetImpl;

	template<auto... Is>
	struct GetImpl<std::index_sequence<Is...>>
	{
		template<typename T>
		static consteval auto dummy(decltype(Is, (void*)nullptr)..., T*, ...) { return TypeBox<T>{}; }
	};
	
public:
	template<std::size_t I>
	static consteval auto get() { return GetImpl<std::make_index_sequence<I>>::dummy((Ts*)nullptr...); }
}

А если в стандарт добавят доступ по индексу, то получим просто:

Код: Выделить всё

template<typename... Ts>
class TypeList
{
public:
	template<std::size_t I>
	static consteval auto get() { return TypeBox<Ts...[I]>{}; }
}

Более того make_index_sequence<> очень медленная штука потому разные компиляторы все равно подменяют стандартные функции своими, например, в gcc для этого есть __integer_pack(N), а в clang - __make_integer_seq<>. Собственно разработчики компиляторов часто и пытаются протолкнуть в стандарт полезные для них фичи, все остальные как минимум получат более быструю компиляцию.

VladislavS

[uquote="azhel12",url="/forum/viewtopic.php?p=4351924#p4351924"]Но ведь работает, а если этот же метакод поместить в стандартную библиотеку, то какая разница?[/uquote]Разница в том, что многие возможности стандартной библиотеки перекочёвывают внутрь компилятора и реализуются проще. У компилятора все типы есть и ему проще их отдать пользователю с помощью специального механизма, чем выполнять метапрограмму.

Eddy_Em

Послушал я тут советчиков и добавил -flto в опции компилятора. Но не проверил сразу. Бдыщ: не работает прошивка. Убираю -flto — работает!
Вот такие пироги. Странно, что у других все ОК с этой опцией.

VladislavS

Поздравляю, значит есть ошибки в программе.

Eddy_Em

Были бы ошибки, оно бы не работало и без -flto.
А еще я вспомнил, почему --specs=nano.specs как-то комментировал: с этим делом у меня тоже прошивка не работала. А без него — да.
Еще натыкался неоднократно на странность: с одними и теми же (за исключением архитектуры, понятное дело) флагами на F072 memcpy работал, а на F103 приводил к хардфолту. Вот, проверил на G070 - тоже memcpy к хардфолту приводит, пришлось свой использовать.
Вообще, самый идеал — совершенно не пользоваться libc, тогда все будет щикарно. Я вот с F303 возился: флоаты заработали, арифметические операции с ними — тоже, а вот sqrt — хрена с два! Возможно, какой-то флаг надо особый указать, чтобы точно с lm оно слинковалось. Благо, у меня нет пока задач, где требуется математика со всякими корнями/логарифмами/экспонентами. Но, если что, тоже могу таблично реализовать, как тригонометрию.

Мурик

Eddy_Em писал(а):Были бы ошибки, оно бы не работало и без -flto.

Наверняка volatile где-то забыли.
Нормально написанная программа работает с LTO.