Easyelectronics.ru

Электроника для всех
Текущее время: 18 окт 2019, 19:27

Часовой пояс: UTC + 5 часов



JLCPCB – Прототипы печатных плат за $2/10pcs (Любой цвет!)
Крупнейший производитель печатных плат и прототипов. Более 600000 клиентов и свыше 10000 заказов в день!
Получите скидку на почтовую отправку при первом заказе в JLCPCB!

Начать новую тему Ответить на тему  [ Сообщений: 87 ]  На страницу Пред.  1, 2, 3, 4  След.
Автор Сообщение
 Заголовок сообщения: Re: STM32+SEGGER+FreeRTOS+C++
СообщениеДобавлено: 06 июн 2018, 16:44 
Старожил
Аватара пользователя

Зарегистрирован: 23 сен 2012, 20:35
Сообщения: 2471
siarzhuk писал(а):
Динамическая память предполагает и контроль успешности выделения перед использованием, т.е. самое страшное что случится - переход в состояние ошибки.

И чем это отличается от зависания? А что делать если управляемый объект в это время в опасном состоянии?
siarzhuk писал(а):
Да и в случае отказа можно попытаться malloc_trim-ом освобождённые куски слить и попробовать ещё раз. Но, как и всё в этой области - без 100%-ной гарантии успешности.

В нормальной реализации хипа дефрагментация делается при освобождении куска памяти. Но, естественно, и это не гарантирует успешного выделения памяти.
siarzhuk писал(а):
evsi писал(а):
P.P.S. динамическое распределение памяти в эмбеде вполне применимо, но стандартные new/delete для этого подходят плохо.

VMT для объекта инициализировать можно конечно и placement new вызвать на полученном из malloc блоке памяти, но у стандартного new это получится надёжнее.

Во-первых, placement new отличается от обычного только тем, что работает по готовому куску памяти, а не по тому, который вернул malloc. То есть надежность инициализации VMT там ровно такая же. Во-вторых, зачем вам вообще VMT? Вы что, собрались иерархию типов городить?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32+SEGGER+FreeRTOS+C++
СообщениеДобавлено: 06 июн 2018, 18:07 
Заглядывает иногда

Зарегистрирован: 15 ноя 2015, 12:11
Сообщения: 173
evsi писал(а):
siarzhuk писал(а):
Динамическая память предполагает и контроль успешности выделения перед использованием, т.е. самое страшное что случится - переход в состояние ошибки.

И чем это отличается от зависания?

Наличием обратной связи.
evsi писал(а):
А что делать если управляемый объект в это время в опасном состоянии?

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

В newlib пришлось trim-ать.
evsi писал(а):
Во-первых, placement new отличается от обычного только тем, что работает по готовому куску памяти, а не по тому, который вернул malloc.

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32+SEGGER+FreeRTOS+C++
СообщениеДобавлено: 06 июн 2018, 18:39 
Старожил
Аватара пользователя

Зарегистрирован: 23 сен 2012, 20:35
Сообщения: 2471
siarzhuk писал(а):
evsi писал(а):
И чем это отличается от зависания?

Наличием обратной связи.

То есть, по сути, ничем. Устройство не работает, а причина интересна только программисту.
siarzhuk писал(а):
evsi писал(а):
А что делать если управляемый объект в это время в опасном состоянии?

Получить все ресурсы до входа в транзакцию.

Чем это отличается от того, что бы не пользоваться динамическим выделением памяти? Не считая, конечно, того, что ситуация "не смогли начать транзакцию", в случае без динамического выделения памяти, в принципе невозможна.
siarzhuk писал(а):
evsi писал(а):
Во-первых, placement new отличается от обычного только тем, что работает по готовому куску памяти, а не по тому, который вернул malloc.

Атомарность создания объекта разная.

С этого места поподробнее, пожалуйста.
siarzhuk писал(а):
Плейсменту можно подсунуть блок меньшего размера ...

