Мысли о STM32 HAL или стоит ли стремиться в метапрограммирование на C++

Навеяно сообщением коллеги evsi
Что же до либ, то есть куда более перспективный путь, хотя он и не лежит в плоскости очередного HAL от конкретного производителя. Я имею в виду вот эту либу: github.com/andysworkshop/stm32plus
Кстати, сам Andy Brown (автор либы) ведет весьма интересный сайт andybrown.me.uk/
в недавнем обсуждении STM32 Peripheral Libs: FWLib -> SPL -> Middleware+HAL+CubeMX -> Middleware+Snippets -> CMSIS-Driver API? Куда это все ведет и есть ли истинный путь?

Шаблонное метапрограммирование.
По мере изучения С++, я вижу, что все пути ведут туда. Но пока я не способен (легко) понимать такой код, а уж тем более написать.
У меня к такой библиотеке вопросы:

1. Полностью ли абстрагирует эта конкретная библиотека железо, во всей его сложности? Вопрос шире. Пусть не эта конкретная, а в принципе, можно ли с помощью шаблонного метапрограммирования написать библиотеку, с помощью которой можно включить железо в любом описанном в datasheet режиме?
Не будем брать GPIO, возьмем АЦП. Какой-нибудь сложный режим совместного использования отдельных модулей АЦП, с пересылкой по DMA, запуском по таймеру. Повторюсь, простая периферия не интересует, интересует сложная в извращенных режимах.
Если кто-то из гуру положительно ответит на этот вопрос, буду расти в ту сторону.

2. Вот пишу я код в таком стиле, ухожу из конторы. Сколько будет стоить специалист, способный поддерживать такой код? Как легко его будет найти?

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

Почему бы не взять для генерации исходников более мощный язык, предназначенный для манипулирования текстом? Perl, Python, Javascript и так далее.
Описать в декларативном стиле (a-la QML) в JSON формате, что нам нужно от периферии. Парсим этот файл, генерируем C++ исходник, в котором классы периферии имеют простое АPI, минимально необходимое в конкретной задаче.

class AdcSigmaDelta
{
public:
    enum Gain
    {
        Gain05,
        Gain1,
        Gain2,
        Gain4,
        Gain8,
        Gain16,
        Gain32,
    };

    AdcSigmaDelta(const std::vector<Pin> & pins);

    bool start();
    int16_t code(size_t idx) const;
    float voltage(size_t idx) const;
    bool setGain(Gain gain);
...
}

Методы класса наш генератор реализует напрямую регистрами максимально эффективно.
Генератор должен не давать использовать одну периферию в разных местах, GPIO, задействованные в АЦП не задействовать для ШИМ.
Отсюда плавно приходит в голову использовать GUI для генерации JSON файла описателя.

Та-дам! Вот и он — STM32CubeMx.

Для меня, пока, круг замкнулся. Тот Cube, который сейчас есть, пускать в свой код нельзя, только для быстрого старта — сгенерил, посмотрел, взял в свой код, навел порядок.

Тот Cube, который я хотел бы видеть:
открытый исходный код — чтобы тысячи эмбеддеров совместно развивали проект (тысячи бесплатных тестировщиков!),
гибкий, настраиваемый — чтобы код генерился в моем стиле, раскиданный по мной описанному заголовочному файлу.
  • -2
  • 27 мая 2016, 21:38
  • tugo

Комментарии (125)

RSS свернуть / развернуть
есть еще mbed.org (только кушает 20-25 кB без ковыряния)
не считая всяких openlibcm и ещё 100500 поделок.
Не понимаю споров про HAL. Не хочешь — не пользуйся.
0
Значит я плохо написал. Спор не про HAL — пользоваться или нет. Уровень абстракции периферии нужен. Вопрос в том, как его создать — универсальный (библиотека, которая может все) или каждый раз читая даташит и реализуя свой простенький API.
Хочется универсального. Но не получается.
mbed видел, пользовался, сейчас в проекте, буду избавляться. GPIO абстрагирует хорошо, спору нет. А вот хотя бы PWM — не может. Как чуть чего то посложнее хочется от ШИМ лезем внутрь и правим.
В mbed мне нравится (меньше всего не нравится, вернее так), что сделана проверка — можно ли назначить на эту ногу такую альтернативную функцию и интерфейсы классов.
0
Хм. А еще никто не начал разработку опенсорсного интерактивного парсера даташитов? Чтобы тадам- и выдал тебе приложение, в котором гуи с интерактивной настройкой всей периферии желаемого мк и кнопкой «сгенерировать код» на любом доступном языке.
0
Можно обобщить информацию из ПДФ

чтобы по крайней мере сделать удобную кросс-ссылочную справку

но тут в голову приходит мысль, что сначала правильнее обобщить имена/фамилии/явки из заголовочных файлов, чтобы не напороться больно на опечатки или ошибки в книжках…
и тут понимаешь, что надо понять и простить 963 процессора…

чтобы потом сделать интерактивный помощник генератор кода на любой вкус… как в Дельфи — хош под Винду, хош под Андроид, хощ под ёпл...(хал/спл/регистр)


но тут нежданно негаданно приходит лето…
-1
А еще никто не начал разработку опенсорсного интерактивного парсера даташитов?

У ARM, специально не для людей, а для роботов программ (IDE, плагинов, визардов), в составе стандарта CMSIS есть подстандарт на файлы SVD — огромные даташиты, описывающие всю периферию чипа, в формате xml.

По сути, хедер-мегапортянка описания периферии из состава фирменной либы CMSIS — это просто текстовая отрыжка для гуманоидов этого xml-даташита, сгенерированная программкой SVDConv.exe и обработанная затем руками несчастных программерных негров — Doxygen, причесывание, комментарии и т.п. тупая работа. Видимо в фирмах на эту черную и тяжелую работу бросают самых молодых или самых тупых/провинившихся — это как на флоте раньше заставляли скрести ножами или осколками стекл палубу и точить напильником якорь, чтобы блестели.
-1
Никто даже не сделал считыватель желаний напрямую из мозга.
Подумал — тадам и устройство работает.
Не надо никаких ГУИ-ШМУИ и кнопок для языков.
0
Andy Brown неплохой блог, но он как бы на продажу нацелен. поэтому и выглид и содержание поддерживает.
0
А вообще, я думаю, что будущее embedded контроллеров за связкой [простое быстрое ядро]+[быстрая плис]+[матрица аналоговой периферии] на кристалле. А периферия программно подгружаемая (покупаемая).
И приложение для генерирования.
Возможностей будет куда больше.
0
Так это уже как 5 лет есть PSoC от Cypress. Но что там у них не заладилось — видимо никому это не надо. Может мне повезло, но собственно железо у меня занимает 5% от кода. Алгоритмы обработки гораздо более сложный вопрос. Тот же ST жмётся дать исходники для osMotion… — уже вторую неделю ковыряю. Да еще лицензии придумали. Наивные.
0
Вся эта суета вызывает легкое уныние после просмотра
что было ещё 30 лет назад
0
Попробую высказать свою точку зрения.

STM32 — это относительно более сложный МК, по сравнению с AVR-ками и MSP430. Это очевидно и не требует доказательств.

Разработчики, не первый год работающие с разными МК, привыкли к простеньким МК, и когда на рынке появились доступные Кортексы, оказалось, что люди не готовы их воспринимать как сложные изделия. Люди по инерции мышления (не задумываясь) пытались воспринимать эти новые МК как такие же простые МК, на подобие ATMEGA и MSP430. Ну, то есть люди ожидали, что они новые МК будут чуточку по-сложнее тех, с чем они имели дело до этого.

На деле, оказалось, что STM32 сложнее не «чуть-чуть», а на порядок. Во всяком случае сложнее значительно. Сложнее, чем ожидалось!

Сама по себе относительная сложность STM32 ничего не значит. В природе бывает ещё более сложные изделия. Другое дело, что STM32 как бы «не оправдал» негласных ожиданий разработчиков.

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

Несбыточность желания создать такую библиотеку заключается в том, что:

БОРОТЬСЯ СО СЛОЖНОСТЬЮ МОЖНО ТОЛЬКО ОТКИДЫВАНИЕМ ФУНКЦИОНАЛЬНОСТИ

Прошу прощения за капс! Прочтите еще раз и вдумайтесь в сказанное, я его не зря выделил!

На Казусе перетирается тема «почему здесь не любят ардуинщиков?». Дак за то их и не любят, что Ардуино упростило жизнь разработчикам (я бы сказал — недо-разработчикам) за счет того, что скрыло от разработчика целый пласт возможностей процессора. Ардуино упростило сложность системы за счет откидывания функциональности.

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

Резюме. Нельзя из изначально сложной системы создать более простую путем перестановки акцентов. На выходе получатся те же яйца! При замене одной сложной сущности на другую, сложность не уменьшается, а увеличивается! Уменьшить сложность можно только за счет отказа от чего-либо. Упростить можно только пожертвовав какими-то не очень нужными вещами (функциональностью). И обязательно нужно что-нибудь принести в жертву. Например — объем кода, быстродействие, ещё что-нибудь.

Чудо не в том, что где-то сущетсвует волшебная палочка. Чудо в том, этой палочкой мы — разработчики — умеем пользоваться. Для других — это просто палка. И как бы мы эту палочку не разрисовывали разными узорами для них (других людей) она так и останется обычной палкой.

Я предпочитаю по старинке юзать CMSIS и управлять периферией с помощью регистров. По крайней мере у меня всегда твёрдая почва под ногами, и я знаю, что делает мой код. Череда выпущенных библиотек — это всего лишь отвлекающие игрушки для «гуглеров». Игрушки подменяющие одну сложность на другую с потерей чего-либо в качестве необходимой сакральной жертвы.
0
БОРОТЬСЯ СО СЛОЖНОСТЬЮ МОЖНО ТОЛЬКО ОТКИДЫВАНИЕМ ФУНКЦИОНАЛЬНОСТИ
Это не так. Бороться со сложностью можно (и нужно) повышением уровня абстракции. Собственно, именно так работает человеческое мышление. Иначе говоря, абстрагирование это выработанный миллионами лет эволюции механизм, позволяющий нам оперировать понятиями весьма высокой сложности. Почему вместо того, что бы использовать этот инструмент надо пытаться упростить отбрасыванием функциональности, я не понимаю.

Резюме. Нельзя из изначально сложной системы создать более простую путем перестановки акцентов. На выходе получатся те же яйца! При замене одной сложной сущности на другую, сложность не уменьшается, а увеличивается! Уменьшить сложность можно только за счет отказа от чего-либо. Упростить можно только пожертвовав какими-то не очень нужными вещами (функциональностью).
Из неправильной посылки получается неправильный вывод. Упрощать можно разными способами, и не все они связаны с жертвами или потерями. Это особенно заметно в ПО, где львиную долю сложности составляют связи и зависимости между частями программы, а не собственно код как таковой. В этом случае можно сильно уменьшить сложность изолируя отдельные части программы путем локализации связей, объединяя небольшие кусочки данных с кодом, который с ними работает. Замечу, что жертвовать при этом ничем не приходится.

