Комментарии 81
Ох какая классная наркомания! Круто!
По-моему, более «традиционный» подход к такому (который исповедуют всякие микропитоны и эспруино) — это интерпретатор на самом проце, с написанием кода в терминале. Не берусь судить, какой подход проще или лучше.
По-моему, более «традиционный» подход к такому (который исповедуют всякие микропитоны и эспруино) — это интерпретатор на самом проце, с написанием кода в терминале. Не берусь судить, какой подход проще или лучше.
Можно и так, но тут считай сравнивать теплое с мягким.
Потому как предназначения разные. Виртуальные машины / интерпретаторы на МК, могут исполнять скрипты автономно и вполне могут использоваться в продакшене. Но там мы упираемся в ограничение ресурсов МК, необходимость портирования вирутальной машины / интерпретатора, а так же еще написание библиотек переферии.
В моем подходе программы/скрипты не могут исполняться автономно, но нам доступны все ресурсы нашего хостового ПК, все виды библиотек и все виды языков программирования. При этом при использовании С/С++ можно использовать стандартные библиотеки от производителя для работы с переферией.
Потому как предназначения разные. Виртуальные машины / интерпретаторы на МК, могут исполнять скрипты автономно и вполне могут использоваться в продакшене. Но там мы упираемся в ограничение ресурсов МК, необходимость портирования вирутальной машины / интерпретатора, а так же еще написание библиотек переферии.
В моем подходе программы/скрипты не могут исполняться автономно, но нам доступны все ресурсы нашего хостового ПК, все виды библиотек и все виды языков программирования. При этом при использовании С/С++ можно использовать стандартные библиотеки от производителя для работы с переферией.
ПРошу прошения, не в ту ветку.
А есть инструменты, в которых можно сразу такой workflow рисовать и сразу в C компилировать?
Абсолютно противоположное впечатление: «После того как поработаешь в большом программировании С++, Java, Python, и т. Д с микроконтроллерами, возвращаться к маленьким и пузатым микроконтроллерам к большому программированию С++, Java, Python совсем не хочется. К их скудным монстроузным инструментам и библиотекам. Но делать иногда нечего, задачи real-time и автономности UI, хранения и обработки данных, не оставляют выбора.»
Подозреваю, что просто усталость от того, чем чаще занимаешься.
Я лично подустал от невозможности использовать динамическую память, от медленных компиляторов, от кривой поддержки хотя бы С++11, от безумных аппаратных косяков в процах и ошибок монтажа…
Все мы страдаем от несовершенства мира в своем углу.
Я лично подустал от невозможности использовать динамическую память, от медленных компиляторов, от кривой поддержки хотя бы С++11, от безумных аппаратных косяков в процах и ошибок монтажа…
Все мы страдаем от несовершенства мира в своем углу.
Скорее от недостатка понимания и/или отсутствия мотивации (неинтересно). А за статью спасибо, интересно, и, главное, применимо
невозможности использовать динамическую память
Запрет на предприятии? Если так, то да, больно. Если нет, то при использовании FreeRTOS все более чем шикарно. Работа с динамической памятью (при достаточном выделении ресурсов под ее дефрагментацию и прочее) очень удобна.
кривой поддержки хотя бы С++11
GCC адекватно может в C++14 (около года пишу так).
от безумных аппаратных косяков в процах
В самих ядрах косяков либо нет совсем, либо их не много. А вот периферия… Да.
ошибок монтажа…
С опытом такие вещи достаточно быстро раскрываются. Особенно если монтаж осуществлял не ты сам.
Лично мне нравится под МК программировать. Как только ты доходишь до понимания того, что твоего кода 5-10 кб, а остальное библиотеки и ты закидываешь их в отдельное место и больше почти не шьешь, то прошивка занимает не более 2-3 секунд. Очень удобно. А остальные 200 кб BSP лежат себе тихонько в конце flash и все. Как-нибудь напишу статью на эту тему. Как организовать это правильно. Есть подводные камни.
За статью спасибо. Приятно было почитать. Однако именно так я врят ли буду вопрос. Все же я когда-то давно написал универсальное средство вывода и отладки (да-да, на базе UART-а. Вернее USB-UART-а, но ни суть. Надо кстати задокументировать будет и описать...). Его мне хватает с головой.
GCC безусловно может C++14, но, позвольте, всегда ли доступна соответствующая версия компилятора для определённой платформы? Лет пять назад, когда цивилизованный мир давно уже перелез на С++11 и линукс 3.х, приходилось страдать с ядром 2.6.х и дремучим GCC для одной из вариаций ARM, на поддержку которой производитель (Texas Instruments) забил.
А на что именно так крепко забил TI?
И что, поддержка этого ядра исчезла из транка gcc?
Или просто их Code Composer старый? Не велика беда, мне кажется…
И что, поддержка этого ядра исчезла из транка gcc?
Или просто их Code Composer старый? Не велика беда, мне кажется…
Их композером вообще не пользовался. Работа велась с DM3730, и последняя сборка под эту платформу была в конце 11-го года: www.ti.com/tool/linuxdvsdk-dm37x
В ядрах третьей версии поддержки нужного чипа я тогда не нашёл, а делать порт самостоятельно было не в моих силах. Со сборкой более новых версий gcc для кросс-компилирования под эту платформу тоже были какие-то проблемы, сейчас уже не вспомню, какие.
В ядрах третьей версии поддержки нужного чипа я тогда не нашёл, а делать порт самостоятельно было не в моих силах. Со сборкой более новых версий gcc для кросс-компилирования под эту платформу тоже были какие-то проблемы, сейчас уже не вспомню, какие.
Запрет на предприятии? Если так, то да, больно. Если нет, то при использовании FreeRTOS все более чем шикарно. Работа с динамической памятью (при достаточном выделении ресурсов под ее дефрагментацию и прочее) очень удобна.
Ну, прямого запрета нет, только рекомендации MISRA :) Но с фриртосом действительно удобно, хотя бы heap_1 можно себе позволить и стеки руками не создавать.
В самих ядрах косяков либо нет совсем, либо их не много. А вот периферия… Да.
Кхе-кхе… Миландр 1986ВЕ1… Кхе-кхе…
Но да, ошибки в периферии существенно чаще попадаются.
С опытом такие вещи достаточно быстро раскрываются. Особенно если монтаж осуществлял не ты сам.
Ну, понятное дело, что раскрываются, просто каждый раз тратится уйма времени на поиски этих ошибок. А переделать печатную плату — это дело нескольких недель; пока оплата пройдет, пока ее изготовят, пока доставят…
GCC адекватно может в C++14 (около года пишу так).
Keil, к сожалению, только частично умеет в С++11, причем стандартная библиотека осталась от С++98. А их новый компилятор armclang пока сыроват.
Ну, я просто оставлю это здесь.
Страдаю с Analog Device SC-589 based платой. Там нет даже С++11 и попытка его включить на том говне мамонта той версии GCC приводит к внутренней ошибке линкера ибо линкер древний и забагованный в этом месте, а обновлять это никто не будет. Шёл 20189 год, а мне приходиться писать на C++03 под эту жопуелезку. И вот это дно происходит на железке которая даже не микроконтроллер, а трёх ядерная система ARM + 2 DSP с 2 ГБ ОЗУ. Всё очень плохо в этом королевстве :'(
Страдаю с Anal
arm-none-eabi-gcc поддерживает последний 17 стандарт в полной мере.
Вот да, с какой радостью я недавно клепал бутлоадер на xmega. Сидишь себе, пишешь, отлаживаешь, красота. Единственная проблема, мне надо было впихнуть 13кБ программы и библиотек в 8кБ бутлоадера. И от этого я получил ещё большее удовольствие. На ПК такое испытать можно, но только если делать что-то в ядре или типа того.
Форт. мне кажется, для микроконтроллеров с достаточным объемом ОЗУ (от 8Кб, скажем) и достаточным объемом FLASH (от 64Кб, скажем) форт будет хорошим решением для того, что бы сделать хоть прототип, хоть готовое приложение ))
А еще можно делать кровавый патчинг через терминал, тоже очень мило ))
Давеча попробовал mecrisp.sourceforge.net и остался доволен результатами. Как раз надо было сопрячь железку со странным протоколом с МК. Получилось хорошо и быстро.
Прототип сделал. Теперь думаю, что может его не перекладывать на Си, а продолжать писать на форте.
В этой, конкретной, реализации очень удобно разрабатывать тем, что можно слова создавать в ОЗУ, а потом пересоздавать их во FLASH. А если есть возможность подключить SD, то набросав редактор можно полностью вести процесс разработки на МК.
А еще можно делать кровавый патчинг через терминал, тоже очень мило ))
Давеча попробовал mecrisp.sourceforge.net и остался доволен результатами. Как раз надо было сопрячь железку со странным протоколом с МК. Получилось хорошо и быстро.
Прототип сделал. Теперь думаю, что может его не перекладывать на Си, а продолжать писать на форте.
В этой, конкретной, реализации очень удобно разрабатывать тем, что можно слова создавать в ОЗУ, а потом пересоздавать их во FLASH. А если есть возможность подключить SD, то набросав редактор можно полностью вести процесс разработки на МК.
Очень бы хотелось развернутую статью об этом опыте ( mecrisp )
Mecrisp stellaris unoficial doc
hightechdoc.net/mecrisp-stellaris/_build/html/index.html
Ещё можно этого автора почитать и его директорию проекта с Форт кодом на Github
jeelabs.org/2016/02/dive-into-forth
P.S. Экспериментировал, в частности, с www.mpeforth.com/xc7.htm
hightechdoc.net/mecrisp-stellaris/_build/html/index.html
Ещё можно этого автора почитать и его директорию проекта с Форт кодом на Github
jeelabs.org/2016/02/dive-into-forth
P.S. Экспериментировал, в частности, с www.mpeforth.com/xc7.htm
Голову вывернуть полностью надо с этим вашим фортом…
Когда-то давно коллега в «толстый» STM32 (тогда «толстым» был STM32F4) запихивал Lua.
Когда-то давно коллега в «толстый» STM32 (тогда «толстым» был STM32F4) запихивал Lua.
А почему просто не воспользоваться возможностями которые идут из коробки?
С кросс-компилятором идет gdb, openocd умеет работать как gdb сервер,
подключаемся gdb к openocd и вот у нас repl, gdb умеет и скрипты запускать,
и интерпретироваться подмножество языка С, типа *(int *)0x4 = 5;,
и можно даже вызывать отдельные функции из загруженного кода в память МК.
Ну и скрипты на python он поддерживает.
Хорошее замечание. Тоже об этом думал. Но давайе по порядку…
У GDB нет REPL, это скорее консоль для исполнения уже встроенных команд и откомпилированных команд программы. Может интерпретровать простые констуркции С но и только.
Проблематично вызывать ф-ции из программы, а допустим иницилизировать структуры и классы и передавать их в аргументы это будет жуткая боль.
Скрипты и расширения на python отчасти спасают, но всеравно читаемость и масштабируемость будет хромать.
Во второй части будет наглядный пример, как все довольно просто работать будет. В этой статье мы всего лишь готовим инструмент для этого.
У GDB нет REPL, это скорее консоль для исполнения уже встроенных команд и откомпилированных команд программы. Может интерпретровать простые констуркции С но и только.
Проблематично вызывать ф-ции из программы, а допустим иницилизировать структуры и классы и передавать их в аргументы это будет жуткая боль.
Скрипты и расширения на python отчасти спасают, но всеравно читаемость и масштабируемость будет хромать.
Во второй части будет наглядный пример, как все довольно просто работать будет. В этой статье мы всего лишь готовим инструмент для этого.
BSDL? Не, не слышал!
Я тоже не слышал. Может раскроете свою мысль?
Boundary Scan Description Language — с помощью такого файла-описания чипа и JTAG Boundary Scan (который как раз был в первую очередь придуман с целью упрощения тестирования плат с большим количеством взаимосвязанных чипов, а не для отладки/прошивки чипов, как многие думают), можно дрыгнуть любой ногой любого чипа, «сидящего на JTAG-chain, считать состояние любого пина и т.д., и все это без знания регистров и внутреннего устройства чипа (т.к. JTAG Boundary Scan-функционал реализован независимо от остальных частей кристалла, включая CPU). Минусом технологии является низкая скорость, т.к. данные последовательно загоняются с первый чип, потом во второй, третий и т.д., и потом возвращаются обратно в JTAG-железку, через которую идет управление.
Могу ошибаться, но еще наверно стоит к минусам отнести:
то что у микросхемы должен быть обязательно JTAG интерфейс — на той тестируемой плате это не прокатывало, так как там была единственная stm32 и у нее был выведен SWD только
стоимость такого решения — было бы интересно узнать у людей кто в теме
Ну и BSDL решает только вопрос тестирования соединений микросхем ( на сколько я понял )
Допустим более сложные тесты уже не провернуть — к примеру проверить работу трансформатора на определенной частоте, корректность работы микросхем (на случай их брака)
то что у микросхемы должен быть обязательно JTAG интерфейс — на той тестируемой плате это не прокатывало, так как там была единственная stm32 и у нее был выведен SWD только
стоимость такого решения — было бы интересно узнать у людей кто в теме
Ну и BSDL решает только вопрос тестирования соединений микросхем ( на сколько я понял )
Допустим более сложные тесты уже не провернуть — к примеру проверить работу трансформатора на определенной частоте, корректность работы микросхем (на случай их брака)
НЛО прилетело и опубликовало эту надпись здесь
Все относительно. Сейчас могут набежать, те кто топит за функциональное программирование, кто за хайповые golang и Котлин и закидать вас монадами, коурутинами и прочими плюшками.
Под каждую задачу свой инструмент. И что-то громоздкое городить на бедном мк, не всегда рационально.
P.s. не холивара ради.
Под каждую задачу свой инструмент. И что-то громоздкое городить на бедном мк, не всегда рационально.
P.s. не холивара ради.
У меня проект был попроще, электроника скорее моё хобби, и я наоборот решил попробовать применить приёмы из «большого» программирования прямо «в лоб». Сначала жестко разделил в коде логику и физику, хотя казалось, что логики было намного меньше — по факту оказалось наоборот. Логику тестировал прямо на x86, написал на неё юнит-тесты. Потом, написал что-то типа интеграционных тестов, но без физики — gpio и работа с uart/spi и прочим io — пробрасывалась программно на код, который работал с «той стороны» чипа (то есть на хостовой системе или в соседнем чипе). Это тоже гонялось какое-то время на x86, пока я доделывал устройство. Последним шагом создал тестовый стенд из готового устройства и raspberry pi, который своими gpio зацеплен за тест-поинты и может шить чипы устройства через бутлоадер по uart. На нем бегает агент от гитлаба, который по изменению кода в репозитории шьет новую версию и прогоняет ранее написанные тесты уже на железе с полноценной интеграцией всех компонент (тесты и код хостовой системы бегают на малине, в чипах прямо продакшн-прошивка без каких-либо тестовых инструментов живёт). Плюс к этому есть агент на x86, который гоняет ранее написанные юниты, дабы лишний раз не насиловать флеш контроллера, когда я делаю глупую ошибку.
Может конечно будь у меня OpenOCD я бы пошел по пути близкому к вашему, но так через test driven development и автоматизацию деплоя удалось упростить большую часть экспериментов с освоением периферии чипа, бонусом получив дополнительное покрытие тестами.
Пока у меня не до конца закрыт вопрос с аналоговым трактом, но его для успешного завершения проекта всё равно решать, лень мне руками несколько десятков модулей тестировать, поэтому, видимо, стенд обрастёт парочкой программируемых источников напряжения для генерации тестовых сигналов (хотя может хватит фильтрованного ШИМа с малины опять же).
Может конечно будь у меня OpenOCD я бы пошел по пути близкому к вашему, но так через test driven development и автоматизацию деплоя удалось упростить большую часть экспериментов с освоением периферии чипа, бонусом получив дополнительное покрытие тестами.
Пока у меня не до конца закрыт вопрос с аналоговым трактом, но его для успешного завершения проекта всё равно решать, лень мне руками несколько десятков модулей тестировать, поэтому, видимо, стенд обрастёт парочкой программируемых источников напряжения для генерации тестовых сигналов (хотя может хватит фильтрованного ШИМа с малины опять же).
Крик души.
Как же меня достали эти микроконтроллеры. Я больше так жить не хочу. Я устал. Это супергеморой. Я устал от того количества проводов, и места, которое занимает устройство на столе. От того что иногда приходится подготавливаться, припаиваться, чтобы посмотреть события на шине, чтобы отладить периферию. Инструменты отладки и программирования есть разные, нужно разбираться в различных программаторах, методах, способах, и чего-там нового напридумывали разработчики этого софта. Самый ужасное это программирование периферии. Помимо хороших знаний схемотехники, конкретной схемы, особенностей, нужно вкуривать дотащит. Если у вас 5-10 различных периферийных устройств на разных шинах, в среднем вам нужно досконально знать и понимать как это устройство лучше использовать. Средний даташит до 100 страниц (ADE7878A), потом нужно написать под него LL драйвер, если у вас RTOS, на одной шине, реализовать атомарный доступ, драйвер ос по сути. Читать Datasheet, App note, Reference Manuals, Programming Manuals и понимать как лучше реализовывать те или иные фишки. И это только для конкретного проца или серии. Хороший проект, и вы прочитаете > 1000 страниц.
Если вы более-менее сложную электронику разрабатываете, вам нужна техника, которую нужно переодически обновлять. За этот год только купил: анализатор спектра, осциллограф, лаб БП. Есть хороший мультиметер, анализатор логический. А мне еще генератор сигналов векторный нужен. Периодически RF занимаюсь. До кучи вы должны быть электронщиком-схемотехником.
Прошивки могут быть достаточно большими, например текущий проект: 20к строк бутлоадер + 80к строк основная. Это без либ конечно. Недавно ступил и не поставил скобочки в условии у функции, как итог, прошивка неожиданно падала, а компилятор молчал. Или решил обновить freertos на свежий, поставил скомпилировал и устройство стало падать раз в день. От чего? Как найти? Вернул в зад. Отладка сложная, невозможна без таких подходов, как у автора например. В свое время создал для себя UART логгер на SD, тк устройство не для работы на столе предназначалась.
Единственный критерий исправной прошивки — работа устройства без всяких ватчдогов в течении недели/месяца. Это значит что код должен быть качественным.
Софт: Нормальный софт платный, я пользуюсь Visual Studio + VisualGDB + ReSharper. Две последних позиции более 10к в год. Не понимаю людей как можно пользоваться Keil, IAR, CooCox, Eclipse и тд. Пользовался всем, ужасный софт.
Документация: Все нужно документировать, иначе никто кроме тебя не разберет, особенно те места, где пересекаются границы программистов.
Иногда требуется софт на ПК для настройки, или сам пишешь если нет документации или программиста. Лучше делать его кроссплатформенный.
Зарплата: разРаб на stm32 — 100к в СПБ, ну и чуть больше в МСК, а в регионах… Знать нужно ВООООО, опыта — ВООООО лет от 5-ти.
Для меня большое счастье, когда нужно писать например на Go или Java. А SQL — это кайф. А mongoDB — еще больший кайф. А знаешь Java можно сказать что знаешь Android, несмотря на то что нужно в тренде быть, знать что нового в ОС напридумывали и как это правильно в коде реализовать.
Все, кто ко мне приходят с целью узнать, как быть разрабом МК, отговариваю, показываю этот супергеморой, показываю ЗП на HH, говорю что лучше быть Android программистом. Go, Java, Kotlin.
Один мои приятель, с появлением второй дочери, в регионе, денег перестало хватать, бросил МК, и ушел в Go. Можно быстро переучиться с C/C++. Спустя год зарабатывает хорошие деньги, и гораздо счастлив.
Другие мои знакомые, кто хоть раз писали прошивки, сразу поняв что это геморой, ушли в системное C++/C# и БД.
Не занимайтесь этими микроконтроллерами, не тратьте свое драгоценное время, они его отбирают, отбирают эмоции, которые вы могли бы потратить на родных и близких и задолжали, будьте программистом и хорошо зарабатывайте. Вы не будете писать такие эпосы, а в вашей жизни будет время больших чудес, а не штудированная даташитов.
Как же меня достали эти микроконтроллеры. Я больше так жить не хочу. Я устал. Это супергеморой. Я устал от того количества проводов, и места, которое занимает устройство на столе. От того что иногда приходится подготавливаться, припаиваться, чтобы посмотреть события на шине, чтобы отладить периферию. Инструменты отладки и программирования есть разные, нужно разбираться в различных программаторах, методах, способах, и чего-там нового напридумывали разработчики этого софта. Самый ужасное это программирование периферии. Помимо хороших знаний схемотехники, конкретной схемы, особенностей, нужно вкуривать дотащит. Если у вас 5-10 различных периферийных устройств на разных шинах, в среднем вам нужно досконально знать и понимать как это устройство лучше использовать. Средний даташит до 100 страниц (ADE7878A), потом нужно написать под него LL драйвер, если у вас RTOS, на одной шине, реализовать атомарный доступ, драйвер ос по сути. Читать Datasheet, App note, Reference Manuals, Programming Manuals и понимать как лучше реализовывать те или иные фишки. И это только для конкретного проца или серии. Хороший проект, и вы прочитаете > 1000 страниц.
Если вы более-менее сложную электронику разрабатываете, вам нужна техника, которую нужно переодически обновлять. За этот год только купил: анализатор спектра, осциллограф, лаб БП. Есть хороший мультиметер, анализатор логический. А мне еще генератор сигналов векторный нужен. Периодически RF занимаюсь. До кучи вы должны быть электронщиком-схемотехником.
Прошивки могут быть достаточно большими, например текущий проект: 20к строк бутлоадер + 80к строк основная. Это без либ конечно. Недавно ступил и не поставил скобочки в условии у функции, как итог, прошивка неожиданно падала, а компилятор молчал. Или решил обновить freertos на свежий, поставил скомпилировал и устройство стало падать раз в день. От чего? Как найти? Вернул в зад. Отладка сложная, невозможна без таких подходов, как у автора например. В свое время создал для себя UART логгер на SD, тк устройство не для работы на столе предназначалась.
Единственный критерий исправной прошивки — работа устройства без всяких ватчдогов в течении недели/месяца. Это значит что код должен быть качественным.
Софт: Нормальный софт платный, я пользуюсь Visual Studio + VisualGDB + ReSharper. Две последних позиции более 10к в год. Не понимаю людей как можно пользоваться Keil, IAR, CooCox, Eclipse и тд. Пользовался всем, ужасный софт.
Документация: Все нужно документировать, иначе никто кроме тебя не разберет, особенно те места, где пересекаются границы программистов.
Иногда требуется софт на ПК для настройки, или сам пишешь если нет документации или программиста. Лучше делать его кроссплатформенный.
Зарплата: разРаб на stm32 — 100к в СПБ, ну и чуть больше в МСК, а в регионах… Знать нужно ВООООО, опыта — ВООООО лет от 5-ти.
Для меня большое счастье, когда нужно писать например на Go или Java. А SQL — это кайф. А mongoDB — еще больший кайф. А знаешь Java можно сказать что знаешь Android, несмотря на то что нужно в тренде быть, знать что нового в ОС напридумывали и как это правильно в коде реализовать.
Все, кто ко мне приходят с целью узнать, как быть разрабом МК, отговариваю, показываю этот супергеморой, показываю ЗП на HH, говорю что лучше быть Android программистом. Go, Java, Kotlin.
Один мои приятель, с появлением второй дочери, в регионе, денег перестало хватать, бросил МК, и ушел в Go. Можно быстро переучиться с C/C++. Спустя год зарабатывает хорошие деньги, и гораздо счастлив.
Другие мои знакомые, кто хоть раз писали прошивки, сразу поняв что это геморой, ушли в системное C++/C# и БД.
Не занимайтесь этими микроконтроллерами, не тратьте свое драгоценное время, они его отбирают, отбирают эмоции, которые вы могли бы потратить на родных и близких и задолжали, будьте программистом и хорошо зарабатывайте. Вы не будете писать такие эпосы, а в вашей жизни будет время больших чудес, а не штудированная даташитов.
Угу-угу, все так, программировать можно и в более комфортных условиях. Только вот ни одна из этих областей не дает то самое чувство, когда берешь в руки железку, которую сделал и запрограммировал ты, и она работает. Когда видишь, что твоя работа — не просто биты в памяти и пиксели на экране.
Согласен, меня самого это и привлекает, когда бездушная железка начинает «дышать».
Но с опытом, считаю железка это проблемы — ее нужно произвести, ее нужно продать. Иногда нужны компоненты, которые нужно еще и растаможить.
Софт легко поправить и выслать новую версию, с железом так не получится, будешь рекламации собирать от заказчиков, и ответственность выше, потому что железка должна работать надежно.
Но с опытом, считаю железка это проблемы — ее нужно произвести, ее нужно продать. Иногда нужны компоненты, которые нужно еще и растаможить.
Софт легко поправить и выслать новую версию, с железом так не получится, будешь рекламации собирать от заказчиков, и ответственность выше, потому что железка должна работать надежно.
До кучи ещё можно вспомнить ПЛИС и VHDL, тоже зона отладочного кошмара. Четыре года назад ушёл с микроконтроллеров и микропроцессоров на более высокоуровневое программирование, и не жалею. Тоже конечно не везде можно нормально отлаживаться, не для всех языков и не для всех окружений удаётся построить удобную инфраструктуру. В общем, на самом деле всё это, конечно, вопрос в основном опыта и личных пристрастий: чем их больше в какой-то области, там и хорошо :)
Ваш пост читается как «разработка встраиваемых систем — это очень интересно, но не для всех» :). Настоящее удовольствие приходит тогда, когда ты еще и разработчик собственно железки, которую отом оживляешь. А самое-самое удовольствие, когда в проекте есть место и для легкого безумияПЛИС, программу/не программу для которой тоже пишешь ты.
Полное слияние железа и софта для него.
Ну да, это должно нравиться, иначе боль, тоска и в лучшем случае уход в чистые программисты. С зарплатами увы, есть такая проблема, которая усугубляется еще и тем, что работа начинает «держать». Уходить с нее, собственно, некуда, только на другую такую же.
Полное слияние железа и софта для него.
Ну да, это должно нравиться, иначе боль, тоска и в лучшем случае уход в чистые программисты. С зарплатами увы, есть такая проблема, которая усугубляется еще и тем, что работа начинает «держать». Уходить с нее, собственно, некуда, только на другую такую же.
Так, на какой язык проще переучиваться после верилога?
На VHDL ). Языки описания аппаратуры слишком сильно отличаются от языков программирования. Другой способ мышления, если хотите.
А с нуля тогда что лучше изучать?
Речь про HDL-языки? Вряд ли можно сказать, что «лучше». По ощущениям, на верилоге пишет бОльшее количество народа. С другой стороны, VHDL более структурированный, что ли, плюс есть некоторые возможности, которых нет у верилога. С третьей стороны, есть еще и SystemVerilog, с неимоверно более богатыми возможностями в плане верификации. С вменяемой литературой вот только по нему плоховато.
По остальным языкам, впрочем, тоже. В свое время мне ветка по верилогу на forum.ixbt.com помогла больше, чем все имеющиеся на тот момент книги.
По остальным языкам, впрочем, тоже. В свое время мне ветка по верилогу на forum.ixbt.com помогла больше, чем все имеющиеся на тот момент книги.
«разработка встраиваемых систем — это очень интересно, но не для всех»
Подписываюсь под каждым словом.
И под каждым словом автора комментария в начале ветки (кроме SQL и Java, не приходилось разрабатывать на них).
Уже несчётное число раз думал уйти нафиг из embedded. Но кайф от разработки железа, пайки, отладки удерживает. Плюс ЗП вроде вменяемая.
Надеюсь, что всё же к 30 годам гормоны улягутся и я таки уйду в чистого программиста, ибо ситуация с соотношением ЗП\навыки в эмбеде и правда удручает.
К 30 годам станет только хуже, и желание и речь про что-то изменить сменится на какой в этом смысл.
А с кайфом по разработке железа, нужно понять какого он типа — если это доминантность (делаешь то что другие не могут или что-то уникальное что никто другой не делал), я всегда вспоминаю профессоров в институте, некоторые из них академические ветки придумали, но при этом ходят в протертых штанах, получают копейки, и за это держаться, когда зав.каф. уже давно используют по полной индексы хирша, гранты, конференции и тд в том числе для прибыли.
Наверное, в определенное время они не готовы меняться, что против логики жизни, и остаются делать то, что редко кому нужно.
Это не значит что нужно талант на деньги менять, это значит что свое реальное время жизни надо менять на реальные ресурсы.
А с кайфом по разработке железа, нужно понять какого он типа — если это доминантность (делаешь то что другие не могут или что-то уникальное что никто другой не делал), я всегда вспоминаю профессоров в институте, некоторые из них академические ветки придумали, но при этом ходят в протертых штанах, получают копейки, и за это держаться, когда зав.каф. уже давно используют по полной индексы хирша, гранты, конференции и тд в том числе для прибыли.
Наверное, в определенное время они не готовы меняться, что против логики жизни, и остаются делать то, что редко кому нужно.
Это не значит что нужно талант на деньги менять, это значит что свое реальное время жизни надо менять на реальные ресурсы.
А удовольствие от работы — это реальный ресурс? Или же реальный ресурс это всегда кэш? И как тогда быть с вещами, на которые тратишь свое реальное время и реальный кэш, взамен получая удовольствие?
Цель/смысл жизни это штука такая… У всех разная.
Цель/смысл жизни это штука такая… У всех разная.
Я считаю так, если ты настоящий программист, ты можешь писать на любом языке. Это подтверждают мои некоторые друзья, которые иногда шли устраиваться на backend, но собеседование было по frontend, их брали на работу, за месяц они вникали в тему, и начинали работу над проектом. И им по кайфу это стало делать.
А все железо, они на хобби оставили, коптеры собирают, ну и что там AlexGyver делает на youtube. Просто не нужно бояться перемен.
А все железо, они на хобби оставили, коптеры собирают, ну и что там AlexGyver делает на youtube. Просто не нужно бояться перемен.
Тут вот обсудили, что с hdl на не-hdl сложно перескакивать или с асм-а на ооп…
А что делать, если не «программист», а «инженер» (да не будет это никому в обиду сказано)? :) И тем более, если с хоббями (совершенно другими) и так нет никаких проблем? :)
Просто вот для Вас, если я правильно понимаю, «эмбеддед»===«программированию контроллеров». Написание программ для них, не больше и не меньше. Работа с собственно самой железкой скорее неприятное дополнение, обязанность, нежели чем сколь-нибудь интересный процесс. Ещё и деньги, фиктически, отнимает. В таком случае на этом «эмбеддед» сидеть нет никакого смысла, это верно.
Просто вот для Вас, если я правильно понимаю, «эмбеддед»===«программированию контроллеров». Написание программ для них, не больше и не меньше. Работа с собственно самой железкой скорее неприятное дополнение, обязанность, нежели чем сколь-нибудь интересный процесс. Ещё и деньги, фиктически, отнимает. В таком случае на этом «эмбеддед» сидеть нет никакого смысла, это верно.
Я скорее сам инженер. Для меня нормально это и схемотехника и программирование.
Embedded я скорее называю разработка устройства, с процом и ОЗУ, где есть ОС, более менее полноценная типа Linux. Это сложная схема и плата, uboot, это настройка ядра, buildroot, это кросс-компиляция, ну и дальше, какой-либо твой софт.
Все что типа at91sam, stm32, nxp и тд. это микроконтроллеры, там интересные схемотехнические решение, и крайне сложный софт. Это иногда разработка DC/DC (тут недавно статья была от Nordic), иногда и трансформатор помотать руками приходится. Это про то как и чем bulk от boost отличаются, и что такое Sepic. А прошивка — вдохнуть жизнь в плату.
Я просто хочу сказать, что на берегу, где есть backend/frontend есть жизнь, она более интересная, более нужная людям и как результат более высокооплачиваемая. А драгоценное время жизни, вы можете потратить на родных и близки, на то, что действительно важно!
Embedded я скорее называю разработка устройства, с процом и ОЗУ, где есть ОС, более менее полноценная типа Linux. Это сложная схема и плата, uboot, это настройка ядра, buildroot, это кросс-компиляция, ну и дальше, какой-либо твой софт.
Все что типа at91sam, stm32, nxp и тд. это микроконтроллеры, там интересные схемотехнические решение, и крайне сложный софт. Это иногда разработка DC/DC (тут недавно статья была от Nordic), иногда и трансформатор помотать руками приходится. Это про то как и чем bulk от boost отличаются, и что такое Sepic. А прошивка — вдохнуть жизнь в плату.
Я просто хочу сказать, что на берегу, где есть backend/frontend есть жизнь, она более интересная, более нужная людям и как результат более высокооплачиваемая. А драгоценное время жизни, вы можете потратить на родных и близки, на то, что действительно важно!
ходят в протертых штанах
Посмотрел на свои ботинки, в которых вместо замка — пластиковые стяжки для проводов…
Чёрт, пора идти за новыми. Мне просто лень на другой конец города ехать.
А насчёт разработки железа — в данный момент времени я просто понимаю, что не смогу променять то, чем мне нравится заниматься, на то, от чего меня спать тянет, пусть даже за вдвое большую ЗП.
Очень надеюсь, что через несколько лет я всё же смогу найти направление в IT вне эмбеда, за которое смогу зацепиться и в которое смогу развиваться.
Я вот смотрю в сторону Китая — там сейчас востребована разработка всяких девайсов, и железячники и программеры в цене. Но эта страна на любителя конечно, не всем подойдет.
Дело тут не только в ботинках, а скорее в семье и воспитании. И чаще негативном. Меня например в детстве, мамка на базар таскала, купить «серенький» свитерок под горлышко. А мне с утра так это не нравилось, а меня таскали и предлагали, ну вот посмотри, а этот, а тот. В итоге в 18-20 лет я ходил в чем угодно, лишь бы не идти в магазин за вещами. Что сыграло плохую штуку, барышням, которые мне нравились, я был не очень интересен. Помню, как появились деньги, насильно себя заставлял идти в магазин идти и выбирать, мерять, снимать. Сейчас с этим вроде хорошо. Теперь я за вещами в Стамбул езжу, там она дешевле стоит, ну и там вкусная еда еще.
Я сейчас думаю что здорово быть, красивым (следить за собой, одеваться стильно и в спортзал регулярно ходить).
Вам наверное по советую сделать большой и сложный проект embedded, значимый для вашей психики. Завершить что-то. Тогда вам захочется чего-то нового.
Я сейчас думаю что здорово быть, красивым (следить за собой, одеваться стильно и в спортзал регулярно ходить).
Вам наверное по советую сделать большой и сложный проект embedded, значимый для вашей психики. Завершить что-то. Тогда вам захочется чего-то нового.
В политике самый высокий курс обмена времени на блага, в финансах, но никак не в программировании.
А самое-самое удовольствие, когда в проекте есть место и для
легкого безумияПЛИС, программу/не программу для которой тоже пишешь ты.
Это нужно только в военных НИИ для разработки радаров.
НЛО прилетело и опубликовало эту надпись здесь
Определенно последнее, что мне не понравилось в том чтобы быть таким разработчиком.
Меня перевели в новый отдел, нас стало 4 человека: схемотехник и три программиста. Знаете сколько было руководителей? 3 человека. На них весели еще обязанности, но главной конечно было драть с нас 3 шкуры. Нужно было делать то что нужно, а не то что ты хочешь, и не всегда этот проект или железка интересна. Конечно, нужно уметь работать над проектом, в независимости от того нравится или не нравится железка, но порой, когда запросов много ты просто превращается в некий обработчик чужих хотелок. А для работы того или иного устройства нужно вложить душу. Я понял, что в современном мире, имея убеждения, которые позволяют кайфовать от того что например железка заморгала как надо, более шустрые ребята будут попросту использовать вас, ваше время, мозги, меняя на ЗП в 65к (3 года назад была такая зп у меня). Таким поведением и взглядами вы заранее обрекаете себя на использование вас другими бабуинами.
Душу можно вкладывать в свой проект, в свой бизнес, что не посредственно вам эквивалент затрачено частички души, времени и сил. А не пустые поздравления старших коллег, показывающих вашу значимость, признание в коллективе, или эмоции от заработавшей платы, по сути манипулируя вами.
Как только простые люди поймут основу своего я, самоидентифицируются, управлять, т.е. манипулировать ими будет чрезвычайно тяжело».
Я уволился, сейчас получается зарабатывать в разы больше, и заниматься своими проектами. Следующий шаг — уйти из программирования под МК и стать разработчиком на высокоуровневых языках. Мк, оборудование останутся только для хобби проектов. Жизнь с годами должна становиться проще.
Меня перевели в новый отдел, нас стало 4 человека: схемотехник и три программиста. Знаете сколько было руководителей? 3 человека. На них весели еще обязанности, но главной конечно было драть с нас 3 шкуры. Нужно было делать то что нужно, а не то что ты хочешь, и не всегда этот проект или железка интересна. Конечно, нужно уметь работать над проектом, в независимости от того нравится или не нравится железка, но порой, когда запросов много ты просто превращается в некий обработчик чужих хотелок. А для работы того или иного устройства нужно вложить душу. Я понял, что в современном мире, имея убеждения, которые позволяют кайфовать от того что например железка заморгала как надо, более шустрые ребята будут попросту использовать вас, ваше время, мозги, меняя на ЗП в 65к (3 года назад была такая зп у меня). Таким поведением и взглядами вы заранее обрекаете себя на использование вас другими бабуинами.
Душу можно вкладывать в свой проект, в свой бизнес, что не посредственно вам эквивалент затрачено частички души, времени и сил. А не пустые поздравления старших коллег, показывающих вашу значимость, признание в коллективе, или эмоции от заработавшей платы, по сути манипулируя вами.
Как только простые люди поймут основу своего я, самоидентифицируются, управлять, т.е. манипулировать ими будет чрезвычайно тяжело».
Я уволился, сейчас получается зарабатывать в разы больше, и заниматься своими проектами. Следующий шаг — уйти из программирования под МК и стать разработчиком на высокоуровневых языках. Мк, оборудование останутся только для хобби проектов. Жизнь с годами должна становиться проще.
Подписываюсь под каждым Вашим словом.
На эту тему есть отдельный культовый опус
Вы в Самом Деле Хотите Стать Программистом Микроконтроллеров?
https://habr.com/ru/articles/668368/
Отладка сложная, невозможна без таких подходов, как у автора например. В свое время создал для себя UART логгер на SD, тк устройство не для работы на столе предназначалась.Единственный критерий исправной прошивки — работа устройства без всяких ватчдогов в течении недели/месяца. Это значит что код должен быть качественным.
Я тоже от этого сильно страдал до того как не начал пользоваться интерфейсом командной строки (CLI) поверх UART вкупе с модульными тестами внутри прошивки.
https://habr.com/ru/articles/694408/
Теперь жизнь буквально заиграла новыми красками
Вся отладка теперь сводится к запуску модульный тестов из UART-CLI и просмотру YouTube пока формируется отчет. Красота!
Знать нужно ВООООО, опыта — ВООООО лет от 5-ти.
Вот, кстати, список того, что надо знать, чтобы работать программистом микроконтроллеров
Коллоквиум по программированию микроконтроллеров
https://habr.com/ru/articles/676076/
Даже не знаю много это или мало?
На мой взгляд, микроконтроллеры — это одна из немногих областей, где осталось настоящее программирование, с алгоритмами и оптимизацией. В большом мире, где фреймворк на фреймворке и ты только дергаешь чужие методы и раскидываешь кнопки по форме, совсем не осталось места для творчества.
НЛО прилетело и опубликовало эту надпись здесь
Из-за объема, бывало и такое что делили прошивку, и писали в несколько человек.
Дело еще в том что кому-то проще читать даташиты и описывать LL функции, а кто-то, кто постоянно с абстракциями работает, он может над логикой поработать.
Как не странно, си отлично поддерживает модульность, функции заглушки и тд, и позволяет работать в команде. Так вот, те, кто работает только с логикой, уже не знают что там внизу, хоть и могут посмотреть.
«Фреймворк на фреймворке» — у меня так руководитель говорил, хотя на деле, для современных stm32 уже приходится использовать криптолибы, либы USB, и другие.
Наверное он так говорил, тк он иногда на ассемблере писал под какой-нибудь pic10f200, да и вообще asm много времени посвятил и разным процам.
Дело еще в том что кому-то проще читать даташиты и описывать LL функции, а кто-то, кто постоянно с абстракциями работает, он может над логикой поработать.
Как не странно, си отлично поддерживает модульность, функции заглушки и тд, и позволяет работать в команде. Так вот, те, кто работает только с логикой, уже не знают что там внизу, хоть и могут посмотреть.
«Фреймворк на фреймворке» — у меня так руководитель говорил, хотя на деле, для современных stm32 уже приходится использовать криптолибы, либы USB, и другие.
Наверное он так говорил, тк он иногда на ассемблере писал под какой-нибудь pic10f200, да и вообще asm много времени посвятил и разным процам.
Напомнило историю одного байта
А не думали попробовать в qemu эмулировать устройство? А целом вроде на английском сейчас только ленивый не пишет/докладывает про off-target test driven development…
Вы про тестирование программ на эмуляторе?
Если так то у меня стояла другая задача.
Мне требовалось проверять физические устройства/платы на ошибки монтажа, корректность установленных микросхем.
А так же мне нужен был удобный инструмент для экспериментов и изучения работы с новыми устройствами.
Поэтому qemu и off-target test driven development мне тут в помощь не будут.
Если так то у меня стояла другая задача.
Мне требовалось проверять физические устройства/платы на ошибки монтажа, корректность установленных микросхем.
А так же мне нужен был удобный инструмент для экспериментов и изучения работы с новыми устройствами.
Поэтому qemu и off-target test driven development мне тут в помощь не будут.
Репозиторий Mecrisp Форт кода Jeelabs
github.com/jeelabs/embello/tree/master/explore/1608-forth
github.com/jeelabs/embello/tree/master/explore/1608-forth
Абсолютно похожие мысли. Начинал с программирования МК (STM32, PIC32MX), потом «перетек» в DSP (Analog Devices), сейчас докатился до того, что пишу целиком на ассемблере под DSP-ядро (вместе с оптимизацией), которые крупные вендоры встраивают в свои SoC. Производитель этого DSP-ядра не поставляет C-компилятор. Планирую в ближайшем будущем уходить в С++ или Rust, в свободное время изучаю эти языки, и наконец-то забыть весь этот фулл-таймовый ассемблер как страшный сон.
Мое личное мнение — большинство психологических неудобств вытекает из того, что при работе с железом, плохо оборудованы рабочие места, и сам рабочий процесс не очень хорошо налажен. Ну вот банальщина — один осциллограф на отдел, две или три платы на 6 и более программистов, все испытательные стенды собраны из веточек из желудей (Вместо разъемов скрутки которые вылетают и т.п.) потому что «Зачем нам нормально все собирать, все равно этот стенд потом разбирать» и так далее. «Электротехника — это наука о контактах» — вот это точное попадание. Можно до посинения отлаживать код, а потом выяснить, что кто-то где-то вместо пайки засунул провод в разъем на стенде, капнул при пайке припоем и замкнул цепь, подал вместо 24V DC 24V AC, примеры можно до бесконечности приводить…
В общем, если коротко о главном, в меньшинстве пишется сама полезная нагрузка (функционал и т.п.) а в большинстве — борьба со всем сопутствующим.
Мое личное мнение — большинство психологических неудобств вытекает из того, что при работе с железом, плохо оборудованы рабочие места, и сам рабочий процесс не очень хорошо налажен. Ну вот банальщина — один осциллограф на отдел, две или три платы на 6 и более программистов, все испытательные стенды собраны из веточек из желудей (Вместо разъемов скрутки которые вылетают и т.п.) потому что «Зачем нам нормально все собирать, все равно этот стенд потом разбирать» и так далее. «Электротехника — это наука о контактах» — вот это точное попадание. Можно до посинения отлаживать код, а потом выяснить, что кто-то где-то вместо пайки засунул провод в разъем на стенде, капнул при пайке припоем и замкнул цепь, подал вместо 24V DC 24V AC, примеры можно до бесконечности приводить…
В общем, если коротко о главном, в меньшинстве пишется сама полезная нагрузка (функционал и т.п.) а в большинстве — борьба со всем сопутствующим.
Белые люди тестируют проекты с помощью JTAG Boundary Scan
Если вы к ним относитесь, то интересно будет узнать об этой технологии, особенно интересна цена.
EEVblog #499 — What is JTAG and Boundary Scan?
Эта технология, когда PC является кукловодом для микроконтроллера-марионетки, идеальна для тестов на пропай при массовом производстве электронных плат.
Можно на NetTop PC прокручивать хитрый алгоритм Cross-Detect
https://habr.com/ru/articles/762142/
и протестировать PCB до того как на нее накатят первую прошивку.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как перестать писать прошивки для микроконтроллеров и начать жить