Easyelectronics.ru

И это ради экономии десятка тактов?! У тебя ЦП загружен на 99%?

Ещё ни один человек, говоривший мне о подобном замедлении, не мог назвать загрузку ЦП или даже процент использования времени между двумя прерываниями. Это так, наблюдение из жизни.

Вот передо мной STM32F411. У него тактова 100МГц, поэтому при частоте прерываний 10кГц между двумя прерываниями будет 10000 тактов ЦП. И что на этом фоне 10 тактов на вызов виртуального метода? По-моему, очень немного за удобства, которые дают виртуальные методы.

Если сопоставить стоимость электродвигателя и твоей зарплаты со стоимостью МК, то проще взять МК пошустрее и не заниматься интеллектуальным онанизмом, выкраивая 10 тактов. Будь 1000 тактов, тогда игра стоила бы свеч, а так...

cheblin, так ведь запросы клиентов известны? Можно ж статистику собрать, сколько из них кодогенерит для C, и по результатам решить, стоит ли от них отказываться.

Хотя, честно говоря, не понимаю проблемы. Если бы речь шла о написании на C руками – да, тут понятно, крестики могут сильно облегчить жизнь. Но откуда сложности с кодогенерацией?

Надо понимать, что там не один-единственный ШИМ. Во-первых, в этом же цикле три инвертора и, соответственно, три класса ШИМ, в каждом из которых производится расчет итоговой скважности с учетом реверса и проверка защит. Во-вторых, кроме ШИМ, там также контуры управления по положению всеми тремя двигателями, довольно развесистые. И кроме того, там же обработка данных с датчиков положения и тока, а также мониторинг аварийных ситуаций и командоаппарат, вычисляющий задания для систем управления приводами. Суммарная загруженность цикла составляла около 70 процентов на ARM с тактовой частотой 100 МГц. Выбрать другой МК было проблематично на тот момент.
P.S. И да, по поводу и без бросаться словами про онанизм и заглядывать другим в карман на предмет того, какая и у кого зарплата как-то не слишком прилично. Я понимаю, что вы видимо старше и много опытнее меня, но это не дает вам права безосновательно размахивать руками и орать.

так сам кодогенератор ручками пишется, и потом сопровождать нужно.

да и задолбало биться об ограниченность си. ради чего все эти "страдания". так и нет ответа.

просто чтоб было? лучше уж на сферический V кодогенератор потратиться очень уж оно мне нравится.

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

однажды точно также отказался от кодогенерации в JavaScript в пользу TypeScript и время показало правильность этого шага.

О как. Я никому не заглядываю в карман, считая чьи-то деньги, а просто предложил сопоставить стоимость более мощного МК со стоимостью оборудования, затрат времени и усилий на написание ПО. По-моему, проще взять МК на 100 рублей дороже, чем тратить уйму времени на написание и отладку глубоко оптимизированного, но головоломного кода. Ну будет у тебя загрузка не 70%, а 80%, и что, всё сломается? Скорей всего, нет. Ну выиграл ты 10% в быстродействии, и чего добился? Потешил своё самолюбие? В какой-то книжке по программированию попалась очень мудрая мысль, что корень всех проблем программиста кроется в преждевременной оптимизации. И как назвать кучу усилий ради получения собственного удовольствия без практической пользы для дела? Какой смысл убиваться ради выигрыша в 10%? Вот именно так, как я и назвал. Кроме твоей программы в МК больше не будет других программ, то есть ты никому не помешаешь, потратив на себя эти 10%.

P. S. Судя по твоей обидке на мои слова, ты парень грамотный, но тебе оооочень не нравится твоя зарплата. Ты считаешь себя недооценённым, потому тебя и зацепили мои слова. Смени работу на более оплачиваемую и сразу успокоишься по поводу того, что я сказал.

sdv_cyborg, не надо так сразу.... это же не вопрос именно размера зарплаты.
Оптимизация - вопрос экономики:
Предположим код соптимизировали, и конечное устройство стало на 5 баксов дешевле. Инженер (обычно уровня senjor, а кто еще будет оптимизацией заниматься) потратил на это ну, пусть, 3 дня, и еще тестировщики (они дешевле) еще 2 дня дополнительно тесты гоняли. И инженер и тестировщики стоят компании денег (и зарплата там процентов 20-30 не более).
Вопрос: сможем продать столько дополнительных готовых устройств, что бы покрыть эти расходы? (за время до конца жизненного цикла конкретной ревизии оптимизированного модуля). Если считаем что да, то молодцы - надо делать.

