Comments 169
2) Говорить о быстродействии вне контекста задачи — беседа с малым количеством смысла
Современная ОСРВ со всеми нужными сервисами и кучей сторонних. Приятный API на C++. Поддержка просто горы плат на Cortex-M* прямо из коробки, включая примерно все Nucleo. Порог входа не то что низкий — он нулевой, даже IDE ставить не надо: регистрируешься на сайте, открываешь онлайн-IDE, выбираешь плату и готовый пример. На том уровне, на котором пишут поделки для ардуины там, по-моему, вообще ничего знать не надо, всё уже есть и работает. Ну да, в пользовательских библиотеках там адок, но в ардуине он ещё хуже.
Я в общем студентам (из 45 человек где-то 3-4 имели опыт работы с STM32 без RTOS, остальные в лучшем случае однажды щупали ардуину) показывал, как с RIOT OS между первой встречей и мигающим светодиодом лежит по сути только установка тулчейна, но блин, в Mbed даже этого не надо.
Вот нахрена, нахрена нужна эта ардуина, ребята, опомнитесь, 2018 год скоро кончится уже?
Чтобы накачать из инета готовых примеров и библиотек по форумам и, сильно не рефлексируя, собрать на них умную лампочку в сортир?
Ну и у ARM-овских микроконтроллеров (как от STM, так и от Microchip), с которыми мне приходилось дело иметь — есть какие-то подводные камни. Типа начнешь SD-ADC в F373 юзать с DMA — отваливается I2C. И каждый errata вычитывать целыми днями — не очень продуктивно.
Не говоря уже о том, что когда ищешь какую-то готовую библиотеку под нужную фигню — постоянно сталкиваешься с тем, что или вообще нет, или написана под другой тулкит (или без него, напрямую с регистрами) и переписывать нужно все вообще. С ардуинками проще во всех случаях. Даже если производительности/периферии не хватает — берешь тот же ATSAM и вперед…
Не всем и не всегда удобно делать разработки в онлайн-IDE.
Эээ… и какая конкретно религия запрещает вам в таком случае поставить IDE локально?
Типа начнешь SD-ADC в F373 юзать с DMA — отваливается I2C
Вы в данный момент просто беседуете с играющим в голове радио, или хотите сообщить, что на ардуине проблем с SD-ADC и DMA на F373 не испытываете?..
Ну, на большинстве ардуин вообще нет SD-ADC, так что даже соблазна не возникает, да. А для тех, у которых есть что-то более сложное (типа ATSAM) — есть готовые ардуиновские библиотеки обычно. Гарантии, конечно, нет никаких, что не нарвешься на очередной ARM-овский косяк, но как-то легче обычно, на форумах люди уже все обсудили… :)
Да, можно.
Кстати, форумы там тоже есть.
А количество пользователей (как и полезных советов) на их форумах — гораздо меньше ардуиновских.
Я боюсь, если мы начнём рассматривать качество советов на ардуиновских форумах, станет совсем смешно.
3D-принтеров базируется на Ардуино.
/* — Function addFN(char c)
Add char to FileName and move old chars
TODO: rewrite function with cycle
— */
void addFN(char c) {
fn[19] = fn[18];
fn[18] = fn[17];
fn[17] = fn[16];
fn[16] = fn[15];
fn[15] = fn[14];
fn[14] = fn[13];
fn[13] = fn[12];
fn[12] = fn[11];
fn[11] = fn[10];
fn[10] = fn[9];
fn[9] = fn[8];
fn[8] = fn[7];
fn[7] = fn[6];
fn[6] = fn[5];
fn[5] = fn[4];
fn[4] = fn[3];
fn[3] = fn[2];
fn[2] = fn[1];
fn[1] = fn[0];
fn[0] = c;
}
Я знаю хороших программистов, которые решают сложные задачи, но пишут код чуть ли не одним пальцем и очень долго. Вообще не имеет значения КАК решена задача, если она работает и делает это хорошо.
byte U = 0;
Тоже legacy или так и должно быть?!
Или например strings.ino:
void StrClear(char *str, char length) {
for (int i = 0; i < length; i++) {
str[i] = 0;
}
}
memset на Ардуино не подвезли?
Но есть ещё один важный момент — практика — критерий истины и этот «неправильный» код имеет подтверждённые аптаймы в месяцы беспроблемной работы.
Научитесь ли вы когда-либо в будущем — вопрос открытый. На данный момент — нет, не умеете.
В свете этого говорить с вами о программировании как-то немного бессмысленно.
У человека есть результат, это важно. То что он делает какие-то глупости, но в результате работает, то это не имеет значения. Если вы имеете шикарный, красивый, но бесполезный код, то грош вам цена.
n2 ^= f(n1+key[0]);
n1 ^= f(n2+key[1]);
n2 ^= f(n1+key[2]);
n1 ^= f(n2+key[3]);
n2 ^= f(n1+key[4]);
n1 ^= f(n2+key[5]);
n2 ^= f(n1+key[6]);
n1 ^= f(n2+key[7]);
n2 ^= f(n1+key[0]);
n1 ^= f(n2+key[1]);
n2 ^= f(n1+key[2]);
n1 ^= f(n2+key[3]);
n2 ^= f(n1+key[4]);
n1 ^= f(n2+key[5]);
n2 ^= f(n1+key[6]);
n1 ^= f(n2+key[7]);
А вас, что циклом for не учили пользоваться? И не говорите, что это нельзя было упихать в цикл. После этого наезжать подобным кодом на smart_alex просто не этично. Всё с вами ясно, профессор…
Ну, в смысле, называя моим кодом форк проекта codefix, в котором нет ни одного коммита от меня?
Сильно.
P.S. Упихать это в цикл можно, но в некоторых случаях не нужно, т.к. в развёрнутом виде у этого кода выше производительность — а в системах шифрования она часто является узким местом.
Вы сейчас хотите нам рассказать, что не знаете, как работает git вообще и GitHub в частности?
Не претендую на знатока git. И вообще не вижу зазорного чего-то не знать. Так же лично я не утверждал, что вселенский программист, и суперумный преподаватель тракторно-заборостроительного института. Вы ж эксперт и профессор, который позорится с каждым комментарием.
А касательно форка, то вы могли бы это и поправить. Раз вы критикуете чужой код.
Вы спрашивайте, не стесняйтесь.
Да нечего спрашивать. В данном случае просто выудил первое попавшееся. Я посмотрел другой ваш код, есть до чего докопаться. Но опускаться до вашего уровня я не собираюсь. Поскольку каждый имеет право писать код так как ему хочется. Да и я не святой программист.
Картинка из одного вашего же поста, который вас же и характеризует.
github.com/unwireddevices/RIOT/commits/loralan-public
О, так вы все-таки соизволили форкнуть ртос, авторов которого поливаете у себя в фб, а теперь выдаете их работу за образчик профессионализма команды Unwired Devices? Спасибо, хоть исходники не зажали, бэгэгэ
— Веб-сервера
— Сайтового движка
— 8-и сайтов, каждый со своим функционалом, дизайном и топологией
— С поддержкой честных интерактивных 3D-сцен
— Power Monitor-а на 14 каналов и сетевого осциллографа
— Поддержку nRF24 связи с датчиками и актуаторами
— Dash-панель работающей в реальном времени
— И прочими возможностями, список которых весьма велик
Подтверждённые аптайм этой системы составляет многие месяцы беспроблемной работы. Вы считаете, что это можно сделать не умея программировать?
Я в прошлый раз, помнится, в вашей программе за минуту нашёл идиотскую ошибку с выходом за пределы массива, а вы даже не поняли, что это такое.
из объективных проблем при применении всего этого можно выделить пихание куда не нужно и попытки написания разного рода костылей для исправления костылей самой ардуйни (железа или софта). одновременно с этим всегда присутствуют комментарии про то, что в кардиостимулятор эту платформу не засунуть, да и роутеры на 10гбит плоховатые получаются. зачем это упоминать? как может явно не тупой человек писать такие каракули, при этом освещая достаточно адекватные технологии на ютубе?
на практике получается, что любители/домохозяйки (или технари не связанные с железом/софтом) лепят поделки на ардуино, пишут свои велосипеды, выкладывают всё это в виде законченных проектов и это в итоге работает. просто потому, что для цветочной поливалки скорости атмеги хватает, хватит даже на корявый вебсервер. а потом приходит взрослый состоявшийся инженер (ниже даже есть некий преподаватель) и говорит что это говно, нужно на стм.
и да, прошивка для принтера это совсем не школьный уровень, вообще не школьный.
Или программирование тестов на C/C++?
В первую очередь, Ардуино это аппаратная платформа с низким порогом вхождения в мир микроконтроллеров, а не микроконтроллер.
Если идет сравнение эстээмщиков и ардуинщиков, то сравниваете уж дискаверщиков с ардуинщиками.
И нет ничего зазорного в использовании ардуины. Я и сам в некоторых проектах применяю ардуину, считая приемлемым вариантом для данных проектов.
Ардуино это аппаратная платформа с низким порогом вхождения в мир микроконтроллеров, а не микроконтроллер.
золотые слова!
Ардуино это аппаратная платформа с низким порогом вхождения в мир микроконтроллеров
А еще под нее можно на Scratch писать. :)
gcc-то как раз в ардуине есть. И notepad.exe ещё есть — но в приличных кругах этого уже четверть века как маловато.
>И notepad.exe ещё есть
notepad.exe — это вин-онли проприетарная поделка, как и большая часть тулчейна для stm, который я когда-то видел. А еще в нем нет подсветки.
это вин-онли проприетарная поделка, как и большая часть тулчейна для stm, который я когда-то видел
Я каждый раз при беседе с ардуинщиками убеждаюсь, что это просто несчастные люди, которые ничего слаще редьки в жизни не ели — и теперь пытаются всех (и себя в первую очередь) убедить, что нет ничего вкуснее.
Скажите, вы про существование arm-none-eabi-gcc и GNU Make в курсе?
Под stm завезли кросс-платформенный полностью открытый тулчейн? Искренне рад за стмщиков!
Да хоть Sublime с плагинами — он будет поустойчивее и чуть быстрее, чем VS Code на электроне.
Ваше разделение по приоритетам звучит обидно. Правильный подход, удобный стиль, хороший инструмент — залог успеха.
А ваши высокие умы могут бесконечно долго обсуждать концепты.
Это я к тому, что если очень хочется, то можно и IDE настроить, не вижу в этом ничего плохого, а если нет под рукой IDE, то и текстовый редактор + make + gcc в консольке — нормальный инструмент, ничем не хуже, местами лучше (спросите емаксера или вимера, что он думает о редакторе вижуалстудии или эклипса). Можно обсуждать их удобства и преимущества для разных ситуаций, но никак не повод кичиться, тем более сводить целую платформу с развесистой экосистемой к убогому текстовому редактору.
целую платформу с развесистой экосистемой к убогому текстовому редактору
Простите, а эта ваша целая платформа вообще из чего состоит?
1) простенький 8-битный микроконтроллер, давно вышедший из употребления у большинства профессиональных разработчиков
2) IDE, которую более-менее адекватно можно было воспринимать году эдак в 1995-м
3) гора библиотек и скетчей, написанных в основном любителями и, как правило, тривиальных и невысокого качества
Каким из этих компонентов надо восхищаться? Или я что-то забыл?
8-битный микроконтроллер
да пишите сразу 4-битный, чего уж там
Каким из этих компонентов надо восхищаться? Или я что-то забыл?
Она умеет запускать код, написанный на Си/С++, скомпилированный с gcc, для меня этого достаточно
Я что-то не так сказал про то, что AVR — 8-битный контроллер?
Давайте пост свой, и показывайте как надо, отдельно. А потом в комментариях ссылайтесь на него. Я так делал в своём посте «Как нельзя зарядить смартфон» — просто не стал спорить с человеком в комментариях и написал пост. А пока это всё пустозвонство.
Ардуино != Atmega.
Ардуино != Arduino IDE.
А что есть другая платформа, где есть аналогичное количество готовых библиотек и все они написаны исключительно профессионалами?
Которые написаны с расчётом на атмегу и сборку в Arduino IDE, что внезапно возвращает нас к первым двум пунктам.
2) В Mbed вам чего не хватает? При том, что присутствующее в Mbed и отсутствующее в Arduino можно перечислять примерно так до завтра?
2) нормально справляющаяся с тем говнокодом и с теми требованиями, которые соответствуют уровню применения ардуины
3) в большинстве случаев это достоинство.
при поливании поносом нужно быть аккуратным, т.к. после определённого момента аргументы заканчиваются и такие комменты в большей степени показывают ограниченность автора, нежели предмета обсуждения.
Я каждый раз в развёртнутой статье про ардуину не вижу ничего, кроме мучительного изобретания вещей, которыми всё остальное человечество давно уже просто пользуется.
смотреть нужно шире, не зацикливаясь на своих знаниях. не смотря на то, что лазерные принтеры продаются в любом магазине а струйники отгружают по цене пластмассы — квитанции всё равно шлют отпечатанными на матричном принтере.
Значительно проще в этом случае ардуину забыть как страшный сон.
А матричные принтеры используют по вполне конкретным экономическим соображениям, не знаю, чем вы тут меня хотели удивить — у них стоимость печати самая низкая и они легко конструируются под нестандартные форматы типа кассовой ленты.
а ардуину используют по вполне конкретным экономическим соображениям, не понимаю в чём тут может быть удивление и вопрос. в цивилизованной стране человек покупает ЭТУ ардуину и ТОТ датчик. совместно с ВОН ТЕМ блоком питания он за один вечер собирает хоббийную поделку. всё работает, клац-тык и завелось. строитель не будет вникать, почему стм32 за цену в два раза большую чем атмега8 имеет начинку в 13 раз лучше. какой смысл в 16 таймерах, если на их изучение нужно потратить месяц? месяц вечеров стоит три доллара разницы, или атмега не потянет замок с Bluetooth? просто экономика, ничего личного.
кстати про экономику. одно из направлений фриланса в данной области — перевод хоббийных проектов или проектов выполненных непрофессионалами на более высокий уровень. когда Джонни из Техаса хочет сделать ворота с кастомным управлением то он покупает все детальки по цене своего обеда и стряпает вечерами корявую поделку на бредборде. уверяю, что это всё получается и работает. затем он заходит на апворк и вполне себе определённый Андрюша или Игорь переводит его схему в «правильный» вид. то же самое (не всегда) с софтом для этой поделки. как итог — у Билли есть ЕГО проект, выполненный на хорошем уровне и по цене половины кроссовка. ему нет нужды платить тонны зелени за местного инженера (помним, что АндрюИгорь — просто рабы) и не нужно вникать в проблемы отладки CorteX-M под фрибсд с джитаг и эклипс. а местный специалист получает работу + в той или иной степени развитие. все довольны, всем выгодно, правила экономики во всей красе.
если на их изучение нужно потратить месяц?
Слушайте, может вы мне объясните, почему ардуинщики так железобетонно уверены, что весь остальный мир до сих пор Hello world на регистрах ассемблером пишет, а HAL только у них изобрели?..
получается что есть некая статья и в ней Петя, мидл программист на джаве, рассказывает как он наговнокодил свой проект. вытяжка работает, жалюзи открываются и всё замечательно. при этом железо убогое, код индусен полностью и выглядит всё как упавший на материнскую плату друшлаг макарон.
затем вкатываются тру эмбеддеры и рассказывают что проще на стм, там шима больше, стоит на доллар дешевле и вообще модно сейчас.
смотрелось бы нормально, если бы это был срач в сельском клубе, а тут получается что образованный, состоявшийся инженер (элита населения по сути) порет какую-то чушь, которая к теме статьи отношения не имеет. очень дико смотрится.
Поправочка — STM32F030F4P6 стоит этак в полтора-два раза дешевле AtMega8.
Выдергивать разработчика из комфортной среды — так себе аргумент, т.к. речь не о их способностях, а о вас и вашего нехотеня использовать удобный инструмент. Это очень странно.
Например, я в поисках хорошего и удобного перепробовал много IDE и текстовых редакторов. Тем не менее, если вы заберете у меня все красявости и оставите перед голой консолькой, то я себя прекрасно буду чувствовать и в vim. Но предпочтения отдам, естественно, удобному IDE.
P.S. Я не ардуинщик, пишу на чистых плюсах. Просто стало обидно за принижение качеств любимого инструмента. И да, кроме GCC знаком с более современным Clang/LLVM, не отрицаю — тоже потрясающая вещь.
То есть вот лет десять тому назад ещё.
И Arduino IDE оно по удобство радикально так обходило, на голову. И кнопочек разных было много.
P.S. Во!
Считаю, что правильные тесты должны тестировать и прошивку и железо, с ней связанное. А поэтому должны исполняться на внешней, по отношению к проверяемой плате, системе.
В железе, не обременённом таким наследием, смысла в атмеге чаще всего очень мало. Тем более, доллар — это уже вполне себе далеко не самый тощий Cortex-M0+, а для 8-битного процессора и вовсе как-то дофига.
Кроме того, проясните вопрос про серии: вот мне Aspencore в исследовании 2017 года по рынку встраиваемой электроники сообщает, что 8-битные процессоры используются в 12 % текущих проектов, а вы — что они выпускаются большими сериями. Мне кому верить?
Массово, дёшево.
Пока там ардуинщик ещё разберётся, почему у него влажность прочитать не получается…
P.S. Датчики физических величин не стоит лишний раз перепаивать, им от этого плохеет.
Или учебность и одноразовость определяются формой печатной платы?
Потому как «плата с чипом, под который есть среда» — это и NRF52-DK с Mbed, и SmartRF06 с TI RTOS, и многое другое. И от ардуины они качественно отличаются.
и многим этого более чем достаточно.
некоторые через это приходят (начинают) в более взрослый мир. а остальным не нужно ни ардуины, ни nrf…
есть ли реальный опыт применения такого подхода и примеры, где это было реализовано и использовано? примеры для наглядности приведены неправильные и плохие, т.к. не учитывать размерность переменных при работе с контроллерами и одновременно писать крутой код, покрывать его тестами — нельзя. физически нельзя, такого в мире не бывает. а если это встретится то речь идёт про аутиста и это не лечится.
пример с двигателем плох в том, что при «статической» работе, когда контроллер просто крутит двигатель — именно отладчик (или симулятор) быстро показывают где затык. также частая возможная проблема — если используются несколько прерываний и в одном из них, например, используется математика, то прерывания с более высокими приоритетами могут нарушать работу в плане нехватки времени (должно было посчитаться внутри прерывания, не успело). такое тоже отлавливается отладчиком + осциллограф, комплексный подход для живого железа.
могут ли описанные тесты подойти для ситуации когда часть условий (внешние сигналы) влияют на ход выполнения кода и не могут быть имитированы тупым «элементарным ручным вызовом обработчика»?
есть ли реальный опыт применения такого подхода и примеры, где это было реализовано и использовано?
не претендуя на «реальность», есть более развернутый пример:
github.com/sadr0b0t/stepper_h/blob/master/stepper_test/stepper_test.cpp
это моя библиотечка для управления шаговыми моторами, основанная на подсчете шагов и отправке импульсов фоном из прерывания таймера. В общем, примерно то, что описано в примере, только для нескольких моторов и с более ветвистой логикой. Собственно, эти тесты я начал применять и обкатал подход именно в ней, т.к. в один момент там внутри начали происходить странные вещи, которые без потактового разбора за пределами железки было крайне сложно, если вообще возможно, отловить. Добавление тестов помогло отловить и исправить многие проблемы уровня «недосчитались шага на последнем такте, если время шага некратно частоте импульса таймера».
могут ли описанные тесты подойти для ситуации когда часть условий (внешние сигналы) влияют на ход выполнения кода и не могут быть имитированы тупым «элементарным ручным вызовом обработчика»?
появление внешних сигналов можно легко имитировать при помощи мокапов, ситуацию можно разложить на что-то вроде: вот пришел внешний сигнал (записали состояние в мокап), вот выполнили тестируемый участок кода (он внутри проверяет состояние сигнала), вот он дал такой результат; вот пришел другой сигнал, вот опять выполнили этот участок, вот он дал другой результат и т.п. Если речь о том, что от сигнала идет прерывание и он там меняет какие-то переменные, которые используются внутри тестируемого участка, в любой произвольный момент, то не знаю, наверное это тоже можно как-то протестировать, если разложить тестируемый кусок на более мелкие запчасти и проверить поведение в каждом из возможных промежутков. В общем, идея — свести ситуацию к множеству последовательных событий (и их разных комбинаций) в одном потоке, тогда в каждой контрольной точке можно делать предсказуемые проверки. Если прям нужно много потоков, не знаю, возможно и есть такие техники для модульных тестов, я не в курсе.
Да, для каждого используемого вызова API Ардуино мы добавляем в проект собственную заглушку:
Для того, чтобы посмотреть, загорится ли светодиод, без реальной платы — есть же для симуляции, Протеус, и не надо колхозить с заглушками.
В покрытом тестами проекте может быть сложно проводить глобальную реорганизацию кода (рефакторинг)
Это неверное утверждение, т.к. юнит-тесты во многом как раз и служат для того, чтобы безболезненно проводить рефакторинг или другие изменения кода.
Что касается «писать модули так, чтобы можно было их использовать и в тестах, и в прошивке» — это решается выбором необходимого уровня абстракции. В C++ это, имхо, вообще не проблема (правда, я не уверен на 100%, что в ардуино-проектах можно использовать такие вещи, как виртуальные функции и интерфейсы)
(правда, я не уверен на 100%, что в ардуино-проектах можно использовать такие вещи, как виртуальные функции и интерфейсы)Я просто оставлю это здесь.
Не столько вам, сколько всем остальным.
Кстати, слово "мокап" тут неверно употребляется. Вероятно, имеется в виду "мок". Мокап — это графический макет (например, для GUI)
www.multitran.ru/c/m.exe?CL=1&s=mockup
www.multitran.ru/c/m.exe?l1=1&l2=2&s=mock
Разный результат на разных чипах, что не удивительно.
Интересная статья, но остаётся ощущение некоторой костыльности. Для своих проектов на AVR8 и STM32 используем систему сборки Ceedling с тестовым фреймворком Unity и библиотекой генерации моков CMock. Ну и используем достаточный уровень абстракции на C, чтобы код был по большей части платформонезависимым и переносимым между указанными платформами. Плюс некоторая дисциплина написания кода и понимание стандарта C. Та же работа с GPIO может быть описана как драйвер, у которого есть несколько вариантов работы в зависимости от таргета. А пользовательский код уже вызывает функции этого драйвера, что уже тестируется путем создания моков на указанные функции. Для чувствительных библиотек, которым вот прям надо работать с железом как можно теснее, им можно скармливать коллбэки на необходимые функции. В итоге ситуация, когда требуется лезть в GDB и смотреть, что же такое не работает, возникает очень редко.
Удобно: смотришь datasheet, errata, конструируешь архитектуру, пишешь тесты, пишешь код, пишешь приемочные тесты (для автоматического прогона на железе основных функций) — и все работает сразу.
Тесты конечно писать приходится, здесь спору нет, но это тесты действительно сложных вещей типа файловых систем, как например, вот эти
А функции работающие в жестком реальном времени проверять и надо в жестком реальном времени. Для этого у микроконтроллеров на ARM Cortex-M (Arduino делают и на них) есть механизм трассировки.
Проблему отладки управления шаговым двигателем он бы решил за пару минут.
Трассировочные вставки там тоже пришлось бы писать, но они во-первых очень короткие и могли бы остаться даже в релизном коде, во-вторых их можно написать не менее чем в 10 раз быстрее чем любые модульные тесты, и переделывать архитектуру кода этот подход не требует.
AVR 16 бит? Вы уверены?
Интеграционные тесты абсолютно необходимы если мы имеем дело с двигателями. Прежде всего для отлова проблем со сбоями и ошибками вызванными помехами или ошибками планирования ресурсов времени. Что автор старательно и выполняет, причем достаточно неэффективно, поскольку для таких тестов можно было бы и пользовательский интерфейс разработать на целевой платформе и инструментальные утилиты на PC.
Модульные тесты для проектов Ардуино