C++ для Микроконтроллеров | Урок 7 часть 1 | Программирование STM32F4 на CMSIS

[@Timon_kakno]

Все еще ждем новые уроки…

[@mikitashary5552]

Ну наконец то новый выпуск

[@donrumata5299]

Да.. Время, кажется, появилось. Скоро будет урок о настройке новых IDE. А потом перейдём к Taimer`у.

[@mikitashary5552]

@@donrumata5299 здорово, спасибо огромное за то что делаешь

[@SuperPracion]

Так, вот эти вот 6 дизов - это люди которые просто не понимают всю необходимость ООП и его реального применения. Автор - крут.

[@sledleo]

Автор, продолжения не будет?! Ясно! У меня банальный вопрос, кто-нибудь заглядывал в команды поддерживаемые ARM процессором в чипах STM32? То есть те самые ассемблерные команды и работота на уровне регистров. Может кто-то мне объяснит почему бытовых операций нет в Си? И как он (Си компилятор) может догадаться что собственно мы хотим сотворить? Может он сам может понять что мы хотим изменить биты, которые имеют отображение в bit bang адресах, он может? И так далее... Простой пример, пишем мигалку светодиодом на CMSIS в Keil компилим и смотрим на результат - светодиод как-то странно тускло мерцает, но в алгоритме зашито постепенно изменение частоты туда-сюда. Где результат?! А все просто, по умолчанию при создании проекта Keil нам помог - включил оптимизацию уровень 0. Ахренительная оптимизация! При этом глобально объявленные переменные, не видны в вотч листе - допустим тупо на регистрацию реализовал, но показать мне привязку к нужному регистру Keil не смог?! Гениально! Но почему результата нет в светодиоде?! Все просто - ставим оптимизацию на default и о чудо, светодиод мигает как надо и переменные появились в watch листе. Вывод: какие-то "умные" дяди выдумали далёкие галактики и абстракции и теперь тупо давят всех авторитетом и в их коде Херсон поймёшь, что они сами-то хотели сказать - непонятный многостраничный говнокод, но машина на хромой козе реализуют как-то функционал пожирая ресурсы и всех всё устраивает! Вот такие чудеса. А с микроконтроллерам все их концепции ещё хуже работают, но все верят в их авторитет... Если бы язык давал возможность описывать концерт задачи и давал выбрать вариант реализации и способ/тип оптимизации на выбор создателя, то можно было бы говорить, что это правильный помощник, который вместо тебя написал корректный код и корректно оптимизировал. Что даже бы простейшая задача помигать светодиодом сводилась бы к простому описанию циклического сигнала с известным источником управляющего переменной/переменных и с указанием выходным пином, среда разработки предложила бы все варианты и критерии выбора, по факту от тупого delay, до прерываний на SysTick, на таймере, на DMA, использовать ли bit bang, а так же все варианты использования ассемблерных команд и регистров R0 -R13 и т.д. Берём SPI и тоже выбираем нужный нам оптимальный вариант реализации и т.д. Также выбираем нужный нам тип мультизадачности от простой до всяких там заумных RTOS, которые только и умеют задрачивать стек (наверно и ещё что-то). Поэтому я за понимание ассемблерных команд, за возможность выбора из всех возможных вариантов реализаций прописаной мною концепций алгоритма. А пока... а пока мы имеем простой факт - вся супер производитеность современных МК компенсирует неуклюжесть и неэффективность средств разработки... Всякие С×× лабают абстракции, ОС предлагают паровоз, а ассемблерщики ковыряются в командах АЛУ - разброд и шатания, и никакой ИИ им всем не поможет ..... Может начать с начала и признаться себе в правде жизни, до чего докатились?! Может начать с ассемблера и создания прокси языка, который будет в стиле Python прост и нагляден, который позволит генерировать любой желаемый ассемблерный код, который будет позволять увидеть все варианты реализации простых блоков?! А уж потом будем прижумывать всякие галактики и абстракции?!

[@fnhm_]

С ЯЗЫКА БУКВАЛЬНО СНЯЛ. Я сам некоторое время назад пытался бороться с фреймворком Arduino и писать свой, но там проблема с самим avr-gcc. В итоге решил перейти полностью на STM. Если ты читаешь комменты, то ответь, пожалуйста, есть ли нормальные фреймворки для STM по типу как ты рассмотрел в видео? Очень хочется верить, что такие варианты есть. P.s. Очень классное видео, спасибо, подписался

[@donrumata5299]

Да, комменты читаю) Ну, во-первых, выбор сужается тем, что просто удобная библиотека - это ещё не фреймворк.. Самый очевидный вариант - это, собственно HAL от ST, который интегрируется с STM Cube, он генерирует код инициализации периферии. В чём-то это удобно, но мне не нравится сама идея генерации кода, особенно - когда тебе говорят, где нужно писать код, чтобы он не стёрся при первой перегенерации кода инициализации кубом… Есть ещё вариант использовать то же Ардуино, но на STM32... Ну и ещё есть ОС реального времени, например, FreeRTOS, которая распределяет задачи..

[@mega_mak]

Ничего непонятно, но очень интересно. Ну наконец-то это не то видео где: "Мы в этом видео не будим углубляется в математическую структуру, а просто расскажем вам...". ЛУКАС!

[@ПавелЛобанов-ж3и]

Здравствуйте! Большое спасибо за ваши видеоуроки! Если данная тема ещё не заброшена, можете сделать видео по настройке ЦАП?

[@donrumata5299]

Тема не заброшена, занимаюсь этим на учебной практике…) Но времени сейчас катастрофически мало - «потом» - наверняка будет и про ЦАП…

[@ПавелЛобанов-ж3и]

@@donrumata5299 а у вас, случайно, нет методички, которая помогла бы разобраться самостоятельно? Заранее благодарен!

[@donrumata5299]

​@@ПавелЛобанов-ж3и Уффф… Ну, могу предложить разве что Reference Manual…) DAC всё-таки проще, чем ADC - верю, что разберётесь, удачи!

[@ПавелЛобанов-ж3и]

@@donrumata5299 деваться некуда, попробую)

[@liliansirbu840]

а как совместим стиль написания на регистровом уровне в CMSIS и с высокой абстрациеи яоо как С++? нужно конкретные уроки/примеры увидить что и как

[@donrumata5299]

Вопрос действительно интересный, особенно - когда нужно не просто запрограммировать конкретное устройство, а ещё и унифицировать интерфейс, чтобы потом писать абстрактный и, соответственно, переносимый и красивый код. Планирую сделать видео о чём-то подобном, но - сюрприз - не на С++, а на Rust: там ребята действительно красивый код продвигают)

[@sledleo]

@@donrumata5299 Автор, продолжения не будет?! Ясно! У меня банальный вопрос, кто-нибудь заглядывал в команды поддерживаемые ARM процессором в чипах STM32? То есть те самые ассемблерные команды и работота на уровне регистров. Может кто-то мне объяснит почему бытовых операций нет в Си? И как он (Си компилятор) может догадаться что собственно мы хотим сотворить? Может он сам может понять что мы хотим изменить биты, которые имеют отображение в bit bang адресах, он может? И так далее... Простой пример, пишем мигалку светодиодом на CMSIS в Keil компилим и смотрим на результат - светодиод как-то странно тускло мерцает, но в алгоритме зашито постепенно изменение частоты туда-сюда. Где результат?! А все просто, по умолчанию при создании проекта Keil нам помог - включил оптимизацию уровень 0. Ахренительная оптимизация! При этом глобально объявленные переменные, не видны в вотч листе - допустим тупо на регистрацию реализовал, но показать мне привязку к нужному регистру Keil не смог?! Гениально! Но почему результата нет в светодиоде?! Все просто - ставим оптимизацию на default и о чудо, светодиод мигает как надо и переменные появились в watch листе. Вывод: какие-то "умные" дяди выдумали далёкие галактики и абстракции и теперь тупо давят всех авторитетом и в их коде Херсон поймёшь, что они сами-то хотели сказать - непонятный многостраничный говнокод, но машина на хромой козе реализуют как-то функционал пожирая ресурсы и всех всё устраивает! Вот такие чудеса. А с микроконтроллерам все их концепции ещё хуже работают, но все верят в их авторитет... Если бы язык давал возможность описывать концерт задачи и давал выбрать вариант реализации и способ/тип оптимизации на выбор создателя, то можно было бы говорить, что это правильный помощник, который вместо тебя написал корректный код и корректно оптимизировал. Что даже бы простейшая задача помигать светодиодом сводилась бы к простому описанию циклического сигнала с известным источником управляющего переменной/переменных и с указанием выходным пином, среда разработки предложила бы все варианты и критерии выбора, по факту от тупого delay, до прерываний на SysTick, на таймере, на DMA, использовать ли bit bang, а так же все варианты использования ассемблерных команд и регистров R0 -R13 и т.д. Берём SPI и тоже выбираем нужный нам оптимальный вариант реализации и т.д. Также выбираем нужный нам тип мультизадачности от простой до всяких там заумных RTOS, которые только и умеют задрачивать стек (наверно и ещё что-то). Поэтому я за понимание ассемблерных команд, за возможность выбора из всех возможных вариантов реализаций прописаной мною концепций алгоритма. А пока... а пока мы имеем простой факт - вся супер производитеность современных МК компенсирует неуклюжесть и неэффективность средств разработки... Всякие С×× лабают абстракции, ОС предлагают паровоз, а ассемблерщики ковыряются в командах АЛУ - разброд и шатания, и никакой ИИ им всем не поможет ..... Может начать с начала и признаться себе в правде жизни, до чего докатились?! Может начать с ассемблера и создания прокси языка, который будет в стиле Python прост и нагляден, который позволит генерировать любой желаемый ассемблерный код, который будет позволять увидеть все варианты реализации простых блоков?! А уж потом будем прижумывать всякие галактики и абстракции?!

[@igorying8548]

Thanks! But, where is the next lesson?

[@donrumata5299]

I hope, I'll manage to find a couple of days in this summer for video production after exams...

[@everythingabout6066]

Добрый день, вы имеете возможность дать частные уроки ?

[@donrumata5299]

Добрый. Прямо уроки? Могу консультацию, возможно, но на уроки прям времени маловато: график очень загруженный

[@everythingabout6066]

@@donrumata5299 можно попробовать консультацию, я немного запутался в своей программе обучения)) как вам удобно связаться ?

[@donrumata5299]

@@everythingabout6066 А какие у вас примерно знания по теме, что примерно планируете изучить и с какой целью (по работе/учёбе/для себя)?

[@everythingabout6066]

@@donrumata5299 для работы, нужно писать код для STM32F407, пытаюсь учить что попадется, английский не знаю, только некоторые технические термины, по практике работал пока только с чистым Си и 8 разрядными индикаторами, я писал вам на почту.

[@mikitashary5552]

Доброго дня, не нашел как написать вам в лс, поэтому тут. Может у вас есть пример кода работы с i2c на чистом cmsis, именно интересует прием отправка пакетов, хотя бы с мало мальскими комментариями

[@donrumata5299]

К сожалению, именно I2C и нету... Но я скоро буду разбираться с USB, думаю, заодно и с ним могу. Вероятно, там комментарии сами придут через названия функций и т.д... В теории. Вообще рекомендую при существующем неработающем коде на CMSIS просто потихоньку его скрещивать с работающим кодом на SPL, например. Очень помогает найти ошибку..

[@nicolascage4670]

Интересное видео, по c++ для микроконтроллеров очень мало информации, продолжай в том же духе! О какой IDE будет идти речь в следующем видео?

[@donrumata5299]

Думаю, о CLion

[@nicolascage4670]

don Rumata а с каким компилятором?

[@donrumata5299]

@@nicolascage4670 от gnu для arm, gcc-none-eabi называется, кажется

[@ДмитрийНормов-ю6ц]

@@donrumata5299 инфы по программированию low level на С++ вообще практически нет....

[@alankuzhev8242]

0:56 для RCC вы выбрали использовать макроопределения, а для всего остального воткнули магичекие числа, хм.. Далее выбрали устаревшую(!!) StdPeriph(?! почему не LL раз пином дрыгать только решили) и далее 1:11 "я хочу чтоб було так" ну заверните в си указатели на функции в структуры и typedef enum обмажтесь и будет так

[@donrumata5299]

Ну, тут весьма субъективно (хотя магических чисел там как раз не было - 1, 2 и 12 - фундаментальные константы и номер пина, но код, разумеется крайне «шумный»). И самая большая проблема такого сравнения в том, что библиотеки признают негодными не из-за некрасивости интерфейса, а из-за неспособности решать сложные задачи, которые можно только словесно описать, но не продемонстрировать кодом в маленьком видео. Но использование стиля плюсов для периферии хорошо просто за счёт того, что весь код на нём написан, и удобнее соединять

[@vladsol5575]

продолжение то будет или все зависло из-за сложности С++ ?

[@donrumata5299]

Всё зависло из-за учёбы... привычный мне С++ то как раз только упрощает работу.. учу rust, кстати. Добро пожаловаь на мой гитхаб)

[@SmD_Amir_]

видео прикольное, но музыка на фоне слишком громкая)

[@donrumata5299]

Ага, уже учтено.

[@sledleo]

@don Rumata Автор, продолжения не будет?! Ясно! У меня банальный вопрос, кто-нибудь заглядывал в команды поддерживаемые ARM процессором в чипах STM32? То есть те самые ассемблерные команды и работота на уровне регистров. Может кто-то мне объяснит почему бытовых операций нет в Си? И как он (Си компилятор) может догадаться что собственно мы хотим сотворить? Может он сам может понять что мы хотим изменить биты, которые имеют отображение в bit bang адресах, он может? И так далее... Простой пример, пишем мигалку светодиодом на CMSIS в Keil компилим и смотрим на результат - светодиод как-то странно тускло мерцает, но в алгоритме зашито постепенно изменение частоты туда-сюда. Где результат?! А все просто, по умолчанию при создании проекта Keil нам помог - включил оптимизацию уровень 0. Ахренительная оптимизация! При этом глобально объявленные переменные, не видны в вотч листе - допустим тупо на регистрацию реализовал, но показать мне привязку к нужному регистру Keil не смог?! Гениально! Но почему результата нет в светодиоде?! Все просто - ставим оптимизацию на default и о чудо, светодиод мигает как надо и переменные появились в watch листе. Вывод: какие-то "умные" дяди выдумали далёкие галактики и абстракции и теперь тупо давят всех авторитетом и в их коде Херсон поймёшь, что они сами-то хотели сказать - непонятный многостраничный говнокод, но машина на хромой козе реализуют как-то функционал пожирая ресурсы и всех всё устраивает! Вот такие чудеса. А с микроконтроллерам все их концепции ещё хуже работают, но все верят в их авторитет... Если бы язык давал возможность описывать концерт задачи и давал выбрать вариант реализации и способ/тип оптимизации на выбор создателя, то можно было бы говорить, что это правильный помощник, который вместо тебя написал корректный код и корректно оптимизировал. Что даже бы простейшая задача помигать светодиодом сводилась бы к простому описанию циклического сигнала с известным источником управляющего переменной/переменных и с указанием выходным пином, среда разработки предложила бы все варианты и критерии выбора, по факту от тупого delay, до прерываний на SysTick, на таймере, на DMA, использовать ли bit bang, а так же все варианты использования ассемблерных команд и регистров R0 -R13 и т.д. Берём SPI и тоже выбираем нужный нам оптимальный вариант реализации и т.д. Также выбираем нужный нам тип мультизадачности от простой до всяких там заумных RTOS, которые только и умеют задрачивать стек (наверно и ещё что-то). Поэтому я за понимание ассемблерных команд, за возможность выбора из всех возможных вариантов реализаций прописаной мною концепций алгоритма. А пока... а пока мы имеем простой факт - вся супер производитеность современных МК компенсирует неуклюжесть и неэффективность средств разработки... Всякие С×× лабают абстракции, ОС предлагают паровоз, а ассемблерщики ковыряются в командах АЛУ - разброд и шатания, и никакой ИИ им всем не поможет ..... Может начать с начала и признаться себе в правде жизни, до чего докатились?! Может начать с ассемблера и создания прокси языка, который будет в стиле Python прост и нагляден, который позволит генерировать любой желаемый ассемблерный код, который будет позволять увидеть все варианты реализации простых блоков?! А уж потом будем прижумывать всякие галактики и абстракции?!

[@donrumata5299]

Так… По порядку - Насчёт продолжения: сейчас у меня напряжённый график с учёбой и стажировками, когда будет больше свободного времени - надеюсь, сделаю ещё - Почему в Keil по умолчанию включен режим оптимизации «-O0», и при нём не видны какие-то переменные/константы? В С++ принято иметь два основных варианта сборки (не считая всяких санитайзеров, профайлеров): Debug и Release. В первой нет никаких оптимизаций, оно работает существенно медленнее (иногда - раз в 100), чем Release. Идея C++ в т.н. zero cost abstractions: можно добавить абстракции, чтобы сократить/упростить пользовательский код, и при этом СКОРОСТЬ В RELEASE остаётся такой же. С другой стороны, если требуется отладка, следует выбрать Debug (который «без оптимизаций, с отладочными символами»). Важно, что оптимизации работают на уровне абстрактной машины C++, конкретно к контроллеру и его ножкам, сведодиодам это не имеет никакого отношения. Например, оно может разделить на константу, известную во время компиляции, быстрее банальной операции деления. - Почему нет такой глубокой интеграции, чтобы можно было, например, выбрать в IDE вариант мигания светодиодом? Во-первых, есть. Это stm32Cube (Хотя не до такой карикатурной степени). Плюс есть ещё куча всяких игрушек по типу Arduino. Во-вторых, у такого подхода есть масса ограничений. Люди неспроста программируют на текстовых языках программирования, а не на детских блоках - это самый эффективный способ записать алгоритм. Мы должны понимать, что мигание светодиодом по конкретному закону - это одно из гигантского количества применений контроллера. То, какое нужно в данном случае - выбирается с помощью программы - «С++ - это снежный ком» - популярная идея, имеющая под собой основание. Поэтому существует новый язык Rust, который должен занять нишу С++ (высокая производительность, близость к железу, zero-cost-abstractions(, но при этом безопасно) ), и проработан с учётом всех недостатков плюсов. На нём тоже можно программировать микроконтроллеры, и об этом я обязательно расскажу в одном из следующих видео.

[@slavaglow6933]

Спасибо за освещение темы C++ для микроконтроллеров, эта тема для меня не розкрыта. Что можете посоветовать почитать или в каком направлении двигаться в изучении C++ для микроконтроллеров?

[@donrumata5299]

Ну, во-первых, нужно знать С++ на достаточном уровне, а потом - либо пользоваться той библиотекой stm32plus, либо писать свою, руководствуясь даташитами и уроками на Си. Всё ограничено только воображением пишущего код

[@wastegate711]

писать код в студии это очень удобно, но как насчет отладки?

[@donrumata5299]

Да, в СLion гораздо круче, теперь его использую) Не только в Keil есть отладка, но и в CLion и даже в студии. Проблема у студии (по сравнению с CLion, конечно) скорее в удобстве написания кода, в её умности, Build системе (CMake - лчший) и т.д.

[@BalabayUA]

Я бы не стал вязать плюсы к инициализации/работе с железом. В серьезных проектах железо занимает малую часть кода и с этим вполне справляется С без классов.

[@donrumata5299]

Хм, но обычно «серьёзную работу» же можно перенести на комп, а контроллер будет чисто работать с железом и немного предобрабатывать (на моей практике, по крайней мере, проекты не слишком серьёзные, конечно…). Тут не только плюсы, а ещё и Rust прикрутить можно, где пытаются сделать действительно работающие абстракции над железом, а не эти ваши SPL и ST Hal…

[@BalabayUA]

Ваша позиция кажется понятна. Но к примеру, в моем проекте периферия отдана HAL + Cube IDE. Что не может делать HAL, сделал опустившись на уровень CMSIS. На отладку железа ушёл один день, отладил, работает и забыл. А вот остальное время уходит на вникание в чужие библиотеки (типа FatFs. TCP/IP + MQTT...) + алгоритмы и код...много кода. Код который очень далёк от железа. И вот тут иногда хочется подключить возможности Си плюсов, но лень делать прокладки между кодом С и С++. Я к тому, что оправданы ли затраты времени замены HAL на прокладку "как в Ардуоно". У STM32 сложная периферия, чтобы охватить всё под все семейства нужна большая команда индийских программистов.

[@donrumata5299]

​@@BalabayUA Ууу, ну, если система с файловой системой и сетью, тут дело серьёзное…) > прокладки между кодом С и С++ А какие там прокладки? Компилим всё компилятором плюсов. Если там появляются интерфейсы не в стиле идиоматических плюсов, очень жаль, живём с ними, но их очень мало. По поводу проколадки «в стиле Ардуино» - со своей ангажированной колокольни позволю себе сказать, что это скорее CMSIS или SPL, а не условный github.com/rust-embedded/embedded-hal - «как в Ардуино». В Ардуино делается ставка на простоту, а в нормальном HAL - на абстракции. Абстрактный код ≠ тривиальный. Но это то, каким программирование должно быть. А насчёт моей попытки сделать библиотеку для C++ - да, весьма амбициозно и - да, тут скорее потребовалась бы команда индийских разработчиков…) Но в определённый успех rust-embedded я верю

[@inBuff]

Музыку потише и норм было бы

[@Запискисамоучки]

в основной своей деятельности веб-программист (в первую очередь backend и php). Также очень быстро захотелось писать читабельный код. Но вот незадача. Нет нормальных библиотек под C++, даже IDE под него не могут сгенерить проект, приходится извращаться и допиливать ручками... на русском языке нашел только несколько хороших статей. Пару докладов... чую придется параллельно со своими проектами писать и библиотеку компонентов. Вот только это хобби и сколько это займет времени неясно :(

[@donrumata5299]

Ну есть библиотеки на Си, которые можно без проблем использовать для С++, есть stm32plus (github.com/andysworkshop/stm32plus), не сказать, что они нормальные, но если нет нормальных библиотек для С++, то для Си - тем более нет... Ну есть CMSIS, даташиты, мои видео)... "даже IDE под него не могут сгенерить проект"

[@CoBaldr]

Так блэт, где видео:)

[@CoBaldr]

Ах да про идеологию, я не топлю за си или сипипи, для себя я твердо решил что все что касается динамической памяти в МК=абсолютное зло, поэтому если сипипи то только как си с классами для удобства.

[@donrumata5299]

Ну как сказать, в c++ есть несравнимо больше вещей, не требующие динамической памяти, чем Вы думаете. Шаблоны, концепты, constexpr (очень круто для МК), stl, которая работает далеко не только с динамической памятью, так что если хорошо знать плюсы, можно получить с этого серьёзные дидвиденды

[@alexboycov7082]

Куда пропал?

[@lawrencecleanov9122]

учится он..

[@user77090]

Музыку делай еще громче.

[@donrumata5299]

Так точно, сэр.

[@alexorlovecky6662]

Никогда не понимал недовольства людей по поводу стандартных библиотек или о Боже хал... Они используются только при инициализации. Обработчики у всех давным давно написаны свои, без всяких непонятных проверок внутри.. Видео, как размешать воду в стакане. Кому реально нужен ООП, и так его давно использует. Уйти от кейла в стандартную среду разработки... удачи автору, потом на дебаге без 99% функционала заложенного для отладки арм ядер.

[@АлексейШевела-щ9н]

Кто с кем борется? Фоновая музыка с автором или автор пытается ее перекричать?!!!!!!!

[@user_PsevdonimyEtoPolnyjOtstoj]

Прошёл год...

[@tanixtx5298]

Музыка вот ваще не к кстати к обучалкам, еще и так громко

[@donrumata5299]

Согласен) Поэтому в новых видео (про Rust) - музыки нет

[@allex6829]

ересь, сядьте за комп и напиши 10 простеньких программ на Си для МК. Как таковой синтаксис ты не увидешь, это работа с документацией и встроенными регистрами. Назови их по твойму примеру и можно выбросить все на мусор.

[@donrumata5299]

Десять (и даже, разумеется, больше) простеньких программ для МК на Си я написал. И да, там действительно была по большей части работа с регистрами. Однако из этого факта никак не следует общее утверждение «Конкретный язык программирования для микроконтроллеров не важен, так что нужно писать на том, у чего порог входа меньше». - Во-первых, такая ситуация будет только в простых демонстрационных программах. В реальных проектов появляется логика, возможно, нетривиальная, которая может использовать самые разные средства языка. И да, в реальных проектах у меня это встречается. - Во-вторых, если иметь нормальные библиотеки, реализующие основную заявленную идею «абстрагирования от железа», и не придётся ручками постоянно тыкать регистры. Посмотрите, как HardwareAbstractionLayer реализован в Rust Embedded: docs.rust-embedded.org/book/portability/ (кстати, про него, скорее всего, будет следующее видео, но пока у меня очень много дел про институту и работе). А вот у STM щиков, пишущих очередной HAL руки явно не из того места растут…

[@allex6829]

@@donrumata5299 можешь удалить канал? сделайте в свободные минутки. Разработай микроконтроллер с нуля, попробуй записать в каждую яцейку памяти сигнал, напиши на нее документацию внятную а потом представь публике, и то не факт что им зайдет. А хотя подожди, если ты так рассуждаешь значит пишешь на Ардуино. вопросов больше нет. удаляй канал.

[@donrumata5299]

@@allex6829 Про канал и Ардуино, конечно, позабавило (нет, я не использую Ардуино). Но для остальных зрителей: Во-первых, претензии разработчикам hal, а не нижних уровней стека ст корпорейшн Во-вторых, я не просто критикую и не предлагаю какой-то мифический подход: он реализован и уже применяется в Rust, хотя приходится бороться с неоднородностью контроллеров

[@locky1827]

А что забросил то? Я тока начал смотреть и бац, все.

[@donrumata5299]

Понимаете ли, embedded программисты нынче на расхват - такие же горячие пирожки, как басисты, так что: Приходит парень брать уроки игры на бас-гитаре. На первом уроке преподаватель ему говорит: - Первая струна - это ми. Вот играй на ней так: бум-бум-бум. Иди занимайся, приходи через неделю. Тот приходит через неделю на второй урок. Преподаватель: - Вторая струна - это ля. Попробуй на ней: бам-бам-бам. Молодец. Приходи через неделю. Проходит неделя, вторая, ученик не приходит. Через некоторое время преподаватель случайно встречает его на улице: - Ну, где ты пропал? - Да вы знаете, просто некогда - записи в студии, гастроли... …но я собираюсь исправиться: возможно, уже этим летом будет контент про Embedded Rust :)