Notice: Memcache::get(): Server localhost (tcp 11211) failed with: Connection refused (111) in /home/a146/www/we.easyelectronics.ru/engine/lib/external/DklabCache/Zend/Cache/Backend/Memcached.php on line 134
STM32 Peripheral Libs: FWLib -> SPL -> Middleware+HAL+CubeMX -> Middleware+Snippets -> CMSIS-Driver API ? Куда это все ведет и есть ли истинный путь? / Блог им. well-man2000 / Сообщество EasyElectronics.ru

STM32 Peripheral Libs: FWLib -> SPL -> Middleware+HAL+CubeMX -> Middleware+Snippets -> CMSIS-Driver API ? Куда это все ведет и есть ли истинный путь?

СТАТЬЯ НА НЕБОЛЬШОЙ ПЕРЕДЕЛКЕ — НАДО КОЕ-ЧТО ДОБАВИТЬ И ПРИЧЕСАТЬ.

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

RSS свернуть / развернуть
Вы использовали на практике эту Кейловскую либу CMSIS? Поделитесь вашим конкретным опытом. Это было бы гораздо интереснейи полезней, чем софистика на тему куда зашли разработчики со своими разработками. Но всё равно спасибо. Я не слышал про эту либу — присмотрюсь к ней.
0
Посмотрел пока Gpio и их использование в CMSIS-RTOS Blinky проекте. Если отбросить якобы платформонезависимость, и смотреть в сухом остатке, что библиотека даёт при разработаке под конкретный МК, то мало чего она даёт. Уровень абстракций отсутствует как и в SPL. Если я в своей либе выкину использование SPL (ума не приложу что ж многим так свербит эта SPL — никто конкретного ответа ни разу не дал, только ноют растекаясь мыслЯми по древу) и заменю его на работу с регистрами, то она будет окончательно на голову выше этой кейловсеой. Повторюсь это касается GPIO. Ещё немного глянул CAN — там такая же байда, нет конкретных абстракций. Отличий от SPL практически нет.
0
никто конкретного ответа ни разу не дал
Ответ был и не раз. Другое дело, что прочитать его внимательно не каждый удосужится.
0
Единственно о чём вы говорили в комментариях к моим статьям: «SPL — это не библиотека, а адаптер». Ещё говорите про какие-то мифические сложно выловимые ошибки без конкретики, но такое всерьёз лично я не воспринимаю. Вот и всё что есть в обвинение SPL в комментариях к моим статьям. Как-то негусто. Так что
никто конкретного ответа ни разу не дал
в силе
0
Я же говорил, что вы не удосужились прочитать внимательно. Да, это адаптер и он привносит дополнительный код не изменяя функциональности. Как следствие, вы имеете дополнительный оверхед и увеличиваете размер кода не получая ничего взамен. Это более чем достаточная причина, что бы не пользоваться SPL.
0
Я с этим согласен. Но на мой взгляд это не столь критичная проблема. Зачем бросаться-то в крайности? Так можно и от С/С++ отказаться в пользу аsm. Лично я оставил подложку SPL для быстрой реализации неординарных ситуаций, на которые не расчитана моя либа (лично для меня c SPL работается быстрее чем с регистрами, собственно STM и разошлись как горячие пирожки именно благодаря ей вкупе с жирной перифферией под её управлением). Избавление от SPL в библиотеке я рассматриваю, но на мой взгляд пока рано.
0
Кому как. С моей точки зрения SPL существенно менее удобна, плюс является потенциальным новым источником ошибок связанных с неинициализированными полями в структурах.
0
За несколько лет не встретил ни одной такой ошибки. Переработал практически со всей периферией.
0
Вы еще скажите, что всегда все поля инициализировали. Даже с опытными С-шниками время от времени эта фигня случается.
0
В смысле все поля структуры передающейся в функцию инициализации? Да, абсолютно все. Я копирую определение структуры в свой модуль и на базе этого определяю значения всех полей.
0
И в итоге получаете нечитаемую портянку, которую, к тому же, легко испортить в процессе редактирования. И «на глаз» эту ошибку не выловить. И то, что абсолютно вся работа с периферией постоянно дублируется (ваш код инициализирует структуру, а затем SPL переносит ровно эти же данные в регистры), судя по всему, вас совершенно не смущает. Как и то, что этот код никак не инлайнится и не оптимизируется.
0
Инициализация происходит один раз при включении, так что оптимизация инициализации — это уж совсем придирка. У вас переходные процессы по питанию будут дольше проходить чем инициализируется вся периферия. В том то и дело, что эта портянка у меня зашита в мой модуль который даёт удобную абстракцию. И на глаз ошибку выловить гораздо легче при использовании SPL, нежели регистров.
0
Разве я написал «инициализация»? Вообще вся работа с периферией через SPL (а это вовсе не только инициализация) дает такой оверхед.
И на глаз ошибку выловить гораздо легче при использовании SPL, нежели регистров.
Без SPL некоторые ошибки просто не могут возникнуть, вот в чем проблема. И то, что вы натренировались бороться с граблями SPL вовсе не значит, что этих грабель там нет. Наоборот, это свидетельство того, что они там есть изначально. Замечу, что я не сравниваю SPL с работой с регистрами напрямую. То, что при работе напрямую можно ошибиться это тоже понятно. Я просто считаю, что SPL не снижает вероятность ошибки, а всего лишь меняет то, какого плана ошибки более вероятны.
0
Я не натренеровался с ними бороться. Я просто их не встречал. Я просто работаю и работаю с SPL и проблем в принципе нет. Вы можете превести конкретный пример грабли?
0
Вы же сами написали:
Я копирую определение структуры в свой модуль и на базе этого определяю значения всех полей.
Вот вам пример граблей и пример того, что вы именно натренировались с ними бороться. Даже если вы так это не воспринимаете и вам кажется, что все в порядке.
0
Так я сделал это только раз. И теперь всё это инкапсулировано в мою оболочку и больше я этого не делаю.
0
Как вы могли заметить, речь не о вашей оболочке (которая хороша уже хотя бы потому, что реально повышает уровень абстракции), а об SPL и претензиях к ней. Надеюсь, после этого обсуждения вам стало понятнее, в чем суть претензий к ней?
0
Я понимаю эту претензию. Как я уже говорил в будущем вырезать SPL есть мысли. Но пока пусть будет. Пока мне с ней удобней.
0
SPL ускоряет включение чего-то нового.
0
Где сказано что инициализация происходит только один раз?
0
в spl есть специально обученные функции для инициализации структур.
0
И что? Это ищбавляет от оверхеда? Иои уменьшает вероятность ошибок?
0
ответ был на комментарий
Вы еще скажите, что всегда все поля инициализировали. Даже с опытными С-шниками время от времени эта фигня случается.
0
И что? Даже специально обученную функцию надо не забыть вызвать.
0
искать способы сломать себе ногу? уверен что смогу найти такой способ при любом подходе.
0
Нет, это обычная человеческая невнимательность.
0
то есть единственный вариант — значения по-умолчанию? однако это не исключает возможности по той же невнимательности забыть определить нужный параметр.
0
Конечно. Это еще одна причина считать SPL ненужным адаптером.
0
Вы использовали на практике эту Кейловскую либу CMSIS?

API интерфейс CMSIS-Driver, предложенный ARM, реализовал KEIL (т.к. это подразделение ARM по разработке инструментального ПО) для NXP LPC1700/1800, STM32F1/F4 и SiLabs EFM32 Giant Geko(пока только DMA/SPI/USB) в своих software_pacs для MDK 5 — посмотри там в папочках RTE_Driver или CMSIS\Driver для этих чипов. Для TI TM4C пока нет, другие чипы не смотрел.
0
Ответ так себе. То есть вы не использовали но рекомендуете? Посмотрел я всё это. Ну и оно как-то не очень.
0
Посмотрел я всё это. Ну и оно как-то не очень.

