Comments 159
В основном - фигня. К тому же - "до степени смешения" похожая на эту статью.
Я дал ретроспективу и ответил статьей всем снобам от embedded, а по ссылке про личный опыт развития.
Правильно сделали, спасибо за статью! Лично я указанную @VT100статью пропустил, а вашу прочитал, понравилось!
Отличная статья.
А вы не тот самый «старый электронщик»? )
Про кого речь идет не знаю, но возраст у меня и правда предпенса, так что даже статью пришлось написать про найм возрастных кандидатов, но новыми технологиями я очень доволен.
Да, не молод.
Я про то, что лёгкость освоения - обманчива, а Даннинга-Крюгера - трудно разглядеть вблизи.
Сколько процентов из "вкатунов через Ардуино" начнут подтягивать знания алгоритмов, ТОЭ, микроэлектроники и т.п.? https://habr.com/ru/post/649845/ (статья по ссылке исправлена после того, как автору в панамку накидали)
Вкатуны пожгут ведро мосфетов и успокоятся. А те что поумнее, пойдут теорию учить.
Главное, чтобы вкатуны ничего не успели с капельницами сделать....
Если помидоры ардуиной поливают, то ладно. А в больницы их никто не пустит, вменяемые глав.врачи имею ввиду.
Я думал, речь идёт про сленговое название системы капельного орошения растений. Для медицинских капельниц существуют вполне себе сертифицированные электронные помпы, позволяющие подавать по уставке точное количество лекарства за единицу времени. Они запломбированы и обслуживаются сертифицированными специалистами, поэтому к ним не то что вкатунов, просто левых людей не подпустят.
Ну по сравнению - карт(инг) и авто..... Вроде похоже, после картинга освоение авто конечно легче, но все равно отличается.... НО - нельзя просто так взять и посадить "овердипломированного" картингиста в авто....
Картингист уже знает, как работает мотор и как ведет себя рама с колесами на дороге. Осталось только ПДД выучить. Из 100 картингистов - будет 100 хороших водителей, после автошколы. Из 100 случайных людей после автошколы если выйдет 30 хороших водителей, уже хорошо.
Согласен. И они будут понимать с ранних лет, что быстрая и неаккуратная езда опасна, особенно, когда вы не на специализированной трассе, а на общей дороге. Карт ≠ обычная легковушка.
И кроме того, если сравнивать с Аrduino, приходит раьшек понимание ответственности за ошибки в релизных версиях проверка, и что баги на самом деле не страшны, и их можно без проблем исправить, понимая общую структуру кода и правила языка.
При чем тут сравнение картинга и авто? Сравнение должно быть картинг и формула3 или формула1 и т.д. (из автоспорта) например. Про что собственно и ведётся речь в статье. Или ты дальше, или ты в картинге (delay) остаёшься
Да даже геймеры (!) в ЛеМан вон смогли, что уж там картингисты =)
А КДПВ это ИИ нарисовал, или у меня глюки что провода как-то странно идут, да и операционка на macOS на Макбуке не похожа (хотя виртуалка, ну или Linux можно поставить на Макбук ещё)?
Nano Banana. Красиво же. Вот в следующей статьей про искусственный рассвет- сниму реальную плату, так страшненько будет.
Это жесть, если честно. Артефакты есть, но это реально нужно всматриваться и знать особенности коммутации проводов и как должны выглядеть девайсы.
Ну там провод паяльника идёт "вникуда"... Хотя это надо всматриваться, конечно.
Но от ИИ картинок пока ещё есть какое-то подсознательное ощущение "ненатуральности", как будто объекты на фото приклеены что ли...
да, я тоже сразу почувствовал. Но у меня это ощущается, как будто сломана общая геометрия и пространство. Вроде смотришь все корректно. Потом всматриваешься и видишь артефакты. И некоторые объекты реально искажены в пространстве (узкогубцы например). Видимо мозг подсознательно очень быстро все это считывает и ему не нравится)
Наша естественная нейросеть пока что видимо лучше натренирована за счёт многолетнего наблюдения реального мира во всём его многообразии.... Но не факт, что мы сможем быть лучше ии и дальше....
Обширные нейронные связи в процессе своего слопа кушают куда меньше энергии для выдачи каких-либо генераций, чем ИИшки, и тут вряд ли будут какие-то существенные изменения. ИИ может и сгенерит реальную картинку, но какой ценой :)
УПД: иногда задумываюсь - вот было бы круто иметь такое устройство, чтобы картинки и образы из головы - выводить в электронном виде) Или например сны записать...
Тогда реально можно было бы наглядно понаблюдать на мясной нейрослоп)
Начали бы строить датацентры с мясными нейронками внутри...
Скрытый текст
Основное , помоему, это появление простого и понятного GPIO, причем не только наружу, для этого можно было и LPT приспособить, но и "во-внутрть". (Хотя ЦАП/АЦП вроде давно были). А Arduino это уже реализация этого.
Несмотря на то, что ардуина дала возможности, массовое появление ардуинщиков сильно сказалось на ЗП эмбедд и частично асутп сферы. Не потому, что они приходят и предлагают решения пачками (хотя и могли бы). А потому, что верхушки руководства вполне себе обнаруживают, что нахрена им целый отдел, если вчерашний школьник может написать программу управления гексаподом с 16 сервами? Нет, они не увольняют никого, но начинают понемногу выжимать на ЗП, мотивируя - а ты можешь написать программу для управления тиристорами привода за день? Нет? Чтоо? Год? Ты дурак, Вася...А вот школьник - написал! И пофиг возражения.
Вы объясните лучше, что тиристоры бахнут, если ардуину к ним подключить, и 95% кода там от STM32? - нужны, чтобы они не бахнули на разных граничных условиях.
А серьезно, я считаю, что традиционному эмбедд лет 10 еще осталось. ИИ очень быстро прогрессирует. Лично я активно беру и применяю новинки.
Ну нет! ИИ отвратительно пишет ембеддед! Уж проще дать ему написать "ынтерпрайз джава клиент-сервер микросервис-ориентед... (продолжите по настроению)". Благо там за всей внешней обвязкой перекладывают JSON в XML или обратно. А микроконтроллеры оно программирует ужасно: во-первых, меньше примеров кода, во-вторых примеры зачастую "немного пахнут". Соответственно, если вам просто помигать светодиодом - то это он может. А вот сложную задачу, с опросами датчиков, дисплеем, и т.д. - плохо, очень плохо. Причем, он сам не понимает почему плохо - и лечит одну ошибку, делая две других. Это надо построчно потом проверять - и это ДОЛЬШЕ чем самим писать, мы экспериментировали!
Уточните ии модели, которые использовали?
Для программирования Claude 3.7 показала себя как наиболее адекватная. Предыдущая версия 3.5 страдала отсутствием любопытства - могла не посмотреть файл, но сфантазировать что там. А 4.0 и 4.5 растекаются мыслью по древу - и частенько ведут себя неустойчиво и непредсказуемо.
Типичный пример ошибок ИИ-модели, например - это оно делает устройство с батарейным питанием, и забывает положить контроллер спать. А если на это указать, то радостно вставляет команды сна, забывая что при глубоком засыпании снимается тактирование PWM, и т.д... Пару раз было что она в середине забывает каким портом пользовалась, и меняет ногу, или PortB на PortC... Не сказать что часто - но блин, проверять потом все это!
В ынтерпрайзе можно хотя бы тесты написать и заставить выполнить, чтобы она поняла свою ошибку и поправила. А в мелких проектах на контроллере - это проблематично...
У меня Gemini 3 показала на сегодня лучшие результаты. Типичный кейс на простом проекте описал здесь: https://habr.com/ru/articles/969230/
Быстрее 10 лет, т.к. до этого момента искины появятся в типовых IDE или мастерах типа CubeMX.
Я тоже перешёл на генерацию кода для эмбеда. В ближайшее время планирую зациклить разработку кода для платы на саму плату и искин, чтобы итеративным процессом он управлял сам. Через год, думаю, появятся такие решения, когда ты задаёшь ТЗ и подключаешь плату, а искин сам пишет и тут же отлаживает код.
Вот - ии пошел в массы эмбеда! Статья будет? Опыт, вижу, старый в написании есть, тема актуальная, давайте опытом обмениваться.
Я иду сложным путём. У меня есть опыт использования gdb+py для тестирования платы живьём. Недавно попросил Gemini 3 составить архитектурный план по организации тестирования генерируемого кода в двух вариантах: при помощи QEMU и при помощи GDB, который сейчас поддерживает управление отладкой через python расширение.
Не многие эмбеддеры такое потянут :)
План действий очень простой:
1. Учим искин отлаживать код в QEMU, пытаясь зациклить разработку, чтобы отладкой занимался он сам.
2. Учим делать то же, но уже более конкретно при помощи реальной платы и GDB отладчика.
3. Совершенствуем и автоматизируем оба способа, используя средства, предоставляемые github или gitlab (агентов). Переводим всё на использование контейнеров и серверов с подключенными платами или qemu.
Я пока также думаю как-нибудь попробовать блупилл повесить на Стлинк по юсб и запустить автономного агента на ноутбуке, чтобы с нейросетками он без присмотра сам написал программу, залил, проверил логи, оттестировал, и сам же выложил все в репо с отчетами.
В идеале должно выглядеть так - утром сгрузил текстом с описанием, что должна делать прошивка, вечером - прочитал реферат по итогам работы агента. И плюс уже прошитую плату.
Удаленное управление драйвером двигателей с трансляцией видеопотока, возможностью подключить BT-джойстик и еще разной периферией поморгать - да пожалуйста.
95% кода написано ИИ, включая и фронт и прошивку esp32 на Си. Не без проблем, но заработало. Писалось полгода назад вроде во времена Sonnet 3.6, сейчас уверен было бы лучше.
Возможно для stm32 / плис / других не так распространенных контроллеров все будет похуже, но для популярных ардуин/esp - уже вполне годится. Профессионал наверняка руками напишет быстрее, но в качестве хобби или сайд проектов - имеет право на жизнь.
Это всё хорошо, только вот задача с кучей готовых решений на мега популярном контроллере. Мы тут недавно делали медиаконвертер modbus rtu/mqtt под свои задачи. Примерно так: две линии RTU, до 6 приборов на линии, минимальный период опроса 200мс ± 1мс, если больше то кратно 200, конфигурация и обновление прошивки по TCP, хранение конфигураций в eeprom, работа с float16 и сдвоенными регистрами, трансляция modbus команд в первую линию RS, отладка по USB. Работало на китайском чипе на cortex-m4f (но это неважно, у нас разделена логика на C++ и периферия на C) с FreeRTOS.
Максимум на что хватило Sonnet 4 это написать получение json конфигурации и её парсинг на lwjson (и то потом пришлось переписывать) и работа с файловой системой для хранения конфигураций. Все решения не соответствовали требованиям вообще от слова совсем или просто не работали. Решения по архитектуре она, конечно, предлагала весьма правдоподобные, но вот реализация примерно никакая.
Имхо, это единственное на что годятся нейронки - обсудить архитектуру, накидать прототип и сделать всё самому, уточняя какие-то моменты по ходу дела.
но в качестве хобби или сайд проектов - имеет право на жизнь
Можно, а зачем? Я вот люблю код писать, и не очень люблю отладку, а у меня забирают то, что я люблю, оставляя делать то, что я не люблю. Другое дело если тебе что-то нужно, но ты не знаешь как это сделать.
Что касаемо меня, то я к написанию кода отношусь равнодушно (много на чем писал, для того чтобы не иметь любимчиков), я больше предпочитаю смыслы, и не важно на каком языке они выражены.
Условно говоря - вы выполняете работу переводчика с человеческого языка на машинный, разной степени абстракций. И если ТЗ кривое, и изобилует техническими неувязками, то и код будет такой же.
А вот написание ТЗ просто на русском языке с указанием граничных условий, и многочисленных обработок случае в стиле "а что, если", типа если откажет этот датчик, если пропадет питание, если заклинит мотор и т.п. очень сильно облегчает потом написание кода программы.
Мало того - такая структурированная и четкая постановка задачи практически без ошибок переводится современными ИИ в код для контроллера.
И наоборот - я больше люблю отладку. Завести технику в одном тепличном режиме много труда не надо, а вот заставить ее работать в всех мыслимых и немыслимых комбинациях внешних условий и поломок - вот это настоящий класс.
Тоже довелось много на чём писать, но, во-первых, речь по хобби проекты. Какой смысл в создании чего-то не своими руками как хобби, очень сомнительная затея как по мне.
А вот написание ТЗ просто на русском языке с указанием граничных условий
...очень хорошо работает до тех пор пока нейронка не начинает писать код. Я вот что заметил - внимательности к деталям у них ноль. Зачастую банально в индексах массива ошибаются, что-то выдумывают и так далее. Не говоря уже о проблемах с потерей контекста на дальней дистанции. Особенно забавно когда ИИ просто выдумывает функции SDK когда ты буквально дал на него ссылку. Дьявол кроется в деталях, как говорится.
Мало того - такая структурированная и четкая постановка задачи практически без ошибок переводится современными ИИ в код для контроллера.
Чего я ни разу не видел. В небольшом проекте да, возможно. В приведённом мной примере больше 70 файлов и 10к строк кода, не считая наших внутренних библиотек (и то это небольшой проект, у нас обычно просто описание работы прибора это документ на 300 страниц). Даже учитывая что у нас модульная архитектура, связи и особенности реализации очень легко потерять. Опять же, дьявол кроется в деталях.
ТЗ, кстати говоря, у нас составляется настолько подробно что описание кода который просто контролирует схему узла защиты от КЗ это 3 страницы с подробнейшим описанием и ссылками на схемы, даже блок-схема алгоритма работы есть - это ТЗ потом ляжет в основу описания принципа работы и доказательства безопасности, поэтому и пишем так подробно. Зато код потом пишется ОЧЕНЬ быстро.
мыслимых и немыслимых комбинациях внешних условий и поломок
Вот поэтому я её и не люблю, хоть и кормит меня работа с безопасным оборудованием. Банальный человеческий фактор, очень легко упустить какую-то делать или мелочь, которая потом может привести к неожиданным последствиям. А ещё я травмирован работой над доказательствами безопасности, процесс очень сложный, долгий, муторный и незаметный. Два года разрабатываем прибор и три года тестируем и дорабатываем.
На реальных проектах я старался делить проекты на модули и не давать нейросеткам на растерзание более 1000 строк, а лучше 500 строк. Это кстати у меня такой лимит обозримости кода.
И в промптах писал типа такого - "Вот код:ххх, старый код не менять, выведи обновленный с пометкой "==ИЗМЕНЕНИЯ==", что сразу фокусирует мое внимание - принять ли изменения от нейросетки или нет.
Естественно, ии показывает себя только если есть до этого мощный бекграунд ручного написания программ, чтобы понять, когда код следует принять, а когда ии вывалила своих галлюцинаций.
1000 строк, а лучше 500 строк
Это всё хорошо пока эти строки работают полностью независимо от всего остального. В реальности же эти строки входят в модуль с изменяемым состоянием, который взаимодействует с ещё 5 модулями и меняет их состояние или использует их контекст. Да, слабые связи, но их может быть много и они могут сильно повлиять на работу если упустить какие-то детали.
а когда ии вывалила своих галлюцинаций.
Ну то есть смысла особо нет, потому что всё равно приходится вникать в то что она выплюнула, а тогда максимум на что она годится - это проработка концепции, но не реализация.
Это плохое проектирование. Задача переходит в разряд магии. Типа мы в подвале переставили стул, а на чердаке открылось окно.
Разумное разделение проекта на модули, по типу оптопар - это хорошо. К примеру у серводрайверов на пром.роботах везде опторазвязки, система изолированно работает сама по себе. А логика вынесена отдельно и на нее никак не могут повлиять наводки от обмоток.
Модульность и стандартизация создали мир, какой мы видим сейчас, если бы каждый производитель точил свои гайки и болты - мы бы далеко не уехали.
А логика вынесена отдельно и на нее никак не могут повлиять наводки от обмоток
Только связь через оптопару все равно остаётся связью и если обвязка оптопары изменится - изменится и результат работы блока после неё.
Мы, к сожалению, не живём в идеальном мире, не надо тут абстрактных речей. Тут банально достаточно ошибиться при парсинге конфигурации и узнаем мы об этом только когда данные на MQTT увидим. Или забыв что вообще-то при обновлении конфигурации надо остановить опрос по modbus.
Так же и в вашем примере, наводок-то нет, классно, логика отдельно. Но вот то, что часть за оптопарой сгорела нахрен, мы не узнаем. Да, состояние рабочее, мы там что-то считаем, выдаём. А ничего не работает. То есть нужно всё-таки контролировать, что у нас там за оптопарой происходит. Вот вам ещё связь. А ещё нам надо контролировать что мы сигнал правильный выдаём (это в основном ЖД касается). Ещё связь.
Или например оптопару-то мы поставили, а питание развязать забыли.
Типа мы в подвале переставили стул, а на чердаке открылось окно.
Ну да, представьте себе, мы не можем добиться идеального диверситета. Вы можете спокойно вылететь за предел стека задачи FreeRTOS и не узнать об этом пока где-то что-то не упадёт.
каждый производитель точил свои гайки и болты
Ну вот у нас модуль стандартный, вход modbus, выход mqtt, всё по стандартам, та самая гайка, пусть и умная. А что, у нас все гайки и болты одинаково производят? У всех одинаковые технологии, объёмы, производство, материалы?
За передающей оптопарой можно еще ответную оптопару которая сигнал готовности гонит. По крайней мере на сервоприводах у роботов так.
К сожалению, есть какой-то период развития техники, когда идет борьба стандартов. Здесь у нас есть небольшая возможность повлиять, выбрав хороший стандарт.
Вот меня сейчас бесит ситуация с умными домами - куча производителей, несовместимые устройства.
За передающей оптопарой можно еще ответную оптопару которая сигнал готовности гонит.
Воооооот, и вы уверены что нейронка не забудет что у нас там где-то стоит оптопара (или например обратная связь) и если на ней пропал высокий уровень (или сигнал после фильтров вне допусков) то надо выдать предупреждение и потушить всё что не должно работать если что-то произошло на обратной связи. Хотя казалось бы, какая связь между тем что за оптопарой и нашим кодом который вообще другим занимается. А это как раз то самое
переставили стул, а на чердаке открылось окно
Так что увы, модули это правильно, но полностью независимо они работать не могут и это надо учитывать.
А в частотниках Yaskawa - микроконтроллер управляет силовым мостом просто через IGBT-драйвер. Без всяких "святых оптрончиков", которые используются только для изоляции связи с внешним миром.
Оптроны - это не догма, а один из способов развязки. В тиристорных контакторах на сварочных машинах, к примеру, обычные трансформаторы на развязке стоят.
Отступать от канонов проектирования иногда можно, если есть четкое понимание для чего это делается.
В тиристорных приводах типа ЭПУ тоже трансформаторы. В других тиристорных приводах от Mentor там уже стоят изоляторы емкостные- ну это типа ADUM которые могут в микросекунды, только снаружи интерфейс как у оптронов.
Да хрен бы с ними с оптронами. Ородруинщики это просто...ну не знаю. Вот чем они плохи? Тем что могут начальству выкатить буквально за неделю тестовый стенд. А начальство на этом уже пиарится начальству повыше.... Вот, все включается, регулируется и даже с телефона! Были такие у нас. Школьники. Освещение цехов решили через ардуины и простую вебморду автоматизировать и управлять. Распилили 60 млн.р, ардуины эти в электрощитах валяются до сих пор а светильники поснимали умные, ибо им управление надо (светодиодные, диммируемые, защита Ex) а в промышленных условиях ардуино далее 5 метров даже 485 передать не могла. Собиралось строго из готовых шилдов. Что там за шилды и тд я даже не смотрел. Тупо кинули платы в щит освещения, соединили кое как - и на этом всё. Телевидение приезжало - надо же, школьники на производстве умное освещение делают!
Вот такие вот ардуины у нас были. Вот такие вот умные олимпиадные школьники.
Распилили 60 млн
Школьники, да? :)
Школьники тут причем? Они в меру своего образования и энтузиазма сделали, как смогли. Не надо перекладывать с больной головы на здоровую.
У меня бы вопрос возник к начальнику производства который школьников в цеха пустил, а затем принял работу. Налицо вопиющая некомпетентность руководства.
Судя по "Ардуинным" статьям на разных ресурсах, именно - догма:
"Зачем у Вас соединён один из выводов светодиода с одним из выводов фототранзистора?
Как зачѣ'мъ? От помѣ'х!"
Я буду возражать против "перевода с русского языка на компьютерный". На самом деле - это не перевод. Программирование отличается от всех других дисциплин инженерии тем, что у нас как таковая отсутствует операция "изготовление", или "обработки материала". Там где на материальном производстве работает технолог и оператор станка - у нас все автоматизировано: комплятор, линкер, ldso - без всякого ручного труда. То есть - как только вы составили однозначную и непротиворечивую спецификацию вашего будущего (аналог комплекта чертежей в машиностроении) - вы его сразу же и получили. Проблема только в том, чтобы составить ее однозначно и непротиворечиво. И в этот момент выясняется, что русский язык для этой работы годится плохо - он создавался в других условиях, и для другого. Поэтому программирование предлагает специальный инструмент - искусственно обедненные языки, на которых сильно труднее выразиться неоднозначно или противоречиво (хотя - при желании... см например UB в C/C++). Собственно поэтому - вы не переводите с языка на язык при программировании, а вы описываете на специальном языке - как оно должно быть. Даже если у вас есть перед глазами какое-то техническое задание на русском - вы его не транслируете в код "as is". Вместо этого, вы соотносите текст со своим жизненным опытом, портретом заказчика - и пишете спецификацию на языке программирования. Нет, наверное теоретически можно запинать русский язык до такой степени, чтобы написанная на нем спецификация была однозначна и непротиворечива. Но вангую, что это будет совершенно нечитаемо - а кроме того, совершенно не нужно. Ибо мы выбрасываем именно то, в чем русский язык силен (художественные образы, богатство лексики и свобода построения предложений), и пытаемся пользоваться остатками там, где он слаб. Можно гвозди отверткой забивать с тем же успехом, или шуруп молотком закручивать...
Ну, собственно о чём я и говорил выше, дьявол кроется в деталях, особенно если мы говорим про контроллеры и ОСОБЕННО если он ещё и взаимодействует с каким-то железом.
Недавно случай забавный был - ЦАП 16-разрядный китайский, работает только один канал, интерфейс похож на i2s и требуется 8 стартовых бит управления, данные защёлкиваются по импульсу на WS. Чтобы оно нормально работало с штатным i2s с dma (скорость большая, 48кгц), нам пришлось делать циклический сдвиг данных, так как i2s контроллера выдаёт данные на левый-правый канал по 16 бит, переставляя 32-бит данные dma.
Для таких тонкостей, я не полагался на стандартный вывод нейросеток, и дополнительно кормил сети напрямую даташитами, и по наличию в своем контексте даташита редкой железки, нейросетка давала рабочий код с учетом тонкостей железа.
Поступил я значит так как, вы говорили. Дал даташит, полное описание, даже сказал что точно надо использовать двойную буферизацию, использовал sonnet 4.5, что по итогу:
Правильно проинициализировала периферию
Честно сказала что данные надо сдвинуть в старшую часть чтобы правильно обработался SYNC и дала формулу
Правильно сказала что 2 младших байта перед данными управляющие
Что не так:
Неправильная ширина данных DMA (как данных, так и периферии)
Не догадалась что нет необходимости загружать 24-разрядное слово, по умолчанию управляющая последовательность - нули.
Перепутала HDT и FDT (а это важно для обработки двойной буферизации), ну и ещё мелкие недочёты
В целом если ты с таким сталкивался, проблем не будет от слова совсем. Другое дело что в таком случае проблема решается копипастингом, а если ты хорошо пишешь, у тебя ещё и будет набор функций которые инициализируют предоставленную периферию (нейронка решила сделать это через макросы). Но вот если ты с таким не работал, нейронку легко завести в тупик, когда она будет нести ахинею потому что доступа к железу нет.
У русского(английского, или любого родного) есть преимущество - его понимает заказчик.
Приписывать себе и только себе магические умения по переводу с языка человека на язык машины - это ошибка.
Вот на вытеснение таких дорогостоящих "магов" и нацелена сейчас индустрия ии.
В итоге, или "маги" вылетят на обочину жизни, или сами освоят ии, чтобы стать еще более сильными магами.
Кодеров - то есть просто переводчиков "дайте мне спецификацию, я закодирую" - безусловно вытеснят. Но инженер решает задачу, а язык программирования (так же как чертеж) - инструмент его. И хотя теоретически, ИИ все это должен когда-то смочь (в конце-концов у каждого из нас тут нейронная сеть на плечах в габаритах футбольного мяча с потреблением 100-150вт) - текущей технологии (LLM) до этого очень далеко... При всем уважении к людям которые их развивают - то что получилось - это студент, который перед экзаменом проглотил учебник по предмету (на самом деле - сотни учебников по сотне предметов). И теперь он может говорить правильные слова в примерно правильном порядке, в случае удачи даже воспроизведет правильный фрагмент решения из учебника - но решить самостоятельно задачу не может. Ибо не понимает...
Я прошу прощения за грубый вопрос, а вы точно инженер? Я вообще-то проектирую систему, архитектуру и пишу ТЗ с учётом языка на котором она будет реализовываться железа на котором будет работать (а это всё выбирается под требования) и сразу прикидываю что уже реализовано из того что надо. Что называется, работаем с тем что имеем. И чтобы понять, а как именно лучше реализовать что-то, уже нужен опыт с реализацией, набитые шишки и так далее. Без опыта реализации можно напроектировать такого, что за голову не возьмёшься.
И что за снобизм, никто себе и не приписывает магические умения. Программирование это в первую очередь проектирование. И только потом реализация. У нас зачастую бывают ситуации когда на проектирование потратили 6 месяцев, а реализовали за пару недель.
Ну если мне платят за программирование и инженерию уже 30 лет, то инженер, наверное.
А статья у меня родилась из дискуссии с одним инженером, который заявил, что в программировании нет царского пути и школоты нам только и не хватало в ембедд.
Не, статья-то здравая, сам в эмбед попал после того как с ардуино играться начал. А инженеру этому передайте что без преемственности у индустрии не будет развития, я стараюсь как минимум облегчить работу тех кто придёт после. Если стажёр - объяснить так чтобы понял, мне же работать проще будет. Не самая выигрышная стратегия учитывая обстановку, но мне всё равно.
Я вот наверное не могу себя пока что инженером назвать. Часто не хватает инженерного мышления чтобы принять взвешенное решение.
Я вот люблю код писать, и не очень люблю отладку, а у меня забирают то, что я люблю, оставляя делать то, что я не люблю. Другое дело если тебе что-то нужно, но ты не знаешь как это сделать.
Я тоже люблю писать код, но скажем так, бизнесовый, а всякие шаблонные связки-обвязки - не очень.
Скажем, вот сейчас делаю игру. В UI-библиотеке не хватает компонента. Я знаю примерно, как его написать, т.к. понимаю логику движка в целом, но нейросеть нагенерила мне этот компонент за 5 минут (включая написание промта), а я бы сам писал в районе часа. Больше времени осталось на написание кода, который мне интересен, т.е. собственно логику игры)
У нас, как раз чтобы по минимуму писать шаблонный код для периферии, он весь вынесен в отдельные модули, зачастую это просто инициализация. Все модули инициализации написаны наподобие linux драйверов с мапами периферии которая задействована в работе модуля, по которым периферия и инициализируется, совершенно стандартно, и это пишется один раз под контроллер который мы хотим использовать.
Мне, кстати говоря, в принципе нравится код писать. Любой. Работа с железом, логика, внесение изменений, неважно, мне просто это нравится. Находить какие-то мелочи, особенности работы, тонкости которые всплывают в процессе, нетривиальные конструкции, хитрые методы и разные возможности для упрощения. Мне просто интересно, да и в работе такой подход помогает - там на каждую строчку должно быть обоснование, так как от этого зависит безопасность людей (буквально).
традиционному эмбедд лет 10 еще осталось
А там или ишак сдохнет или падишах...
А серьезно, я считаю, что традиционному эмбедд лет 10 еще осталось. ИИ очень быстро прогрессирует. Лично я активно беру и применяю новинки.
Ни куда он не денется это традиционный эмбед да и любая другая разработка софта, ИИ может помочь/ускорить разработку, повысить любимый менеджерами KPI. Это все если мы говорим про реальный продакшен а не хобби, нужно вам написать контроллер для инвертора асинхронного трёхфазного привода, ИИ возможно не плохо скомпилирует код из всех сэмплов что он найдёт по гитхабу и документации от вендоров, и на лабораторном стенде может даже и двигатель начнет вращаться, и инвертор не взорвется сразу, но как только пойдет нагрузка вылезет куча хардварных заморочек которые нужно учесть в софте, а как пойдет реальный продакшен то еще стопятсот заморочек.
Здесь весь вопрос только в моделях в нейросетях. Когда нейросети научатся не только текстами оперировать, но и получат стройные модели физической реальности в своих кремниевых чипах, в виде моментов инерции роторов, теплоемкости обмоток, биений подшипников и т.п. - вот тогда и будет реальный скачок в качестве проектирования.
Может быть, это все только повышает производительность не более того, более того такие стройные физ. модели и сейчас в общем то доступны и загоняются в матлаб, причем еще в далёкие времена когда был студентом проектирование так и происходило, была сложная модель тягового асинхронного привода, на ней обкатывались разные режимы работы и алгоритмы управления, все это оценивалось людьми, с ИИ ни чего не поменяется, может разве “костяк” модели быстрее будет создан. Но после всех моделирований и прототипирований неизбежны натурные испытания, которые внесут изменения в модель, потом начнется реальный продакшен, когда внезапно силовые транзисторы от Митсубиси недоступны в том объёме что нужен, и проходиться срочно искать замену, или датчики тока от другого производителя и т.д., все это нужно заново испытывать, либо сразу закладывалось, потом появляется крупный кастомер с камазом денег, которому нужны изделия но с другими массагабаритами или какой то доработкой в его имеющееся производство.
Поэтому на мой взгляд реальный продакшен-эмбед мало поменяется, может разве что ускорится будет цикл разработки.
Да внезапная замена железа - это боль. То вдруг подорожало на порядок, говорят ставь другое, то вдруг перестали отгружать по санкциям, то вдруг сняли с производства.
Созрела по этому кейсу идея, - давать нейросетям код, даташит на старую железку и даташит на новую железку и посмотреть что выйдет.
Но реальных испытаний в железе после замены это, конечно, не отменит.
Но реальных испытаний в железе после замены это, конечно, не отменит.
А если взять разработку аудиотехники, тех же усилителей/ресиверов, даже не знаю чем там может сильно помочь ИИ, все ровно все нужно руками трогать, отлаживать, проверять, вносить изменения, или цифровые фотоаппараты там вообще стык цифровой обработки сигналов, оптики, механики.
Ну в фотоаппаратах, например, внутри сотовых телефонов — ИИ помогает тем, что рисует почти похожую почти правдоподобную картинку по мотивам полученных с матрицы сигналов, и в некоторых моделях это даже почти что сносно выглядит :-)
А на звуковых частотах уже как будто всё последние лет 30 тысячу раз посчитано, и большая часть разработки усилителей-ресиверов — подбор цвета ручек и рисование менюшки позадорнее. Вот всякие саундбары и прочая дичь на тему "заставить через DSP колонки от компа из девяностых играть как «наутилусы»" — там уже да, есть в чём закопаться.
Ну теоретически для звуковых частот если ИИ будет делать усилитель...То на первый взгляд это будет просто нагромождение элементов на схеме. Вы видели ракетный двигатель, который комп спроектировал? Совершенно неземной непонятный дизайн. А еще есть про микросхему, спроектированную компом - в ней вообще никто ничего не понял, а она взяла и заработала как надо (про двигатель вот я не помню). Я намеренно не употребляю сокращение "ИИ" и пишу - комп то, комп сё. Потому что в обоих этих случаях не применяются алгоритмы чатботов, для многих ставшими синонимами "ИИ". Stable Diffusion - это ИИ? Нет. Хоть и нейронка. Ну и вот. Тут же вот сегодня же была или вчера статья про разработку бота - схемотехника, который опрашивает пользователя, затем через ltspice прогоняет много раз, совершенствует и выдает на выход готовую схему со всеми удобствами. Надо оно или нет такое вот, если даже не будет ошибаться?
Здесь просто возникает вопрос понимания результата работы нейросети. Новичок первый раз увидев сложную схему усилителя также испытывает шок. В сравнении с 1транзисторным усилком. Но если все объяснить по каждому элементу схемы для чего он нужен - то все становится понятным.
Современные нейросетки уже умеют объяснять что и к чему. Мало того, у меня было дело - из кода писал алгоритм нейросеткой русским языком, что делает программа.
Так и нейросеть можно спросить - зачем и почему она спроектировала схему именно так. И потом, если ии играет в го лучше людей, почему он и усилители не может делать лучше людей?
Обожаю это чувство когда делаешь что-то на модели в матлабе или мультисиме/лтспайс, собираешь железку, а она не работает, мммм
Мне вот одно интересно, это же сколько будет стоить доступ к такой вот вундервафле, кто и на какие шиши будет всем этим заниматься.
Ардуино - великая вещь, но не имеет никакого отношения к робототехнике. Скорее уж Lego Mindstorms сделала для робототехники больше чем все вузы вместе взятые...
Ардуино - молодцы, потому что взяли хороший для своего времени процессор (не шибко нежный, честные +5V GIPO, неплохая нагрузочная способность), и сделали стандарты плат (Mega, Micro, Nano). Дальше народ написал кучу библиотек, и получилась идеальная среда для прототипирования и экспериментов. Потому что когда ты хочешь подключить датчик, а он не работает, вариантов очень много: ты дурак, в документации ошибка, датчик полудохлый, наводки, и т.д. Так вот - если ты собрал, подключил, и с библиотекой от Ардуино оно работает, значит половину вариантов уже можно исключить! А поскольку исходники доступны - то можно еще и проверить реализацию протокола. И поверьте мне, собирать систему и писать прошивку когда на макете оно уже работает - намного проще, чем тыкаться вслепую!
Сейчас вопрос в применении AVR - довольно спорный. Родовым пятном этой серии МК является отсутствие поддержки сети. Соответственно, как только ты хочешь сеть - надо идти или в ESP, или в STM. Но первое - полузакрытое, а второе - гораздо более сложно конфигурируемое (особенно, если не применять автогенерацию кода в проекте и hal). Собственно, и я сам периодически что-то такое несложное отлаживаю на платформе, а потом запихиваю в габариты Tiny13a/Tiny85. Естественно, уже без всяких ардуин и бутлоадеров... Но ключевой момент - отлаженное на нормальной платформе той же архитектуры (mega328p) с дисплеем, индикаторами и прочими атрибутами внутрисхемной отладки...
Плюс, конечно - как только появился стандарт, библиотеки и потребность - китайцы наклепали модулей на все случаи жизни! А раньше - блин, хочешь драйвер шаговика - иди собирать драйвер шаговика. Хочешь Power-independent clock - иди собирай себе часики на микрухах TI... А сейчас - вытащил из коробки хошь - термометр, хошь - датчик холла с ОУ, хошь - индикатор воды, подключил три-пять проводов, и погнали проверять идею и прототипировать! Лепота!
Верно, сам часто mega2560 использую для прототипирования - десяток припасен для разных тестов.
Про роботизацию я трактую более широкую гамму устройств, стиральная машина и посудомойка - это тоже в некотором смысле роботы.
Так ардуино сейчас прекрасно поддерживает и ESP и STM, в чём проблема? С bluepill и blackpill из ардуины уже несколько лет назад проекты делал. Сейчас уже больше ESP32
Взял я как то либу, написанную для atmega, и давай запускать на esp. А оно виснет. На записи в spi. И никакого прямого доступа к железу, честный wiring. Как оказалось, аффтар в некоторых местах после begintransacton написал end transaction. А в некоторых забыл. Походу arduino для atmega такое прощает, а для esp32 нет.
Поддерживаться то оно поддерживается.. но как..
Я не стеснялся кормить ии готовыми библиотеками с промптом:"найди ошибки, предложи исправления", и оно работало. Если либа редкая, ошибки находились. Авторы тоже люди, и не могут покрыть тестами все сферы применения.
Вот бы бы еще hex от атмеги бы в есп залили. А потом бы жаловались что есп плохая (встречал таких товарищей).
Но аффтара либы при этом не оправдываю. Еще тот разгильдяй.
Еще немаловажный пункт то, что у них в итоге это получилось сделать хорошо. Например, микроконтроллеры AVR, как по мне, очень просты, их приятно использовать и изучать. Взяли бы они ARM или что-то 32-х битное, то магии было бы меньше. Еще в статье не заметил упоминания, что это проект с открытым исходным кодом, это тоже немаловажный пункт, по которому и появилось миллион клоново.
Сначала нужно купить микроконтроллер (PIC или AVR). Затем найти программатор ($50–100) или паять LPT-программатор «на соплях», рискуя сжечь порт материнской платы. Потом открыть даташит на 300 страниц на английском, чтобы понять, в какой регистр нужно «плюнуть» битом, чтобы просто зажечь светодиод. И, наконец, написать код на Ассемблере или голом Си, где ошибка в одной запятой превращает устройство в кирпич
Какой ужас! Зато сейчас как хорошо стало, купил у китайцев ардуин, модулей, соединил проводами, залил скетч из готовых библиотек и готово, можно в продакшн. /s
Понимаю иронию, да я видел котлы на ардуине, говорил, ребята то, что это дешево - это хорошо, а то что оно на пару порядков хуже по надежности промоборудования - это как?
Слушайте, ну на PIC делали же промку, и никто не возмущался! Просто в ардуино нет, и не было культуры написания безопасного кода. Там даже watchdog никто особо не использует! Ну потому что в синхронной парадигме написания кода (когда мы ждем ответа датчика крутясь в холостом цикле) - это ж невозможно сделать! Это же надо чтобы все библиотеки такое поддерживали... Не говоря уже о более сложных решениях типа когда одна нога дергает транзистор через разделительный конденсатор, а другая нога задает низкий/высокий уровень на выходе. И резистор который подтягивает это в "безопасное" состояние. Соответственно, если ты завис, то импульсов на разрешающем входе нет, проходной транзистор закрывается (ибо конденсатор постоянный ток не проводит), и система гарантированно приходит в безопасное состояние. Но чтобы такое проектировать - это надо учиться. Желательно, в хорошем ВУЗе - и потом пройти практику в хорошей компании с культурой безопасности при разработке...
А желать чтобы любой человек с улицы мог проектировать решения эквивалентные сертифицированным - ну да, абстрактно хорошо, но никогда не будет! Другое дело, что семья и школа должны давать достаточно знаний, чтобы человек не лез с ардуиной туда, где это опасно... У нас в доме была семья инженеров, паяльник и радиодетали были в доступе чуть ли не с младших классов - но родители сразу сказали: даже не смотри в сторону схем с питанием 220 вольт, не пытайся чинить телевизор, и не лазь в силовую часть импульсных блоков питания. Так и вырос - живой... :-)
да я видел котл на ардуине,
Не верю. Сделать аналог мозгов котла конечно можно, там внутри atmega. Только чтобы закодировать правильно все нужные циклограммы, нужно приложить туеву хучу труда.
оно на пару порядков хуже по надежности промоборудования - это как?
Atmega в синей плате внезапно теряет надежность? ;) или там ldo специально ненадежные? Или текстолит не той системы?
ATmega как микроконтроллер - прекрасен и достаточен для огромного пласта задач медленной и средней автоматики. Сама по себе архитектура AVR надежна, предсказуема и проверена десятилетиями в тысячах коммерческих устройств (от стиральных машин до автомобильных блоков).
Однако типичные Arduino-платы (Uno/Nano/Mega) - это сугубо учебные «девборды» (development boards), непригодные для суровой реальности цеха.
Главные проблемы, закрывающие им путь в серьезный продакшн:
Механическая несостоятельность: Штыревые соединения (Dupont 2.54 мм) держатся на трении. В условиях вибрации от станков или термоциклирования контакт неизбежно деградирует, окисляется или пропадает, что недопустимо в системах, где простой стоит денег. Промышленный стандарт — это винт, пружина или пайка, а не «втыкание в гребенку».
Отсутствие «иммунитета» (EMC): Разводка печатных плат Arduino (особенно китайских клонов) часто игнорирует правила защиты от помех. Отсутствие нормальных полигонов земли и экранирования превращает дорожки в антенны. Щелчок мощного контактора поблизости вызывает наводку, которая либо перезагружает контроллер, либо вешает его, превращая станок в тыкву.
Нулевая защита портов: В промышленности стандарт — 24В и гальваническая развязка (оптопары). У Arduino — «голые» 5В пины напрямую от ножки чипа. Любой скачок напряжения, статика или случайное замыкание датчика сжигают не копеечный предохранитель, а сам микроконтроллер, часто утягивая за собой и всю периферию.
Слабость по питанию: Линейные стабилизаторы на платах не рассчитаны на широкий диапазон входных напряжений и перегреваются, а отсутствие Watchdog-таймера в старых загрузчиках делает систему неспособной к самовосстановлению после сбоя.
Вердикт: Для лабораторного стенда, быстрого прототипирования и хобби Arduino идеальна. Но ставить её в ответственный узел - это закладывать «бомбу замедленного действия», где экономия $50 на железе обернется убытками в много денег из-за простоя оборудования.
Вообще то плата Ардуино это голый микроконтроллер на печатной плате. А судя по посту, в промышленном контроллере стоят какие-то особо крутые микроконтроллеры, "голыми" ножками принимающие и 24 Вольта, и киловольты гальваноразвязки и прочие помехи... Ан нет, как ни залезешь, обыкновенные AVRки или там STMки. Как жеж так?
В любом готовом изделии и уровни напряжений, и защита и экранирование и даже стойкость к вибрации обеспечивается внешней обвязкой. Правильно поставьте Ардуино на матплату и в окружении правильной обвязки и будет работать не хуже прочих. Никак не пойму постоянных претензий к платке с голым микроконтроллером с требованием стойкости защищённости промышленного оборудования
Вряд ли кто то додумается bredboard с ворохом проводов отправить в прод. Можно и пропаять, и лаком залить. А для всего остального нужно понимать, что за факторы будут влиять на оборудование.
Котлы Oasis работали под управлением Mega8.
Тогда что - одна ibm xt тоже сделала больше чем все вузы мира в своей области?)
Тот, кто овладел Адруино вряд ли может считаться инженером. Из овладевших инженерами становились не все, более того, иллюзия "я уже профи" многим ещё и помешала закончить вуз, мне кажется.
Коммерческая успешность вызвана просто тем фактом, что ещё не очень сложно, уже достаточно быстро и, главное, не дорого. К 2000 году был целый зоопарк всяких контроллеров и модульных и мезонинных технологий. Взять хотя бы pc104 с последователями - там даже не загрузчик к 386, а целый биос, хоть дос ставь хоть qnx, любой модуль на двухрядный штыревой разъем а то и на isa-pci. Цена только порядка тысяч, а так отличная вещь)
Полно контроллеров было у ti на любой вкус, мотороллы (freescale), mips - вот это был embedded и в медицину, и в приборы, и телефоны и везде в общем. А вот сфера адруин она была и остаётся как бы ээ.. ниже, имхо) Ну а уж сейчас вообще непонятно во что они превратятся
Новичок смотрит на это и видит криптографию. Битовые маски, регистры... Зачем мне это знать, чтобы мигнуть лампочкой?
Очень странное обоснование зачем нужен ардуино кит. Чтобы избавиться от манипулирования битами, почему бы новичку просто самому, без сторонних либ, не написать человекочитаемую высокоуровневую обёртку:
enum IOMode { INPUT = 0, OUTPUT = 1 };
enum Level { LOW = 0, HIGH = 1 };
static inline void setIOMode(volatile uint8_t* ddr,
uint8_t number,
enum IOMode mode) {
if (mode == OUTPUT) {
*ddr |= (1 << number);
} else {
*ddr &= ~(1 << number);
}
}
static inline void setLevel(volatile uint8_t* port,
uint8_t number,
enum Level level) {
if (level == HIGH) {
*port |= (1 << number);
} else {
*port &= ~(1 << number);
}
}
setIOMode(&DDRB, 5, OUTPUT);
setLevel(&PORTB, 5, HIGH);
Новичок такое не захочет писать вместо 2х строк. Я в статье упомянул, что переход на другой уровень написания программ идет от потребностей. Если будет расти в сложности и надежности проектируемых проектов доберется и до битовых масок.
Для каждого интерфейса замучаешься писать, особенно если микроконтроллеров много. Прелесть ардуино, что digitaRead и digitalWrite работают одинаково для всех даже если это не поддерживаемая плата, для которой добавили поддержку сторонние разработчики.
Другими словами это даже не только для новичков, а для любого уровня лентяев от любителей до профессионалов, которые хотят меньше телодвижений. Например, даже профессионалу будет проще и приятнее использовать эти функции, даже если он знает как устанавливать битовые маски и регистры. Если он, конечно, не перфекционист.
Зачем каждому строгать из бревна свой велосипед? Переиспользование кода - нормально. Использование либ - нормально.
Ну что за снобизм? А чего вы хлеб в магазине покупаете, а не выращиваете пшеницу и потом муку из неё не мелете чтобы хлеб испечь?
Ещё напрашивается атрибут always_inline, потому что без гарантии инлайнинга смысл меняется - через типы нельзя передать информацию, что адрес доступен в IO-пространстве и надо атомарно менять бит за одну инструкцию.
Arduino это как Бейсик в 80е. На моём компе было два варианта писать программы - либо ассемблер, либо бейсик. Сразу программить на асме - очень сложно. Поэтому я сперва начал на бейсике, а когда его стало не хватать - уже постепенно перешёл на асм, ведь бейсик позволил мне понять основы алгоритмистики и вообще как примерно работают программы.
В итоге я стал профессиональным программистом. А не было бы бейсика - не известно пошёл бы я вообще в IT или просто бы на компе гонял игрушки.
Такая же фигня, только с самой ардуино. Попала она ко мне в руки впервые когда я вот буквально поступил в универ, всё завертелось, меня затянуло. Написал пару строчек, и вот лампочки мигают, моторчик вращается, данные по serial идут, офигеть, магия. Потом начал потихоньку изучать, а как же это работает под капотом - сказалось любопытство. И тут пошёл работать ещё будучи студентом (ещё сказалось образование - связь).
Даже не знаю попал бы я в эмбед без этого или нет.
Посмотрел видеоуроки от одного американского парнишки....
Узнал что такое дребезг и притягивание к GND. И много чего еще.
Для минимала нужна 328p и 2 конденсатора. Можно и кварц. Эта штука в режиме покоя от 9 в кроны способна жить 1.5 года.
Arduino изменило мой мир.
Arduino + chatGPT(вставьте своё ИИ) сделали автоматизацию доступной даже для бабушки. Хочешь автоматизированную грядку(я хочу), опиши подробно задачу - получи инструкцию и смонтируй.
Мне теперь даже не надо потеть над синтаксисом, записью в EERPOM для сохранения настроек при сбоях питания и прочими занудными вещами. Просто, как пропиленовый трубопровод.
Мне тут такая автоматизация досталась на доделку. Ну т.е. чтобы заработала. И не от бабушки, люди себя специалистами называют.
Все самые пагубные практики смогли в жизнь воплотить включая ногодрыг с делеями. Ну т.е они-то непричем, этож чатбот писал, а они красавцы...
Задача стояла объяснить как это заставить работать, попросил старый друг, сам он вполне инженер, но не программист.
Две недели мы с ним перезванивались. В результате это всё как-то поехало, ну т.е. работает вроде, применение не ответственное.
Сделать по-нормальному можно было бы вдесятеро быстрее и было бы в разы лучше, быстрее, надёжней, легче в поддержке.
Фиг знает, но яб такое на полив грядок не поставил.
Сделать по-нормальному можно было бы вдесятеро быстрее и было бы в разы лучше, быстрее, надёжней, легче в поддержке.
Только сначала нужно нормально изучить теорию. Не быстрее.
Или обратиться к тому кто умеет. Дороже.
Лично я мог бы сделать быстрее, надежнее, легче в поддержке итд итп. Но до меня оно всё равно не работало, а видимость работы показывало...
Совершенно не представляю кому оно поможет что-то реально годное получить.
Но в качестве попытки давления на исполнителей в процессе торга может и сойдет. Яб правда отправил в добрый путь прям сразу, но люди все разные.
А еще Arduino-ядра существуют под почти все хоть сколько-то известные архитектуры, и магией PlatformIO можно запустить один код на чем угодно, от STM до NXP
Но если код немного сложнее blink - будут нюансы.
Ну, и да, и нет. В рамках базовых функций Wiring проблем почти не бывает, большие популярные библиотеки нативно имеют поддержки ряда архитектур, например у Adafruit и Sparkfun. Проблемы будут если вы используете аппаратные функции в обход абстракций, да. Но в любом случае достигаемый уровень переносимости года шокирующие высок
До сих пор помню как собрал фильтр АЧХ, я за одно устройство которое было спаяно на коленке понял весь годовой курс по ЭМВ. Когда ты просто пишешь схемы в тетрадке и к ним прикручиваешь формулы, ничего непонятно, но если взять теорию и самому искать медный провод N сечения и пытаться накрутить его сколько необходимо, сразу понимаешь зачем в формуле присутствует значение
Я делал именно так: покупал AVR и тд. И тут не лишним будет упомянуть @DIHALT благодаря которому я познакомился и погрузился в мир управляемой электроники. Да, позже я перешёл на Arduino ведь так проще. Но твёрдую базу знаний и понимание того, что происходит "под капотом", я всё-таки получил именно благодаря AVR. Кроме того, подозреваю, что если бы работа с микроконтролером переросла во что-то больше чем хобби то я бы остался на AVR по сей день.
написать код на Ассемблере или голом Си, где ошибка в одной запятой превращает устройство в кирпич.
заголовок то отличный, а вот это вот - провокация
открыть даташит на 300 страниц на английском
ах бедняжки. железо легко можно и на арудине пальнуть, да и на ПЛК - если не понимать что делаешь, для чего приходиться хоть немного почитать документацию .
По сути вопроса - это прекрасно, что люди которые не очень в теме, но хотят сделать че то полезное - берут и делают. но почти сразу возникает вопрос: а почему так можно а так нельзя, почему так не работает, а так - тормозит, и нужно контролер на 5 ГГц. Разобраться самостоятельно - уже долго, скушно, это ж надо гуууглить, проще спросить в форумах у людей которые внезапно 100 лет этим занимается, да еще и не верить их советам
За то, что сделали создатели Arduino им нужно поставить памятник при жизни от благодарного человечества.
Хотя сама система Arduino в адвокатах не нуждается - десятки и сотни миллионов пользователей говорят сами за себя.
Представьте мир до середины нулевых. Вы — школьник, студент или просто энтузиаст, и вы хотите собрать простенького робота. Ваши действия?
Сначала нужно купить микроконтроллер (PIC или AVR). Затем найти программатор ($50–100) или паять LPT-программатор «на соплях», рискуя сжечь порт материнской платы. Потом открыть даташит на 300 страниц на английском, чтобы понять, в какой регистр нужно «плюнуть» битом, чтобы просто зажечь светодиод. И, наконец, написать код на Ассемблере или голом Си, где ошибка в одной запятой превращает устройство в кирпич.
Картина была другой. LPT-программатор вполне можно было купить на радиорынке, совсем не за $50, а гораздо дешевле.
Чтобы понять, как работать с регистрами, не обязательно было читать даташит на английском. Были книги на русском, например "Микроконтроллеры AVR семейства Classic фирмы ATMEL" Евстифеева, к 2006 году вышло аж 3-е издание.
Код не нужно было писать на ассемблере, и даже не обязательно на голом С - поддержка C++ появилась в компиляторах для AVR не позднее, чем в 2002 году. А PIC в принципе плохо подходит для новичков, уж больно не по-человечески он сделан архитектурно.
Вот как выглядит включение светодиода на классическом AVR-C:
DDRB |= (1 << 5); // Настройка пина на выход
PORTB |= (1 << 5); // Установка высокого уровня
Это не классический C, это классический неграмотный спагетти-код. На классическом C грамотный код выглядит так:
#define GPIO_SET_OUT_MODE(PORT,PIN) (_SFR_IO8(_SFR_IO_ADDR(PORT)-1) |= (1U << (PIN)))
#define GPIO_SET_HIGH(PORT, PIN) ((PORT) |= (1U << (PIN)))
#define LED_PORT PORTB
#define LED_PIN 5
GPIO_SET_OUT_MODE( LED_PORT, LED_PIN );
GPIO_SET_HIGH( LED_PORT, LED_PIN ); Причём первые 2 макроса обычно не нужно было писать самому - достаточно было подключить стандартный хидер из avr-libc, написав #include <avr/io.h>
Причём первые 2 макроса обычно не нужно было писать самому - достаточно было подключить стандартный хидер из avr-libc, написав #include <avr/io.h>
Их туда добавили, когда компилятор не распознавал идиому над "IO-доступными" адресами, и потом задепрекейтили в 2005 со словами
Cообщество AVR-GCC теперь единственное известное мне сообщество C-программистов, работающих непосредственно с железом, которое до сих пор не поняло, как работают побитовые операции в C. В списках рассылки FreeBSD я никогда не видел запросов на макрос, который заменял бы |= и &=~. [и дальше про то, что если писать макрос для себя, то сразу LED_ON и LED_OFF]
А почему только роботы? Я пару дней назад собрал на arduino примитивную штуку на ультразвуковом датчике расстояния (по сути то же самое, что парктроник автомобиля). Стоит 500 руб, собирается за пару часов, глаза конечно не заменит, но человек радуется. Хотя бы перестал биться головой в стены
Я начал писать под контроллеры году в 2004, сначала 51 серия, потом перешел на AVR. Программатор понипрог собирался за полчаса. Когда появилась Ардуина, году наверно в 2010 я чот попробовал под нее пописать, офигел от размера бинарника и продолжил писать в CV. До сих пор на нем и пишу. Эмбеддеры были всегда их было достаточно много. Никакой особой пользы я считаю Ардуино не принесла, кто писать умел на чем хочешь напишет, а кто не умеет, ему ничто не поможет. Порог входа +- одинаковый, и чтобы писать эффективно нужно знать устройство контроллера.
Пара лишних мегабайтов бинарника - абсолютное зло, а ардуинщики - дебилы. Но сейчас слепой человек ходит и не бьётся головой о стены. Впервые в жизни. Благодаря arduino. Конечно же от arduino никакой пользы нет, но жёсткий диск на пару ТБ всё-таки нужно нужно прикупить, чтобы бинарники не напрягали своими гигантскими мегабайтами.
Нет, порог входа очень сильно различается. Возьмём ардуино. За 100 рублей плату купил, ide поставил, пример запустил одной кнопочкой, светодиодиками помигал, библиотеку взял, сервоприводом подвигал.
Ну а AVR... Программатор найди, плату найди или сам сделай, фьюзы настрой с риском окирпичивания, пойди пойми как с портами работать, как периферию инициализировать. Уже заинтересованный это сделает. А тот кто присматривается потыкается помыкается, да забьёт. Всегда надо с чего-то начинать, как и с детьми, первые шаги очень важны.
кто писать умел на чем хочешь напишет
Любопытное наблюдение из личной жизни. Все эмберы которые так говорят не умеют писать код. Для них если ты просто МК запустил уже писать код умеешь. А для меня ты умеешь писать код если он поддерживаемый и портируемый, как минимум. Вот вам и разница в восприятии при разных порогах входа
Типичный сноб.
Исходные посылы в статье странные. Во превых нет никакой сложности с внешним программатором. Наоборот, он работает всегда, даже если ты сдуру затер загрузчик. Во вторых не надо никаикх программаторов за $50. Вначале были 5 проводов от LPT, потом был USBASP2. Во вторых Arduino IDE сложно назвати IDE. В AVR студии можно было написать код на асме и смотреть его работу на симуляторе. Для отладки конечно нудна была дорогая плата которой у меня никогда не было, я с LPT, консолью и миганием светодиодом справлялся. Но в Arduino IDE нет даже нормальной подсветки синтаксиса. При всем при этом заслуга у ардуины есть. И эта заслуга в том что масса производителей стали выпускать платы и другие узлы для самодельщиков, в том числе для тех, кто сооружает роботов в учебных целях. Ведь сделать дома плату намного проще, чем сделать какой нибудь редуктор с колесиками.
Да, тема бум подняла сильный. Я только хочу сказать что чем проще что-то делать тем больший к этому интерес. Кто например на asm будет писать код и вообще изучать asm. Проще использовать С++ который куда проще чем asm.
Вторым фактором я считаю что работать уже с готовой платой куда проще чем собирать свою плату, даже при условии что развести несложную с двух сторон плату легко и в домашних условиях. Так тут ещё и опять нужно, а плата построена на беспаечой системе.
Я конечно думаю что не первый высказал такое мнение но всё же, тема меня затронула и я не смог пройти мимо. Такое мнение я сформировал как из личного опыта так и из части статей опубликованных в интернете по схожим темам (программирование, инженерия).
Спасибо автору что затронул данную тему, так как сегодня мало кто затрагивает подобные темы на данном ресурсе. Постоянный читатель ресурса have Android...
Ну хз, я среду ардуино использовал только для процов esp8266 / 32 и то только потому что под vs code мне тогда не удалось правильно настроить среду разработки - скомпилированный код почему то работал не стабильно. Для всего остального использовал разные среды программирования для Атмег codevisionAvr/AtmelStudio для stm - Keil, для арма - IAR ну и vs code для других типов процов. Для новичков да ардуино хорош, до того момента когда уже нужна скорость работы и гибкость в настройке регистров. И отладка в реальном режиме времени.
А почему (не самый интересный, на мой взгляд) пересказ статей Алекса Гайвера вызывает такой интерес?
Ардуино всё же куда больше чем конструктор для обучения или быстрого прототипирования. Это ещё и палочка-выручалочка на промышленных предприятиях. Например надо супер-срочно автоматизировать сбор и анализ данных с кучи датчиков (платы Mega), или резко ускорить процесс разбраковки изделий по статике и динамике(платы Due), или даже целой зондовой установкой управлять вместо компа с 486 процессором (плата Leonardo). И притом надёжность оказалась не хуже чем у тех же компов столетних, главное питание стабильное обеспечить и от статики беречь. В общем, серьёзная вышла экономия времени и средств.
Платы шилдов конечно разводили сами, ещё в PCAD, а сейчас наверняка это ещё проще делается. Разве что пайка smd-элементов требует некоторого опыта, или всего пару дней обучения у опытного сборщика.
У комментаторов распространённая профдеформация/деградация. Они с высоты своего важного опыта разработки уже никогда не смогут посмотреть на вещи со стороны новичка/ребёнка/без способностей айти человека. Тут классическое "пф, это пишется в две строчки кода. Ну правда я 20 лет это изучал, но странно что вы не догадались за один вечер емае" и "ну я же смог, почему другие не могут? Вот тупые, хотят себе что-то облегчить"
Также эти люди не способны понять, что бывают другие методы познания, а не их любимый конченный "от сложного к простому"
Я преподавал основы Ардуино людям, для которых delay это "делай", а пин это герой из Смешариков.
Не все знают английский, не все способны легко осваивать программирование, не все станут программистами (о боже, не все вокруг программисты?).
Но многим Ардуино может принести удовольствие, пользу, а может кого-то действительно приведет в разработку в будущем.
Вот бы геометрию так обучать через разработку примитивного 3D-движка.
А С++ можно начать учить через гениальную goto-ориентированность.
Мне сдается, что мало кто понимает реальный вред, который принесли легкие в освоении программные микроконтроллерные платформы. Это вовсе не массовый приход любителей: такое действительно только к лучшему. О реальной проблеме говорил еще @DIHALT лет пятнадцать назад, а сейчас она только обострилась. Я последние годы занимаюсь редактированием переводов и собственно переводами импортной литературы по электронике, и профессиональной, и с уклоном в DIY, и немного знаю, о чем говорю:
Электроника перестала делаться электронщиками, она теперь делается программистами.
Классический пример на эту тему: объявление портов в Ардуино не через константу, и не через дефайны даже, а тупо в виде переменных в памяти: Причем не просто переменных, а двухбайтовых int. Это встречается и в штатных (рекомендованных) библиотеках Arduino, свидетельствуя о полном непонимании как там все устроено.
Результат печальный: чувак, спец по ASIS и FPGA (что типа высший пилотаж в современной электронике), имеет крайне слабое представление об устройстве дисплеев, о том, зачем к светодиоду нужен резистор, как его правильно подобрать и т.п. И это не единичный случай, нет места тут излагать в подробностях, скажу только, что исключений, которые хотя бы вскользь проглядели Хоровица-Хилла , почти не встречал. Они отлично знают, как настроить пакет для программирования STM32 в виртуальной.Linux-машине, как прикрутить TinyML и всякие прочие NumPy-SciPy. Но не представляют, как устроен датчик температуры/влажности и почему модуль BME280 для практических погодных измерений абсолютно неприменим (а ведь об этом даже в его даташите написано, надо только вчитаться).
И это все фигня, потому что плохо, но безопасно: а вот история, прогремевшая тут на Хабре несколько лет назад со школьным набором для сборки самодельного электрокардиографа, гальванически неизолированного от "земли" компьютера - это не по той же ли причине?
Мне несколько вернул веру в человечество один инженер, работавший в фирме Textronix, который после выхода на пенсию решил поделиться накопленным опытом и написал кучу книжек (выпустил за свой счет, и предлагает перевести в России, на Западе не оценят!). Вот там все правильно и строго, и с электроникой (которая первична) и с программированием (которое все-таки вторично). Но ему уже 75, Карл! А чему могут научить в инженерном плане вот эти, которые все в подробностях про Питон на платформе RaspberryPI Pico, но ни бум-бум про токи и напряжения, представляю с трудом.
Вы судите со своих вершин и написанных книг, и имеете право. Но вот смотрите - ребенок тот же, он стоит в начале жизни у подножия этих вершин и не видит огромного поля знаний, которое открывается с вершин.
Ардуино дает первый толчок подняться на эти вершины, сначала холмики, потом повыше, а потом и горные пики, и хорошо бы если ему на этом пути повстречались хорошие книги и учителя.
Если этого не было, то и будут пробелы в т.ч. и в принципах работы радиодеталей. Согласен, что нельзя давать только Ардуино - лучше чтобы после первого блинка - ребенок собрал просто мультивибратор со светодиодом на транзисторах.
А то, что электроника сейчас делается программистами - это потому, что программа может реализовать такие чудовищные алгоритмы обработки, которые невозможно создать на аналоговой базе.
Проблему с образованием надо просто решать тем, что закоренелых Ардуинщиков надо бы просить и аналоговой электроникой интересоваться. В принципе, нормальные школы, кружки, вузы так и делают.
Здесь есть еще одна проблема - образование в загоне, кто мог бы нормально преподавать, идти подвижничать за копейки не особо горят желанием.
Для меня Ардуино ну никак не синий текстолит, а простой МК, которого можно зашить через программатор (дада, тот самый, железный), предварительно получив бинарник из скетча ИДЕ, когда надо быстро решить какую-то задачу. Ну, к примеру, http://rw6hrm.qrz.ru/vigintos.htm - когда надо со старых передатчиков считать телеметрию через интернет. В принципе, это тот же полив цветочков, ага ;)
А куча готовых дополнительных шилдов только упрощает решение задачи.
А в чем сложность ассемблера для AVR???.
Спасибо за статью, когда-то давно начинал с arduino, потом перешёл на raspberry pi, и в итоге стал программистом.
Почему одна Arduino сделала для робототехники больше, чем все вузы мира вместе взятые