[makc 190]

20 минут назад, Arlleex сказал:

"Инлайн этот - странный предмет... Вроде бы есть, а вроде и нет"

Есть ещё более странный предмет - extern inline. 

 

[one_eight_seven 3]

24 minutes ago, Arlleex said:

дендрофекальных

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

Во-вторых, "дендру" часто вообще не завозят, поэтому, вот так : )

24 minutes ago, Arlleex said:

То зачем они вообще нужны?

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

Изменено 15 октября, 2021 пользователем one_eight_seven

[haker_fox 60]

15 hours ago, Arlleex said:

что определение функции в самом классе неявно подразумевает наличие inline. Т.е.

Вполне возможно. Но всё же проверять стоит листинг, т.к. у меня строгой уверенности нет.

14 hours ago, jcxz said:

Читали или нет?

А Вы?)

14 hours ago, jcxz said:

Повторю:

И я повторю: я прекрасно Вас понял ещё в прошлом посте. Но что мешает все эти телодвижения с допольнительными параметрами спрятать внутри тела драйвера? А наружу выставить только общепринятые и нужные методы: открыть, закрыть, писать, читать? Тот же linux работает на куче архитектур, но позволяет обращаться к последовательному порту стандартизированным API.

14 hours ago, jcxz said:

нужно везде городить функции с множеством передаваемых параметров

Зачем? Если можно просто использовать класс драйвера, имея общий интерфейс?

14 hours ago, jcxz said:

Так городить вам в вашем универсальном драйвере семафоры для доступа функционалу UART или нет?

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

15 hours ago, jcxz said:

А ведь в третьем проекте может вообще потребоваться работа без ОС

Такого не было у меня. Я сторонник везде использовть ОСРВ. Тем более есть совсем кроха по ресурсам: scmRTOS.

15 hours ago, jcxz said:

Вот как раз на вашем примере и виден оверхед:

Да, оверхед есть. Но стоит ли только на него смотреть? А потраченное время на адаптацию кода под конкретный пример? А стоит ли тратить это время? Я пока ответил для себя "нет". Пусть будет всё универсальное. Но если понадобится, я отнаследую драйвер с необходимыми кастомными няшами)

15 hours ago, jcxz said:

Вот тогда эта кажущаяся простота куч и аукнется длительными поисками места утечки....

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

15 hours ago, jcxz said:

Так что если "контролировать" - то после каждой минимальной правки исходника, после каждой компиляции. Веселье ещё то....

Зато нескучно!

 

13 hours ago, Arlleex said:

Ну все равно вот представьте, как бы хорошо жилось, если бы было "жесточайшее" требование тулчейну - инлайнить!

Такое есть))) Называется инлайн-ассемблер, или отдельный листинг на ассемблере)))

[jcxz 184]

1 час назад, haker_fox сказал:

Да, оверхед есть. Но стоит ли только на него смотреть?

Не понимаю - с чем Вы тогда спорите... То доказываете, что универсальный драйвер будет не менее оптимальным, чем специализированный, то вдруг "оверхед есть". Сами себе противоречите... Если какое-то решение требует больше ресурсов, чем другое, на выполнение аналогичной задачи, это означает, что оно менее оптимально. Всё! О чём тут спорить?

Вопрос "зачем" - я не рассматривал. Каждый для себя сам определяет "зачем". Если Вас устраивает время старта устройства = ~1мин и требование везде впендюривать внешнюю SDRAM + внешнюю флешку для загрузки ПО - ставьте линух, на который Вы ссылаетесь. И эти его требования - это как раз следствие универсальности и возможности "работать на куче архитектур". Но тогда не удивляйтесь, что задачам требуются мегабайты стека (как Вы писали ранее) или что они сжирают батарейку за полдня. Или когда работа с теми же несколькими UART-ами стала сжирать значительное время CPU.

1 час назад, haker_fox сказал:

общепринятые и нужные методы: открыть, закрыть, писать, читать?

Кем "общепринятые"? Вами? Так и говорите за себя. У других могут быть свои "общепринятые" методы. И вообще не понимаю - что такое "открыть, закрыть" и зачем это UART-у? Что там закрывать?

Практический пример: Вот написали Вы эти свои методы, с семафорами и прочими блэкджеком и шлюхами плюшками, а в новом проекте вдруг потребовалось писать/читать этот UART из ISR! Что будете делать?

1 час назад, haker_fox сказал:

А потраченное время на адаптацию кода под конкретный пример? А стоит ли тратить это время?

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

У меня складывается ощущение, что все ваши задачи - примерно одинаковые. Как и используемые МК. Потому Вы просто не можете представить себе всего многообразия различных требований предъявляемых в разных проектах к похожим интерфейсам. И потому ваше "универсальное решение" кажется вам оптимальным.

 

1 час назад, haker_fox сказал:

Зато нескучно!

Только что сами же говорили о "пустой трате времени". Опять сами себе противоречите. 

 

PS: Универсальность == неэффективность. Однозначно. Спорить тут не о чем.

[haker_fox 60]