НО:

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

Тут как раз ситуация была такая, что проще было соптимизировать, по сути заменить микроконтроллер на более производительный возможности не было. Не буду вдаваться в тему того, почему так получилось, скажем так: нам в отдел принесли железку и сказали, что без вариантов должно работать на ней. Пришлось повыкручиваться немного, чтобы хватило ресурсов на будущее. Да и тем более цена вопроса была лишь в том, чтобы сделать структуру вида:



Ну и горсть оберток для нее, в том числе инициализаторов, которые автоматически по enum'у инвертора заполняют все поля, в том числе и колбек внутри структуры. Так-то весьма типовое решение, а если функция инита инлайновая, а объявление структуры и типа драйвера, описанного enum'ом статические, то компилятор все это весьма хорошо оптимизирует.

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

Я к посту уважаемого //Mt могу только добавить от себя благодарность за его высказывание. Всё точно так и есть.

Вот ты сам и подтвердил, что я тебе говорил: и парень ты грамотный, и сделал всё правильно. Просто с возрастом будешь мыслить ленивей и рациональней. Сначала сделаешь чтобы работало, потом проверишь, что есть запас по быстродействию процентов 20%, а потом... оставишь как есть, ибо

Золотые слова!

Я тут с одним человеком общался... Он эту же задачу, что и у меня, написал на Ассемблере. Потратил год на переписывание с С на Ассемблере. Скорость выше, примерно, раза в 3-5, чем у меня без оптимизаций на С++. За этот год STM выпустила линейку Н7, которая быстрей F7 раза в 2, то есть эффект от ускорение, полученное от переписывание на Ассемблере снижен. А самое смешное (грустное?) состоит в том, что на задачах, которые решает с помощью своего ПО этот человек, даже F103 обеспечивает, примерно, десятикратный(!) запас быстродействия. ...Вот и я не понимаю, нафиг он это сделал. Доказал, что у него самое быстродействуеющее ПО? Безусловно. Но я сторонник другого подхода:

Девиз половины отечественных шаражек, которые ничего путного не производят годами. И к сожалению, до



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

Н-да-а-а-а, sdv_cyborg, не везёт тебе в жизни...

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

С этим трудно не согласиться.

Что – неужели ему надо было переписывать всё, а не несколько процентов кода? Не верится.

Интереснее, кто же согласился ему этот год оплачивать?

Год ждать результата, причем результат - оптимизация по производительности и лапша на асме (поддерживаемость кода на асме - это отдельная тема). Если заменят MCU - еще год ждать?

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

...бг-г-г
сишники оказывается ещё и нищеброды



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

Так неудивительно. Конечный результат работы сишников измеряется считанными мегабайтами, а в случае эмбеда и вовсе килобайтами. За что им платить? ;))

Похоже, не в теме ты.
Scala, Golang, Ruby, Kotlin не только отечественными, но западными стандартами запрещены к использованию для управления чем-то более сложным, чем fucking machin.
Objective-C, Swift. Нигде не встречал ссылки на стандарты этих языков.

С остальными та же самая фигня. В итоге для программирования МК остаются С и С++. Для промышленных контроллеров они же, плюс МЭК 61131-3. Даже древний Паскаль можно использовать для систем жизнеобеспечений, в отличие от всей этой новомодной шушеры. Так что дело не в старпёрстве, а знании стандартов и сфере деятельности.

вахтёр детектед.
у тебя есть в это жизни ещё что нибудь, помимо "управления чем-то"?

Забавно. Зп питоняш находится на уровне PHPшников )

Дык, одна и та же гадость же! Вообще, странно, что пыхпыхеры что-то получают, отличное от нуля. Я думал, это дерьмо уже лет 10 как перестали использовать. А школота все лезет и лезет со своими пыхами/пытхонами/goвнами и педеrustами…

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

Честно говоря, так питон и ниасилил - как-то с matlab/octave тяжко слезать, да и нет особого желания.
Лучше уж Julia изучать, как по мне.

У меня заказчики и объекты серьёзные. Просто специфика работы.

"управление чем-либо" - это, наверное, сильно меньше 1% от рынка разработки ПО (возможно и на порядки меньше).
Так что на зарплаты С/С++-девелоперов эта сфера не влияет от слова "никак".

.