Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 87
Извините за глупый вопрос: «С VS достаточно понятно, хотя тоже спорно… Но зачем QT Creator, для того, чтобы поиграться в консоли? Не проще ли просто воспользоваться услугами компиллятора и не париться с установкой сред программирования, заточенных больше для GUI?»
Почему, когда люди слышат про Qt Creator, то обращают внимание только на слово Qt? Да, для чего-то ооооочень простого достаточно текстового редактора и gcc -o main main.cpp, а то вообще какого-нить ideone.com, но что-то чуть сложнее… подсветка синтаксиса, автодополнение, отладка (как же много вопросов на том же ru.SO которые решаются просто запуском под отладчиком) — оно помогает. Да, крутым перцам достаточно и саблайма — там всё настроить можно и самописного Makefile. Я вот не крутой, QtC даже для Baremetal использую (сейчас с платой вожусь, которая физически в Канаде находится, а сам я — во Владивостоке).
В общем, IDE хороший вариант для старта, где всё необходимое уже упаковано. Хорошо ли, плохо ли, удобно ли, неудобно ли — это другие вопросы. Плюс те же официальные сборки QtC сразу ставят и MinGW компилятор (речь про винду).
В общем, IDE хороший вариант для старта, где всё необходимое уже упаковано. Хорошо ли, плохо ли, удобно ли, неудобно ли — это другие вопросы. Плюс те же официальные сборки QtC сразу ставят и MinGW компилятор (речь про винду).
Я с вами согласен насчет использования IDE для разработки малого-среднего-большого проекта. Но речь же шла про «поиграться в консоли». Разве так уж важна подсветка синтаксиса и автодополнение для ознакомления с С и написания (и небольшого изменения) типичного HelloWorld? Я близок к такой точке зрения, что, осознав необходимость фич, предоставляемых IDE, новичок сам решится на установку этой самой среды разработки… Но это лишь моя точка зрения.
QT Creator — это не GUI дизайнер, а полноценная IDE, возможности которой в редактирование C/C++ кода на голову превосходят почти всё (продукты основанные на Эклипсе могут конкурировать) классические решения из мира микроконтроллеров.
Продукты на Эклипсе преимущественно отстойны, конкурирует только Visual Studio (и выигрывает у Creator благодаря отличному отладчику; именно редактирование кода в Creator не хуже).
Да уж, по отладчику ни Qt Creator, ни CLion к VS пока не подобрались(
Редактирование кода и в Qt Creator и в Eclipse и в Netbeans лучше чем в чистой Visual Studio. Если же брать VisualStudio + VisualAssist, то такой комплект уже может конкурировать в редактирование кода с перечисленными современными IDE.
По поводу отладчиков — это сложный вопрос, т.к. собственно отладкой часто занимается отдельное приложение (например gdb), а в IDE делают только визуализацию соответствующих данных. Так что тут надо разделять кто «виноват» за плюсы или минусы отдельных решений.
Но в сумме для локальных приложений решение по отладке в VS кажется чуть комфортнее. А вот для удалённых или каких-то нетривиальных типа на Андроиде или на микроконтроллере как раз QTCreator в последнее время стал удобнее всех.
По поводу отладчиков — это сложный вопрос, т.к. собственно отладкой часто занимается отдельное приложение (например gdb), а в IDE делают только визуализацию соответствующих данных. Так что тут надо разделять кто «виноват» за плюсы или минусы отдельных решений.
Но в сумме для локальных приложений решение по отладке в VS кажется чуть комфортнее. А вот для удалённых или каких-то нетривиальных типа на Андроиде или на микроконтроллере как раз QTCreator в последнее время стал удобнее всех.
Редактирование кода и в Qt Creator и в Eclipse (насчёт последнего, кстати, не очень согласен) было лучше до появления VS 2015.
А как Qt Creator работает с Андроидом? Это только QML / Qt приложения на чистом С++, я правильно понимаю? Нормальное, нативное для Андроида Java приложение с С++ — ядром он не может?
А как Qt Creator работает с Андроидом? Это только QML / Qt приложения на чистом С++, я правильно понимаю? Нормальное, нативное для Андроида Java приложение с С++ — ядром он не может?
Ммм, вообще то C++ приложения вполне себе нативны для Андроида (не забываем про NDK). Просто у него нет доступа к некоторым возможностям из Java API (но зато есть множество других возможностей, недоступных из Java). Если нужны эти возможности, то многие из них доступны в C++ приложениях с использованием библиотеки Qt (там это реализовано через спец. прослойку на Java). И в любом случае при таком подходе получаются реально кроссплатформенные приложения, а не просто под Андроид.
Но весь текст выше не имеет никакого отношения к IDE, т.к. подобное (программировать на NDK или же с библиотекой Qt) можно делать в любой IDE. Разве что редактор GUI тогда будет в виде отдельного приложения, а не в самой IDE. Здесь же у нас речь шла о другом — об отладке. И она в Qt Creator поддерживается не только для локальных приложений, но и для удалённых машин (есть свои мелкие удобства), для андроида (там же свой adb, который кстати никак не связан с C++), для микроконтроллеров.
Но весь текст выше не имеет никакого отношения к IDE, т.к. подобное (программировать на NDK или же с библиотекой Qt) можно делать в любой IDE. Разве что редактор GUI тогда будет в виде отдельного приложения, а не в самой IDE. Здесь же у нас речь шла о другом — об отладке. И она в Qt Creator поддерживается не только для локальных приложений, но и для удалённых машин (есть свои мелкие удобства), для андроида (там же свой adb, который кстати никак не связан с C++), для микроконтроллеров.
Слишком сильная кроссплатформенность часто означает потерю нативности. ИМХО наилучший подход — вся бизнес-логика в кросс-платформенном ядре, и тонкая обёртка UI. Но я отклонился от темы, да.
Да, это хороший подход. Но у него есть пара минусов:
1. Он подходит далеко не всегда. К примеру если мы имеем дело скажем с видео в реальном времени, то понятно, что единственный приемлемый вариант, это выводить его на экран средствами самого C++. И таких примеров множество.
2. Он довольно дорогой. Потому как надо иметь минимум по одному специалисту (а лучше по команде) для написание UI под каждую платформу: две главные (android и windows), две второго эшелона (ios и osx) и возможно ещё маргинальные (linux, winphone и т.д и т.п.).
1. Он подходит далеко не всегда. К примеру если мы имеем дело скажем с видео в реальном времени, то понятно, что единственный приемлемый вариант, это выводить его на экран средствами самого C++. И таких примеров множество.
2. Он довольно дорогой. Потому как надо иметь минимум по одному специалисту (а лучше по команде) для написание UI под каждую платформу: две главные (android и windows), две второго эшелона (ios и osx) и возможно ещё маргинальные (linux, winphone и т.д и т.п.).
Кстати, мне понравилась простота, как с помощью Qt Creator можно создать приложение под андроид. Ни разу не писав под него, буквально за 5 минут, подцепил телефон и приложение в режиме отладки запустилось на реальной железке!
Но зачем QT Creator, для того, чтобы поиграться в консоли?В QtCreator встроен QtDesigner, но это не значит, что он заточен на GUI. Во-первых он очень просто устанавливается, несет в комплекте все необходимое, «париться» не нужно. Сборка одной кнопкой гораздо дружелюбнее чем голая консоль. Там есть отличный текстовый редактор с подсветкой и автодополнением, что гораздо комфортнее чем писать в блокноте.
Upd. да, комменты неплохо бы обновлять перед отправкой :/
Я бы еще добавил «Пользуйтесь системой контроля версий, не важно какой». Почему-то именно среди программистов микроконтроллеров большой процент людей, которые про такие штуки вообще не знают (по моим наблюдениям).
И тогда в лучшем случае архивы-бекапы с датами, а в худшем — ничего вообще.
Особенно на этапе обучения возможность откатиться на пару шагов назад очень полезна.
И тогда в лучшем случае архивы-бекапы с датами, а в худшем — ничего вообще.
Особенно на этапе обучения возможность откатиться на пару шагов назад очень полезна.
Я бы ещё посоветовал как можно скорее отходить от Makefile. У меня был проект, где можно было параметрами включать различные опции, в один прекрасный момент столкнулся с проблемой: всё собирается и линкуется, но работает криво, причём ошибки феерические. Делаешь полный ребилд — всё отлично. Всякие CMake, qbs и так далее, дают возможность задавать опции на уровне конфигурирования билда, положить на плечи системы отслеживание зависимостей и принуждать делать ребилды, когда оно требуется, даёт возможность использовать теневые сборки, что позволяет не мешать код и бинарники, использовать несколько раздельных билд-конфигураций с разными параметрами, а не перестраивать всё в одном дереве. Потом помогает.
такое случается, когда не правильно указанны зависимости в makefile.
Например — нет зависимостей от хидеров: пусть есть a.h включенный в b.c и c.c.
Собираем, получаем b.o и c.o затем правим a.h и b.c пересобирается только b.o, а c.o вполне может содержать устаревшие определения из старой версии a.h — буфера не правильного размера и пр.
Лечится включением генерируемых зависимостей (см ключ gcc -MM).
Сам сейчас осваиваю qbs, но чудес не происходит — чуть что сложное, например __weak__ в статик либе — все рулы приходится писать руками.
Например — нет зависимостей от хидеров: пусть есть a.h включенный в b.c и c.c.
Собираем, получаем b.o и c.o затем правим a.h и b.c пересобирается только b.o, а c.o вполне может содержать устаревшие определения из старой версии a.h — буфера не правильного размера и пр.
Лечится включением генерируемых зависимостей (см ключ gcc -MM).
Сам сейчас осваиваю qbs, но чудес не происходит — чуть что сложное, например __weak__ в статик либе — все рулы приходится писать руками.
Зависимости генерировались средствами gcc, вручную их описывать, это адъ. Где-то возник косяк, в общем файлов уже очень много и мысль была проста: если какой-то инструмент мне может облегчить жизнь, то почему бы им не воспользоваться. На написание правил, да, ушёл день (больше на придумывание как оно должно быть, удобнее, минималистичнее и generic use): github.com/h4tr3d/fx3-cmake
дополняя: лучше остановиться на какой-то децентрализованной. Проще, что комиты можно делать локально, не нужен сервер. А вот какую: git, mercurial, bazaar — дело вкуса или наличия местного гуру :)
помоему у радиолюбителей часы это как у хирурга первое вскрытие.
Я в прошлом году тоже начал с часов на газоразрядных лампах, ничего не знал и не умел, да и програмировать на с тоже не умел, почти шесть месяцев делал. В конце конечно доделал, но пришлось упростить немного. Хотел сначала с dcf77 сделать, но не смог побороть помехи от блока питания, пришлось сделать просто с ds3231.
Может кому интересно www.youtube.com/user/sanshotur/videos
И я с автором не соглашусь, надо начинать именно с конкретного проекта. Из-за знания конечной цели не так сильно падает интерес и мотивация.
Я в прошлом году тоже начал с часов на газоразрядных лампах, ничего не знал и не умел, да и програмировать на с тоже не умел, почти шесть месяцев делал. В конце конечно доделал, но пришлось упростить немного. Хотел сначала с dcf77 сделать, но не смог побороть помехи от блока питания, пришлось сделать просто с ds3231.
Может кому интересно www.youtube.com/user/sanshotur/videos
И я с автором не соглашусь, надо начинать именно с конкретного проекта. Из-за знания конечной цели не так сильно падает интерес и мотивация.
… надо начинать именно с конкретного проекта...
Насколько я понял автора, говоря про узлы периферии, он имел ввиду именно конкретные минималистические проекты, которые предназначены для изучения работы конкретных узлов периферии.
Например: работа с таймером, UART, PWM и тп, но все в отдельных проектах. А уже после приступать к более высоко-уровневым и сложным проектам.
Лично я, почти так же поступил когда-то:
Проанализировал свои идеи и разбил на составляющие узлы (механизмы), из чего понял какие мне нужны технологии периферии. Но я уже владел и Си, и Ассемблером.
А к словам автора, я бы добавил механизмы виртуализации разработок, как например Proteus.
Многие его ругают, но ИМХО это от недостатка знаний. Меня он пока не подводил.
Ведь для таких экспериментов и паять уметь не нужно (для начала конечно), а параллельно с этим изучить и уроки пайки.
И тогда успех будет сто процентным.
помоему у радиолюбителей часы это как у хирурга первое вскрытие.
О времена…
Когда то это был радиоприемник.
Darti спасибо за шикарный набор рекомендаций. Чётко и по делу.
Подскажите пожалуйста начинающему электронщику. Сам я программист, но интересуюсь изготовлением мелких девайсов на ардуинах(avr), так вот — разобраться с самими МК для меня относительно несложно(и платку вытравить и мк запрограммировать отдельно), но вот с аналоговой электроникой большие проблемы. По отдельности теоретически я понимаю как работает каждый аналоговый компонент (резистор, транзистор, диод, конденсатор, etc), но вот перешагнуть порог понимания «как работает вот этот набор деталей(схема)» никак не могу. Посоветуйте, пожалуйста, что почитать или сделать — чтобы попытаться приблизить это понимание.
А всё очень просто. Вот вы знаете, теоретически, как работает транзистор. Разопните его на макетке, понацепляйте переменных резисторов (ими удобно на лету всё регулировать), лампочку (не светодиод!) в цепь, мультиметр, и крутите, смотрите за поведением в разных включениях, вплоть до того, как не спалите. Только так до меня дошло, как он работает, хотя книг уйму читал. Правда было это в 7 классе :)
Ах да, как бы смешно это не звучало, нужно понимать закон Ома. Знает его любой школьник, а нужно именно понимать. Не посчитать ток в цепи (пусть даже в уме), или напряжение где какое, а просто интуитивно сказать, что будет, если какой-то номинал уменьшить/увеличить, или напряжение изменить. Не в числах, а просто в какую сторону что поплывёт. Это как наступить на край табуретки — упадёт она или нет? И когда и в какую сторону упадёт?
Смешно, но практика показывает, что очень много технически грамотных инженеров, даже работающих в близких к электронике сферах (например энергетика) этого не понимают. Знают, но не понимают.
Ах да, как бы смешно это не звучало, нужно понимать закон Ома. Знает его любой школьник, а нужно именно понимать. Не посчитать ток в цепи (пусть даже в уме), или напряжение где какое, а просто интуитивно сказать, что будет, если какой-то номинал уменьшить/увеличить, или напряжение изменить. Не в числах, а просто в какую сторону что поплывёт. Это как наступить на край табуретки — упадёт она или нет? И когда и в какую сторону упадёт?
Смешно, но практика показывает, что очень много технически грамотных инженеров, даже работающих в близких к электронике сферах (например энергетика) этого не понимают. Знают, но не понимают.
Скачайте LT-spice ( www.linear.com/designtools/software/#LTspice ).
Ну а далее по порядку:
— делитель напряжения
— RC-фильтр
— транзисторы
— операционники (аналоговые сумматоры и т.д.)
Ну а далее по порядку:
— делитель напряжения
— RC-фильтр
— транзисторы
— операционники (аналоговые сумматоры и т.д.)
Ключевое слово было упомянуто в статье — Хоровиц. Если полнее — Хоровиц и Хилл, «Искусство схемотехники». После прочтения новой главы проверять усвоенное применением на практике. В порядке увеличения сложности — усилитель низкой частоты, радиоприёмник, часы, терменвокс, миноискатель, шифровальная машина и так далее. Всё это делается безо всяких ардуин и с минимумом дополнительного оборудования.
Да, Хоровиц и Хилл.
Серия книг МРБ.
Я в свое время зачитывался этой — Шаг за шагом. Транзисторы. Сворень Р.А. От физики процессов до готовых схем, максимально простым языком и с картинками.
Серия «Шаг за шагом» и другие книги. Р. А. Сворень
Как бы странно не звучало, если хотите разобраться в основах — начинайте со старых книг, в новых упор уже идет на практику, без обьяснения зачем и почему так, на уровне «подключаем светодиод к ардуине и начинаем писать скетч».
Серия книг МРБ.
Я в свое время зачитывался этой — Шаг за шагом. Транзисторы. Сворень Р.А. От физики процессов до готовых схем, максимально простым языком и с картинками.
Серия «Шаг за шагом» и другие книги. Р. А. Сворень
Как бы странно не звучало, если хотите разобраться в основах — начинайте со старых книг, в новых упор уже идет на практику, без обьяснения зачем и почему так, на уровне «подключаем светодиод к ардуине и начинаем писать скетч».
Берёте детский конструктор типа такого и вперёд
http://masterkit.ru/shop/studygoods/assembly-kits/1927737
Я себе недавно такой прикупил ;-)
http://masterkit.ru/shop/studygoods/assembly-kits/1927737
Я себе недавно такой прикупил ;-)
Я могу порекомендовать издание «Полупроводниковая схемотехника» (в двух томах). Авторы — Ульрих Титце и Кристоф Шенк. Отличный справочник. Всё коротко, ясно и по делу — без лишней воды.
Я не совсем согласен с Вашим утверждением что успеха в создании конструкций на микроконтроллерах невозможно добится без изучения языка программирования. По Вашим выкладкам получается что разработчик должен быть этаким супер универсалом. В совершенстве знать языки програмирования (включая ассемблер), и при этом отлично разбираться в электронике и конструировании устройств. Честно говоря «Это фантастика сынок»(цитата). Слишком разные области знаний. Это давно уже поняли производители промышленных контроллеров, и создали свои специфические среды программирования, которые позволяют имено конструкторам-электронщикам создавать серьёзные системы управления. По роду своей деятельности я работаю как раз в обеих областях, и чаще всего втречаю программистов которые не имеют ни малейшего представления как работает транзистор, и инженеров для которых понятие «указатель на область памяти» — пустой звук. Причем и те и другие отличные проффесионалы в своей области. Что бы стать проффесионалов в каждой из этих областей, надо посвятить этому большую часть своей жизни, и на другую просто не останется времени.
Программисты используют микроконтроллеры на «поиграться», и поэтому большинство представленных на хабре постов о изделях от программистов с красивым кодом представляют собой игрушки. А представленные на гиктайме посты от хороших элетронщиков (реально полезные устройства) имеют код собранный с помощью копи-паста из примеров. Да и чаще всего электронщики шарахаются от контроллеров когда только заходит разговор об их программировании.
В свое время я начал проект (для себя любимого, и друзей) где попытался решить эту проблемму, и вот на третий год жизни проекта, я могу с уверенностью сказать, что тем же электронщикам надо только дать понятный им инструмент, и тогда они свернут горы. Они действительно создают полезный и законченные проекты начиная от промышленных станков, заканчивая управлением солнечными батареями. Я думаю что начав ломать свой мозг изучением того же си, они никогда бы не сделали того, что делают сейчас используя понятные инструменты.
Мое мнение -«Каждый должен нести свой чемодан»(опять цитата). Программисты пускай создают те самые инструменты — нормальные среды программирования для различных контроллеров (возьмите тот же TiaPortal от Siemens), а конструкторы с помощью этих инструментов уже будут создавать полезные устройства. Наверное такой симбиоз будет наиболее удачен.
Программисты используют микроконтроллеры на «поиграться», и поэтому большинство представленных на хабре постов о изделях от программистов с красивым кодом представляют собой игрушки. А представленные на гиктайме посты от хороших элетронщиков (реально полезные устройства) имеют код собранный с помощью копи-паста из примеров. Да и чаще всего электронщики шарахаются от контроллеров когда только заходит разговор об их программировании.
В свое время я начал проект (для себя любимого, и друзей) где попытался решить эту проблемму, и вот на третий год жизни проекта, я могу с уверенностью сказать, что тем же электронщикам надо только дать понятный им инструмент, и тогда они свернут горы. Они действительно создают полезный и законченные проекты начиная от промышленных станков, заканчивая управлением солнечными батареями. Я думаю что начав ломать свой мозг изучением того же си, они никогда бы не сделали того, что делают сейчас используя понятные инструменты.
Мое мнение -«Каждый должен нести свой чемодан»(опять цитата). Программисты пускай создают те самые инструменты — нормальные среды программирования для различных контроллеров (возьмите тот же TiaPortal от Siemens), а конструкторы с помощью этих инструментов уже будут создавать полезные устройства. Наверное такой симбиоз будет наиболее удачен.
Это не фантастика, а так и должно быть. Самые интересные работы находятся на стыке областей, и чтобы там преуспеть, надо хорошо разбираться в обоих.
Например, программирование и схемотехника (что покрывает по сути всю современную электронику, как промышленную, так и потребительскую). Или статистика и программирование (big data). Или программирование и финансы (high frequency trading).
А что на освоение двух предметных областей уйдёт не 10 лет, а 20 — так они всё равно уйдут.
Например, программирование и схемотехника (что покрывает по сути всю современную электронику, как промышленную, так и потребительскую). Или статистика и программирование (big data). Или программирование и финансы (high frequency trading).
А что на освоение двух предметных областей уйдёт не 10 лет, а 20 — так они всё равно уйдут.
Наверное так хорошо было-бы, но Вы то уже большой и наверное в сказки не верите. Возможно и есть уникумы которые могут осилить две разные области деятельности на высоком уровне, но чаще всего получается и не там и не тут высоких уровней нет. Как говорится за двумя зайцами погонишся… Жизнь требует сосредоточится на какой — то конкретной дороге. Кормить семью, и иметь работу надо сейчас а не через 20 лет. Поэтому в большинстве организаций занимающихся разработкой устройств на микроконтроллерах работают пары: программист+инженер-электронщик.
Как я уже писал выше, для создания систем АСУ производители промышленных контроллеров нашли выход позволяющий обойтись без программиста, и этот подход полностью себя оправдал. Но правда цены на такие контроллеры пугают.
Каждый должен заниматься тем что ему нравится, тогда и результат будет. Нравится писать код — пиши. Нравится рисовать схемы — рисуй. И не надо заставлять себя заниматься тем, к чему душа не лежит.
Я как раз и пробую дать возможность перевести программирование контроллера в привычную для электронщика процедуру создания принципиальной схемы, которая потом будет работать внутри контроллера. Ну не нужны им всякие if-ы, for-ы и т.д. Им нужны реле, контакты, реле сравнения. Ну или компараторы, дешифраторы, тригеры… В этом они хорошо понимают. Ну а задача программиста создать им инструмент который поможет им это делать. Потому что научить программиста например расчёту помехозащищённости, или расчёту выходного силового ключа то же сложная задача. Если он справится, честь и хвала ему, ну а если не справится, то такое изделие (которое сгорит после 10 пусков) и не нужно.
Как я уже писал выше, для создания систем АСУ производители промышленных контроллеров нашли выход позволяющий обойтись без программиста, и этот подход полностью себя оправдал. Но правда цены на такие контроллеры пугают.
Каждый должен заниматься тем что ему нравится, тогда и результат будет. Нравится писать код — пиши. Нравится рисовать схемы — рисуй. И не надо заставлять себя заниматься тем, к чему душа не лежит.
Я как раз и пробую дать возможность перевести программирование контроллера в привычную для электронщика процедуру создания принципиальной схемы, которая потом будет работать внутри контроллера. Ну не нужны им всякие if-ы, for-ы и т.д. Им нужны реле, контакты, реле сравнения. Ну или компараторы, дешифраторы, тригеры… В этом они хорошо понимают. Ну а задача программиста создать им инструмент который поможет им это делать. Потому что научить программиста например расчёту помехозащищённости, или расчёту выходного силового ключа то же сложная задача. Если он справится, честь и хвала ему, ну а если не справится, то такое изделие (которое сгорит после 10 пусков) и не нужно.
Во-первых необязательно знать обе области на самом высоком уровне. Так действительно бывает редко. Но если программист не знает закон Ома, а электронщик не умеет написать цикл, то в embedded им обоим делать нечего. Никаких сверхестественных способностей для этого не надо, любой выпускник нормального ВУЗа вполне может справиться с электроникой в пределах Хоровица и Хилла и программированием в пределах трупа Страуса.
Во-вторых никто не заставляет сначала 20 лет учиться, а только потом работать. Это делается одновременно. Просто если только писать код (особенно на одном языке, в одной среде разработки и той же самой предметной области), то можно очень легко и быстро остаться без работы. Окулист или водопроводчик без работы не останется, а попробуйте сейчас найти позицию программиста на языке GOC в операционной системе GEOS. Пример, кстати, взят из реальной жизни.
Ну и заодно давайте я вам сэкономлю немного времени. Попытки сделать визуальную среду программирования для непрограммистов предпринимались неоднократно и все они окончились безуспешно. Потому что загвоздка там не в том, соединять квадратики линиями или писать if.
Во-вторых никто не заставляет сначала 20 лет учиться, а только потом работать. Это делается одновременно. Просто если только писать код (особенно на одном языке, в одной среде разработки и той же самой предметной области), то можно очень легко и быстро остаться без работы. Окулист или водопроводчик без работы не останется, а попробуйте сейчас найти позицию программиста на языке GOC в операционной системе GEOS. Пример, кстати, взят из реальной жизни.
Ну и заодно давайте я вам сэкономлю немного времени. Попытки сделать визуальную среду программирования для непрограммистов предпринимались неоднократно и все они окончились безуспешно. Потому что загвоздка там не в том, соединять квадратики линиями или писать if.
Насчет неудачных попыток Вы можете спросить у того -же Simens, Schneider, ABB и др. Большинство настоящих систем управления производством, да и практически любая автоматизированная система написана как раз с помощью сред где как Вы говорите «надо соединять квадратики». Хотя в этой фразе всё таки чувствуется программист. Для Вас всё что не связанно с написанием многих «буковок» — это детские забавы. А тут не просто детские забавы — это создание принципиальной схемы, как раз то, в чем электронщики сильны. А вот для программиста — это действительно соединение между собой непонятных квадратиков
Очень тяжело работать с программистом, который не знает, не хочет знать и не собирается узнать, что такое регистры, буферы, триггеры, и почему может быть по одному и тому же адресу на запись доступ к одной сущности, а на чтение — к другой, когда по схеме это более чем очевидно. Приходится тратить массу времени — два-три рабочих дня целиком — чтобы составить ему подробную карту памяти устройства на запись и чтение. На этапе отладки макета это непозволительная роскошь, потому что при перестройке прибора под изменяющиеся на лету требования вся эта бумага будет урнирована и переписана заново. С программистом, умеющим хорошо читать и хотя бы хреновенько писать схемы просто сидишь рядом и пальцем показываешь: выгода — пять секунд против двух дней.
Очень некомфортно работать со схемотехником, которому пофигу на твои карты памяти (тебе надо — ты и рисуй, а я не знаю что это и зачем), который изобретает фильдиперстовые решения, разбивающие простую последовательность адресов, например, без особой выгоды.
Короче, если один в паре абсолютно «не шарит» в соседской области, второму придется быть спецом в обеих областях, если оба «специалиста» сверхузкие — нужен третий в роли переводчика. Реально дешевле научить обоих видеть чуть-чуть шире своей норки.
И таки да, результат «единоличника», который сам схему рисует и сам программу пишет, получается обычно самым эффективным и самым сопровождаемым, даже при том, что человек не собирался передавать на сопровождение, и делать этого не умеет и не любит. Однако же, разобраться в его творчестве несколько проще. Но таких, да, мало.
Очень некомфортно работать со схемотехником, которому пофигу на твои карты памяти (тебе надо — ты и рисуй, а я не знаю что это и зачем), который изобретает фильдиперстовые решения, разбивающие простую последовательность адресов, например, без особой выгоды.
Короче, если один в паре абсолютно «не шарит» в соседской области, второму придется быть спецом в обеих областях, если оба «специалиста» сверхузкие — нужен третий в роли переводчика. Реально дешевле научить обоих видеть чуть-чуть шире своей норки.
И таки да, результат «единоличника», который сам схему рисует и сам программу пишет, получается обычно самым эффективным и самым сопровождаемым, даже при том, что человек не собирался передавать на сопровождение, и делать этого не умеет и не любит. Однако же, разобраться в его творчестве несколько проще. Но таких, да, мало.
Я как раз и пробую дать возможность перевести программирование контроллера в привычную для электронщика процедуру создания принципиальной схемы, которая потом будет работать внутри контроллера. Ну не нужны им всякие if-ы, for-ы и т.д. Им нужны реле, контакты, реле сравнения. Ну или компараторы, дешифраторы, тригеры…И зачем таким электронщикам вообще контроллеры? Пусть рисуют схемы для ПЛИС, в графическом режиме.
И зачем таким электронщикам вообще контроллеры? Пусть рисуют схемы для ПЛИС, в графическом режиме.
А зачем программистам микроконтроллеры? Пускай программируют однопалатные компьютеры.
А зачем электронщикам контроллеры, можете спросить любого из нескольких тысяч пользователей программы. Зайдите на сайт (flprog.ru), почитайте форум, посмотрите статьи пользователей. Посмотрите что делают люди совершенно не знакомые с программированием в классическом смысле. На 99% это законченные и приносящие пользу изделия. В отличие от игрушек настоящих программистов.
Вот да, многие забывают что и ПЛИС и МК работают не внутри симуляторов в их компьютерах, а в реальном мире. И получается, что вроде бы и идея интересная, и по функционалу и по реализации довольно интересно, а схему глянешь — и ужасаешься тому, что даже питание того же МК реализовано мягко говоря странно, или сигнальные линии длинной в десять метров заведены напрямик на порты, безо всякой защиты.
Да, оно работает. Но беда в том, что симуляторы от реальности отличаются очень сильно, и чистому программисту это понять очень непросто.
Да, оно работает. Но беда в том, что симуляторы от реальности отличаются очень сильно, и чистому программисту это понять очень непросто.
А зачем программистам микроконтроллеры? Пускай программируют однопалатные компьютеры.А тут вопрос, что понимать под одноплатными компьютерами. В нашем случае, их и программируют, собственно. Программирование голого контроллера никого не интересует, интересует устройство (разработанное схемотехником), реализующее некоторый алгоритм (запрограммированный программистом). Если при этом алгоритм можно выразить схемой — нафиг маяться, пусть это делает ПЛИС, у нее и быстродействие будет поинтереснее. Помнится, пробовали посчитать CRC16 килобайтных блоков последовательного кода программно и на ПЛИС… А вот оцифрованный сигнал, скажем, обработать — тут без программиста тяжело будет. Поэтому у нас, например, платы имеют два основных элемента — ПЛИС (иногда не одна) и процессор/контроллер. И всем работы хватает — одни рисуют, другие пишут :-)
Описанный вами набор навыков называется «разработчик встраиваемых систем». И они таки существуют, эти разработчики!
Бестолковые советы. Начинать всегда надо с азбуки, а лучше с поиска единомышленников, которые и азбуку объяснят, и помоями поливать не будут. Найдите учителя, и будет вам счастье.
Увидел много жизненных советов…
А какой кримпер посоветует автор?
А какой кримпер посоветует автор?
Не постесняюсь: geektimes.ru/post/256948
Супер статья, подпишусь почти под всем. Единственное, не надо путать C и C++ — это совсем разные языки с похожим синтаксисом. И платы не обязательно на клеммах собирать — можно заказывать изготовление. Это чуть дороже, но во-первых не сильно, а во-вторых работать с качественной платой в разы приятнее и проще.
Нынче писать на чистом C имеет смысл разве что предельно простые программы с пять-десятью раздельными переменными и несколькими функциями. Если возникает хоть одна сущность, для работы с которой делается хотя бы пара-тройка функций — уже стоит подумать о C++.
Контроллеры разные бывают. На некоторых даже накладные расходы на чистый Си отъедят половину памяти.
В правильно организованной системе «компилятор+линкер+библиотеки» накладные расходы определяются потребностями программы. Никто ж не заставляет использовать исключения, RTTI и прочие «тяжелые» возможности языка. А программа на C++, в которой функции-члены оперируют данными-членами, будет почти побайтно идентичной программе на чистом C, где обычные функции оперируют полями структуры.
Другое дело, что бывают неудачные CRT-стартапы, которые даже в минимальном варианте тянут из библиотек много лишнего. Профессионалу нетрудно призвать их к порядку, но для новичка это действительно не годится.
Другое дело, что бывают неудачные CRT-стартапы, которые даже в минимальном варианте тянут из библиотек много лишнего. Профессионалу нетрудно призвать их к порядку, но для новичка это действительно не годится.
К спору о необходимости знания программирования — оно так да, действительно нужно. Но следует понимать границы погружения в язык для решения конкретных проблем. Я сам люблю с утра озадачить коллег — молодых инженеров вопросом «Знаете ли Вы язык С?» Наученные горьким опытом, они сразу признаются, что не знают, и я показываю какой-нибудь трюк типа тернарного оператора слева от равенства. Но такое погружение совершенно необязательно и они замечательно пишут необходимые нам программы.
С другой стороны, хоть я и не разделяю пренебрежительного отношения к «ардуинщикам», тем не менее среди них имеется значительное количество людей, которые не знают, и, самое ужасное, не собираются узнавать, что именно происходит при выполнении той или иной стандартной библиотечной функции. Это еще можно было бы простить, если бы подобные «создатели электронных устройств» оставляли свои чудесные произведения для внутреннего употребления, но они их выкладывают на всеобщее обозрение и лично у меня, кроме чувства тягостного недоумения, данные экзерсисы (надо бы словечко похлеще, тоже с буквы э, ну да ладно) не вызывают. Самое ужасное, когда подобные творения проползают в фирменные примеры, вот это уже край.
С другой стороны, хоть я и не разделяю пренебрежительного отношения к «ардуинщикам», тем не менее среди них имеется значительное количество людей, которые не знают, и, самое ужасное, не собираются узнавать, что именно происходит при выполнении той или иной стандартной библиотечной функции. Это еще можно было бы простить, если бы подобные «создатели электронных устройств» оставляли свои чудесные произведения для внутреннего употребления, но они их выкладывают на всеобщее обозрение и лично у меня, кроме чувства тягостного недоумения, данные экзерсисы (надо бы словечко похлеще, тоже с буквы э, ну да ладно) не вызывают. Самое ужасное, когда подобные творения проползают в фирменные примеры, вот это уже край.
Simens выпускают газотурбинные генераторы. И вы не поверите, но во всей прошивке для всех контроллеров которые управляют турбиной нет ни строчки кода. А только чарты (схемы по нашему). Разработчики этой системы не имеют ни малейшего представления какой код крутится в контроллерах. Я лично общался и с разработчиками, и с сервисниками и поэтому знаю об этом. И представляете, они эти поделки не только не прячут, а ещё и продают по всему миру. Вот ужас то!!! И так во всех промышленных системах. Как ни странно их разрабатывают инженеры — электронщики, а не программисты. Куда катится мир.
Вот ужас то — программы для Тойота разрабатывали тоже инженеры-электронщики и сколько за это Тойоте пришлось отстегнуть? Куда катится мир.
А вот для того, чтобы разработчики квадратиков для ПЛК могли ничего не понимать в происходящем, большие группы людей, которые в совершенстве владеют программированием и понимают ВСЕ процессы в железе делали операционную среду и разрабатывали максимально надежные методы ее программирования на уровне квадратиков.
Ну и напоследок — сообщите публике, сколько стоит ПЛК фирмы Siemens (я то знаю, а вот многие будут неприятно Вашими цифрами удивлены), сколько стоит лицензия на кодогенератор для этих ПЛК, каковы условия поддержки изделий от этой фирмы, и, я надеюсь, читатели поймут, что рекламируемая Вами продукция и метод программирования совершенно для них не подходит.
Ролс-Ройс, конечно, отличный автомобиль, но немногие могут себе его позволить.
А вот для того, чтобы разработчики квадратиков для ПЛК могли ничего не понимать в происходящем, большие группы людей, которые в совершенстве владеют программированием и понимают ВСЕ процессы в железе делали операционную среду и разрабатывали максимально надежные методы ее программирования на уровне квадратиков.
Ну и напоследок — сообщите публике, сколько стоит ПЛК фирмы Siemens (я то знаю, а вот многие будут неприятно Вашими цифрами удивлены), сколько стоит лицензия на кодогенератор для этих ПЛК, каковы условия поддержки изделий от этой фирмы, и, я надеюсь, читатели поймут, что рекламируемая Вами продукция и метод программирования совершенно для них не подходит.
Ролс-Ройс, конечно, отличный автомобиль, но немногие могут себе его позволить.
Вот я и предлагаю программистам заниматься своим делом, разрабатывая те самые среды разработки для электронщиков. Только для недорогих контроллеров. Примеры есть. Проект Horizont Automatics, Canny (но у них свой контроллер и цена высоковата), ну и мой проект FLProg. Это только Российские проекты. Horizont Automatics и FLProg бесплатны. Рассчитаны на недорогие ардуинки (хотя я потихоньку готовлюсь к расширению списка контроллеров).
Так что можно обойтись без дорогих промышленных контроллеров, взяв от них самое ценное — проверенные годами графические языки. Нужно только желание программистов заняться создание подобных сред, ну и не драть за них большие деньги.
Но к сожалению большинство программистов сегодня пишут «Весёлые фермы», всякие онлайн стратегии, и т.п. Ведь за них при небольших умственных и физических затратах можно стрясти с хомячков неплохие деньги.
Так что можно обойтись без дорогих промышленных контроллеров, взяв от них самое ценное — проверенные годами графические языки. Нужно только желание программистов заняться создание подобных сред, ну и не драть за них большие деньги.
Но к сожалению большинство программистов сегодня пишут «Весёлые фермы», всякие онлайн стратегии, и т.п. Ведь за них при небольших умственных и физических затратах можно стрясти с хомячков неплохие деньги.
Еще раз — не следует смешивать горькое с холодным.
Когда речь идет о ПЛК, то там действительно вылизанная годами исполняющая система и программирование на уровне схем автоматики, причем для решения профессионалами в денной предметной области строго определенного (и весьма ограниченного) круга задач с высокой надежностью.
Когда же речь идет о МК, то 1)здесь круг задач намного более широк, 2) уровень вхождения для языка схем автоматики весьма высок (на мой взгляд, запределен) — как в вашем случае, либо 3) графическое программирование превращается в язык блок-схем, что вообще не имеет права на существование, но это не Ваш случай.
Хотя определенные задачи, типа управления термостатом, однозначно приводимые к схемам автоматики, вполне можно программировать и на Вашем языке (я попробовал — получилось, но я все-таки не типовой пользователь), но нужно очень хорошо понимать ограничения данного метода.
А впрочем — пусть расцветают сто цветов, кому-то и пригодится, просто мне не очень понравился Ваш посыл
Ну а по поводу
Когда речь идет о ПЛК, то там действительно вылизанная годами исполняющая система и программирование на уровне схем автоматики, причем для решения профессионалами в денной предметной области строго определенного (и весьма ограниченного) круга задач с высокой надежностью.
Когда же речь идет о МК, то 1)здесь круг задач намного более широк, 2) уровень вхождения для языка схем автоматики весьма высок (на мой взгляд, запределен) — как в вашем случае, либо 3) графическое программирование превращается в язык блок-схем, что вообще не имеет права на существование, но это не Ваш случай.
Хотя определенные задачи, типа управления термостатом, однозначно приводимые к схемам автоматики, вполне можно программировать и на Вашем языке (я попробовал — получилось, но я все-таки не типовой пользователь), но нужно очень хорошо понимать ограничения данного метода.
А впрочем — пусть расцветают сто цветов, кому-то и пригодится, просто мне не очень понравился Ваш посыл
Чтобы программировать микроконтроллеры не обязательно знать языки программирования!как рекламный слоган — неплохо, как руководство к действию — сомнительно.
Ну а по поводу
при небольших умственных и физических затратахэто вы погорячились, у меня есть знакомые в этой индустрии и там конкуренция за хомячков дичайшая, без киллер-фичи никаких шансов, да и с ней не очень много.
Еще раз — не следует смешивать горькое с холодным.
А чем отличается ПЛК и микроконтроллер? ПЛК — это микроконтроллер+входные развязки+выходные ключи или выходные реле. Часто добавляют простенький дисплей, ну и интерфейсы выводят.
Круг задач решаемых графическими языками практически не ограничен, что опять таки доказано годами эксплуатации действительно больших систем автоматизации. Управление той — же турбиной — это далеко не термостат. По крайней мере использовать все возможности микроконтроллера вполне можно.
уровень вхождения для языка схем автоматики весьма высок
Для кого? Электронщик пользуясь этим языком находится в привычном окружении и пользуется привычными знаниями и терминами. Он занимается своей обычной работой, то есть просто создаёт схему.
Для программиста который разрабатывает данную среду? Ну Вы же призываете электронщиков изучать непонятные для них языки программирования. Причем для создания законченных изделий им необходимо изучить язык на достаточно серьёзном уровне. Так почему бы программисту не освоить хотя бы азы электроники что бы понимать чем отличается Т-триггер от RS-триггера.
Ну а мой посыл опять таки оправдан большим опытом в разработке промышленной автоматики. Обычное программирование для меня хобби, и я не считаю себя професионалом — программистом. Все таки я больше конструктор-схемотехник. И людей в среде разработчиков систем АСУ, которые являются обычными программистами — единицы. Но между тем заводы работают, электростанции выдают электроэнергию, котельные дают тепло.
Может это надо было сказать где-то выше по ветке, но скажу здесь.
Вы сейчас спорите о том что лучше функциональный язык или императивный.
На системы промавтоматики очень хорошо ложится функциональный язык программирования — схемы на него переводятся один в один. И ваши инженеры-схемотехники таки становятся программистами-функциональщиками просто не задумываясь об этом.
Но попробуйте поработать в условиях ограниченных ресурсов с большим объёмом данных, где нужно обрабатывать данные последовательно, по очереди т.к. весь кусок просто не помещается в доступную память или решение получается слишком дорогим и функциональный язык проигрывает императивному.
Автоматика на производстве это хорошо, но почему-то когда речь идёт о мультимедиа — вывод графики и звука блок-схемы становятся очень неудобными, а императивный подход становится очень простым и наглядным.
Вы сейчас спорите о том что лучше функциональный язык или императивный.
На системы промавтоматики очень хорошо ложится функциональный язык программирования — схемы на него переводятся один в один. И ваши инженеры-схемотехники таки становятся программистами-функциональщиками просто не задумываясь об этом.
Но попробуйте поработать в условиях ограниченных ресурсов с большим объёмом данных, где нужно обрабатывать данные последовательно, по очереди т.к. весь кусок просто не помещается в доступную память или решение получается слишком дорогим и функциональный язык проигрывает императивному.
Автоматика на производстве это хорошо, но почему-то когда речь идёт о мультимедиа — вывод графики и звука блок-схемы становятся очень неудобными, а императивный подход становится очень простым и наглядным.
Ну вообще то я электронщик и язык автоматики ну никак не входит в мой повседневный багаж, то есть я его понимаю, но это все-таки никак не схема в привычном понимании слова, а скорее описание алгоритма.
Что же касается нетривиальных задач, не сводимых к «включить на время до условия/ выключить на время», то реализация их на базе графических языков — весьма и весьма непроста. На мой взгляд — так и невозможна (конечно, «невозможно только спать на потолке», все остальное только вопрос затраченного времени, но зачем «чесать левой ухо правой рукой, пропустив ее под коленкой левой ноги») до тех пор, когда кто то для Вас не нарисует квадратик, выполняющий нужную Вам сложную функцию либо общение с интерфейсом.
Можете на досуге попробовать нарисовать конечный автомат, который реализует последовательный обмен с прибором класса WS2811, и лучше бы не в терминах регистров, в в терминах предлагаемого Вами программного продукта, потом сделайте то же самое на Verilog и на C, и потом сравните, что проще в понимании. Для меня результат очевиден, я владею всеми 4 инструментами, и предпочитаю писать на С (оставляя первые три способа для ПЛИС), но Вы можете попробовать.
Есть такое выражение — «каждый язык для своей задачи» и оно в данном случае справедливо, как никогда.
Что же касается нетривиальных задач, не сводимых к «включить на время до условия/ выключить на время», то реализация их на базе графических языков — весьма и весьма непроста. На мой взгляд — так и невозможна (конечно, «невозможно только спать на потолке», все остальное только вопрос затраченного времени, но зачем «чесать левой ухо правой рукой, пропустив ее под коленкой левой ноги») до тех пор, когда кто то для Вас не нарисует квадратик, выполняющий нужную Вам сложную функцию либо общение с интерфейсом.
Можете на досуге попробовать нарисовать конечный автомат, который реализует последовательный обмен с прибором класса WS2811, и лучше бы не в терминах регистров, в в терминах предлагаемого Вами программного продукта, потом сделайте то же самое на Verilog и на C, и потом сравните, что проще в понимании. Для меня результат очевиден, я владею всеми 4 инструментами, и предпочитаю писать на С (оставляя первые три способа для ПЛИС), но Вы можете попробовать.
Есть такое выражение — «каждый язык для своей задачи» и оно в данном случае справедливо, как никогда.
Эти контроллеры гарантируют срабатывание автоматики в жёстко реальном времени. Если ваша конфигурация слишком сложная, чтобы эту гарантию предоставить, программа просто не «скомпилируется». То же самое можно, естественно, сделать и на языке общего назначения, но это требует очень высокой квалификации программиста. Один программист наворотит какой-нибудь модный асинхронный движок, другой хитрую систему обработки прерываний, третий где-нибудь напишет неэффективный код, который может задержать критическую операцию и т.д. — вариантов выстрелить себе в ногу — миллион. А если у вас газотурбинный генератор, то сбой софта стоит очень много денег. Я уж не говорю про сбой в какой-нибудь ABS в машине — это вообще жизней стоить может.
Не согласен с тем, что конкретный проект не нужен. Сделать часы это идеальная для обучения задача.
Опять же, про C++ в embedded ни слова. Constexpr и статический полиморфизм как будто созданы специально для микроконтроллеров. Получаем легко читаемый и переносимый код без оверхеда.
Опять же, про C++ в embedded ни слова. Constexpr и статический полиморфизм как будто созданы специально для микроконтроллеров. Получаем легко читаемый и переносимый код без оверхеда.
Очень вовремя в начале года. Просто снимаю шляпу.
Расскажу про реальные проблемы старта. Может быть вы поможете мне реальным советом или ссылкой а может скажете, что я ленив в своих поисках и в таком случае поможете просто пинком. В любом случае результат есть результат.
Присказка:
У меня есть конкретная цель-2016 «программировать „микроконтроллеры“, паять платы.
Целей достигать я умею: бюджет выделен, время заложено. В запасе имеется знание скриптовых языков(я админ), общая техническая подкованность, сбор неких простых (однако полезных мне) arduino-содержащих устройств (в вышеописанном стиле, скопировал-вставил, отладил, заработало).
Однако нет какого-то конкретного плана. Об это всё разбивается.
Поясню. Попытки стартовать обламываются примерно так:
Пример 1:
У меня есть под рукой советская „схемотехника“ 80ых годов издания. Я честно и трудолюбиво сажусь за неё. Однако с первых страниц описание уходит в очень дебри. Интуитивно я чувствую, что мне достаточного 20% этой информации сейчас, а вернуться к этим страницам стоит уже после. И так с многой литературой и даже тем что гуглится — нет постепенного погружения. Идеально: дайте мне закон ома, заставьте спать к нему простейшую схему поиграть и почувствовать(!), спалить светодиод и я готов идти к более сложному.
Пример два.
Я хочу хорошо паять, на текущий момент я могу спаять провода между собой, я могу поменять конденсатор в материнской плате. Однако (например) когда я припаиваю чип у меня между ножек получается месиво. Через три часа я с грехом пополам добиваюсь желаемого, проклянув всех и вся. Позже я узнаю что сейчас есть 100500 различных флюсов припоев флюсоотсосов, подходящих жал для паяльной станции, флюсов-гелей и прочих примочек и каждую имеет смысл использовать в своём случае. Достаточно было прихватить крайние ножки, провести раствором по остальным, взять другой припой и за 10 минут чип был припаян идеально. Хорошо что узнал хоть потом.
Однако систематизировано, данную информацию найти я не могу. Идеально: Урок NN, задача — распаиваем пяем мк, инструмент — //такой-то//, расходники — //такие-то//.
Итог:
Без какой-то систематизации своего обучения, заход в эту тему превращается в постоянные грабли.
Автор и комментаторы, поделитесь опытом как вы заходили в эту воду?
Расскажу про реальные проблемы старта. Может быть вы поможете мне реальным советом или ссылкой а может скажете, что я ленив в своих поисках и в таком случае поможете просто пинком. В любом случае результат есть результат.
Присказка:
У меня есть конкретная цель-2016 «программировать „микроконтроллеры“, паять платы.
Целей достигать я умею: бюджет выделен, время заложено. В запасе имеется знание скриптовых языков(я админ), общая техническая подкованность, сбор неких простых (однако полезных мне) arduino-содержащих устройств (в вышеописанном стиле, скопировал-вставил, отладил, заработало).
Однако нет какого-то конкретного плана. Об это всё разбивается.
Поясню. Попытки стартовать обламываются примерно так:
Пример 1:
У меня есть под рукой советская „схемотехника“ 80ых годов издания. Я честно и трудолюбиво сажусь за неё. Однако с первых страниц описание уходит в очень дебри. Интуитивно я чувствую, что мне достаточного 20% этой информации сейчас, а вернуться к этим страницам стоит уже после. И так с многой литературой и даже тем что гуглится — нет постепенного погружения. Идеально: дайте мне закон ома, заставьте спать к нему простейшую схему поиграть и почувствовать(!), спалить светодиод и я готов идти к более сложному.
Пример два.
Я хочу хорошо паять, на текущий момент я могу спаять провода между собой, я могу поменять конденсатор в материнской плате. Однако (например) когда я припаиваю чип у меня между ножек получается месиво. Через три часа я с грехом пополам добиваюсь желаемого, проклянув всех и вся. Позже я узнаю что сейчас есть 100500 различных флюсов припоев флюсоотсосов, подходящих жал для паяльной станции, флюсов-гелей и прочих примочек и каждую имеет смысл использовать в своём случае. Достаточно было прихватить крайние ножки, провести раствором по остальным, взять другой припой и за 10 минут чип был припаян идеально. Хорошо что узнал хоть потом.
Однако систематизировано, данную информацию найти я не могу. Идеально: Урок NN, задача — распаиваем пяем мк, инструмент — //такой-то//, расходники — //такие-то//.
Итог:
Без какой-то систематизации своего обучения, заход в эту тему превращается в постоянные грабли.
Автор и комментаторы, поделитесь опытом как вы заходили в эту воду?
Азбука, библия и камасутра — это Хоровиц и Хилл, «Искусство схемотехники». А «поиграть и почувствовать» — это книжки из серии МРБ (массовая радиобиблиотека), особенно выпуски, ориентированные на «чайников», с игрушками типа простых одноголосвх музыкальных инструментов, датчиков наполнения ванны и т. п. Мои первые опыты были по книжке Б. С. Иванов «Электронные игрушки» из упомянутой серии, «Радио и связь», 1988 г.
насчет «программировать „микроконтроллеры“, паять платы» — для побаловаться с USB (программировать и паять я более-менее умею) я взял контроллер подешевле с возможностью внутрисхемного программирования по USB, спаял банальную схему из даташитки, к портам данных подключил светодиоды и кнопки по рекомендациям из той же даташитки. Плату рисовал утюгом, для четвертьмиллиметровых лап этой технологии хватает. Простое HID-устройство было собрано и заработало (спасибо Агурову) меньше, чем за неделю.
Что касается «паять» — ну, тут надо паять. Сорокаватным паяльником на 220 В со спиртоканифольным самодельным флюсом я паял корпуса VQFP (AT89C5131, месье не знает толк в извращениях, месье нищ и не имеет паяльной станции). Это приходит в основном с опытом. А вообще, чем тоньше «лапы» — тем более легкоплавкий желательно припой и тем тоньше жало. Температуру жала тоже надо держать в правильных пределах — сперва по рекомендациям умных книжек, потом по опыту. А флюс проще и дешевле всего — толченая канифоль в спирте, другие не настолько лучше, насколько дороже. Единственное, если, не дай бог, аллергия на дым канифоли — флюс придется подбирать по себе экспериментально, бывают случаи.
насчет «программировать „микроконтроллеры“, паять платы» — для побаловаться с USB (программировать и паять я более-менее умею) я взял контроллер подешевле с возможностью внутрисхемного программирования по USB, спаял банальную схему из даташитки, к портам данных подключил светодиоды и кнопки по рекомендациям из той же даташитки. Плату рисовал утюгом, для четвертьмиллиметровых лап этой технологии хватает. Простое HID-устройство было собрано и заработало (спасибо Агурову) меньше, чем за неделю.
Что касается «паять» — ну, тут надо паять. Сорокаватным паяльником на 220 В со спиртоканифольным самодельным флюсом я паял корпуса VQFP (AT89C5131, месье не знает толк в извращениях, месье нищ и не имеет паяльной станции). Это приходит в основном с опытом. А вообще, чем тоньше «лапы» — тем более легкоплавкий желательно припой и тем тоньше жало. Температуру жала тоже надо держать в правильных пределах — сперва по рекомендациям умных книжек, потом по опыту. А флюс проще и дешевле всего — толченая канифоль в спирте, другие не настолько лучше, насколько дороже. Единственное, если, не дай бог, аллергия на дым канифоли — флюс придется подбирать по себе экспериментально, бывают случаи.
Канифоль хорошо работает только на низких температурах, безсвинцовым припоем с её помощью паять невозможно — быстро пригорает и испаряется.
Я бы эти цели разделил.
Цель 1 — «программировать „микроконтроллеры“
Зачем Вам для этого паять вообще? Определитесь с платформой (AVR, STM32, PIC еще что-то). Для простых проектов я использую AVR, для чего-то более сложного — STM32.
Затем, как правильно заметил автор, начинайте осваивать периферию контроллера (AVR в этом плане весьма несложный вариант, так как инициализация периферии попроще).
Начните с GPIO, USART, читайте даташит на эти части, осваивайте IDE.
Я года полтора назад затевал серию образовательных мероприятий в местном клубе инженеров, по модному именуемом хакерспейсом.
Ссылка на 1-й семинар, может будет полезна.
На начальном этапе можно даже не касаться железа вообще, собрать схему в том же Proteus (если мы говорим об AVR, STM32 он пока не поддерживает, на сколько мне известно). Второй вариант — купить любую ардуину начального уровня, но использовать ее как обычную отладочную плату и шить через ISP. У STM32 в этом плане есть плюс — вшитый бутлоадер.
Когда разберетесь с периферией, придумайте себе несложную задачу и пробуйте ее развивать.
Параллельно можно решать вторую задачу, купить готовый радиоконструктор на алиэкспрессе или местном рынке, попробовать его собрать и настроить, как-то так :)
Цель 1 — «программировать „микроконтроллеры“
Зачем Вам для этого паять вообще? Определитесь с платформой (AVR, STM32, PIC еще что-то). Для простых проектов я использую AVR, для чего-то более сложного — STM32.
Затем, как правильно заметил автор, начинайте осваивать периферию контроллера (AVR в этом плане весьма несложный вариант, так как инициализация периферии попроще).
Начните с GPIO, USART, читайте даташит на эти части, осваивайте IDE.
Я года полтора назад затевал серию образовательных мероприятий в местном клубе инженеров, по модному именуемом хакерспейсом.
Ссылка на 1-й семинар, может будет полезна.
На начальном этапе можно даже не касаться железа вообще, собрать схему в том же Proteus (если мы говорим об AVR, STM32 он пока не поддерживает, на сколько мне известно). Второй вариант — купить любую ардуину начального уровня, но использовать ее как обычную отладочную плату и шить через ISP. У STM32 в этом плане есть плюс — вшитый бутлоадер.
Когда разберетесь с периферией, придумайте себе несложную задачу и пробуйте ее развивать.
Параллельно можно решать вторую задачу, купить готовый радиоконструктор на алиэкспрессе или местном рынке, попробовать его собрать и настроить, как-то так :)
Про самопальные платы особенно согласен, один товарищ взялся даже студентов учить микроконтроллерам и начал с самопальной отладочной платы под atmega на утюге, хотелось применить грубую физическую силу.
Статья для дошкольников =(
Я просто в ступоре от того, насколько абсолютно неграмотные люди обуреваемы страстью кгого-либо пообучать.
Ни разу не встречал необщительных, сердитых и раздражительных радиолюбителей. Радиолюбитель для меня тот, кто проводит радиосвязи и конструирует аппаратуру в первую очередь. Среди них описанных типажей не встречал. Совершенно незнакомые люди очень общительны и приходят на помощь, естественно и зарубежные тоже.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Советы начинающим программистам микроконтроллеров