Комментарии 147
ST Nucleo-L152Почему выбрана именно эта плата? Она не самая доступная в России и не самая дешевая. Что в ней есть такого, за что стоит отдавать полторы тысячи, заморачиваясь с доставкой, но нет в более доступных и дешевых платах?
НЛО прилетело и опубликовало эту надпись здесь
Значит я не умею гуглить отладочные платы :) А в статье ссылок не было.
НЛО прилетело и опубликовало эту надпись здесь
В следующей статье будет подробнее про то, что за платы, что за ОС (RIOT с нашими доработками), что за среда (arm-none-eabi) и т.п. — мы это будем проговаривать студентам, т.к. не все из ходящих на лекции будут ходить и на практику в лабораторию IoT Академии.
А так полное название — Nucleo-L152RE, www.chipdip.ru/product/nucleo-l152re
Выбор именно STM32L152, а не STM32F103, например, потому что L1 — следующая по распространённости после F1 серия, и ввиду её относительной новизны, там есть фишки, которые в F1 реализованы сильно иначе или вообще не реализованы. Ну, например, у нас в ОС есть штатные субсекундные таймеры на RTC, они работают на регистре RTC_SSR, который даже в L151 в ранних моделях ещё отсутствовал (L151CB — нет, L151CC и L151CB-A — уже есть).
Мы вряд ли успеем на курсе рассказать детали всего этого внутреннего хозяйства, но прелесть ОС в том, что использовать его это ничуть не мешает (и в теме про энергосбережение таймеры на RTC мы использовать будем на полную катушку).
А так полное название — Nucleo-L152RE, www.chipdip.ru/product/nucleo-l152re
Выбор именно STM32L152, а не STM32F103, например, потому что L1 — следующая по распространённости после F1 серия, и ввиду её относительной новизны, там есть фишки, которые в F1 реализованы сильно иначе или вообще не реализованы. Ну, например, у нас в ОС есть штатные субсекундные таймеры на RTC, они работают на регистре RTC_SSR, который даже в L151 в ранних моделях ещё отсутствовал (L151CB — нет, L151CC и L151CB-A — уже есть).
Мы вряд ли успеем на курсе рассказать детали всего этого внутреннего хозяйства, но прелесть ОС в том, что использовать его это ничуть не мешает (и в теме про энергосбережение таймеры на RTC мы использовать будем на полную катушку).
Полторы тысячи — абсолютно адекватная (и в общем даже весьма скромная) цена за фирменную отладку с полноценным набортным программатором, к тому же доступную в куче магазинов.
Это очень дешево. Современные отладки для верхней линии NRF 4-6к стоят.
Ну, наука знает много гитик. Мне, например, нравится поведение TI, которые на новых чипах сначала делают EMK-модуль по $49 (фактически голая плата с чипом), втыкающийся в «профессиональную отладку» за $99 и продающийся исключительно комплектом из двух отладок и двух EMK, итого $299.
А через год на том же чипе выпускают Launchpad за $29, которого 10 разработчикам из 10 хватает по уши.
Сам чип при этом всё это время стоит $5 в розницу с НДС.
А через год на том же чипе выпускают Launchpad за $29, которого 10 разработчикам из 10 хватает по уши.
Сам чип при этом всё это время стоит $5 в розницу с НДС.
Тут я честно признаюсь, что c камнями от TI кроме универа так и не работал больше. Впрочем, я полностью согласен, что многим бизнес-моделям есть право на существование. Кто-то продает принтеры, кто-то чернила. Просто хотел отметить, что если рассматривать весь диапазон цен, то озвученные 20-30 баксов попадают в нижнюю треть.
Мне нравится, что она Arduino-совместимая по форм-фактору. Кто бы что ни говорил.
НЛО прилетело и опубликовало эту надпись здесь
Собственно, что плохого в Ардуино, HAL, cube и китайских модулях, которые имея то же самое железо на борту в половину дешевле?
Ничего, кроме того, что это уровень любительских поделок, а не серьёзной разработки.
НЛО прилетело и опубликовало эту надпись здесь
Ардуино занимает свою нишу примитивной автоматизации, hal даёт слой абстракции при работе с железом, Cube ровным счётом ни к чему не обязывает, позволяя экономит время, а платы собранные на китайских линиях не уступают качеством, при более низкой стоимости.
Инженерны инженерами, идиоты идиотами; перечисленные вещи не являются чем-то постыдным.
Госдеп вообще ни к месту.
Инженерны инженерами, идиоты идиотами; перечисленные вещи не являются чем-то постыдным.
Госдеп вообще ни к месту.
Они являются чем-то бессмысленным.
Обладая прекрасным 10-летним опытом работы с ардуиной, кубом и китайскими платами, большую часть решаемых у нас задач по разработке вы не то что не сможете решить — вы не сможете понять, с какой стороны вообще к ним подступаться.
Всё, что вы сможете сделать, обладая этим опытом — это штамповать типовые копеечные поделки.
P.S. Про платы, собранные на китайских линиях, тут недавно уже была история — как у людей из-за смены чипа SPI-флэшки бизнес встал, потому что никто не мог понять, что с новым чипом делать, кроме как брать фен и менять на старый на всей партии.
Обладая прекрасным 10-летним опытом работы с ардуиной, кубом и китайскими платами, большую часть решаемых у нас задач по разработке вы не то что не сможете решить — вы не сможете понять, с какой стороны вообще к ним подступаться.
Всё, что вы сможете сделать, обладая этим опытом — это штамповать типовые копеечные поделки.
P.S. Про платы, собранные на китайских линиях, тут недавно уже была история — как у людей из-за смены чипа SPI-флэшки бизнес встал, потому что никто не мог понять, что с новым чипом делать, кроме как брать фен и менять на старый на всей партии.
Вы знаете, с наскока stm32 не осилить. С hal ещё как то можно было, имея под рукой лишь интернет и собственные домыслы.
Полагаю, Ваши материалы именно то, чего не хватало правильного понимания платформы. Спасибо.
Полагаю, Ваши материалы именно то, чего не хватало правильного понимания платформы. Спасибо.
С наскока вообще ничего не осилить.
Вот у вас в схеме стоит банальное электромагнитное реле, куда уж проще, да? А теперь — список типовых ошибок, которые я видел в релейных схемах, спроектированных любителями:
* использование биполярных драйверов ULN2003A при неучёте зависимости напряжения срабатывания реле от температуры, в результате чего температурный диапазон устройства оказывается в районе -20...+30 °С
* неучёт разных рейтингов реле по напряжению и току на постоянном и переменном токе
* использование шунтирующего диода вместо TVS на обмотке реле при коммутации индуктивных нагрузок (жёсткое шунтирование обмотки сильно увеличивает время дребезга контактов при отпускании)
* неиспользование последовательных или параллельных симисторов для подавления дугообразования на контактах при коммутации индуктивных нагрузок
* и это уже не говоря про очень распространённое непонимание обеспечения правильной гальванической развязки схемы (зачем-то воткнутый оптрон между контроллером и реле и одновременно 0,5 мм между дорожками высоковольтной части и земляным полигоном низковольтной — вообще типичная картина)
Комбинируем пару пунктов из списка — и легко получаем такое простое и понятное релейное устройство, в котором контакты гарантированно умирают за год, а если в жарком климате, то за пару месяцев.
А это всего лишь обычное электромагнитное реле.
Вот у вас в схеме стоит банальное электромагнитное реле, куда уж проще, да? А теперь — список типовых ошибок, которые я видел в релейных схемах, спроектированных любителями:
* использование биполярных драйверов ULN2003A при неучёте зависимости напряжения срабатывания реле от температуры, в результате чего температурный диапазон устройства оказывается в районе -20...+30 °С
* неучёт разных рейтингов реле по напряжению и току на постоянном и переменном токе
* использование шунтирующего диода вместо TVS на обмотке реле при коммутации индуктивных нагрузок (жёсткое шунтирование обмотки сильно увеличивает время дребезга контактов при отпускании)
* неиспользование последовательных или параллельных симисторов для подавления дугообразования на контактах при коммутации индуктивных нагрузок
* и это уже не говоря про очень распространённое непонимание обеспечения правильной гальванической развязки схемы (зачем-то воткнутый оптрон между контроллером и реле и одновременно 0,5 мм между дорожками высоковольтной части и земляным полигоном низковольтной — вообще типичная картина)
Комбинируем пару пунктов из списка — и легко получаем такое простое и понятное релейное устройство, в котором контакты гарантированно умирают за год, а если в жарком климате, то за пару месяцев.
А это всего лишь обычное электромагнитное реле.
Первый пункт про реле… не очень ясно как такое получается. Можете привести пруфы или расчеты?
Посмотрел пару тройку даташитов на реле и нигде не увидел зависимость срабатывания реле от температуры. К тому же причем тут ULN2003A?
Посмотрел пару тройку даташитов на реле и нигде не увидел зависимость срабатывания реле от температуры. К тому же причем тут ULN2003A?
Берём популярное реле серии RT1: https://static.chipdip.ru/lib/145/DOC000145160.pdf
Вторая страница, «Coil operating range DC». При +25 °С минимальное напряжение срабатывания под полной нагрузкой — 0,8 от паспортного, при +40 — уже ближе к 0,9. Для 5-вольтового реле это 4 и 4,5 В, соответственно.
Теперь берём ULN2003A: https://www.diodes.com/assets/Datasheets/ULN200xA.pdf
Страница 3, «Collector Emitter Saturation Voltage» — при нагрузке 100 мА это уже до 1,1 В.
Ну вот мы и получаем даже при идеальном питании +5,0 В всего лишь 3,9 В на катушке реле, чего тупо недостаточно для гарантированного срабатывания под нагрузкой и/или при повышенной температуре.
Выкидываем к чёрту ULN2003A, ставим вместо него MOSFET с практически нулевым падением напряжения сток-исток (IRLML2402 будет иметь падение меньше 35 мВ при управлении напрямую от 3,3-В микроконтроллера и токе 100 мА) — и наши волосы снова длинны и шелковисты.
Вторая страница, «Coil operating range DC». При +25 °С минимальное напряжение срабатывания под полной нагрузкой — 0,8 от паспортного, при +40 — уже ближе к 0,9. Для 5-вольтового реле это 4 и 4,5 В, соответственно.
Теперь берём ULN2003A: https://www.diodes.com/assets/Datasheets/ULN200xA.pdf
Страница 3, «Collector Emitter Saturation Voltage» — при нагрузке 100 мА это уже до 1,1 В.
Ну вот мы и получаем даже при идеальном питании +5,0 В всего лишь 3,9 В на катушке реле, чего тупо недостаточно для гарантированного срабатывания под нагрузкой и/или при повышенной температуре.
Выкидываем к чёрту ULN2003A, ставим вместо него MOSFET с практически нулевым падением напряжения сток-исток (IRLML2402 будет иметь падение меньше 35 мВ при управлении напрямую от 3,3-В микроконтроллера и токе 100 мА) — и наши волосы снова длинны и шелковисты.
Вы меня заинтриговали, Олег, по поводу напряжения срабатывания реле.
Ну не должно так быть, чтобы информацию о ключевом параметре, напряжении срабатывания, извлекали бы из графика.
Мне все таки кажется, что значение должно быть четко указано в таблице, в данном случае 3.5, а график может показать его уменьшение относительно номинального, что не есть существенно, иначе фигня какая то получается.
Ну не должно так быть, чтобы информацию о ключевом параметре, напряжении срабатывания, извлекали бы из графика.
Мне все таки кажется, что значение должно быть четко указано в таблице, в данном случае 3.5, а график может показать его уменьшение относительно номинального, что не есть существенно, иначе фигня какая то получается.
предположим что это так, тогда как интерпретировать верхнии линии на этом графике?
Откуда любителям про такое знать? Напишите хрошую статью про эти моменты, сделайте лучше всем)
Вы представляете себе количество таких моментов?
Ведь это мы только банальное электромагнитное реле потрогали.
Знание таких вещей нарабатывается только и исключительно через личную привычку внимательно читать документацию, а не лепить «MVP за пять минут» из китайских модулей.
Ведь это мы только банальное электромагнитное реле потрогали.
Знание таких вещей нарабатывается только и исключительно через личную привычку внимательно читать документацию, а не лепить «MVP за пять минут» из китайских модулей.
Смотрите какая интересная получается ситуация: на словах вы против этих ошибок, а набросать простую статью в которой были бы указаны такие моменты вы не хотите. Касательно вашего комментария выше, про 0,8 и 0,9 от номинального, кто-то делает реле с неноминальным срабатыванием? Я в целом поддерживаю вашу позицию про то, что надо изучать основы, а не брать да модуля, соединять проводами и на этом заканчивать, но проблема в том, что нет нормальной учебной базы и никто не хочет ее делать.
а набросать простую статью в которой были бы указаны такие моменты вы не хотите
Вы сейчас не понимаете, почему я не хочу бесплатно поработать и, потратив пару часов моего времени, написать статью для каких-то посторонних мне людей, излагающую в доступной им форме то, что они ленятся прочитать самостоятельно, потратив пару часов своего времени.
Должен признать, это не очень заманчивое предложение.
кто-то делает реле с неноминальным срабатыванием
Что такое «реле с неноминальным срабатыванием»? У реле есть номинальное напряжение обмотки и отклонения от него вверх и вниз, при которых оно ещё срабатывает.
Не хочу с вами спорить, просто тогда не нужно удивляться таким ошибкам у людей, они наберутся опыта и возможно их исправят. Касательно номинального напряжения срабатывания, все стараются делать с напряжение на обмотках как можно ближе к номинальном рабочему, у обычного транзистора падение меньше чем у сборки дарлингтона, поэтому мне непонятно его приведение в примере. Берём в пример bc557 docviewer.yandex.ru/view/145059403?*=28sA4Ek5PDDY2v5vbWHzku%2Bdvdd7InVybCI6Imh0dHBzOi8vbGliLmNoaXBkaXAucnUvNTAwL0RPQzAwMTUwMDc0NC5wZGYiLCJ0aXRsZSI6IkRPQzAwMTUwMDc0NC5wZGYiLCJ1aWQiOiIxNDUwNTk0MDMiLCJ5dSI6Ijc0Nzc4MjI4MTE1MTAzNDEwMjUiLCJub2lmcmFtZSI6dHJ1ZSwidHMiOjE1MjAxNjA1NzYxNzUsInNlcnBQYXJhbXMiOiJsYW5nPWVuJm5hbWU9RE9DMDAxNTAwNzQ0LnBkZiZ0bT0xNTIwMTYwNTU4JnRsZD1ydSZ0ZXh0PWJjNTU3JnVybD1odHRwcyUzQSUyRiUyRmxpYi5jaGlwZGlwLnJ1JTJGNTAwJTJGRE9DMDAxNTAwNzQ0LnBkZiZscj0zOSZtaW1lPXBkZiZsMTBuPXJ1JnNpZ249MTdiNjA1YTEwYmE1N2FkMzVkYjdiOTA1OGNjYTM0NTMma2V5bm89MCJ9&page=2&lang=en и типовое падение 0,25В максимум 0,65В.
росто тогда не нужно удивляться таким ошибкам у людей
Я не удивляюсь, я констатирую факт. И большинство из этих людей никогда не наберётся опыта, ибо уже счастливы с ардуиной и китайскими модулями (происхождение модулей заодно позволяет легко объяснить, кто виноват, если оно таки сдохло).
поэтому мне непонятно его приведение в примере
https://www.google.ru/search?q=ULN2003A+relay
Вплоть до википедии, сообщающей нам «Typical usage of the ULN2003A is in driver circuits for relays, lamp and LED displays, stepper motors, logic buffers and line drivers».
Его, конечно, можно применять для управления реле. Но есть один нюанс.
ну если иметь только его на руках, то да, если искать так www.google.ru/search?newwindow=1&ei=DdWbWtbaOMmysQHtnojIBw&q=relay+circuit+tutorial&oq=relay+tutorial+circuit&gs_l=psy-ab.1.0.0i22i30k1l2.8898.17911.0.22978.12.11.1.0.0.0.248.2212.0j6j5.11.0....0...1.1.64.psy-ab..0.11.2135...0i19k1j0i22i30i19k1j33i160k1.0.B4xpoTH5jzA, то везде просто транзисторы. Я понял вашу точку зрения, отчасти я с ней согласен, но чтобы чему-то научиться нужны знания и опыт, а ими никто не хочет делиться.
Везде транзисторы, потому что для щёлкания одним реле семиканальный драйвер не очень нужен. Как только реле становится полдюжины — тут же вылезает этот ULN, в т.ч. в китайских модулях, в т.ч. в 5-вольтовых.
И знания о таких вещах приобретаются не из опыта — никто не сидит с термошкафом, регулируемым источником, мультиметром, осциллографом и ящиком реле, чтобы изучить их характеристики при разных температурах.
Это всё давно описано и разжёвано в даташитах и аппнотах, которые надо читать — вместо того, чтобы бездумно лепить первую попавшуюся в интернете схему без малейшего понимания, как и почему она работает. Позиция «расскажите мне об этом так, чтобы я не напрягался» — это чистой воды let me google it for you.
И знания о таких вещах приобретаются не из опыта — никто не сидит с термошкафом, регулируемым источником, мультиметром, осциллографом и ящиком реле, чтобы изучить их характеристики при разных температурах.
Это всё давно описано и разжёвано в даташитах и аппнотах, которые надо читать — вместо того, чтобы бездумно лепить первую попавшуюся в интернете схему без малейшего понимания, как и почему она работает. Позиция «расскажите мне об этом так, чтобы я не напрягался» — это чистой воды let me google it for you.
Лично мне в первую очередь приходит на ум Сдвиговый регистр и жменя транзисторов, а не такой вот модуль. Есть различные категории людей, не все все знают, это нормально. Почему-то у программистов с этим гораздо проще чем у электронщиков ( и алгоритм расскажут и пример реализации скинут). Конечно никто никому ничего не обязан, но таким подходом вы повышаете порог вхождения и толкает людей со стороны к тем же модулям ардуино которые вы не любите. И зачастую чтобы знать что искать тоже нужны какие-то начальные знания
Конечно никто никому ничего не обязан, но таким подходом вы повышаете порог вхождения и толкает людей со стороны к тем же модулям ардуино которые вы не любите
Вы сейчас продолжаете убеждать меня, что я должен вам денег.
Почему-то у программистов с этим гораздо проще чем у электронщиков
Понимающий ситуацию программист никогда не будет делиться уникальными знаниями просто так. Зачем плодить себе потенциальных конкурентов.
Что-бы преодолеть порог, нужны вложения — либо своё время и усилия, либо наемный «репетитор». Никто не обязан повышать профессиональный уровень окружающих бесплатно.
Мне кажется все развитие мира open source с вами не согласно.
Вы мало знакомы с миром open source — большая его часть коммерческая, практически все крупные проекты явно или неявно поддерживаются различными компаниями (явно — это просто деньгами на проект, неявно — сотрудниками в штате, в обязанности которых входит работа с этим проектом).
В проектах, где коммерческой основы нет, вы с большой вероятностью быстро столкнётесь с мейнтейнером, который тут и.о. царя и бога, а также «я так вижу». Ничего особенно приятного, по сути люди чешут собственное эго.
В результате, если вы хотите использовать в работе опенсорс — вы, в зависимости от величины того опенсорса, либо сажаете людей на окладе на взаимодействие с мейнтейнерами и контрибуцию, либо делаете свой форк.
Собственно, тот же RIOT, который мы используем и в учебном курсе, и в изделиях, у нас живёт в виде нашего форка, который контрибьютиться в mainline не будет. Просто потому, что после пары дискуссий с мейнтейнерами, в которых два человека в двух ветках совершенно спокойно утверждали противоположные вещи, и сходились только в тезисе «мы так решили уже давно, не нравится — читайте Code of Conduct до просветления, а не спорьте тут», я решил, что процесс не окупает затрачиваемых усилий.
В проектах, где коммерческой основы нет, вы с большой вероятностью быстро столкнётесь с мейнтейнером, который тут и.о. царя и бога, а также «я так вижу». Ничего особенно приятного, по сути люди чешут собственное эго.
В результате, если вы хотите использовать в работе опенсорс — вы, в зависимости от величины того опенсорса, либо сажаете людей на окладе на взаимодействие с мейнтейнерами и контрибуцию, либо делаете свой форк.
Собственно, тот же RIOT, который мы используем и в учебном курсе, и в изделиях, у нас живёт в виде нашего форка, который контрибьютиться в mainline не будет. Просто потому, что после пары дискуссий с мейнтейнерами, в которых два человека в двух ветках совершенно спокойно утверждали противоположные вещи, и сходились только в тезисе «мы так решили уже давно, не нравится — читайте Code of Conduct до просветления, а не спорьте тут», я решил, что процесс не окупает затрачиваемых усилий.
Обладая прекрасным 10-летним опытом работы с ардуиной, кубом и китайскими платами, большую часть решаемых у нас задач по разработке вы не то что не сможете решить — вы не сможете понять, с какой стороны вообще к ним подступаться.А можно примеров несколько навкидку? мне просто интересно без оценок и мнения в спорах (я не ардуинщик и вообще сложнее светодиодов лет 20 ничего не паял.)
* практически всё, что связано с режимами сна, входом и выходом из них, переключением частот процессора и периферии, сохранением состояния системы — в ардуинах и китайских модулях ничего этого нет (ну т.е. возможности-то у процессора есть, но ни нормальной программной реализации, ни способности готовых модулей поддерживать какой-то low power не наблюдается, и куб вам этого не нагенерирует)
* различные хитрые tips & tricks внутри процессора — например, программное определение объёма памяти и наличия периферии в конкретном чипе методом простукивания по адресам и ловли аппаратных исключений (Bus Fault / Hard Fault в Cortex-M) при попадании на невалидный адрес (реально используем в наших прошивках, например, чтобы обеспечить работу одного и того же бинарника на чипах с разным числом ножек и разным объёмом EEPROM)
* в железе — вообще вагон всего, чего вы никогда в жизни не встретите на китайских шилдах. Весь low power сразу записываем в terra incognita, например. У нас в одной из последних конструкций, например, штук пять разных DC/DC на одной плате, включая повышающий с полным отключением выхода (типовой повышающий DC/DC, даже имея вход Enable, выход отключать не умеет), один понижающий со специальным программно выключаемым сверхэкономичным режимом, второй понижающий с программным переключением выходного напряжения… У ардуинщика с его китайскими понижайками на LM25xx всё это просто будет включено всё время — и высадит аккумулятор за день вместо положенного по ТЗ месяца.
* хитрые схемы управления электромагнитными реле с шунтированием контактов симистором для подавления дугообразования — в результате чего реле с рейтингом 16 А на резистивной нагрузке может спокойно коммутировать 16 А индуктивной, и ему ничего не будет
* ну и собственно любое промышленное устройство подразумевает разводку индивидуальной платы и индивидуальный же подбор компонентов. Попросите любого ардуинщика сделать железку с LoRa и GPS, внешними интерфейсами USB и NFC, датчиком отпечатка пальца, OLED-экраном и встроенным аккумулятором с набортным контроллером зарядки — в формате, сравнимом с офисным пропуском на смарт-карте. Посмотрите на его глаза.
* различные хитрые tips & tricks внутри процессора — например, программное определение объёма памяти и наличия периферии в конкретном чипе методом простукивания по адресам и ловли аппаратных исключений (Bus Fault / Hard Fault в Cortex-M) при попадании на невалидный адрес (реально используем в наших прошивках, например, чтобы обеспечить работу одного и того же бинарника на чипах с разным числом ножек и разным объёмом EEPROM)
* в железе — вообще вагон всего, чего вы никогда в жизни не встретите на китайских шилдах. Весь low power сразу записываем в terra incognita, например. У нас в одной из последних конструкций, например, штук пять разных DC/DC на одной плате, включая повышающий с полным отключением выхода (типовой повышающий DC/DC, даже имея вход Enable, выход отключать не умеет), один понижающий со специальным программно выключаемым сверхэкономичным режимом, второй понижающий с программным переключением выходного напряжения… У ардуинщика с его китайскими понижайками на LM25xx всё это просто будет включено всё время — и высадит аккумулятор за день вместо положенного по ТЗ месяца.
* хитрые схемы управления электромагнитными реле с шунтированием контактов симистором для подавления дугообразования — в результате чего реле с рейтингом 16 А на резистивной нагрузке может спокойно коммутировать 16 А индуктивной, и ему ничего не будет
* ну и собственно любое промышленное устройство подразумевает разводку индивидуальной платы и индивидуальный же подбор компонентов. Попросите любого ардуинщика сделать железку с LoRa и GPS, внешними интерфейсами USB и NFC, датчиком отпечатка пальца, OLED-экраном и встроенным аккумулятором с набортным контроллером зарядки — в формате, сравнимом с офисным пропуском на смарт-карте. Посмотрите на его глаза.
Зачем вы сравниваете промышленные устройства со средой для домашних поделок? У каждого своя сфера применения. На платах ардуино стоят нормальные контроллеры, вполне себе применимые для многих задач. Для других задач есть другие платы, в том числе те, о которых пишете вы.
А зачем под каждым постом про разработку электроники появляются люди, сообщающие «с ардуиной нам тоже хорошо и даже лучше!»?
Интереса ради посмотрел с чего началась эта ветка обсуждений:
Отличная затея! Хоть кто-то пытается привить людям нормальный подход в разработке, а не очередных быдлокодеров наплодить, которые кое-как с Ардуины смогут переползти на HAL+Cube и начать лепить очередной «умный дом» на китайских модулях.
Вы перепутали причину и следствие, тут наоборот: в комментариях появился человек, начавший набрасывать на вентилятор в сторону тех, кто использует фреймворк Ардуино и hal, чьи решения в сравнении с представленным в статье просты, а в последствии вообще обозвал лохами.
НЛО прилетело и опубликовало эту надпись здесь
Где я сравниваю? Не надо наговаривать. Мне не понравилось лишь то, что вы о более простых вещах рассудаете свысока. Мол: вы лохи, а мы профи, стук себя пяткой в грудь. А когда ваш ребенок учился читать по слогам, Вы его тоже передергивали за отсутствие навыков? Потом пытались оскорбить меня за мою любительскую работу, хотя для меня это, как и для многих читателей гиктаймса электроника — интересный досуг, не связанный с академической специальностью профессией. Далее, полагаю, Вы пытаетесь намеками убедить меня, что фиксация на термоклей (коим приклеивают экраны смартфонов, не именно такой, но все же) каком то образом влияют на качество работы простенького реле времени? Быть может посоветуете эпоксидную смолу или заказ специально корпуса на фабрике?
НЛО прилетело и опубликовало эту надпись здесь
Читать даташтиты недостаточно для написания качественного кода на С, и Вы прекрасно это знаете. Не надо приуменьшать умение писать хороший код.
За конструктивную критику благодарю, сожалею, что Вы не отписались в той теме.
За конструктивную критику благодарю, сожалею, что Вы не отписались в той теме.
STM-ы вообще раскуриваются имея на руках только reference manual
Просто интересно, какой набор знаний вы предполагаете для того, чтобы просто раскурить рефер на стм (32, я так понял)?
вот да. Более того — на что в универе научили — чаще всего с этим первое время человек долго и живёт, собственно для этого универ и нужен — давать в экономику относительно готового специалиста. С софтом уже кажется это начали понимать, очень хорошо что в МИРЭА это понимают по железу, втройне здорово. что начали ещё и по актуальному в мире железу, а не 30-летней давности как было когда учился я (не мирэа, но не суть). Ну да, возможно самунг там дал бонусы и помог с организацией — так молодец, далеко вперёд смотреть умеет.
А арудуина — это тоже мега-прорыв своего рожа, но не надо их противопоставлять с промавтоматикой, это дополнительная ниша, ну как огороды и пром. с/х, гаражи и заводы и т.п.
А арудуина — это тоже мега-прорыв своего рожа, но не надо их противопоставлять с промавтоматикой, это дополнительная ниша, ну как огороды и пром. с/х, гаражи и заводы и т.п.
А не хотят там, на перспективу, поучить программировать контроллеры на Rust?
Rust — это красиво, но это чисто университетская игрушка на данный момент. В реальном мире в эмбеддеде C и C++ занимают… да практически 100 % и занимают, если отбросить жирный эмбеддед с линуксами внутри (если не отбрасывать, то около 80 %).
К тому же, под микроконтроллеры на Rust фактически нет ОСРВ (есть порт FreeRTOS и что-то ещё совсем маргинальное), а в самом языке любое неловкое движение (использование стандартных библиотек) увеличивает размер кода одним махом на десятки килобайт.
К тому же, под микроконтроллеры на Rust фактически нет ОСРВ (есть порт FreeRTOS и что-то ещё совсем маргинальное), а в самом языке любое неловкое движение (использование стандартных библиотек) увеличивает размер кода одним махом на десятки килобайт.
Современные студенты начнут работать года через 3-4. Сокращением размера исполняемого файла разработчики Rust уже озаботились, к выпуску эта проблема будет решена. Так что учить можно уже начинать.
НЛО прилетело и опубликовало эту надпись здесь
Rust обеспечивает практически те же гарантии по производительности и реактивности, что и C/C++, но при этом дает и гарантии надежности, сравнимые с языками типа ML, Haskell. Ради таких гарантий во встаревоемом ПО гнаться за такими технологиями надо. Говорю даже не как программист, а как пользователь, котоорому жить в мире, напичканом устройствами, которые запрограммируют сегодняшние студенты.
У него тулчейн пока не поддерживает embedded из коробки, в другой теме Halt и khim описали ситуацию — в этом году планируются подвижки в сторону встраиваемых платформ, будем посмотреть; плюс дело ещё упирается в поддержку со стороны LLVM.
Вообще, гарантии по памяти для очень маленьких встраиваемых платформ (как в статье) не самая большая головная боль. По хорошему, там вы вообще стремитесь не использовать динамическое выделение в куче — выделили при инициализации всё что надо и больше кучу не трогаете. Иначе потом каждый malloc()/new будет бомбой замедленного действия — кто знает в какой момент выделение обломится из-за фрагментации кучи. Понятно что Rust — это не только память, но всё же в ситуации, когда кучу вообще лишний раз трогать чревато, его привлекательность падает.
Вообще, гарантии по памяти для очень маленьких встраиваемых платформ (как в статье) не самая большая головная боль. По хорошему, там вы вообще стремитесь не использовать динамическое выделение в куче — выделили при инициализации всё что надо и больше кучу не трогаете. Иначе потом каждый malloc()/new будет бомбой замедленного действия — кто знает в какой момент выделение обломится из-за фрагментации кучи. Понятно что Rust — это не только память, но всё же в ситуации, когда кучу вообще лишний раз трогать чревато, его привлекательность падает.
В Rust пока достаточно жирная старндартная библиотека, которую сложно линковать по частям. Проблемы с памятью там не с памятью данных, а с размером кода, который, если не принимать специальные усилия, получается в несколько раз больше, чем на C.
LLVM поддерживает и ARM, и MIPS. А 8- и 16-разрядные платформы в этом курсе, как я понял, не рассматриваются.
LLVM поддерживает и ARM, и MIPS. А 8- и 16-разрядные платформы в этом курсе, как я понял, не рассматриваются.
Про поддержку — это я к тому, что там с ней неоднозначно, и из коробки тулчейн Rust как-то не дружелюбен к тому же STM32, надо на голове постоять и скачать разной степени допиленности куски, сделанные сообществом. Код уменьшают — это хорошо, конечно. Что до памяти, то я скорее имел в виду, что у Rust одна из фишек — это управление памятью. В embedded этот вопрос не так остро стоит, в том числе в мелких 32-разрядных машинках как L151.
К сожалению, на данный момент красивого, работоспособного и читаемого кода уже недостаточно, он должен быть еще и безопасным, а с этим все очень плохо и в С, и в С++. Преимущество Rust именно в том, что компилятор не даст выстрелить себе в ногу или голову, а все места, в которых стрелять все таки нужно заставит пометить как unsafe. Ясно, что если писать «на регистрах» и заниматься арифметикой указателей, то весь код будет пестрить этими unsafe и сильно лучше чем в С не будет, но уже на следующем уровне абстракции Rust становится заметно лучше языков с неявным владением, неявным и неконтролируемым временем жизни объектов, побочными эффектами в самых неожиданных местах, молчаливым приведением типов, мутабельностью по умолчанию, сырыми указателями, целочисленным переполнением и прочими особенностями С и его наследников, которые мы знаем и любим.
Я тот самый суровый нордический парень с бородой, пытающийся наладить безопасность прошивок того самого хипстеровского макбука и я вам откровенно заявляю: писать сколько нибудь безопасный код много, быстро и недорого на С невозможно, даже если обвешаться статическими анализаторами, АСАНами, УБСАНами и десятком других утилит, помогающими находить ошибки в на вид совершенно безошибочном коде.
Да, мы используем этот язык 30+ лет, да, по нему достаточно специалистов, да, его придется изучать и с ним придется работать, но я вас заклинаю: если можете, пожалуйста, не пишите на нем ничего, связанного с безопасностью, он для этого подходит примерно как ножи для жонглирования — есть люди, которые умудряются еще и штуку инжира кушать, жонглируя ими, но в основном все заканчивается очень плохо. История с уязвимостями всех без исключения ядер современных ОС, написанных на С-подобных языках — отличное тому подтверждение.
Я тот самый суровый нордический парень с бородой, пытающийся наладить безопасность прошивок того самого хипстеровского макбука и я вам откровенно заявляю: писать сколько нибудь безопасный код много, быстро и недорого на С невозможно, даже если обвешаться статическими анализаторами, АСАНами, УБСАНами и десятком других утилит, помогающими находить ошибки в на вид совершенно безошибочном коде.
Да, мы используем этот язык 30+ лет, да, по нему достаточно специалистов, да, его придется изучать и с ним придется работать, но я вас заклинаю: если можете, пожалуйста, не пишите на нем ничего, связанного с безопасностью, он для этого подходит примерно как ножи для жонглирования — есть люди, которые умудряются еще и штуку инжира кушать, жонглируя ими, но в основном все заканчивается очень плохо. История с уязвимостями всех без исключения ядер современных ОС, написанных на С-подобных языках — отличное тому подтверждение.
Я очень сильно сомневаюсь, что через 3-4 года ситуация с языками как-то заметно для невооружённого глаза изменится. Притащить же Rust сейчас — это и вовсе резко поднять входной порог, т.к. по нему банально сильно меньше доступного материала в онлайне.
При этом наша цель — дать студентам понимание того, как работать с типовым современным микроконтроллером. Человек, таким пониманием обладающий, при необходимости другие контроллеры (мир не заканчивается на STM32) и другие языки освоить сможет уже сам.
При этом наша цель — дать студентам понимание того, как работать с типовым современным микроконтроллером. Человек, таким пониманием обладающий, при необходимости другие контроллеры (мир не заканчивается на STM32) и другие языки освоить сможет уже сам.
В Rust продуманая система документирования, благодоря которой материалов для обучения хватает.
А ситуация не поменяется, если ее не менять. Будет как с Cobol, который тоже вечен.
А ситуация не поменяется, если ее не менять. Будет как с Cobol, который тоже вечен.
Материалы для обучения — это в наше время в значительной степени содержание StackOverflow, ибо любой разработчик быстро сталкивается с разными довольно нестандартными ситуациями, которые в руководствах общего назначения попросту не описаны никак вообще.
Так вот Rust там мало, и долго ещё будет мало.
Так вот Rust там мало, и долго ещё будет мало.
Судя по его популярности на StackOverflow количество материалов будет расти достаточно быстро. Да и «нестандартные ситуации» должны возникать не часто, так как они стараются минимизировать неопределенное поведение и обеспечить максимальные гарантии на уровне компилятора.
А что со средой разработки? Насколько она дружественная и кроссплатформенная? На Маке можно будет возиться с этой платой, или только Вин/Лин?
Вообще, хотелось бы побольше актуально информации о плате, несколько ссылок не помешало бы — для тех, кто не глубоко в этой теме.
Вообще, хотелось бы побольше актуально информации о плате, несколько ссылок не помешало бы — для тех, кто не глубоко в этой теме.
Будет в следующей статье, которая уже конспект лекции.
Среда сборки — GNU ARM Toolchain, developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads, работает под всеми основными ОС. Ничего другого требоваться не будет, код можно хоть в текстовом редакторе писать (всегда так делаю, кстати).
Среда сборки — GNU ARM Toolchain, developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads, работает под всеми основными ОС. Ничего другого требоваться не будет, код можно хоть в текстовом редакторе писать (всегда так делаю, кстати).
Это кстати объясняет ваше отношение к rust. IDE это зло? Может и платы разводить в pcad 4?
А как связаны отношения к IDE и к Rust?
Я сам Rust очень люблю, а IDE пользоваться так и не научился, до сих пор пишу в vim на Scala. Но, теоретически, к IDE отношусь хорошо, особенно после просмотра лекций про Idris и Types Driven Development (коллеги продемонстрировали, что приемы из лекции и в IDEA со Scala работают).
Я сам Rust очень люблю, а IDE пользоваться так и не научился, до сих пор пишу в vim на Scala. Но, теоретически, к IDE отношусь хорошо, особенно после просмотра лекций про Idris и Types Driven Development (коллеги продемонстрировали, что приемы из лекции и в IDEA со Scala работают).
IDE — это хорошо, а ещё лучше — возможность собрать проект без IDE. Я слишком много видел хороших проектов, которым была нужна то пять лет как умершая IDE, то коммерческий Keil, то ещё что-нибудь столь же интересное.
Не далее как пару недель назад восстанавливал исходники, написанные когда-то кем-то под какой-то давно мёртвый форк gcc.
Не далее как пару недель назад восстанавливал исходники, написанные когда-то кем-то под какой-то давно мёртвый форк gcc.
Просто для полноты картины — CLion не бесплатен, но хорош. С тем плюсом, что CMake — это его нативный формат проекта, не приходится что-то из чего-то постоянно генерировать, один и тот же проект можно открыть в CLion или собрать как есть на CI сервере.
Я думал про Microsoft Code (который как раз бесплатен), но решил, что в курсе и так мало времени — а привнесение любой IDE требует отдельного занятия по её освоению (либо надо уточнять, что студенты изучают в обычном курсе программирования, и по возможности подстраиваться под это; и тут может всплыть странное, например, если у них основной курс вокруг Visual Studio — то что, VisualGDB срочно всем закупать?).
При этом использование IDE не является чем-то уникальным для эмбеддеда, так что студенты программистских факультетов познакомятся с ними в любом случае, с нашим участием или без.
При этом использование IDE не является чем-то уникальным для эмбеддеда, так что студенты программистских факультетов познакомятся с ними в любом случае, с нашим участием или без.
Вряд ли там что-то очень сложное, может в лекцию включать и не стоит, а написать пару параграфов о сопряжении с ide, будет полезно.
Это я скорее не в контексте курсов (для студентов понятно что лучше бы поменьше возни с подготовкой рабочего места, и уж тем более тащить коммерческую IDE, учитывая что они, может, дома что-то захотят сделать), а просто как возможный вариант для рабочего использования. Выше в ветке просто всплыло про ситуацию «упс, наша IDE перестала существовать, конвертируем проект в следующий проприетарный формат».
Keil и IAR есть учебные версии бесплатные. Путь там плохие редакторы кода, но компиляторы, отладчики и симуляторы самые лучшие.
НЛО прилетело и опубликовало эту надпись здесь
Я посмотрел. То что вы предлагаете сделано на Eclipse (Java) и жутко тормозит, по сравнению с Keil. Эти IDE сейчас у TI, SiLabs и т.д. Редактор ничего нового не предлагает, та же подсветка синтаксиса, автодополнение, всплывающие фигульки. Всё это есть в Keil. Отладчики ваши с типовым скромным функционалом. Раз уж выбрали ARM, то Keil их родная среда. Я не вижу ничего лучше. Возможно вы какую-то версию из 20 века описываете.
НЛО прилетело и опубликовало эту надпись здесь
Онлайн курс бы.
Более того, институт будет вести видеозапись всех лекций и выборочную видеозапись практических занятий, в блоге IoT Академии Samsung будут появляться конспекты прошедших лекций, адаптированные под использование плат ST Nucleo-L152, доступных в продаже для всех желающих по цене 1200-1400 рублей, а в Github-репозитарии Unwired Devices появится используемые на занятиях код.
Плату заказал, где посмотреть записи лекций и код? Вроде бы уже достаточно времени прошло чтобы курс выложили?
Смотрите здесь: www.youtube.com/playlist?list=PLJEYfuHbcEIApuZR4L5tRiBCwTZCYeTNY
необходимость написать полстраницы кода только для того, чтобы микроконтроллер завёлся.Это все ерунда. Когда в универе были лабы по ЦОС на сигнальниках от AD, на первой лабе нам просто давали код инициализации. Потом уже все детальнее разбиралось. Порты AVR до электрической схемы раскапывались, но первую лабу можно тоже было сделать и сдать с довольно общими знаниями. Это нормальная практика.
- Беспроводные сети передачи данных. Работа с радиоканалом LoRa. Защита передаваемых данных от типовых атак.
Практика: передача сообщений между двумя микроконтроллерами с использованием готового драйвера LoRa-трансивера SX1276. Шифрование сообщений, защита от подделки сообщений, защита от атак повтором.
А можете поделиться драйвером? Я какое-то время поискал, не нашел и написал что-то свое, частично портировав драйвер с Arduino, выкинув с него говнокод, расширив путем вдумчивого курения даташита. Правда потом стало резко не до этого, не дописал до конца, так руки и не дошли
RadioHead
https://github.com/unwireddevices/RIOT/archive/v1.60.zip — тут в drivers/sx1276
Я даю ссылку на старый релиз, потому что в новых он совсем переплёлся с операционкой. Сам драйвер портирован из семтековского кода LoRaMac-Node с парой добавленных фич и исправленных ошибок.
Я даю ссылку на старый релиз, потому что в новых он совсем переплёлся с операционкой. Сам драйвер портирован из семтековского кода LoRaMac-Node с парой добавленных фич и исправленных ошибок.
Спасибо!
Посмотрел этот RIOT — довольно занятная штука (как я понимаю, вы ее используете и контрибьютите?). Может я чего-то про нее не понял, но у меня возник вопрос, соотносящийся с идущей здесь дискуссией про ардуинщиков.
Там есть HAL, конечно, не такой ущербный, как у ардуины, но все равно с высоким уровнем абстракции. И в чем принципиальная разница — юзает человек HAL ардуины (если забыть о его убогости), SPL, HAL от ST или HAL RIOT'а?
Далее. Там поддерживается много всего, и AVR, и STM32, и NRF и т.д. И все они отличаются по своим возможностям, но драйвера (например, те же sx1276) реализованы поверх HAL'а и вроде как переносимы. Но возможности каких-нибудь ATMega328 и STM32F4 сильно различаются. И чтобы драйвера были переносимыми, придется подводить под общий знаменатель, жертвовать функциональностью более сложных камней (всякие DMA и прочее).
Тут должен быть какой-то вывод, но у меня нет окончательно сформированного мнения по этому вопросу
И в чем принципиальная разница — юзает человек HAL ардуины (если забыть о его убогости), SPL, HAL от ST или HAL RIOT'а
ОС — это далеко не только HAL. Это ещё потоки, сообщения, виртуализация железа, стандартные API к различным подсистемам, наборы готовых драйверов…
Взять те же таймеры. Спросите ардуинщика, сколько таймеров он может завести — он полезет смотреть, сколько аппаратных таймеров есть в камне. Спросите меня… слушайте, ну много, у меня тут ОЗУ 32 килобайта, а один таймер байт восемь занимает, что ли.
И чтобы драйвера были переносимыми, придется подводить под общий знаменатель, жертвовать функциональностью более сложных камней (всякие DMA и прочее).
Совершенно не обязательно. Драйверы периферии как раз непереносимы по определению, поэтому их можно написать с DMA под один камень и без DMA под другой, лишь бы наружу одинаковые функции торчали.
ОС — это далеко не только HAL. Это ещё потоки, сообщения, виртуализация железа, стандартные API к различным подсистемам, наборы готовых драйверов…
Все это понимаю, я тут исключительно про абстракцию над GPIO, I2C и т.п. Либо я не понял Вас, либо Вы в комментариях тут утверждали что лучше всего все делать на регистрах, а SPL, HAL — от лукавого.
Спросите ардуинщика, сколько таймеров он может завести — он полезет смотреть, сколько аппаратных таймеров есть в камне.
Хех, более вероятно, что он сделает круглые глаза "О_о", максимум будет втирать про TimerOne :)
ну много, у меня тут ОЗУ 32 килобайта, а один таймер байт восемь занимает, что ли.
А насколько быстро? А ШИМ? В целом, зависит от задачи. Иногда имеет смысл использовать программные таймеры, иногда лучше аппаратные и разгрузить ядро. (с) Капитан Очевидность
Совершенно не обязательно. Драйверы периферии как раз непереносимы по определению, поэтому их можно написать с DMA под один камень и без DMA под другой, лишь бы наружу одинаковые функции торчали.
Видимо, я не разобрался до конца. Я просмотрел несколько https://github.com/RIOT-OS/RIOT/tree/master/drivers, но не увидел камне-зависимых реализаций.
Либо я не понял Вас, либо Вы в комментариях тут утверждали что лучше всего все делать на регистрах
Это не имеет практического смысла делать не на регистрах. SPL тоже всё делает на регистрах, только вы заранее не знаете, как — и имеете все шансы в неудачный момент попасть на разборки с глюком или особенностью SPL.
То есть, уметь в регистры вам всё равно потребуется.
Собственно, ST не даром сделала ещё и LL, которые являются промежуточным звеном между CMSIS и SPL.
Я просмотрел несколько github.com/RIOT-OS/RIOT/tree/master/drivers, но не увидел камне-зависимых реализаций.
Это драйверы внешних устройств, от периферии самого MCU там только хедеры, они действительно процессоронезависимы. Периферия конкретных камней лежит в cpu/
SPL тоже всё делает на регистрах, только вы заранее не знаете, как — и имеете все шансы в неудачный момент попасть на разборки с глюком или особенностью SPL.
Точно так же какая-нибудь i2c_read_reg может содержать ошибку и привести к глюкам.
То есть, уметь в регистры вам всё равно потребуется.
Абсолютно согласен.
Это драйверы внешних устройств, от периферии самого MCU там только хедеры, они действительно процессоронезависимы
Про внешние и говорил. Например, можно писать (ну пусть в тотююу же LoRa) вручную побайтово, а можно дма. Либо забить на совместимость, либо забить на дма, либо делать реализацию драйвера для авр без дма, для стм с дма, nrf с дма (но уже другой, можно сделать абстракцию dma...)
В физический чип трансивера пишет драйвер SPI, специфичный для конкретного микроконтроллера и получающий от драйвера трансивера на вход ссылку на массив и размер того массива.
Пишет он его дальше побайтово, через DMA или как-то ещё — исключительно дело драйвера SPI. Драйверу радиотрансвера на это глубоко пофиг.
Пишет он его дальше побайтово, через DMA или как-то ещё — исключительно дело драйвера SPI. Драйверу радиотрансвера на это глубоко пофиг.
достаточно того, что в циклах while{...} нет таймаутов, из-за чего прогрмамма может в неожиданный момент зависнуть.
Курсы по современным микроконтроллерам и программированию это конечно хорошо. Но очень часто на таких курсах за основу берется либо экзотическая плата, либо экзотическая библиотека и среда разработки. Оно и понятно, преподавателей мало, и тот кто все-таки нашелся, тащит с собой свои наработки.
Я считаю, что нужно брать самую распространенную отладочную плату (не обязательно при этом самую дешевую) и нормальную среду разработки (IAR и т.п.). Для STM32 обязательно использовать CubeMX — стандарт, который ОЧЕНЬ сильно облегчает жизнь, практически убирая необходимость напрямую копаться в огромной куче регистров и спец-констант. При этом ничего не мешает при необходимости переписать стандартные обработчики HAL и залезть напрямую в регистры. И самое главное, переход на другой чип будет относительно безболезненным.
Есть у меня пример для адептов прямой работы с регистрами.
как пример, вспоминаю курс по 3D графике в НГУ. Вместо изучения OpenGL или Direct 3D, мы изучали самописную библиотеку преподавателя SmogDX. В итоге,
если захочешь устроиться на работу, то не знаешь ни DirectX, ни OpenGL, и все нужно учить заново
Я считаю, что нужно брать самую распространенную отладочную плату (не обязательно при этом самую дешевую) и нормальную среду разработки (IAR и т.п.). Для STM32 обязательно использовать CubeMX — стандарт, который ОЧЕНЬ сильно облегчает жизнь, практически убирая необходимость напрямую копаться в огромной куче регистров и спец-констант. При этом ничего не мешает при необходимости переписать стандартные обработчики HAL и залезть напрямую в регистры. И самое главное, переход на другой чип будет относительно безболезненным.
Есть у меня пример для адептов прямой работы с регистрами.
Попросили меня доработать проект на STM32, добавив UART, ну и по мелочи баги убрать. Беда была в том, что вся инициализация и работа была регистрами, в них записывались какие-то магические числа. Ок, открываю доку, нахожу какой бит за что отвечает, разбираюсь. Но дело движется ОЧЕНЬ медленно. Плюнул и переписал все с нуля на CubeMX. Нужно поменять частоту тактирования или таймера — меняешь в GUI, и не паришься насчет того, что где-то что-то забыл поменять в десятке регистров. И после меня,
кому нужно будет дорабатывать проект, будет намного легче, т.к. все функции самодокументированы, примеров в интернете и документации по HAL полно.
Для STM32 обязательно использовать CubeMX — стандарт, который ОЧЕНЬ сильно облегчает жизнь, практически убирая необходимость напрямую копаться в огромной куче регистров и спец-констант
А зачем вам в них копаться, если у вас есть ОСРВ со своим HAL? И как вы планируете выхлоп CubeMX в эту ОСРВ интегрировать?
Нужно поменять частоту тактирования или таймера — меняешь в GUI, и не паришься насчет того, что где-то что-то забыл поменять в десятке регистров
/**
* @name Clock system configuration
* @{
**/
#define CLOCK_LSE (32768) /* external low-speed crystal frequency */
#define CLOCK_HSE (24000000U) /* external high-speed crystal frequency */
#define CLOCK_HSI (16000000U) /* internal high-speed crystal frequency */
#define CLOCK_CORECLOCK (32000000U) /* targeted core clock frequency */
/**
* @brief Timer configuration
* @{
*/
#define TIMER_0_MAX_VALUE (0x0000ffff)
static const timer_conf_t timer_config[] = {
{
.dev = TIM11,
.max = TIMER_0_MAX_VALUE,
.rcc_mask = RCC_APB2ENR_TIM11EN,
.bus = APB2,
.irqn = TIM11_IRQn
}
};
#define TIMER_0_ISR isr_tim11
#define TIMER_NUMOF (sizeof(timer_config) / sizeof(timer_config[0]))
/** @} */
/**
* @name I2C configuration
* @{
*/
#define I2C_0_EN 1
#define I2C_1_EN 1
#define I2C_NUMOF (I2C_0_EN + I2C_1_EN)
#define I2C_IRQ_PRIO CPU_DEFAULT_IRQ_PRIO
#define I2C_APBCLK (CLOCK_APB1)
/* I2C 0 device configuration */
#define I2C_0_EVT_ISR isr_i2c1_ev
#define I2C_0_ERR_ISR isr_i2c1_er
/* I2C 1 device configuration */
#define I2C_1_EVT_ISR isr_i2c2_ev
#define I2C_1_ERR_ISR isr_i2c2_er
static const i2c_conf_t i2c_config[] = {
/* device, port, scl-, sda-pin-number, I2C-AF, ER-IRQn, EV-IRQn */
{I2C1, GPIO_PIN(PORT_B, 8), GPIO_PIN(PORT_B, 9), GPIO_OD_PU,
GPIO_AF4, I2C1_ER_IRQn, I2C1_EV_IRQn, 0},
{I2C2, GPIO_PIN(PORT_B, 10), GPIO_PIN(PORT_B, 11), GPIO_OD_PU,
GPIO_AF4, I2C2_ER_IRQn, I2C2_EV_IRQn, 1},
};
/** @} */
Очень сложно?
А зачем вам в них копаться, если у вас есть ОСРВ со своим HAL? И как вы планируете выхлоп CubeMX в эту ОСРВ интегрировать?
Если FreeRTOS удовлетворяет потребностям, то в Cube он идет из коробки. Даже размечает исходники, для кода разработчика, чтобы в случае перегенерации проекта не затереть написанный руками код.
Хотя FreeRTOS сейчас — самая распространённая ОС, мир существенно больше.
Ну и часть смысла ОС — в возможности разделении низкоуровневой и высокоуровневой разработки, поэтому при её использовании пишущему верхние алгоритмы потроха процессора не нужны, а допиливающему саму ОС от CubeMX толку мало, потому что всё равно надо контролировать, что он там нагенерил, ибо бывают сюрпризы.
Ну и часть смысла ОС — в возможности разделении низкоуровневой и высокоуровневой разработки, поэтому при её использовании пишущему верхние алгоритмы потроха процессора не нужны, а допиливающему саму ОС от CubeMX толку мало, потому что всё равно надо контролировать, что он там нагенерил, ибо бывают сюрпризы.
Для студента сложно. Очень. Например, что такое GPIO_PIN? Макрос? Какой? Где искать?
Заполняете структурку i2c_config. Почему такие значения? Где возможные варианты смотреть? Какая последовательность инициализации? Почему именно такая?
Ваши студенты получат ответы? //мне не надо, я знаю.
Заполняете структурку i2c_config. Почему такие значения? Где возможные варианты смотреть? Какая последовательность инициализации? Почему именно такая?
Ваши студенты получат ответы? //мне не надо, я знаю.
Вы это так пишете, как будто в CubeMX вам разъясняют, какова последовательность инициализации, а не просто предлагают галочек на внешней поверхности чёрного ящика натыкать.
Где вы видите в моих сообщениях про CebeMX?
Вы же сами пишите: «Однако, как показала практика, многим студентам интересно более серьёзно углубиться в то, что происходит внутри микроконтроллеров.»
Да, работать с регистрами для этого надо. И ваш выбор STM32 или любого ядра Cortex-M — не самое лучшее решение. Те же attiny,PIC или 8051 позволяют лучше понять работу контроллера. Все остальные библиотеки, IDE по мере необходимости осваиваются, когда базовые знания есть.
Многозадачность, семафоры, события — всё это надо знать, но не на начальном этапе. Это я вам как человек с учёной степенью и небольшим опытом преподавания пишу.
Вы же сами пишите: «Однако, как показала практика, многим студентам интересно более серьёзно углубиться в то, что происходит внутри микроконтроллеров.»
Да, работать с регистрами для этого надо. И ваш выбор STM32 или любого ядра Cortex-M — не самое лучшее решение. Те же attiny,PIC или 8051 позволяют лучше понять работу контроллера. Все остальные библиотеки, IDE по мере необходимости осваиваются, когда базовые знания есть.
Многозадачность, семафоры, события — всё это надо знать, но не на начальном этапе. Это я вам как человек с учёной степенью и небольшим опытом преподавания пишу.
Где вы видите в моих сообщениях про CebeMX?
Вы отвечаете в треде, начавшемся с тезиса «Для STM32 обязательно использовать CubeMX». Я, конечно, понимаю, что старые фидошники сабжа не меняют, но.
Те же attiny,PIC или 8051 позволяют лучше понять работу контроллера
Покажите мне в ATTiny работу с RTC или динамическое конфигурирование частот и включение-выключение периферии.
Многозадачность, семафоры, события — всё это надо знать, но не на начальном этапе
Чем вам мешает знание о многозадачности?
когда базовые знания есть
Базовые — это какие конкретно?
Чем вам мешает знание о многозадачности?Не мешает. Эти знания необходимы. Но это не предмет для обучения на 1 лекции. А во второй половине курса. К этому понимаю надо подвести.
Базовые — это какие конкретно?Вы это всё знаете. Возможно, сами себе и другим объяснить не можете. Складывается впечатление, что вы хотите себе сотрудников подготовить для решения конкретных задач, а не университетское образование даёте.
1) Необходимо рассказать об архитектуре, шинах, памяти, адресах, прерываниях. Можно сравнить с 8051, где данные и программа хранятся раздельно.
2) Порты. Если исходить из того, что микроконтроллер — это устройство управления эл.сигналами по программе, то тут много чего надо рассказать и показать с привязкой к эл.схемам. Конкрентные примеры. Про push-pull, open-drain я уже писал. Фронты сигналов. Сюда же встроенный триггер Шмитта и расчёт RC-цепочки к нему. Режимы main/alt. И из всего этого настраивается/конфигурируется порт. Тут можно диодом помигать и кнопку понажимать без дребезга. На осциллограф посмотреть.
3) Ваш курс про SPI, I2C, UART. С примерами. И про max232 не забыть, DTR, CTS. А то вроде бы все uart знают, а управлять нормально линией не умеют.
4) Прерывания и таймеры.
На этот этапе эволюционно проясняется архитектура ПО микроконтроллера. Она может быть разной. Сначала:
while(1)
{
LedTogle();
Delay(100);
}
Потом конструкция усложняется и появляются if
while(1)
{
if( KeyPressed )
LedOn();
else
LedOff();
}
Тут необходимо напомнить о механизме callback и указателях на функцию.
Вскоре программа усложняется и превращается в конечный автомат, finite state machine. Обычно это выглядит в форме множества вложенных операторов if или switch. Те кто изучал эту тему, знают что этот автомат можно представить в виде графа или матрицы состояний. В языке С это реализуется в виде массива. Элементы массива — указатели на функции-обработчики состояния. Таким образом, происходит следующий шаг эволюции ПО. Появляются отдельные функции, в том числе с привязкой к прерываниям: OnKeyPressed(), OnSend(), OnRecieve и т.д… и OnTimer().
В итоге получилась событийная система, которая как мне кажется наиболее часто используется. Все эти обработчки необходимо между собой связать, согласовывать их работу, разделять данные. Появляются семафоры, события, lock, volatile и т.д. Часть кода требуется выполнять параллельно или периодически.
Примерно так происходит переход к RTOS, плавно, эволюционно.
Это я не вам лекцию читаю, это я план учебного курса даю. Вы то всё знаете. Рассказать другим — искусство. А вы бац и сразу.
P.S. Вопрос про Attiny считаю риторическим, с целью поспорить. Ответ — никак, а вот ногами учиться дрыгать на нём можно, порты дубовые, не сгорят. Но на 8051 можно на лету и частоту менять, и биты адресовать.
Но это не предмет для обучения на 1 лекции. А во второй половине курса. К этому понимаю надо подвести.
К пониманию чего конкретно? Вы считаете, что эти же студенты не знакомы с многозадачностью на обычных декстопах, под которые они пишут обычные программы?
Складывается впечатление, что вы хотите себе сотрудников подготовить для решения конкретных задач, а не университетское образование даёте
Вы никогда не задумывались над тем, что образование — в том числе и университетское — всегда движется от общего к частному, а не наоборот? Нет? А зря.
Интереса ради посмотрите на любые другие программы — в школе, в университете, где угодно. Вас — вот лично вас — никогда, ни в одном учебном заведении, через которое вы прошли, не начинали учить с деталей. Вам всегда давали сначала общую картину, а уже потом начинали её детализировать и уточнять.
Вы пишете и читаете на русском языке, при этом вряд ли сможете внятно ответить хоть на один вопрос из области лингвистики и конкретно славянистики. Ваши школьные курсы физики, математики, химии, биологии и астрономии смехотворны. Ваше знание простейшей химической реакции «2×H2 + O2 → 2×H2O» бессмысленно, потому что это просто бездумно заученная вами строчка, про которую вы даже приблизительно не представляете, что она на самом деле означает; и примерно то же с абсолютным большинством дисциплин, по которым вас учили.
Мешает ли вам это в жизни? Подозреваю, что нет. Потому что, получив этот набор общих знаний, вы выбрали для себя какое-то направление специализации (на самом деле, вы его выбирали много раз, это многократно повторяющийся процесс), по которому вас уже и нагрузили специфическими деталями.
Так вот, наше обучение программированию микроконтроллеров построено ровно на тех же принципах, что и всё остальное образование: от общего к частному. Мы даём полусотне студентов навыки работы с микроконтроллерами, позволяющие взять микроконтроллер и работать с ним на современном уровне. Четверть этих студентов выберет микроконтроллеры в качестве направления специализации и будет изучать детали; три четверти останутся с базовыми навыками, примерно соответствующими, например, вашим навыкам в физике, химии, биологии, географии, экономике, литературе и примерно всем остальным дисциплинам, которым вас в жизни учили.
А от вас из полусотни студентов три четверти просто сбегут на этапе расчёта RC-цепочек и останутся ни с чем, потому что им это не нужно и неинтересно.
P.S. «Управление линией в RS232» — это вообще не университетская программа, а дрессировка «по рабочей специальности» людей, которые самостоятельно учиться неспособны.
Очень сложно, а самое главное, не нужно. Зачем тратить время на эту информацию, если можно потратить его на более важные вещи типа написания основного кода программы. Все эти интерфейсы, DMA — довольно простые штуки, если смотреть с верхнего уровня на них. Но если погружаться в конкретную реализацию на конкретном чипе, то всплывают горы конфигурационных битов, которые нужно установить строго в определенном порядке. На отладку всего этого гемороя тратится очень много времени.
По поводу наличия HAL в ОСРВ. Мне кажется, что задача ОСРВ — это прежде всего обеспечить многопоточность и таймеры — семафоры. Все остальное это либо HAL от производителя чипа, либо сторонние библиотеки, как например LwIP или FatFS. HAL от ST хорошо документирован и известен в интернете. А HAL от RIOT?
По поводу наличия HAL в ОСРВ. Мне кажется, что задача ОСРВ — это прежде всего обеспечить многопоточность и таймеры — семафоры. Все остальное это либо HAL от производителя чипа, либо сторонние библиотеки, как например LwIP или FatFS. HAL от ST хорошо документирован и известен в интернете. А HAL от RIOT?
Зачем тратить время на эту информацию
А откуда вы знаете, на какой частоте вообще работает ваш контроллер и есть ли у него вообще, например, RTC и I2C, если вы не потратили время на эту информацию?
Но если погружаться в конкретную реализацию на конкретном чипе, то всплывают горы конфигурационных битов
Вы в приведённом выше примере видиее хотя бы один конфигурационный бит?
Все остальное это либо HAL от производителя чипа, либо сторонние библиотеки
С HAL от производителя чипа всё замечательно, кроме того, что у каждого производителя свой API, не похожий больше ни на что в мире.
использование плат ST Nucleo-L152
А что то из серия XNucleo можно использовать, она вроде новее и функциональнее?
А можно еще mbed os 5 использовать, keil rtx, segger emOS и еще 100500. Можно и RIOT. Разницы никакой нет. Принципы одни и те же. Меньше знаний — больше флэша. Но нам то флэша не жалко.
Посмотрев на автора поста, я сделал для себя выводы. Спорить и доказывать вообще бесполезно. Применение и обучение с ОС реального времени — ошибка, такая же как использование библиотек Arduino.
Сначала надо научить как завести контроллер. Как инициализировать порты, какие режимы работы портов, что такое Push-Pull, Open Drain, Main/Alternative и т.д. На электрической схеме разжевать почему I2C open-drain, SPI наоборот PP. Рассмотреть, на примере SD карты, схему подключения и подтяжек.
Про DMA в вашем курсе ни слова. Про прерывания вскользь. Мне это понятно, вы упор делаете на RTOS. Но это в вашей фирме так, а у других иначе. Ваша продукция работает месяцами, а у других несколько секунд под спец.нагрузками. Учить надо так, чтобы инженер мог использовать любой MCU в любых условиях.
P.S. И про отладку ни слова. А это 90% времени разработки.
Сначала надо научить как завести контроллер. Как инициализировать порты, какие режимы работы портов, что такое Push-Pull, Open Drain, Main/Alternative и т.д. На электрической схеме разжевать почему I2C open-drain, SPI наоборот PP. Рассмотреть, на примере SD карты, схему подключения и подтяжек.
Про DMA в вашем курсе ни слова. Про прерывания вскользь. Мне это понятно, вы упор делаете на RTOS. Но это в вашей фирме так, а у других иначе. Ваша продукция работает месяцами, а у других несколько секунд под спец.нагрузками. Учить надо так, чтобы инженер мог использовать любой MCU в любых условиях.
P.S. И про отладку ни слова. А это 90% времени разработки.
А может ещё и закон Ома в том же курсе им давать? Двоичную систему, понятие алгоритма и вообще арифметику?
НЛО прилетело и опубликовало эту надпись здесь
И вообще пусть сначала свой первый ALU на К155ЛА3 соберут.
И чтобы каждый сходил на пляж, принёс песок и сам добыл немного кремния.
Если в цели разработка встраиваемых решений с автономным питанием — измерение потребления тока, расчёт ёмкости амперчасов с приемлемой точностью — must have. Что бы интеграторы не страдали от маркетологических «работа на одной батарейки 10 лет». Это я как специалист, которые эти устройства потом ставит, и ой, а оно и полгода не продержалось.
Полностью согласна. Я включу задачи такого рода в новую версию курса IoT Академии Samsung — работа над этим уже ведется.
Кстати, в неплохом курсе Architecting Small IoT Devices на Coursera есть раздел, посвященный этой теме: ru.coursera.org/learn/iot-architecture/lecture/u9EJP/power-budget
Кстати, в неплохом курсе Architecting Small IoT Devices на Coursera есть раздел, посвященный этой теме: ru.coursera.org/learn/iot-architecture/lecture/u9EJP/power-budget
NB: в составе железа тогда надо предусмотреть измеритель тока. В текущем комплекте потребление пристойно измерить нечем.
Мультиметр + осциллограф не спасут? Хотя бы в черновом варианте?
Во-первых, надо плату как минимум с шунтом, а лучше ещё и с усилителем, чтобы измерять конкретно потребление радиомодуля (ну или только процессора, потому что когда LoRa спит, у неё собственное потребление порядка 0,1 мкА).
Во-вторых, там диапазон токов — почти 5 порядков, от 1-2 мкА во сне до 40 мА при активном передатчике и процессоре одновременно. Поэтому по-хорошему такие вещи измеряют специальными логгерами с несколькими параллельными усилителями с разным Ку — данные снимают со всех, выбирают и масштабируют к общей шкале тот, который в данный момент не перегружен.
Мультиметры у нас в комплектах хорошие, но ими можно будет только ток покоя в глубоком сне измерить (тоже интересное знание, я покажу на лекции пару ловушек, которые в статьях освещают редко). Осциллографом можно посмотреть, как скачет потребление при переключении процессора между режимами, но не измерить что-либо точно.
Во-вторых, там диапазон токов — почти 5 порядков, от 1-2 мкА во сне до 40 мА при активном передатчике и процессоре одновременно. Поэтому по-хорошему такие вещи измеряют специальными логгерами с несколькими параллельными усилителями с разным Ку — данные снимают со всех, выбирают и масштабируют к общей шкале тот, который в данный момент не перегружен.
Мультиметры у нас в комплектах хорошие, но ими можно будет только ток покоя в глубоком сне измерить (тоже интересное знание, я покажу на лекции пару ловушек, которые в статьях освещают редко). Осциллографом можно посмотреть, как скачет потребление при переключении процессора между режимами, но не измерить что-либо точно.
Да, но я имел ввиду, что измерить и посчитать бюджет на столе это одно. Условия, как правило, идеальные. Можно то и измеритель мощности прецизионный поставить, если бюджет денежный позволяет.
А высчитать понижающий коэффициент в каждом месте специализированным устройством- это было бы отлично. Когда монтажник промеряет местные условия (покрытие и качество поля и прочие параметры) и извещении о монтаже делает отметки — когда расчётный регламент. По-хорошему — устройство должно само логгировать, анализировать.
А то обидно (как инженеру) видеть объект, нафаршированный по последнему слову поквартирного учёта и узнать, что половина данные не передаёт, а почему — интегратор не знает, а узнать нечем.
А высчитать понижающий коэффициент в каждом месте специализированным устройством- это было бы отлично. Когда монтажник промеряет местные условия (покрытие и качество поля и прочие параметры) и извещении о монтаже делает отметки — когда расчётный регламент. По-хорошему — устройство должно само логгировать, анализировать.
А то обидно (как инженеру) видеть объект, нафаршированный по последнему слову поквартирного учёта и узнать, что половина данные не передаёт, а почему — интегратор не знает, а узнать нечем.
А высчитать понижающий коэффициент в каждом месте специализированным устройством- это было бы отлично
В рамках курса, думаю, достаточно будет рассказать о таких коэффициентах (температура, расходы на коллизии и т.п.).
А измерение на столе показать — чтобы было понятно, как прикидывается номинальный энергетический бюджет, и не было желания делать это мультиметром.
А не подскажете, студентам каких групп этот курс будет читаться? Какой курс, какой факультет (точнее институт или как там они теперь стали называться)?
Институт информационных технологий, директор Андрей Зуев.
Курсы — второй и третий, занятия факультативные. На лекцию, я думаю, можно приходить всем свободно, там аудитория человек на сто, на лабораторных занятиях присутствие ограничено размером лаборатории, это человек 30 максимум (особенно с учётом, что в итоге решили делать не два потока по 5 занятий, а один в 7 занятий, каждую неделю новое).
Курсы — второй и третий, занятия факультативные. На лекцию, я думаю, можно приходить всем свободно, там аудитория человек на сто, на лабораторных занятиях присутствие ограничено размером лаборатории, это человек 30 максимум (особенно с учётом, что в итоге решили делать не два потока по 5 занятий, а один в 7 занятий, каждую неделю новое).
Хорошее дело! А как часто ожидать статьи по данному циклу?
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Программирование современных микроконтроллеров — новый курс МИРЭА, Samsung и Unwired Devices