Сдуру можно и хер сломать. Или мы собираемся обсуждать возможные ошибки программиста в каждом случае?
siarzhuk писал(а):
evsi писал(а):
Во-вторых, зачем вам вообще VMT? Вы что, собрались иерархию типов городить?

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32+SEGGER+FreeRTOS+C++
СообщениеДобавлено: 07 июн 2018, 00:32 
Заглядывает иногда

Зарегистрирован: 15 ноя 2015, 12:11
Сообщения: 173
evsi писал(а):
То есть, по сути, ничем. Устройство не работает, а причина интересна только программисту.

По вашему пересылать два килограмма кирпича через полшарика, чтобы выяснить что в нём банально выгорела UV лампа, и везти обратно с новой лампой - это эквивалентно получению по e-mail кода ошибки и высылке пострадавшему картонки с лампой. Не, уже проходили .... :)
evsi писал(а):
Чем это отличается от того, что бы не пользоваться динамическим выделением памяти?

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

"Ненадёжность стандартного new" вас отвратила, осмелюсь напомнить.
evsi писал(а):
Хех. Вы опираетесь на возможность и исходя из нее придумываете архитектуру.

Я опираюсь на конкретный прототип, который мне разработчики притащили для оживления, и на опыт поддержки предыдущего поколения аналогичного устройства - и шишки набитые с ним. Да и, человек у которого в руках молоток всегда весьма искушаем завернуть шуруп известным образом. И если "классики" себя уже показали хорошо - какой ленивец откажется их скопипейстить? Разве что только кто типа меня, что в известном месте играет чего-то нового попробовать. ;-)
evsi писал(а):
Но вполне удобное решение возможно и с другой архитектурой.

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

Класс - это методы, а данные - это объект, и от того, что в классе вместо одного набора данных будет массив наборов на все "объекты" во вселенной - да на одной индексации разорение. Не говоря о том, что работать будет в среднем 100/N % этих данных, где N - количество возможных типов модулей. А их мне обещают только больше и больше со временем.
evsi писал(а):
В добавок, весь код работы с конкретным устройством оказывается привязан к конкретному классу (или темплейту), а не размазан по иерархии.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32+SEGGER+FreeRTOS+C++
СообщениеДобавлено: 07 июн 2018, 08:29 
Старожил
Аватара пользователя

Зарегистрирован: 23 сен 2012, 20:35
Сообщения: 2471
siarzhuk писал(а):
evsi писал(а):
То есть, по сути, ничем. Устройство не работает, а причина интересна только программисту.

По вашему пересылать два килограмма кирпича через полшарика, чтобы выяснить что в нём банально выгорела UV лампа, и везти обратно с новой лампой - это эквивалентно получению по e-mail кода ошибки и высылке пострадавшему картонки с лампой. Не, уже проходили .... :)

Такая "обратная связь" реализуема в любом варианте. Не о том речь вовсе.
siarzhuk писал(а):
evsi писал(а):
Чем это отличается от того, что бы не пользоваться динамическим выделением памяти?

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

Динамическое выделение и есть источником энтропии.

siarzhuk писал(а):
Класс - это методы, а данные - это объект, и от того, что в классе вместо одного набора данных будет массив наборов на все "объекты" во вселенной - да на одной индексации разорение. Не говоря о том, что работать будет в среднем 100/N % этих данных, где N - количество возможных типов модулей. А их мне обещают только больше и больше со временем.

Думаю вам самое время почитать об паттерне композит. А сколько их будет работать не играет никакой роли. Объем неиспользуемого в каждый момент кода будет +- одинаков при любом варианте.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32+SEGGER+FreeRTOS+C++
СообщениеДобавлено: 08 июн 2018, 11:07 
Заглядывает иногда

Зарегистрирован: 15 ноя 2015, 12:11
Сообщения: 173
evsi писал(а):
Такая "обратная связь" реализуема в любом варианте. Не о том речь вовсе.

Речь о том, что 0 из malloc-а - не приговор устройству. Куча - всего-лишь один из "периферийных модулей" мо́гущих временно отказать в обслуживании.
evsi писал(а):
Динамическое выделение и есть источником энтропии.

