Forger

так не все сводится к одному единственному lwIP, наверняка есть и другие готовые, возможно еще шустрее этого )

Так с тех пор мало что изменилось в это сфере. Можно сказать что это - Буквари с большой буквы, может в чем то уже не так актуальны, но в целом по-прежнему ценны. Слишком общие хотелки ) Чтобы собрать все в одну чудо-книжку и чтобы она прям всех во всем устраивала - это конечно утопия ) Но книжки по т.н embedded разумеется есть. Если не забанены в гугле, то вот например список Отнюдь. Вот у меня в проектах практически нет asm. А в последних вообще нет ни одного asm файла, это не хвастовство, просто он уже не нужен, как это было раньше. Нет нужды туда влезать. Исключение - глянуть disasm для спорных кусков кода и конечно для отладки когда все пошло "по одному месту" )) Лет 15 назад в просторах интернетов это слово звучало очень часто, а сейчас уже не те времена и такой существенной разницы уже пожалуй нет ))

Если плюшки ради плюшек - это одно, это баловство, оно хоть и нужно, но с ним нужно аккуратно, а вот если плюшки для дела - и дают ощутимый профит, то это другое. Боятся этого не стОит! Грань найти сложно, она только с опытом приходит. Но если не пробовать ничего нового, то как узнать что можно некоторые вещи делать быстрее и проще, ну и велИк риск безвозвратно "отстать от поезда"... Кого-то такой расклад страивает, а кого-то нет. Тут сам каждый решает. Мне тоже довелось столкнуться с такими мракобесием: лет 12 назад некий молодой прогер в тщедушный 80166 проц на примерно 200МГц всунул плюсы во всей их красе с активнейшим использованием stl и соотв. кучи. Более того туда же другой, но тоже не менее отважный прогер запихнул SQL сервер .... Короче, по итогам работ заставили молодого прогера ввести как минимум профилирование, чтобы замерить скорости работы его кода, где бы он сам убедился насколько все печально. В итоге он сам же убирал оттуда все тяжеловесное, переписывая критичные куски. Плюсы остались, по итогах они как раза беды не делали, ибо код на удивление был спроектирован довольно грамотно, а вот от кучи и встроенной stl конечно отказались, переписав критичный по скорости работы куски ... Сейчас этот прогер уже много лет работает на серьезную импортную фирму, где пишет низкоуровневый код под некие "биржевые сервера" с предельно жесткими требования к скорости разбора сетевых пакетов. Получает оч. хорошие деньги, не просто так, за бугром просто так ничего никому не платят ) Короче, не дали б ему тогда люлей много лет назад за подобную неоправданную самодеятельность, где она вообще не требовалась и не дали ему же возможность самостоятельно все исправить, то глядишь, он так и не добился б таких успехов в профессии... Кмк, плохи и непродуктивны две крайности - бить себя пяткой в грудь, что голый си это на все времена и плюсы зло и наоборот восхвалять до небес плюсы с их тяжеленными шаблонами где они больше вредят чем приносят пользы ... По мне оптимально некое комромисное решение - не боятся ничего нового, но при этом быть готовым и более досконально проверять как это все новое работает. Будет "серьезная обработка" и проект будет выстроен соответственно. Но оптимизировать все и вся и где это никому не нужно я не стану. У нас в подъезде дома живет некий старик, который ВСЕГДА выключает свет в подъезде (выключатель на первом этаже), хотя на каждом этаже стоит датчик присутствия и светодиодная лампа. Типа "экономит электричество". Даже простейший приблизительный подсчет показал, что его "выдающаяся экономия" дает на одну квартиру примерно несколько рублей экономии В ГОД. Но об этой "экономии" сразу забываешь, когда вечером заходишь в темный подъезд и на ощупь ищешь это чертов выключатель ... Это старик своей "экономией" мне сильно кого-то напоминает ))

Так об и нужно было спрашивать ))) Например мои буквари были эти: Роберт Мартин. ЧИСТЫЙ КОД Ален И. Голуб. ВЕРЕВКА ДОСТАТОЧНОЙ ДЛИНЫ, ЧТОБЫ ВЫСТРЕЛИТЬ СЕБЕ В НОГУ Christopher Michael Kormanyos. "Real-Time C++ Efficient Object-Oriented and Template Microcontroller Programming" Скотт Мейерс Наиболее эффективное использование C++ Именно! По сути с этой целью я и делаю прерывания предельно короткими, а для синхронизации с фоном задач как раз и используются сервисы ос: семафоры, очереди ... К примеру, при разборе очереди данных с последовательных портов я использую счетные семафоры и программные очереди (буферы), которые уже потом разгребаются в фоне соотв. задач. В прерывании не анализирую приходящие данные, нет на этого времени. Их нужно быстро забрать из аппаратного буфера, и тут же переложить в программный, сказать об этом и тут же освобождать время ядра для других.

