Форум РадиоКот

SPL, как я понимаю, не абстрагируется от регистров, а просто реализует структурированный доступ к ним через указатель? или всё-таки "включи таймер на прерывание каждые 20 мс" и все, остальное юзеру не нужно?

[uquote="КРАМ",url="/forum/viewtopic.php?p=4351029#p4351029"]Прикольная "логика"...
Типа если вектора назначены одинаково, значит они назначены костыльно... Поздравляю![/uquote]
Эта ваша логика из той же серии, что назначение одного вектора разной периферии? Кстати, прежде чем выдавать такое, попробуйте все же задуматься, чем могут руководствоваться разработчики, чтобы подобное было оправдано.

КРАМ писал(а):Я жду от вас ПРИЧИНУ, а не оценку.

Точную причину мне знать, разумеется, неоткуда: я в ST не работаю. Но правдоподобную версию я озвучил.
Если она вас не устраивает, можете назвать свою, посмеемся.

КРАМ писал(а):В вопросе поиска обработчиков в проекте я и не претендовал на оптимальность. Но моим способом найти БЕЗУСЛОВНО МОЖНО.

Ну разумеется, можно. А еще можно весь бинарник дизассемблировать.
Вас спросили, как специалиста по ST-HAL, как это сделать максимально "правильно".

ARV писал(а):думаю, все это делали(ют). ну и чем это не HAL?

Именно чтобы избежать путаницы, я и пишу ST-HAL чтобы не путать с HAL (hardware abstraction level) вообще. Любая библиотека в чем-то HAL. Просто реализация от ST (как и у Ардуины) оказалась неудачной. Вероятно, и те и другие попытались сделать ее излишне универсально, в результате чего потеряли и в производительности, и в читаемости, да и той самой универсальности достичь не смогли.

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4351057#p4351057"]Точную причину мне знать, разумеется, неоткуда: я в ST не работаю. Но правдоподобную версию я озвучил.
Если она вас не устраивает, можете назвать свою, посмеемся.[/uquote]
Ну наконец то, я получил ответ. Вы причину НЕ ЗНАЕТЕ. Вы ее предполагаете. Ваше предположение не имеет никакого обоснования, о чем я выше сказал и аргументировал. То есть носит чисто фантазийный характер. То есть извинения не будет.
Это во первых.
Во вторых, я не утверждал, что я знаю, в отличии от вас. Я всего лишь сказал, что вы самоуверенно заявили о костыльности, ни разу не понимая почему вендор выбрал такое решение. И ВСЁ.
Все остальное пустопорожняя беллетристика.

[uquote="ARV",url="/forum/viewtopic.php?p=4351034#p4351034"]например, кто поклянется, что никогда не пытался сделать "универсальную функцию, настраивающую USART"? типа "передаем ей номер USART и скорость, а нужные биты в нужных регистрах она сама ставит"? думаю, все это делали(ют). ну и чем это не HAL? вся разница-то между самодельным велосипедом и заводским...[/uquote]
Так это отнюдь не HAL, а "библиотека-надстройка". Точней, даже сниппет.
Вот, например, — настройка двух/трех USART'ов STM32F0x2. Но привязано к ногам. Как реальный HAL делается, можешь у Владислава посмотреть: у него через крестовые шаблоны реализован достаточно гибкий HAL. И, кстати, в отличие от кала от ST, его код достаточно легко переносим между разными МК. Вот так и нужно было убогим ST'шным индусам делать, а не через задницу, как обычно. Я себе так не делаю, т.к. кроме С никаких ЯП не признаю (ну, разве что приходится иногда на жабоскрипте клепать, но тут никуда не денешься: на С, к сожалению, клиент-сайд в вебе не сделать; хорошо хоть сервер-сайд отлично на С пишется).

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4351057#p4351057"]Вас спросили, как специалиста по ST-HAL, как это сделать максимально "правильно".[/uquote]
Это ложь. Причем двойная.
1. Спросили НЕ МЕНЯ, а неопределенный круг лиц.
2. Ни о каком "максимально правильно" речи не шло, ибо это не имеет никакого значения. Проблема ОДНОРАЗОВАЯ.
Нашел где HAL размещает колбэки и успокоился. Он их там будет размещать и впредь.

КРАМ писал(а):исполнение практически мгновенное.