P.S. особенно порадовала фраза «Проект получается ничуть не проще, чем если бы он создавался на чистом Си.» применительно к ардуине. ардуина и написана на «чистом С» и уровень сложности и абстрактности там ровно такой же как и в любой другой либе подобного уровня (тот же libmaple).
+1
Бороться со сложностью можно (и нужно) повышением уровня абстракции.
В общем случае — это именно так. У меня нет возражений.

Но как Вы себе представляете повышение абстракции тех же портов? Повышение абстракции у USART-ов? Повышение абстракции у таймеров? А что будем делать с обработчиками прерываний, они-то как впишутся в концепцию повышения абстракции?

Ровным счётом, я не вижу ни малейшего способа избавить разработчика-программиста от знаний регистров и битов периферийных устройств МК.

На каком-то этапе создания абстактной программной модели МК может быть и удастся избавиться от регистров и битов, от той кучи знаний как это хозяйство работает и взаимодействует друг с другом. Но, мне кажется, наступит момент, когда кто-нибудь вытащит самую нижнюю карту и домик начнет падать. Скорее всего получится так, что автор абстрактной модели выкатит её со словами «Вот это избавит вас от необходимости нырять глубоко. Но если вам нужно более гибкое управление, то вам всё-таки придется изучать регистры и биты.»

И что мы имеем в итоге? А в итоге разработчик будет нести двойную нагрузку. Ему нужно будет знать абстрактную модель, и — как ни крути — ему придётся всё равно погрузиться в пучину регистров и битов. Единственным шансом на успех будет надежда на то, что это (в смысле — необходимость изучать регистры и биты) произойдёт не для всей используемой в проекте периферии, а только в каком-то отдельном модуле. Но по мере работы с разными проектами, программисту так или иначе придётся «погружаться» то по одному, то по другому периферийному модулю, и всё равно программист будет вынужден изучить работу большей части (если не все!) регистров МК.

Оставаться же на высоком уровне абстракции и не опускаться вниз до битов-регистров в отношении МК вряд ли получится. В отношении компов этот фокус канает только лишь потому, что вычислительная мощность (размер памяти, скорость работы процессора) значительно превосходят требования большинства «тяжелых» программ. Но микроконтроллеры мы обычно выбираем с очень небольшим запасом по мощности.

К стати, на рынке ведь имеются АРМ-ы с аппаратной Джавой (Jazelle) на борту! Почему они мало распространены? Ведь, казалось бы, берешь такой проц, заливаешь в него прогу (электронные часы + термометр или еще какую!) и радуешься жизни. Что не так?

P.S. особенно порадовала фраза «Проект получается ничуть не проще, чем если бы он создавался на чистом Си.» применительно к ардуине. ардуина и написана на «чистом С» и уровень сложности и абстрактности там ровно такой же как и в любой другой либе подобного уровня (тот же libmaple).
Я имел в виду, что человек, который пишет стретчи для Ардуино, он пишет только инициализацию модулей и бизнес-логику. За всё остальное, которое остается за кадром, отвечает библиотечный код Ардуины. В результате для ардуинщика откидывается целый пласт знаний (информации) как оно там под капотом всё работает. То есть для ардуинщика процесс написания программы для управления динамической индикацией в часах окажется проще, чем если бы точно такая же по функциональности программ была написана с нуля на чистом Си. Вот, что я имел в виду.

Но стоит попросить ардинщика написать прогу для более сложных устройств, то скорее всего ничего не получится. Хотя бы по тому, что апааратно помахать ножкой в Ардуино получается чуть ли не в 10 раз медленнее, чем если бы это было сделано на Си.

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

Возможно, я ошибаюсь. Возможно, чего-то не вижу. Но мне кажется, что до тех пор, пока мы не получим МК с избыточной памятью и избыточным быстродействием, говорить о повышении уровня абстракции как-то не логично. Хотя…

… да! Можно, например, взять STMF4xx и собрать на этом камне какую-нибудь светодиодоморгалку. Написать код на какой-нибудь высокоуровневой системе (библиотеке). И, я уверен, это заработает. Но какова цена вопроса? А с другой стороны — объёмы памяти у МК растут, скорости растут, а цена снижается. Неисключено, что через деясток лет какой-нибудь продвинутый программист из кагорты гуглер-копипастер выберет МК с объемом памяти в 1 ГБайт для создания супер-пупер часы-термометр на неонках с синей светодиодной подсветкой. И это будет считаться верхом творчества.

Так мы в этом направлении толкаем мир?
0
Вы путаете два совершенно ортогональных процесса, отсюда и скептицизм. Абстрагирование нужно не для того, что бы «избавиться от той кучи знаний, как это хозяйство работает и как взаимодействует друг с другом». Оно нужно для того, что бы не держать эти знания постоянно в голове в процессе работы над, собственно, бизнес-логикой. И да, в некоторых случаях прийдется спускаться в эти детали и под конкретный проект и чип дописывать необходимые части. Вопрос больше в том, что делать это («поднимать капот и чинить мотор») вполне может делать кто-то другой. Ровно так же, как в программировании компов давно (я бы даже сказал очень давно) произошло разделение специализаций программистов на «системщиков» и «прикладников», так же вполне может произойти и в эмбеде.

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

По поводу Jazelle: во-первых, Java вовсе не признак высокого уровня абстракции. Во-вторых, продавцы Jazelle хотят изрядно денег, так что ожидать массового распространения не стоит, пока ситуация не изменится.

Насчет ардуино: рассматривать ардуино с точки зрения «эпик фейл повышения уровня абстракции» не учитывая а) целей, которые преследовали разработчики и б) целевой аудитории — некорректно. Для своих целей и для своей аудитории ардуино отлично доказывает, что повышение уровня абстракции может реально помочь решению множества задач. И да, именно в этом случае из-за выбора подходов и инструментов решение потребовало ресурсов. Но это совершенно не обязательное условие. И на каких-нибудь STM32F0 с минимальными ресурсами либы типа stm32plus позволяют получить достаточно высокий уровень абстракции и, одновременно, оверхед меньший, чем у SPL.

Насчет «цены вопроса»: думаю, на тот момент она будет в районе 10-ки баксов или что-то около того. Вы беспокоитесь о ресурсах МК, хотя это всего лишь кусок обработанного кремния, в массовом производстве он стоит копейки. Куда более важный и значительно более дорогой ресурс — время программиста. Вот для того, что бы рационально использовать этот ресурс и нужно повышение уровня абстракции.
+1
Обычно когда говорят, что в компах есть этот запас, рассматривается только одна программа
Да и одной программе ресурсов откровенно мало, если говорить о «тяжелых», а не блокноте.
+1
Если говорить о ардуино, то быстродействие и функциональность там пали жертвой не уровня абстракции и не требований кроссплатформенности, а уровня ЦА. Именно из-за нее максимально простой API и защита от дурака, из-за которой тот же GPIO так медленно и работает.
+1
Оставаться же на высоком уровне абстракции и не опускаться вниз до битов-регистров в отношении МК вряд ли получится. В отношении компов этот фокус канает только лишь потому

может быть потому, что там и не надо как правило дрыгать ножками(в смысле в компах)), а как только потребуется то будет абсолютно то же самое как и МК, как Вам кажется?
-1
а как только потребуется то будет абсолютно то же самое как и МК, как Вам кажется?
На досуге посмотрите ядро линуха, особенно драйвера.
0
Речь о том, что «как правило» микроконтроллеры и лэптопы, используются для разных приложений. МК «как правило» для детального(даже можно сказать кастомного -) ) управления разным железом, лэптопским программам «как правило» достаточно стандартных средств предоставляемых драйверами. Драйверы управляя писиайными девайсами как раз и являются уровнем обсуждения т.е. МК.
0
Отчасти. Драйвера должны взаимодествовать друг с другом в плане разделения и выделения ресурсов. Так что в итоге там есть свое подобие HAL.
0
лэптопским программам «как правило» достаточно стандартных средств предоставляемых драйверами
Некоторое время назад на ПК точно так же «детальное управление железом» было вшито прямо в программы (характерный пример — досовские игрушки с вшитыми драйверами видео- и звуковых карт). Но это неудобно, в связи с чем и произошло выделение HAL, встроенного в операционную систему. Чуть позже аналогичные изменения произошли с игровыми приставками (если в пятом поколении железо программировалось напрямую, то уже в шестом в приставках появилась ОС и слой дров). Что-то похожее нынче происходит и в области МК.
0
STM32 это совсем не сложный процессор. Так я работал с разными, я бы даже сказал он чуть сложнее AVR. Процессоры 30-40 лет назад были гораздо сложнее и нормально люди справлялись. Просто уровень падает и простое кажется сложным. По фото заброшенного ангара можно понять уровень. никакой STM32 там рядоим не стоял. Мне кажется сейчас подход MS на решение проблем путем увеличения MHz и RAM переходит в embedded. Мало 72 — возьми 168, Хотя можно напрячь мозг и сделать алгоритм чуть эффективнее. Но это не выгодно. Есть только одно проблема — БАТАРЕЙКИ. Никак их не могут в том же объеме сделать в 10 раз больше по энергии. Вот тут и возникает коллизия между MHz и временем подхода к зарядке.

В общем как обычно всё свелось к формуле

знания * деньги = const
0
STM32 это совсем не сложный процессор.
А я и не говорил, что он сложный. Я говорил:
STM32 — это относительно более сложный МК, по сравнению с AVR-ками и MSP430.

Для доказательства очевидного, давайте сравним регистры управления портами ввода-вывода у AVR и у STM32.

У АВР-ок всего три регистра PORTx, DDRx и DIRx, которые сразу же после подачи питания на МК готовы к работе. В качестве исключения сюда же можно отнести регистры DIDRx, которые осуществляют отключение цифровых буферов. ожно натянуть сову на глобус и PCMSKx
+1
(Блин! Ошибся с клавишей, недописанное сообщение «улетело в продакшын»!)

… продолжаю.

У самой первой серии STM32F1xx регистров управления портами ввовда-вывода уже семь: CRL, CRH, IDR, ODR, BSRR, BSR и LCKR. Ну, хорошо-хорошо, пусть регистры CRL и CRH — это будет как один регистр. Но все равно — где Вы видели в АВР-ках конфигурирование скорости работы порта (биты MODE), конфигурирование типа выхода (биты CNF)?

Ах, да, чуть совсем не забыл! Чтобы порты заработали нужно сначала включить им тактирование.

Хорошо, давайте оставим порты. Давайте сравним USART, давайте сравним систему тактирования. Наконец, давайте сравним разнообразие и количество периферии у AVR и STM32.

Я еще ра повторю свою фразу:
STM32 — это относительно более сложный МК, по сравнению с AVR-ками и MSP430. Это очевидно и не требует доказательств.

Вы сказали:
Так я работал с разными, я бы даже сказал он чуть сложнее AVR.

В отличие от Вас мне удалось поработать не с таким уж большим количеством разных микроконтроллеров. Пожалуйста, приведите пример микроконтроллера, который был не «чуть» сложнее AVR, а был __существенно__ сложнее и AVR, и STM32.

