Литература для stm32

[VladislavS]

Единственное, шифровки тпа "PB13, 1, 1, 1, 5, 3, 3, " на меня навевают тоску. С этим надо что-то делать.

[Reflector]

VladislavS писал(а):

Единственное, шифровки тпа "PB13, 1, 1, 1, 5, 3, 3, " на меня навевают тоску. С этим надо что-то делать.

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

[COKPOWEHEU]

Вы смешиваете в одном предложении две разные задачи:

Зачем вы разделяете одну задачу на две? Если у меня к выводу подключен светодиод, мне его надо сначала сконфигурировать, а потом переключать.

Всё верно. Светодиод, кнопка и даже реле типовые объекты наших схем и заслуживают написания для них, пусть и простенького, но отдельного от GPIO кода.

Отдельно для светодиода, отдельно для реле, отдельно для кнопки, отдельно для каждой периферии?

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

Тогда к чему был пример с контроллером на ПЛИС?

Тут стоило бы поставить ВАШЕ ЖИРНОЕ IMHO.

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

Вот даже не надо далеко ходить, пару сообщений выше, сравните

Сравниваем: очевидный типизированный код против кода с необходимостью лезть в реализацию. Из вашего кода не очевидно за что отвечает поле buf, надо смотреть в определении типа.

И если присмотреться то видно, что почти в каждый класс пробрасываются пины

Если это работает так, как я думаю, то это отличная фича языка.

А на С что будет? Сколько страниц кода придется написать чтобы заменить хотя бы две последние строки

Порядочно. Но вешать дисплей на несколько портов это обычно плохая идея.

[VladislavS]

COKPOWEHEU писал(а):

Зачем вы разделяете одну задачу на две? Если у меня к выводу подключен светодиод, мне его надо сначала сконфигурировать, а потом переключать.

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

COKPOWEHEU писал(а):

Отдельно для светодиода, отдельно для реле, отдельно для кнопки, отдельно для каждой периферии?

Совершенно верно! Причём вы пишете код, чтобы ему можно было просто в заголовочном файле типа main.hpp указать параметром шаблона куда он подключен и всё. Да какая разница диоду на какой контроллер он подключен? Ему надо знать как поставить "0" и "1" на той ноге что ему указали и задать соответствие между "0/1" и "вкл/выкл".

COKPOWEHEU писал(а):

Тогда к чему был пример с контроллером на ПЛИС?

К тому что существуют порты у которых нет Push-Pull режима, что вас удивило, на что я привёл пример. Вы таки следите за диалогом, а то складывается впечатление, что со стенкой разговариваешь.

COKPOWEHEU писал(а):

"исходного кода меньше" - нет, мы видели, что больше

Где вы видели? Я показывал свой код? По фрагментам судите?

COKPOWEHEU писал(а):

"результирующий код лучше по быстродействию" - нет, результирующий код практически одинаковый.

"Мочало, мочало, начинай сначала". Много раз показал, что быстрее. От нескольких тактов на простой операции до десятков раз на сложных.

COKPOWEHEU писал(а):

Если не упарываться с ручными оптимизациями, конечно.

В том то и дело, что вы не упарываетесь и получаете менее оптимальный код. И я не упарываюсь тоже, но за меня это делает компилятор, неустанно, в каждом проекте, сурово и беспощадно.

COKPOWEHEU писал(а):

"дополнительные проверки позволяют избегать многих ошибок" - которых никто никогда не допускает.

Это на какой такой планете?

COKPOWEHEU писал(а):

"можно сделать много такого, чего макросам даже и не снилось" - теоретически да, но практического примера мы пока не видели.

Может стоит глаза разуть?

COKPOWEHEU писал(а):

Сравниваем: очевидный типизированный код против кода с необходимостью лезть в реализацию.

Чёрное это белое, война это мир. Выведи не пойми что не пойми откуда в вашем случае. Против чёткого "выведи все элементы буфера", при этом тип элемента будет автоматически учтён и правильно выведен, именно так как в буфере и хранится. Как можно так шиворот на выворот реальность переворачивать?

COKPOWEHEU писал(а):

Из вашего кода не очевидно за что отвечает поле buf, надо смотреть в определении типа.

А из вашего аж прям так очевидно...

COKPOWEHEU писал(а):

Если это работает так, как я думаю, то это отличная фича языка.

Именно так и работает. А ещё, это не влечёт за собой вызова кучи функций. После того как всё "пробросится" происходит генерирование кода с полной оптимизацией всего и вся. Будет просто быстрый оптимальный код. Бывает, что он больше по размеру из-за сильного инлайна, но зато быстрее работает.

COKPOWEHEU писал(а):

Но вешать дисплей на несколько портов это обычно плохая идея.