Увы, не помню (( но вот по поиску за пару минут наткнулся на такие материалы: https://web.engr.oregonstate.edu/~traylor/ece473/pdfs/minimize_interrupt_response_time.pdf https://www.beningo.com/3-tips-for-speeding-up-interrupt-handlers/ А вообще минимизация времени нахождения в прерывании, как и минимизация накладных расходов на их обслуживание - кмк одно из самых важных правил оптимизации кода и проекта в целом.

такая схема может оказаться полезной для жирных сторонних библиотек, например попробую заценить это на открытой LUA библиотеке, а почему бы нет )))

вероятно это очень сильно зависит от проекта и его организации, где все впритык как по скорости так и по размеру кода, то видимо это действительно будет заметно, но много ли таких проектов и у кого? к слову, у меня ни одного нет и не припомню чтобы были такие У такого подхода есть как минимум один минус - малейшее изменение кода хотя бы в одной строчке в любом файле потребует повторной перекомпиляции всего это толстенного исходника. Это сказывается лишь на времени работы над проектом. Впрочем, пока идет отладка (у меня DEBUG), от такой схемы можно отказаться, а использовать ее лишь на релизах (соотв. RELEASE).

А что проект уже не влезает в камень? Просто подобная "оптимизация" скорости коду точно не добавит. А размер - спорно, разве что эксперимента ради )) А для себя давно решил, что достаточно в опциях компилятора на весь проект ставить одну единственную крайне важную галку "One ELF Section Per Function", которая прекрасно помогает компилятору линкеру убрать из кода всякий неиспользуемый в коде хлам.

ну, типа того ))

да, это самое простое, везде работает )

В keil такого нет, но можно индивидуально для любого исполняемого файла по ALT+F7 в окне снять галку Include In Target Build и создать, как предложил коллега makc выше, отдельный исполняемый файл, куда заинклудить нужные исполняемые файлы. Все это добро сложить в отдельную группу чтобы было наглядно.

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

Вот только что из академического интереса проверил сколько тактов в потолке проводит стек USB от ARM MDK-Middleware, под руками проект с MSC устройством (host тут есть, но пока не используется). Короче, вышло максимум 873 такта на работу библиотечного OTG_FS_IRQHandler(), который я должен вызывать в прерывании. В среднем счетчик показывал около 400 тактов. Замерял по циклам из DWT_CYCCNT. Проц. старый добрый F407 на 168MГц. Итого, если считать по тактам выходит время жизни в прерывании в среднем 2,5мкс, максимум около 5мкс. Интересный момент, при подключении по USB (после вызова USBD_Initialize и USBD_Connect) сразу создаются две задачи: Степень их загруженности тут не могу посмотреть. Получается что мой выигрыш в несколько тактов на входе в прерывание при отказе от делегата никакой погоды вообще не сыграет, овчинка выделки не стоит ))

Это проблема решается классическим вызовом такого обработчика. Вот кстати, почитал про это и задумался, что в моей схеме на делегатах можно выиграть на входе в прерывания пару тактов, если библиотечный обработчик того же USB стека вызывать напрямую, без использования делегата. Такой функционал был бы полезен )) Короче, полезно читать форумы, стимулирует появление умных мыслей )) Это еще не самое страшное, это можно пережить )) Куда хуже когда из-за "этого" весь проект летит "коту по хвост", а сроки поджимают

И что мешает разместить ее вне стека? Что мешает в прерываниях оставить лишь быстрые действия с событиями с аппаратными буферами, а наружу в задачи вынести разгребание их содержимого и по сути весь USB стек? По-моему ничего не мешает. Кмк ARM в своих библиотеках MDK-Middleware пошли именно по такому пути, иначе какой смысл создавать для стека отдельную задачу, точно также для работы с файловой системой они создали еще одну задачу, не спрашивая разрешения Но я этот момент обязательно изучу, стало любопытно ) Откуда такое необычное мнение? Я вот сторонник нафик убрать из прерываний все что можно по максимуму, как советуют гуру в своих книгах. Мне эта мысль кажется логичной. Это печально

