Я было расстроился, что не смогу работать через программатор (это существенно ускоряет заливку скетчей в ардуинку), но, как оказалось, VSCode тоже не умеет с ним работать (никак баг не починят). Так что по итогу, я не так много и потерял.
Сам по себе VSCode почти ничего не умеет, но настроить его на программирование Arduino - несложная задача.
Язык программирования у Arduino — это С++, но система сборки своя, избавляющая новичков от некоторых “неприятных” особенностей языка.
По факту там avr-gcc, из особенностей, только свой дополнительный набор библиотек. Makefile, похоже, генерится автоматом, но это не точно. Всё это, при минимальном желании, можно подключить и писать программы хоть vi, хоть в sublime, хоть ещё в чём.
Так в приведённой Вами цитате и есть ответ. Содержимое Makefil'а генерировалось плагином и что там будет зависело, видимо, от левой пятки автора плагина.
Мне надоели эти "радости" - когда автор плагина спрятал от меня довольно простые вещи, типа автоматизировав рутинную работу, при этом наворотив там там невесть чего, а потом перестал поддерживать свой проект. Проще один раз разобраться в базовых вещах и сделать всё самому. При таком подходе, даже вернувшись к проекту через десять лет, даже если IDE перестала существовать, Вы можете всё подправить буквально в блокноте.
Может у Вас что-то с программатором? Сегодня специально подключил atxmega32a4 по pdi к дракону, нормально читается, шьётся, в отладку заходит. Всё программами из репозитория Debian, ни каких самостоятельных сборок. Вообще с этой серией никогда не работал, камень случайно попал в руки.
Не могу на нём включить внутренний генератор 32МГц, всё застряёт на ожидании флага запуска генератора.
В том-то и дело, при таком подходе минимум движений при переезде с компа на комп. Если у Вас пути к программам находятся в PATH, то вообще ничего менять не нужно, даже между Win и Linux, а я так и работаю. В своей первой стать, в комментариях, я писал, что перемещаюсь между рабочей Win7, домашним Debian и PaspberryPi4. Синхронизация проекта идёт через git-репозиторий, доступный со всех трёх машин. Никаких изменений вносить не приходится.
К тому же, это поначалу кажется всё сложно и непонятно, но после пары проектов, понимаешь, что всё нормально. К тому же это не самый сложный Makefile, бывает как понаворотят... А .c и .h вам всё равно писать, если программируете не всё в одном файле.
Адекватный ответ будет в виде — их проще детектировать и по таким маркерам проще определять размер всего штрихкода.
Я так думаю.
Не так давно попадалась объёмная статья по штрихкодам, но найти нё быстро не получается и лень, а по памяти я точно не помню.
А эти НИКТО в курсе? По-моему нет, и вполне используем.А ещё можете посмотреть на структурки многих широко используемых микросхем, там биполярников хватает и как раз в описанных применениях. Если можно в микросхемах, почему нельзя в дискретке?
ШИМ не даст такого чистого выхода как ЦАП, как ни старайся. Бывают ситуации когда это критично. Поэтому комплект ЦАП + Биполярник ещё долго будет актуален. По сути была схема 3 статьи с последовательным резистором в базе.
А вообще статья хорошая, для начинающих. Если бы молодые инженеры, последние курсы ВУЗов и выпускники, обладали хотя бы такими знаниями и представлениями - с ними можно было бы работать и давать какую-то работу. Надеюсь, что только мне везёт на таких "специалистов" и в других местах всё лучше.
Может существенное отличие в скоростях, высотах, размерах и прочих мелочах, а ещё во времени на операцию. Если текущая цель - четыре беспилотника за пол-часа, то круто.
Не спорю, но зачем мне ещё один плагин, если я всё это могу и сам сделать за пять минут.
Что Вы будете делать, когда автору плагина надоест его поддерживать, а вы знать не знаете о той ерунде которую он делал? Уже не раз столкнулся с такой ерундой на Eclipse, когда программист решил не переписывать плагин под новую версию среды.
Смотря с чем сравнивать. Первая сборка идёт дольше, но потом пересобираются только изменённые файлы, а это один - два. Если учесть, что большую часть времени тупишь над котодом или смотришь результат в режиме отладки, то если время полной сборки будет пятнадцать секунд, а не десять - я переживу.
Я тоже выкидываю из Кубовского проекта всё безбожно, меня от него интересуют только свежие библиотеки и начальная инициализация тактировки, HAL выпиливаю начисто.
Нет, просто теперь ещё меньше денег останется на реальное развитие медицины, науки, техники и пр. Всё больше будет отписок и приписок.
Сам по себе VSCode почти ничего не умеет, но настроить его на программирование Arduino - несложная задача.
По факту там avr-gcc, из особенностей, только свой дополнительный набор библиотек. Makefile, похоже, генерится автоматом, но это не точно. Всё это, при минимальном желании, можно подключить и писать программы хоть vi, хоть в sublime, хоть ещё в чём.
Так в приведённой Вами цитате и есть ответ. Содержимое Makefil'а генерировалось плагином и что там будет зависело, видимо, от левой пятки автора плагина.
Мне надоели эти "радости" - когда автор плагина спрятал от меня довольно простые вещи, типа автоматизировав рутинную работу, при этом наворотив там там невесть чего, а потом перестал поддерживать свой проект. Проще один раз разобраться в базовых вещах и сделать всё самому. При таком подходе, даже вернувшись к проекту через десять лет, даже если IDE перестала существовать, Вы можете всё подправить буквально в блокноте.
Может у Вас что-то с программатором? Сегодня специально подключил atxmega32a4 по pdi к дракону, нормально читается, шьётся, в отладку заходит. Всё программами из репозитория Debian, ни каких самостоятельных сборок. Вообще с этой серией никогда не работал, камень случайно попал в руки.
Не могу на нём включить внутренний генератор 32МГц, всё застряёт на ожидании флага запуска генератора.
В том-то и дело, при таком подходе минимум движений при переезде с компа на комп. Если у Вас пути к программам находятся в PATH, то вообще ничего менять не нужно, даже между Win и Linux, а я так и работаю. В своей первой стать, в комментариях, я писал, что перемещаюсь между рабочей Win7, домашним Debian и PaspberryPi4. Синхронизация проекта идёт через git-репозиторий, доступный со всех трёх машин. Никаких изменений вносить не приходится.
К тому же, это поначалу кажется всё сложно и непонятно, но после пары проектов, понимаешь, что всё нормально. К тому же это не самый сложный Makefile, бывает как понаворотят... А .c и .h вам всё равно писать, если программируете не всё в одном файле.
Адекватный ответ будет в виде — их проще детектировать и по таким маркерам проще определять размер всего штрихкода.
Я так думаю.
Не так давно попадалась объёмная статья по штрихкодам, но найти нё быстро не получается и лень, а по памяти я точно не помню.
А эти НИКТО в курсе? По-моему нет, и вполне используем.А ещё можете посмотреть на структурки многих широко используемых микросхем, там биполярников хватает и как раз в описанных применениях. Если можно в микросхемах, почему нельзя в дискретке?
Давайте честно, для большинства неответственных или не очень ответственных изделий этого вполне хватит.
По Вашему, сколько в Москве должен получать молодой специалист со знаниями
на уровне этой статьи?
Подросший ток прикроет транзистор, за счёт падения на эмиттером резисторе - ток уменьшится. Это при условии постоянного напряжения на базе.
ШИМ не даст такого чистого выхода как ЦАП, как ни старайся. Бывают ситуации когда это критично. Поэтому комплект ЦАП + Биполярник ещё долго будет актуален. По сути была схема 3 статьи с последовательным резистором в базе.
А вообще статья хорошая, для начинающих. Если бы молодые инженеры, последние курсы ВУЗов и выпускники, обладали хотя бы такими знаниями и представлениями - с ними можно было бы работать и давать какую-то работу. Надеюсь, что только мне везёт на таких "специалистов" и в других местах всё лучше.
Сильно! Жена оценила мотивацию?
Может существенное отличие в скоростях, высотах, размерах и прочих мелочах, а ещё во времени на операцию. Если текущая цель - четыре беспилотника за пол-часа, то круто.
Спектрум не умрёт никогда!!!
Лично у меня не на столько много лишнего времени, что бы поддерживать форк чужой программы. Особенно, если учесть, что она мне не нужна.
И сейчас достаточно работы
Вы же не будете выпускать свой хлеб, только потому что ваша любимая пекарня решила закрыться
Не знаю как IAR, а вот с Keil'а пытаемся слезть на описанную в статье связку. Сейчас занимаемся корректировкой рабочего проекта.
Не спорю, но зачем мне ещё один плагин, если я всё это могу и сам сделать за пять минут.
Что Вы будете делать, когда автору плагина надоест его поддерживать, а вы знать не знаете о той ерунде которую он делал? Уже не раз столкнулся с такой ерундой на Eclipse, когда программист решил не переписывать плагин под новую версию среды.
Смотря с чем сравнивать. Первая сборка идёт дольше, но потом пересобираются только изменённые файлы, а это один - два. Если учесть, что большую часть времени тупишь над котодом или смотришь результат в режиме отладки, то если время полной сборки будет пятнадцать секунд, а не десять - я переживу.
Всё остальное работает как и на большой машине.
Если посмотрите Makefile, то там подключаются только те файлы исходников, которые используются, а дальше всё на совести gcc.
Я тоже выкидываю из Кубовского проекта всё безбожно, меня от него интересуют только свежие библиотеки и начальная инициализация тактировки, HAL выпиливаю начисто.