Просто, мне кажется, что мы говорим о разных понятиях. Я реально не знаю __широко_применяемых__ микроконтроллеров, которые бы были сложнее STM32. Возможно Вы говорите о каких-то уникальных дорогих изделиях — то есть об исключениях, но я-то говорю о правилах — о тех микроконтроллерах, которые широко используются народными массами.

Не получается ли так, что каждый из нас говорит о своём?
+1
Я реально не знаю __широко_применяемых__ микроконтроллеров, которые бы были сложнее STM32.
Думаю, серия LPC4300 существенно сложнее. Начиная с того, что они многоядерные (хотя все еще Cortex-M4/M0, а не Axx).
+1
Несчитова!

LPC4300 сложнее любого STM32F1xx. Тут без вопросов! Но ведь разговор шёл про "__широко_применяемых__ микроконтроллеров".

Хотя, да! Нужно было нужно заранее оговаривать, что подразумевает под собой определение «широко пременяемые МК народными массами». Из Вашего ответа теперь получается, что LPC4300 — применяется народными массами столь же широко, как STM32. Ну, скажем так — LPC4300 так же интенсивно обсуждается на easyelectronics, как STM32F100. Количество проектов на LPC4300 соизмеримо с количеством проектов на STM32. Но ведь это же не так!

Ладно. Мы тут что, адвокатские поединки устраиваем что ли? Кто кого подловит на неточностях.
0
Да, количество проектов на LPC4300 значительно меньше, но, тем не менее, это массовый чип и он применяется достаточно широко. Собственно, если не обобщать «STM32», а посмотреть, хотя бы, по сериям, то окажется, что массовыми в этом смысле могут считаться разве что серии F1 и F0, остальные распространены гораздо меньше.

P.S. на LPC4300 вроде как собираются делать Smoothieboard 2.0. пожалуй, для любительских разработок это достаточно заметная конструкция. и, думаю, достаточно массовая.

Да, конечно это не адвокатский поединок. Я всего лишь пытаюсь добавить информации в обсуждение, что бы оно не пошло по пути отбрасывания фактов не вписывающихся в исходные концепции.
0
1. Полностью ли абстрагирует эта конкретная библиотека железо, во всей его сложности? Вопрос шире.
Свой взгляд на этот вопрос я уже описывал — реализовать, в принципе, можно что угодно, но когда пытаешься создать кроссплатформенный API — все приходится чесать под общую гребенку, а HAL на мой взгляд в первую очередь именно средство кроссплатформенности.
Описать в декларативном стиле (a-la QML) в JSON формате, что нам нужно от периферии.
Это называется DSL, и в принципе, есть немало специалистов, считающих этот путь лучшим. Но в плане HAL-подобного применения я еще не встречал DSL в эмбеде, только XML-описания периферии МК, используемые некоторыми средами.
0
  • avatar
  • Vga
  • 28 мая 2016, 09:59
Я считаю что в этом вопросе правильный подход 80/20. То есть не надо пытаться покрыть HAL-ом весь функционал. Только время угрохаешь, а на выходе будет штука не легче и не проще, чем просто без HAL-а.
0
Эта библиотека stm32plus тоже стала жертвой неустойчивой библиотечной политики ST Micro. Вот что бывает, когда строишь свое здание не на твердом фундаменте CMSIS, а на некой надстройке над ним.

Фирменные либы описания ядра и периферии чипа, сделанные по стандарту CMSIS (по сути там жалкая горсть файлов), приняты сообществом MCU кодеров безоговорочно, как фундаментальный стандарт. Даже регистрщиками а-ля Dosikus, и ими в первую очередь, т.к. они-то и знают их досконально. Библиотечники же могут о них кое-что знать, но обычно не ползают по ним столь же усердно, т.к. файлы CMSIS подтягиваются/инклудятся из библиотеки SPL/HAL автоматом.

Так вот, stm32plus построена так, что она инклудит хедеры библиотеки SPL из \lib\fwlib\fx\stdperiph\inc\ и юзает их name_space, эти хедеры уже в свою очередь инклудят сам CMSIS из \lib\fwlib\fx\cmsis\. Гы-ы, получается что щас Andy Brown'у надо срочно переписать/дописать stm32plus для поддержки уже хедеров из либы HAL от ST Micro :DDD Или же переписать либу так, чтобы этих оберток в виде SPL/HAL хедеров ваще не было.
0
Т.е. stm32plus вроде бы 100% CMSIS Compiant, но через прослойку от SPL, которая уже obsolete и NRND.
0
Создатель же либы libopencm3, так же упоминавшейся кем-то, решил ваще героически попилить якоря напильником и совершил марафонские забеги — попереписал портянки мега-хедеры из состава CMSIS в виде кучи своих файлов, см. например, в каталоге \include\libopencm3\stm32\fx. Как и файлы CMSIS для ядра, см. \include\libopencm3\cm3.

Т.е., грубо говоря, libopencm3, ваще, NO CMSIS Compliant.
0
Гы-ы, получается что щас Andy Brown'у надо срочно переписать/дописать stm32plus для поддержки уже хедеров из либы HAL от ST Micro
Зачем?
+2
На самом деле — все еще даже хуже.

Щас посмотрел внимательнее stm32plus, конкретно GPIO. Как уже сказал, в \lib\fwlib\fx\stdperiph\ находится SPL, как прослойка. Но дело в том, что использован готовый name_space не только из хедеров в \lib\fwlib\fx\stdperiph\inc\, например, из хедера stm32f10x_gpio.h заюзаны:
enum GPIOSpeed_TypeDef
struct GPIGPIO_Pin_X
struct GPIO_InitTypeDef // Wow! Даже эта старая знакомая!
// ну и продефайненный константы:
GPIO_Remap_XXX
GPIO_PortSourceGPIOX
GPIO_PinSourceX

Но и функции, да, КАРЛ!, ФУНКЦИИ!
// конкретно вот эти функции:
GPIO_PinAFConfig
GPIO_WriteBit
GPIO_Write
GPIO_ResetBits
GPIO_SetBits
GPIO_ReadInputData
GPIO_ReadInputDataBit
GPIO_StructInit
GPIO_Init

Не поливая совершенно грязью саму библиотеку stm32plus, можно сказать: она была сделана как надстройка над SPL, которую (как показала жизнь) нельзя считать твердым фундаментом или даже некой устойчивой и постоянной прослойкой (под коей, я лично, вижу щас только CMSIS-Driver + свой Snippets код внутре него).

По хорошему, stm32plus надо переписывать под HAL или лучше просто сразу над CMSIS для STM32, а еще лучше — над CMSIS-Driver, что даст еще и переносимость между MCU разных производителей, но тогда это будет уже не stm32plus, а CortexMplus.

Или же просто юзать CMSIS-Driver, ну и писать(копи-пастить) самому его драйвера для конкретного MCU.
0
Ну реюзать готовые константы и структуры это нормально, в конце-концов это всего лишь описание данных. Вот то, что теперь используется SPL это новость для меня. Раньше вроде такой фигни не было.
+1
Да, использование имен из stm32f10x_gpio.h — это просто чисто эстетический недостаток для перфекционистов. Но использование функций из stm32f10x_gpio.c — это уже ЩАС проблема для него. Он был уверен в незыблемости SPL, и что она будет просто расти горизонтально по мере появления новых семейств.
0
Я не думаю, что он вообще полагался на то, что SPL будет расти. К тому же в либе поддерживаются семейства типа F0, для которых SLP нет.
+1
Под F0 есть SPL v.1.5.0
Её CMSIS точно поддерживает следующие чипы:
#if !defined (STM32F030) && !defined (STM32F031) && !defined (STM32F051) && \
    !defined (STM32F072) && !defined (STM32F042) && !defined (STM32F091) && \
    !defined (STM32F070xB) && !defined (STM32F070x6) && !defined (STM32F030xC)
  /* #define STM32F030 */   
  /* #define STM32F031 */   
  /* #define STM32F051 */   
  /* #define STM32F072 */
  /* #define STM32F070xB */   
  /* #define STM32F042 */
  /* #define STM32F070x6 */   
  /* #define STM32F091 */
  /* #define STM32F030xC */  
#endif
0
Для L0 не делали SPL.
0
Ну и для F7.
0
вообще я считаю, что все эти либы — чистый маркетинг.
1.Есть профессионалы, которым либы не нужны… Но их мало. Они оценят чип по железу.
2.Есть программеры среднего звена. Они боятся/не доросли/лень/нет времени разбираться с железкой. Но есть «волшебный» HAL. На них собственно это и рассчитано. Но как говорится, помощник феи, подаривший хрустальные туфельки Золушке, хотя он только учился, оказался куда более прогрессивным, чем его учительница добрая фея. Ее волшебство рассеялось, а вот его туфелька осталась)
0
вообще я считаю, что все эти либы — чистый маркетинг.
Учитывая, что автор либы занимается этим как хобби — никаким маркетингом там и не пахнет.
1.Есть профессионалы, которым либы не нужны… Но их мало. Они оценят чип по железу.
Я бы сформулировал это иначе: есть люди, которым по приколу колупаться в отдельных битах, их интересует процесс, а не результат. Прикладная сторона процесса для них вторична (а то и третична). Хороший вариант для хобби, но совершенно не годится для промышленной разработки.
2.Есть программеры среднего звена. Они боятся/не доросли/лень/нет времени разбираться с железкой. Но есть «волшебный» HAL.
Все куда проще: их интересуте результат, а не процесс. И скорость получения этого результата. А еще у них руки не из задницы, потому они могут сделать свою жизнь удобнее, а процесс разработки быстрее, с фокусом на результат, а не на процесс.
+4
Угу. От себя добавлю, что писать свой велосипед для реализации, например, обертки вогруг GPIO или таймеров прикольно только первые раза 3 :) А потом надоедает, и хочется сконцентрироваться на самой логике устройства а не заниматься написанием в очередной раз очередного велосипеда под очередную платформу.
+1
да, вот только поддержка хромает. Волшебство рассеялось… Либы перестали поддерживать. Сначала SPLб теперь уже HAL не модно… Что теперь? А изучать все эти талмуды библиотечек не считается потерей времени?
0
А изучать все эти талмуды библиотечек не считается потерей времени?
Если это быстрее, чем изучить регистры — нет.
0
Так или иначе, чтобы изучить назначение всех этих библиотечных функций — требуется предварительно изучить периферию. На мой взгляд, весь этот оверхед лишь кажется ускоряющим процесс.
0
Для лечения болезни «конец поддержки» давно и весьма успешно используется опенсорс. До тех пор, пока либа хоть кому-то нужна, она будет жить и развиваться.
0
это хорошо, если образуется команда, которая возьмется централизованно фильтровать и применять доработки программеров или горе-программеров. Но в данной области, что-то мне подсказывает, сдвигов нет особо.
0
Наличие команды совершенно не обязательно. Если либа очень нужна, а текущее состояние не устраивает — сделайте форк и развивайте самостоятельно так и туда, куда нужно именно вам.