Ответ так себе в квадрате.

Что Вы там посмотрели? Что Вам не понравилось конкретно и в каких драйверах? Не понравилась реализация функционала самого API, предложенного ARM, его уровень абстракций (как любит говаривать evsi), конкретная реализация KEIL'ом функций этого API для конкретного MCU? Ну вот почему не взять допустим LPC1700 и STM32F1 в MDK software_packs и сказать, что конкретно не понравилось в драйверах USART, например (в функциях USART_Initialize, USART_Receive, USART_Send, USART_Transfer и т.д.)?

P/S
Ваша самопальная прослойка (подобного в СЕТИ много энтузиасты наваяли) НЕ НУЖНА никому (хотя бы потому что другие или тоже считает себя умнее остальных и будут юзать свой велосипед, или же они к нему уже привыкли и он им удобнее), тем паче над SPL, которая в свою очередь УЖЕ никому не нужна (кроме поддержки old projects), получается: все это НЕ НУЖНО никому В КВАДРАТЕ.
0
 что конкретно не понравилось вдрайверах USART

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

osSignalSet(tid_myUART_Thread, 0x01); 
USARTdrv->Control (ARM_USART_CONTROL_TX, 1);


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

if (version.api < 0x200) /* requires at minimum API version 2.00 or higher */
{ /* error handling */
return;
}


Хотя саму идею стандартизации «драйверов» я поддерживаю двумя руками.
+2
Это все мелочи, там по ссылке просто examples. Более важны мнения об реализации самого интерфейса API, предложенного ARM, о его элементах и механизмах абстракции.

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

Создание таких абстракций для сферической и более-менее универсальной периферии MCU — это не дело каких-то кодеров с завышенным энтузиазмом или ЧСВ и каких-то дней или недель. Это достаточно капитальный и сложный труд, достойный кандидатского диссера для отдельного человека или же непростая аналитическая работа, выполненная неким коллективом настоящих профи.

Мне, как ремесленнику и человеку среднего ума, просто некогда велосипедировать, да и не охото этим заниматься, и хочется все же положиться на готовое решение этой проблемы от кого-то более-менее солидного и знающего, т.е., например, от ARM. Но окончательное заключение будет все же от мирового сообщества MCU-кодеров и всей индустрии. Т.е. будут юзать это API, станет оно популярным, как FATFs или FreeRTOS, или нет? Но какие-то предварительные заключения все же хотелось бы узнать. Т.к. давно уже хочется иметь какую-то более-менее твердую почву под ногами, и не забивать каждый раз башку очередными Periph Libs от очередного производителя или каждый раз ползать по новому очередному мегахедеру и кодировать на_ручнике.

ARM, по сути, предлагает только готовый и продуманный его спецами стандартный name_space и структуры (т.е. хедеры) + пустые шаблоны файлов.с с прототипами функций API. То, что внутри этих функций, должны уже реализовывать для конкретных семейств MCU эти самые кодеры-регистрщики, юзая name_space CMSIS и свои Snippets.

Вот и произошло совершенно мирное разделение двух непримиримых группировок — «дебилы» библиотечники будут ваять реализацию Application, а регистрщики-даташисты с удовольствием будут работать со своими любимыми битами и ваять конкретную железную реализацию драйверов. Что, кстати, не мешает никому соединить эти две ипостаси в одном лице.
0
Когда вы отфильтровали самокопание и начали писать по делу, это стало вполне можно читать. Что же до либ, то есть куда более перспективный путь, хотя он и не лежит в плоскости очередного HAL от конкретного производителя. Я имею в виду вот эту либу: github.com/andysworkshop/stm32plus
Кстати, сам Andy Brown (автор либы) ведет весьма интересный сайт andybrown.me.uk/
+3
Другие производители ARM Cortex-M MCU тоже сейчас ведут активный поиск решений выхода из этого софтового тупика, образовавшегося в пространстве между middleware/user_application и этим просто чудовищным хидером – мегапортянкой, описывающей всю эту резко разбухшую и усложнившуюся периферию чипов.


ИМХО, проблема не в этом месте. Портянка большая, но она не сильно разрастается, т.к. список и функционал периферии уже достаточно давно устаканился (разве что раньше часть периферии, типа USB, присутствовала только в топовых чипах, а теперь ее пихают в более бюджетные чипы). Да и вообще работа с периферией – относительно тривиальная вещь (код там примитивный, локализированный в одном месте, как правило, есть примеры или готовые библиотеки от производителей).

Проблема как раз в middleware, вернее в том, что раньше производители вообще здесь ничего не предлагали. Допустим у нас есть заказчик, который хочет, чтобы девайс подключался по USB и конфигурировался из браузера (вполне обычные современные требования). Значит, нам нужно реализовать RNDIS, потом сетевой стек, потом простенькую отвечалку HTTP. И вот здесь (по крайней мере раньше — точно) производитель нам ничего не предлагал (ну разве, что низкий уровень USB, в лучшем случае – пример какого-нибудь USB HID или CDC ). По сравнению с RNDIS и TCP/IP – работа непосредственно с периферией – это мелочи жизни. Плюс такие вещи как, например, RNDIS тяжело отлаживать ибо есть свои нюансы на стороне ПК (разные ОС и т. д.).

Дык вот, по моим наблюдениям многие производители в последнее время задумались о middleware. Библиотеками уровня SPL сейчас никого не удивишь и не заманишь, а вот готовая из коробки прослойка middleware – это уже интересно.
+2
Давайте будем честны: железячники не умеют в программирование. Я по основной профессии — программист, и я могу сказать, что всё, что выходит из рук железных компаний — лютое говно. Все библиотеки, драйвера (которые выкладываются с исходниками), халы-шмалы — это кровавые слёзы, когда видишь, это код, написанный программистами с уровнем культуры разработки уровня пхп-фрилансеров по 5 долларов за час. Возможно, есть исключения, но я пока не видел. А я и перепиливал драйвера под FreeBSD и пользовался микроконтроллерными библиотеками от производителя и читал семплы от всяких прозиводителей радиомодемов — везде одно и то же. Неаккуратный, неряшливый, тяп-ляп, написанный код. Даже когда он работает — читать а, тем более, расширять его — неприятно, как выгребать сельский нужник руками. Работа возможная и иногда нужная, но не хочется.

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

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

Поэтому, мне кажется, и все эти метания.
+3
Всё именно так. Я это и пытаюсь от этого уйти в своих библиотеках. В них всё просто и понятно, что даже вовсе не программисты редактируют программы на этих библиотеках.
0
Ещё очень много проблем подкидывает размытая архитектура с которой приходится работать. Приведу простой пример:
Допустим есть модуль УАРТ и выше стоящий Модбас рту. А ещё есть (периодически) микросхема RS485 в которой есть пины RE/DE которые могут быть подключены к одному пину МК, а могут и к двум. И вот куда засунуть работу с этими пинами? В модуль УАРТ? Да вроде уарту до лампочки на эти RE/DE. В модбас? Да и он тут не причём. Вот из-за огромного кол-ва таких нюансов, и желания их все отработать коды и разрастаются до непонятных и нечетко структурированных.
0
Все достаточно просто: работа с пинами так, как это нужно для конкретной периферии делается в конкретной периферии. Если включаете модбас, то пины инитятся под модбас, если под UART — соответственно под него. Но для этого надо несколько другая идеология работы с периферией в целом, а для этого C++ подходит куда лучше.
0
пины инитятся под модбас
Модбас знать — не знает ни про какие пины. Вот в этом и есть главный минус железячных программистов. Неправильное деление на абстракции.
0
Тут дело не в абстракции, а в инкапсуляции. В идеале должно быть что-то типа Modbus.init(CONFIG_DEFAULT) или SPI.init(SPI1_ALT), который возвращает референс на инициализированный объект, через который и идет вся дальнейшая работа.
0
Ну дык у меня всё так и есть. Только все референсы задаются статически для каждого объекта в модуле работы с этим самым обектом. То есть в модуле SPI.h у меня есть структура sSpi spi1, spi2 в которых задаются необходимые референсы для соответствующих spi. И затем все вышестоящие абстракции юзают spi по указателю &spi1. Это вполне наглядно показано в моей первой статье про GPIO. Но только то что вы ответили ни как не решает проблемы куда деть пины RE/DE.
0
Еще раз: раз вы инициализируете конкретную периферию, то там же должны инициализироваться и все пины под нее. Да, с учетом того, что пины шарятся, код инициализации этих пинов появляется в нескольких местах (возможно разный, а возможно и одинаковый). Но это, как по мне, лучше, чем постоянно держать в голове, что «если используется SPI1, то надо не забыть проинициализировать пины такие-то».

