[ViKo 1]

5 минут назад, Forger сказал:

Изобретать велосипед - это очень увлекательное и познавательно занятие :)

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

9 минут назад, Forger сказал:

Поэтому без глобальных объектов в таком решении уж никак не обойтись.

Можно вызвать функцию - член класса Com_port для записи в его же буфер.

[Forger 17]

1 minute ago, ViKo said:

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

Изобретать и совершенствовать - это абсолютно разные понятия ;)

[k155la3 26]

Вот посмотрите, первый листинг ТУТ в ветке scmRTOS

ps  

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

Если-б было на чистом С - хрен разберешься (как в FreeRTOS).

 

[ViKo 1]

21 минуту назад, Forger сказал:

Изобретать и совершенствовать - это абсолютно разные понятия ;)

Скажите это dxp & C°. 

[Forger 17]

21 minutes ago, ViKo said:

Можно вызвать функцию - член класса Com_port для записи в его же буфер.

Хрен редьки не слаще: экземпляр этого класса все равно остается глобальным.

[ViKo 1]

4 минуты назад, Forger сказал:

Хрен редьки не слаще: экземпляр этого класса все равно остается глобальным.

А как же. Только в нём уже всё будет ладненько складировано и лишнего наружу не показываться. Только пе(н)дали и руль. 

[Forger 17]

3 minutes ago, ViKo said:

А как же. Только в нём уже всё будет ладненько складировано и лишнего наружу не показываться.

Дык, я так раньше и делал - объект с припиской static или классы с кучей статических методов ...

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

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

[AHTOXA 14]

11 минут назад, ViKo сказал:

А как же. Только в нём уже всё будет ладненько складировано и лишнего наружу не показываться.

Ну, здесь особо не напридумываешь. Если есть класс - UART, то в нём и обработчики прерываний:

UartType uart1(1, 115200...);

void USART1_IRQHandler()
{
     uart1.UartIrqHandler();
}

Здесь, конечно, используется глобальный объект uart1. В любом случае будет что-то глобальное, как правильно заметил Forger. Либо это будут глобальные буфера и указатели, либо мы прячем все эти буфера и указатели в класс Uart. Второй вариант, как мне кажется, удобнее.

К тому же, легко добавить второй UART:

UartType uart2(2, 115200...);

void USART2_IRQHandler()
{
     uart2.UartIrqHandler();
}

 

А уж обработчик сам должен читать из нужного UART-а, и обрабатывать.

[Arlleex 131]

45 минут назад, Forger сказал:

Поэтому без глобальных объектов в таком решении уж никак не обойтись.

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

[Forger 17]

https://habr.com/ru/post/78299/

 

[esaulenka 5]

4 minutes ago, Arlleex said:

идея: буферы, а также общие переменные линковать в определенном регионе памяти по определенному адресу

Похожую идею использует Nordic в своих библиотеках.

Они используют это для раздачи событий в разные модули.

В линкере объявлена секция. Каждый модуль, который подписывается на событие, с помощью спец-макроса кладёт в эту секцию указатель на коллбэк, который надо вызвать по этому событию. Модуль, который события раздаёт (он один), при каждом событии с помощью другой дефайн-магии бегает от начала до конца этой секции и вызывает коллбэки.

Секций, на самом деле, несколько, каждая для своего типа событий (и, соответственно, своего модуля, который это раздаёт).

 

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

И это за меня всё сделали, мне ничего писать не надо (а это не одна сотня строк исходника), только модули подключить.

В общем - нет, никогда и ни за что!

[Arlleex 131]

10 минут назад, Forger сказал:

https://habr.com/ru/post/78299/

Прочитал. Понял 2% текста

Я просто хотел предложить средство обхода зависимости от глобальных общих объектов.

 

6 минут назад, esaulenka сказал:

В общем - нет, никогда и ни за что!

А как по мне - идея вполне жизнеспособная... Просто, ИМХО, нужно получше разобраться и будет все очевидно.

Я прям загорелся, надо опробовать - как раз напросился тут проект простейший - измерить температуру и по запросу отправить ее ответом по UART

[Forger 17]

1 minute ago, Arlleex said:

Прочитал. Понял 2% текста

Там самое важное как раз изложено вначале. Что, зачем и для чего.

Далее идет полная ботва по реализации, кстати, она там не самая удачная 

 

1 minute ago, Arlleex said:

Я просто хотел предложить средство обхода зависимости от глобальных общих объектов.

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

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

[Arlleex 131]

Только что, Forger сказал:

Там самое важное как раз изложено вначале. Что, зачем и для чего.

Вот начало-то я как раз понял и даже мысленно сказал себе "да это же прописные истины" А дальше - да, для меня пока что не подъемно...

[alexunder 4]

Прочёл всю тему, но так и не увидел явных аргументов и предпосылок для применения ООП. А значит что? А значит, автору ООП для данной задачи не нужно.