P.S. в stm32plus такая команда есть и есть постоянная активность.
0
ну, собственно, туда и вернулись, отчего и начали — к велосипедам
0
только проблема еще и усугубилась. Придется чужие шестеренки пилить
0
я так уже попал, когда подсел на uIP. Когда мне нужно было внедрить поддержку нескольких IP на одном девайсе уже после того, как большая часть софта была написана. Пришлось пилить. Занятие не их приятных, скажу я вам
0
Хороший повод подумать, прежде чем писать следующий проект.
0
Не нравятся готовые — сделайте свои.
0
С чего вдруг «велосипедам»? Аналогов «от производителя» нет и, судя по всему, не предвидится.
0
Учитывая, что автор либы занимается этим как хобби — никаким маркетингом там и не пахнет.
Ну я как бы о SPL и HAL говорил.
0
Да, но в ответе на пост об stm32plus. Собственно, я потому так часто эту либу и упоминаю, что она лишена всех проблем характерных для «либ от производителя». Она опенсорсная, так что поддержка не прекратится, она постоянно развивается и расширяется, она достаточно высокоуровневая, что бы пользоваться было удобно, она достаточно легко расширяется при необходимости и, наконец, в силу своей архитектуры она дает минимальный оверхед и, думаю, сравнима по эффективности с прямым колупанием в регистрах.
0
Оглядываясь на BSP для всяких взрослых ARM-процессоров для линукса — HAL, абстракции и библиотеки наше неизбежное светлое будущее. Просто хорошую модель еще не придумали, но судя по CubeMX и DAVE от инфинеона, по всей видимости все будет двигаться в этом направлении. Мышкой тыкаем, потом генерим заготовку и в заранее определенные места вписываем свой код.
А битодрочерство станет уделом «эстетов».
+2
Мышкой тыкаем, потом генерим заготовку и в заранее определенные места вписываем свой код. А битодрочерство станет уделом «эстетов».

Да, нахрена? Нахрена это всё нужно? Нахрена какой-то мышкой куда-то тыкать! Бабло вообще решает все вопросы.

Берм пачку денег
идем на Авито/Алиукспресс/Ибай или находим лоха-разработчика
покупаем то, что нужно.
Соединяем проводки

профит!

Не, нуачо? Эффективность решения вопроса посредством денег всегда выше эффективности что-то самостоятельно изорбретать-колхозить, ждать появления на рынке универсальных-библиотек-на-все-случаи-жизни… А библиодрочерство станет уделом «эстетов».
0
> Бабло вообще решает все вопросы.
Слабая попытка применения риторического приема «доведение до абсурда», так что за аргумент не считается.
Мы же тут обсуждаем чем все это закончится?
Так вот, что тут сказал evsi, для компенсации сложности надо использовать высокоуровневые абстракции. Спорить с этим аргументом глупо, весь путь развития человечества показывает это. Так что предлагаю рассуждать в этом ключе. Тем более составные части решения уже давно придуманы, осталось сделать последний шаг и все это объеденить.
Только начать надо с другого конца, не с железки, а с программы. Придумать компактный мощный язык под решение встраиваемых задач. Решение типовых задач на нем. Никому не нужно чтение битов статуса и дерганье ногами, всем нужно отправлять в порт свои структурированные данные. Принимать и обрабатывать отсчеты от ADC. Формировать ШИМ-ы. Поддерживать диспетчеризацию своих задач. Читать/писать внешнюю память. Так вот под все эти абстрактные задачи придумать готовые модули. А потом уже исходя из этих требований уже запилить правильное железо чтобы оно максимально эффективно решало эти задачи. Тем более, что в целом этим может заняться любой студент. Купить быструю и жирную плисину сейчас совсем не проблема. И вот когда эта задача будет решена, мы получим не кучу странных архитектур, а набор стандартных базовых блоков с оптимальной поддержкой со стороны ПО. А производители будут соревноваться в быстродействии и потребляемой мощности. Ну и в придумывании новых интересных блоков которые уже будут встраиваться в эту программно-аппаратную архитектуру.
+2
Хм. Я бы скорее ожидал стандартизованный слой дров (вероятно, CMSIS Driver — по крайней мере, сама CMSIS прижилась) и последующую адаптацию периферии под него. Возможно — кодогенераторы, хотя со стандартным HAL-ом в них особой нужды не будет, и они могут быть 3rd party.
0
Ну да, признаю — мой каммент содержит едкий сарказм на реплику «А битодрочерство станет уделом «эстетов»», которая мне и не понравилась. Согласен — каммент не является серьезным для делового разговора. Закроем этот пункт. Давайте лучше поговорим по делу. Тем боле и Вам и мне этого хочется.

Ну, во первых, отрицать, что при использовании микроконтроллеров чаще всего возникают примерно одинаковые задачи — как Вы сказали: «нужно отправлять в порт свои структурированные данные. Принимать и обрабатывать отсчеты от ADC. Формировать ШИМ-ы. Поддерживать диспетчеризацию своих задач. Читать/писать внешнюю память» — ну, это было бы глупо.

Набор программных модулей (можно назвать — драйверов) наверно бы решил проблему разработчиков, которые предпочитают работать со стандартным программным интерфейсом (API? ABI? POSIX? ...), а не зарываться в определение битов и названия регистров конкретного микроконтроллера.

И в самом деле, берём любой (доступный) микроконтроллер — STM32F, LPC, AT91SAM3, MSP432 или ещё какой и качаем из интернет-репозитория необходимые драйверы на его периферийные модули. Затем подключаем эти драйверы в проект и обращаемся к ним стандартным образом — через единый для всех микроконтроллеров интерфейс.

Однако, засада в том, что у разных производителей разная реализация аналогичных периферийных устройств. Самый простой пример: разрядность портов ввода вывода. У LPC порты 12-разрядные, у STM32 — 16-разрядные. У AT91SAM7 были 32-разрядные (я не знаю скольки-разрядные у AT91SAM3, но подозреваю, что по аналогии с SAM7 тоже 32-разрядные).

Про то, что управление портами даже у одной фирмы ST Microelectronics разное, я молчу! Я имею в виду порты ввода вывода у STM32F1xx и порты ввода вывода у STM32F0xx.

Порты ввоза-вывода — это регулярные структуры. Под регулярные структуры легко можно написать масштабируемые макросы. Но что делать с нерегулярными структурами типа USART-ов?

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

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

А вот дальше начинается песня! Один микроконтроллер позволяет передавать блоки информации через DMA, а у другого этой функции нет, так нет самого DMA. Один микроконтроллер имеет аппаратную поддержку RS485, а у другого эту функциональность нужно реализовывать программно. К стати, RS485 — это не такой уж и экзотический канал передачи данных!

Один микроконтроллер имеет поддержку протокола Smartcard ISO 7816-3, а другой — только IrDA, а у третьего — только поддержка LIN. Все микроконтроллеры — разные…

Таким образом, получается для того, чтобы мы могли создать универсальный драйвер, мы должны ПРИНЕСТИ В ЖЕРТВУ уникальные функциональные возможности микроконтроллеров. То есть это то, о чём я говорил ещё в самом начале дискуссии. Хотим мы этого или нет, но в целях упрощения работы с драйвером нам так или иначе придется ОТКИНУТЬ ФУНКЦИОНАЛЬНОСТЬ.

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

Мы же стремимся упростить работу разработчика. Хф хотим вывести его на более высокий уровень абстракции. Мы хотим предоставит ему универсальный драйвер, который подходит к любому (ну, пусть — в каком-то ограниченном списке) микроконтроллеру. И в то же время не заявляем, что мы при переходе на новый уровень абстракции мы не потеряли часть функциональности.

Возможно, я чего-то не понимаю… Но на этот раз я пытаюсь с Вами вести серьезный диалог.

Ведь, на сколько я понимаю, мы тут собрались не письками меряться, а попытаться выяснит, можно ли создать такое програмное обеспечение, которое… и, если нельзя, то — почему.
0
Я в своей библиотеке иду другим путем — не отбрасываю имеющуюся «избыточную» функциональность, а описываю желаемую, типа как andi123 говорит. Описываю в API, какая функциональность мне нужна бы с точки зрения прикладной программы. Конфигурация периферии более специфична для конкретной платформы; она отделена от использования, которое менее специфичное. Для конкретного МК часть может быть не описана — тогда или некоторый код просто не соберется для этой платформы или надо будет писать программную имитацию. Нет четкого разделения на HAL и прикладной код; это скорее независимые компоненты (в большинстве своем), которые можно собрать в нужной конфигурации. Ну и API придумывается не раз и навсегда, а постепенно редизайнится/расширяется под новые задачи (без оглядки на совместимость). Все делается на C++-шаблонах.
0
В моем понимании «библиотека» — это то, что используется без адаптации к конкретному проекту. Ну, например, стандартная библиотека Си — от проекта к проекту мы её код не трогаем. (Точнее — мы вообще этот код не трогаем!)

А то, что делаете Вы, это скорее напоминает сниппеты. Сниппеты — это примеры использования кода. Я лично, как раз создаю новые проекты на основе кодов из старых проектов. Иногда коррекция кода достигает чуть ли не 90%. А иногда код ложится в новый проект один в один вообще без какой-либо правки.

Может быть Вы говорите о библиотеке сниппетов (то есть о некотором наборе сниппетов), а не о библиотеке, как двоичном (уже откомпилированном) модуле?

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

Да! Маленькое уточнение — для МК я пишу исключительно на Си, не не С++.

Я считаю, что использование С++ оправдано, когда в программе требуется динамически создавать и разрушать объекты. Когда нужно динамически запрашивать память в одном месте, использовать в другом, а в третьем — возвращать обратно в пулл. Ну и в некоторых других случаях. Но те задачи, с которыми мне приходится иметь дело в своих проектах, этого ничего не требуют. Максимум, что им надо — обмен сообщениями между модулями системы. Поэтому я как-то не вижу особой надобности прибегать к применению С++. Мои проекты не такие уж сложные, и на моей памяти у меня было два или три проекта, которые вышли за грань понимания того, что я вообще делаю. Ну, не в смысле что вообще проект делает, а в смысле, что я не особо догоняю, как дальше развивать (увеличивать его функционал) проект. Поэтому я не вижу проблемы использования Си. Я пользуюсь и проблем не знаю. Поэтому, наверно, мне и не понятны заботы о какой-то универсальном слое, который бы похоронил под собой необходимость знаний регистров и битов.
+1
А какое отношение С++ имеет к динамической памяти? Не тем он ценен в эмбед проектах.
+1
а чем?
0
Шаблоны, constexpr, классы (они совсем не обязаны быть динамически создаваемыми — впрочем, и таким в соседнем топике нашли применение).
+2
А зачем мне, в микроконтроллерной программе шаблоны? Я ж говорил про свои проблемы. А Вы про вообще что-ли? Мне и классы-то как таковы не нужны. Вот чего точно не хватает, так это пространства имён — в больших проектах слишком много бывает почти одинаковых имен функций. Хотелось бы как-то их «красиво» группировать.