Если дисплей подразумевает разные интерфейсы, если в контроллере шину можно реализовать разными способами (ногодрыг или fmc), то разделить интерфейсы рисования и подключения вполне логично. Менять интерфейс подключения несколькими параметрами в шаблоне при определении в заголовочном файле это быстро, удобно, мало кода.

[НовыйДень]

VladislavS писал(а):

Единственное, шифровки тпа "PB13, 1, 1, 1, 5, 3, 3, " на меня навевают тоску. С этим надо что-то делать.

Графическая утилита с выбором ног и режимов и генерация готового кода чисто конкретно под этот выбор. Я серьезно, не шучу. В CubeMX красивая и удобная графическая часть. Почему бы не запилить подобную графическую утилиту? Вот это будет класс по всем направлениям. А то портянки текста, куча потраченного впустую времени. Единственный плюс - изучил кодописательство на продвинутом С++. А в остальном - ааа, фихня, оверинжениринг и трата времени. По-другому делать нада! Нужно оформлять в утилиту удобного графического представления, как это сделано в CuveMX. И что бы вы там не говорили, сколько бы портянок не писали, но это всего лишь полумера, на узкого любителя портянок и ради самолюбования.

[a797945]

" ! Даешь парсер портянок hal'a !"
и пусть выплевывает регистры со значениями

[НовыйДень]

HAL - это Hardware Application Layer - очень правильная идеология абстракции уровней программного кода. А самый правильный инструмент конфигурирования - диалоговый, с кодогенерацией компактного кода без излишней лапши.

[Dimon456]

Графическая утилита ... Почему бы не запилить подобную графическую утилиту?

VladislavS, помнится, у меня губа отвисла, а у этого еще и слюна потекла.
У avr нет отдельной графической утилиты, пользуемся вспомогательными средствами, такими как, например cvavr.
НовыйДень, вот возьми да сделай доброе дело, изобрети графическую утилиту, глядишь другие люди большое спасибо тебе скажут.

[AVI-crak]

HAL - это Hardware Application Layer - очень правильная идеология абстракции уровней программного кода.

Нет, HAL - это дополнительный лишний слой абстракции над cmsis. Он не может 100% верно задать последовательность действий, не может простым способом показать ключевые точки управления, не имеет нативного деления на слои. Всё что он может - предоставить полный контроль над всей имеющейся информацией.
А мне не надо весь контроль, и не нужна вся информация. Этого всего банально много, слишком много.
Мне нужно готовое решение, с ограниченной зоной видимости, и явным указанием управляющих функций. Но в готовом виде ничего похожего нет. По этому приходится постоянно возить за собой свою маленькую тележку, с прицепом из 13-ти вагончиков кода.

[tonyk]

НовыйДень писал(а):

HAL - это Hardware Application Layer - очень правильная идеология абстракции уровней программного кода. А самый правильный инструмент конфигурирования - диалоговый, с кодогенерацией компактного кода без излишней лапши.

Золотые слова! Только делать это надо на С++ с шаблонами, хорошие примеры этого были у VladislavS, или ПЛК. Других вариантов нет. Только в этих случаях можно получить максимально эффективный по размеру и/или скорости код.

Ещё раз перечитайте историю создания С. По-сути, это высокоуровневый ассемблер, посему все оптимизации только за счёт опыта и старания того, кто программирует. С++ со всей его заумью последних версий как раз и создан для того, чтобы программист мог описать, как делать всю низкоуровневую оптимизацию, чтобы компилятор построил оптимальный код.

Добавлено after 5 minutes 44 seconds:
COKPOWEHEU, знаешь, чё самое прикольное? Это когда берёшь портянку от VladislavS, целый вечер читаешь Страуструпа, чтобы понять написанное в этой портянке, а потом в дизассемблере видишь, что эта портянка превратилась в полдюжины команд проца.

[НовыйДень]

tonyk, я говорю о том, что самый правильный вариант - это скрытие портянок (на любом языке, хоть на пайтоне) и выдачу сгенерированного компактного куска кода.
VladislavS наваял конечно много монструозных портянок с глубоким погружением и оверинженирингом, чем очень и гордится. Но времена не стоят на месте, сейчас это уже не актуально, он опоздал. Для теоретиков программирования - эта монструозность сойдет, чисто для погружения в возможности С++. Но для практиков программирования сия тряхомудия является просто атавизмом и зря потерянным временем. Сейчас не 2012 год, а 2022. И ныне в тренде наглядные, визуальные методы, а не портянки текста с проприетарным наполнением. Отгадайте секрет бешеной популярности Cube MX. Секрет в том, что этот инструмент попал в нужное русло и соответствует духу времени, посему не требует той навязчивости и убеждений, как у портянок VladislavS. Вот и всё. Я ж говорю - вот эти его портянки закрыть бы в диалоговую графическую среду - и был бы совсем другой коленкор.

[VladislavS]

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

[Dimon456]