Именно это я и имел ввиду. ;-)
evsi писал(а):
Думаю вам самое время почитать об паттерне композит.

Сдаётся мне, что схожесть терминов играет тут злую шутку. Composite pattern как один из 23-ёх (?), своими деревьями и кучкованием, к моему контексту не приклеивается даже волшебной синей изолентой, а имели вы в виду composition АКА агрегацию АКА [банальное] включение - всем известная альтернатива наследованию. Так?
evsi писал(а):
А сколько их будет работать не играет никакой роли. Объем неиспользуемого в каждый момент кода будет +- одинаков при любом варианте.

Вопрос не в коде - вопрос в данных, используемых для каждого физического модуля, - и при отказе от динамики резервировать место надо по максимуму каждого типа - то бишь нужна "матрица" 6 х N в и к тому же заведомо разреженная - так как работать одновременно могут лишь 1 - 6 блоков.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32+SEGGER+FreeRTOS+C++
СообщениеДобавлено: 08 июн 2018, 12:32 
Старожил
Аватара пользователя

Зарегистрирован: 23 сен 2012, 20:35
Сообщения: 2471
siarzhuk писал(а):
Речь о том, что 0 из malloc-а - не приговор устройству. Куча - всего-лишь один из "периферийных модулей" мо́гущих временно отказать в обслуживании.

0 из malloc-а значит, что вы не можете начать "транзакцию", следовательно устройство не может выполнять свои функции. Что это как не приговор устройству?
siarzhuk писал(а):
evsi писал(а):
Думаю вам самое время почитать об паттерне композит.

Сдаётся мне, что схожесть терминов играет тут злую шутку. Composite pattern как один из 23-ёх (?), своими деревьями и кучкованием, к моему контексту не приклеивается даже волшебной синей изолентой, а имели вы в виду composition АКА агрегацию АКА [банальное] включение - всем известная альтернатива наследованию. Так?

Нет. Речь шла именно о композите. Думаю, вдумчивое прочтение первых четырех предложений из вики вам поможет понять о чем идет речь.
siarzhuk писал(а):
evsi писал(а):
А сколько их будет работать не играет никакой роли. Объем неиспользуемого в каждый момент кода будет +- одинаков при любом варианте.

Вопрос не в коде - вопрос в данных, используемых для каждого физического модуля, - и при отказе от динамики резервировать место надо по максимуму каждого типа - то бишь нужна "матрица" 6 х N в и к тому же заведомо разреженная - так как работать одновременно могут лишь 1 - 6 блоков.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32+SEGGER+FreeRTOS+C++
СообщениеДобавлено: 09 июн 2018, 08:41 
Старожил
Аватара пользователя

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 2349
Создал шаблончик.
Может "академически" неправильно - извиняйте, только учусь.
Segger+FreeRTOS10+SPL+потокобезопасный new/delete
FreeRTOS работает с системной кучей.
https://yadi.sk/d/Dj18xB-W3XXUUh

Камень - stm32f103ret6


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32+SEGGER+FreeRTOS+C++
СообщениеДобавлено: 10 июн 2018, 00:37 
Заглядывает иногда

Зарегистрирован: 15 ноя 2015, 12:11
Сообщения: 173
evsi писал(а):
0 из malloc-а значит, что вы не можете начать "транзакцию", следовательно устройство не может выполнять свои функции.

избавились от ненужного, опционально trim-анули, получили требуемое, начали "транзакцию".
evsi писал(а):
Думаю, вдумчивое прочтение первых четырех предложений из вики вам поможет понять о чем идет речь.

Задача несколько изощрённе, чем "возможность управления группой как одним объектом", и беглый взгляд на типовую реализацию паттерна, предлагающую interface прошибает на смешок: -"Привет VMT, <тут слова с простыми корнями>".
evsi писал(а):
О да, выделить один байт (в котором каждый бит соответствует одному слоту) это офигенный оверхед.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32+SEGGER+FreeRTOS+C++
СообщениеДобавлено: 03 июл 2019, 21:37 
Старожил
Аватара пользователя

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 2349
Начал щупать шаблоны.
Хочу сделать шаблоны для настройки периферии и работы с ней.
Начну c USART.
Можно и на регистрах сделать, или на LL - не принципиально, но мне быстрее на SPL, так как класс (не шаблонный) уже успешно работает.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32+SEGGER+FreeRTOS+C++
СообщениеДобавлено: 03 июл 2019, 21:57 
Старожил
Аватара пользователя