Может быть я не прав… но на сколько я понимаю, чтобы писать код для МК на С++, а не на Си, — это нужно полностью перестроить свой образ мышления. Нужно «думать» о работе программы не в контексте вызовов процедур, кто кого вызывает и какие параметры передает, а в контексте объектов, которы друг о друге почти ничего не знают.

Объект — это клерк, который сидит и ждет приказа. Нет приказа — ничего не делает со своими данными. Есть приказ — выполняет. Клерков много. Они обмениваются друг с другом сообщениями-приказами. Значит, должен быть какой-то общий для всех клерков диспетчер, который как раз и занимается диспетчеризацией «работ» или событий. В систем должен быть первичный источник событий, а чаще всего — даже несколько источников, которые как правило уже обслуживаются обработчиками прерываний.

Возникает в систем какое-нибудь прерывание (допустим, тикает системный таймер или поступает в UART очередной байт извне), система генерит целый кластер вторичных событий. Вторичные (или производные) события — это, например, сообщения объектам, что нужно произвести кусочка данных запись во внешний EEPROM или просто зажечь синий светодиод.

Ну, то есть такая программа должна работать в полном соответствие с парадигмой ООП. Но если мы пишем С++-код в режиме Си, то в чем тогда прикол?

А если мы используем С++ по взрослому, то создавать и разрушать динамически объекты — это наше всё! Но при этом надо отдавать себе отчет в том, что оперативная память будет жестоко дефрагменитроваться. Памяти в МК как мы знаем — не разбежишься! Поэтому приходится осторожничать, опасаясь, что в процессе эксплуатации может возникнуть элементарная нехватка в системе относительно большого неразрывного куска памяти. Ну допустим под какой-нибудь буфер или объект типа принятый пакет. (Парадигма С++ — данные управляют процессом, а не процесс управляет данными.)

Ну, то есть я хотел сказать, что применять С++ на половину, конечно, можно, но для меня прелесть С++ выражается не только в его полиморфизме, наследовании, шаблонах, пространствах имен, жесткой типизации, но прежде всего в его способности динамически создавать и разрушать объекты. Это механизм С++ для моих программ очень нужен, но всё, как я уже говорил упирается в две проблемы — МК не обладают достаточно большим объемом оперативы (1), а использовать С++ только ради этого, как-то не очень рационально. Собственно, можно было бы взять проц с большим количеством ОЗУ, но зачем? Зачем мне покупать более навороченный камень, если я успешно могу поднять проект на Си?

Вот и всё, что я имел ввиду в предыдущем, когда говорил о динамических способностях С++.

В общем, я не вижу жесткой необходимости использования С++ в своих проектах. Ну, это как бы мои проблемы. Я не думаю, что их стоит здесь обсуждать.
0
А зачем мне, в микроконтроллерной программе шаблоны?
Например, для удобной и быстрой обертки на GPIO.
Объект — это клерк, который сидит и ждет приказа. ...
Описанное скорее относится к событийно-ориентированному программированию, которое к ООП довольно мало отношения имеет. С++ подобного не навязывает. Можно использовать доступные средства как угодно.
А если мы используем С++ по взрослому, то создавать и разрушать динамически объекты — это наше всё!
Опять же, совершенно не обязательно. Только если того требует задача.
Парадигма С++ — данные управляют процессом, а не процесс управляет данными.
Нет, это парадигма DDP. С++ же мультипарадигменный. Как хочешь, так и пиши. Главное, чтобы правильно.
но прежде всего в его способности динамически создавать и разрушать объекты
Вот как раз в этом моменте С++ от С отличается минимально, если вообще отличается.
+2
Нет, это именно библиотека, а не сниппеты. Код не трогаем, если он и так делает все, что нужно. Обычно для самописных библиотек это не так — тогда развиваем в нужном направлении. Ну и абстрагироваться от регистров — можно и нужно. Это не сложно. Сложнее выделить API, который действительно общий для всех возможных реализаций. И да, C++ у меня без динамической памяти.
0
Код не трогаем, если он и так делает все, что нужно. Обычно для самописных библиотек это не так — тогда развиваем в нужном направлении.
Но тогда, получается, что в очередном новом проекте, куда будет линковаться библиотека, может оказаться так, что в библиотеке не будет какой-то функциональности. Ну допустим, мы обычно работали с проектами, которые используют «чистый» RS232, а тут нам нужно сделать проект для RS485. Что мы делаем? Мы открываем исходники библиотеки, дописываем в них функциональность для управления линией (приём/передача, локальное эхо)… к стати, как будем решать проблему — какой бит и какого порта выделить для этого дела? Затем компилируем новую версию библиотеки. Пока всё хорошо!

Через месяц подряжаемся на создание прибора управления по ИК-каналу каким-нибудь телеящиком (да, я фантазирую!), И мы снова вытаскиваем исходники библиотеки и дописываем работу IrDA.

Через год нам понадобится дописать код для управления еще какой-нибудь хренью. Заране-то как знать — что может понадобиться?

Но проблема не в этом! Проблема в том, что в процессе жизненного цикла библиотека будет жирнеть и разбухать. Количество ошибок в коде пропорционально его объему. Добавляя в код новую функциональность вы добавляете возможные ошибки. Которые могут вылезти не прямо сейчас, а в процессе эксплуатации изделия. Вы будете вынуждены брать для своих изделий микроконтроллеры с большим объемом флеша — ведь библиотека будет содержать много чего лишнего с точки зрения проекта, но ведь это лишнее не выкинешь!

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

Мне кажется, что это какая-то утопия! Для реализации этой мечты придётся затратить уйму времени, чтобы раз и навсегда создать универсальный-код-на все-случаи-жизни. И только потом, изредка и немного его подправлять. Мне кажется, это не реально… Ваш основной источник дохода — ведь не написание таких библиотек? Когда вы это всё будете делать? Какова эффективность Вашего труда с точки зрения общества?

Я уж помолчу про документацию и маны к этой библиотеке…
А ну как в вашей библиотеке встретится какая-нибудь ошибка, которая будет возникать эпизодически? Ну, например, UART, работающий в режиме RS485, будет «глотать» последний бит в последнем байте пакета и делать это будет только в том случае, если этот бит будет нулевой? (Я опять фантазирую. Но основа моих фантазий — множество подобных случаев на практике.) И как пользователи Вашей библиотеки будут отлаживать свои программы?

Поэтому самый приемлемый путь, как мне кажется, — это юзать сниппеты и учить регистры. Тогда код будет компактным и будет легко отлаживаться.
+1
Вы будете вынуждены брать для своих изделий микроконтроллеры с большим объемом флеша — ведь библиотека будет содержать много чего лишнего с точки зрения проекта, но ведь это лишнее не выкинешь!
Действительно, ведь смарт-линкеры еще не изобрели…
Поэтому самый приемлемый путь, как мне кажется, — это юзать сниппеты и учить регистры. Тогда код будет компактным и будет легко отлаживаться.
Компактным — возможно, хотя и не факт. Легко отлаживаться — ой врядли.
+1
Легко отлаживаться — ой вряд ли.
Ну для этого нужно иметь проверенную годами и разными проектами библиотеку. Ладно, если она есть такая?

А что делать в случае, когда в библиотеке косяк? Причем, что косяк именно в библиотеке, а не в твоем коде, — нужно убедиться.

Если свой код, который мы сами писали, мы еще понимаем (понимаем, как он работает), то код чужой библиотеки нужно еще вкурить… На сколько это проще — вопрос.
0
Я прикладник в первую очередь, использовать и курить чужие библиотеки — дело привычное. Так что все эти проблемы если и не надуманы, то как минимум не так уж страшны.
+1
Я прикладник
— а-а, ну это многое объясняет! Как минимум то, почему мы друг друга плохо понимаем.
Мне ближе железо.
+1
Могу только предложить подтянуть программирование и не нести чушь вроде «Парадигма С++ — данные управляют процессом, а не процесс управляет данными».
+1
На сколько я понял, andy123 хотел бы иметь с модулями, в которые не нужно влазить. Которые нужно просто подключить в файл проекта и слинковать вместе с файлами, описывающими бизнес-логику.
Вот не надо тут про меня фантазировать. Я конечно люблю все готовое, но смысла держать готовые бинари для МК, уже через чур. Все должно быть в исходниках, причем все неиспользуемое на этапе компиляции должно быть исключено. Чем и хорош в данном случае С++ с шаблонами, что пишешь обобщенную логику, а на этапе компиляции она разворачивается в очень компактный конкретный вариант реализации.
+1
ну пусть будет так, как Вы говорите!

Но вопрос-то всё равно не снимается — кто будет сопровождать и поддерживать эти библиотеки-в-исходниках (или как их правильно называть)?

На сколько я понимаю, это будет тот еще код! Не каждый разработчик рискнёт в них лезть и править баги и подгонять под свои требования. Вы когда-нибудь видели программ без багов и с безупречной идеологией (алгоритмикой)? Чем ваша гипотетическая библиотека будет отличаться в этом смысле от других программных продуктов?

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

А языком чесать код мы все умеем.
0
Ну в ядре линукса сейчас 15+ млн строк. И ничего, народ поддерживает, компеляет, делает свои форки, пишет драйвера, портирует куда попало. Проблема надуманная. Вы кстати свой код в репозиторий (SVN, GIT) складываете?
+2
Выкладываю. С коллегами по работе так и работаем. Иногда свои испражнения сливаю.

Для чего это Вам?
0
(или как их правильно называть)
Библиотеками и называть. С чего вообще библиотеки должны быть в бинарниках? Тем более странно слышать это от линуксоида, которые обычно блобы люто бешено любят.
Не каждый разработчик рискнёт в них лезть и править баги и подгонять под свои требования.
Вообще, по хорошему, библиотека затем и нужна, чтобы в нее не лезть, а юзать как черный ящик. Если в нее приходится постоянно лазить и подкручивать — лучше послать такую библиотеку куда подальше и поискать (на крайняк написать) нормальную. Никто же в том же линуксе не патчит Qt под себя, не так ли?

Я юзаю только одну библиотеку, которую приходится регулярно подпиливать под себя. И можешь мне поверить, эта библиотека — отличный образец библиотек, с которыми не надо связываться.
0
С чего вообще библиотеки должны быть в бинарниках? Тем более странно слышать это от линуксоида, которые обычно блобы люто бешено любят.
А кто тут думает, о «библиотеке» в широком смысле этого понятия, как о бинарных кодах? Библиотеки — они ведь разные. Бывают даже с бумажными книжками! Ой, любите Вы батенька троллить и перходить на личности! Ой, любите!

Если в нее приходится постоянно лазить и подкручивать — лучше послать такую библиотеку куда подальше
Во-о! Золотые слова! А теперь смотрим, что может у нас получится.

Библиотека в виде текстовых файлов (исходников). В библиотеке наверняка найдутся и косяки и нелогичные действия. У продвинутых разработчиков появится высокий соблазн влезть и поправить. А через некоторое время еще раз залезть и поправить в другом месте. Со временем человек научится ориентироваться в коде, и процесс ползучей модификации уже станет перманентным…

