Easyelectronics.ru • Просмотр темы - STM32+SEGGER+FreeRTOS+C++

Easyelectronics.ru

Электроника для всех
Текущее время: 16 авг 2018, 10:51

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



    • JLCPCB - Прототипы 10 PCBs всего за 2$ (100*100mm, 2-layer)
    • Как мы делаем платы, смотрите на YouTube
    • Крупнейшая китайская фабрика прототипов. 300000+ заказчиков и 10000+ заказов в день!
    • LCSC - Крупнейший китайский онлайн магазин комплектующих.

Начать новую тему Ответить на тему  [ Сообщений: 34 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: STM32+SEGGER+FreeRTOS+C++
СообщениеДобавлено: 04 июн 2018, 20:10 
Старожил
Аватара пользователя

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 1860
Хочу создать шаблон для Segger IDE под С++ с FreeRTOS.
Как настроить проект, какие дополнительные либы подключать, какие функции перегружать, какие флаги ставить?
Хочу использовать STL с её контейнерами.
Пока понял, что у FreeRTOS есть реализация malloc и можно реализовать свои
Show new и delete


Что ещё?


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

Зарегистрирован: 04 окт 2011, 10:19
Сообщения: 1375
Мозг


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

Зарегистрирован: 01 фев 2013, 02:21
Сообщения: 225
Вот в SEGGER и спрашивайте


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

Зарегистрирован: 29 янв 2010, 15:41
Сообщения: 1125
Откуда: Германия
операторы new и delete намного сложнее, чем то, что вы написали.
Все что вам надо, это переопределить функции
Код:
void * malloc ( size_t size )
{
  void * ptr;
  ptr = HeapAlloc( size );
  return ptr;
}

void free ( void * ptr )
{
  HeapFree( ptr );
}

void * realloc ( void * ptr, size_t size )
{
  HeapFree( ptr );
  return HeapAlloc( size );
}

void * calloc ( size_t num, size_t size )
{
  return HeapAllocClear( num * size );
}

ну и от FreeRTOS'а:
Код:
void *pvPortMalloc( size_t xSize ) PRIVILEGED_FUNCTION
{
  return HeapAlloc( xSize );
}

void vPortFree( void *pv ) PRIVILEGED_FUNCTION
{
  HeapFree( pv );
}

А операторы new и delete сами выйдут на это malloc'и.
Отличие их от того, что вы написали, в том, что они еще вызывают конструкторы/деструкторы для сложных типов типа структур и классов, чего у в вашей реализации нет.

_________________
Мои поделки
http://www.fun-electronic.net/


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

Зарегистрирован: 15 ноя 2015, 12:11
Сообщения: 101
MasterAlexei писал(а):
Все что вам надо, это переопределить функции
Код:
void * malloc ( size_t size )
{
  void * ptr;
  ptr = HeapAlloc( size );
  return ptr;
}


В контексте FreeRTOS-а разумнее его менеджер памяти и использовать, нет?
MasterAlexei писал(а):
А операторы new и delete сами выйдут на это malloc'и.

А не на глобальную-ли operator new() из исходного сообщения они выйдут для получения памяти?
MasterAlexei писал(а):
Отличие их от того, что вы написали, в том, что они еще вызывают конструкторы/деструкторы для сложных типов типа структур и классов, чего у в вашей реализации нет.

обработки set_new_handler-a там не хватает, а как глобальная функция без знаний о объекте сможет его сконструировать?


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

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 1860
Разве это не задача компилятора создавать (вставлять вызовы) на конструкторы и деструкторы?
new и delete тут ни при делах, ИМХО.
Их задача - память выделить(очистить) и передать указатель.


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

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 1860
Есть проект, рабочий, написан грамотным товарищем
https://github.com/DAlexis/caustic-lasertag-system/blob/master/cpp-sources/universal-device/high-level/src/core/os-wrappers.cpp

Никаких конструкторов и деструкторов нет, как видите

Код:
///////////////////////////////////////
/// new/delete wrappers

void * operator new(std::size_t n)
{
   CritialSection cs; cs.lock();
   Kernel::heapAllocatedTotal += n;
    return malloc(n);
}
void operator delete(void * p)
{
   CritialSection cs; cs.lock();
    free(p);
}

void *operator new[](std::size_t n)
{
   CritialSection cs; cs.lock();
   Kernel::heapAllocatedTotal += n;
   return malloc(n);
}

void operator delete[](void *p) throw()
{
   CritialSection cs; cs.lock();
    free(p);
}



CritialSection cs; cs.lock(); - специальный класс для мьютекса.

Но реализации malloc я не нашел.
Тут так же используется FreeRTOS и есть функции
Код:
/*-----------------------------------------------------------*/

void *pvPortMalloc( size_t xWantedSize )
{
void *pvReturn;

   vTaskSuspendAll();
   {
      pvReturn = malloc( xWantedSize );
      traceMALLOC( pvReturn, xWantedSize );
   }
   ( void ) xTaskResumeAll();

   #if( configUSE_MALLOC_FAILED_HOOK == 1 )
   {
      if( pvReturn == NULL )
      {
         extern void vApplicationMallocFailedHook( void );
         vApplicationMallocFailedHook();
      }
   }
   #endif

   return pvReturn;
}
/*-----------------------------------------------------------*/

void vPortFree( void *pv )
{
   if( pv )
   {
      vTaskSuspendAll();
      {
         free( pv );
         traceFREE( pv, 0 );
      }
      ( void ) xTaskResumeAll();
   }
}



но названия функций другие.
Как их надо связать с malloc и free ?
Или компилятор свяжет их автоматически?

Если есть глобальная new - как её перекрыть?


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

Зарегистрирован: 22 июл 2017, 11:48
Сообщения: 2103
siarzhuk писал(а):
В контексте FreeRTOS-а разумнее его менеджер памяти и использовать, нет?

Можно создать две непересекающиеся в ОЗУ кучи, одну для RTOS, другую для стандартного аллокатора. Одну кучу оставить для работы RTOS - выделение памяти под задачи, очереди, семафоры. А другую кучу использовать для выделения памяти средствами стандартного аллокатора для каких-то буферов, которые не предполагается хранить ни в стеке задачи, ни в очереди. Например, такую отдельную кучу можно создать в SDRAM и использовать ее для графических применений. Короче, там, где идет потоковое обращение. Не секрет, что SDRAM любит потоковую передачу большими блоками, а одиночные обращения будут медленными. Поэтому, использовать SDRAM для кучи RTOS малоэффективно. Механизмы RTOS всегда будут обращаться к SDRAM одиночными запросами, даже если это копирование в/из очереди.
И еще. Когда работаете со стандартным malloc в отдельной куче, очень-очень желательно это выполнять внутри критической секции RTOS, чтобы не получить неприятных сюрпризов из-за переключения задач и параллельных запросов.


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

Зарегистрирован: 29 янв 2010, 15:41
Сообщения: 1125
Откуда: Германия
Pingvin писал(а):
Разве это не задача компилятора создавать (вставлять вызовы) на конструкторы и деструкторы?
new и delete тут ни при делах, ИМХО.
Их задача - память выделить(очистить) и передать указатель.

Компилятор скомпилирует ваш вызов new/delete на библиотечную функцию. И нет - это не задача компилятора - вызывать конструктор/дуструктор, а задача программиста, который писал библиотечную функцию, и позаботился о вызовах конструкторов и деструкторов.
Цитата:
Есть проект, рабочий, написан грамотным товарищем

Я в принципе тоже не совсем туп, как пробка, и в моих проектах я использую те "заглушки", что привел тут, и ничего более. И работает все так, как надо и как по стандарту написано. В GCC и в IAR компиляторах.
При этом вызываются все конструкторы и деструкторы автоматом, и в итоге все запросы к new/delete попадают в мои Heap* функции.

Тем более, если почитать внимательно про то, как работает оператор new, особенно, если нет больше свободной памяти...

По умолчанию и по стандарту в этом случае new выпадает в exception (по нашему в HardFault). Чтоб этого не происходило, надо либо свой обработчик объявлять:
Код:
void no_memory ()
{
  printErrorMsg( "\n\n\nFailed to allocate memory! Aborting\n" );
  while( 1 )
  {
    __asm("BKPT #0\n");
  }
}
...
std::set_new_handler(no_memory);

либо при каждом обращении к new писать
TListItem * newListArray = new( std::nothrow ) TListItem[ count + 1 ];

В случае своего переопределения, не известно, в каком именно месте компилятор встроит вызов именно ваших операторов new/delete - до или после этих вот моментов. Если вообще будет делать так, как по стандарту.

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

_________________
Мои поделки
http://www.fun-electronic.net/


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

Зарегистрирован: 23 сен 2012, 20:35
Сообщения: 1898
Pingvin писал(а):
Хочу использовать STL с её контейнерами.

Зачем?


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

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 1860
MasterAlexei писал(а):
Компилятор скомпилирует ваш вызов new/delete на библиотечную функцию. И нет - это не задача компилятора - вызывать конструктор/дуструктор, а задача программиста, который писал библиотечную функцию, и позаботился о вызовах конструкторов и деструкторов.


Когда выходим за область видимости переменной, мы же не вызываем явно каждый раз деструктор.
Это делает компилятор - разве не так?

И мне нужно, чтобы использовалась куча RTOS.
Все обращения будут из потоков.


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

Зарегистрирован: 29 янв 2010, 15:41
Сообщения: 1125
Откуда: Германия
Pingvin писал(а):
Когда выходим за область видимости переменной, мы же не вызываем явно каждый раз деструктор.
Это делает компилятор - разве не так?


Вы малость путаете вещи.
операторы new/delete, точнее их работу, и создание или уничтожение переменных.
естественно, компилятор вставляет вызовы конструктора и деструктора при создании и уничтожении объектов, как статических, так и тех, что в стеке (локальные переменные/объекты)
Но когда вы явно пишете в коде :
ObjClass * a = new ObjClass;
то тут компилятор тупо вызывает реализацию оператора new из библиотеки, и что вы там написали - дело уже десятое.
И когда управление выйдет за пределы видимости переменной ObjClass * a, то деструктор объекта вызван НЕ будет.
Это раз.
Два это когда создается массив из таких объектов:

ObjClass * arr = new ObjClass[10];
В таком случае оператор new вызовет конструкторы для каждого из 10ти объектов, как и при вызове delete [] arr; оператор delete вызовет деструкторы для каждого из 10 объектов массива. Это делают именно операторы сами, НЕ компилятор!

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

_________________
Мои поделки
http://www.fun-electronic.net/


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

Зарегистрирован: 15 ноя 2015, 12:11
Сообщения: 101
MasterAlexei писал(а):
В той реализации, что приведена выше, этот момент вообще не освещен никак, т.е. при создании массивов уже все полетит к чертям.

Куда надо туда и полетит - обращение к стандартным переопределяемым функциям-аллокаторам происходит до вызова конструкторов http://en.cppreference.com/w/cpp/memory ... erator_new.

Код:
void* operator new  ( std::size_t count );   (1)    
void* operator new[]( std::size_t count );   (2)
[...]
1) Called by non-array new-expressions to allocate storage required for a single object. The standard library implementation allocates count bytes from free store. [...]
2) Called by the array form of new[]-expressions to allocate [b]all storage required for an array[/b] (including possible new-expression overhead). The standard library implementation calls version (1)

