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

[VladislavS]

[uquote="Eddy_Em",url="/forum/viewtopic.php?p=4234174#p4234174"]Скрипты для такого рукожопия не предназначены.[/uquote]От так вот. Накуси - выкуси

[Eddy_Em]

Да, вот так вот.
Если мне нужно, чтобы скрипт допускал сложные выражения в качестве параметра, то я и соответствующим образом скобочки расставляю.
Но чаще всего этого не нужно, а то и вообще является признаком ошибки/опечатки.

[jcxz]

[uquote="VladislavS",url="/forum/viewtopic.php?p=4234182#p4234182"]От так вот. Накуси - выкуси [/uquote]

[НовыйДень]

Пасаны, вы бы с таким рвением упражнялись бы в работе MIPI DSI, в работе радиомодуля STM32W55 и реализации ZigBee, в согласовании работы двух ядер в H747. А то - тьфу, какая фигня - как порты более запупенсто скорфигить. Ну чесслово, этой теме уже лет 15, а вы всё еще мусолите её. Ну несерьезно тратить столько страниц темы на такую хню, которая лишь дело вкуса.

[Martian]

гомопень, тебя волнует? иди лучше советуй, как микроволнами соседей облучать, это настоящее дело.

[COKPOWEHEU]

Вот-вот. А потом окажется, что для одного пина активный уровень "1", а для другого- "0".

А вот мои макросы с этим справляются прекрасно. Третий параметр обычно именно за это отвечает.

*((volatile uint8_t *)&GPIOA->MODER+3) |= 3<<2;

Имеете в виду что для входов значение OTYPER безразлично? Это добавляется одним условием.
Кстати, вариант с F1 был интереснее в плане выбора в какой из регистров писать.
И что-то мне подсказывает, что вы ошиблись в смещениях. Как может быть +3 если поля двухбитные. Тем более что в примере вы хотели PA13, там должно быть +(13*2) и маска (0b11<<(13*2)). Но это, конечно, ерунда: в реальном проекте все посчитает компилятор, а он не ошибается.

А просто листинг посмотреть не судьба?

Это было скорее для HAL'овцев если не сумеют отодрать код настройки пина от всего остального. Получить дизасм может оказаться проще.

Я не собираюсь очередное подобие кала писать. Мне нужно лишь упростить написание и чтение кода.

А что упростилось-то? Как была ручная возня с регистрами и битами, так и осталась.
Я понимаю отказаться унифицировать специфичное железо, которое в разных МК не совпадает вот совсем. Но GPIO-то везде выполняют одни и те же задачи примерно одним и тем же способом.

Добавлено after 4 minutes 16 seconds:

Пасаны, вы бы с таким рвением упражнялись бы в работе

Мы тут например USB обсуждали. Присоединяйтесь. Как вы считаете, как лучше абстрагировать переключение буферов точек с двойной буферизацией и надо ли это вообще делать? Как лучше обрабатывать события по обмену пакетом - поллингом или колбэками?

[НовыйДень]

USB теперь уже мало кого интересует, а для меня это уже пройденный этап и далее неинтересен. Некоторое время назад был интересен STM32WB55, но известные события огорчили.

[VladislavS]

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4234201#p4234201"]Имеете в виду что для входов значение OTYPER безразлично? Это добавляется одним условием.[/uquote]Конфигурация порта задаётся 7 регистрами (MODER, OSPEED, PUPDR, OTYPER, AFRL, AFRH, ODR(BSRR). В зависимости режима часть регистров (вообще говоря разная) не используется. Это, мягко говоря, далеко не одно условие. Плюс к этому, можно задать опцию "учесть состояние при включении питания", тогда можно не менять те биты, которые уже и так правильно стоят.

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4234201#p4234201"]Кстати, вариант с F1 был интереснее в плане выбора в какой из регистров писать.[/uquote]AFRL и AFRH разве не то же самое?

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4234201#p4234201"]И что-то мне подсказывает, что вы ошиблись в смещениях. Как может быть +3 если поля двухбитные. Тем более что в примере вы хотели PA13, там должно быть +(13*2) и маска (0b11<<(13*2)). Но это, конечно, ерунда: в реальном проекте все посчитает компилятор, а он не ошибается.[/uquote]Я не ошибся. Я же не зря просил кого-нибудь ещё сделать эту, казалось бы обычную, операцию. Чтобы потом сравнить результат. А на этапе компиляции было вычислено, что менять будем данные только в 3-м байте. Соответственно применен байтовый доступ к регистру. Это дало экономию нескольких байт, так как загрузить короткие данные можно в той же инструкции, а 32-битную константу, извините.