Так ЧТО, говорите, является гарантией того, что эта библиотека, о которой мы тут пишем очередную Тору, будет сразу идеальной и не потребует вмешательства?
0
А кто тут думает, о «библиотеке» в широком смысле этого понятия, как о бинарных кодах?
Ты.
Может быть Вы говорите о библиотеке сниппетов (то есть о некотором наборе сниппетов), а не о библиотеке, как двоичном (уже откомпилированном) модуле?
Мы говорим о библиотеке, как middleware. Это не библиотека сниппетов, это как раз второй вариант — но совершенно не обязательно в двоичном виде.
У продвинутых разработчиков появится высокий соблазн влезть и поправить.
Править библиотеки нежелательно. Причем аргумент я приведу со стороны железячников
— А может, просто отпилить эту фигню с клеммы и все? — спросил я
— Комплектующие доработке не подлежат — строго ответил руководитель радиокружка
Так ЧТО, говорите, является гарантией того, что эта библиотека, о которой мы тут пишем очередную Тору, будет сразу идеальной и не потребует вмешательства?
Здесь именно обсуждение как создавать такую библиотеку, чтобы и весь функционал иметь, и не допиливать ее отдельно под каждый проект.
А если вам таки надо уже готовую библиотеку такого типа — вон, ардуино есть. Хороший образец, только функциональность подкачала — особенности ЦА.
0
Ха! Ну Вы мастер натягивать сову! Я же говорил не в утвердительной форме, а в форме предположения, как раз пытаясь выяснить что подразумевается под термином «библиотека» в контексте ЭТОГО разговора.

А если вам таки надо уже готовую библиотеку
Да, Вы меня с кем-то путаете! Мне как-то на библиотеки глубоко. Я с удовольствием юзаю сниппеты и кручу шестерёнки из регистров и битов. Ну, будет в свободном доступе какая-то библиотека сниппетов. Ну и что! Это никак не изменит мой подход к созданию программных проектов. Возможно, я повыдергаю их этой библиотеки какие-нибудь понравившиеся мне участки кода, и тем дело ограничится. А таскать за собой полный чумодан (библиотеку) кодов — я вряд ли буду.

Нахрен мне заботится о её целостности, если я точно не буду применять 90% кода из того, что там будет? Нахрен мне нужна какая автоматизация при инициализации регистров ввода-вывода, когда я УЖЕ владею инструментом как программировать регистры ввода вывода. Нафиг мне нужно изучать какие-то сомнительные кодовые «сахара», когда я уже не плохо пишу свои проекты?

Нет, ребята. Вам нужна библиотека — вы её и точите! Я лучше по старинке буду курить отдельные независимые сниппеты и примеры красивого кода, и копипастить их в свои исходники.
0
(забыл сказать)

Нахрен мне изучать то, что возможно не взлетит. Где гарантия того, что ЭТО не окажется очередным «фреймворком», коих уже пруд пруди?

Уже которой круг в погоне за Граалем нарезаем, а результат тот же!
0
Где гарантия того, что ЭТО не окажется очередным «фреймворком», коих уже пруд пруди?

А что не так с фреймвоками? Вы же сами используете Qt, что с ним не так?

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

Я лучше по старинке буду курить отдельные независимые сниппеты и примеры красивого кода

Понимаете, подход «писать все самому» становится совсем не эффективным по мере роста сложности задачи. Написать самому ногодрыг — да, вообще не проблема. Написать файловую систему или, например парсер какго-то формата уже не столь тривиальная задача. А таких задач в рамках одного проекта может быть море, Вы физически не сможете «написать все сам» за обозримое время.

А унификация API (на примере тех же драйверов) – это чудесно, это избавляет от необходимости писать адаптеры, позволяет писать переносимый код, позволяет быстро, в случае необходимости, заменить реализацию компонента…
+1
Вы же сами используете Qt, что с ним не так?
Дак это я Вам должен задать этот вопрос!

Кьют — он что, «очередной»?
Или Вам потроллить хоцца?

Понимаете, подход «писать все самому» становится совсем не эффективным по мере роста сложности задачи.
Понимаете, я это понимаю не хуже Вас. Более того, я считаю, что всё гораздо хуже. В нашу область пришло столько людей, что стало тесно. А если учесть, что ещё и кормовая база стала заметно сокращаться, то всё чаще и чаще становится совсем уж хреново найти источник дохода. Я уж не говорю «вкусный» источник дохода.

Я не знаю, но может уже пора кардинально изменить направление деятельности? Почти все поляны уже вытоптаны. А вновь появившиеся захватываются с такой скоростью, что иногда думаешь, может пора переходить с «ягод» на «фрукты»?
0
Кьют — он что, «очередной»?
Или Вам потроллить хоцца?
Нет, я не тролю. Кьют отличный фрейворк, но он не первый и думаю не последний, что вас смутило в моем вопросе?

 В нашу область пришло столько людей, что стало тесно.

Ну, не знаю, субъективно я не вижу какой-то переполненности на рынке эмбедда, наоборот, по мим наблюдения рынок растет. Сугубо ИМХО.

Но какое это имеет отношение к обсуждаемому вопросу использования библиотек? В этом вопросе более важно то, что сложность устройств и программ в последнее всремя сильно растет, что заставляет переосмысливать старые подходы типа «напишу все сам с нуля», т. к. они банально перестают работать. Аналогично было с ПК — все начиналось с того, что программа сама работала напрямую с периферией, несла в себе свою реализацию всех слоев — от «драйверов» до реализации элементов пользовательского интерфейса. Сейчас никто в задаром уме так писать программы под ПК не станет … По моему мнению — ровно то же самое произойдет и с программированием микроконтроллеров (рано или поздно).
0
Ха! Ну Вы мастер натягивать сову!
Значит, я тебя неправильно понял. ОК, переформулирую то, что хотел сказать:
библиотеки-в-исходниках (или как их правильно называть)
Незачем выделять пункт «в исходниках», middleware — он и есть middleware независимо от формы, хотя предпочтительно, конечно, в форме исходных кодов.
Нафиг мне нужно изучать какие-то сомнительные кодовые «сахара», когда я уже не плохо пишу свои проекты?
Почитай.
Нахрен мне заботится о её целостности, если я точно не буду применять 90% кода из того, что там будет?
Если ты выудил кусок библиотеки и интегрировал в свой проект — конечно, незачем. Но речь-то идет о библиотеке, которую можно подключить как она есть и использовать. И тогда модификации ее придется синхронизировать с обновлениями библиотеки, между проектами и так далее. Все это нежелательно, по этой причине подобные библиотеки должны быть такими, чтобы их можно было использовать такими, какие они есть. Я не зря привел в пример ардуино — никто не правит ее библиотеку, кроме как централизованный выпуск новых версий, ее используют как есть.
Нет, ребята. Вам нужна библиотека — вы её и точите! Я лучше по старинке буду курить отдельные независимые сниппеты и примеры красивого кода, и копипастить их в свои исходники.
Прекрасно. Но о чем тогда ты ведешь дискуссию в этом топике?
0
P.S.
Ой, любите Вы батенька троллить и перходить на личности! Ой, любите!
На данный момент я не троллю, а веду серьезную дискуссию. Хотя, возможно, местами получаются перегибы или недопонимания. Если так — сорри.
0
Однако, засада в том, что у разных производителей разная реализация аналогичных периферийных устройств.
А вот дальше начинается песня! Один микроконтроллер позволяет передавать блоки информации через DMA, а у другого этой функции нет, так нет самого DMA. Один микроконтроллер имеет аппаратную поддержку RS485, а у другого эту функциональность нужно реализовывать программно. К стати, RS485 — это не такой уж и экзотический канал передачи данных!
Хотим мы этого или нет, но в целях упрощения работы с драйвером нам так или иначе придется ОТКИНУТЬ ФУНКЦИОНАЛЬНОСТЬ.

Но ведь можно это все оставить в реализации драйвера. Есть DMA — будет работать через DMA, нету — значит по-другому будет работать. То есть в зависимости от чипа драйвер будет либо использовать аппаратную реализацию, либо программную.
Или повесить это на плечи пользователя:
if(Usart.DmaSupport)
{
    usart1.initDma();
}
else
{
    usart1.initDefault();
}
+2
В С++ для этого можно использовать частичную специализацию шаблонов.
0
То есть, Вы хотите сказать, что мы должны в драйвер заложить избыточность кода?
0
мы должны
Было бы здорово, если бы не МЫ, а производитель МК это делал.
заложить избыточность кода?
А почему бы и нет, если это возможно обеспечит хорошую переносимость кода между разными МК? Да и многие вещи могут делаться препроцессором или шаблонами или как там оно еще бывает.
0
Таким образом, получается для того, чтобы мы могли создать универсальный драйвер, мы должны ПРИНЕСТИ В ЖЕРТВУ уникальные функциональные возможности микроконтроллеров.


А кто говорит о универсальном драйвере? Драйвер — он на то и драйвер, он специфический под каждую платформу и скрывает особенности платформы. Нужно только, чтобы программный интерфейс драйверов был унифицирован. А с этим особый проблем нет, можно, например, пойти путем Юникса open() close() read() write() и ioctl() для специфических вызовов. Можно сделать API разным для разных типов устройств.
+2
микроконтроллер имеет аппаратную поддержку RS485

Вроде бы RS-485 (как и RS-232) — это просто стандарт физического уровня для USART: какой приемопередатчик будет на выходе стандартного USART порта — такой и будет физ.интерфейс.

Я же уже давал ссылку на описание USART драйвера в стандарте CMSIS-Driver. У кого нет KEIL MDK 5, software_packs для него можно скачать здесь. Например, «STMicroelectronics STM32F1 Series Device Support, Drivers and Examples» (Keil.STM32F1xx_DFP.2.1.0.pack) — это обычный zip-архив, и посмотреть там конкретную реализацию USART драйвера в папке RTE_Driver.

Реализован он только поверх CMSIS:
#include "stm32f10x.h"

Т.е. все закодировано на_ручнике, а-ля Snippets.

Гы-ы :D, хотя тот же драйвер в pack'е для STM32F4, реализован через прослойку пресловутой новой либы HAL от ST:
#include "stm32f4xx_hal.h"

Ну вот и надо дать свое КОНКРЕТНОЕ заключение по этому КОНКРЕТНОМУ софту и стандарту: чего он такого не выполняет, чего якобы бывает нужно, чего там не хватает и что там якобы не застандартизировано и не реализовано.

P/S Советую посмотреть там же и драйвер GPIO — мне лично очень понравилось: всего по страничке чистого кода в каждом файле, горсть заинлайненных коротеньких:
GPIO_PinWrite
GPIO_PinRead
GPIO_PortWrite
GPIO_PortRead

+ горсть небольших функций для инициализации порта:
GPIO_PortClock
GPIO_GetPortClockState
GPIO_PinConfigure
GPIO_AFConfigure