А применять конструкторы на полученную из этих функций память - забота "new / new[] expression" а не программиста.


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

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 1860
MasterAlexei писал(а):
операторы new и delete намного сложнее, чем то, что вы написали.
Все что вам надо, это переопределить функции
Код:
void * malloc ( size_t size )
{
  void * ptr;
  ptr = HeapAlloc( size );
  return ptr;
}

void free ( void * ptr )
{
  HeapFree( ptr );
}

void * realloc ( void * ptr, size_t size )
{
  HeapFree( ptr );
  return HeapAlloc( size );
}

void * calloc ( size_t num, size_t size )
{
  return HeapAllocClear( num * size );
}

ну и от FreeRTOS'а:
Код:
void *pvPortMalloc( size_t xSize ) PRIVILEGED_FUNCTION
{
  return HeapAlloc( xSize );
}

void vPortFree( void *pv ) PRIVILEGED_FUNCTION
{
  HeapFree( pv );
}

А операторы new и delete сами выйдут на это malloc'и.
Отличие их от того, что вы написали, в том, что они еще вызывают конструкторы/деструкторы для сложных типов типа структур и классов, чего у в вашей реализации нет.



Попробовал так сделать - ошибку выдает.

undefined reference to `HeapAlloc'


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

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 1860
Функции malloc и free нужно самому определять, или они должны работать "из коробки".
Или какую-нибудь newlib нужно подключать?


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

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




https://sourceforge.net/p/freertos/disc ... /?limit=25


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

Зарегистрирован: 29 янв 2010, 15:41
Сообщения: 1125
Откуда: Германия
Pingvin писал(а):
Попробовал так сделать - ошибку выдает.
undefined reference to `HeapAlloc'