Слюна до пола.

Аналогичный пример его портянок где-то на хабре лежит, наверное чуть-ли не ко всем stm.

[НовыйДень]

VladislavS, ну так ты ж усердно продвигаешь тут свою кодописанину, а потом вдруг обижаешься, что её обсуждают Критику то надо уметь принимать, а не только расхваливать ЧСВ.
И правильно - лучше никому не показыавай свою писянину, а то засмеют за оверинжениринг, когда узнают, что тонны портянок всего лишь конфигят порты и кой-чо помелочи еще. Это на несведущих только может произвести вау-эффект. А практикующие программисты скажут: "И это всё, что могут эти портянки? А знаешь, завтра к нам приезжают (например) PIC32 с совершенно другой структурой. У тебя есть срок до обеда, чтобы переписать свою тряхомудию на новые МК".
На практике то оно выглядит всё совершенно иначе, чем в теории. На практике - диалоговый конфигуратор вместо портянок оверинжениринга. Такой вот раскладец. И можно чо угодно и как угодно расхваливать, но портянки - для собственного ЧСВ ("а вот как я умею!), а для практической работы - закрытый конфигуратор, герерирующий готовый компактный код по месту.

[VladislavS]

И слова то они умные знают, и язык у них острый, и конфигуратор с кодогенератором эффективного кода у каждого в рукаве. Только что-то через пост один куб на слуху. А весь скулёжь выглядит как-то так

Спойлер

[Eddy_Em]

Ох уж эти вантузоиды! Вот только дай им мышей потыкать!
Прискорбно, что дегенератов в мире так много…

А самое ужасное — то, что большинство этих дегенератов работают. И на работе занимаются этим тряхомудием. А потом орут: почему это в России все так через жопу? А в зеркало смотреться не пробовали??? Если б не было 99% населения дебилов, то и страна в говне бы не сидела!

[Reflector]

НовыйДень писал(а):

На практике - диалоговый конфигуратор вместо портянок оверинжениринга. Такой вот раскладец. И можно чо угодно и как угодно расхваливать, но портянки - для собственного ЧСВ ("а вот как я умею!), а для практической работы - закрытый конфигуратор, герерирующий готовый компактный код по месту.

Берем еще раз несколько строк инициализации дисплея:

Код:

using lcdDataPins = PinList<PE10, PE9, PE8, PE7, PD1, PD0, PD15, PD14>;
Lcd<RM68140, LcdOrient::Landscape, PB13, lcdDataPins, PD7, PE6, PD5, PD4, 0, 8, 0> lcd;
lcd.init();

Здесь можно указать любые пины и все максимально оптимизируется т.к. среди прочего этот код юзает либу портов предоставляющую соответствующий функционал. Если делать конфигуратор он ведь может сгенерить такой-же компактный код? Конечно может, более того это еще и упростит написание самого конфигуратора. С другой стороны он может нагенерить плохо читаемые портянки настолько же эффективного кода под конкретные пины или нечто менее громоздкое, но и настолько же менее эффективное. Точно лучше получится? Ты за портянки или против? Хороший конфигуратор должен опираться на качественные библиотеки которые полезны и сами по себе, они могут быть достаточно сложными и изощренными, но зато в итоге не получится еще один Куб. Нужен нам второй Куб?

[COKPOWEHEU]

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

Ну так любую задачу можно разбить на подзадачи.

Совершенно верно! Причём вы пишете код, чтобы ему можно было просто в заголовочном файле типа main.hpp указать параметром шаблона куда он подключен и всё.

И сколько вариантов периферии вы реализовали? Отдельно светодиод. Что еще?

К тому что существуют порты у которых нет Push-Pull режима, что вас удивило, на что я привёл пример.

Нет, меня удивило зачем вы такой приме рпривели в обсуждении настройки на push-pull. У вас часто возникает задача генерировать такие контроллеры и настраивать именно урезанные пины?

Где вы видели? Я показывал свой код? По фрагментам судите?

Да, по фрагментам. Даже ваши фрагменты занимают раза в три больше места, чем аналогичный макрос.

"Мочало, мочало, начинай сначала". Много раз показал, что быстрее.

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

В том то и дело, что вы не упарываетесь и получаете менее оптимальный код. И я не упарываюсь тоже, но за меня это делает компилятор, неустанно, в каждом проекте, сурово и беспощадно.

Зачем вы врете? Компилятор не имеет права разивать 32-битный регистр на байты, это вы делали вручную.

Это на какой такой планете?

На Земле. Это третья планета солнечной системы.

Может стоит глаза разуть?

И что, общие соображения внезапно станут фактами?

Чёрное это белое, война это мир. Выведи не пойми что не пойми откуда в вашем случае. Против чёткого "выведи все элементы буфера", при этом тип элемента будет автоматически учтён и правильно выведен, именно так как в буфере и хранится. Как можно так шиворот на выворот реальность переворачивать?

Не знаю зачем вы пытаетесь вывернуть реальность.
"выведи все элементы буфера независимо от типа" - но нужно не элементы буфера, а байты. Тот же USB не элементами буфера неизвестных типов оперирует, а байтами.

А из вашего аж прям так очевидно...

Конечно, он же не завязан на внутреннее устройство переменной. Хоть int туда подставить, хоть строку - все будет работать очевидно и предсказуемо.

Если дисплей подразумевает разные интерфейсы, если в контроллере шину можно реализовать разными способами (ногодрыг или fmc), то разделить интерфейсы рисования и подключения вполне логично. Менять интерфейс подключения несколькими параметрами в шаблоне при определении в заголовочном файле это быстро, удобно, мало кода.

Хорошо, но какое это имеет отношение к разбиению линии данных по портам?
Изменить способ обмена через define ничуть не сложнее.

Графическая утилита с выбором ног и режимов и генерация готового кода чисто конкретно под этот выбор...

...идиотов.
Код должен быть доступен для чтения и редактирования без специнструментов. Тот ужас, что генерирует Куб или cvavr, для чтения непригоден. Спецутилиты устаревают и становятся просто недоступны.
Представьте, что такой же кубом ушибленный написал свой кодогенератор на каком-нибудь quickBasic, который подставляет прямо номера регистров и значения в десятичном виде. Допустим даже, что он добросовестный и вместе с каждым проектом прикладывает исходники своего кодогенератора. Вот только так получилось, что он работает исключительно под MSDOS какой-то замшелой версии и с конкретным аппаратным багом.
А вас заинтересовал его проект и вы хотите им воспользоваться. Как вы будете это делать?
А теперь представьте, что кодогенератор писали не менее добросовестные программисты на каком-то предприятии десяток лет назад под какую-нибудь win98. Вот только исходники за давностью лет потерялись. Так что эта штука работает только под win98, генерирует код в стиле, принятом именно у них и заточен под те три контроллера, с которыми они работаели.
Или исходники не то что утеряны со временем, а изначально писались кем-то недобросовестным, кто исходников не просто не публиковал, но и старательно обфусцировал: вот вам образ для Mac, вот скомпилированные объектники библиотек - пользуйтесь.
Или, как сейчас модно, онлайн-конфигурялка. А сайт внезапно забанили.
Не говоря о том, что бывает, когда подобный "код" выкладывают на форумах. У окружающих ведь вашего конфигуратора, естественно, нет - есть только портянка с кучей невразумительных функций и магических чиселок без форматирования и комментариев.

[AVI-crak]

Здесь можно указать любые пины и все максимально оптимизируется

Промышленное изделие с чипом stm32f, и очень красивой разводкой почти в одном слое - это плод любви того самого дизайнера, который так видит.
Красиво, это когда все ноги с одной линии контактов - без переходов уходят на чип с параллельным портом, одной красивой полосой проводников.
Да, красиво, да работает - но в 100 раз медленнее чем могло-бы работать.
А это означает что можно было взять чип в 100 раз слабее и дешевле. Мысль понятна?

[НовыйДень]

Если делать конфигуратор он ведь может сгенерить такой-же компактный код? Конечно может, более того это еще и упростит написание самого конфигуратора. С другой стороны он может нагенерить плохо читаемые портянки настолько же эффективного кода под конкретные пины или нечто менее громоздкое, но и настолько же менее эффективное. Точно лучше получится? Ты за портянки или против? Хороший конфигуратор должен опираться на качественные библиотеки

Ну так зачем делать конфигуратор, который будет генерить плохой код? Хороший конфигуратор выдаст код длиной в несколько строчек, в которых будет чисто конкретно только то, что нужно.
Некоторые из вас никак не могут понять, что все эти длинные портянки, которые тут показывал VladislavS, прячутся в недра конфигуратора (они даже могут быть написаны на любом другом языке, хоть на Питоне), а на выходе в файле исходника получается короткая выжимка, всё чисто по месту. И верх красоты - конфиг нужных пинов в одном месте за раз.
Вот это - действительно дело. А не то, что вы там насочиняли портянок и гордитесь тем, кто больше лишнего текста напишет. Упражняться в кодописательстве - прекрасно. Но для практикующего программиста этот случай неинтересен. Вау-эффект можно произвести только на несведующего программиста. А любой профессионал скажет вам: "И это всё, чего ты сделал за год? Тьху ты, блин. Ты нам не подходишь."

Ну и для несведущих погромистов еще раз напоминаю: HAL - Hardware Abstraction Level. А Cube - это приложение-конфигуратор от STMicroelectronics. Кому то оно нравится, кому-то нет. Но HAL - это Hardware Abstraction Level, а не название продукта. И не путайте понятие и название.