само исполнение вроде и у меня мгновенное, но вот какие-то промежуточные действия явно тормозят... например, в окошке слева, что появляется в режиме отладки, выводится "дерево отладки" (так и не понял, нахрен оно нужно, ведь в окне кода и так видно, в каком модуле на какой функции остановка), так вот, оно обновляется крайне долго - пустое место заполняется содержимым не мгновенно, а за те самые 10 секунд и более... ноут у меня не самый быстрый и молодой, но все равно подозрительно выглядит это...

VladislavS писал(а):А что, в личке про это не пишут?

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

COKPOWEHEU писал(а):Просто реализация от ST (как и у Ардуины) оказалась неудачной.

про ST-шников не скажу, а в чем неудачность ардуины-то? миллионы поклонников вряд ли согласятся с вами...

имхо, если бы разработчики HAL провели какой-то "опрос мнений", возможно, вышло бы все намного лучше... мне представляется, что надо уйти от концепции низкоуровневой аппаратуры на таких "больших и мощных" МК, как ARM, и сформировать нечто типа системы драйверов, как в ОС (но попроще, со скидкой на отсутствие ОС). например, предоставить на выбор 3 варианта: минимальный размер, оптимум и максимальная скорость - это на этапе конфигурирования проекта. сами драйверы должны иметь наиболее абстрактный интерфейс, например, как уже было предложено, ПОРТ - собирается из пинов, и настраивается целиком одинаково, т.е. или ввод, или вывод и т.п. Система прерываний делается отдельной сущностью, как бы самостоятельной, а не пришитой к конкретной периферии, и в неё можно либо добавить обработчик (в момент добавления нужная периферия нужным образом настраивается), либо отсоединить обработчик (с аналогичными настройками). то есть пользователю интересно прерывание по изменению уровня пина - он пишет что-то типа add_interrupt_handler(PinToggleInterrupt, MyPort, MyPin, MyHandler, HandlerPriority), и всё, может быть уверен, что обработчик будет вызван при изменении уровня пина на указанном порту. и такая функция для всех МК одинакова, даже если нет системы приоритетов, то все равно параметр остается (просто игнорится компилятором). Аналогично для всего прочего. Ведь принципиально необходимости во всяких отдельных GPIO_Init-ах или TIM_Init-ах нужды нет - все настройки автоматически известны в зависимости от того, как пользователь собрался использовать драйвер, и выделять это в отдельную функцию, которую он должен руками вызывать, нет необходимости - вы ведь не работаете с драйвером мышки на компе напрямую, он как бы и без вас есть и настроен, вы хотите получать координаты курсора и получаете их, а откуда они возникают - вам не нужно. так и в МК с "правильным" (по моему мнению) HAL-ом быть должно: хотите сигнал оцифровывать, пишите Add_Adc_Samples_Handler(BufferedSamplesMode, BUF_SZ, SampleSpeed, MyPort, MyPin, MyHandler) - и получаете вызов MyHandler с указателем на буфер, в котором данные - и было там DMA или не было, вам особо и думать не надо (для максимальной производительности, вероятно, будет DMA и статически выделенный буфер, возможно даже два чередующихся, а для минимального размера, возможно, и не будет)

и подобный HAL покроет 90% всех потребностей, а остальные 10% будут радовать Eddy_Em

миллионы поклонников вряд ли согласятся с вами...

Про миллионы мух напомнить?
Миллионы дегенератов берут абдурину, качают "скетчи" из интернета, не задумываясь копипастят чей-то "код", прошивают, подключают убогими разноцветными проводочками "модули", запихивают эту убогость в картонную коробку и получают "wifi-метеостанцию". Нарукожопили? Нарукожопили, ну и флаг им в руки.
Только ведь от такого рукожопия в их скудных двух извилинах ничего нового не появится! Да и "метеостанция" такая долго не проработает.

Никогда! Ну никогда из попытки абстрагироваться от железа ничего хорошего не выходило. Про абдурину и калокуб мы уже говорили, а я напомню про абдурину для богатеньких Буратин — NI'шные железяки с их уродским LabView. Только совершенно ненормальный [censored] мог дойти до идеи "программирования мышью". Да, у них есть и библиотеки, которые можно использовать в проектах на С или С++, вот только а) добрых две трети их железа в линуксе не работает, б) все эти "библиотеки" представляют из себя закрытые блобы (т.е. там жесточайший оверхед, т.к. все используемые внешние библиотеки слинкованы статически, но вот при смене версии glib все это превратится в тыкву), в) за это дерут адовы деньги и г) за свои железяки они тоже дерут адовы деньги! Вот где логика? Ну если ты делаешь железки, ориентированные на дебилов, то хотя бы продавай их недорого, чтобы дебилы могли себе позволить ☺
А пока что я не встречал ни одной серьезной реализации чего-либо на лабвью: только пускание пыли в глазах, как в пресловутом ЮФУ. Сама NI почти бесплатно раздает железяки + бесплатно раздает софт (правда, только под игровые приставки) для университетов, чтобы те проталкивали это говнище. Я видел, как студенты пользуются железками за тысячу баксов каждая, говняя из них такую же "метеостанцию" из говна и палок, как абдуринщик (да еще и "программируя мышью"). В общем, поработав (в основном удаленно) какое-то время в ЮФУ, я понял, что ВУЗ — абсолютное дерьмище, которое готовит никчемных дегенератов, не приспособленных к реальной жизни.