Зарегистрирован: 13 янв 2018, 21:36
Сообщения: 1013
Держи нас в курсе, обязательно! :D


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32+SEGGER+FreeRTOS+C++
СообщениеДобавлено: 04 июл 2019, 13:45 
Старожил
Аватара пользователя

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 2349
Обожаю изучать что то новое, преувлекательнейшее занятие.

Сколько книжек не читай, все равно все познавать приходится "методом тыка".

Определил переменные времени компиляции (в прошивке места не занимают)

Код:
constexpr static uint32_t USART1_RX_SIZE_BUF = 1024;
constexpr static uint32_t USART1_TX_SIZE_BUF = 1024;

constexpr static uint32_t USART2_RX_SIZE_BUF = 1024;
constexpr static uint32_t USART2_TX_SIZE_BUF = 1024;


constexpr static uint32_t USART3_RX_SIZE_BUF = 1024;
constexpr static uint32_t USART3_TX_SIZE_BUF = 1024;




Создал шаблонную структуру для кольцевого буфера
Код:
template<uint32_t RX_BUFFER_SIZE, uint32_t TX_BUFFER_SIZE>
struct RingBuffer {
public:
   RingBuffer(): txBufTail(0), txBufHead(0), txCount(0),
   rxBufTail(0), rxBufHead(0),rxCount(0){};
   //передающий буфер
   unsigned char TxBuf[TX_BUFFER_SIZE];
   uint32_t txBufTail;
   uint32_t txBufHead;
   uint32_t txCount;

   //приемный буфер
   unsigned char RxBuf[TX_BUFFER_SIZE];
   uint32_t rxBufTail;
   uint32_t rxBufHead;
   uint32_t rxCount;


};



Перечисляемый тип, у нас же несколько UARTов может быть
Код:
enum usart_x
{
   usart_1,
   usart_2,
   usart_3,
   usart_4
};
typedef usart_x TUSART;




Пустой шаблонный класс для UART
Код:
template<TUSART  USARTx>

class Usart {

public:


private:


};




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

Код:

template<>
class Usart<usart_1>
{
public:

   Usart(){


      };

   void init(void){

   //   rx_buff[5]='5';
   };

//static unsigned char rx_buff[1024];
static RingBuffer<USART1_RX_SIZE_BUF,USART1_TX_SIZE_BUF> ring_buffer;
private:


};

//template<>
//unsigned char Usart<usart_1>::rx_buff[1024];
RingBuffer<USART1_RX_SIZE_BUF,USART1_TX_SIZE_BUF> Usart<usart_1>::ring_buffer;





В main создаём экземпляры

Код:

   Usart<usart_1> uart_1;
   Usart<usart_2> uart_2;
   Usart<usart_3> uart_3;
   //Usart<usart_1>::rx_buff[0]='A';
   //uart_1.rx_buff[1]='R';
   uart_1.ring_buffer.txCount=0;
   uart_1.ring_buffer.TxBuf[0]=2;
   uart_2.init();
   uart_1.init();
   uart_3.init();



Пока все.
Проверяю на "живом" железе.

Ах, да...
Show Тут же прерывания


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32+SEGGER+FreeRTOS+C++
СообщениеДобавлено: 04 июл 2019, 14:23 
Старожил

Зарегистрирован: 23 янв 2016, 15:37
Сообщения: 1016
Pingvin писал(а):
Создал шаблонную структуру для кольцевого буфера

RingBuffer должен быть универсальным классом, чтобы его можно было использовать и в других местах, т.е. он должен принимать тип элементов и не должен совмещать в себе два буфер сразу:
Код:
template<typename T, uint32_t Capacity>

