1. Многие начинающие электронщики не знают с чего начать, поэтому спрашивают совета. Большинство бывалых радиолюбителей ответят, что начни собирать какую нибудь схему. Естественно в голове любого начинающего сразу мелькает LCD дисплей с jpeg картинками, какой нибудь mp3 плеер или часы, без малейшей мысли о том, что не имея базовых знаний это неподъемная задача.
Я категорически против такого подхода. Обычно это все заканчивается — либо ничем, либо забитые форумы с мольбами помочь. Даже если кому то помогают, то в 90% он больше никогда не всплывет на сайтах по электронике. В остальных 10% он так и продолжает заливать форумы мольбами, его будут сначала пинать, затем поливать грязью. Из этих 10% отсеивается еще 9%. Далее два варианта: либо таки до глупой головы доходит и все же происходит goto к началу, либо в особо запущенных вариантах, его удел копировать чужие конструкции, без единой мысли о том как это работает. Из последних зачастую рождаются ардуинщики.
Путь с нуля на мой взгляд заключается в изучении периферии и особенностей, если это микроконтроллер. Правильнее сначала разобраться с тем как дрыгать ножками, потом с таймерами, затем интерфейсами. И только тогда пытаться поднимать свой FAT. Да это не быстро, да это потребует времени и усилий, но практика показывает, как бы вы не пытались сократить этот путь, все равно всплывут проблемы, которые придется решать и время вы потратите куда больше, не имея этой базы.
Только не нужно путать теплое и мягкое. Первое — из всех правил есть исключения, лично видел людей, которые в руках раньше не держали микроконтроллеров, но за крайне короткий срок смогли обскакать бывалых опытных радиолюбителей, их в расчет не берем. Второе — мне попадались личности, которые начинали с копирования схем и сходу разбирались, но скорее это тоже исключение из правил. Третье — и среди ардуинщиков попадаются опытные программисты, это ведь всего навсего платформа, но и это скорее исключение.
Если говорить об общей массе, то дела обстоят именно так как я описал вначале: нежелание разбираться с основами, в лучшем случае оттягивает момент того, когда придется вернуться к этим вопросам. В худшем случае, вы быстро упретесь в потолок своих знаний и все время винить в своих проблемах кого то другого.
2. Перед решением задачи, дробите ее до абсурда вплоть до «припаять резистор», это помогает, проверено. Мелкие задачи решать куда проще. Когда большая задача разбита на кучу мелких действий, то все что остается — это выполнить их. Могу привести еще один годный совет, хоть он вам и покажется бредовым — заведите блокнотик и пишите в него все что собираетесь сделать. Вы думаете, итак запомню, но нет. Допустим сегодня у меня хорошее настроение и думаю о том, как собрать плату. Запиши план действий: сходить купить резистор, подготовить провода, сделать крепление дисплея. Потом все забудешь, откроешь блокнотик и смотришь — ага сегодня настроение попилить и построгать, сделаю крепление. Или собираешь ты плату и уже осталось допаять последний компонент, но не тут то было резисторы кончились, вот записал бы перед тем как паять, то вспомнил.
3. Не пользуйтесь кодогенераторами, нестандартными фичами и прочими упрощалками, хотя бы на первых этапах. Могу привести свой личный пример. Во времена активного использования AVR я пользовался кодогеном CAVR. Меня он полностью устраивал, хотя все говорили, что он кака. Звоночки звенели постоянно, были проблемы с библиотеками, с синтаксисом, с портированием, но было тяжело от этого отказаться. Я не разбирался как это работает, просто знал где и как поставить галочки.
Кол в мой гроб был вбит с появлением STM32, нужно было обязательно переползать на них, вот тогда то и появились проблемы. Проблемы мягко сказано, фактически мне пришлось осваивать микроконтроллеры и язык Си с нуля. Больше я не повторял прошлых ошибок. Надо сказать это уже пригодилось и не один раз. С тех пор мне довелось поработать с другими платформами и никаких затруднений не испытываю, подход оправдывает себя.
По поводу всех улучшалок и упрощалок, было одно очень хорошее сравнение, что они подобны инвалидным коляскам, которые едут по рельсам, можно ехать и наслаждаться, но вставать нельзя, куда везут — туда и приедешь.
4. Изучайте язык Си. Эх, как же часто я слышу, как начинающие радиолюбители хвалятся, что хорошо знают сишку. Для меня это стало кормом, всегда люблю проконсультироваться у таких собеседников. Обычно сразу выясняется, что язык они совершенно не знают. Могу сказать, что не смотря на кажущуюся простоту, людей которые действительно хорошо бы его знали, встречал не так много. В основном все его знают на столько, на сколько требуется для решения задач.
Однако, проблема на мой взгляд заключается в том, что не зная возможностей, вы сильно ограничиваете себя. С одной стороны не оптимальные решения, которые потребуют более мощного железа, с другой стороны не читаемый код, который сложно поддерживать. На мой взгляд, читаемость и поддерживаемость кода занимает одно из важнейших мест и мне сложно представить, как можно этого добиться не используя все возможности языка Си.
Очень многие начинающие брезгуют изучением языка, поэтому если вы не будете как все, то сразу станете на две ступени выше остальных новичков. Так же не никакой разницы, где изучать язык. На мой взгляд, микроконтроллер для этого не очень подходит. Гораздо проще поставить какую нибудь Visual studio или Qt Creator и порешать задачки в командной строке.
Хорошим подспорьем будет также изучение всяких тестов по языку, которые дают при собеседованиях. Если порыться то можно много нового узнать.
5. Изучение ассемблера? Бояться его не нужно, равно как и боготворить. Не нужно думать, что умея написать программу на ассемблере, вы сразу станете гуру микроконтроллеров, почему то это частое заблуждение. В первую очередь это инструмент. Даже если вы не планируете использовать его, то все равно я бы настоятельно рекомендовал написать хотя бы пару программ. Это сильно упростит понимание работы микроконтроллера и внутреннего устройства программ.
6. Читайте даташит. Многие разработчики, пренебрегают этим. Изучая даташит вы будете на две ступени выше тех разработчиков. Делать это крайне полезно, во первых это первоисточник, какие бы сайты вы не читали, в большинстве случаев они повторяют информацию из даташита, зачастую с ошибками и недосказанностями. Кроме того, там может находиться информация, о которой вы не задумываетесь сейчас, но которая может пригодиться в будущем. Может статься так, что вылезет какая то ошибка и вы вспомните что да, в даташите об этом было сказано. Если ваша цель стать хорошим разработчиком, то этого этапа не избежать, читать даташиты придется, чем раньше вы начнете это делать, тем быстрее пойдет рост.
7. Часто народ просит прислать даташит на русском. Даташит — это то, что должно восприниматься как истина, самая верная информация. Даже там не исключены ошибки. Если к этому добавятся ошибки переводчика, он ведь тоже человек, может даже не нарочно, просто опечататься. Либо у него свое видение, может что-то упустить, на его взгляд не важное, но возможно крайне важное для вас. Особенно смешной становится ситуация, когда нужно найти документацию на не сильно популярные компоненты.
На мой взгляд, намного проще исключить заранее весь слой этих проблем, чем вылавливать их потом. Поэтому я категорически против переводов, единственный верный совет — изучайте английский язык, чтобы читать даташиты и мануалы в оригинале. Понять смысл фразы с помощью программ переводчиков можно, даже если уровень вашего языка полный ноль.
Мною был проведен эксперимент: в наличии был студент, даташит и гугл переводчик. Эксперимент №1: студенту вручен даташит и дано задание самостоятельно найти нужные значения, результат — «да как я смогу», «да я не знаю английский», «я ничего не нашел/я не понял» типичные фразы, говорящие о том, что он даже не пытался. Эксперимент №2: тому же студенту, вручен все тот же даташит и тоже задание, с той разницей, что я сел рядом. Результат — через 5 минут он сам нашел все нужные значения, абсолютно без моего участия, без знания английского.
8. Изобретайте велосипед. Например, изучаете какую то новую штуку, допустим транзистор, дядька Хоровиц со страниц своей книги авторитетно заявляет, что транзистор усиливает, всегда говорите — НЕ ВЕРЮ. Берем в руки транзистор включаем его в схему и убеждаемся что это действительно так. Есть целый пласт проблем и тонкостей, которые не описываются в книгах. Прочувствовать их можно только, когда возьмешь в руки и попробуешь собрать. При этом получаем кучу попутных знаний, узнаем тонкости. Кроме того, любая теория без практики забудется намного быстрее.
На первоначальном этапе, мне очень сильно помог один метод — сначала собираешь схему и смотришь как она работает, а затем пытаешься найти обоснование в книге. То же самое и с программной частью, когда есть готовая программа, то проще разобраться в ней и соотнести куски кода, какой за что отвечает.
Также важно выходить за рамки дозволенного, подать побольше/поменьше напряжение, делать больше/меньше резисторы и следить за изменениями в работе схемы. В мозгу все это остается и оно пригодится в будущем. Да это чревато расходом компонентов, но я считаю это неизбежным. Первое время я сидел и палил все подряд, но теперь перед тем как поставить тот или иной номинал, всегда вспоминаю те веселые времена и последствия того, если поставить неверный номинал.
9. А как бы я сделал это, если бы находился на месте разработчиков? Могу ли я сделать лучше? Каждый раз задавайте себе эти вопросы, это очень хорошо помогает продвигаться в обучении. Например, изучите интерфейсы 1wire, i2c, spi, uart, а потом подумайте чем они отличаются, можно ли было сделать лучше, это поможет осознать почему все именно так, а не иначе. Так же вы будете осознавать, когда и какой лучше применить.
10. Не ограничивайтесь в технологиях. Важно что этот совет имеет очень тонкую грань. Был этап в жизни, когда из каждой подворотни доносилось «надо бы знать ПЛИС», «а вот на ПЛИС то можно сделать». Формально у меня не было целей изучать ПЛИСины, но и пройти мимо было никак нельзя. Этому вопросу было выделено немного времени на ознакомление. Время не прошло зря, у меня был целый ряд вопросов, касаемых внутреннего устройства микроконтроллеров, именно после общения с плисинами я получил ответы на них. Подобных примеров много, все знания, которые я приобретал в том или ином виде, рано или поздно пригодились. У меня нет ни единого бесполезного примера.
Но как было сказано, вопрос технологий имеет тонкую грань. Не нужно хвататься за все подряд. В электронике много направлений. Может вам нравится аналог, может цифра, может вы специалист по источникам питания. Если не понятно, то попробуйте себя везде, но практика показывает, что вначале лучше сконцентрироваться на чем то конкретном. Даже если нужно жать в нескольких направлениях, то лучше делать это ступеньками, сначала продавить что то одно.
11. Если спросить начинающего радиолюбителя, что ему больше нравится программирование или схемотехника, то с вероятностью 99% ответ будет программирование. При этом большую часть времени эти программисты тратят на изготовление плат ЛУТом/фоторезистом. Причины в общем то понятны, но довольно часто это переходит в некий маразм, который состоит в изготовлении плат ради изготовления плат.
В интернетах практически единственный трушный путь к программированию это стать джедаем изготовления печатных плат. Я тоже прошел через этот путь, но каждый раз задаю себе вопрос зачем? С тех пор, как я приобрел себе пару плат, на все случаи жизни, каждый раз думаю о том, что мог бы спокойно прожить все это время без самодельных плат. Мой совет, если есть хоть капля сомнений, то лучше не заморачиваться и взять готовую отладочную плату, а время и средства лучше бы потратить на программирование.
12. Следующий совет, особенно болезненный, мне очень не хочется его обсуждать, но надо. Часто мне пишут, мол ххх руб за ууу дорого, где бы подешевле достать. Вроде бы обычный вопрос, но обычно я сразу напрягаюсь от него, так как зачастую он переходит в бесконечные жалобы на отсутствие денег. У меня всегда возникает вопрос: почему бы не оторвать пятую точку и не пойти работать? Хоть в тот же макдак, хоть на стройку, потерпеть месяц, зато потом можно приобрести парочку плат, которых хватит на ближайший год. Да я знаю, что маленьких городах и селах сложно найти работу, переезжайте в большой город. Работайте на удаленке, в общем нужно крутиться. Просто жаловаться нет смысла, выход из ситуации есть, кто ищет его тот находит.
13. В ту же копилку внесу очень болезненный вопрос инструмента. Инструмент должен позволять вам максимально быстро разрабатывать устройства. Почему то очень многие разработчики не ценят свое время. Типичный пример, дешевая обжимка для клемм, на которой так любят экономить многие работодатели. Проблема в том, что она даже обжимает не правильно, из-за этого провода вываливаются. Приходится производить кучу дополнительных манипуляций, соответственно тратить время. Но как известно дурак платит трижды, поэтому низкая цена кримпера возрастет во много раз, за счет затрачиваемого времени и плохого качества обжима.
Не говорю что дешевое = плохое, нет — все зависит от ситуации. Вернусь к примеру кримпера, было время когда обжимал чем попало, поэтому часто возникали проблемы. Особенно неприятно, когда заводишь плату и она не работает, после долгих поисков ошибки понимаешь что из-за плохо обжатого проводочка, обидно. С тех пор как появилась нормальная обжимка этих проблем нет. Да внутренняя жаба и квакала, и душилась от ее стоимости, но ни разу не пожалел об этом решении. Все что я хочу сказать, что поработав с нормальным инструментом, совершенно не хочется возвращаться к плохому, даже не хочется обсуждать это. Как показывает практика, лучше не экономить на инструментах, если сомневаетесь — возьмите у кого нибудь потестить, почитайте отзывы, обзоры.
14. Заведите сайт, можно писать на нем, что угодно, просто как записки. Практика показывает, что работодатели все равно его не читают, но сам факт производит большой эффект.
15. Тонкий вопрос: профильное высшее образование, нужно ли оно? Мне известны не единичные случаи, когда люди работали абсолютно без образования и по опыту и знаниям они могли дать прикурить любому дипломированному специалисту. Собственно, у меня нет профильного образования, испытываю ли я от этого дискомфорт? В определенной степени да.
Еще в самом начале, когда микроконтроллеры были для меня хобби, я много помогал с курсовыми и дипломами разных вузов, просто чтобы оценить свой уровень. Могу сказать уверенно, что уровень в целом невысок вне зависимости от имени вуза. Учиться несколько лет, для того чтобы написать такой диплом, совершенно необязательно. Достигнуть этого можно самостоятельно за весьма короткий срок. И все же зачастую бывали моменты, когда студенты знали какой то предмет, который они проходили на 2-3 курсе, а я этого не знал. Хоть все эти знания и компенсировались самообразованием, но все же лучше было бы не тратить на это время.
Вуз ради бумажки. Могу сказать, что были и такие ситуации, когда предлагали работу, которая требовала обязательного наличия образования и было обидно, что именно в тот момент бумажки не было. Но в целом, история показывает, что большинству работодателей наплевать на вашу бумажку.
Следующий момент довольно часто не учитывается, это окружение. Не забывайте, что люди, с которыми вы учитесь это ваше поколение, не исключено что вам с ними работать. Количество фирм работающих в одной отрасли сильно ограничено. Практика показывает, что даже в больших городах все и все друг о друге знают, вплоть до интимных подробностей.
Еще один момент это возможности. Зачастую у вузов есть свои возможности — оборудование, может какие то секции, может какие то программы работы за рубежом, этим нужно пользоваться, если есть хоть малейшая возможность. Если в вузе вы не видите перспективы, идите в другой, мир на каком то одном не заканчивается.
Если подытожить то совет таков: если есть хоть малейшая возможность — нужно идти учиться, обязательно по профилю, если есть хоть какие то шансы, то лезть везде, а не отсиживать штаны на задней парте. Заводить знакомства, параллельно дома самому практиковаться, развиваться.
16. Поздно ли начинать программировать в 20, 30, 40, 50 лет? Практика других людей показывает, что возраст вообще не помеха. Многие почему то не учитывают то, что есть целый пласт работы, которую молодые в силу своих амбиций не хотят делать. Поэтому работодатели предпочитают брать тех, кто будет ее тащить. Это ваш шанс зацепиться, а дальше все зависит только от вас.
И последний совет. Многие радиолюбители необщительные, сердитые и раздражительные — считайте это спецификой работы. Излучайте добро и позитив, будьте хорошим человеком.
Комментарии (81)
Amomum
06.01.2016 16:37+3Я бы еще добавил «Пользуйтесь системой контроля версий, не важно какой». Почему-то именно среди программистов микроконтроллеров большой процент людей, которые про такие штуки вообще не знают (по моим наблюдениям).
И тогда в лучшем случае архивы-бекапы с датами, а в худшем — ничего вообще.
Особенно на этапе обучения возможность откатиться на пару шагов назад очень полезна.
monah_tuk
06.01.2016 17:01+1Я бы ещё посоветовал как можно скорее отходить от Makefile. У меня был проект, где можно было параметрами включать различные опции, в один прекрасный момент столкнулся с проблемой: всё собирается и линкуется, но работает криво, причём ошибки феерические. Делаешь полный ребилд — всё отлично. Всякие CMake, qbs и так далее, дают возможность задавать опции на уровне конфигурирования билда, положить на плечи системы отслеживание зависимостей и принуждать делать ребилды, когда оно требуется, даёт возможность использовать теневые сборки, что позволяет не мешать код и бинарники, использовать несколько раздельных билд-конфигураций с разными параметрами, а не перестраивать всё в одном дереве. Потом помогает.
Uint32
08.01.2016 14:29такое случается, когда не правильно указанны зависимости в 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__ в статик либе — все рулы приходится писать руками.monah_tuk
08.01.2016 15:32Зависимости генерировались средствами gcc, вручную их описывать, это адъ. Где-то возник косяк, в общем файлов уже очень много и мысль была проста: если какой-то инструмент мне может облегчить жизнь, то почему бы им не воспользоваться. На написание правил, да, ушёл день (больше на придумывание как оно должно быть, удобнее, минималистичнее и generic use): github.com/h4tr3d/fx3-cmake
monah_tuk
06.01.2016 17:05дополняя: лучше остановиться на какой-то децентрализованной. Проще, что комиты можно делать локально, не нужен сервер. А вот какую: git, mercurial, bazaar — дело вкуса или наличия местного гуру :)
Amomum
06.01.2016 17:17Svn-сервер тоже легко поднимается локально… Но начинать с svn сейчас, пожалуй, уже не стоит :)
de1m
06.01.2016 16:59помоему у радиолюбителей часы это как у хирурга первое вскрытие.
Я в прошлом году тоже начал с часов на газоразрядных лампах, ничего не знал и не умел, да и програмировать на с тоже не умел, почти шесть месяцев делал. В конце конечно доделал, но пришлось упростить немного. Хотел сначала с dcf77 сделать, но не смог побороть помехи от блока питания, пришлось сделать просто с ds3231.
Может кому интересно www.youtube.com/user/sanshotur/videos
И я с автором не соглашусь, надо начинать именно с конкретного проекта. Из-за знания конечной цели не так сильно падает интерес и мотивация.
DolphinSoft
06.01.2016 17:25… надо начинать именно с конкретного проекта...
Насколько я понял автора, говоря про узлы периферии, он имел ввиду именно конкретные минималистические проекты, которые предназначены для изучения работы конкретных узлов периферии.
Например: работа с таймером, UART, PWM и тп, но все в отдельных проектах. А уже после приступать к более высоко-уровневым и сложным проектам.
Лично я, почти так же поступил когда-то:
Проанализировал свои идеи и разбил на составляющие узлы (механизмы), из чего понял какие мне нужны технологии периферии. Но я уже владел и Си, и Ассемблером.
А к словам автора, я бы добавил механизмы виртуализации разработок, как например Proteus.
Многие его ругают, но ИМХО это от недостатка знаний. Меня он пока не подводил.
Ведь для таких экспериментов и паять уметь не нужно (для начала конечно), а параллельно с этим изучить и уроки пайки.
И тогда успех будет сто процентным.
dimao79
07.01.2016 11:06+3помоему у радиолюбителей часы это как у хирурга первое вскрытие.
О времена…
Когда то это был радиоприемник.
Alexeyslav
07.01.2016 23:56Детекторный… как сейчас помню. В Киеве даже работал с трубой отопления в качестве антенны.
dimao79
08.01.2016 12:38Ага, и ловил ровно одну станцию, ту, которую передавали по проводному радио ))
Alexeyslav
08.01.2016 23:51Ту что вещала наиболее мощно. Тогда они уже начали сходить на нет и Мощные АМ-передатчики в ДВ-диапазоне начали закрывать.
de1m
08.01.2016 14:35я сомневаюсь, что меня можно назвать радиолюбителем, всётаки с радио я ничего не делаю.
Alexeyslav
08.01.2016 23:53Любая схема где имеется переменный ток является радиопередатчиком… так что формально всё-таки радиолюбители.
OnYourLips
06.01.2016 18:15> Путь с нуля на мой взгляд заключается в изучении периферии и особенностей, если это микроконтроллер.
Может все-таки стоит начать с физики?
Сначала общий курс физики, потом EECS (например курс MIT 6.002), потом устройство микропроцессоров и процессоров (например курс MIT 6.004).
Тот, кто учится что-то делать, не понимая, как это работает, далеко не уйдет.
aml
07.01.2016 11:09+1Не обязательно в «академическом» порядке. Можно сначала разобраться с программированием, потом с устройством процессора (и воскликнуть: «Ага! Так вот как оно работает!»), потом с физикой (" А… Вон оно как все просто, а я думал — магия...")
Visphord
06.01.2016 20:30Подскажите пожалуйста начинающему электронщику. Сам я программист, но интересуюсь изготовлением мелких девайсов на ардуинах(avr), так вот — разобраться с самими МК для меня относительно несложно(и платку вытравить и мк запрограммировать отдельно), но вот с аналоговой электроникой большие проблемы. По отдельности теоретически я понимаю как работает каждый аналоговый компонент (резистор, транзистор, диод, конденсатор, etc), но вот перешагнуть порог понимания «как работает вот этот набор деталей(схема)» никак не могу. Посоветуйте, пожалуйста, что почитать или сделать — чтобы попытаться приблизить это понимание.
ploop
06.01.2016 22:19+2А всё очень просто. Вот вы знаете, теоретически, как работает транзистор. Разопните его на макетке, понацепляйте переменных резисторов (ими удобно на лету всё регулировать), лампочку (не светодиод!) в цепь, мультиметр, и крутите, смотрите за поведением в разных включениях, вплоть до того, как не спалите. Только так до меня дошло, как он работает, хотя книг уйму читал. Правда было это в 7 классе :)
Ах да, как бы смешно это не звучало, нужно понимать закон Ома. Знает его любой школьник, а нужно именно понимать. Не посчитать ток в цепи (пусть даже в уме), или напряжение где какое, а просто интуитивно сказать, что будет, если какой-то номинал уменьшить/увеличить, или напряжение изменить. Не в числах, а просто в какую сторону что поплывёт. Это как наступить на край табуретки — упадёт она или нет? И когда и в какую сторону упадёт?
Смешно, но практика показывает, что очень много технически грамотных инженеров, даже работающих в близких к электронике сферах (например энергетика) этого не понимают. Знают, но не понимают.
valeriyk
06.01.2016 22:52Скачайте LT-spice ( www.linear.com/designtools/software/#LTspice ).
Ну а далее по порядку:
— делитель напряжения
— RC-фильтр
— транзисторы
— операционники (аналоговые сумматоры и т.д.)ploop
06.01.2016 23:09+1Ненене, только паяльник! :)
Симуляторы уже потом, когда надо проверить что-то заковыристое, а собирать макет лень.
dimview
07.01.2016 01:33+2Ключевое слово было упомянуто в статье — Хоровиц. Если полнее — Хоровиц и Хилл, «Искусство схемотехники». После прочтения новой главы проверять усвоенное применением на практике. В порядке увеличения сложности — усилитель низкой частоты, радиоприёмник, часы, терменвокс, миноискатель, шифровальная машина и так далее. Всё это делается безо всяких ардуин и с минимумом дополнительного оборудования.
dimao79
07.01.2016 11:30+1Да, Хоровиц и Хилл.
Серия книг МРБ.
Я в свое время зачитывался этой — Шаг за шагом. Транзисторы. Сворень Р.А. От физики процессов до готовых схем, максимально простым языком и с картинками.
Серия «Шаг за шагом» и другие книги. Р. А. Сворень
Как бы странно не звучало, если хотите разобраться в основах — начинайте со старых книг, в новых упор уже идет на практику, без обьяснения зачем и почему так, на уровне «подключаем светодиод к ардуине и начинаем писать скетч».
beeruser
07.01.2016 21:29Берёте детский конструктор типа такого и вперёд
http://masterkit.ru/shop/studygoods/assembly-kits/1927737
Я себе недавно такой прикупил ;-)
jok40
08.01.2016 09:27Я могу порекомендовать издание «Полупроводниковая схемотехника» (в двух томах). Авторы — Ульрих Титце и Кристоф Шенк. Отличный справочник. Всё коротко, ясно и по делу — без лишней воды.
totuin
06.01.2016 22:57-1Я не совсем согласен с Вашим утверждением что успеха в создании конструкций на микроконтроллерах невозможно добится без изучения языка программирования. По Вашим выкладкам получается что разработчик должен быть этаким супер универсалом. В совершенстве знать языки програмирования (включая ассемблер), и при этом отлично разбираться в электронике и конструировании устройств. Честно говоря «Это фантастика сынок»(цитата). Слишком разные области знаний. Это давно уже поняли производители промышленных контроллеров, и создали свои специфические среды программирования, которые позволяют имено конструкторам-электронщикам создавать серьёзные системы управления. По роду своей деятельности я работаю как раз в обеих областях, и чаще всего втречаю программистов которые не имеют ни малейшего представления как работает транзистор, и инженеров для которых понятие «указатель на область памяти» — пустой звук. Причем и те и другие отличные проффесионалы в своей области. Что бы стать проффесионалов в каждой из этих областей, надо посвятить этому большую часть своей жизни, и на другую просто не останется времени.
Программисты используют микроконтроллеры на «поиграться», и поэтому большинство представленных на хабре постов о изделях от программистов с красивым кодом представляют собой игрушки. А представленные на гиктайме посты от хороших элетронщиков (реально полезные устройства) имеют код собранный с помощью копи-паста из примеров. Да и чаще всего электронщики шарахаются от контроллеров когда только заходит разговор об их программировании.
В свое время я начал проект (для себя любимого, и друзей) где попытался решить эту проблемму, и вот на третий год жизни проекта, я могу с уверенностью сказать, что тем же электронщикам надо только дать понятный им инструмент, и тогда они свернут горы. Они действительно создают полезный и законченные проекты начиная от промышленных станков, заканчивая управлением солнечными батареями. Я думаю что начав ломать свой мозг изучением того же си, они никогда бы не сделали того, что делают сейчас используя понятные инструменты.
Мое мнение -«Каждый должен нести свой чемодан»(опять цитата). Программисты пускай создают те самые инструменты — нормальные среды программирования для различных контроллеров (возьмите тот же TiaPortal от Siemens), а конструкторы с помощью этих инструментов уже будут создавать полезные устройства. Наверное такой симбиоз будет наиболее удачен.dimview
07.01.2016 01:40+2Это не фантастика, а так и должно быть. Самые интересные работы находятся на стыке областей, и чтобы там преуспеть, надо хорошо разбираться в обоих.
Например, программирование и схемотехника (что покрывает по сути всю современную электронику, как промышленную, так и потребительскую). Или статистика и программирование (big data). Или программирование и финансы (high frequency trading).
А что на освоение двух предметных областей уйдёт не 10 лет, а 20 — так они всё равно уйдут.totuin
07.01.2016 02:39-1Наверное так хорошо было-бы, но Вы то уже большой и наверное в сказки не верите. Возможно и есть уникумы которые могут осилить две разные области деятельности на высоком уровне, но чаще всего получается и не там и не тут высоких уровней нет. Как говорится за двумя зайцами погонишся… Жизнь требует сосредоточится на какой — то конкретной дороге. Кормить семью, и иметь работу надо сейчас а не через 20 лет. Поэтому в большинстве организаций занимающихся разработкой устройств на микроконтроллерах работают пары: программист+инженер-электронщик.
Как я уже писал выше, для создания систем АСУ производители промышленных контроллеров нашли выход позволяющий обойтись без программиста, и этот подход полностью себя оправдал. Но правда цены на такие контроллеры пугают.
Каждый должен заниматься тем что ему нравится, тогда и результат будет. Нравится писать код — пиши. Нравится рисовать схемы — рисуй. И не надо заставлять себя заниматься тем, к чему душа не лежит.
Я как раз и пробую дать возможность перевести программирование контроллера в привычную для электронщика процедуру создания принципиальной схемы, которая потом будет работать внутри контроллера. Ну не нужны им всякие if-ы, for-ы и т.д. Им нужны реле, контакты, реле сравнения. Ну или компараторы, дешифраторы, тригеры… В этом они хорошо понимают. Ну а задача программиста создать им инструмент который поможет им это делать. Потому что научить программиста например расчёту помехозащищённости, или расчёту выходного силового ключа то же сложная задача. Если он справится, честь и хвала ему, ну а если не справится, то такое изделие (которое сгорит после 10 пусков) и не нужно.dimview
07.01.2016 04:40+3Во-первых необязательно знать обе области на самом высоком уровне. Так действительно бывает редко. Но если программист не знает закон Ома, а электронщик не умеет написать цикл, то в embedded им обоим делать нечего. Никаких сверхестественных способностей для этого не надо, любой выпускник нормального ВУЗа вполне может справиться с электроникой в пределах Хоровица и Хилла и программированием в пределах трупа Страуса.
Во-вторых никто не заставляет сначала 20 лет учиться, а только потом работать. Это делается одновременно. Просто если только писать код (особенно на одном языке, в одной среде разработки и той же самой предметной области), то можно очень легко и быстро остаться без работы. Окулист или водопроводчик без работы не останется, а попробуйте сейчас найти позицию программиста на языке GOC в операционной системе GEOS. Пример, кстати, взят из реальной жизни.
Ну и заодно давайте я вам сэкономлю немного времени. Попытки сделать визуальную среду программирования для непрограммистов предпринимались неоднократно и все они окончились безуспешно. Потому что загвоздка там не в том, соединять квадратики линиями или писать if.totuin
07.01.2016 11:28Насчет неудачных попыток Вы можете спросить у того -же Simens, Schneider, ABB и др. Большинство настоящих систем управления производством, да и практически любая автоматизированная система написана как раз с помощью сред где как Вы говорите «надо соединять квадратики». Хотя в этой фразе всё таки чувствуется программист. Для Вас всё что не связанно с написанием многих «буковок» — это детские забавы. А тут не просто детские забавы — это создание принципиальной схемы, как раз то, в чем электронщики сильны. А вот для программиста — это действительно соединение между собой непонятных квадратиков
Alexeyslav
08.01.2016 00:09+1Промышленная автоматика довольно проста, нет никаких сложностей организовать такое решение которое устроило бы схемотехников. Но это резко сокращает возможности по разработке, хотя и делает результат стабильным и предсказуемым.
RomeoGolf
07.01.2016 10:31+3Очень тяжело работать с программистом, который не знает, не хочет знать и не собирается узнать, что такое регистры, буферы, триггеры, и почему может быть по одному и тому же адресу на запись доступ к одной сущности, а на чтение — к другой, когда по схеме это более чем очевидно. Приходится тратить массу времени — два-три рабочих дня целиком — чтобы составить ему подробную карту памяти устройства на запись и чтение. На этапе отладки макета это непозволительная роскошь, потому что при перестройке прибора под изменяющиеся на лету требования вся эта бумага будет урнирована и переписана заново. С программистом, умеющим хорошо читать и хотя бы хреновенько писать схемы просто сидишь рядом и пальцем показываешь: выгода — пять секунд против двух дней.
Очень некомфортно работать со схемотехником, которому пофигу на твои карты памяти (тебе надо — ты и рисуй, а я не знаю что это и зачем), который изобретает фильдиперстовые решения, разбивающие простую последовательность адресов, например, без особой выгоды.
Короче, если один в паре абсолютно «не шарит» в соседской области, второму придется быть спецом в обеих областях, если оба «специалиста» сверхузкие — нужен третий в роли переводчика. Реально дешевле научить обоих видеть чуть-чуть шире своей норки.
И таки да, результат «единоличника», который сам схему рисует и сам программу пишет, получается обычно самым эффективным и самым сопровождаемым, даже при том, что человек не собирался передавать на сопровождение, и делать этого не умеет и не любит. Однако же, разобраться в его творчестве несколько проще. Но таких, да, мало.
RomeoGolf
07.01.2016 10:34-1Я как раз и пробую дать возможность перевести программирование контроллера в привычную для электронщика процедуру создания принципиальной схемы, которая потом будет работать внутри контроллера. Ну не нужны им всякие if-ы, for-ы и т.д. Им нужны реле, контакты, реле сравнения. Ну или компараторы, дешифраторы, тригеры…
И зачем таким электронщикам вообще контроллеры? Пусть рисуют схемы для ПЛИС, в графическом режиме.totuin
07.01.2016 11:41+1И зачем таким электронщикам вообще контроллеры? Пусть рисуют схемы для ПЛИС, в графическом режиме.
А зачем программистам микроконтроллеры? Пускай программируют однопалатные компьютеры.
А зачем электронщикам контроллеры, можете спросить любого из нескольких тысяч пользователей программы. Зайдите на сайт (flprog.ru), почитайте форум, посмотрите статьи пользователей. Посмотрите что делают люди совершенно не знакомые с программированием в классическом смысле. На 99% это законченные и приносящие пользу изделия. В отличие от игрушек настоящих программистов.dimao79
07.01.2016 11:59+2Вот да, многие забывают что и ПЛИС и МК работают не внутри симуляторов в их компьютерах, а в реальном мире. И получается, что вроде бы и идея интересная, и по функционалу и по реализации довольно интересно, а схему глянешь — и ужасаешься тому, что даже питание того же МК реализовано мягко говоря странно, или сигнальные линии длинной в десять метров заведены напрямик на порты, безо всякой защиты.
Да, оно работает. Но беда в том, что симуляторы от реальности отличаются очень сильно, и чистому программисту это понять очень непросто.
RomeoGolf
07.01.2016 12:12+1А зачем программистам микроконтроллеры? Пускай программируют однопалатные компьютеры.
А тут вопрос, что понимать под одноплатными компьютерами. В нашем случае, их и программируют, собственно. Программирование голого контроллера никого не интересует, интересует устройство (разработанное схемотехником), реализующее некоторый алгоритм (запрограммированный программистом). Если при этом алгоритм можно выразить схемой — нафиг маяться, пусть это делает ПЛИС, у нее и быстродействие будет поинтереснее. Помнится, пробовали посчитать CRC16 килобайтных блоков последовательного кода программно и на ПЛИС… А вот оцифрованный сигнал, скажем, обработать — тут без программиста тяжело будет. Поэтому у нас, например, платы имеют два основных элемента — ПЛИС (иногда не одна) и процессор/контроллер. И всем работы хватает — одни рисуют, другие пишут :-)
olekl
07.01.2016 12:32+2Описанный вами набор навыков называется «разработчик встраиваемых систем». И они таки существуют, эти разработчики!
scratch_book
06.01.2016 23:00-2Бестолковые советы. Начинать всегда надо с азбуки, а лучше с поиска единомышленников, которые и азбуку объяснят, и помоями поливать не будут. Найдите учителя, и будет вам счастье.
Grox
07.01.2016 00:56+1Многие учатся сами. А ваш совет с первого взгляда напоминает волшебную таблетку ) Это хороший совет, как дополнение, а не вместо них.
aml
07.01.2016 11:15+1Супер статья, подпишусь почти под всем. Единственное, не надо путать C и C++ — это совсем разные языки с похожим синтаксисом. И платы не обязательно на клеммах собирать — можно заказывать изготовление. Это чуть дороже, но во-первых не сильно, а во-вторых работать с качественной платой в разы приятнее и проще.
emusic
13.01.2016 16:42Нынче писать на чистом C имеет смысл разве что предельно простые программы с пять-десятью раздельными переменными и несколькими функциями. Если возникает хоть одна сущность, для работы с которой делается хотя бы пара-тройка функций — уже стоит подумать о C++.
ploop
13.01.2016 16:47+1Контроллеры разные бывают. На некоторых даже накладные расходы на чистый Си отъедят половину памяти.
emusic
13.01.2016 16:57В правильно организованной системе «компилятор+линкер+библиотеки» накладные расходы определяются потребностями программы. Никто ж не заставляет использовать исключения, RTTI и прочие «тяжелые» возможности языка. А программа на C++, в которой функции-члены оперируют данными-членами, будет почти побайтно идентичной программе на чистом C, где обычные функции оперируют полями структуры.
Другое дело, что бывают неудачные CRT-стартапы, которые даже в минимальном варианте тянут из библиотек много лишнего. Профессионалу нетрудно призвать их к порядку, но для новичка это действительно не годится.
GarryC
07.01.2016 18:04+1К спору о необходимости знания программирования — оно так да, действительно нужно. Но следует понимать границы погружения в язык для решения конкретных проблем. Я сам люблю с утра озадачить коллег — молодых инженеров вопросом «Знаете ли Вы язык С?» Наученные горьким опытом, они сразу признаются, что не знают, и я показываю какой-нибудь трюк типа тернарного оператора слева от равенства. Но такое погружение совершенно необязательно и они замечательно пишут необходимые нам программы.
С другой стороны, хоть я и не разделяю пренебрежительного отношения к «ардуинщикам», тем не менее среди них имеется значительное количество людей, которые не знают, и, самое ужасное, не собираются узнавать, что именно происходит при выполнении той или иной стандартной библиотечной функции. Это еще можно было бы простить, если бы подобные «создатели электронных устройств» оставляли свои чудесные произведения для внутреннего употребления, но они их выкладывают на всеобщее обозрение и лично у меня, кроме чувства тягостного недоумения, данные экзерсисы (надо бы словечко похлеще, тоже с буквы э, ну да ладно) не вызывают. Самое ужасное, когда подобные творения проползают в фирменные примеры, вот это уже край.totuin
07.01.2016 18:19+1Simens выпускают газотурбинные генераторы. И вы не поверите, но во всей прошивке для всех контроллеров которые управляют турбиной нет ни строчки кода. А только чарты (схемы по нашему). Разработчики этой системы не имеют ни малейшего представления какой код крутится в контроллерах. Я лично общался и с разработчиками, и с сервисниками и поэтому знаю об этом. И представляете, они эти поделки не только не прячут, а ещё и продают по всему миру. Вот ужас то!!! И так во всех промышленных системах. Как ни странно их разрабатывают инженеры — электронщики, а не программисты. Куда катится мир.
GarryC
07.01.2016 18:45+1Вот ужас то — программы для Тойота разрабатывали тоже инженеры-электронщики и сколько за это Тойоте пришлось отстегнуть? Куда катится мир.
А вот для того, чтобы разработчики квадратиков для ПЛК могли ничего не понимать в происходящем, большие группы людей, которые в совершенстве владеют программированием и понимают ВСЕ процессы в железе делали операционную среду и разрабатывали максимально надежные методы ее программирования на уровне квадратиков.
Ну и напоследок — сообщите публике, сколько стоит ПЛК фирмы Siemens (я то знаю, а вот многие будут неприятно Вашими цифрами удивлены), сколько стоит лицензия на кодогенератор для этих ПЛК, каковы условия поддержки изделий от этой фирмы, и, я надеюсь, читатели поймут, что рекламируемая Вами продукция и метод программирования совершенно для них не подходит.
Ролс-Ройс, конечно, отличный автомобиль, но немногие могут себе его позволить.totuin
07.01.2016 19:12-2Вот я и предлагаю программистам заниматься своим делом, разрабатывая те самые среды разработки для электронщиков. Только для недорогих контроллеров. Примеры есть. Проект Horizont Automatics, Canny (но у них свой контроллер и цена высоковата), ну и мой проект FLProg. Это только Российские проекты. Horizont Automatics и FLProg бесплатны. Рассчитаны на недорогие ардуинки (хотя я потихоньку готовлюсь к расширению списка контроллеров).
Так что можно обойтись без дорогих промышленных контроллеров, взяв от них самое ценное — проверенные годами графические языки. Нужно только желание программистов заняться создание подобных сред, ну и не драть за них большие деньги.
Но к сожалению большинство программистов сегодня пишут «Весёлые фермы», всякие онлайн стратегии, и т.п. Ведь за них при небольших умственных и физических затратах можно стрясти с хомячков неплохие деньги.GarryC
07.01.2016 19:37+4Еще раз — не следует смешивать горькое с холодным.
Когда речь идет о ПЛК, то там действительно вылизанная годами исполняющая система и программирование на уровне схем автоматики, причем для решения профессионалами в денной предметной области строго определенного (и весьма ограниченного) круга задач с высокой надежностью.
Когда же речь идет о МК, то 1)здесь круг задач намного более широк, 2) уровень вхождения для языка схем автоматики весьма высок (на мой взгляд, запределен) — как в вашем случае, либо 3) графическое программирование превращается в язык блок-схем, что вообще не имеет права на существование, но это не Ваш случай.
Хотя определенные задачи, типа управления термостатом, однозначно приводимые к схемам автоматики, вполне можно программировать и на Вашем языке (я попробовал — получилось, но я все-таки не типовой пользователь), но нужно очень хорошо понимать ограничения данного метода.
А впрочем — пусть расцветают сто цветов, кому-то и пригодится, просто мне не очень понравился Ваш посылЧтобы программировать микроконтроллеры не обязательно знать языки программирования!
как рекламный слоган — неплохо, как руководство к действию — сомнительно.
Ну а по поводупри небольших умственных и физических затратах
это вы погорячились, у меня есть знакомые в этой индустрии и там конкуренция за хомячков дичайшая, без киллер-фичи никаких шансов, да и с ней не очень много.totuin
07.01.2016 20:07Еще раз — не следует смешивать горькое с холодным.
А чем отличается ПЛК и микроконтроллер? ПЛК — это микроконтроллер+входные развязки+выходные ключи или выходные реле. Часто добавляют простенький дисплей, ну и интерфейсы выводят.
Круг задач решаемых графическими языками практически не ограничен, что опять таки доказано годами эксплуатации действительно больших систем автоматизации. Управление той — же турбиной — это далеко не термостат. По крайней мере использовать все возможности микроконтроллера вполне можно.
уровень вхождения для языка схем автоматики весьма высок
Для кого? Электронщик пользуясь этим языком находится в привычном окружении и пользуется привычными знаниями и терминами. Он занимается своей обычной работой, то есть просто создаёт схему.
Для программиста который разрабатывает данную среду? Ну Вы же призываете электронщиков изучать непонятные для них языки программирования. Причем для создания законченных изделий им необходимо изучить язык на достаточно серьёзном уровне. Так почему бы программисту не освоить хотя бы азы электроники что бы понимать чем отличается Т-триггер от RS-триггера.
Ну а мой посыл опять таки оправдан большим опытом в разработке промышленной автоматики. Обычное программирование для меня хобби, и я не считаю себя професионалом — программистом. Все таки я больше конструктор-схемотехник. И людей в среде разработчиков систем АСУ, которые являются обычными программистами — единицы. Но между тем заводы работают, электростанции выдают электроэнергию, котельные дают тепло.Alexeyslav
08.01.2016 00:28Может это надо было сказать где-то выше по ветке, но скажу здесь.
Вы сейчас спорите о том что лучше функциональный язык или императивный.
На системы промавтоматики очень хорошо ложится функциональный язык программирования — схемы на него переводятся один в один. И ваши инженеры-схемотехники таки становятся программистами-функциональщиками просто не задумываясь об этом.
Но попробуйте поработать в условиях ограниченных ресурсов с большим объёмом данных, где нужно обрабатывать данные последовательно, по очереди т.к. весь кусок просто не помещается в доступную память или решение получается слишком дорогим и функциональный язык проигрывает императивному.
Автоматика на производстве это хорошо, но почему-то когда речь идёт о мультимедиа — вывод графики и звука блок-схемы становятся очень неудобными, а императивный подход становится очень простым и наглядным.
GarryC
08.01.2016 10:18+2Ну вообще то я электронщик и язык автоматики ну никак не входит в мой повседневный багаж, то есть я его понимаю, но это все-таки никак не схема в привычном понимании слова, а скорее описание алгоритма.
Что же касается нетривиальных задач, не сводимых к «включить на время до условия/ выключить на время», то реализация их на базе графических языков — весьма и весьма непроста. На мой взгляд — так и невозможна (конечно, «невозможно только спать на потолке», все остальное только вопрос затраченного времени, но зачем «чесать левой ухо правой рукой, пропустив ее под коленкой левой ноги») до тех пор, когда кто то для Вас не нарисует квадратик, выполняющий нужную Вам сложную функцию либо общение с интерфейсом.
Можете на досуге попробовать нарисовать конечный автомат, который реализует последовательный обмен с прибором класса WS2811, и лучше бы не в терминах регистров, в в терминах предлагаемого Вами программного продукта, потом сделайте то же самое на Verilog и на C, и потом сравните, что проще в понимании. Для меня результат очевиден, я владею всеми 4 инструментами, и предпочитаю писать на С (оставляя первые три способа для ПЛИС), но Вы можете попробовать.
Есть такое выражение — «каждый язык для своей задачи» и оно в данном случае справедливо, как никогда.
aml
07.01.2016 23:51Эти контроллеры гарантируют срабатывание автоматики в жёстко реальном времени. Если ваша конфигурация слишком сложная, чтобы эту гарантию предоставить, программа просто не «скомпилируется». То же самое можно, естественно, сделать и на языке общего назначения, но это требует очень высокой квалификации программиста. Один программист наворотит какой-нибудь модный асинхронный движок, другой хитрую систему обработки прерываний, третий где-нибудь напишет неэффективный код, который может задержать критическую операцию и т.д. — вариантов выстрелить себе в ногу — миллион. А если у вас газотурбинный генератор, то сбой софта стоит очень много денег. Я уж не говорю про сбой в какой-нибудь ABS в машине — это вообще жизней стоить может.
sam_satan
08.01.2016 13:36Не согласен с тем, что конкретный проект не нужен. Сделать часы это идеальная для обучения задача.
Опять же, про C++ в embedded ни слова. Constexpr и статический полиморфизм как будто созданы специально для микроконтроллеров. Получаем легко читаемый и переносимый код без оверхеда.
Dare
09.01.2016 14:33Очень вовремя в начале года. Просто снимаю шляпу.
Расскажу про реальные проблемы старта. Может быть вы поможете мне реальным советом или ссылкой а может скажете, что я ленив в своих поисках и в таком случае поможете просто пинком. В любом случае результат есть результат.
Присказка:
У меня есть конкретная цель-2016 «программировать „микроконтроллеры“, паять платы.
Целей достигать я умею: бюджет выделен, время заложено. В запасе имеется знание скриптовых языков(я админ), общая техническая подкованность, сбор неких простых (однако полезных мне) arduino-содержащих устройств (в вышеописанном стиле, скопировал-вставил, отладил, заработало).
Однако нет какого-то конкретного плана. Об это всё разбивается.
Поясню. Попытки стартовать обламываются примерно так:
Пример 1:
У меня есть под рукой советская „схемотехника“ 80ых годов издания. Я честно и трудолюбиво сажусь за неё. Однако с первых страниц описание уходит в очень дебри. Интуитивно я чувствую, что мне достаточного 20% этой информации сейчас, а вернуться к этим страницам стоит уже после. И так с многой литературой и даже тем что гуглится — нет постепенного погружения. Идеально: дайте мне закон ома, заставьте спать к нему простейшую схему поиграть и почувствовать(!), спалить светодиод и я готов идти к более сложному.
Пример два.
Я хочу хорошо паять, на текущий момент я могу спаять провода между собой, я могу поменять конденсатор в материнской плате. Однако (например) когда я припаиваю чип у меня между ножек получается месиво. Через три часа я с грехом пополам добиваюсь желаемого, проклянув всех и вся. Позже я узнаю что сейчас есть 100500 различных флюсов припоев флюсоотсосов, подходящих жал для паяльной станции, флюсов-гелей и прочих примочек и каждую имеет смысл использовать в своём случае. Достаточно было прихватить крайние ножки, провести раствором по остальным, взять другой припой и за 10 минут чип был припаян идеально. Хорошо что узнал хоть потом.
Однако систематизировано, данную информацию найти я не могу. Идеально: Урок NN, задача — распаиваем пяем мк, инструмент — //такой-то//, расходники — //такие-то//.
Итог:
Без какой-то систематизации своего обучения, заход в эту тему превращается в постоянные грабли.
Автор и комментаторы, поделитесь опытом как вы заходили в эту воду?
RomeoGolf
09.01.2016 19:59Азбука, библия и камасутра — это Хоровиц и Хилл, «Искусство схемотехники». А «поиграть и почувствовать» — это книжки из серии МРБ (массовая радиобиблиотека), особенно выпуски, ориентированные на «чайников», с игрушками типа простых одноголосвх музыкальных инструментов, датчиков наполнения ванны и т. п. Мои первые опыты были по книжке Б. С. Иванов «Электронные игрушки» из упомянутой серии, «Радио и связь», 1988 г.
насчет «программировать „микроконтроллеры“, паять платы» — для побаловаться с USB (программировать и паять я более-менее умею) я взял контроллер подешевле с возможностью внутрисхемного программирования по USB, спаял банальную схему из даташитки, к портам данных подключил светодиоды и кнопки по рекомендациям из той же даташитки. Плату рисовал утюгом, для четвертьмиллиметровых лап этой технологии хватает. Простое HID-устройство было собрано и заработало (спасибо Агурову) меньше, чем за неделю.
Что касается «паять» — ну, тут надо паять. Сорокаватным паяльником на 220 В со спиртоканифольным самодельным флюсом я паял корпуса VQFP (AT89C5131, месье не знает толк в извращениях, месье нищ и не имеет паяльной станции). Это приходит в основном с опытом. А вообще, чем тоньше «лапы» — тем более легкоплавкий желательно припой и тем тоньше жало. Температуру жала тоже надо держать в правильных пределах — сперва по рекомендациям умных книжек, потом по опыту. А флюс проще и дешевле всего — толченая канифоль в спирте, другие не настолько лучше, насколько дороже. Единственное, если, не дай бог, аллергия на дым канифоли — флюс придется подбирать по себе экспериментально, бывают случаи.Alexeyslav
10.01.2016 22:12Канифоль хорошо работает только на низких температурах, безсвинцовым припоем с её помощью паять невозможно — быстро пригорает и испаряется.
ploop
11.01.2016 07:44+1Да зачем новичкам безсвинцовка? На неё и опытные плюются.
Alexeyslav
11.01.2016 16:51Перепаивая конденсаторы на материнках приходится работать с безсвинцовым припоем…
valeriyk
11.01.2016 21:09ну если промышленная вытяжка дома есть, то можно и свинцовым
ploop
12.01.2016 07:40+2Ещё надеть белый халат и противогаз.
Промышленная вытяжка нужна, если вы работаете монтажником, паяете 8 часов в день. Из-за двух проводков в неделю ничего с вами не случится. Во всяком случае свинца вы больше наглотаетесь от камаза, газонувшего у вас под окнами.
Kolyuchkin
Извините за глупый вопрос: «С VS достаточно понятно, хотя тоже спорно… Но зачем QT Creator, для того, чтобы поиграться в консоли? Не проще ли просто воспользоваться услугами компиллятора и не париться с установкой сред программирования, заточенных больше для GUI?»
monah_tuk
Почему, когда люди слышат про Qt Creator, то обращают внимание только на слово Qt? Да, для чего-то ооооочень простого достаточно текстового редактора и gcc -o main main.cpp, а то вообще какого-нить ideone.com, но что-то чуть сложнее… подсветка синтаксиса, автодополнение, отладка (как же много вопросов на том же ru.SO которые решаются просто запуском под отладчиком) — оно помогает. Да, крутым перцам достаточно и саблайма — там всё настроить можно и самописного Makefile. Я вот не крутой, QtC даже для Baremetal использую (сейчас с платой вожусь, которая физически в Канаде находится, а сам я — во Владивостоке).
В общем, IDE хороший вариант для старта, где всё необходимое уже упаковано. Хорошо ли, плохо ли, удобно ли, неудобно ли — это другие вопросы. Плюс те же официальные сборки QtC сразу ставят и MinGW компилятор (речь про винду).
Kolyuchkin
Я с вами согласен насчет использования IDE для разработки малого-среднего-большого проекта. Но речь же шла про «поиграться в консоли». Разве так уж важна подсветка синтаксиса и автодополнение для ознакомления с С и написания (и небольшого изменения) типичного HelloWorld? Я близок к такой точке зрения, что, осознав необходимость фич, предоставляемых IDE, новичок сам решится на установку этой самой среды разработки… Но это лишь моя точка зрения.
AlexPublic
Что-то я не вижу ничего общего между «работой в консоли» (таким образом собираются сложнейшие проекты) и «HelloWold» (для этого дела действительно IDE не нужна).
Kolyuchkin
Вы не разделяете понятия разработки и сборки?
AlexPublic
Сборка происходит многократно в процессе разработки. )
AlexPublic
QT Creator — это не GUI дизайнер, а полноценная IDE, возможности которой в редактирование C/C++ кода на голову превосходят почти всё (продукты основанные на Эклипсе могут конкурировать) классические решения из мира микроконтроллеров.
VioletGiraffe
Продукты на Эклипсе преимущественно отстойны, конкурирует только Visual Studio (и выигрывает у Creator благодаря отличному отладчику; именно редактирование кода в Creator не хуже).
Randl
Да уж, по отладчику ни Qt Creator, ни CLion к VS пока не подобрались(
monah_tuk
В чём не подобрались? На десктопе — ещё может быть. Хотя, пока, хватало. А вот для Embedded (в т.ч. baremetal), так это VS даже близко к QtC не подобрался. Clion, к слову, тоже. Eclipse — лучше, но там других проблем много есть.
AlexPublic
Редактирование кода и в Qt Creator и в Eclipse и в Netbeans лучше чем в чистой Visual Studio. Если же брать VisualStudio + VisualAssist, то такой комплект уже может конкурировать в редактирование кода с перечисленными современными IDE.
По поводу отладчиков — это сложный вопрос, т.к. собственно отладкой часто занимается отдельное приложение (например gdb), а в IDE делают только визуализацию соответствующих данных. Так что тут надо разделять кто «виноват» за плюсы или минусы отдельных решений.
Но в сумме для локальных приложений решение по отладке в VS кажется чуть комфортнее. А вот для удалённых или каких-то нетривиальных типа на Андроиде или на микроконтроллере как раз QTCreator в последнее время стал удобнее всех.
VioletGiraffe
Редактирование кода и в Qt Creator и в Eclipse (насчёт последнего, кстати, не очень согласен) было лучше до появления VS 2015.
А как Qt Creator работает с Андроидом? Это только QML / Qt приложения на чистом С++, я правильно понимаю? Нормальное, нативное для Андроида Java приложение с С++ — ядром он не может?
AlexPublic
Ммм, вообще то C++ приложения вполне себе нативны для Андроида (не забываем про NDK). Просто у него нет доступа к некоторым возможностям из Java API (но зато есть множество других возможностей, недоступных из Java). Если нужны эти возможности, то многие из них доступны в C++ приложениях с использованием библиотеки Qt (там это реализовано через спец. прослойку на Java). И в любом случае при таком подходе получаются реально кроссплатформенные приложения, а не просто под Андроид.
Но весь текст выше не имеет никакого отношения к IDE, т.к. подобное (программировать на NDK или же с библиотекой Qt) можно делать в любой IDE. Разве что редактор GUI тогда будет в виде отдельного приложения, а не в самой IDE. Здесь же у нас речь шла о другом — об отладке. И она в Qt Creator поддерживается не только для локальных приложений, но и для удалённых машин (есть свои мелкие удобства), для андроида (там же свой adb, который кстати никак не связан с C++), для микроконтроллеров.
VioletGiraffe
Слишком сильная кроссплатформенность часто означает потерю нативности. ИМХО наилучший подход — вся бизнес-логика в кросс-платформенном ядре, и тонкая обёртка UI. Но я отклонился от темы, да.
AlexPublic
Да, это хороший подход. Но у него есть пара минусов:
1. Он подходит далеко не всегда. К примеру если мы имеем дело скажем с видео в реальном времени, то понятно, что единственный приемлемый вариант, это выводить его на экран средствами самого C++. И таких примеров множество.
2. Он довольно дорогой. Потому как надо иметь минимум по одному специалисту (а лучше по команде) для написание UI под каждую платформу: две главные (android и windows), две второго эшелона (ios и osx) и возможно ещё маргинальные (linux, winphone и т.д и т.п.).
ploop
Кстати, мне понравилась простота, как с помощью Qt Creator можно создать приложение под андроид. Ни разу не писав под него, буквально за 5 минут, подцепил телефон и приложение в режиме отладки запустилось на реальной железке!
Zifix
Upd. да, комменты неплохо бы обновлять перед отправкой :/