[uquote="ARV",url="/forum/viewtopic.php?p=4351055#p4351055"]SPL, как я понимаю, не абстрагируется от регистров, а просто реализует структурированный доступ к ним через указатель? или всё-таки "включи таймер на прерывание каждые 20 мс" и все, остальное юзеру не нужно?[/uquote]Не совсем так.
SPL содержит конкретный набор востребованных функций настройки периферии. Функции "включи таймер на прерывание каждые 20 мс" не может быть по определению ни в SPL, ни в HAL. поскольку это задача написания драйвера периферии. Сиречь совокупности достаточно разномастного кода, который гарантирует выполнение этой задачи В ЗАДАННЫХ ПРОГРАММИСТОМ УСЛОВИЯХ. Условия могут быть самые разнообразные...
Конкретно для такой задачи можно генерировать прерывания по апдейту таймера, а можно по OutputCompare. Будет различаться фаза события прерывания относительно временной базы таймера.
То есть в SPL настраиваем таймер и отдельно пишем настройку прерываний, а так же содержимое обработчика/колбэк.

КРАМ писал(а):Он их там будет размещать и впредь

как будто это что-то плохое Eddy_Em, вон, в истерику впадает при попытке заюзать float без отдельного вычислительного модуля в ядре, а я должен страдать от коллбека?! я тоже раньше думал (еще с AVR), что вызывать функции из обработчика - не хорошо: куча регистров в стеке сохраняется, дескать, медленно это и плохо. а потом смотрю - миллионы ардуинщиков, а так же тысячи пользователей ОСРВ, вот совсем не парятся по этому поводу! 16 регистров в стеке, 32 такта на вход и 32 такта на выход - это что, убийственно даже для AVR с его жалкими 20 МГц тактовой (максимум)?! и знаете, как-то сразу стало легче жить... для моей практики AVR это было третьим "отпустило": первые два - это printf и float

Eddy_Em писал(а):и "метеостанция" такая долго не проработает

это доказанное утверждение, или просто порция ядовитой слюны?

ARV, это - констатация факта. Как думаешь: долго продержатся на открытом воздухе контакты из говна и палок?
Да, по поводу SPL: сравни адову портянку инициализации чего-либо в SPL с инициализацией на CMSIS. Ну и не забывай про оверхед: ведь SPL построен не на макросах или TRUE_INLINE, а на обычных функциях. И не факт, что gcc их все заинлайнит! А даже если заинлайнит, все равно получается оверхед: сначала ты заполняешь структуру нужными данными, а потом в функции эти данные по регистрам распихиваются (зачастую еще и с вычислениями). В случае же CMSIS у тебя вычисления производятся на стадии компиляции (т.к. все - константы) и значения сразу в регистры попадают. Просто не надо писать что-то вроде a |= flag1; a |= flag2; a |= flag3; a |= flag4;… потому как регистры - они ж волатильные, соотвественно, gcc не объединит все эти инструкции в одну, а реально будет поочередно исполнять.
Я когда-то начинал с SPL, попытался было одну штукенцию несложную сделать на 100-ногом STM32F103, замучился. Перешел на opencm3. Но оно - тоже не подарок, т.к. имеет аналогичные слабости (хотя их и меньше, чем в SPL: opencm3 организован намного грамотней, чем кал или SPL, все-таки, его писали не быдлокодеры, а нормальные разработчики). Попользовавшись немного opencm3, я наткнулся однажды, что все мои предыдущие наработки перестали собираться, т.к. разрабы этой библиотеки внезапно решили сменить API (причем, сменить достаточно радикально), не добавив поддержку deprecated на переходное время. В общем, послал их куда подальше, и стал пользоваться "голым" CMSIS. Но на гитхабе оставил под маркой "deprecated" старые наработки. Если тебе не лень приводить API в соответствие с последней версией opencm3, можешь попробовать.
Ну и заодно можешь сравнить объемы кода для CDC на opencm3 и на CMSIS.
P.S. Прикольно: полез в более-менее свежий код из deprecated, смотрю, а я там практически везде уже инициализацию и т.п. на CMSIS делаю, не используя функции opencm3 (помню, первый раз наткнулся на проблемы, когда делал работу с 1-wire: там нужно было быстро перенастроить таймер, а не получалось, и выходил маленький левый пичок, который ломал всю транзакцию; воткнув вместо вызова библиотечных функций одну строчку смены регистра CMSIS, получил, что надо).