P.S. плюсы для решения подобных задач подходят куда лучше. все подобные зависимости там вполне удобно можно выразить средствами языка.
0
в структуре sSpi есть указатели
sGpio* gpioMiso; // пин MISO
sGpio* gpioMosi; // пин MOSI
sGpio* gpioSck; // пин SCK
которые прекрасно инициализируются в функции SPIInit (sSpi* spi)
вместе с напосредственно интерфейсом spi
0
посмотрите вот этот пример . там в модуле Relay используется GPIO, по принципам ни чем не отличается от SPI
0
Угу. И надо не забыть о том, что их нужно передать. И какие именно передать. Причем ошибка в этом месте вылезет только в рантайме. А может и не вылезет, поскольку в силу «четности ошибок» пин может оказаться инициализированным в другом месте. Тогда ошибка вылезет при переделке или в процессе развития проекта. Или даже в другом проекте, куда код с подобной ошибкой будет скопипащен.
0
Не понимаю я о каких вы ошибках говорите.
1) Берем модуль GPIO и создаём нужные нам пины.
2) Берем драйвера выше уровнем (UART, SPI, ADC...) и создаём нужные нам экземпляры периферии, включив в них соответсвующие созданные пины в первом пункте.
3) Создаём драйвера работы с конкретными устройствами (модемы, сенсоры, дисплеи и т.д.) включив в них соответствующие пины при необходимости и периферию для связи.
4) Всё готово. Осталось написать логику работы разрабатываемого устройства и математику поднять если надо.
0
Вот на этапе 2 и могут возникнуть ошибки, если неправильно передать пины. Причем ошибок компиляции не будет, могут быть только ошибки в рантайме.
0
Ну это ошибки из разряда невнимательности. Такие ошибки могут возникнуть вообще где угодно.
0
Тут, пожалуй, стоит углубиться в теорию: ошибки можно сгрупировать по типам: (в порядке трудоемкости обнаружения и тяжести последствий):
— ошибки времени компиляции
— ошибки времени выполнения
— ошибки в логике

Первые ошибки самые простые, они обнаруживаются еще до запуска и легко устраняются. Вторые всегда сложнее в обнаружении, поскольку вылазят в процессе работы. Третий вид ошибок самые сложные в обнаружении и часто проскальзывают незамеченными и долго живут в продукте, а проявляются только при определенном сочетании фаз луны и других трудноуловимых нюансов.
Это все к чему: «errare humanum est», а значит всегда надо стремиться сдвигать ошибки вверх по этой пирамиде. Возврашаясь к обсуждаемому примеру: в том варианте, который я упомянул выше, ошибиться с пинами принципиально невозможно, поскольку в конкретной конфигурации уже зашиты конкретные (правильные) пины. Ваш вариант может приводить к ошибкам третего типа. В моем варианте тоже можно сделать ошибку, но она будет иметь другой вид, а именно в разную периферию можно передать конфликтующие конфигурации (например, использовать шареные пины под две разных периферии), но это значительно проще обнаружить (поскольку для этого надо промазать по конкретному экземпляру используемой периферии, а это будет видно сразу). Полагаю, на С++ при некоторых усилиях можно свести эти ошибки к ошибкам времени компиляции. Ваш вариант к ошибкам времени компиляции свести не получится никак. Даже к рантайм ошибкам его свести сложно.
0
Я понял про что вы. И на мой взгляд в моём решении могут встретиться 2 варианта ошибки:
1) использование пина не созданного в модуле GPIO — тут линкер на страже и не даст это собрать (верхний уровень вашей пирамиды)
2) перепутаны созданые пины (подключаются не туда куда должны) — это как я понимаю ошибка времени выполнения. Разве нет?
0
Хотя не, 2) — ошибка логики. Но она всплывят мгновенно. Как только вы запустите программу.
0
2) перепутаны созданые пины (подключаются не туда куда должны) — это как я понимаю ошибка времени выполнения. Разве нет?
Это может быть ошибкой времени выполнения (перепутаны пины и что-то не работает), а может быть ошибкой в логике (которая вылезет только при определенном сочетании условий). Второй случай возможен в случае «четных ошибок» (например, перепутаны пины для двух разных периферий, но исходная инициализация у них совпадает). В таком случае проблема вылезет только когда конкретная периферия или другой код попробует изменить настройки пина.
0
Тут дело не в абстракции, а в инкапсуляции. В идеале должно быть что-то типа Modbus.init(CONFIG_DEFAULT) или SPI.init(SPI1_ALT), который возвращает референс на инициализированный объект, через который и идет вся дальнейшая работа.
Я задумывался об этом, но пока дальше обычного Си не ушел. Как сделать так, что бы если я инициализировал UART и GPIO под него, то нельзя было использовать эти же пины для других целей? Например, я забыл что там UART и решил повесить туда светодиод, и если я повторно пытаюсь настроить GPIO (который отведен под UART), то компилятор выдает ошибку.
Такое возможно реализовать средствами C++?
0
Можно как вариант запоминать порт и пин в функции инициализации пина (порт и пин) и в каждой новой инициализации проверять нет ли такой комбинации уже в памяти. Была такая мысль сделать, но подумал что лишнее.
0
Такое возможно реализовать средствами C++?
Вот так на вскидку не скажу, «давно не брал я в руки шашек». Но думаю, что возможно.
0
Я все реализую на темплейтах; одна из целей — получать максимум ошибок уже при компиляции. ИМХО такую проверку на этапе компиляции сделать нельзя. Зато легко сделать в ран-тайме.
0
Думаю, если повыносить определение конфигураций в раздельные файлы, и в каждом из них сделать дефайны на используемые пины и проверить, что бы этих дефайнов не было определено, то, думаю, можно сделать и рантайм проверку. Что-то типа такого:

...
file: SPI_CONFIG_1.h
...
#ifdef PIN_GPIO_A1_DEFINED
#error "Conflicting configuration"
#end
...
#define PIN_GPIO_A1_DEFINED 
...

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

file: SPI_CONFIG_1.h
USES_GPIO(A_1,A_2,A_3)

Правда, над этим надо еще подумать.