16 minutes ago, jcxz said:

Не понимаю - с чем Вы тогда спорите...

Я спорю? Перечитал свои ответы, я не обнаружил спора.

16 minutes ago, jcxz said:

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

Где я это доказываю? Возможно мы с Вами друг друга недопоняли.

17 minutes ago, jcxz said:

Если Вас устраивает время старта устройства = ~1мин

Нет, не устраивает. Но такого старта у меня и нет. 5 секунд максимум.

17 minutes ago, jcxz said:

Но тогда не удивляйтесь, что задачам требуются мегабайты стека (как Вы писали ранее) или что они сжирают батарейку за полдня

Похоже, что как раз Вы невнимательно читаете мои сообщения. Либо я невладею русским языком достаточно полноценно, чтобы собеседник смог понять меня. Поясню ещё раз: я работаю в офисе на фирму, где формат ПО и железа диктует мой руководитель. В силу его некоторых психофизических свойств он не всегда прислушивается к мнениям коллег. Вот там, да, и мегабайты ОЗУ и львинные расходы стека. Допольнительно я делаю свои личные проекты вне офиса. И там у меня стоят STM32F030/F091/LPC1768. И никаких внешних сдрамов и никаких громадных расходов стэка. Пишу и проектирую так, как считаю нужным. Вроде бы я писал об этом, а Вы смешиваете в кучу((

21 minutes ago, jcxz said:

Кем "общепринятые"? Вами?

Хотя бы POSIX. Возможно, я не всё перечислил, но перечисленное там есть.

21 minutes ago, jcxz said:

И вообще не понимаю - что такое "открыть, закрыть" и зачем это UART-у? Что там закрывать?

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

22 minutes ago, jcxz said:

а в новом проекте вдруг потребовалось писать/читать этот UART из ISR! Что будете делать?

Обычно у меня такого не возникало. Но если возникте, то первое, что я сделаю, так это подумаю. Но, скорее всего, добавлю специализированные методы с окончанием "FromISR" или что-то подобное, где оптимизирую чтение/запись из прерывания.

24 minutes ago, jcxz said:

С Вашим подходом времени тратиться будет больше. В общем случае.

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

25 minutes ago, jcxz said:

У меня складывается ощущение, что все ваши задачи - примерно одинаковые. Как и используемые МК

Мои задачи:

1. На официальной работе в офисе: различные системы сбора данных (аналоговые, дискретные) с самыми разными параметрами сигналов. Более редко всякие интерфейсы связи и различные разовые работы в стиле "пределать блютус модуль к прибору".

2. Для себя: модули ввода-вывода на шину RS-485 с акцентом на отказоустойчивость. И прочая автоматизация.

Чтож, да, задачи можно сказать, что одинаковые.

28 minutes ago, jcxz said:

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

Всем нам ещё предстоит чему-то научиться. Пока сужу со своей колокольни. Но, насколько я могу заметить, я никому не навязываю своё видение. Лишь излагаю его, но это не запрещено на форуме, не так ли?

 

29 minutes ago, jcxz said:

Только что сами же говорили о "пустой трате времени". Опять сами себе противоречите. 

Не противоречу. Это я про работу на фирме. Если она готова своим сотрдуника оплачивать пустую трату времени, то пусть. Здесь я уже ничего не могу поделать. В своё время я много раз чего пытался доказать начальству, только действительно время потерял.

30 minutes ago, jcxz said:

PS: Универсальность == неэффективность. Однозначно. Спорить тут не о чем.

@jcxz, я не веду спор. Почему Вы так часто упоминаете этот глагол? Может быть Вы хотите поспорить?

[jcxz 184]

16.10.2021 в 13:37, haker_fox сказал:

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

Конечно. А почему "запутаетесь"? Ведь этот драйвер будет однозначно проще универсального, который должен быть рассчитан на все возможные случаи. А значит в универсальном запутаться проще.

Вот у меня сейчас в проекте есть UART, который:

1) в который нужно писать данные из ISR;

2) это только запись в FIFO UART, а собственно сама передача физически должна начинаться от аппаратного сигнала таймера значительно позже записи (но с привязкой к таймеру с точностью до такта CPU);

3) момент начала старт-бита (на приёмной стороне) надо отследить максимально точно (желательно с точностью до такта CPU), а значит - захватить его по аппаратному таймеру;

4) размер "символов" этого UART = 24 бита.

Вот и попробуйте такое засунуть в "универсальный драйвер".   

[haker_fox 60]

 

11 hours ago, jcxz said:

Вот и попробуйте такое засунуть в "универсальный драйвер". 

Я бы и не стал. Как я уже говорил, проще унаследовать от абстрактного класса (или от конкретного по ситуации) новый драйвер последовательного порта, и спрятать всю логику в нём. Вытащив наружу те методы, которые Вам нужны. Заодно, такой драйвер станет базой для последующих разработок)

По факту получается то же самое, что и у Вас. Только я просто всё закрываю классами. И да, я тоже не леплю уж прямо всё в один класс или один файл. Разумный подход всё же рулит)