Дальше, я не вижу нигде volatile, конечно его можно добавить в виде приведения непосредственно в функциях, но сомневаюсь, что ты именно это хочешь сделать :) Без volatile банальная проверка на empty(), которая сравнивает пару указателей на начало и конец, с включеной оптимизайией будет просто подвисать. И размер тут не нужен, его лучше вычислять, потому что тогда не нужны атомарные операции. Главное сначала писать или читать данные, потом изменять индексы, например, так:
Код:
volatile uint32_t head, tail;
...
void pushBack(const T& value)
{
   _assert_(size() < Capacity);

   if constexpr (pot)
   {
      uint32_t tmp = tail;
      buf[tmp & mask] = value;
      asm volatile ("" ::: "memory");   // memory barrier
      tail = ++tmp;
   }
   else
   {
      uint32_t tmp = tail;
      buf[tmp] = value;
      asm volatile ("" ::: "memory");
      if (++tmp > Capacity) tmp = 0;
      tail = tmp;
   }
}

Часто встречается такой такой код:
Код:
buf[tail++ & mask] = value;

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

Цитата:
Код:
enum usart_x
{
   usart_1,
   usart_2,
   usart_3,
   usart_4
};
typedef usart_x TUSART;

Лучше сразу учиться использовать более строгий enum class. И заодно using вместо typedef. Typedef в современном C++ в принципе не нужен.

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

Я делал так:

Код:
template<uint32_t TxBufSize, uint32_t RxBufSize>
using Usart1 = UsartT<USART1_BASE, USART1_IRQn, TxBufSize, RxBufSize>;

template<uint32_t TxBufSize, uint32_t RxBufSize>
using Usart2 = UsartT<USART2_BASE, USART2_IRQn, TxBufSize, RxBufSize>;
...

Usart1<256, 512> usart1;
Usart2<32, 8> usart2;

void USART1_IRQHandler() { usart1.IrqHandler(); } // нужно если используется буферизация
void USART2_IRQHandler() { usart2.IrqHandler(); }

....
usart1.init<PinA<10, 7>, PinA<9, 7>>(9600); // пины нужны только здесь
usart2.init<PinB<3, 7>, PinB<4, 7>>(115200);



Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32+SEGGER+FreeRTOS+C++
СообщениеДобавлено: 04 июл 2019, 14:41 
Старожил
Аватара пользователя

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 2349
Нельзя буфера делать статическими!
Сразу оперативу занимают без создания экземпляря.
Буду думать...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32+SEGGER+FreeRTOS+C++
СообщениеДобавлено: 04 июл 2019, 14:48 
Старожил
Аватара пользователя

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 2349
Ну мне пока многое незнакомо и непонятно.
Как работает using к примеру?
Что за ассемблерные вставки, для чего?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32+SEGGER+FreeRTOS+C++
СообщениеДобавлено: 04 июл 2019, 15:00 
Старожил

Зарегистрирован: 23 янв 2016, 15:37
Сообщения: 1016
Pingvin писал(а):
Как работает using к примеру?

Код:
using usart_x = TUSART;

using FP = void(*)(int);

template<uint32_t pin, uint32_t af = 0>
using PinA = PinT<GPIOA_BASE, pin, af>;

А typedef с шаблонами вообще не работает...

Цитата:
Что за ассемблерные вставки, для чего?

Они дают гарантии, что к этому моменту запись в переменные действительно произошла, т.е. инкремент индекса произойдет после buf[...] = value. Компилятор может менять порядок выполнения, есть некоторые ограничения для volatile, но в данном случае я не могу точно сказать, что этого достаточно.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32+SEGGER+FreeRTOS+C++
СообщениеДобавлено: 04 июл 2019, 15:03 
Старожил
Аватара пользователя

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 2349
Цитата:
using usart_x = TUSART;

using FP = void(*)(int);

template<uint32_t pin, uint32_t af = 0>
using PinA = PinT<GPIOA_BASE, pin, af>;



Ну что это всё значит?
Как это используется?
Аналог #define что ли?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32+SEGGER+FreeRTOS+C++
СообщениеДобавлено: 04 июл 2019, 15:06 
Старожил