[uquote="ARV",url="/forum/viewtopic.php?p=4351069#p4351069"]то есть пользователю интересно прерывание по изменению уровня пина - он пишет что-то типа add_interrupt_handler(PinToggleInterrupt, MyPort, MyPin, MyHandler, HandlerPriority), и всё, может быть уверен, что обработчик будет вызван при изменении уровня пина на указанном порту. и такая функция для всех МК одинакова, даже если нет системы приоритетов...
и подобный HAL покроет 90% всех потребностей, а остальные 10% будут радовать Eddy_Em [/uquote]
Не покроет. Патамушта исключит 90% возможностей контроллера, сделав его применение целесообразным только для самого начинающего любителя.
Даже HAL в имеющейся инкарнации грешит заметными упрощениями возможностей.

ARV писал(а):а отладка в кубе тормозит у всех, или только у меня? скажем, от запуска отладки до момента "остановки" на входе в main проходит секунд 40, а потом каждый шаг еще секунд 10... это нормально?

Вот видео

[uquote="Eddy_Em",url="/forum/viewtopic.php?p=4351080#p4351080"]и стал пользоваться "голым" CMSIS.[/uquote]
Эдуард, не преувеличивайте. Чистый битовый ногодрыг, например, гораздо читабельней посредством SPL-функции, а по факту там оверхед только за счет call/return.
Первоначальный инит вообще не имеет значения в смысле объема кода/скорости исполнения.
Если же в основном рантайме (суперлуп или прерывания) требуется переинициализировать периферию, то действительно это лучше сделать CMSIS-ом.

КРАМ, "чистый битовый ногодрыг" и у меня реализуется посредством более читаемых макросов ☺
Скажем: Просто вызывается GPIOA->BSRR = …
Жаль только, что нет возможности, как у некоторых других МК, атомарно инвертировать биты порта. Приходится считать IDR или ODR, применить маску, да записать в BSRR или ODR.

[uquote="Eddy_Em",url="/forum/viewtopic.php?p=4351087#p4351087"]Просто вызывается GPIOA->BSRR = …[/uquote]
Это тупо инлайн содержимого той же функции SPL. Читаемость неотличима.

Если чисто с практической точки зрения подходить, то

8 тактов в тяжелых условиях санкций на дороге не валяются! тут и в самом деле впору задуматься...

[uquote="Dimon456",url="/forum/viewtopic.php?p=4351095#p4351095"]Если чисто с практической точки зрения подходить, то[/uquote]
С практической точки зрения более медленный, но "атомарный" HAL_GPIO_TogglePin() будет работать практически всегда, в отличии от...

[uquote="ARV",url="/forum/viewtopic.php?p=4351101#p4351101"]8 тактов в тяжелых условиях[/uquote]Про надежность уже сказали, добавлю только, что ногодрыг для АРМов - это для критически быстрых задач очень плохое решение. В таких задачах нужно изыскивать аппаратную генерацию с помощью OutputCompare. Поэтому 15 тактов Toggle выглядит превосходным, особенно с учетом высокой тактовой частоты ядра. Да и Toggle - это маргинальная функция разве что для отладки. В основном ногодрыг - это Set/Reset.

Reflector, это с чего вдруг HAL_GPIO_TogglePin - "атомарный"? У ней внутри та же неонка портянка с чтением ODR, XOR и записью в ODR.
Кстати, глянул на свой макрос: И вспомнил, что мне как-то Владислав как раз говорил о том, что не гоже делать чтение ODR, XOR, запись в ODR, т.к. мало ли что за это время могло произойти (скажем, в прерывании; хоть у меня и нет моды в прерывании ногами дрыгать, разве что в отладочных целях, а не в "продакшне") → пусть мы потратим лишние операции, зато воздействуем лишь на тот бит, который и нужно изменить.