Естественно - HeapAlloc HeapFree - мои собственные функции. Вы должны написать свои, либо вызывать их из менеджеров кучи FreeRTOSa. Я в них даже не заглядывал.

_________________
Мои поделки
http://www.fun-electronic.net/


Последний раз редактировалось MasterAlexei 05 июн 2018, 22:25, всего редактировалось 2 раз(а).

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

Зарегистрирован: 29 янв 2010, 15:41
Сообщения: 1125
Откуда: Германия
siarzhuk писал(а):
А применять конструкторы на полученную из этих функций память - забота "new / new[] expression" а не программиста.

Слово expression вы как перевели?
siarzhuk писал(а):
...
Куда надо туда и полетит -
...

Вы привели описание действия операторов из стандартной библиотеки.
Товарищ Pingvin пытается создать свою библиотеку взамен той стандартной, описание которой вы тут привели, свои собственные операторы new/delete. Так что это именно его забота - делать все эти вызовы конструкторов/деструкторов.

Упдт.
Поглядел сейчас, чего получается в дебагере на месте вызова operator new. Он сначала вызывает malloc, и инлайнит вызов конструктора объекта.
Так же глянул исходники этого самого оператора new в GCC. Скорее всего, все же именно что сам компилятор GCC с его стандартной библиотекой, при синтаксическом разборе вставляет вызовы конструкторов (как и говорил siarzhuk). Интересно было бы посмотреть, что будет если переопределить этот оператор new[] на свой именно, а не из библиотеки.
Сейчас попробую этот момент у себя.