А мне не приходится это делать. Могу вообще все прерывания сделать с равным приоритетом в одной группе, и все одно проект будет так же работать. Потому по замерам в прерываниях он живет крайне мало времени. И меня такой прогнозируемый расклад полностью устраивает. Другое дело проекты без RTOS, там вообще вся жисть в прерываниях. Тут уж что есть то есть. Но там и проекты слишком простые. а это зависит от стека например я пользуюсь решением от ARM, библиотека закрытая, но она при запуске для USB сама создает как миминум одну задачу, несколько семафоров и вроде даже мьютекс (или EventFlags), точно не помню. Моя задача лишь определить ей размер стека этой задачи и несколько интерфейсных функций, чтобы связать стек с железом. В прерывании находится крайне мало времени (обязательно по случаю замерю, стало даже любопытно). Это меня полностью устраивает. Хотя было бы идеально иметь доступ к исходникам.

Суть какая - как только переносите код в прерывания из фона задачи, этот код прервать никто другой уже не может (если конечно не заморачиваться с вытесняющими друг друга прерываниями и их приоритетами, что вообще лишает смысла наличия в проекте РТОС). Т.е. сильно нарушается сама задумка кода в задачах с разными требованиями к их приоритету. По началу пока код небольшой это будет незаметно, постепенно, с ростом объема обработчиков прерываний в основном коде начнется бардак, который все сложнее и сложнее отлаживать. По сути если изначально спроектировать проект так, чтобы не было никакой нужды курить бамбук в прерываниях, то это по сути полезная привычка сэкономит массу времени на отладке и дальнейшем развитии проекта. А если все уже запущено и лень переписывать толстые обработчики, то эта лень в итоге рискует погубить весь проект. Сужу исключительно по своему личному опыту. странное сравнение, мой код я пишу прежде всего для себя, т.к. мне же его потом и сопровождать, а себя я люблю, себе подлянок делать не стану ) Если кому то под заказ без сопровождения, то может сделаю как нибудь с длиннющими обработчиками, а там пофиг, пусть другие расхлебывают )) В таком подходе конечно можно сделать вход в прерывания хоть на сотню тактов, не мои проблемы )))

ничего не мешает вводить камень в спячку из фона задач будить понятно что от прерываний

Это справедливо отчасти если в проекте не используется RTOS и через прерывания и их приоритеты по сути организована ее некая "эмуляция". Если РТОС есть, то в прерываниях подолгу делать нечего, быстренько проверили флажки прерываний от железа, сложили данные в буфер, просемафорили куда надо и скорее на выход. Так пишут в умных книжках и это действительно справедливо, лично в этом убеждался

вот уж действительно при чем тут вменяемость, когда в проекте 256 программных таймеров )) По этой причине не использую программные таймера, ибо у таких таймеров нет индивидуальных приоритетов, и если один "тормозит", то все остальные ждут, даже если остальным "нужнее". Отлаживать такой код неприятно. Увы, но обработчик прерывания "рвет" весь основной код и нарушает (временно) приоритетность выполнения тех потоков/задач. Поэтому обработчики всегда советуют делать минимально возможной длины (по времени исполнения). Например, из обработчика семафорят, а уже в основном коде разгребают и делают расчеты. Если код забит прерываниями, то основной код рискует поплыть по таймингам, что вообще катастрофа. а это кстати полезный функционал, серьезно, не спорю, может пригодится если обработчик состоит лишь из одного вызова некой библиотечной функции, у меня есть такие случаи Тут мы прекрасно понимаем друг друга, но все-таки бенчмарк дело полезное, это в конце концов информация, которая может пригодится при поиске узких мест. Но если нет желания выяснять, что ж, хозяин - барин ))

Да, пора с этим заканчивать, пустое это Увы, но как раз для обработчиков прерываний это очень и очень важно. В смысле если в одном проекте это прокатывает, то в другом станет узким местом. А ведь такое решение претендует на универсальность, иначе какой смысл во всей этой затеи Если не сложно, посмотрите пожалуйста, сколько все-таки занимает вход в обработчик. Без оптимизации и с нею. Из чисто академического интересу ) За такой невменяемо длинный обработчик следуют уже применять суровые методы инквизиции ))

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

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

не очень хочу чем-то хвастаться, и какое это имеет отношение к теме?

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