[yanvasilij 0]

Для этого же проца не нашел в свое время SPL. Пришлось сделать HAL. Немного не привычно, но не страшно, разобраться можно.

[Eddy_Em 1]

не нашел в свое время SPL. Пришлось сделать HAL.

Ничего себе, это ж просто деление на нуль!

Ладно еще, когда народ по своей абдуринской привычке эти монструозные библиотеки на F4 или F7 пихает, но на F0 это просто жесть!

Неужто сложно прочесть тоненький RM?

[yanvasilij 0]

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

Смысл такой: что spl, что hal, что opencm3 дают очевидные, на мой взгляд, преимущества:

1) не нужно тратить время на написание драйверов с нуля, при том что когда пишешь драйвера с нуля точно также допускаешь ошибки (выше по теме Вы можете это наблюдать). От чтения RM это конечно не освобождает, без этого никак. Там есть ошибки - не страшно, они отлавливаются на раз-два, было бы терпение и потом многократно используются.

2) hal, opencm3, и даже spl в отличии от самописных библиотек поддерживаются разработчиками и сообществом. Они развиваются и их функционал расширяется, ошибки внутри устраняются. Самописную же либу, поддерживает только один разработчик.

3) Тот же hal тянет за собой массу дополнительных библиотек (стек tcp, файловую систему, стек usb и прочее). Вы скажете, что это можно поднять самому скачав отдельно? Но зачем делать работу второй раз и тратить на нее время? Не проще ли разобраться в том, что уже сделано?

4) Переносимость между сериями и проектами. Код написанный другим разработчиками под hal, spl, opencm3, легко перенести к себе другому разработчику, который тоже использует hal, spl, opencm3. Это какая-никакая унификация. А если каждый будет колхозить свои библиотеки, тот как обмениваться наработками? Можно но уже сложнее, ибо низкоуровневые вещи нужно переписывать.

 

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

Покажите мне сравнительные тесты, в которых наглядно показывается что по вине hal программа начинает работать в разы медленнее. В моей практике такого не было.

Большее потребление памяти? Сколько раз в жизни у вас было такое, что на cortex процах у вас кончалась память? Если такое и было, то держу пари это точно происходило не по вине hal.

Код громоздкий и непонятный? Это уже чистой воды субъективизм, найдется приличное количество народу, кто не согласится с этим. В добавок ко всему hal достаточно гибкий совсем не обязательно использовать все его конструкции.

 

Ну вот вообщем такое мое мнение. Извините за оффтоп.

[juvf 10]

Смысл такой: что spl, что hal, что opencm3 дают очевидные, на мой взгляд, преимущества:

+1. ППКС

 

 

но на F0 это просто жесть!

А мне бы SPL для L0 :rolleyes:

 

[Eddy_Em 1]

Когда я заводил 1-wire через таймер с ПДП, был первый раз, когда я столкнулся с невозможностью реализации задуманного по вине библиотеки. Opencm3 оказалась слишком медленной.

Во всех перечисленных библиотеках очень жирный код. Поражающая избыточность приводит к 1) тормозам, 2) увеличению объема прошивки. Оба этих момента в определенный момент могут подставить подлянку.

 

На мой взгляд единственным правильным вариантом будет нарабатывать сниппеты. А "обмениваться" быдлокодом смысла не вижу. Самый страшный пример — абдурина. Я тут намедни писал обработчик, работающий с термодатчиком TSYS01. Скачал код для абдурины — думал, шустрей будет. А там такое... Какой-то идиот мало того, что флоаты воткнул, так еще и температуру вычислял по формуле из даташита!!!

Я от такого идиотизма вообще в шоке.

 

Под STM32 тоже полно кода в интернетах можно найти. Мне к девборде заботливые китайцы диск приложили с уймой проектов под калокубы. Я даже пытался было для работы с экранчиком взять готовое, но почитав этот жесточайший быдлокод понял, что так делать ни в коем случае нельзя!

Вот каким надо быть чудаком на букву "М", чтобы использовать ногодрыг на проце, имеющем нужную периферию и DMA?

 

И да, т.к. сами авторы опенцм3 говорят, что библиотека еще в стадии тестирования, лучше ею не пользоваться. После того, как они поменяли API, я решил от этой дряни отказаться. Пока ваяю под STM32F0, и очень даже хорошо все идет. Надо будет только USB откуда-нибудь выдрать (из той же opencm3, например), т.к. хочу посредника между USB и CAN на STM32F042 замутить. Да и просто на F103 я привык с CDC работать вместо подключения лишнего переходника на USART.

Изменено 11 марта, 2017 пользователем Эдди

[Baser 5]

... Пока ваяю под STM32F0, и очень даже хорошо все идет. Надо будет только USB откуда-нибудь выдрать (из той же opencm3, например), т.к. хочу посредника между USB и CAN на STM32F042 замутить. ...

Я когда перетаскивал проект с Меги128 на STM32F072 и нужно было в духе времени по-быстрому USB подцепить вдогонку к RS-232.

Так сгенерировал проект на HALе, и первое время, когда с ним разбирался, тоже диву давался тому, как там все понаписано.

