[Forger 17]

22 minutes ago, Arlleex said:

Еще страшнее, когда он летит коту под хвост из-за того, что весь проект ты когда-то решил написать пока что еще не до конца освоенными подходами в программировании))

Вот именно поэтому выше я и спросил коллегу, а делал ли он замеры в цифрах результатов своего нового "подхода" ))

 

[std 6]

В 18.09.2023 в 23:00, Forger сказал:

Я вот сторонник нафик убрать из  прерываний все что можно по максимуму, как советуют гуру в своих книгах. Мне эта мысль кажется логичной.

Не припомните, что за книга/книги?

[Forger 17]

7 minutes ago, std said:

Не припомните, что за книга/книги?

Увы, не помню   ((

но вот по поиску за пару минут наткнулся на такие материалы:

https://web.engr.oregonstate.edu/~traylor/ece473/pdfs/minimize_interrupt_response_time.pdf

https://www.beningo.com/3-tips-for-speeding-up-interrupt-handlers/

А вообще минимизация времени нахождения в прерывании, как и минимизация накладных расходов на их обслуживание - кмк одно из самых важных правил оптимизации кода и проекта в целом.

[x893 35]

1 minute ago, Forger said:

А вообще минимизация времени нахождения в прерывании, как и минимизация накладных расходов на их обслуживание

Если в цикле __NOP или __WFI - есть разница по времени входа в прерывании ? Может кто мерял.

[std 6]

3 часа назад, Forger сказал:

Увы, не помню   ((

но вот по поиску за пару минут наткнулся на такие материалы:

https://web.engr.oregonstate.edu/~traylor/ece473/pdfs/minimize_interrupt_response_time.pdf

https://www.beningo.com/3-tips-for-speeding-up-interrupt-handlers/

А вообще минимизация времени нахождения в прерывании, как и минимизация накладных расходов на их обслуживание - кмк одно из самых важных правил оптимизации кода и проекта в целом.

Спасибо. Мне не этот вопрос интересен, есть интерес почитать волшебные книги реальных гуру. Я уже размечтался. 😃

От себя скажу, схема с выставлением булевого или битового флага в прерывании (флаг что прерывание произошло) связана не только с "минимизацией времени обработки прерывания".
Этот архитектурный паттерн для меня обладает иной ценностью. Прерывания представляют собой полноценный параллельный поток выполнения. И если внутри прерывания отрабатывают какие-то алгоритмы зависимые по данным с основным потоком, придется вводить примитивы синхронизации. С возможностью ошибки. Рабочий алгоритм программы разбавится еще и вызовами синхронизации, блокировками, итд.
Паттерн с выставлением из прерывания флажка и анализа флажка в заданном нами месте позволяет "обработать" прерывание именно тогда когда мы желаем, в заданной очередности, избегая синхронизации.

     

4 часа назад, x893 сказал:

Если в цикле __NOP или __WFI - есть разница по времени входа в прерывании ? Может кто мерял.

Для wfi есть.  В большинстве реализаций это вход в режим энергосбережения с возможной приостановкой сигналов синхронизации и проч. Соответственно, прерывание придет и понадобится время раскочегариться.

[Forger 17]

31 minutes ago, std said:

Мне не этот вопрос интересен, есть интерес почитать волшебные книги реальных гуру.

Так об и нужно было спрашивать )))

Например мои буквари были эти:

• Роберт Мартин. ЧИСТЫЙ КОД
• Ален И. Голуб. ВЕРЕВКА ДОСТАТОЧНОЙ ДЛИНЫ, ЧТОБЫ ВЫСТРЕЛИТЬ СЕБЕ В НОГУ
• Christopher Michael Kormanyos. "Real-Time C++ Efficient Object-Oriented and Template Microcontroller Programming"
• Скотт Мейерс  Наиболее эффективное использование C++

 

 

31 minutes ago, std said:

Паттерн с выставлением из прерывания флажка и анализа флажка в заданном нами месте позволяет "обработать" прерывание именно тогда когда мы желаем, в заданной очередности, избегая синхронизации.

Именно! По сути с этой целью я и делаю прерывания предельно короткими, а для синхронизации с фоном задач как раз и используются сервисы ос: семафоры, очереди ... 

К примеру, при разборе очереди данных с последовательных портов я использую счетные семафоры и программные очереди (буферы), которые уже потом разгребаются в фоне соотв. задач.

В прерывании не анализирую приходящие данные, нет на этого времени. Их нужно быстро забрать из аппаратного буфера, и тут же переложить в программный, сказать об этом и тут же освобождать время ядра для других.

[jcxz 187]

В 19.09.2023 в 09:37, Forger сказал:

Получается что мой выигрыш в несколько тактов на входе в прерывание при отказе от делегата никакой погоды вообще не сыграет, овчинка выделки не стоит ))