Опять же, весь это регистровый Snippet код сделан только поверх CMSIS:
#include "stm32f10x.h"
0
Хуета какая-то минусанула — подленько так, мразь, — без объяснения причин. Но вот эти-то минусики в моих тех.постах меня взбесили люто.

Какая к хуям тогда здесь может быть техн.дискуссия? e_mc2 тогда плакался: хнык-хнык, наше тех.сообщество умирает.

Горсть ПЖ и «гуру» перетирают то, какие они вумные а-ля «Я прикладник в первую очередь, использовать и курить чужие библиотеки — дело привычное» (А в SPL/HAL ты хотя бы заглядывал? SPL уже больше 6 лет, а HAL больше 2-х — с такими-то «талантами», ты должен знать их наизусть, не говоря уже про пару дюжин проектов с их использованием) или «Могу только предложить подтянуть программирование и не нести чушь».

А так же выдают, как КО, разного рода вумные напутствия и банальности а-ля «Бороться со сложностью можно (и нужно) повышением уровня абстракции» или «Описанное скорее относится к событийно-ориентированному программированию, которое к ООП довольно мало отношения имеет» и т.п. потоки словесной воды. Без всякой привязки к конкретике: к конкретным либам (в которые они уже давно и не заглядывали), коду и т.д.
0
Но вот эти-то минусики в моих тех.постах меня взбесили люто.
Видимо, кто-то считает, что ты несешь чушь.
Какая к хуям тогда здесь может быть техн.дискуссия?
Техническая дискуссия? С тобой? Лол.
Без всякой привязки к конкретике: к конкретным либам (в которые они уже давно и не заглядывали), коду и т.д.
Конкретика — это «решите за меня, какие мне лучше библиотеки юзать»? С этим туда же, куда и с запросами «напишите мне код».
0
Техническая дискуссия? С тобой? Лол

Ну не с тобой же? :DDD

С тобой не о чем разговаривать, т.к. ты кроме банальностей больше ничего и не знаешь (о чем уже выше и написано). Ну еще клавы и мышки можно обсудить :DDD
-2
Я же в техн.темах — очень скромный и внимательно слушающий человек (ну твою вумную чушь и болтовню я обычно быстро пробегаю глазами и даже уже и не помню через 5 минут). Не зная более-менее техн.деталей чего-то — я обычно ничего не пишу и не спорю на эти темы — зачем толочь воду в ступе и сыпать банальностями. И я никогда себе не позволял сентенций, типа: «Могу только предложить подтянуть Вам программирование и не нести чушь», т.е. не раздувался на пустом месте :DDD

Ну special_topics (на свободные темы), конечно не в счет, там ты уже давно со мной стараешься не сталкиваться, Гы-ы ЖD

P/S Люди поговаривают, что ты тут на админке сидеть подрядился (вырос — забурел Ж). Так вот и скажи-ка мне: кто это минусует мои посты в этой теме?
-1
И я никогда себе не позволял сентенций, типа: «Могу только предложить подтянуть Вам программирование и не нести чушь», т.е. не раздувался на пустом месте :DDD
Какая хорошая иллюстрация поговорки про бревно и соринку.
Ну special_topics (на свободные темы), конечно не в счет, там ты уже давно со мной стараешься не сталкиваться, Гы-ы ЖD
В отличие от некоторых, я предпочитаю следовать поговорке «не тронь говно — оно не завоняет». С другой стороны, иногда хватает одной фразы, чтобы получить с тебя целую веточку лулзов.
P/S Люди поговаривают, что ты тут на админке сидеть подрядился (вырос — забурел Ж). Так вот и скажи-ка мне: кто это минусует мои посты в этой теме?
Понятия не имею. Ну кроме последних трех, с выпадами в мой адрес, которые я проминусовал лично.
0
Вот наблюдаю все, как ты все больше и больше разбухаешь здесь, и поэтому, вот все хочу у тебя, VGA, спросить: У тебя видимо амбициозные планы?

не тронь говно — оно не завоняет

Ладно, не буду уже тебя трогать здесь, в этой, так называемой, техн.теме :D
0
Конкретика — это «решите за меня, какие мне лучше библиотеки юзать»? С этим туда же, куда и с запросами «напишите мне код».

Тю-тю-тю, и кто это говорит? А говорит это главный выклянчиватель кода здесь: А покажи как ты это сделал, можно взглянуть на алгоритм, дай исходники посмотреть? И это все под видом — мы же все здесь (в инторнете) на ты и камрады/«коллеги» + open_source там.
0
Между любопытством «как это сделано?» и «мне насрать на программирование, напишите за меня мой курсовой» есть некоторая разница. Хотя представители второго пункта этого могут и не понимать.
+2
evsi недавно высокопарно высказал мне что-то типа: Вы, своими сержантскими шуточками и солдафонским сленгом постоянно, даже уже не замечая этого за собой, каждый раз глубоко оскорбляете нас — ПРОГРАММИСТОВ! :DDD
-2
У вас очень неплохо получается видеть в словах опонента то, чего вам там сильно хочется увидеть, а не то, что там есть на самом деле. Моя фраза была такой «Я, конечно, понимаю, что вы сильно-пресильно верите, что этим сможете зацепить меня и других программистов, но по факту это не работает.» Как говорится, найдите десять отличий от того, что прочитали в ней вы.
+1
Хуета какая-то минусанула — подленько так, мразь, — без объяснения причин. Но вот эти-то минусики в моих тех.постах меня взбесили люто.
На эту тему есть замечательный анекдот:
«Боцман вышел на палубу, потянулся и воскликнул:
— Какое замечательное утро!
— Мать… Мать… Мать… — привычно откликнулось эхо.»

P.S. насчет банальностей вы правы, это действительно они самые. тем более удивительно, что это приходится озвучивать технически грамотным людям, которые уж чего-чего, но это должны понимать сами.
P.P.S. «потоки словесной воды» на самом деле содержат много информации для тех, кто в теме. расписывать детали не всегда есть время и, тем более, желание.
+1
Но вот эти-то минусики в моих тех.постах меня взбесили люто.
Я сейчас конечно скажу вещь банальную и не свою (из Пушкина)
Они в самом тебе. Ты сам свой высший суд;
Всех строже оценить умеешь ты свой труд.
Зачем вы обращаете внимание на чужие оценки вас? Вы не уверены в себе и вам нужно чужое одобрение?
С этим надо бороться.

Теперь про программистов и железячников. К сожалению все матерые программисты которых я знавал ни черта не понимают в железе. И наоборот электронщики ни черта не понимают в программировании. Лично мне повезло с самого начала балансировать посередине так, что я ни в том ни в другом ничего не понимаю. Но при этом прекрасно понимаю, что все страдания железячников о сложностях в программирования от их малограмотности. И все их проблемы как минимум надуманы (проведите опрос о сложностях в копании в чужом коде, 9 из 10 будут железячниками). В программировании уже давно подход такой, что пишутся не программы, а языки программирования для решения конкретных задач (откройте и посмотрите сколько языков появилось за последнее десятилетие). Основная причина в том что настоящие программисты умеют программировать сложные вещи типа синтаксических анализаторов, интерпретаторов и компиляторов и много других вкусных вещей. То есть могут по-быстрому выстругать себе подходящую палку-копалку для решения своих задач.
Железячники могут только «соплю» на выводы навесить, чтобы лишний раз не компелять. А инструментарий у них всегда с чужого плеча. Выдали им готовую среду программирования в которой они научились нажимать кнопочки и все. Вот они в рамках этой среды и пырхаются. Особо упорные продолжают любить асм, кто-то по-продвинутей уже сишечку осилил. Есть конечно и те которые начинают догадываться, что мир чуть богаче и уже шаблоны из «крестов» подтягивают. Но кто-то где-то видел чтобы железячник запилил свою свою среду, свой язык? Я вот не знаю таких. А получается что? Выдали вам стамеску и рубанок вы им и дрова рубите и подстригаетесь.
Только не подумайте, что я как-то хочу обидеть железячников. Просто делать новые электронные сущности вы могете, а вот программные в основной своей массе уже нет.
+2
Лично мне повезло с самого начала балансировать посередине так, что я ни в том ни в другом ничего не понимаю.
Позвольте примазаться к Вашей славе!
А а ещё испачкался Питоном — на Питоне начал стругать себе разные утилитки для работы с проектами и для работы с микроконтроллерами через последовательный порт.

Все делаю не по правилам корифеев, и везде нещадно бьют. Но с другой стороны — у меня всё танцует и поёт так, как мне надо.
0
Но с другой стороны — у меня всё танцует и поёт так, как мне надо.
Почитай про «парадокс Блаба».
0
Примазаться не разрешаю :)
А а ещё испачкался Питоном
Тонкий наброс на тему писькомерки :) Одобряю! Но меряться не буду (у меня все равно толще).
Это же замечательно, что у вас все танцует и поет. Только тогда не понятно в чем тогда спор? Вы хотите нас убедить, что асма и битов хватит всем (утрирую конечно, но вы меня поняли)? В противном случае не вижу предмета спора.
0
Тонкий наброс на тему писькомерки
Та, не-е! Какой-там!!! Наоборот — хныкаю, что написав очердную утилитку и опубликовав её у себя в блоге, тут же получаю по мордасе от питонитста хоккейной клюшкой. И ведь, что су-а характерно! (с) — понимаю, что мой код — это что самый ни на есть настоящий говнокод. А человек, который прислал свою версию, меня учит правильному написанию питоновского кода. И я ему, не смотря на такой хлопок по морде, благодарен за науку!

А что насчет «всё танцует и поёт» — ну, это в том смысле, что если для работы или для отладки не хватает какого-то инструмента (ну, допустим, некоторой программы, которая бы периодически отправляла в последовательный порт команды, получала ответы, и выполняла бы кое-какую нештатную (с точки зрения стандартных программ-терминалов) работу) — всё это делается из говна и палок и ещё какого-то змия типа Питон. Получается некая табуретка, которая позволяет отлажывать и тестировать МК-устройство. Но, то есть, я использую Питон как станок для создания некудишной оснастки для производства основного вида продукции. Быстро, дешево, некачечественно. Последнее — пофигу, так как это внутренний продукт. Не на продажу! Красить и вешать бантики — не имеет смысла.

Как-то так…

Нахрен, этот форум! На улице — солнышко!
0
Нахрен, этот форум! На улице — солнышко!
Вот, стоящий комментарий, остальное мышиная возня.
0
какая-то минусанула — подленько так, мразь
Дак таких мелкосерущих под дверь на каждом форуме полно. Они ни на что другое не способны, кроме как тайком мелко гадить. Не обращайте внимание!

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

В 2011-от у меня как-то был печальный опыт общения на Казусе. Тема была об использовании Линукса. Тема актуальная и интересная. Разговор мог бы получиться содержательным и полезным. Впрочем, местами он таковым и становился. Но временами появлялся неадекватный товарищ st_1 и разворачивал учинял балаган. Короче, достал он меня своими выходками. Какое-то время я его, конечно, терпел, но потом как-то стало особенно понятно, что мне здесь делать нечего. С моей точки зрения тут собрались люд, которые не приемлют Линукс ни в какой форме. С их точки зрения, я — чужой. Нафига я буду на них тратить свое время и нервы? Я просто перестал заходить на этот форум и общаться.