P.S. все примеры условные, под рукой сейчас нет даже компилятора С/C++, что бы проверить соображения.
0
Не, дефайнами не пойдет. Придется слишком дробить все на мелкие файлы. Или всю конфигурацию на дефайнах делать. Например, для SPI можно использование MISO/MOSI/SS отдельно указывать.
0
Ну возможны и другие варианты. Например, использовать макрос типа USES_CONFIGS(cfg,...) внутри которого и разворачивать проверки на повторное использование пинов. Вобщем, потенциально это можно сделать. Будь в C++ нормальная реализация «языка времени компиляции» это вообще бы делалось в одно касание, но это уже был бы не С++ :)
0
#ifdef WITH_PINS_LOG
LogPin();
#endif
А дальше первая компиляция с логами, потом смотришь что инициализируется дважды. Когда наигрался, WITH_PINS_LOG закомментировать.
Очевидный минус — в чипах с малым объёмом запасной памяти.
0
вся эта абстракция и инкапсуляция приводят к проблемам, которые заставляют писать костыли. разделение ресурса (периферии) никто даже не рассматривает как возможный вариант.
0
К проблемам приводит отсутствие абстракции и инкапсуляции. Что имеется в виду под разделением ресурса?
0
допустим UART используется в нескольких режимах требующих различной инициализации различного набора периферии. и имелся в виду вред не использования ООП, а использования готовых библиотек.
0
Для разных режимов и предусматриваются разные конфиги.
0
и получим навороченную либу, которая настолько умная что требует еще большего количества телодвижений? не проще написать специализированный велосипед для конкретной ситуации?
0
Какого «еще большего количества телодвижений»? Каждую периферию можно инициализировать конечным и весьма небольшим количеством вариантов. Описать эти конфигурации не составит большого труда. И телодвижений будет абсолютный минимум.
0
то есть пишем максимально низкоуровнево?
0
С чего вдруг такой вывод?
0
Давайте будем честны: железячники не умеют в программирование. Я по основной профессии — программист...
А уж если — совсем честно — «железячника» ещё можно чему-то научить! В отличие от современного «программиста» :-( Более тупых (и самонадеянных) людей трудно встретить… Многие даже Русский Язык не в состоянии выучить, что же тут про какие-то другие Языки говорить...:-(
0
Можно, если он потратит на программирование столько же времени, сколько на железо. Но это довольно редкие кадры.
+1
Vga, может тебе просто повезло на «редких кадров». Я только обратный процесс наблюдаю.
0
Не совсем понимаю, что ты имеешь в виду под «обратным процессом».
0
«Всеобщую дебилизацию населения»… Ща well-man2000 выйдет, он популярно объяснит :-)
-2
Современные программисты ничем не отличаются от несовременных.
+1
я бы осмелился заявить обратное. программист прикладник в эмбеде зло. лучше я посмотрю на код «написанный программистами с уровнем культуры разработки уровня пхп-фрилансеров по 5 долларов за час» чем на «профессиональный» с использованием ООП, 50 уровнями наследования. железячный код часто должен быть несколько некрасивым и неочевидным.
0
В профессиональном коде не будет 50 уровней начледования. И да, «железячнмки» зачастую не умеют писать софт, а изучать современные инструменты брезгуют и считают это злом. Просто потому, что не учитывают того, что а) сложность софта постоянно растет и б) пишется софт только раз, а потом многие годы сопровождается и дополняется.
0
на то и стоят кавычки. у Java программиста, который в своей области профессионал, видение правильного кода несколько иное. и оно будет выражено как раз таки в виде огромного дерева наследования для простого мигания светодиодами. и это не потому что он плохой программист. это как раз таки потому что он специалист в своей области, где иначе никак. та же инкапсуляция модулей совсем не обязана быть явной. с моей точки зрения достаточно логического разделения кода на модули в виде отдельных c-файлов. однако с точки зрения некого работника в сфере энтерпрайз разработки это быдлокод.
+1
Как раз в Java наследование не популярно и наличие иерархии хотя бы из 3 уровней, как правило, признак проблем в дизайне. Что же до инкапсуляции через модули в С, то это вполе себе вариант, поскольку инструмент (язык) не позволяет сделать лучше, удобнее или надежнее.
0
вопрос не в вариантах исполнения, а в том для кого что кажется нормальным, а для кого ужасным.
0
Нет никакого «кажется». Есть вполне рациональные и выработанные десятилетиями подходы, которые себя оправдывают. Да, есть разница в решении одних и тех же задач на разных языках, но это именно инструменто-специфичная разница, а не платформо- или уровне- специфичная.
0
«кажется» есть. без него никуда. это как «все фломастеры на вкус разные».
0
Нет никакого кажется. И да, фломастеры разные, но программирование это программирование, общие рациональные подходы никто не отменял, поскольку они применимы к любому виду программирования. Даже в тех случаях, когда этих подходов не придерживаются, этому есть рациональное объяснение. Но промышленное программирование микроконтроллеров никаких особенностей в этом плане не имеет.
0
каждому подходу свое место. и это не все хотят понимать.
0
каждому подходу свое место.
Этим подходам место везде. Даже пионеров этому стараются обучать с самого начала. Конечно, если речь идет о промышленном программировании, а не детским забавах дома в гараже.
0
самый базовый «подход» это выбор правильного для данной ситуации подхода. если мне нужно написать драйвер для частотного привод который завтра могут поменять, то я напишу обертку для возможности быстрой замены драйвера не трогая тела программы. если мне нужно включить двигатель через пускатель, то я не буду городить лишних сущностей.
Однако мне приходилось видеть раздутый код прикладных программиста, которые писали так как привыкли. и более того мне приходилось слышать их критику, по поводу излишней прямоты моего кода.
Одна из значимых разниц между прикладным и встраиваемым ПО в том, что встраиваемое как правило привязано к железу, и конечная цель имеет некие границы. большой красный светодиод всегда будет большим и красным, кнопка всегда будет иметь только 2 состояния. в прикладном же этот «светодиод» может менять цвет и размеры, а «кнопка» внезапно превратиться в комбобокс, и они привыкли это учитывать
0
в прикладном же этот «светодиод» может менять цвет и размеры, а «кнопка» внезапно превратиться в комбобокс, и они привыкли это учитывать
Вы решили еще раз продемонстрировать, что не знаете ничего о прикладном программировании? Пишут (во всяком случае очень стараются писать) минимальный работающий код. Потому что если писать так, как вам кажется, ни один проект никогда не будет закончен в срок, а если вдруг такое чудо и произойдет, то 90% кода никогда не будет использовано пользователем в реальной жизни. А это банально очень дорого.
0
Вы решили еще раз продемонстрировать, что не знаете ничего о прикладном программировании?
Что вы понимаете под прикладным проектированием? Что вижу я — крупные проекты и недели-месяцы планирования и согласования архитектуры перед первой строчкой кода.
0
Что вижу я — крупные проекты и недели-месяцы планирования и согласования архитектуры перед первой строчкой кода.
Угу. Вот только «кнопки» и «светодиоды» с возможностью расширения закладывают в проект только в том случае, если есть реальные требования, а не «на всякий случай».
+1
я не знаю как у вас, но у нас в проект закладывается все, что хотя бы теоретически может прийти в голову заказчику.
0
я не знаю как у вас, но у нас в проект закладывается все, что хотя бы теоретически может прийти в голову заказчику.
Подозреваю, вы не говорите заказчику, что собираетесь потратить от половины до 80% его денег на собственные развлечения…
0
нет. начальная цена от этого сильно не страдает. зато поддержка получается более выгодной как для нас (меньший объем работ, нет повторного полномасштабного тестирования, как в случае с переписыванием в случае незапланированной доработки), так и для заказчика (умеренные цены на достаточно крупные доработки, короткие сроки)
0
Извините, в сказки не верю. Начальная цена от этого страдает очень сильно, поскольку деалется много не нужной работы. Ровно та же фигня с поддержкой. Чем больше code base, тем дороже, сложнее и дольше ее поддерживать и развивать. Насчет «нет полномасштабного тестирования» особенно порадовало. У любого нормального заказчика полномасштабное тестирование делается после любого коммита. И, соответственно, чем больше code base тем дольше и дороже обходится тестирование. Что касается стоимости и времени доработок, то они дешевле и быстрее, если писать минимально работающий код.