11 hours ago, jcxz said:

А почему "запутаетесь"?

Проектов много. Все драйвера так или иначе могут различаться содержимым, названием имён переменных и функций... Возможно, что это когнитивные особенности конкретного разработчика. Ведь по сути мы с Вами говорим об оформлении кода) А стиль оформления у каждого, как известно, свой. Если корпоративный стандарт не доминирует.

11 hours ago, jcxz said:

Вот у меня сейчас в проекте есть UART, который:

Да, такие интерфейсы связи пока не попадались на моём пути)

[Сергей Борщ 119]

16 часов назад, jcxz сказал:

Вот у меня сейчас в проекте есть UART, который:

Он построен на базе железного УАПП контроллера? Если да - можно отнаследоваться от базового класса, имеющего примитивы работы с железным УАПП - настраивать скорость, четность и т.п и строить свою ветку классов от этого места, пусть даже не все функции базового класса будут использоваться. Если же он не имеет ничего общего с железным  УАПП - не нужно пытаться их засунуть в общее дерево классов - надо для него строить свое отдельное дерево.

[Forger 17]

1 hour ago, Сергей Борщ said:

Он построен на базе железного УАПП контроллера? Если да - можно отнаследоваться от базового класса, имеющего примитивы работы с железным УАПП - настраивать скорость, четность и т.п и строить свою ветку классов от этого места, пусть даже не все функции базового класса будут использоваться. Если же он не имеет ничего общего с железным  УАПП - не нужно пытаться их засунуть в общее дерево классов - надо для него строить свое отдельное дерево.

Поддерживаю!

Это примерно то же самое, что от наследуя от класса МОЛОТОК пытаться расширить его функционал до класса СЛЕСАРНОГО ВЕРСТАКА.

Ведь по логике "молоток" является лишь ЧАСТЬЮ верстака, причем в секции private, чтобы кто-попало не брал чужие инструменты.

Поэтому у меня экземпляр класса порта (не суть какого именно) - лишь один из объектов в поле private, а портов ("молотков") в "мастерской" может быть несколько и все они разные.

 

Короче, нужно быть очень "одаренным" проектировщиком кода, чтобы от всех этих "молотков" и "стамесок" разом наследовать класс "верстака" 

 

[one_eight_seven 3]

1 minute ago, Forger said:

Короче, нужно быть очень одаренным проектировщиком кода, чтобы от всех этих "молотков" и "стамесок" разом наследовать класс "верстака" 

Я видел и более одарённых людей - которые "молоток" наследуют не то, что от "верстака" или "слесарного цеха", а от планеты, на которой всё это находится.

[Forger 17]

Есть как минимум один признак увлечения беспощадным и потому бестолковым наследованием - вдруг неожиданная необходимость связать класс потомка с его родителем "снизу вверх".

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

Я лично с таким сталкивался, это крайне путает и загромождает код всякими методами setOwner, приписками friend или типа того. Вот что настоящий кошмар в развивающемся проекте, прям раковая опухоль, которая лечится только полным перестроением проекта ((

 

6 hours ago, haker_fox said:

Возможно, что это когнитивные особенности конкретного разработчика.

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

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

[Arlleex 131]

1 час назад, Сергей Борщ сказал:

Если да - можно отнаследоваться от базового класса...

Хотелось бы вот здесь уточнить, что из себя будет представлять сам базовый класс: это абстрактный класс или обычный, наследники которого переопределяют методы базового?

[Forger 17]

16 minutes ago, one_eight_seven said:

Я видел и более одарённых людей - которые "молоток" наследуют не то, что от "верстака" или "слесарного цеха", а от планеты, на которой всё это находится.

И где они теперь? )) Небось работают в серьезных индусских организациях 

[haker_fox 60]

10 minutes ago, Forger said:

Для этого приходится зачастую отдельно прорисовывать структуру проекта в спец. программах.

О каких программах идёт речь?

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

8 minutes ago, Arlleex said:

Хотелось бы вот здесь уточнить, что из себя будет представлять сам базовый класс: это абстрактный класс или обычный, наследники которого переопределяют методы базового?

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

virtual retval_t write(const uint8_t * const src, const size_t count, const timeout_t timeout = 10) = 0;

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

С другой стороны, настройки того же последовательного порта в обще случае платформенно-независимы (скорость, количество бит данных, чётность, количество стоповых бит) и могут быть реализованы в базовом классе. А именно: сама структура, описывающая настройки; и методы, записывающие эти настройки, проверяющие их корректность, возвращающие их по требованию и т.п.

Мне недавно, например, понадобился RS-485. При этом драйвер последовательно порта у меня уже был для данной архитектуры. Я просто отнаследовал класс от этого драйвера, добавив в него всё необходимое для управления физикой RS-485. Всё остальное при наследовании бралось из родительского класса - драйвера последовательного порта, уже готового и рабочего.

[Forger 17]

3 minutes ago, haker_fox said:

О каких программах идёт речь?

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

 

3 minutes ago, haker_fox said:

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

С этим бессмысленно спорить ))