Упдт 2.
Да - GCC инлайнит вызовы конструкторов сразу после вызова либо библиотечного, который в итоге попадает в malloc, либо пользовательского operator new.
Т.е. это именно сам GCC компилятор при синтаксическом разборе кода вставляет либо один вызов, либо цикл на количество запрошенных объектов (например тут TObject * myObjects = new TObject[ 10 ]; )

Кстати, Pingivn, в приведенном вами последнем примере ошибки.
Надо звездочки расставить:
Код:
void * operator new(size_t size)
{
  void * p;
    p = malloc(size);

  return p;
}

_________________
Мои поделки
http://www.fun-electronic.net/


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

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 1860
Да нет у меня задачи переписать стандартные библиотеки.
Если будет работать со штатными - отлично.
Но все должно быть потокобезопасно.

В segger все работает "из коробки" (malloc, free, new, delete).

Осталось обеспечить потокобезопасность.
Как это лучше сделать?

Проверять семафор при каждом вызове new?
Но ведь есть и неявные вызовы при работе с контейнерами, например.


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

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 1860
MasterAlexei писал(а):
siarzhuk писал(а):
А применять конструкторы на полученную из этих функций память - забота "new / new[] expression" а не программиста.

Слово expression вы как перевели?
siarzhuk писал(а):
...
Куда надо туда и полетит -
...

Вы привели описание действия операторов из стандартной библиотеки.
Товарищ Pingvin пытается создать свою библиотеку взамен той стандартной, описание которой вы тут привели, свои собственные операторы new/delete. Так что это именно его забота - делать все эти вызовы конструкторов/деструкторов.

Упдт.
Поглядел сейчас, чего получается в дебагере на месте вызова operator new. Он сначала вызывает malloc, и инлайнит вызов конструктора объекта.
Так же глянул исходники этого самого оператора new в GCC. Скорее всего, все же именно что сам компилятор GCC с его стандартной библиотекой, при синтаксическом разборе вставляет вызовы конструкторов (как и говорил siarzhuk). Интересно было бы посмотреть, что будет если переопределить этот оператор new[] на свой именно, а не из библиотеки.
Сейчас попробую этот момент у себя.

Упдт 2.
Да - GCC инлайнит вызовы конструкторов сразу после вызова либо библиотечного, который в итоге попадает в malloc, либо пользовательского operator new.
Т.е. это именно сам GCC компилятор при синтаксическом разборе кода вставляет либо один вызов, либо цикл на количество запрошенных объектов (например тут TObject * myObjects = new TObject[ 10 ]; )

Кстати, Pingivn, в приведенном вами последнем примере ошибки.
Надо звездочки расставить:
Код:
void * operator new(size_t size)
{
  void * p;
    p = malloc(size);

  return p;
}