Зарегистрирован: 23 янв 2016, 15:37
Сообщения: 1016
Pingvin писал(а):
Аналог #define что ли?

Какого еще define.... Сказал же, что лучше использовать using вместо typedef, следовательно это улучшенный аналог typedef.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32+SEGGER+FreeRTOS+C++
СообщениеДобавлено: 04 июл 2019, 15:15 
Старожил
Аватара пользователя

Зарегистрирован: 13 янв 2018, 21:36
Сообщения: 1013
При работе с шаблонами typedef не всегда работает и ему на замену пришёл using. Объяснять не берусь, просто поверь и/или переспроси подробней у гугла.

Мне кажется, ты не совсем понимаешь для чего нужны шаблоны. Зачем шаблон для класса USART, объекты которого отличаются только номером? Для этого достаточно параметра в конструктор и создавай хоть N объектов на разные порты. Шаблон нужен, когда у тебя один и тот же алгоритм для разных типов. Reflector, например, показал тебе что кольцевой буфер это вообще-то просто какой-то классс. Как он реализован в общем случае по барабану для работы уарта. При создании объекта ты через шаблон его укажешь и все.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32+SEGGER+FreeRTOS+C++
СообщениеДобавлено: 04 июл 2019, 15:33 
Старожил

Зарегистрирован: 23 янв 2016, 15:37
Сообщения: 1016
Pingvin писал(а):
Нельзя буфера делать статическими!
Сразу оперативу занимают без создания экземпляря.

Попробуй сделать как-то так(внутри статический массив):
Код:
Buffer<int, 256> buf1;
Buffer<int, 256> buf2;

Эти классы идентичны, у них будет один статический буфер на двоих...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32+SEGGER+FreeRTOS+C++
СообщениеДобавлено: 04 июл 2019, 21:45 
Старожил
Аватара пользователя

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 2349
Цитата:

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


На это, кстати - попадался.
Пока решил вопрос критическими секциями.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32+SEGGER+FreeRTOS+C++
СообщениеДобавлено: 04 июл 2019, 21:49 
Старожил
Аватара пользователя

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 2349
Тут кстати про using =
Псевдоним типа называется
https://ru.cppreference.com/w/cpp/language/type_alias
Спасибо, узнал кое-что новое (или вспомнил забытое).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32+SEGGER+FreeRTOS+C++
СообщениеДобавлено: 04 июл 2019, 23:58 
Старожил

Зарегистрирован: 08 июл 2013, 17:00
Сообщения: 234
Как-то странно всё это выглядит..

У всех UART (УАПП) есть общая часть:
- настройка скорости;
- формат посылки;
- размер буфера.

Есть специфическая:
- приём-передача по одному байту;
- приём-передача через ПДП;
- задействование кольцевого буфера;

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32+SEGGER+FreeRTOS+C++
СообщениеДобавлено: 05 июл 2019, 06:22 
Старожил
Аватара пользователя

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 2349
tonyk писал(а):
Как-то странно всё это выглядит..

У всех UART (УАПП) есть общая часть:
- настройка скорости;
- формат посылки;
- размер буфера.

Есть специфическая:
- приём-передача по одному байту;
- приём-передача через ПДП;
- задействование кольцевого буфера;

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

Всё верно, пришёл к такому же выводу.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32+SEGGER+FreeRTOS+C++
СообщениеДобавлено: 05 июл 2019, 08:44 
Старожил

Зарегистрирован: 08 июл 2013, 17:00
Сообщения: 234
Класс УАПП, по-моему, вообще разумно делать как синглтон. Даже если приспичит на ходу переключаться из консоли в режим Модбаса, то просто порождается наследник от консоли и Модбаса, который в зависимости от режима работы вызывает методы обработки того или иного своего предка.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 87 ]  На страницу Пред.  1, 2, 3, 4  След.

Часовой пояс: UTC + 5 часов


Кто сейчас на конференции

Сейчас этот форум просматривают: Google [Bot], serglg


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB