Comments 57
Целый профессор не в курсе про watchdog в древнем микроконтроллере.
нэа, он теоретик. Тут побольше апломба нагнать надо.
Нагнал много чего полезного (и вредного ) но вот как мне кажется важного не сказал.
Проблема все таки не в самой Ардуине (как семейства железок и софта) а в ЦА на которую оно рассчитано. И это, если что, не оскорбление ни первых ни вторых =).
Это гениальный конструктор для тех, кто слабо знаком с электроникой. Для тех кому надо решить с помощью нее какую-то интересную задачу. Электроника тут не самоцель, а лишь инструмент, и максимальной быстрый в применимости инструмент из всех, что есть на рынке.
Но вот чтоб эффект Даннинга — Крюгера не завладел теми, кто научился включать ватчдог и думает, что теперь он сделает серийную железку на основе своего пет-проекта как раз и рассчитана эта статья, ну и дополнения в комментах.
watchdog не работает на ардуинах со старым бутлоадером (читай: на всех китайских), потому что старый бутлоадер его не сбрасывает, и оно уходит в бутлуп
Ещё профессор не в курсе про термошкафы Vötsch, например, для термотестов. 5 лет понадобилось для учета всех температурных особенностей... Блин, простите, это жесть ставить реальные натурные эксперименты в полях, вместо лабораторных, для которых уже "сто лет" продаётся спецоборудование...
А что мешало целому профессору отладить сбой питания и перезагрузку? Ровно то же, что и помешало бы ему отладить ту же саму ситуацию на промышленном контроллере. Может всё дело не в конроллерах, а в данных профессорах?
Железо промышленного класса должно быть более защищённым, в том числе по питанию. Так что гражданскому железу на производстве делать особо нечего, нужно разрабатывать конкретно под условия на производстве. Ребята как-то свое разрабатывали, так у них контроллеры перезагружались из-за сильных помех по питанию, это программно не решается в принципе.
Любое хоть сколько нибудь production ready решение это минимум 3-6 интераций разработки. Надеяться что все заработает с первого раза... это не проблема arduino. И цена убитых птиц будет входить в итоговую цену рабочего продукта.
Страшно подумать что входит в итоговую цену разработки медицинского оборудования согласно вашей логике...
"Техника безопасности написана кровью" (c)
"У каждого врача есть своё кладбище" (с)
Давайте вместе подумаем над смыслом этих "крылатых фраз".
сертификация самое дорогое
Огромное количество животных на тесты? И местами людей https://habr.com/ru/company/pvs-studio/blog/307788/?
Несколько лет назад работал я на пусконаладке одной железки, и рядом трудился коллега из другой фирмы, налаживая конвейер, подающий детальки в нашу систему. Ну, разговорились, кто чем раньше занимался... Он сказал, что до этого работал в пищевой промышленности. Я его спросил - зачем он сменил тепличные условия на шумный и грязный цех литья, а он мне говорит - а ты видел несколько сот литров пива на полу из-за неверно открытых клапанов? Ну вот так-то.
На самом деле есть куча железок, которые надо запускать с первого раза, так как цену изуродованных конвейеров в итоговую цену заказчик включать скорее всего таки не будет. Но современные средства разработки позволяют симулировать практически всё, так что основную часть работы и проверки можно выполнить в уютном офисе. Ну и опять же ошибка ошибке рознь - забыть какую-то копеечную индикацию это одно, а вот уронить многотонную двенадцатиметровую стальную газовую трубу мимо конвейера - это уже несколько другое.
Поэтому в промышленности и берут максимум готовый протестированных модулей, которые будут без ошибок + с зашитыми системами защиты от дурака... вроде все логично. Если мы делаем production ready из 10 production ready решений, то чаще всего все будет ок. Но каждая железяка в отдельности прошла этот путь от прототипа через 3-6 итераций разработки (минимум, я для себя минимум так закладываю всегда), потом альфа, бета и пару поколений устройства с фиксами от клиентов.
А, понял, вы имеете ввиду собственно ПЛК. Ну, как пользователь я в общем ожидаю, что железка будет сразу работать так как заявлено и делать то, что от неё просят (тем более, что стоимость этих игрушек не ардуиновская), и производитель не будет на мне упражняться со своими итерациями. Но баги встречаются, это да.
Вот и получаются рентгеновские аппараты, выдающие пациенту мощность излучения в десятки тысяч рад.
Решать проблему электромагнитных помех, приводящих к сбоям раз в минуту программно? По-моему это в корне порочный путь, потому что сбои - это вероятностное событие, и с какой-то вероятностью могут участиться настолько, что система не успеет вовремя отреагировать на событие, потому что будет непрерывно перезагружаться дольше заданного времени реакции. Быстрое восстановление работоспособнособности через перезагрузку в таких условиях нужно, но чтобы система гарантировано работала нормально, сбои должны происходить не чаще, чем раз в неделю (а то и раз в год, в зависимости от задачи), а не раз в минуту. А так это очень похоже на широко распространённый костыль, про который в итоге забывают до тех пор, пока не случится что-то серьёзное, и потом приходится всё переделывать с нуля.
Проблема даже не только в этом. Вотчдог - это ровно такая же цифровая часть процессора, как и всё остальное. И если железяка работает в условиях непрерывных перезагрузок из-за ЭМ помех - вотчдог точно также может зависнуть. Я уж не говорю, что при таком уровне помех, что идут непрерывные перезагрузки - возможно всё, вплоть до физического повреждения железа.
Использования для перезагрузки при сбоях в условиях интенсивных электромагнитных помех только вотчдога совершенно недостаточно - нужно также контролировать валидность всех хранимых данных непосредственно перед их использованием, правильность вычислений их дублированием, целостность хранимых данных, а также целостность содержимого флэш-памяти и исправность используемых блоков контроллера. Но в статье и не говорится, что для этого используется только вотчдог - напротив, говорится о необходимости "погружения в низкий уровень ПО". Ну а насчёт физического повреждения железа - можно измерить уровень помех, и оценить вероятность такого развития событий, она может оказаться и приемлемой, всё зависит от схемотехники и конструкции контроллера.
Arduino - это целая экосистема. Там есть весьма надёжные платы.
И по существу у конструкторов только один недостаток - их нельзя купить сразу пару тысяч и ожидать поддержки и выпуска без изменений в течении 10 лет.
Поэтому приходится разрабатывать платы точно такие же как Arduino, но на своей компонентной базе.
Arduino IDE отдельная тема. Да, эта IDE довольно ограничена. Но теперь Arduino можно программировать и в VS Code и в Visual Studio и даже в MATLAB-е.
Странно читать про некие ограничения софта в Arduino если эти Arduino сделаны точно на тех же микроконтроллерах что и стиральные машины, и микроволновки, и духовки, и пылесосы, и промышленные ПЛК.
Можно придираться, конечно, к отсутствию специальных цепей защиты, отсутствию гальвано-изоляции, минимализму цепей самодиагностики на платах Arduino. Но автор признался, что сам не ставит достаточно защитных средств на своих платах, поскольку платы у него сбоят. Всем известно, защита - это дорого и её стоимость может превысить цену риска и издержек. В этом смысле Arduino может даже следовало бы похвалить за некую оптимальность.
Так а если для производства промышленного устройства нужно все равно свою плату делать и партия намечается больше 10к штук то зачем вообще тут нужно Arduino? Почему просто не взять софт от производителя контроллера и не написать свою прошивку? Не совсем понимаю в чём тут экономия в случае реальных устройств.
Для быстрого прототипирования да, все понятно, но если уж свою железку делать то все равно программисты нужны. Или тут расчет, что вместо нормальных эмбеддеров можно студентами за еду обойтись?
Например такую Arduino плату я бы взял, но её в стока единицы.
Там софт будет и от производителя (HAL) и популярный опенсорс (mbed) и непосредственно либы Arduino. Все вместе интегрировано, есть сразу загрузчик, WiFi и USB с драйверами, IoT и т.д.
Чем плохо или ненадёжно? Не хуже "профессиональных" решений на FreeRTOS и прочих подобных.
Надежно оно или нет, это надо бы тестирование какое-то провести.
Но опять же все упрется в то что ее в нормальных количествах не найти. На обьемы даже от 1к штук придется разрабатывать что-то свое. В итоге, минимум, грамотный электронщик нужен и к нему грамотный программист. И получится, что этим людям плату сделать и софт написать тоже не проблема. Тогда встанет вопрос, а зачем в этом процессе Ардуино вообще нужно.
А еще же есть такая подстава, как сертификация. Можно встрять, с тем, что вначале устройство и так продается, а при выходе на нового клиента или рынок, потребуется сертификация. И как бы всю эту энчиладу не пришлось переписывать.
В целом я не против Ардуино и согласен, что она сильно продвинула в массы разработку программируемой электроники. Но я не понимаю какую пользу, кроме прототипирования, она может дать компаниям которые профессионально занимаются разработкой электроники.
На моей практике часто видел практические применения Arduino.
Сам не делал, но коллеги вокруг применяют просто массово. Кто-то сделал управление грузовым лифтом, кто-то сделал блок выносных кнопок, кто-то часы с прогнозом погоды на большом матричном индикаторе на рабочее место, кто-то агрегат для полировки биллиардных шаров в офис(и продает на фацебуке задорого).
И это всё в рамках фирмы производящей электронику.
Никто не спрашивает разрешения у руководства пользовать ардуино или нет, просто берут молча и делают, потому что решение стоит копейки.
Я тоже видел много практического применения. Отработав 4 года эмбедером в Tesla я видел и Arduino, Raspberry PI и кучу других "конструкторов". Но это все были как-бы проекты на стороне, чтобы облегчить жизнь тестировщикам или электронщикам. Ни о какой серии или ответственном применении даже речь не шла. Да и не понятно зачем.
Вопрос же не в том нужно разрешение или нет. Вопрос в том, зачем фирме производящей электронику использовать Arduino для устройств, которые идут в массовое производство. Какой вообще профит от этого.
Сам Arduino и есть пример массового, даже очень массового производства.
Не забываем о бесчисленных производителях клонов.
А я всего лишь добавил примеры мелкосерийного производства.
Ответственное применение для Arduino не запрещено. Те же желтые или красные ПЛК с SIL 4 делаются не тех же самых чипах.
Сам Arduino это всего лишь конструктор, он не является конечным устройством не для промышленного ни для потребительского рынка.
Ответственное применение Arduino запрещено пока оно не пройдет соответствующую сертификацию.
К чипам претензий никаких нет, но чипы это и не Arduino. В любой компании занимающейся профессионально электроникой есть свои электронщики и программисты. Ну вот что там такого в этом Arduino, что его обязательно нужно копировать в свои устройства?
Я не так глубоко в теме Arduino что бы прямо так разобрать по полочкам все ценности этой платформы.
Но кое какие сорсы полезные для себя из Arduino брал. Да и сами идеи применения там очень интересные бывают.
Брал драйвера для разных дисплеев, работу с какой-то еще хитрой периферией. С программируемыми LED лентами работу от туда брал. Там это обычно очень лаконично и доходчиво представлено.
Не то что из под линукса чего-нибудь выковыривать.
Надежно оно или нет, это надо бы тестирование какое-то провести.Достаточно взглянуть на плату, и уже не нужно никакого тестирования. Всего один вывод земли на всю кучу внешних сигналов — серьезно?
Надо смотреть на J1 и J2, а не на отверстия по периметру.
Кстати, весьма умно они оставили только один пин земли на тех отверстиях.
Ибо если плата не ставится на материнку со своим плэйном земли, то подсоединять землю к такой плате следует только в одной точке.
Надо смотреть на J1 и J2, а не на отверстия по периметру.Ой… Каюсь, я их и не заметил. Приношу извинения.
Кстати, весьма умно они оставили только один пин земли на тех отверстиях.Только при таком подходе вообще непонятно, зачем использовать такую плату. Например, зачем быстрый 16-разрядный АЦП, если его потенциал нельзя реализовать в полной мере.
Ибо если плата не ставится на материнку со своим плэйном земли, то подсоединять землю к такой плате следует только в одной точке.
быстрый 16-разрядный АЦП
ЕМНИП в классических ардуинах вроде как серия Мега использовалась. В них стоят 10-разрядные АЦП. Или речь про какую-то специфическую плату?
Чем непрофессиональнее разработчик изделия, тем профессиональнее должен быть инженер в эксплуатации. При желании все изделия можно сделать легоподобными, с беспроводными интерфейсами, с индуктивным питанием. То есть полностью изолироваными от внешнего мира. И собираться как блоки лего обычным человеком с улицы. Есть же осциллограф у которого щупы подключаются через оптику.
Обеспечить питание, обеспечить фильтрацию помех, научиться включать вотчдог — можно и на ардуине.
А для защиты от ЧП желается вторичный независимый контур (датчики перегрева, давления, затопления,..) который сам всё выключает когда надо.
Я причастен к выпуску десятков тысяч разных приборов «на ардуине». И пока что все проблемы были с кодом (я отвечаю за железо, программист отдельный)
— Конструкторы не подходят для реальной автоматизации — да. В первую очередь потому что конструктор имеет много точек соединения на скользящих контактах. Это хорошо для быстрого прототипирования, и ужасно в производственной среде. Потому что влажность, изменения температур, вибрация — все это ослабляет контакты и рано или поздно оно начнет глючить.
Можно сделать прототип и поставить его на линию на контактах. Но после опытной эксплуатации надо делать нормальные схемы с пайкой, покрытием лаком и т.д.
— Все рассуждения о температурных диапазонах, по-сути хрень. Да, если вы собираетесь поставляться в нефтегаз или в тропики, то это отдельные климатические исполнения. бОльшая часть того что вы сможете сделать в жизни — будет жить в цехах, где по нормативу температура около +20. И какая разница вам, гарантирует ли производитель диапазон от -70 или от -50 ?!
— Все рассуждения о безопасности — не хрень, но если вы поставляете для РЖД или авиакосмоса, то там есть достаточное количество руководящих документов по которым макет на ардуино не пройдет и так. Аналогично про медицину.
— И да, даже если вы ставите прототип — то почему бы не подумать о безопасности? Например, в проекте был частотник, который крутил конвейер. Несмотря на защиты в прошивке, в частотнике были активированы функции безопасности: установлены лимиты на скорость, и внутренний keepalive (если контроллер перестает периодически засылать через modbus скорость в регистр, то через 5 секунд все останавливается). Но это же не зависит от контроллера! Хоть там сименс, хоть ардуино — это свойства частотника и здравый смысл!
— Я имел вскрывать промышленные контроллеры. Они принципиально ничем не отличаются от ардуины, хотя построены на других процессорах. Точнее, у них два преимущества — защита входных/выходных цепей и минимизация расстояния между компонентами (+ground plane). Первое вы можете сделать и сами на внешних микросхемах, и прицепить к ардуине. Второе — влияет на устойчивость к ЭМИ, и ничего сделать с этим нельзя если не развести специальную печатную плату. Но специальная печатная плата — это уже не ардуино… Это будет промышленный контроллер на AVR8. Непонятно зачем, но в принципе будет работать не хуже и не лучше промышленного контролера на STM или x86 или 51-й серии…
А вообще, с точки зрения энтерпрайза — софт для контроллеров пишется ужасно. Unit-тестов нет. Нормального управления версиями — как правило, нет. Отладка на эмуляторе через костыли и постоянную работу руками. Деплой только руками, а то и через вскрытие машины и подключение шнурков. Когда идет отладка на реальной машине с «временной» блокировкой функций безопасности — я вообще молчу. И в отрасли это норма, потому что «а как иначе?» и «все так делают...».
с точки зрения энтерпрайза — софт для контроллеров пишется ужасно.
Ну, не всё так уж плохо в современном мире. Мы в рамках оптимизации года три как переехали с Сименса на B&R и в общем следуем классическим методологиям разработки - исходники у нас в гите (мы эти ПЛК на плюсплюсах в основном программируем), с CI мы справились - там проект из командной строки собирается, юнит тесты тоже завезли. За Сименсом я давно не следил, но в TIA вроде тоже всё это можно реализовать. Но в целом вы правы, да, эта область довольно консервативна.
У меня на пищевых производствах перед глазами проходило всякое преимущественно программируемое по IEC да под Codesys. Я не говорю про графические языки — там принципиально невозможно изолированное тестирование. IL тоже как бы мимо. Остается ST — но и там не завезли. Мало того, еще же все завязано на библиотеки которые упаковал производитель контроллера. И там тоже никто не собирался думать о том, что это должно быть тестируемым. Поэтому отлаживают уважаемые сервисники производителя как? Либо мышкой в codesys триггеря сигналы, либо собирая подобие стенда на коленке, и тыкая в кнопки (непонятно, что хуже...). В некоторых продвинутых случаях на другом контроллере (опять в codesys) делается какой-то эмулятор интерфейса отлаживаемой системы, и тогда что-то можно автоматизировать. Но библиотеки тестов опять ни у кого нет толком — тест и отлаживаемая процедура модифицируются параллельно — и когда заработало — ненужное выбрасывается (шутка, переконфигурируется под новую задачу).
Но это я описываю если не хороший, то хотя б годный вариант. А негодный, но обычный выглядит так: суем шнурок в автомат для розлива, обновляем прошивку, запускаемся… Ой, а оно не хочет запускаться потому что из-за шнурка не закрыт кожух — замотаем концевик безопасности скотчем… Ой, а оно не хочет запускаться потому что нет продукта — блокируем датчик продукта… Ой, а оно не хочет запускаться потому что не помылось — блокируем защиту по стерильности… А как блокируем? А в коде комментируем, да и все! А когда специально обученный специалист сервиса заканчивает и уходит, все производство молится чтобы он там не забыл раскомментировать то, что ранее закомментировал… Хорошо что производитель тоже не дурак (особенно на европейских машинах) — и вся механика идет с отдельными концевиками, которые не дают ей разнести саму себя. А китайские аппараты идут волшебно — все концевики на контроллер, и вся логика включая безопасность внутри. Ну-ну, как говорится, ну-ну…
все концевики на контроллер, и вся логика включая безопасность внутри
Это-то как раз нормально, мы тоже так делаем. Раньше весь шкаф был забит Pilz Pnoz релейной автоматикой, а теперь мы заводим все критические цепи прямо в ПЛК, включая экстренный останов и т.д. Другое дело, что там цепи двухканальные (там где надо), применяются специальные безопасные модули (мы их "жёлтые" на жаргоне называем), ну и логика программируется в SafeDESIGNER (что добавляет немного головной боли с точки зрения системы контроля версий). У нас ещё и рентген используется, так что требования довольно высокие.
Я не говорю сейчас о спец.контроллерах с мажорированием. Но мне кажется, что отработка примитивных функций безопасности программно — во-первых, не требуется; во-вторых ненадежна. Если у вас стоит драйвер шаговика, то нет проблем limit switches до него пробросить. Копию сигнала можно завести и на контроллер для диагностики. А контроллер пусть мониторит по вторичным параметрам: актуатор запущен, сработки датчика положения нет (или ненормальная задержка) — он уводит устройство в аварию (если допустимо по техпроцессу, или хотя бы регистрирует). Это позволяет поймать ситуации, когда что-то уже начало ломаться но еще не до конца…
Да я в общем тоже - начинал я с ещё STEP5, но когда мне в руки попали вот эти современные игрушки, то теперь меня от них не оттащить. Но всё хорошо в меру, конечно. Зависит от системы, бюджета и т.д.
Походу, что вы, что автор ополчились на Arduino Uno и её первые версии с первой версией IDE. Это выглядит также, как если бы сейчас принялись остро критиковать Windows 3.1
А на самом деле большинство последних Arduino - это мезонинные модули с возможностями превосходящими возможности процессоров ПЛК среднего сегмента.
Я сам прямо сейчас работаю с мезонинными модулями подобными Arduino -
Если бы была гарантия, что производство конкретного модуля Arduino будет стабильным я бы применял Arduino и никакая сертификация бы меня не остановила
А вот если вы берете схемотехнику ардуино, приправляете ее библиотеками ардуино — ну, тогда я не знаю зачем вы это делаете. Качество библиотек там может быть… разным.
А если у вас просто ПЛК на базе AVR8, то еще раз повторюсь — у меня нет сомнений, что это будет работать. Так же как работают системы на базе STM, MCS51, embedded x86 и что угодно еще.
Я просто не знаю зачем это вам может быть нужно? Полно же вокруг платформ ПЛК готовых… Но если душа просит именно AVR8 — не вижу препятствий…
Тут вы явно отходите от посыла статьи. А там упоминается и Raspberry Pi в контексте некой недоделанности.
Прикол в том что SoC на Raspberry вообще полузакрытая архитектура.
И есть сомнения что в ИТМО могут провести её адекватный анализ.
Для меня Raspberry образец недоступной технологии.
И как тогда можно утверждать, что дескать, а вот наша контора все делает круче и индустриальней.
Да не круче, а выкручивается как может. На освоение экосистемы Arduino просто нет сил и интереса, вот и лепят своё. Сотрудничать с Arduino тоже не могут поскольку там высоки требования к преемственности и портируемости софта.
Разные бизнес-модели и не более.
Немного не соглашусь.
На Arduino не нужно делать прототип, потому что если сделали что-то почти работающее, то ничто не останавливает и все остальное доделать на Arduino. Т.е. Arduino это не прототипирование.
Семейство Arduino Portenta H7 идеально подходит под промышленную автоматизацию. Там есть все ходовые межмодульные интерфейсы: Ethernet, FDCAN, QSPI, SDIO и прочие мелкие. Единственная проблема только в том что ребята из Arduino сами не хотят чтобы их дивайсы так массово и специализировано применялись. Они нашли свой бизнес в другом и маркетинг соответственно строят.
Хотя если ограничить понятие Arduino только на Arduino Uno старых версий и старую IDE , то с вами могу согласиться. Но тогда автор должен был это явно указать, и тогда его статья имела бы ещё меньше смысла.
Гляньте UniPi
Китайская ESP на улице трудится уже 3 года и зимой и летом (-45 + 40 ), без специальных мер по герметизации, ничего не отказывает, яйца не "печот". Как показала практика, весьма надежная штука. Думаю вполне себе решение для производства при должном тестировании и подготовке.
Вкину я немного жизни, хотя не уверен, что многие его прочитают)
Учился я у этого профессора и могу сказать, что там очень интересный и богатый опыт разработки с полным понимаем всех нюансов встраиваемых систем, который продолжается до сих пор параллельно с работой в ВУЗе.
Проблема статьи в том, что, как я понимаю, писалась она под широкую аудиторию, а не для профильных специалистов, поэтому многое упрощалось и тут возникает вопрос стоит ли подобное выкладывать в сеть?)
С одной стороны - это полезно и бегло даёт понимание, с другой, судя по комментариям, все хотят больше тонких нюансов для обоснования позиции, но тут тогда и аудитория статьи станет резко меньше и массового читателя не привлечёт.
Если есть желание отвратить публику строить реальную автоматизацию на ардуино, следует доступным языком рассказать, почему. А не кивать на температуру и не высасывать из пальца странные примеры… Которые — как раз, будучи прочитаны непрофессионалами — могут вызвать обратную реакцию: «ух ты — у меня же не загорается в руках светодиод, значит помех нету, и оно будет работать!». Вообще, если речь идет о том, чтобы направить «среднего разработчика» — не следует говорить о том, чего не надо делать. Рассказывайте как надо! То есть если у ардуинщика получился макет, который заработал — то что ему дальше делать? Дадите работающий рецепт, люди пойдут…
Абсолютно согласен с Вами согласен)
Ибо в рабочих проектах очень часто удобно что-то попробовать быстро и просто именно вот на ардуино подобных платах. и это не отменяет их пригодность в ряде случаев общего назначения, тем более, если разработчик отдаёт себе отчёт какие ограничения накладывает на него используемая программно-аппаратная платформа.
А по поводу выхода таких статей в свет, то я думаю тут повторяется давняя история со студентами, которым нужно было для зачёта писать статьи на хабр, но с нюансом, что уже ВУЗу нужна некоторая цитируемость в техническом блоге, вот и пытается кружок журналистов по поводу и без что-то печатать в сеть, а большинству опрашиваемых не очень удобно тратить время на лекции журналистов... Вот так, наверное, и выходит что-то сюда порой в сыром виде)
Как красиво высосана проблема из пальца. Создатель системы не учел основную проблему, значит Ардуино омно!
Ну вот и до Ардуино так же думали инженеры. Но вот кто-то "услышал" желание рынка и теперь все довольны и покупатели и разрабы железки.
Вы, вместо того чтобы писать какое адруино не надежное, приняли бы тот факт что миллионы этих плат используются на полную катушку.
И если вы считаете что это хлам, то пора сделать свою ардуино, но такой какой вы её видите. Критикуя - предлогай. Если у вас такое хорошее виденье проблемы, то сделайте доступную т надежную нашу ардуинку и вы разбогатеете и клиенты будут только рады, если им скажут что есть "гражданская" плата с "почти промвшленой надежностью". Целую серию можно выпустить и платы которые не мокнут и которым песок и зной не страшен в камо расцветке, и плата которая при экстремально низкой температуре работает в расцветке "артика" и т.д.
Короче, я к тому, что клиенту, обывателью наплевать на ваши тонкости работы и чего якобы нельзя делать на ардуино, так как они хотят делать свои изделия, а вы можете или помочь и пойтина встречу или даже жить в своем вакууме.
Если вы сделаете плату идеальную для промышленной автоматизации — она будет плохо подходить для обучения, макетирования и технического творчества.
Если вы сделаете плату которая отлично подходит для обучения и макетирования — ее нельзя оставлять надолго в цехах или на природе.
Если вы сделаете плату пригодную для всего — получится утка. :-)
Нужно просто знать варианты решения, и применять в каждом случае то, что лучше подходит.
статья представляет из себя размышления,нежели хотя бы практический опыт.если б автор побывал в любом приличном сервисе по ремонту и доработке электроники,который не особо презонтабельно выглядет,но у которого очень презентабельная репутация по выполненым ремонтам и доработкам,то у него может случиться инсульт и инфаркт от того,как всё доводится до нужной работоспособности.Теорию и практику,как собираются электронные компоненты и как это всё собирантся воедино на аппаратно-программном уровне посмо реть можно даже в толковых статьях на хабре.Когда люди понимают что делают и как это должно работать.И о чудо,можно даже кривое дешевое китайское барахло сорта(ширпотреб) доработать так,что оно по работоспособности будет превосходить брендируемое дорогое специализированное оборудование.
Просто потому,что это Россия.И мало у кого бюджет резиновый,чтоб купил,настроил,запустил в работу и забыл на долгие годы.А какой способ правильнее это решит каждый сам за себя исходя из возможностей и потребностей.И именно в этой последовательности.
Почему недостаточно Arduino, чтобы автоматизировать производство?