Ну вот - и Вы что то полезное для себя почерпнули...

А вывод то какой в итоге?
Можно потокообезопаситься переписав new и delete (добавив семафоры)?


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

Зарегистрирован: 29 янв 2010, 15:41
Сообщения: 1125
Откуда: Германия
Цитата:
А вывод то какой в итоге?
Можно потокообезопаситься переписав new и delete (добавив семафоры)?

Можно. В моих HeapAlloc, HeapClear я так и делаю, опрашиваю одну, локальную для моего Heap модуля переменную. Единственное ограничение/ или фича, в прерываниях стараться не использовать динамическое выделение памяти, потому как если вы в прерываении, то не получится запретить прерывания или остановить задачи на момент выделения памяти. FreeRTOS функции имеют встроенные макросы, которые выкидывают ексепшины, если их в контексте прерываний использовать.
Но как я и советовал в одном из первых сообщений, переписывать надо не операторы new/delete, а именно malloc calloc free. Таким образом вы и в С++ среде и в С среде будете использовать один централизованный Heap. (Это к вопросу неявных использований - все они в конечном итоге попадают в malloc/free)

_________________
Мои поделки
http://www.fun-electronic.net/


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

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

Все-таки вопрос: зачем вам штатные STL-евские контейнеры?

P.S. обычные ("десктопные") malloc/free могут приводить к фрагментации кучи и при определенном сочетании условий - к отказу выделения памяти даже если общий объем свободного места достаточен для удовлетворения запроса. причем это может происходить не сразу и/или не стабильно. на десктопе это не проблема - попросил у системы еще. в ембеде просить еще не у кого, так что получим зависший контроллер.
P.P.S. динамическое распределение памяти в эмбеде вполне применимо, но стандартные new/delete для этого подходят плохо.


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

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 1860
evsi писал(а):
Pingvin писал(а):
Да нет у меня задачи переписать стандартные библиотеки.
Если будет работать со штатными - отлично.

Все-таки вопрос: зачем вам штатные STL-евские контейнеры?

P.S. обычные ("десктопные") malloc/free могут приводить к фрагментации кучи и при определенном сочетании условий - к отказу выделения памяти даже если общий объем свободного места достаточен для удовлетворения запроса. причем это может происходить не сразу и/или не стабильно. на десктопе это не проблема - попросил у системы еще. в ембеде просить еще не у кого, так что получим зависший контроллер.
P.P.S. динамическое распределение памяти в эмбеде вполне применимо, но стандартные new/delete для этого подходят плохо.


Основная цель - изучение плюсов, желательно применимо к контроллеру.
Ну и удобно контейнеры использовать для своих классов.
Сортировать, присваивать, сравнивать, создавать...


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

Зарегистрирован: 23 сен 2012, 20:35
Сообщения: 1898
Pingvin писал(а):
Основная цель - изучение плюсов, желательно применимо к контроллеру.
Ну и удобно контейнеры использовать для своих классов.
Сортировать, присваивать, сравнивать, создавать...

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


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

Зарегистрирован: 15 ноя 2015, 12:11
Сообщения: 101
MasterAlexei писал(а):
siarzhuk писал(а):
А применять конструкторы на полученную из этих функций память - забота "new / new[] expression" а не программиста.

Слово expression вы как перевели?

В конкретном контексте как сущность из цитируемого описания, исполняющая подразумеваемые за ней действия.
evsi писал(а):
P.S. обычные ("десктопные") malloc/free могут приводить к фрагментации кучи и при определенном сочетании условий - к отказу выделения памяти даже если общий объем свободного места достаточен для удовлетворения запроса. причем это может происходить не сразу и/или не стабильно. на десктопе это не проблема - попросил у системы еще. в ембеде просить еще не у кого, так что получим зависший контроллер.

Динамическая память предполагает и контроль успешности выделения перед использованием, т.е. самое страшное что случится - переход в состояние ошибки. Да и в случае отказа можно попытаться malloc_trim-ом освобождённые куски слить и попробовать ещё раз. Но, как и всё в этой области - без 100%-ной гарантии успешности.
evsi писал(а):
P.P.S. динамическое распределение памяти в эмбеде вполне применимо, но стандартные new/delete для этого подходят плохо.

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

Очень много там копирований за сценой происходит.


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

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


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

Сейчас этот форум просматривают: нет зарегистрированных пользователей


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

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

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