Я что-то потерал? — Да, нет! Скорее, даже приобрел. У меня высвободилось время, меня перестали мучить мысли о собственной неполноценности. Я начал чувствовать себя намного лучше, увереннее.

Так что мой Вам совет — не ходите туда, где вас не уважают.

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

Это, как говорит Савельев (погуглите это имя! Есть чему поучиться!), нормальное явление, прёт нормальная биологическая сущность — жрать, размножаться, доминировать. Первые две цели на форуме осуществлять невозможно. А вот доминирование… — вот оно! Вы думаете, здесь ведутся деловые разговоры? Да здесь, как и везде, одни бабуины стремятся подмять под себя других бабуинов. Ничего нового или удивительного.

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

Ну ща начнется! Щас я о себе такое узнаю… Понеслась!
0
Тем боле и Вам и мне этого хочется.
Вообще-то я пришел «набросить» и немного подразнить любителей «заката солнце в ручную». Без злобы, просто ради всеобщего веселья. Судя по последующим простыням, «наброс» оказался очень в тему.
Таким образом, получается для того, чтобы мы могли создать универсальный драйвер, мы должны ПРИНЕСТИ В ЖЕРТВУ уникальные функциональные возможности микроконтроллеров. То есть это то, о чём я говорил ещё в самом начале дискуссии. Хотим мы этого или нет, но в целях упрощения работы с драйвером нам так или иначе придется ОТКИНУТЬ ФУНКЦИОНАЛЬНОСТЬ.
Все вы верно говорите, но вот начиная отсюда скатываетесь совершенно не туда. Что мешает сделать универсальный драйвер под определенные задачи (за счет тоненькой прослойки под конкретное железо) для реализации базового функционала. При этом сохранить крутилочки для тонкой манипуляции битами? Что же вы все такие монохромные и замкнутые в рамках асма, сишечки и готового железа!
Согласен, что задача не совсем тривиальная. Уверен, что существующие программные аппаратные решения не совсем подходят под такую идеологию. Но что мешает придумать свой язык для естественного описания под него придумать подходящий аппаратный интерфейс и все это слить в эмбедерском экстазе.
В противном случае, наш драйвер будет утяжелён спецификациями, учитывающими тот, другой, третий… микроконтроллер.
я же не зря привел пример линукса и BSP. Ядро вообще ничего не знает про железо! Надо тебе запилить поддержку конкретного образца. Пишешь низкоуровневую прослойку которая для абстрактного ядра реализует все необходимые вызовы и все.
Возможно, я чего-то не понимаю… Но на этот раз я пытаюсь с Вами вести серьезный диалог.
Просто вы пытаетесь мыслить в рамках того, что вам хорошо известно. Попробуйте выйти за эти рамки, попробуйте придумать такую гипотетическую архитектуру, чтобы стандартные вещи писались в три строки, при этом можно было сделать что-то очень экзотическое.
мы тут собрались не письками меряться,
Именно ими и меримся. Кто кого перекудахчет. Почему именно так? Потому что ни вы ни я кроме как ничего кроме упражнения в красноречии делать не будет. Мне в ломы, вы «чего-то не понимаю», Досикуса и так все устраивает :)
Так что конечно по-общаемся, но без супер серьезности. Жить все такие надо веселей.
+2
Что мешает сделать универсальный драйвер...
Но что мешает придумать свой язык для…
Нехватка свободных ресурсов. Недостаток личного времени. Отсутствие команды единомышленников. Недостаточность желания, мотивации. Отсутствие нужных знания того, понимать _ЧТО_ДЕЙСТВИТЕЛЬНО_ нужно делать, в отличие от того, что _Я_ХОЧУ_ это сделать.
Ну и наверно самый большой демотиватор — «А кому это всё надо? Для кого я буду упираться рогом и тратить своё здоровье? Ради вот этих быдло-кодеров что-ли? Для себя любимого я уже написал то, что мне надо. Остальные — как хотите!» Ну, вот как-то так, наверно.
0
Для себя любимого я уже написал то, что мне надо.
Правильнее сказать «то, что мог». Просто потому, что иначе ты бы счел проще запилить DSL и решить проблему раз и насовсем, а не тратить чуть меньшее время на решение ее в каждом проекте заново (примерно как в топике про прошивку стиралки — мона потратить 300грн на прошивку, а можно 400 на программатор).
Так что то, что реально мешает — это все тот же «парадокс Блаба».
0
1. Про прошивку стиралки.
Ну это известная тема. И мне она тоже ничуть не чужда. Я, правда, точно так же поступил не со стиралкой, а с «утюгом» для варки труб ГВС/ХВС. Лет пять назад, когда мы пришли к пониманию, что было бы не худо поменять водопровод у себя в квартире, тоже пришлось поиметь дело с «научными сотрудниками» по прокладке пластиковых труб. Каких только баек-пужалок я от них не наслушался, а потом бац — сгорел предохранитель. А не фиг было цену за свои труды назначать соизмеримую со стоимостью «утюга». Жену, правда, пришлось несколько уламывать. Не верила, что не боги трубы тоже паяют… Купил, потренировался, сделал себе шедевр. Нафотал, разместил у себя в блоге. Прошло много лет, но народ до сих пор с «дретуна» (сатик есть такой) приходят. Изучают. Да мне и не жалко!

Так что инструмент всегда окупится в умелых руках. Будь то утюг, программатор или ещё что.

2. Погулил я по «парадоксу». Нагуглил статью Пола Грэхама. Проситал. К стати, спасибо за пинок в нужном направлении!

Такое ощущение, что я её уже когда-то давно читал. По крайней мере в статье раз пять встретил очень яркие, хорошо запоминающиеся словосочетания. Хотя в целом (о чём статья) — я так и не смог вспомнить по ходу её чтения. (Это ещё одно доказательство, что мозг всё-таки очищается от неиспользуемой информации.)

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

Теперь скажу пару слов по статье. Да, статья нужна и полезная. Но её нельзя и даже вредно понимать буквально. Что я имею ввиду?

Прежде всего нельзя копировать мир США, а тем более уникальный мир Силиконовой долины, на России. Россия — это несколько другая страна, чем Соединеннёные штаты. В России несколько другой менталитет, другие производственные отношения (между работодателем и наёмными работниками, между бизнес-партнёроами) и другое отношение потребителей к производителю. Другие культурные и духовные ценности. В России до конца еще пор не выхолощено презрение к легко-заработанным деньгам. В России всё ещё отрицательно относятся к резко разбогатевшим людям, хотя каждый внутренне завидует таким. Ну, Не везде, конечно, так! Чтобы не разжигать путую дискуссию, давайте, я вернусь к своему посылу: Россия — не Америка.

Во вторых. Как вы заметили эссе Пола написано для эпохи дот-комов. В Россию эпоха вэб-строительства, конечно, тоже пришла, но по моим оценка она какая-то относительно вялая против Штатовской. У нас не было столько пузырей, как там.

В третьих. Все описанное в эссе более относится к теме вэба, чем к теме микроконтроллеров. Это в вэбе нужно бегом-бегом успевать захватывать аудиторию. А в микроконтроллерах одним программированием не обойдёшься. Для микроконтроллеров нужно еще как минимум уметь быстро модифицировать железо (опаники! Вот это неожиданность!). Кроме того, ажиотаж среди «микроконтроллерных» применений сдерживает сам процесс производства оных. Это в области вэба можно посидеть пару часов с кодом и тут же вывалить в продакшин. И люди его мгновенно начнут потреблять. (Эхо, мочать!!!) А для МК-девайсов такая спешка нафиг не нужна! Причины я назвал чуть выше.

Но статья хорошая. Спасибо! Вот, только слепо следовать её призывам вредно. Не применима она в нашей епархии. Другое у нас. И время, и люди, и само производство.
0
1. Про прошивку стиралки.
Ты меня не совсем понял. Это была иллюстрация к вопросу «решать задачу каждый раз, когда она возникает, тратя N ресурсов, против решить задачу раз и навсегда, затратив чуть больше ресурсов».
2. Погулил я по «парадоксу». Нагуглил статью Пола Грэхама. Проситал.
Статью ты нашел правильно. Но выводы… Она не о доткомах и не о силиконовой долине. Она о языках программирования и о том психологическом барьере, который мешает использовать самый мощный инструмент (парадокс Блаба, да). Ну и еще о том, что Лисп круче всех, но это же Грэм (к тому же, он, вероятно, прав).
А для МК-девайсов такая спешка нафиг не нужна! Причины я назвал чуть выше.
Специалисты из NASA JPL рассказывали о том, как полезен LISP в роли языка для написания прошивки космического аппарата. А это самый что ни на есть эмбед.
0
Специалисты из NASA JPL рассказывали о том, как полезен LISP в роли языка для написания прошивки космического аппарата
А также о том, кстати, как менеджеры это направление задавили в пользу мейнстрима. Прямо как писал Грэм:
Если вы работаете в большой компании, это может быть не так просто. Вам будет трудно убедить своего косного босса позволить вам программировать на Lisp'е, особенно если тот только что прочитал в газете о каком-то языке, который, как и Ада двадцать лет тому назад, готов завоевать мир.
0
Зато покудахтали знатно :)
Ради вот этих быдло-кодеров что-ли
То есть вы признаете труд только ради чего-то (успеха, денег, признания). Труд сам по себе в собственное удовольствие вы не признаете? Грустно наверно так жить.
Мотивация должны быть внутри, а не снаружи.
+2
Труд сам по себе в собственное удовольствие вы не признаете?
Да, почему же! С чего Вы это взяли?

Мотивация должны быть и точка!
К сожалению, чаще бывает, что без должной подпитки извне внутренние мотивации испаряются быстрее, чем проект доходит до завершающей стадии.
0
Великолепное обсуждение, просто приятно читать, спасибо! andi123
Выдали вам стамеску и рубанок вы им и дрова рубите и подстригаетесь.
ну это не бровь, а в глаз)))))))
Лично я все же склоняюсь к мнению г-на профессора) Вообще не кажется ли вам, что что дискуссия напоминает спор — условно — автогонщика и автослесаря, каждый хорош на своем месте и каждый если знает не только свою работу, уже очень неплохо, но спорить что лучше — правильно ездить или лучше регулировать двигатель просто некорректно)
-1
дискуссия напоминает спор — условно — автогонщика и автослесаря,
Абсолютно!
0
к мнению г-на профессора
это кто такой?
искуссия напоминает спор — условно — автогонщика и автослесаря
Любая дискуссия, что-то напоминает (все эти споры уже очень давно и неоднократно проспорены). Если вам знакомы история, философия и культурология можно даже прикинуть кто и когда зафиксировал в тексте первый такой спор.
Ответ, тут как всегда прост, нужно правильно ездить на отрегулированном двигателе. Переложить это в канву нашей темы предлагаю самостоятельно.
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.