P.S. вы, конечно, можете со мной не соглашаться, но такие проекты это моя повседневная работа, а не «наблюдения со стороны». и все эти детали я знаю в каждой мелкой подробности.
0
Начальная цена от этого страдает очень сильно
Еще раз скажу одно слово. Маркетинг.
Насчет «нет полномасштабного тестирования» особенно порадовало. У любого нормального заказчика полномасштабное тестирование делается после любого коммита.
Часто доработки даже не доходят до программистов, так как достаточно правки конфигурации.
Что касается стоимости и времени доработок, то они дешевле и быстрее, если писать минимально работающий код.
доработка минимально работающего кода не может быть дешевой, так как она подразумевает переписывание этого кода с новыми требованиями.
это моя повседневная работа
та же херня.
0
Часто доработки даже не доходят до программистов, так как достаточно правки конфигурации.
То, что выпадает на долю програмистов в этом случае, это самый мизер затрат. Тестирование это не отменяет, а в случае мелких доработок (а крупных сменой конфигурации не сделаешь) это львиная доля затрат времени и ресурсов.
доработка минимально работающего кода не может быть дешевой, так как она подразумевает переписывание этого кода с новыми требованиями.
Вы мне рассказываете как оно вам кажется, а я рассказываю как оно есть на самом деле. Надо доделать или переделать — рефакторинг и пошли добавлять новый функционал. По времени это ровно тоже самое, а вот по первоначальным затратам на разработку и тестирование в разы дешевле.

P.S. особенно занятно выходит, когда любители универсальных решений промахиваются. вот тут вся универсальность боком и выходит, поскольку отрихтовать «стройную систему костылей и подпорок» в этом случае обходится многократно сложнее. а в случае минимального кода все изменения идут по одной схеме — рефакторинг+новый функционал. намного более предсказуемо, значительно дешевле и уж точно гораздо более качественно.

P.P.S. даже переделка архитектуры в этой схеме получается относительно дешевой, а бОльшая часть кода повторно используется. в одном проекте (по мере развития самого заказчика и роста нагрузки) мы трижды меняли внутреннюю архитектуру полностью. но около 80% кода остались совершенно не тронутыми.
0
А это банально очень дорого.
переписать пол проекта из-за ошибки проектирования архитектуры может быть в разы дороже.
0
Спасибо кэп.
0
и более того мне приходилось слышать их критику, по поводу излишней прямоты моего кода
Возможно, они правы? Тем более если реалии проекта допускают такое написание, как у них. А в «большой красный светодиод всегда будет большим и красным» я бы не был так уверен, хотя это зависит от проекта.
0
действительно иногда может стать зеленым и маленьким, реже полноцветным. но это скорее исключения.
0
Ну, учитывая что некоторые железячники пишут о миграции изделия с 8051 + сегментный ЖК на STM32 + TFT — ситуации бывают разные.
Ну и у прикладников тоже вопрос того, что закладывать с прицелом на легкую модификацию, а что нет — большая проблема. Как, собственно, и пишет evsi. Так что не стоит думать, что прикладник обязательно будет закладывать расширяемость везде и всюду.
0
это уже не просто миграция…
0
И тем не менее, ядро логики и управления не меняется. Меняется только UI.
0
на моем опыте такие переезды делались или доп контроллером (который отвечает только за UI) или в рамках более глобальной модификации всего устройства в целом.
0
Ты, похоже, не видел, что пишут пхп-фрилансеры за 5 долларов в час. Хотя казалось бы, достаточно посмотреть на софт от Creative, AverMedia или Atmel.
Железячный код может быть несколько некрасивым и неочевидным, если он написан так ради оптимизации, но код-манки за 5 баксов на это не способны по определению, а вот действительно хороший прикладник — способен, хотя и потратит некоторое время на изучение предметной области.
0
Ты, похоже, не видел, что пишут пхп-фрилансеры за 5 долларов в час.
возможно. но я про
может быть несколько некрасивым и неочевидным
способен
вопрос в том захочет ли?
0
Если вопрос стоит в «захочет ли» — значит это не имеет значения.
0
Если человек уверен что он прав (а он же тру кодер, он не может быть не прав в области программирования), то все плохо )
0
Почему плохо, если он действительно прав?
0
потому что то что он уверен в правоте не делает его мнение правдой.
0
А почему ты считаешь его мнение неправдой? Код для железа не обязан быть «некрасивым и неочевидным», напротив, он должен быть красивым и очевидным, если только задача не требует обратного. И если задача требует — то прикладник сделает так. Если же не требует, то можно делать так, как хочет программист — и хороший программист, независимо от специализации, знает, как писать хорошо и правильно.
0
Оверинжиниринг — это тоже зло, несомненно. И программист, который в микроконтроллер (да, будем честны, куда угодно) впихнёт 50 уровней наследования — фиговый программист, обчитавшийся «Паттернов проектирования».

Но во всём железячном коде (причём я подчёркиваю — речь идёт не о коде, который делают люди, делающие конечные устройства, там зачастую всё нормально, а речь идёт о коде, который делают чисто железячные конторы — произвоители чипов, например), что я видел не было банально единообразных отступов, соглашения о том, как называются пременные (зачастую можно увидеть смесь camelCase и names_with_underscores) и констант для магических чисел (драйвер, например, USB2COM-чипа, в котором более 50 шестнадцатеричных констант для регистров и их битов и ни одного имени для них.

Т.е. речь идёт о банальной культуре кодирования а не о плохой архитектуре. Но мне кажется, что такие «мелочи» — это как раз и есть первый звоночек.
+2
«менеджера-дизайнера» надо добавить в группу «железячных программистов»?
Или надо использовать умные редакторы, умеющие сделать отступ, и, если надо, сразу указать на ошибку или недочёт?
0
Редакторы, несомненно, помогают от некоторых вещей, но и до их появления как-то умудрялись писать код по единому стандарту (code style).

Про менеджера-дизайнера не понял.

Да, ещё хочу сказать, что, разумеется, я нигде не утверждаю, что «обычные» программисты такого никогда не опускают! Часто допускают! Как будто я не видел «обычного» кода, от которого текут кровавые слёзы. Ну конечно видел, и не раз!.. Но если берёшь архив с кодом от контор, у которых все деньги в кремнии, — заранее готовишь кровеустойчивый носовой платок, и не ошибёшься.
+2
Про менеджера-дизайнера не понял.
ты написал претензию по оформлению отступов = значит надо сажать дизайнера-верстальщика, чтобы он приводил текст к корпоративному виденью стиля.
Я иногда ужимаю код, чтобы он поместился точно на печатную страницу в нужном объёме.
0
в нормальной конторе коммит с неправильным оформлением просто не пройдет рецензию и вернется на доработку.
+2
ты написал претензию по оформлению отступов = значит надо сажать дизайнера-верстальщика, чтобы он приводил текст к корпоративному виденью стиля.
Это работа программиста, а не дизайнера-верстальщика. Потому что читать код будет этот же или другой программист, а не дизайнер-верстальщик.
Я иногда ужимаю код, чтобы он поместился точно на печатную страницу в нужном объёме.
Повбивавби.
+3
Повбивавби.
Этот пункт вызвал острое желание ткнуть стрелочку вверх минимум три раза. К сожалению, движок позволяет сделать это только однократно.
+1
Давайте не будем с крайностями про печать кода на бумаге, это отдельная тема. Тот код, что я скачиваю, не для печати, очевидно.

А отступы, договорённости об именах идентификаторов и прочее такое — первый признак производственной культуры. Если её нет — или в голове мусор или сделано на отъебись или два сразу.

Почему-то, когда осматривают очередной китайский DC-DC преобразователь или другую поделку за полтора бакса всегда отмечают, ровно ли припаяны SMD-компоненты и хорошо ли отмыт флюс. Хотя ровность компонентов никак не влияет обычно (мы не говорим про высокочастотные схемы тут) на работоспособность таких устройств. Но она является некоторым культуры производства и, косвенно, качества.

Так и с кодом.
+2
длинные строки в принципе моветон. перенос никто не отменял. и дело даже не в печати на бумаге, а просто в том что горизонтальный скролл это зло.
0
Длина строки это только один из элементов code style. И да, код, который его нарушает, просто не пройдет пре-коммит проверки и не будет вкомичен.

P.S. кстати, даже у самых-самых консерваторов типичное значение максимальной длины строки далеко не 80 символов, как в прежние времена.
0
Экраны стали шире. Редакторы умеют грамотно переносить при печати. Так что все логично
0
Однажды прочитал диалог гуру и новичка в программировании МК и полностью с ним согласен:
— Что такое «переносимость кода»?
— Это миф
+1
Не надо крайностей =)

