Рекомендации мне подкинули вас: по сегментам памяти и адресации очень хорошо рассказываете и картинки красивые. Главное что показываете примеры и линкер-скрипты. Мне в свое время пришлось все это осливать самому, сложно было найти откуда что берется.
Просто возьмите микроконтроллер с большим обьемом памяти. Ваше время не такое дешевое, чтобы тратить его на оптимизацию, говорили ОНИ. А потом следствие этого подхода - одна вкладка браузера занимает 1.5 гига.
я тут изучаю яваскрипт и понимаю, почему оно столько жрет оказывается в хтмл есть помимо тегов еще пробелы и знаки переноса строк кода так вот, это тоже объекты со свойствами так что надо оптимизировать даже хтмл код а еще нужно клепать сцайты под мобильные экраны, что тоже требует кучу атрибутов цсс фреймворка для того, чтобы сцайт выглядел тоже норм на вертикальном и горизонтальном экране так же у современного браузера очень много всяких апи типа доступ к батарейке, гпс, джойстикам, даже есть доступ к ком и усб портам
Спасибо, очень годный контент. Хоть я все это и знал, но ваш ролик в определённый период помог бы мне сэкономить очень много времени в разборе всего этого и хождения по граблям) монтаж, звук, картинка тоже все чётко!
Хотелось бы про DMA услышать и работу МК с внешней ОЗУ, понимаю, что на эту тему много информации в интернете, но у вас очень хорошо получается доходчиво, просто, и "на пальцах" объяснить суть происходящего
Здравствуйте! Спасибо за лекцию! Сейчас начал изучать и что-то пробовать на практике в ЦОС на ARM(STM32). Послушав эту лекцию, стало интересно, есть ли какие-либо подобные лайфхаки для работы с большими массивами, циклическими массивами для быстрых преобразований Фурье. Так же интересно было-бы услышать технологию прямого доступа к памяти (DMA), Вы здесь это упомянули лишь вскользь
@ жаль, эта тема самая ожидаемая, в целом если подымать эту тему чаще то можно не плохо забустить канал, а я даже мог бы донаты покидать если эта тема будет чаще подыматься
Дмитрий, спасибо огромное за очень полезный материал! 1. А что за чип на ардуинке в начале ролика между мегой и USB-UART конвертером? 2. Очень хотелось бы чтобы вы разобрали в подобном формате распределение времени для задач, например функцию millis(); изнутри со всеми ее атомарными операциями и программные таймеры на ее основе. Еще раз спасибо!
Спасибо за комментарий! 1) В оригинальной плате это микроконтроллер ATSAMD11D14A, который одновременно выступает софтовым com-портом и прошивает АТмегу. Но тут китайский клон и я так понимаю, что они тоже поставили какой-то МК, отвечающий за прошивку (внешний бутлоадер), а мост USB-UART сделали на 340-м чипе. Но я могу ошибаться. 2) Пока ничего такого не планировал, но спасибо за идею )
Очень крутые видеоролики!!! Подобного контента на русском языке очень мало, вы большой молодец! Целочисленные вычисления принято называть qformat, для операций над ними написано множество библиотек, например, dsp cmsis использует их для вычислений.
Приветствую, что с проектами блока питания и контроллера вентиляторов, очень интересные проекты, и на стыке технологий, тут и программирование и электроника, будет чего по ним, или это уже всё в прошлом?
Добрый день! По БП это Nich1con ведёт проект. Насколько я знаю, он сейчас очень загружен основной работой, поэтому сложно сказать когда будет продолжение. Но у него уже много наработок по этой теме. Прошивку контроллера пилю. В общем, 2 последних ролика и ещё один планирующийся родились как раз из работ по прошивке. В какой-то момент понял что нужен хороший задел на следующую версию, поэтому бОльшую часть кода переделал (и ещё переделываю). Скорее всего ролика не будет, а просто я выложу ссылку на код прошивки в телеге/на бусти. Может ещё продублирую сюда в сообщество.
@@DmitryMuravyevбуквально на днях закончил аппаратный контроллер на 31 вентилятор для охлаждения коммуникационых рэков. Но не на контролере, а на плис. И это была работа, целиком представляющая из себя одну огромную оптимизацию. Потому что у нас двно эти ядра в ходу, но это были контроллеры на 2-4 вента. Когда пнадобился на 31, оказалось, что плиски не хватает 4-кратно! Благодаря проведëнной оптимизации контроллер на N вентиляторов занял 40% плисины с потнциалом до 300 вентиляторов всë в той же самой плисине, а если добавить внешнюю RAM, потенциал ограничен только количеством свободных ног на адресацию. Тупое программироание в лоб - это прямой путь к альцгеймеру и пустому вращению капитала, разоряющему конечного пользователя.
Пока только для C# ну и первый пример я в нём разбираю, но компилировал руками. Недавно решился рабочий ноут на Кубунту перевести, пока ещё осваиваюсь ))
Мне оказались интернсны продвинутые макросы по progmem. Интересно узнать еще за области памяти и как ими я могу воспользоваться. Еще было бы круто исполнять код из оперативной памяти, пару моих проектов ожили бы.
42:51 -- тут как минимум двоекратное UB (неопределённое поведение): 1. на 93 строке кода -- запись в память, которая не принадлежит тебе 2. на 92 строке кода -- с чего взято, что "p" будет имено в нужном расположении в адресном пространстве (мапинг может произойти как угодно в любую точку адресного пространства исполняемого кода)? И неизвестно что вообще будет когда заполнение дойдёт до самой перменной "p" когда будет затирать "магическими данными" непринадлежащую тебе память.
а если взять затирание многобитными значениями -- то вообще достаточно легко перезатрёт и initialTopStack... Вообще конечно когда UB в коде размышлять про такое не имеет смысла -- что произойдёт на самом деле -- но пофантазировать можно )))
1. Это пример для AVR (даже не для megaTinyCore). Тут ничего никуда не мапится, нет RTOS, так что могу позволить себе некоторые вольности. Чуть подробнее (для STM) вот в этой статье можно почитать: habr.com/ru/articles/443030/ 2. Да, было опасение, что "p" будет не в топе стека. Но, нет, всё норм, она в топе. InitialTopStack вообще в bss, т.е. под кучей. И под другими переменными. Для слов/двойных слов, понятно, надо будет делать "зазор" на доп. байты в условиях.
@@DmitryMuravyev для с++ нет разницы -- какая архитектура -- есть UB и компилятора не должно волновать остальное другое -- тоесть даже компилятор может сделать программу вполне себе как ему вздумается в таком случае.
@@DmitryMuravyev в примере на хабре тоже UB -- не стоит копировать такое и распространять под видом действенного -- оно работает скорее всего поскольку компилятор так решил в тот конкретный момент -- любые изменения в настройках компилятора, версии компилятора, чего либо еще могут координально изменить программу. Формально с точки зрения языка программирования тут UB -- дальнейшие размышления тупо потрындеть -- они не имеют никакого смысла
Сам по себе компилятор упарываться в оптимизацию с понижением точности вычислений не будет. Т.е. в любом случае все вычисления, само-собой, сведутся к целочисленным. По этому поводу есть хорошая серия роликов вот тут: www.youtube.com/@%D0%91%D0%B5%D1%81%D0%B5%D0%B4%D1%8B%D0%BE%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B8-%D0%B45%D0%B6/videos Там больше про длинную арифметику, но получить обзорное представление о теоремах и методах вполне себе можно (кстати, этот чувак сейчас коуч по успешному успеху... а хотел ведь заниматься математикой и программированием. Вот что делает с людьми нехватка лайков и подписчиков))). Т.е. у меня речь идёт о преднамеренном загрублении точности в пользу объёма кода. Можно ключами компилятора отчасти добиться такого же эффекта. Например, при помощи ключа -ffast-math. Результаты в случае с моим примером такие (по объёму получившегося бинарника): float: 3662 float (ffast-math): 3336 uint16_t: 2504 Вполне допускаю, что на свежих версиях GCC результаты будут получше, надо проверять. Если знаете какими ещё ключами можно (при прочих равных) загрубить работу с float и получить меньший объём кода - напишите, буду очень благодарен! Вот ещё свежая переводная статейка на тему: habr.com/ru/articles/868600/ Там о GCC вообще не очень лестно отзываются. А в остальном, да, разумеется, компилятор при возможности заменит деление умножением на обратную величину.
Вашими бы устами, да полноценный курс по микроконтроллерам!..
Очень удачно зашёл, а тут такое поучительное видео.
Раз 5 придётся смотреть)
очередная полезная инфа)
Прекрасно! Это просто прекрасно! Огромное вам спасибо😊
Рекомендации мне подкинули вас: по сегментам памяти и адресации очень хорошо рассказываете и картинки красивые. Главное что показываете примеры и линкер-скрипты. Мне в свое время пришлось все это осливать самому, сложно было найти откуда что берется.
Оптимизация всегда полезный контент, ждем новых видосов
Бесценный урок! Благодарю!
Про работу кучи полезно и подробно, это хорошо.
Супер, моё любимое кодокопательство. Правда я люблю ассемблер.
Спасибо за хорошо изложенную информацию. Давно хотелось изучить тему, но как-то всё разрозненно было, а тут всё в одном)
Просто возьмите микроконтроллер с большим обьемом памяти. Ваше время не такое дешевое, чтобы тратить его на оптимизацию, говорили ОНИ.
А потом следствие этого подхода - одна вкладка браузера занимает 1.5 гига.
я тут изучаю яваскрипт и понимаю, почему оно столько жрет
оказывается в хтмл есть помимо тегов еще пробелы и знаки переноса строк кода
так вот, это тоже объекты со свойствами
так что надо оптимизировать даже хтмл код
а еще нужно клепать сцайты под мобильные экраны, что тоже требует кучу атрибутов цсс фреймворка для того, чтобы сцайт выглядел тоже норм на вертикальном и горизонтальном экране
так же у современного браузера очень много всяких апи типа доступ к батарейке, гпс, джойстикам, даже есть доступ к ком и усб портам
Годный контент
Спасибо, очень годный контент. Хоть я все это и знал, но ваш ролик в определённый период помог бы мне сэкономить очень много времени в разборе всего этого и хождения по граблям) монтаж, звук, картинка тоже все чётко!
Спасибо большое за видео! Не смотря на то, что длительность видоса почти час, просмотрел все на одном дыхании! Очень полезно и содержательно!
Классно видеть что в ру сигменте выпускают такие классные и познавательные и главное свежие ролики
ты очень крут, на хорошем уровне все сделано, и графика и содержание
Спасибо, стараюсь! )
@DmitryMuravyev записывайте ещё!
Спасибо. !!!
Узнал много полезного.
Спасибо за видео. 👍 Особенно понравилось окончание про float
Хотелось бы про DMA услышать и работу МК с внешней ОЗУ, понимаю, что на эту тему много информации в интернете, но у вас очень хорошо получается доходчиво, просто, и "на пальцах" объяснить суть происходящего
Да, про DMA уже многие просят. Запишу себе в заметки "на подумать". Спасибо.
@DmitryMuravyev вас спасибо!
Chatgpt вам в помощь. Спасибо вселенной что родарила людям ai.
Супер, спасибо!
Здравствуйте! Спасибо за лекцию!
Сейчас начал изучать и что-то пробовать на практике в ЦОС на ARM(STM32). Послушав эту лекцию, стало интересно, есть ли какие-либо подобные лайфхаки для работы с большими массивами, циклическими массивами для быстрых преобразований Фурье. Так же интересно было-бы услышать технологию прямого доступа к памяти (DMA), Вы здесь это упомянули лишь вскользь
Спасибо. Очень полезная информация
Скоро ли продолжения темы рика хартли?
По плану через 3 ролика. Но я теперь даже приблизительные даты выхода не ставлю себе. Сейчас очень сложно что-либо планировать...
@ жаль, эта тема самая ожидаемая, в целом если подымать эту тему чаще то можно не плохо забустить канал, а я даже мог бы донаты покидать если эта тема будет чаще подыматься
Спасибо. Скачал, пригодиться когда интернет по талонам будет)))
Ох, отличный лектор. Отличная лекция.
Топ контент!!!❤❤❤
Видос огонь!
Дмитрий, спасибо огромное за очень полезный материал!
1. А что за чип на ардуинке в начале ролика между мегой и USB-UART конвертером?
2. Очень хотелось бы чтобы вы разобрали в подобном формате распределение времени для задач, например функцию millis(); изнутри со всеми ее атомарными операциями и программные таймеры на ее основе.
Еще раз спасибо!
Спасибо за комментарий!
1) В оригинальной плате это микроконтроллер ATSAMD11D14A, который одновременно выступает софтовым com-портом и прошивает АТмегу. Но тут китайский клон и я так понимаю, что они тоже поставили какой-то МК, отвечающий за прошивку (внешний бутлоадер), а мост USB-UART сделали на 340-м чипе. Но я могу ошибаться.
2) Пока ничего такого не планировал, но спасибо за идею )
Очень крутые видеоролики!!! Подобного контента на русском языке очень мало, вы большой молодец! Целочисленные вычисления принято называть qformat, для операций над ними написано множество библиотек, например, dsp cmsis использует их для вычислений.
Приветствую, что с проектами блока питания и контроллера вентиляторов, очень интересные проекты, и на стыке технологий, тут и программирование и электроника, будет чего по ним, или это уже всё в прошлом?
Добрый день! По БП это Nich1con ведёт проект. Насколько я знаю, он сейчас очень загружен основной работой, поэтому сложно сказать когда будет продолжение. Но у него уже много наработок по этой теме.
Прошивку контроллера пилю. В общем, 2 последних ролика и ещё один планирующийся родились как раз из работ по прошивке. В какой-то момент понял что нужен хороший задел на следующую версию, поэтому бОльшую часть кода переделал (и ещё переделываю). Скорее всего ролика не будет, а просто я выложу ссылку на код прошивки в телеге/на бусти. Может ещё продублирую сюда в сообщество.
@@DmitryMuravyev Спасибо, значит есть надежда на продолжение.
А прошивка на 6 канальный контроллер вентиляторов будет?
Да!
@@DmitryMuravyevбуквально на днях закончил аппаратный контроллер на 31 вентилятор для охлаждения коммуникационых рэков. Но не на контролере, а на плис. И это была работа, целиком представляющая из себя одну огромную оптимизацию. Потому что у нас двно эти ядра в ходу, но это были контроллеры на 2-4 вента. Когда пнадобился на 31, оказалось, что плиски не хватает 4-кратно!
Благодаря проведëнной оптимизации контроллер на N вентиляторов занял 40% плисины с потнциалом до 300 вентиляторов всë в той же самой плисине, а если добавить внешнюю RAM, потенциал ограничен только количеством свободных ног на адресацию.
Тупое программироание в лоб - это прямой путь к альцгеймеру и пустому вращению капитала, разоряющему конечного пользователя.
а vscode не пробоали под линукс? вот думаю чем бы платный clion заменить
Пока только для C# ну и первый пример я в нём разбираю, но компилировал руками. Недавно решился рабочий ноут на Кубунту перевести, пока ещё осваиваюсь ))
Мне оказались интернсны продвинутые макросы по progmem. Интересно узнать еще за области памяти и как ими я могу воспользоваться. Еще было бы круто исполнять код из оперативной памяти, пару моих проектов ожили бы.
У гайвера есть статья на сайте про оптимизацию кода и эти битовые сдвиги, стоило упомянуть
Не попадалась мне. Я только его статью о progmem видел. Ссылку в описании оставил.
так уже компиляторы сами преобразуют деление в сдвиги. и разницы в коде нету)
Интересно, а если фиксточку через класс и перегрузку операторов сделать. Или нетипизированные шаблоны на крестах изваять.
42:51 -- тут как минимум двоекратное UB (неопределённое поведение):
1. на 93 строке кода -- запись в память, которая не принадлежит тебе
2. на 92 строке кода -- с чего взято, что "p" будет имено в нужном расположении в адресном пространстве (мапинг может произойти как угодно в любую точку адресного пространства исполняемого кода)? И неизвестно что вообще будет когда заполнение дойдёт до самой перменной "p" когда будет затирать "магическими данными" непринадлежащую тебе память.
а если взять затирание многобитными значениями -- то вообще достаточно легко перезатрёт и initialTopStack...
Вообще конечно когда UB в коде размышлять про такое не имеет смысла -- что произойдёт на самом деле -- но пофантазировать можно )))
1. Это пример для AVR (даже не для megaTinyCore). Тут ничего никуда не мапится, нет RTOS, так что могу позволить себе некоторые вольности. Чуть подробнее (для STM) вот в этой статье можно почитать: habr.com/ru/articles/443030/
2. Да, было опасение, что "p" будет не в топе стека. Но, нет, всё норм, она в топе. InitialTopStack вообще в bss, т.е. под кучей. И под другими переменными. Для слов/двойных слов, понятно, надо будет делать "зазор" на доп. байты в условиях.
@@DmitryMuravyev для с++ нет разницы -- какая архитектура -- есть UB и компилятора не должно волновать остальное другое -- тоесть даже компилятор может сделать программу вполне себе как ему вздумается в таком случае.
сейчас это может работать -- завтра нет...
@@DmitryMuravyev в примере на хабре тоже UB -- не стоит копировать такое и распространять под видом действенного -- оно работает скорее всего поскольку компилятор так решил в тот конкретный момент -- любые изменения в настройках компилятора, версии компилятора, чего либо еще могут координально изменить программу. Формально с точки зрения языка программирования тут UB -- дальнейшие размышления тупо потрындеть -- они не имеют никакого смысла
Норм концентрат)
Смешно сначала говорить про АВР и Ардуину а потом сетовать что ARM Cortex-M0 «старый».
специально просто хочет навредить новичкам, чтобы уменьшить их эффективность труда
@@nRADRUSкакая эффективность труда? новички не должны трудиться, они в песке пусть нормальным практикам обучаются.
С достаточной точностью Пи можно вычислить как 22/7
Тут основная мысль в том, чтобы делитель был степенью двойки. Тогда можно делить сдвигом вправо.
47:00 Пожалуйста не делайте так, современные компиляторы прекрасно умеют делить на константу, используя почти те же приемы.
а компилятор дает такие гарантии вообще?
Сам по себе компилятор упарываться в оптимизацию с понижением точности вычислений не будет. Т.е. в любом случае все вычисления, само-собой, сведутся к целочисленным. По этому поводу есть хорошая серия роликов вот тут: www.youtube.com/@%D0%91%D0%B5%D1%81%D0%B5%D0%B4%D1%8B%D0%BE%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B8-%D0%B45%D0%B6/videos
Там больше про длинную арифметику, но получить обзорное представление о теоремах и методах вполне себе можно (кстати, этот чувак сейчас коуч по успешному успеху... а хотел ведь заниматься математикой и программированием. Вот что делает с людьми нехватка лайков и подписчиков))).
Т.е. у меня речь идёт о преднамеренном загрублении точности в пользу объёма кода. Можно ключами компилятора отчасти добиться такого же эффекта. Например, при помощи ключа -ffast-math. Результаты в случае с моим примером такие (по объёму получившегося бинарника):
float: 3662
float (ffast-math): 3336
uint16_t: 2504
Вполне допускаю, что на свежих версиях GCC результаты будут получше, надо проверять. Если знаете какими ещё ключами можно (при прочих равных) загрубить работу с float и получить меньший объём кода - напишите, буду очень благодарен!
Вот ещё свежая переводная статейка на тему: habr.com/ru/articles/868600/
Там о GCC вообще не очень лестно отзываются.
А в остальном, да, разумеется, компилятор при возможности заменит деление умножением на обратную величину.