Но идеология понятна: разработчики хотели добиться переносимости между ВСЕМИ stm32. Поэтому и эта жуткая многослойность различных макросов друг на друге, когда более сложные низкоуровневые постепенно, в несколько этапов, заменяются на применимые к конкретному процессору. И разделение процедур на несколько уровней для разграничения области видимости переменных и функций - тоже прозрачности не прибавляет. Разбираться в этом - пипец полный, но ведь работает :)

 

Но глядя на то, сколько у меня суммарно ушло времени на то, чтобы с нуля начал работать проект с USB и прочей периферией, у меня никакого желания нет погружаться сильно в глубь и переписывать библиотеки. Тем более, что периферия у STM32 не такая и простая, как у предыдущих простеньких ПИКов, АВРок и т.д. Частенько разбираешься с HAL (я обычно верхний уровень, а часто и пониже, правлю, выкидывая уж слишком сложные навороты) и видишь манипуляции с флагами периферии, про которые сразу догадаться, что так нужно делать, при чтении документации невозможно.

 

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

Как то так...

[jcxz 184]

Тем более, что периферия у STM32 не такая и простая, как у предыдущих простеньких ПИКов, АВРок и т.д.

Из всех прочих ARM, с которыми я имел дело, у STM32 самая простая периферия.

А имел дело я и с NXP (LPC17xx и LPC43xx) и TI (Tiva, Concerto, OMAP) и Infineon.

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

Осваивать периферию STM32 не в пример легче, хотя бы потому что приходится читать описания на гораздо меньшее число регистров периферии чем в других МК.

Сужу по собственному опыту.

Например: в том же USART у STM32F4x всего 7 регистров, в то время как у Infineon например - около полусотни в его USIC. И это не считая связанных регистров.

[Eddy_Em 1]

Вот если бы STMщики вместо идиотизма с SPL/калокубом сразу написали побольше сниппетов под все серии своих МК, было бы намного лучше!

Ладно, под STM8 не надо — там даташит тоненький и регистров немного, но вот некоторые вещи у STM32 требуют реально много времени. Скажем, с тактированием I2C я часа на три завис, пока разобрался, что к чему. Непонятно, зачем вообще на простецкий и2це столько регистров. Ведь 99.9% устройств никакого "тюнинга" не требуют. Можно было по тактированию один-единственный регистр с предделителем тактовой частоты завести.

[jcxz 184]

Непонятно, зачем вообще на простецкий и2це столько регистров.

Жалких 10 регистров - это много????? :laughing:

В LPC17 их 16, в Tiva - 27, в Infineon - полсотни. STM32 - самый простой из всех.

Если самый простейший МК Вам сложен, то что будете делать на более серьёзном? :rolleyes:

[Alechek 0]

Но идеология понятна: разработчики хотели добиться переносимости между ВСЕМИ stm32.

Вот только переносимости ЧЕГО - они, видать, так и не придумали....

"HelloWorld" переносить? Потому как при переносе чего существенного все равно возникают проблемы: то тактирование не то, то DMA не совместимы, и вообще, оказывается, одинаковая периферия на самом деле то разная, возможности не те...

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

 

[juvf 10]

наброс говна на вентилятор продолжаем разговор.... ну не нравиться хал где-то в узких местах.... хотя я бы не сказал, что HAL_GPIO_WritePin() прям уж такая тяжелая... в критичных местах можно использовать от туда же LL_GPIO_WriteOutputPort() из набра Low Layer (LL) drivers. LL - это тоже зло от st?

[Eddy_Em 1]

Для set/clear/toggle функции не нужны, делается это элементарно на макросах!

[Alechek 0]

LL - это тоже зло от st?

Все в жизни относительно. Для ST - SPL\HAL\LL - это очень большое добро. Привязывает пользователей к продукции ST.

Для остальных - кому как. Если нравится кому быть привязаным к одному производителю - пожалуйста.

 

У меня свой лунапарк в части интерфейса к GPIO и основой периферии (SPI, I2C, UART). Поэтому не не составляет труда переносить код между используемыми камнями.

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

 

[jcxz 184]

У меня свой лунапарк в части интерфейса к GPIO и основой периферии (SPI, I2C, UART). Поэтому не не составляет труда переносить код между используемыми камнями.

Во-во - у меня тоже. С (насколько возможно) одинаковым интерфейсом для разных МК

[Velund 0]

Во-во - у меня тоже. С (насколько возможно) одинаковым интерфейсом для разных МК

 

И я тоже со времен ARM7 держу единый "стандарт" вызовов для основой периферии (SPI, USART, I2C и т.д.) на которые "верхом" встают драйвера периферии (EEPROM, ADC/DAC, цифровые потенциометры, синтезаторы частоты и прочие мелочи). Под куб написал "обертку", которая приводит форматы вызовов к привычному мне. "Подрываться" и переписывать свои отлаженные и обкатанные на тысячах серийных изделий наработки под каждый "взбрык" индусов, нанятых писать кубы и подобное им - много чести будет.