А мне вспоминается один проект, где "молодые и продвинутые" программеры, в алгоритме сигнальной обработки на DSP накодили на всяких с++-ных плюшках (использовали и перегруженные операторы и наследование и виртуальные методы и т.п. модные и "продвинутые" плюшки). Для простого чтения входных данных из нескольких циклических буферов в цикле сигнальной обработки. И.... вдруг оказалось, что довольно мощный DSP (который выбирался вроде как с запасом по производительности) сильно не тянет. Т.е. - даже базовый функционал он успевает исполнять только на ~30% (быстродействия не хватает уже трёхкратно). А ведь это был только базовый функционал!  Позже планировалось ещё навернуть несколько этажей обработки над ним.

Стали разбираться. Покатили бочку на нас со смехотехником, типа: "Это вы выбрали DSP, не адекватный задаче". Руководство решило вообще закрыть проект, как неудачный. Потом оно ещё посовещалось. Кого-то уволило. Спросили меня - "посмотришь?" (до этого момента исходники мне не показывали, так как "ноу хау", наш собственный закрытый алгоритм). "Иначе - закрываем проект и расходимся по домам." Подписал NDA, получил исходники и..... увидел всё это безобразие, где класс на классе да классом погоняет.    Посмотрел во что это всё выливается компилится на DSP. А на DSP все эти чтения входных данных посредством вызовов методов классов, компилились в вызовы функций. Что приводило к невозможности глубокой оптимизации циклов обработки. Так как аппаратные циклы, в которых в конвеер команд в ядре грузится сразу всё тело цикла целиком, а потом там прокручивается нужное число раз, распараллеливаясь на 8 или более потоков исполнения и не обращаясь вообще к памяти команд для загрузки новых - они не позволяют из себя делать вызовы подпрограмм. Выполнение возможно только в пределах такого аппаратного цикла. Любой вызов функции наружу приводит к тому, что компилятор создаёт программный цикл, с кратным (в несколько десятков раз(!)) уменьшением скорости выполнения.

Вобщем - снёс я всё это модное и продвинутое плюсовое безобразие, реализовал всё то же самое, но на простых указателях на данные. На простом си. Добавил restrict-ов указателям. Перераспределил память и управление ею. И..... циклы взлетели!  Компилятор скомпоновал нормальные VLIW-пакеты инструкций для DSP (с максимальным распараллеливанием), завернул их в аппаратные циклы, задействовал все 64 регистра ядра для обработки. Уменьшение времени выполнения того кода получил почти 100-кратное!!! Руководство долго не верило в такой эффект, пока не получило работающий код.  Проект наш продолжился. Надстроили все этажи которые и планировали. Потом ещё добавили опциональных (так как ресурсов хватало за глаза). И всё равно конечная загрузка CPU составила = максимум ~20...30%. Это даже при том, что работало ядро не на максимальной частоте, а что-то порядка 2/3 от максимума.