Добавлено after 7 minutes 20 seconds:
[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4234201#p4234201"]Мы тут например USB обсуждали.[/uquote]На тактовой процессора 72 МГц при FS подключении на обработку одного пакета больше 3000 тактов. Не успеть принять его за это время надо сильно постараться.

[НовыйДень]

Думаю, пора переходить ко второй избитой проблематике портов - максимальная скорость ногодрыга (по отношению к тактовой частоте) Кто напишет наиболее быстрый способ - получит приз в виде ароматной селедки А кто скажет, будет ли через DMA дрыгать ногами быстрее или нет, тот получит и вторую селедку. А третья селедка разыгрывается за ответ на вопрос - а при исполнении кода из SRAM быстрее или медленне будут дрыгаться ножки?

[COKPOWEHEU]

USB теперь уже мало кого интересует

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

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

Нет смысла. Экономия трех тактов на старте не даст ровно никакого выигрыша.

AFRL и AFRH разве не то же самое?

Да, примерно то же самое.

менять будем данные только в 3-м байте. Соответственно применен байтовый доступ к регистру.

И как у вашего алгоритма с читаемостью?

На тактовой процессора 72 МГц при FS подключении на обработку одного пакета больше 3000 тактов. Не успеть принять его за это время надо сильно постараться.

Чем примечательно "не успеть"? Если не успеть, хост просто пошлет пакет еще раз, и скорость обмена будет ограничиваться не скоростью USB, а скоростью вашего алгоритма.
Но если говорить о точках с одинарной буферизацией, то на время обработки они блокируются, то есть шлют хоста NAK. В HAL именно это ограничивает скорость: длиннющие прерывания, во время которых обмен запрещен.

[НовыйДень]

Я говорю о новых тенденциях и о прогрессе, и не только за себя, а на основании наблюдения за этими тенденциями. USB, особенно в виде FS, основательно потерял популярность. Нынче если и USB, то Type-C с поддержкой Power Delivery.
Ну и STM32WB55 - это вовсе не экзотический микроконтроллер. Та же самая стм-ка с таким же ядром Cortex M0+, только добавлен модуль радио.
Навряд ли, кстати, вы разберетесь с ZigBee, коль уже третью страницу спорите, как пины конфигурировать

[VladislavS]

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4234293#p4234293"]Нет смысла. Экономия трех тактов на старте не даст ровно никакого выигрыша.[/uquote]Если бы три. А то в десятки раз на конфигурации всего чипа. Я ещё не все приёмы рассказал.

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4234293#p4234293"]И как у вашего алгоритма с читаемостью?[/uquote]Замечательно с читаемостью. В том плане, что его вообще не надо читать. IDE сама это делает и даёт варианты.

А сам код вполне читаемый, если владеешь языком. Кусочек из него я приводил в этом сообщении под спойлером. Да и какая разница читаемый он или нет? Ты много раз stdio.h читал? Однако пользуешься и не паришься.

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4234293#p4234293"]Чем примечательно "не успеть"?[/uquote]У меня примечательно "успеть". Это значит войти в прерывание, забрать пакет и поставить статус "готов" раньше, чем NACK пройдёт.

ide_gpio.png

(21.94 КБ) 539 скачиваний

ide_gpio1.png

(7.33 КБ) 530 скачиваний

[COKPOWEHEU]

Если бы три. А то в десятки раз на конфигурации всего чипа.

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

Ты много раз stdio.h читал?

А что, ваш код уже стал поставляться вместе с компилятором?

У меня примечательно "успеть". Это значит войти в прерывание, забрать пакет и поставить статус "готов" раньше, чем NACK пройдёт.

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

[VladislavS]

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4234421#p4234421"]Оптимизировать надо то, что выполняется часто.[/uquote]Ну так оно часто и выполняется. Конфигурирование лишь один из методов класса. Конфиг тоже, кстати, достаточно часто происходит - новые проекты регулярно закладываются. А просто работа с gpio это уж точно не самая редкая операция и оптимизация происходит при каждом доступе. Да и каждое включение это не такое и редкое событие. И вообще, зачем делать плохо, если можно делать хорошо?

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

А вот что писать в ваших "шифрограммах" не способна подсказать ни одна IDE. Приходится постоянно читать код библиотеки или держать в голове шифры от всего зоопарка чипов? Да ну, на, сочувствую.

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4234421#p4234421"]когда можно спокойно обрабатывать один буфер пока железо будет писать во второй.[/uquote]Либо сделать это быстро, а сэкономленное время потратить на обработку данных. 12 МБит это серьёзный поток для обсуждаемых микроконтроллеров. Не хочется чтобы он в /dev/null уходил.

[COKPOWEHEU]

Ну так оно часто и выполняется.

конфигурация при включении питания?!

И вообще, зачем делать плохо, если можно делать хорошо?

Зачем усложнять то, что выполняется единственный раз?

Вы спрашивали про "читаемость". Как способ хранения и распространения кода связан с его читаемостью? Не надо его читать при применении вообще.

Ваш код не входит в стандарт, поэтому будет естественным желание его изучить - какие там баги, насколько оптимально написан и т.п.
Так что и вопрос "зачем читать чужой код" не менее глупый, чем ассоциация своего кода с stdio.
[qoute]А вот что писать в ваших "шифрограммах" не способна подсказать ни одна IDE.[/quote]По stdio она тоже подсказок не выдает.
А если серьезно, то если библиотекой можно пользоваться без костылей вроде IDE, это плюс, а не минус.

риходится постоянно читать код библиотеки или держать в голове шифры от всего зоопарка чипов?

Это у вас методы привязаны к чипу, а у меня - к функции. Если мне надо push-pull, оно и будет GPIO_PP для любого чипа.

Либо сделать это быстро, а сэкономленное время потратить на обработку данных. 12 МБит это серьёзный поток для обсуждаемых микроконтроллеров. Не хочется чтобы он в /dev/null уходил.

Я же приводил вроде ссылку на Хабр, где человек сравнивал HAL с нормальными реализациями. Там же есть осциллограммы как пакеты приходят.

[VladislavS]

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4234515#p4234515"]конфигурация при включении питания?![/uquote]Да. Всякие USB, SPI, I2C далеко не в каждом проекте используются. А GPIO в каждом. При каждом включении питания выполняется конфигурация.

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4234515#p4234515"]Зачем усложнять то, что выполняется единственный раз?[/uquote]GPIO это самый используемый узел в контроллере. Его как раз и надо сделать хорошо. Конфигурация при включении питания это лишь одна из функций, которая примерно 10% от всего кода GPIO.

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4234515#p4234515"]Ваш код не входит в стандарт, поэтому будет естественным желание его изучить - какие там баги, насколько оптимально написан и т.п.[/uquote]Ну, изучите С++ и будете свободно читать, там всё очень красиво и понятно написано. Вас же не смущает необходимость изучить английский, чтобы RM на чип читать?

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4234515#p4234515"]А если серьезно, то если библиотекой можно пользоваться без костылей вроде IDE, это плюс, а не минус.[/uquote]Вот умеете же вы всё с ног на голову вывернуть. С одной библиотекой IDE молчит как рыба об лёд, а с другой даёт красивые подсказки. Какая библиотека удобнее? А без подсказок никто не запрещает писать, только это неудобно в обоих случаях.

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4234515#p4234515"]Это у вас методы привязаны к чипу, а у меня - к функции.[/uquote]Не методы, а типы режимов. Методы у всех чипов одинаковые, а режимы разные.

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4234515#p4234515"]Если мне надо push-pull, оно и будет GPIO_PP для любого чипа.[/uquote]Который из push-pull? Даже если PP нет в чипе? Кто-то запрещает сделать GPIO_PP в моём случае? Вроде в УК такого запрета нет...

[Viktorkin]

Наверно это всего лишь разные вкусы. Одному нравится одно другому нравится другое и каждый считает что его метод самый правильный. Сколько людей столько и мнений.

[VladislavS]

Крове субъективного "нравится" есть вполне объективные критерии: скорость разработки, скорость работы кода, размер кода и т.д.

[COKPOWEHEU]

Да. Всякие USB, SPI, I2C далеко не в каждом проекте используются. А GPIO в каждом. При каждом включении питания выполняется конфигурация.

И вас смущает задержка в пару тактов для операции, которая занимает 10^-11 от всего времени. Вы оптимизируете не там.

Конфигурация при включении питания это лишь одна из функций, которая примерно 10% от всего кода GPIO.

От объема, а не от времени. Ну и 10% это явно завышенное число.

Ну, изучите С++ и будете свободно читать

Изучать новый язык только для того чтобы читать лично ваш код? Как-то недостаточно мотивации. Тем более что с этой задачей мой код справляется ничуть не хуже при лучшей читаемости.
Давайте я вам лучше подкину две смежные задачи, из которых с первой я справился, а со второй - нет.
Как вы знаете, в USB используется ConfigurationDescriptor, разделенный на секции, каждая из которых содержит размер содержимого. Секции могут быть вложенными. Нужен какой-то инструмент чтобы считал этот размер в компил-тайме и подставлял в соответствующее поле дескриптора. Эту задачу я решил.
В описании HID некоторые поля могут быть одно-, двух-, трех- и четырехбайтными. В зависимости от этого будет меняться ведущий байт. Нужен какой-то инструмент, которому передается число и он в зависимости от его размера меняет первый байт и разбивает само число по ячейкам. Например,

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

LOGICAL_MIN(0x01) -> [0x14, 0x01]
LOGICAL_MIN(0x0102) -> [0x15, 0x01, 0x02]
LOGICAL_MIN(0x010203) -> [0x016, 0x01, 0x02, 0x03]
LOGICAL_MIN(0x01020304) -> [0x017, 0x01, 0x02, 0x03, 0x04]

Разумеется, и перед этой штукой, и после нее будут другие подобные, то есть хардкодить номера байтов нельзя.

С одной библиотекой IDE молчит как рыба об лёд, а с другой даёт красивые подсказки. Какая библиотека удобнее?

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

Который из push-pull? Даже если PP нет в чипе?

А какой push-pull нужен чтобы зажечь светодиод или включить реле? Вот тот и включить.
Что за контроллер без push-pull режима?

Кто-то запрещает сделать GPIO_PP в моём случае?

Мне-то откуда знать что в вашем коде? Это ж не stdio чтобы любой встречный знал.

[Viktorkin]

Да вот вы чтото зарубились на тему кто круче запутает код. Оба перемудрили. Хотя вам нужно было создать небольшой кодогенератор в интерфейсе которого вы выбираете пины и их режимы а кодогенератор генерирует уже готовый и короткий код. Захотели поменять пины - перегенерировали участок кода и всё. Именно вот этот подход будет самым правильным в этом случае.