Если вы про накладные расходы процессора - то в времена STM32 это пустяки. А если про временные накладные расходы на изучение матчасти - так это же самообразование, самому потом будет приятней и эффективней на перспективу работать в хорошо структурированной логической системе.
Обучение бывает спорным. Часто бывает такое, что знания просто негде потом применить более одного раза. Вместо бесполезного изучения лучше посидеть и послушать музыку.
Про бесполезное изучение согласен и поддерживаю, хотя иногда у меня бывает тяга "пощупать" что-то новое из-за природного любопытства (ЛИ, кстати, это проходит с возрастом? Интересно ваше мнение.).
Однако, время на реализацию алгоритма в конкретное ПО является объективным критерием в программировании и в долгосрочном периоде следует оптимизировать временные затраты применением абстракций. Т.к. прирост быстродействия процессоров (в микроконтроллерах в том числе) опережает скорость роста накладных расходов на программные абстракции, считаю, что обращать внимание нужно прежде всего на повышение удобства программиста при написании кода.
В embedded для этого придуманы объектно-ориентированный подход и ступенью выше RTOS. Но есть люди, принципиально пишущие на С или языке ассемблера только потому, что не желают делать иначе. На мой взгляд это закостенелость.
"Оптимизировать временные затраты" - это из другой оперы. Здесь не стоит такой цели. Я занимаюсь тем, чем заниматься приятно. А всякие новомодные приемчики - это нечто чужеродное, неуютное. Пусть их эффективность выше, но удовольствия никакого.
Нет большой разницы писать на С или С++, разве что С более распространен и реализован и на том, на чем С++ нет. А вот что для такой задачи даст RTOS, кроме необходимости применять более мощный процессор? Одно дело, когда (мы это в соседнем треде уже обсуждали) нужны тяжелые библиотеки, параллельные процессы в них и т. п. - tcp/ip stack, и стеки протоколов поверх, файловая система, GUI, и т. п. И совсем другое - когда голая управляющая программа с простым протоколом поверх UART для связи. Для первого OS - самое то, RTOS или вообще Linux, для второго - обработчики прерывайний, да зацикленные конечные автоматы для низкоприоритетных задач. Даже если для выбранного контроллера есть RTOS, и она сама по себе не занимает все его ресурсы, какой от нее в такой программе толк?
>>Нет большой разницы писать на С или С++, Да, программа будет работать одинаково, но в случае грамотного использования классов С++ вариант поддерживать будет легче.
>>Даже если для выбранного контроллера есть RTOS, и она сама по себе не занимает все его ресурсы, какой от нее в такой программе толк? Лучше конечно текст вместо видео, но иначе никак На поддержку проекта на RTOS тратится меньше сил за счёт большей наглядности кода.
Как показал опыт, в программе на C++ могут разобраться и внести изменения гораздо меньше людей, чем в программе на C. Поэтому исходники на C++ можно открыто выкладывать, никто и никогда их не будет менять или использовать. Я называю их "самокриптующимися".
Кстати да, и еще очень сильно зависит от стиля. Исходник на плюсах с множественным наследованием, перегруженными операторами, и т. п. понять без документации на грани возможного - что, собственно, делается просто не видно. Ну а учитывая, что в мелких контроллерах еще и каждый лишний вызов - это трата ресурсов, а косвенные обращения еще дороже, увлечение абстракциями еще и стоит денег. Время, конечно, идет, прогресс не стоит на месте, но еще несколько лет назад самый массовый контроллер был масочным четырехразрядным, и программировался на ассемблере. Я лично с такими почти не сталкивался, и стараюсь писать на C[++], но в любой ситуации применять 32хразрядные контроллеры, RTOS и абстракции C++ не готов. Контроллеры с архитектурой pic16 я до сих пор вполне активно применяю, из-за их размеров и цены в районе 40-50 центов. Кстати, в них часто есть EEPROM, которого нет в stm32. И нет компилятора с C++.
Я неаккуратно выразился, я имел в виду конкретно STM32G030* - как замена восьминогих PIC'ов по примерно той же цене. У них нет EEPROM, а мне он обычно нужен, и именно EEPROM, а не flash. Но да, выбор сейчас стал гораздо шире, чем еще несколько лет назад, и, возможно, с восьмиразрядных контроллеров надо слазить. Есть еще мелкие 32хбитные MIPS у Микрочипа, тоже меньше доллара, но тоже без EEPROM.
Или использовать те контроллеры, где EEPROM есть, благо их не мало. Тем более, что для тех задач, которые я на таком железе решаю, ни RTOS, ни C++ мне не нужны.
ЛИ, а вы может пора абстрагироваться в RTOS даже для таких небольших проектов? Разок освоить - потом жизнь станет веселее.
Reply
Reply
Reply
Reply
Reply
Reply
Однако, время на реализацию алгоритма в конкретное ПО является объективным критерием в программировании и в долгосрочном периоде следует оптимизировать временные затраты применением абстракций. Т.к. прирост быстродействия процессоров (в микроконтроллерах в том числе) опережает скорость роста накладных расходов на программные абстракции, считаю, что обращать внимание нужно прежде всего на повышение удобства программиста при написании кода.
В embedded для этого придуманы объектно-ориентированный подход и ступенью выше RTOS. Но есть люди, принципиально пишущие на С или языке ассемблера только потому, что не желают делать иначе. На мой взгляд это закостенелость.
Reply
"Оптимизировать временные затраты" - это из другой оперы. Здесь не стоит такой цели. Я занимаюсь тем, чем заниматься приятно. А всякие новомодные приемчики - это нечто чужеродное, неуютное. Пусть их эффективность выше, но удовольствия никакого.
Прошивка этого БУ написана на C++.
Reply
Reply
Да, программа будет работать одинаково, но в случае грамотного использования классов С++ вариант поддерживать будет легче.
>>Даже если для выбранного контроллера есть RTOS, и она сама по себе не занимает все его ресурсы, какой от нее в такой программе толк?
Лучше конечно текст вместо видео, но иначе никак На поддержку проекта на RTOS тратится меньше сил за счёт большей наглядности кода.
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Leave a comment