Правда потом руководство начало сетовать, что "Выбрали слишком мощный DSP и слишком много ОЗУ поставили. Надо бы как-то урезать осетра. Для удешевления изделия."....  

 

PS: Так что - пока не имеете дела с серьёзной обработкой данных, до тех пор скорей всего не увидите профита от оптимизации.

[Forger 17]

50 minutes ago, jcxz said:

(использовали и перегруженные операторы и наследование и виртуальные методы и т.п. модные и "продвинутые" плюшки).

Если плюшки ради плюшек - это одно, это баловство, оно хоть и нужно, но с ним нужно аккуратно, а вот если плюшки для дела - и дают ощутимый профит, то это другое. Боятся этого не стОит!

Грань найти сложно, она только с опытом приходит. Но если не пробовать ничего нового, то как узнать что можно некоторые вещи делать быстрее и проще, ну и велИк риск безвозвратно "отстать от поезда"... Кого-то такой расклад страивает, а кого-то нет. Тут сам каждый решает.

 

50 minutes ago, jcxz said:

Подписал NDA, получил исходники и..... увидел всё это безобразие, где класс на классе да классом погоняет

Мне тоже довелось столкнуться с такими мракобесием: лет 12 назад некий молодой прогер в тщедушный 80166 проц на примерно 200МГц всунул плюсы во всей их красе с активнейшим использованием stl и соотв. кучи. Более того туда же другой, но тоже не менее отважный прогер запихнул SQL сервер ....

Короче, по итогам работ заставили молодого прогера ввести как минимум профилирование, чтобы замерить скорости работы его кода, где бы он сам убедился насколько все печально.

В итоге он сам же убирал оттуда все тяжеловесное, переписывая критичные куски. Плюсы остались, по итогах они как раза беды не делали, ибо код на удивление был спроектирован довольно грамотно, а вот от кучи и встроенной stl конечно отказались, переписав критичный по скорости работы куски ...

 

Сейчас этот прогер уже много лет работает на серьезную импортную фирму, где пишет низкоуровневый код под некие "биржевые сервера" с предельно жесткими требования к скорости разбора сетевых пакетов. Получает оч. хорошие деньги, не просто так, за бугром просто так ничего никому не платят )

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

 

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

По мне оптимально некое комромисное решение - не боятся ничего нового, но при этом быть готовым и более досконально проверять как это все новое работает.

 

 

 

50 minutes ago, jcxz said:

Так что - пока не имеете дела с серьёзной обработкой данных,

Будет "серьезная обработка" и проект будет выстроен соответственно. Но оптимизировать все и вся и где это никому не нужно я не стану.

 

У нас в подъезде дома живет некий старик, который ВСЕГДА выключает свет в подъезде (выключатель на первом этаже), хотя на каждом этаже стоит датчик присутствия и светодиодная лампа. Типа "экономит электричество".

Даже простейший приблизительный подсчет показал, что его "выдающаяся экономия" дает на одну квартиру примерно несколько рублей экономии В ГОД. Но об этой "экономии" сразу забываешь, когда вечером заходишь в темный подъезд и на ощупь ищешь это чертов выключатель ...

Это старик своей "экономией" мне сильно кого-то напоминает ))

[std 6]

4 часа назад, Forger сказал:

Так об и нужно было спрашивать )))
Например мои буквари были эти:

• Роберт Мартин. ЧИСТЫЙ КОД
• Ален И. Голуб. ВЕРЕВКА ДОСТАТОЧНОЙ ДЛИНЫ, ЧТОБЫ ВЫСТРЕЛИТЬ СЕБЕ В НОГУ
• Christopher Michael Kormanyos. "Real-Time C++ Efficient Object-Oriented and Template Microcontroller Programming"
• Скотт Мейерс  Наиболее эффективное использование C++