Частично код можно сделать вполне переносимым. Если есть достойный HAL, то переносимость будет реализована им. Запчасти типа гпиошек, spi достаточно просты и алгоритмы, использующие только их вполне переносябельны. Организация кода.
И есть дофига библиотек, которые компилируются практически под что угодно — обычно это некие абстрактные алгоритмы типа сжатия какого-нибудь, разжатия или реализации протоколов.
0
хал для контроллеров никогда не будет достойным. он будет или негодным с точки зрения переносимости, или негодным с точки зрения применения (ардуино)
0
Штатная либа в ардуине вполне адекватна. Во всяком случае она достаточно удобна и охватывает достаточно широкий спектр контроллеров. Все претензии к ардуине, обычно, сводятся к IDE, а не к либе.
+1
я считаю что либа имеет слишком высокий уровень абстракции и требует кучи костылей для получения нужного результата.
0
Там нет проблем с уровнем абстракции, но, на мой взгляд, иногда не хватает функциональности.
+1
а почему тогда не хватает функциональности, если нет абстракции от железа?
0
С чего вдруг там нет абстракции от железа? Абстракция там, как раз, вполне есть. Там не учтены некоторые варианты применения где важен перформанс.
0
С чего вдруг там нет абстракции от железа?
я как раз таки говорю о ее излишестве
Там не учтены некоторые варианты применения где важен перформанс.
Там нет проблем с уровнем абстракции
это взаимоисключающие фразы, нет?
0
это взаимоисключающие фразы, нет?
С чего бы вдруг?
0
то есть то «не учтены некоторые варианты применения» это не проблема?
0
это не проблема?
Проблема, но это не имеет никакого отношения к уровню абстракции.
0
Если не требовать от хала какой-то специфики, то всё очень даже переносимо. Вопрос в уровне абстракции, с которого начинается полная независимость от железа.
От гпио много не надо — ноги вверх, ноги вниз, вход, выход, подтяжка. Все контроллеры это умеют (разве что к земле у авр каких нет подтяжки). SPI аналогично, если, конечно, не просить какой-нибудь 13-битный режим. 8/16 бит доступны везде (просто где-то 16 бит за два чтения). Уарт, пока он просто тх-рх, можно абстрагировать достаточно свободно. ШИМ (с поправкой на группировки по таймерам, которая, кстати, тоже везде) можно упростить до функций настройки и задания значения. С ацп сложнее, конечно, но если не требовать осциллографической скорости, всё сводится до adc_Get(channel)… Программный таймер тоже хоть на чём-нибудь, но можно реализовать.

Много алгоритмов не требуют каких-то особых режимов периферии и вполне возможно иметь простой хал под обычные случаи, который будет доступен на чём угодно. SPL потому и не шибко переносим, что он реализует все возможные режимы работы, которые, к тому же, у контроллеров различаются, и многие из которых нужны далеко не всегда.
А такие случаи надо просто выделять в абстрагируемый драйвер, не относящийся к стандартным.
0
Если не требовать от хала специфики, то он не может того, что может контроллер. соотвтественно он нагхыр не сдался.
в общем у тебя все заключение склоняется к «многие, если, все».
0
МК не всегда используются потому, что его SPI может работать в 17.5-битном режиме. А если даже где-то код действительно зависит от специфичного режима периферии — во первых, он уже не портируемый, во вторых, в этой части можно написать свой низкоуровневый модуль. Если же специфика периферии влияет только на эффективность ее работы — то наиболее эффективный режим реализуется прями в HAL'е.
+1
я склоняюсь к однотипному подходу в разработке. то есть вариант в первом проекте работать напрямую с регистрами, во втором использовать HAL мне кажется некрасивым. соответственно в моем понимании хал, который можно использовать не везде вещь бесполезная.
0
Проекты бывают разные. Иногда не то что HAL — приходится писать все самому, на ассемблере и ужимая каждый байт. А иногда можно взять Arduino и писать код, который запустится на любой Arduino-совместимой плате, независимо от ее процессора и его фарша.
+1
на ассемблере и ужимая каждый байт.
думаю это уже в прошлом, к счастью.
приходится писать все самому
везде используя SPL я собрал приличную базу наработок, используя которые можно собрать за неделю проект на stm32 практически любой сложности (вот только к сожалению для F7 spl уже не поддерживается...). для меня такой подход более продуктивен
0
думаю это уже в прошлом, к счастью.
Недельку-две назад таким занимался. USB FS хост в ATTINY13 упихивал.
0
>_<
0
А если даже где-то код действительно зависит от специфичного режима периферии — во первых, он уже не портируемый, во вторых, в этой части можно написать свой низкоуровневый модуль.
не совсем. иногда специфичные режимы просто реализуются различными методами.
0
во вторых, в этой части можно написать свой низкоуровневый модуль.
это уже выглядит как костыль к халу, при чем иногда приходится не просто писать низкоуровневую работу с целью что то реализовать, но и ставить костыли, чтоб хал этому не мешал. и не дай бог придется лезть в исходники самого хала
0
это уже выглядит как костыль к халу
Нет, конечно же. В правильно спроектированном HAL обязательно предусмотрены матоды его расширения.
+1
это сейчас про какой сферический хал в вакууме?
0
Еще раз давать ссылку на stm32plus не вижу смысла. Впрочем, да, что бы правильно написать либу надо иметь программистский, а не железячный бекграунд. Сочетание того и другого, скорее исключение из правила, чем правило.
+1
Как я уже сказал, часто никакой специфики и не нужно. Для специфики — свои драйвера.

Отсутствие переносимости вовсе или переносимость основных и популярных режимов работы — это две большие разницы.
К тому же, если пытаться поддержать всё — HAL станет слоновым, тормозным и неподдерживаемым. И пойдёт уже по этой причине туда же.
+1
К тому же, если пытаться поддержать всё — HAL станет слоновым, тормозным и неподдерживаемым.
Важнее тут даже то, что портируемый универсальный HAL неизбежно будет сводить все железо к некоторой стандартной гребенке. В области ПК, кстати, это давно уже привело к тому, что железо проектируется под HAL, а не HAL под железо. Даже в таких системах, как игровые приставки, где, казалось бы, можно поставить любую специфику, уже лет 15 используются вполне типичное железо.
+1
Ну почему же, есть вполне адекватные попытки. Проблема с переносимостью в том, что STM не заинтересована в совместимости с NXP или там Nuvoton. А те, кто в ней заинтересованы, HAL'ами занимаются довольно редко. Но, вон, ARM задумался над этой проблемой и выдвинул свой стандарт HAL, что позволяет надеяться на причесывание HAL'ов хотя бы на ARM'ах в ближайшем будущем (как CMSIS причесала стартап и описания периферии).
0
даже стмовские халы прилично таки разнятся между семействами.
0
Что и является одной из основных причин «фи!» в их адрес.
+1
Переносимость кода существует :)
Как то 10 лет назад делал проект одного типового объекта — в лаборатории у меня был стенд объекта с частотными приводами, датчиками, станциями ввода/вывода и сенсорными панелями оператора.
Для объекта хватало мощностей S7-315 2DP на Infineon C166 20 MHz.
Уже был выпущен комплект рабочей документации… и тут откуда то появилась сторонняя группа «ИТ» (проталкиваемая коррумпированным менеджером местного Сименса) и как бы решила перебить заказ с предложением сделать это на резервированной паре процессоров S7-417Н.
На вопрос: вы хоть один по данной тематике сделали ?
был ответ: мы сможем...
Я: а у меня есть несколько действующих объектов и действующий стенд, на котором я могу продемонстрировать всю работу
Хотите потратить больше… без проблем
Положил на стол сборку за 20 000 евро и залил в неё программу из контроллера за 1 500 евро

