Комментарии 147
ST Nucleo-L152Почему выбрана именно эта плата? Она не самая доступная в России и не самая дешевая. Что в ней есть такого, за что стоит отдавать полторы тысячи, заморачиваясь с доставкой, но нет в более доступных и дешевых платах?
А так полное название — Nucleo-L152RE, www.chipdip.ru/product/nucleo-l152re
Выбор именно STM32L152, а не STM32F103, например, потому что L1 — следующая по распространённости после F1 серия, и ввиду её относительной новизны, там есть фишки, которые в F1 реализованы сильно иначе или вообще не реализованы. Ну, например, у нас в ОС есть штатные субсекундные таймеры на RTC, они работают на регистре RTC_SSR, который даже в L151 в ранних моделях ещё отсутствовал (L151CB — нет, L151CC и L151CB-A — уже есть).
Мы вряд ли успеем на курсе рассказать детали всего этого внутреннего хозяйства, но прелесть ОС в том, что использовать его это ничуть не мешает (и в теме про энергосбережение таймеры на RTC мы использовать будем на полную катушку).
А через год на том же чипе выпускают Launchpad за $29, которого 10 разработчикам из 10 хватает по уши.
Сам чип при этом всё это время стоит $5 в розницу с НДС.
Инженерны инженерами, идиоты идиотами; перечисленные вещи не являются чем-то постыдным.
Госдеп вообще ни к месту.
Обладая прекрасным 10-летним опытом работы с ардуиной, кубом и китайскими платами, большую часть решаемых у нас задач по разработке вы не то что не сможете решить — вы не сможете понять, с какой стороны вообще к ним подступаться.
Всё, что вы сможете сделать, обладая этим опытом — это штамповать типовые копеечные поделки.
P.S. Про платы, собранные на китайских линиях, тут недавно уже была история — как у людей из-за смены чипа SPI-флэшки бизнес встал, потому что никто не мог понять, что с новым чипом делать, кроме как брать фен и менять на старый на всей партии.
Полагаю, Ваши материалы именно то, чего не хватало правильного понимания платформы. Спасибо.
Вот у вас в схеме стоит банальное электромагнитное реле, куда уж проще, да? А теперь — список типовых ошибок, которые я видел в релейных схемах, спроектированных любителями:
* использование биполярных драйверов ULN2003A при неучёте зависимости напряжения срабатывания реле от температуры, в результате чего температурный диапазон устройства оказывается в районе -20...+30 °С
* неучёт разных рейтингов реле по напряжению и току на постоянном и переменном токе
* использование шунтирующего диода вместо TVS на обмотке реле при коммутации индуктивных нагрузок (жёсткое шунтирование обмотки сильно увеличивает время дребезга контактов при отпускании)
* неиспользование последовательных или параллельных симисторов для подавления дугообразования на контактах при коммутации индуктивных нагрузок
* и это уже не говоря про очень распространённое непонимание обеспечения правильной гальванической развязки схемы (зачем-то воткнутый оптрон между контроллером и реле и одновременно 0,5 мм между дорожками высоковольтной части и земляным полигоном низковольтной — вообще типичная картина)
Комбинируем пару пунктов из списка — и легко получаем такое простое и понятное релейное устройство, в котором контакты гарантированно умирают за год, а если в жарком климате, то за пару месяцев.
А это всего лишь обычное электромагнитное реле.
Посмотрел пару тройку даташитов на реле и нигде не увидел зависимость срабатывания реле от температуры. К тому же причем тут ULN2003A?
Вторая страница, «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, а график может показать его уменьшение относительно номинального, что не есть существенно, иначе фигня какая то получается.
Ведь это мы только банальное электромагнитное реле потрогали.
Знание таких вещей нарабатывается только и исключительно через личную привычку внимательно читать документацию, а не лепить «MVP за пять минут» из китайских модулей.
а набросать простую статью в которой были бы указаны такие моменты вы не хотите
Вы сейчас не понимаете, почему я не хочу бесплатно поработать и, потратив пару часов моего времени, написать статью для каких-то посторонних мне людей, излагающую в доступной им форме то, что они ленятся прочитать самостоятельно, потратив пару часов своего времени.
Должен признать, это не очень заманчивое предложение.
кто-то делает реле с неноминальным срабатыванием
Что такое «реле с неноминальным срабатыванием»? У реле есть номинальное напряжение обмотки и отклонения от него вверх и вниз, при которых оно ещё срабатывает.
росто тогда не нужно удивляться таким ошибкам у людей
Я не удивляюсь, я констатирую факт. И большинство из этих людей никогда не наберётся опыта, ибо уже счастливы с ардуиной и китайскими модулями (происхождение модулей заодно позволяет легко объяснить, кто виноват, если оно таки сдохло).
поэтому мне непонятно его приведение в примере
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».
Его, конечно, можно применять для управления реле. Но есть один нюанс.
И знания о таких вещах приобретаются не из опыта — никто не сидит с термошкафом, регулируемым источником, мультиметром, осциллографом и ящиком реле, чтобы изучить их характеристики при разных температурах.
Это всё давно описано и разжёвано в даташитах и аппнотах, которые надо читать — вместо того, чтобы бездумно лепить первую попавшуюся в интернете схему без малейшего понимания, как и почему она работает. Позиция «расскажите мне об этом так, чтобы я не напрягался» — это чистой воды let me google it for you.
Конечно никто никому ничего не обязан, но таким подходом вы повышаете порог вхождения и толкает людей со стороны к тем же модулям ардуино которые вы не любите
Вы сейчас продолжаете убеждать меня, что я должен вам денег.
Почему-то у программистов с этим гораздо проще чем у электронщиков
Понимающий ситуацию программист никогда не будет делиться уникальными знаниями просто так. Зачем плодить себе потенциальных конкурентов.
Что-бы преодолеть порог, нужны вложения — либо своё время и усилия, либо наемный «репетитор». Никто не обязан повышать профессиональный уровень окружающих бесплатно.
Мне кажется все развитие мира open source с вами не согласно.
В проектах, где коммерческой основы нет, вы с большой вероятностью быстро столкнётесь с мейнтейнером, который тут и.о. царя и бога, а также «я так вижу». Ничего особенно приятного, по сути люди чешут собственное эго.
В результате, если вы хотите использовать в работе опенсорс — вы, в зависимости от величины того опенсорса, либо сажаете людей на окладе на взаимодействие с мейнтейнерами и контрибуцию, либо делаете свой форк.
Собственно, тот же RIOT, который мы используем и в учебном курсе, и в изделиях, у нас живёт в виде нашего форка, который контрибьютиться в mainline не будет. Просто потому, что после пары дискуссий с мейнтейнерами, в которых два человека в двух ветках совершенно спокойно утверждали противоположные вещи, и сходились только в тезисе «мы так решили уже давно, не нравится — читайте Code of Conduct до просветления, а не спорьте тут», я решил, что процесс не окупает затрачиваемых усилий.
Обладая прекрасным 10-летним опытом работы с ардуиной, кубом и китайскими платами, большую часть решаемых у нас задач по разработке вы не то что не сможете решить — вы не сможете понять, с какой стороны вообще к ним подступаться.А можно примеров несколько навкидку? мне просто интересно без оценок и мнения в спорах (я не ардуинщик и вообще сложнее светодиодов лет 20 ничего не паял.)
* различные хитрые 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 и начать лепить очередной «умный дом» на китайских модулях.
За конструктивную критику благодарю, сожалею, что Вы не отписались в той теме.
STM-ы вообще раскуриваются имея на руках только reference manual
Просто интересно, какой набор знаний вы предполагаете для того, чтобы просто раскурить рефер на стм (32, я так понял)?
А арудуина — это тоже мега-прорыв своего рожа, но не надо их противопоставлять с промавтоматикой, это дополнительная ниша, ну как огороды и пром. с/х, гаражи и заводы и т.п.
К тому же, под микроконтроллеры на Rust фактически нет ОСРВ (есть порт FreeRTOS и что-то ещё совсем маргинальное), а в самом языке любое неловкое движение (использование стандартных библиотек) увеличивает размер кода одним махом на десятки килобайт.
Вообще, гарантии по памяти для очень маленьких встраиваемых платформ (как в статье) не самая большая головная боль. По хорошему, там вы вообще стремитесь не использовать динамическое выделение в куче — выделили при инициализации всё что надо и больше кучу не трогаете. Иначе потом каждый malloc()/new будет бомбой замедленного действия — кто знает в какой момент выделение обломится из-за фрагментации кучи. Понятно что Rust — это не только память, но всё же в ситуации, когда кучу вообще лишний раз трогать чревато, его привлекательность падает.
LLVM поддерживает и ARM, и MIPS. А 8- и 16-разрядные платформы в этом курсе, как я понял, не рассматриваются.
Я тот самый суровый нордический парень с бородой, пытающийся наладить безопасность прошивок того самого хипстеровского макбука и я вам откровенно заявляю: писать сколько нибудь безопасный код много, быстро и недорого на С невозможно, даже если обвешаться статическими анализаторами, АСАНами, УБСАНами и десятком других утилит, помогающими находить ошибки в на вид совершенно безошибочном коде.
Да, мы используем этот язык 30+ лет, да, по нему достаточно специалистов, да, его придется изучать и с ним придется работать, но я вас заклинаю: если можете, пожалуйста, не пишите на нем ничего, связанного с безопасностью, он для этого подходит примерно как ножи для жонглирования — есть люди, которые умудряются еще и штуку инжира кушать, жонглируя ими, но в основном все заканчивается очень плохо. История с уязвимостями всех без исключения ядер современных ОС, написанных на С-подобных языках — отличное тому подтверждение.
При этом наша цель — дать студентам понимание того, как работать с типовым современным микроконтроллером. Человек, таким пониманием обладающий, при необходимости другие контроллеры (мир не заканчивается на STM32) и другие языки освоить сможет уже сам.
А ситуация не поменяется, если ее не менять. Будет как с Cobol, который тоже вечен.
Так вот Rust там мало, и долго ещё будет мало.
Вообще, хотелось бы побольше актуально информации о плате, несколько ссылок не помешало бы — для тех, кто не глубоко в этой теме.
Среда сборки — GNU ARM Toolchain, developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads, работает под всеми основными ОС. Ничего другого требоваться не будет, код можно хоть в текстовом редакторе писать (всегда так делаю, кстати).
Это кстати объясняет ваше отношение к rust. IDE это зло? Может и платы разводить в pcad 4?
Я сам Rust очень люблю, а IDE пользоваться так и не научился, до сих пор пишу в vim на Scala. Но, теоретически, к IDE отношусь хорошо, особенно после просмотра лекций про Idris и Types Driven Development (коллеги продемонстрировали, что приемы из лекции и в IDEA со Scala работают).
Не далее как пару недель назад восстанавливал исходники, написанные когда-то кем-то под какой-то давно мёртвый форк gcc.
При этом использование IDE не является чем-то уникальным для эмбеддеда, так что студенты программистских факультетов познакомятся с ними в любом случае, с нашим участием или без.
Более того, институт будет вести видеозапись всех лекций и выборочную видеозапись практических занятий, в блоге IoT Академии Samsung будут появляться конспекты прошедших лекций, адаптированные под использование плат ST Nucleo-L152, доступных в продаже для всех желающих по цене 1200-1400 рублей, а в Github-репозитарии Unwired Devices появится используемые на занятиях код.
необходимость написать полстраницы кода только для того, чтобы микроконтроллер завёлся.Это все ерунда. Когда в универе были лабы по ЦОС на сигнальниках от AD, на первой лабе нам просто давали код инициализации. Потом уже все детальнее разбиралось. Порты AVR до электрической схемы раскапывались, но первую лабу можно тоже было сделать и сдать с довольно общими знаниями. Это нормальная практика.
- Беспроводные сети передачи данных. Работа с радиоканалом LoRa. Защита передаваемых данных от типовых атак.
Практика: передача сообщений между двумя микроконтроллерами с использованием готового драйвера LoRa-трансивера SX1276. Шифрование сообщений, защита от подделки сообщений, защита от атак повтором.
А можете поделиться драйвером? Я какое-то время поискал, не нашел и написал что-то свое, частично портировав драйвер с Arduino, выкинув с него говнокод, расширив путем вдумчивого курения даташита. Правда потом стало резко не до этого, не дописал до конца, так руки и не дошли
Я даю ссылку на старый релиз, потому что в новых он совсем переплёлся с операционкой. Сам драйвер портирован из семтековского кода 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...)
Пишет он его дальше побайтово, через DMA или как-то ещё — исключительно дело драйвера SPI. Драйверу радиотрансвера на это глубоко пофиг.
как пример, вспоминаю курс по 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 он идет из коробки. Даже размечает исходники, для кода разработчика, чтобы в случае перегенерации проекта не затереть написанный руками код.
Ну и часть смысла ОС — в возможности разделении низкоуровневой и высокоуровневой разработки, поэтому при её использовании пишущему верхние алгоритмы потроха процессора не нужны, а допиливающему саму ОС от CubeMX толку мало, потому что всё равно надо контролировать, что он там нагенерил, ибо бывают сюрпризы.
Заполняете структурку i2c_config. Почему такие значения? Где возможные варианты смотреть? Какая последовательность инициализации? Почему именно такая?
Ваши студенты получат ответы? //мне не надо, я знаю.
Вы же сами пишите: «Однако, как показала практика, многим студентам интересно более серьёзно углубиться в то, что происходит внутри микроконтроллеров.»
Да, работать с регистрами для этого надо. И ваш выбор 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» — это вообще не университетская программа, а дрессировка «по рабочей специальности» людей, которые самостоятельно учиться неспособны.
По поводу наличия HAL в ОСРВ. Мне кажется, что задача ОСРВ — это прежде всего обеспечить многопоточность и таймеры — семафоры. Все остальное это либо HAL от производителя чипа, либо сторонние библиотеки, как например LwIP или FatFS. HAL от ST хорошо документирован и известен в интернете. А HAL от RIOT?
Зачем тратить время на эту информацию
А откуда вы знаете, на какой частоте вообще работает ваш контроллер и есть ли у него вообще, например, RTC и I2C, если вы не потратили время на эту информацию?
Но если погружаться в конкретную реализацию на конкретном чипе, то всплывают горы конфигурационных битов
Вы в приведённом выше примере видиее хотя бы один конфигурационный бит?
Все остальное это либо HAL от производителя чипа, либо сторонние библиотеки
С HAL от производителя чипа всё замечательно, кроме того, что у каждого производителя свой API, не похожий больше ни на что в мире.
использование плат ST Nucleo-L152
А что то из серия XNucleo можно использовать, она вроде новее и функциональнее?
Сначала надо научить как завести контроллер. Как инициализировать порты, какие режимы работы портов, что такое Push-Pull, Open Drain, Main/Alternative и т.д. На электрической схеме разжевать почему I2C open-drain, SPI наоборот PP. Рассмотреть, на примере SD карты, схему подключения и подтяжек.
Про DMA в вашем курсе ни слова. Про прерывания вскользь. Мне это понятно, вы упор делаете на RTOS. Но это в вашей фирме так, а у других иначе. Ваша продукция работает месяцами, а у других несколько секунд под спец.нагрузками. Учить надо так, чтобы инженер мог использовать любой MCU в любых условиях.
P.S. И про отладку ни слова. А это 90% времени разработки.
Но интересно все же, тут такие споры в комментах…
Можно конкретнее узнать, что подразумевается под «базовыми знаниями С и светодиода»?
Кстати, в неплохом курсе Architecting Small IoT Devices на Coursera есть раздел, посвященный этой теме: ru.coursera.org/learn/iot-architecture/lecture/u9EJP/power-budget
Во-вторых, там диапазон токов — почти 5 порядков, от 1-2 мкА во сне до 40 мА при активном передатчике и процессоре одновременно. Поэтому по-хорошему такие вещи измеряют специальными логгерами с несколькими параллельными усилителями с разным Ку — данные снимают со всех, выбирают и масштабируют к общей шкале тот, который в данный момент не перегружен.
Мультиметры у нас в комплектах хорошие, но ими можно будет только ток покоя в глубоком сне измерить (тоже интересное знание, я покажу на лекции пару ловушек, которые в статьях освещают редко). Осциллографом можно посмотреть, как скачет потребление при переключении процессора между режимами, но не измерить что-либо точно.
А высчитать понижающий коэффициент в каждом месте специализированным устройством- это было бы отлично. Когда монтажник промеряет местные условия (покрытие и качество поля и прочие параметры) и извещении о монтаже делает отметки — когда расчётный регламент. По-хорошему — устройство должно само логгировать, анализировать.
А то обидно (как инженеру) видеть объект, нафаршированный по последнему слову поквартирного учёта и узнать, что половина данные не передаёт, а почему — интегратор не знает, а узнать нечем.
А высчитать понижающий коэффициент в каждом месте специализированным устройством- это было бы отлично
В рамках курса, думаю, достаточно будет рассказать о таких коэффициентах (температура, расходы на коллизии и т.п.).
А измерение на столе показать — чтобы было понятно, как прикидывается номинальный энергетический бюджет, и не было желания делать это мультиметром.
Курсы — второй и третий, занятия факультативные. На лекцию, я думаю, можно приходить всем свободно, там аудитория человек на сто, на лабораторных занятиях присутствие ограничено размером лаборатории, это человек 30 максимум (особенно с учётом, что в итоге решили делать не два потока по 5 занятий, а один в 7 занятий, каждую неделю новое).
Хорошее дело! А как часто ожидать статьи по данному циклу?
Программирование современных микроконтроллеров — новый курс МИРЭА, Samsung и Unwired Devices