Пропустишь одно слово, так как думаешь что все всё понимают и получаешь.
Ну мы же ведем разговор о EMBEDDED разработке.
Embedded это еще hard realtime, часто ассемблер, прямая работа с железом и оригинальные решения,
платы, разводка, сигналы, схемки, электронные компоненты, алгоритмы, методика отладки и тестирования.
Методика построения проектов электроники, программных проектов.
Документация, в конце концов.   А Мейерсу и Голубу в обед двадцать лет. Примерно тогда я их и скурил.

Интересны гуры именно Embedded разработки, то бишь еще и электроника, а не очередное программирование.  
Теплится надежда что есть тот заветный фолиант, который прочтешь - и сразу станешь магом.
(шучу конечно, но это именно та причина, по которой я спросил что за книжка)

 

3 часа назад, jcxz сказал:

А мне вспоминается один проект, где "молодые и продвинутые" программеры, в алгоритме сигнальной обработки на DSP

Что за камень-то был, имя! 😃
В противовес задвину байку из примерно 2000 года и вышедшей тогда в 1998 свеженькой VS6.
По аналогии с микроконтроллерными циклами или даже с x86 асмом я писал DSP обработку в духе:
 

mov reg_address, address
mov reg_counter, count
loop:
      do with [reg_address] whatever...             ; Что-то делаем с данными по адресу..
      inc reg_address                               ; Инкремент адреса
      dec  reg_counter                              ; Декремент счетчика
      jnz loop
      ....

И удивился, когда циклы в C++  STL показали более быструю работу.
WTF?!? WTF?!

Фича оказалась в том, что STL использует для проверок циклов сравнение указателей,
т.е. обходится без счетчиков.

 

Изменено 21 сентября, 2023 пользователем std

[Forger 17]

1 hour ago, std said:

А Мейерсу и Голубу в обед двадцать лет. Примерно тогда я их и скурил.

Так с тех пор мало что изменилось в это сфере. Можно сказать что это - Буквари с большой буквы, может в чем то уже не так актуальны, но в целом по-прежнему ценны.

 

1 hour ago, std said:

Интересны гуры именно Embedded разработки, то бишь еще и электроника, а не очередное программирование.  

Слишком общие хотелки ) Чтобы собрать все в одну чудо-книжку и чтобы она прям всех во всем устраивала - это конечно утопия )

Но книжки по т.н embedded разумеется есть. Если не забанены в гугле, то вот например список 

 

1 hour ago, std said:

часто ассемблер

Отнюдь. Вот у меня в проектах практически нет asm. А в последних вообще нет ни одного asm файла, это не хвастовство, просто он уже не нужен, как это было раньше. Нет нужды туда влезать.

Исключение - глянуть disasm для спорных кусков кода и конечно для отладки когда все пошло "по одному месту" ))

 

1 hour ago, std said:

Ну мы же ведем разговор о EMBEDDED разработке

Лет 15 назад в просторах интернетов это слово звучало  очень часто, а сейчас уже не те времена и такой существенной разницы уже пожалуй нет ))

[Arlleex 131]

Про безымянные пространства имен.

Пишу некий драйвер на плюсах, но без всяких ООП-ништяков: мне оно тут как собаке пятая нога)) А вот прибрать мусор пространствами имен мне очень даже хочется.

Драйвер - это пара файлов driver.hpp

#ifndef DRIVER_HPP
#define DRIVER_HPP

namespace nsDriver { // глобальное название для семейства различных уровней взаимодействия с API этого драйвера
  namespace nsHw {   // а это уже конкретика: понятно, что в этой паре .cpp/.hpp-файлов будет нечто, работающее на аппаратном уровне
    void init();     // тот, кто видит этот заголовочник, вызывает nsDriver::nsHw::init(), и понятно, что это инициализация аппаратуры этого драйвера
  }
}

#endif

и driver.cpp

#include "driver.hpp"

namespace {
  inline void initSPI() {
    ...
  }
  
  inline void initGPIO() {
    ...
  }
  
  inline void initNVIC() {
    ...
  }
}