переключил интерфейсный кабель… объект не почувствовал замены бойца


Изменил конфигурацию системы мышью, а код программы не заметил подмены бойца

за 2 дня переделали рабочку… судьбу «ИТ» не знаю

есть знающие Специалисты и есть «ИТ» неизвестной этиологии.
0
Перенес с одного S7 на другой — еще бы оно не работало. Я бы посмотрел как какой-нибудь Oven сожрал бы тот же код без модификаций.
0
Абстракция кода на языке контактно-релейной логике позволяет запускать его на всех ПЛК, поддерживающих данный тип языка.
Вот такой абстракции можно добиться и от Куба с его будущими библиотеками… мышкой накликал конфигурацию, вставил нужные тебе имена функций в нужном месте в код и просто работаешь.
0
мышкой накликал конфигурацию
За такие решения сразу расстрел на месте, если они не продублированы чисто текстовой конфиругацией (причем с двунаправленной трансляцией «мышиной конфигурации» в текст и обратно).
+1
Ты не знаешь всего разнообразия форматов хранения программ…
раньше программа хранилась просто в DBF, теперь хранится в SQL…
Я понимаю откуда у некоторых столько самоуверенности в своей позиции… от недостатка самообразования.
тот кто больше всех выступал против атмеги теперь переполз на китайский 8-ми ногий интел51 «420 МГц» и на время заткнулся… :)
0
Ты не знаешь всего разнообразия форматов хранения программ…
Еще как знаю.
раньше программа хранилась просто в DBF, теперь хранится в SQL…
То есть по прежнему в блобе, разница только в нюансах.
Я понимаю откуда у некоторых столько самоуверенности в своей позиции… от недостатка самообразования.
Это, типа, камень в мой огород?
+1
сегодня объект подкинули — к ноябрю надо нарисовать, собрать, смонтировать и сдать в эксплуатацию четыре таких комплекта…
накликал мышкой… угрызений совести от того, что не описал эту конфигурацию текстом нет :)

наивные рассуждения об элитности «ИТ» не воспринимаются — если бы это пришлось программировать «чистому программисту» на уровне регистров микропроцессора с неабстрактным высчетом всего и вся… потребовались бы годы.
0
evsi напирает на текст не потому, что это труЪ, а потому что для текста программисты нарожали огромное количество тулзов. А с блобами даже VCS нормально не работают.
0
блобы… жлобы… тулзы, тузлы… мост в Крым

всё работает…

Кстати… а сколько моделей процессоров STM32?
10...100...1000?

'STM32L486ZG', // 963 процессоров на 23/05/2016
кому не засыпается — пересчитывайте регистры :)
0
Встроенная диффилка — уже хорошо! Особенно если ее можно привязать к VCS. Правда, такие вещи как автомерж (кой и является одной из главных фич гита) работать по прежнему не будут, откатывая на уровень CVS, да и интересно было бы глянуть, во что оно превращается в типичном случае «по полсотни различий в паре десятков файлов».
Кстати… а сколько моделей процессоров STM32?
10...100...1000?
Пара десятков где-то. Конечно, если отдельно считать STM32F100C4 и STM32F100C6, отличающиеся только надписью на корпусе, то будет несколько больше…
0
наивные рассуждения об элитности «ИТ» не воспринимаются
Речь не об элитности, а о том, как этим кодом-конфигурацией потом управлять. Системы контроля версий и все такое. Без этого инструментария у вас получается не разработка, а что-то вроде любительской поделки. Но вы же, поди, деньги за них берете.
0
На картинке выше ты можешь наглядно увидеть сверку версий даже для графического языка…
если не понял, то повторю наглядней и попробуй понять различия


Внесённые кем то изменения будут автоматически зафиксированы ОС контроллера на карте памяти и дату внесения изменений можно легко определить…
Мне не приходится сравнивать версии… я работаю по принципу «Запустил и забыл»… а оно, ворочая сотнями тонн, работает десятки лет штатно по программе… 4 раза в год формально авторски сопровождаю… езжю на северные берега южных морей и южные берега северных ледовитых океанов :)
Пример распечатки 2002 года

*на макетке импульсник для возможности регулирования питания в широком диапазоне входных/выходных напряжений
0
Спасибо, не нужно. Я уже понял, что разработчики контроллера постарались максимально изолировать железячников от софта. Наверное это правильно, но лишает вас возможности включить процесс разработки в более крупный процесс уровня предприятия, систему автоматического сборки и тестирования и так далее. Да и с параллельной работой больших команд над проектом, скорее всего, тоже есть сложности.
0
И большую часть добавленной стоимости создает, а значит и получает в виде капитала производитель ПЛК. Если пройтись дальше в этом направлении, то можно просто брать заказ и искать подрядчика и вообще даже мышью ничего делать не надо.
+1
По данному проекту набирается оборудования Сименса на 300 000 евро…
Мы толкаем весь проект за несколько лимонов… евро… более чем на порядок… из-за малых сроков цена нашей работы выше…
это позволяет потом спокойно трепаться в форумах :)
0
Я конечно понимаю что лезу уже немного в другую степь. Но с таким подходом вы каждый раз им отваливаете допустим по 10%. А можно заменить своим. Пусть и без графического языка но эти модули можно сделать самим и затем легко их юзать и скорость будет не сильно медленнее.
0
Я ещё раз повторю — есть определённый класс оборудования, который работает десятилетиями — на объекте из фотки выше за 14 лет не было ни одной замены комплектующих.
Эти комплектующие до сих пор можно купить как запчасти со склада производителя… хоть и по повышенной цене.
Сопровождение программы не зависит от конкретного Программиста (всякое с людьми бывает) и любой знающий Специалист сможет улучшить и углубить в случае чего…

Да в эпоху импортозамещения стало возможно выпускать и внедрять свои контроллеры для систем управления — сейчас вместо импортных для «умных промышленных зданий» (управление вентиляцией/освещением/отоплением) будем паять свои, так как партия получается для объекта большая и получили добро от Заказчика… но стоить они будут дороже импортных :) но будет стоять Галка об импортозамещении…
0
Сопровождение программы не зависит от конкретного Программиста (всякое с людьми бывает) и любой знающий Специалист сможет улучшить и углубить в случае чего…
То есть суммарный объем всего проекта (для одного контроллера) таков, что один человек вполне может сделать всю работу сам и уложиться в сроки, я правильно понимаю? Если так, то да, большего вам и не нужно, сложность проекта примерно на уровне вот такого www.gnu.org/software/hello/
+1
Как вам такой графический вид отладки?
0
Ну у меня в отладке всё также наглядно если не более.
+2
Ну у меня в отладке всё также наглядно если не более
строка в форуме всё стерпит

0
Я не понимаю, вы что хотите мне доказать? Что примитивные вещи в автоматизации проще реализовать на ПЛК отвалив кучу бабла? Ну я с этим и не спорю. Кстати если уж вы хотите показать какой сложности выполняете проекты то нужно демонстрировать не структурную схему.
+3
Эээ… Представленные скрины отладки выглядят забавно, но отлаживать я предпочту в нормальном дебаггере.
0
Не, вы действительно думаете, что это настолько круто, что этим стоит хвастаться? Любой программист вам покажет свою IDE в режиме отладки, где информации будет во много раз больше.
0
Полагаю вам врядли есть чем похвастаться. Это стоимость рядового аутсорсного ентерпрайз проекта.
0
Уже неплохо, если программная часть проекта укладывается в возможности одного человека. Правда, насколько я знаю, в масштабах всего проекта она смотрится довольно-таки скромно.
0
Проекты подобной стоимости я делал командой из трех человек (включая меня) примерно за 6 месяцев от момента когда даже сам заказчик не до конца понимает чего хочет и до момента, когда система проходит acceptance testing у заказчика.
0
Эх… хорошо… А дедушка где спит?
Какой дедушка? Ааа дедушка… а там… в прихожей… на коврике. А если не слушается, то я его веником…
Это правильно...


верю, что вы в групповой отладке втыкаете свои жилиньки в одну тиньку и пялите её коллективом :)
-2
Интересно, почему когда закончились аргументы вы перешли на личности?

P.S. по работе я не программирую тиньки. как и микроконтроллеры вообще. для тех задач, которые я решаю часто нужны десятки многоядерных компов.
+1
и получим тот же плк?
0
И редактор от Oven сожрет блоб от сименсовского софта? Сомнительно, к тому же, насколько я знаю, у сименса многие языки несколько отличаются от стандартных.
Но, возможно, в области ПЛК и правда с портируемостью лучше. Не зря же МЭК стандартные языки изобретал.
0
Не все задачи можно реализовать одним лишь клацаньем мышки
0
абстрагируйся — есть презентация Портала и там всю программу можно мышкой нарисовать перетаскивая команды и имена переменных из меню прямо на операторы…
У меня теперь очень развито и правое полушарие, так как при программировании я практически все буквы набиваю одной левой (рукой).
Я понимаю непонимание любителей набивать текстовые строки вместо использования эффективных средств разработки посредством мыши и графических языков программирования
набивка чистого текста происходит значительно медленнее, так как Среда не знает, что ты хочешь вбить,
а при использовании графических операторов Среда предлагает набор допустимых переменных для данного ввода и остаётся кликнуть мышью после ввода первых символов…
0
Ваша главная ощибка в том, что все равняете к пром.автоматизации! Там может и проще и быстрее мышкой тягать (в портале так тем более) но кроме промышленности есть много других сфер, где одной мышкой не обойдешься и наличие набора стандартных блоков не спасет тебя…
Представление о таскании мышкой имею:
— из под MatLab программировал контроллеры TI TMS320F28xx и ST STM32;
— в MexBios (чисто для себя) игрался с программированием TMS320F28xx;
— некоторые вещи для дисера пытался реализовать в labview;
— чучуть програмил и сименсовские ПЛК на LAD
И всегда возникала необходимость поднавернуть своего кода, ибо не хватало определенных функциональных блоков или же их смесь давала адовый результат
+3
У меня нет «главной ошибки» — у меня есть знания, опыт и навыки.
Мне есть что с чем сравнивать и мне хотелось бы иметь все удобные инструменты в одной Умной Среде программирования для удобного и без детскиошибочного написания прикладных программ
0
Умной Среде программирования для удобного и без детскиошибочного написания прикладных программ
Ам… Вы про CoDeSys? или он Вам не удобен?
З.Ы. Идеальной среды программирования подходящей для всех задач, всех людей, железа, конечной реализации просто не существует и в ближайшее время врядли будет существовать. Если нашли для себя TIA Portal и он перекрывает все Ваши задачи — заебись! Но большинство не програмит контроллеры сименса
+2
Я понимаю непонимание любителей набивать текстовые строки вместо использования эффективных средств разработки посредством мыши и графических языков программирования
набивка чистого текста происходит значительно медленнее, так как Среда не знает, что ты хочешь вбить,
а при использовании графических операторов Среда предлагает набор допустимых переменных для данного ввода и остаётся кликнуть мышью после ввода первых символов…
Ваше впечатление о том, что вам опонируют «любители набивать текстовые строки» ошибочно. Тем более, что современные средства разработки вполне позволяют минимизировать непосредственный набор текста до весьма незначительных затрат времени. Вы не видите одной простой вещи (просто потому, что не сталкиваетесь с ней) — «эффективные средства разработки посредством мыши» моментально сдуваются как только сложность проекта вырастает выше определенной величины. Иначе говоря, вы имеете дело с примитивными с точки зрения типичного софтверного проекта задачами.
0
а при использовании графических операторов Среда предлагает набор допустимых переменных для данного ввода и остаётся кликнуть мышью после ввода первых символов…
Эээ… Это достижение? Такое, кажется, есть в любой IDE кроме блокнота, хотя я предпочитаю эту часть автодополнения отключать. Я помню, как называются переменные в моем коде, и вбиваю их быстрее, чем нахожу в списке из трех пунктов нужную.
набивка чистого текста происходит значительно медленнее
Напротив. В гуевом редакторе хорошо делается то, что надо видеть — например, художественная расстановка кнопок по форме. Все остальное куда быстрее вбивается текстом при мало-мальском навыке. Единственный плюс схемок вроде FBD — большая наглядность для тех, кто не привык анализировать программный текст (а LAD и вовсе нагляден только тем, кто к нему привык — то есть, ничем в этом плане не отличается от того же асма).
+2
В гуевом редакторе хорошо делается то, что надо видеть — например, художественная расстановка кнопок по форме.
Добавлю, что даже эта часть делается таким способом быстрее только если форм мало. Как только форм становится больше 2-3, лейаут менеджер + копипаста позволяют делать формы существенно быстрее. А уж массовые переделки и рефакторинги вообще только так в приемлемое время и можно делать.
0
А LM разве не графическая же тулза? По крайней мере в Qt формы набивались примерно так же, как в дельфи, только не нужно пиксели выверять и поведение при ресайзе настраивать.
Копипаст — разве формы настолько одинаковые?
0
LM это стратегия расположения элементов. Включить затем компоненты двигая их мышкой или просто вбить руками — несущественный нюанс. Одну-две-три формы проще нарисовать мышкой, а десяток-другой-третий — написать. И да, формы зачастую весьма похожи. Ну и, наконец, я в некоторых проектах делал автоматическую генерацию форм по энтити + аннотации. Это вообще самый быстрый способ. Энтити и так нужны везде, поскольку это отражение предметной области, а аннотации модифицируют автоматическую генерацию форм и задают правила их валидации (при необходимости). Главный плюс такого подхода в том, что вся информация о прикладной области сконцентрирована ровно в одном месте, а используется везде — при генерации форм для гуя, для веба, для валидации на клиенте и на сервере, и так далее, вплоть до обновления схемы в базе. Добавление новых сущностей становится очень простым и рутинным вопросом.
+1
Хмм, возможно. В деле рисования формочек я застрял где-то на уровне Delphi VCL. Про то, что одна и та же формочка может показываться на разных осях, тулкитах и вообще в вебе я регулярно забываю.
Правда, именно художественная расстановка кнопочек все равно лучше выполняется ручным инструментом :D
0
Правда, именно художественная расстановка кнопочек все равно лучше выполняется ручным инструментом :D
Естественно. Проблемы начинаются когда надо расставить так, что бы это не уехало при другом разрешении экрана, на вебе и так далее. Вобщем, для разных задач и ограничений — разные инструменты.
0
 Ну и, наконец, я в некоторых проектах делал автоматическую генерацию форм по энтити + аннотации.
В я тоже так делал (генерация форм (HTML, XAML) и биндингов на основании класса модели и шаблона с декларативным описанием интерфейса. Правда, для добавления новых фичей сложность генератора форм росла экспоненциально, и в наших условиях экономически более выгодным стало писать формы руками, чем поддерживать генератор.
0
Да, первые «пробы пера» на эту тему у меня тоже страдали подобным. Потом я стал из энтити генерировать промежуточное представление, которое постепенно заполняется отдельными процессорами, а потом из него генерируется нужное представление. После этого добавление новых фич стало линейным по сложностии.
0
А вообще, если честно, мне это напоминает «я написал прожку на вин7 (фотография современного ноута), после чего она без переделок и перекомпиляции запустилась на вин2к (фото обшарпанного десктопа начала нулевых), а после замены одной современной функции на депрекейт-аналог — даже на вин95 (фотка ноута на 486-м за некогда 6 килобаксов)!»
+3
Автор топика запретил добавлять комментарии