namespace nsDriver {
  namespace nsHw {
    void init() {
      initSPI();
      initGPIO();
      initNVIC();
    }
  }
}

Почитал про безымянные пространства имен - очень удобно: заменяют ключевое слово static, причем позволяя упрятать даже пользовательские типы данных внутрь этого безымянного пространства. Ну, не суть.

Кто хорошо знает - возможен ли какой-то хитрый трюк (из других единиц трансляции) или непреднамеренная ошибка программиста, когда компилятор выдаст ошибку в функции init() из-за того, что не сможет достоверно определить, какую из предоставленных функций initSPI() и т.д. вызвать? Я имею в виду: если конкретно в этой единице трансляции (driver.cpp) я напишу функцию с таким же именем initSPI() вне каких-либо пространств имен, то init() не скомпилится, т.к. компиятор не будет знать, какую вызвать - ту, что в анонимном пространстве имен или просто глобальную. Это понятно. Но вопрос именно в том, что может ли как-то получиться так, что из других единиц трансляции сломают логику линковки?

[MrYuran 16]

В 22.09.2023 в 00:07, Forger сказал:

Но книжки по т.н embedded разумеется есть. Если не забанены в гугле, то вот например список 

Серия собеседований в топовые конторы Н.Новгорода выявила интересную особенность эмбеда в 2023.

Никому не интересен ваш 20+ опыт в ковырянии железок без ответа на вопросы:

• как вы тестируете ПО?
• как насчет jenkins?
• ну и вообще DevOPS

Все перечисленное в вашем списке представляет нижний слой Hardware/HAL, который усилиями того же STM сегодня мало кому интересен.

Конфигурацию в кубе может и обезьянка накидать. На первое место выходит архитектура системы, технологи DevOPS и бизнес-процессы.

Можете сказать, что рядового разработчика embedded это не касается.. Нет, уже касается.

[Arlleex 131]

30 минут назад, MrYuran сказал:

Никому не интересен ваш 20+ опыт в ковырянии железок без ответа на вопросы:

• как вы тестируете ПО?
• как насчет jenkins?
• ну и вообще DevOPS

Все сильно зависит от области, в которой эта embedded-разработка ведется. От сложности проекта, от количества активных разрабов.

Мнение "ваш хардвэйр нам ... не нужОн (с)" говорит о том, что для типовых задач навыков костылизации кастомизации готового вполне хватает, поэтому можно сосредоточиться на всяких дженкинсах и девопсах.

Я не уверен, что это прям плохо-плохо, но в частности поэтому мы имеем калькуляторы, требующие 100 МБ ОЗУ и гигагерцовый CPU в кармане.

Истина в балансе - и в нормальных конторах есть и железячники, и архитекторы, и балаболы. И все по-своему полезны.

[MrYuran 16]

В 16.11.2023 в 08:59, Arlleex сказал:

Все сильно зависит

Естественно. Но и отрицать реальность довольно глупо.

"Взрослые" практики из "нормального" программирования стремительно переходят в эмбед и становятся новой нормальностью и маст хэв скилами.

В 16.11.2023 в 08:59, Arlleex сказал:

в нормальных конторах есть 

Вот конкретная задача. Сеть беспилотников.

Грубо говоря, взлетает стая птичек и поднимает над лесом/полем интернет.

Предварительное условие: железо будет на самом последнем этапе, но к этому моменту все должно гарантированно работать.

[one_eight_seven 3]

1 hour ago, MrYuran said:

• как вы тестируете ПО?
• как насчет jenkins?
• ну и вообще DevOPS

Первый вопрос правильный.

Второй - маркер, что у них у самих этого или нет, или оно сделано плохо.

Третий - пустозвонство и инфоцыганщина, что, в общем-то с самого начала декларируется и манифестируется апологетами девопса. ну и ещё раз маркер того, что у них этого нет, или сделано отвратительно.

Изменено 16 ноября, 2023 пользователем one_eight_seven