Easyelectronics.ru

Электроника для всех
Текущее время: 22 окт 2018, 22:35

Часовой пояс: 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
Сообщения: 1979
Хочу создать шаблон для Segger IDE под С++ с FreeRTOS.
Как настроить проект, какие дополнительные либы подключать, какие функции перегружать, какие флаги ставить?
Хочу использовать STL с её контейнерами.
Пока понял, что у FreeRTOS есть реализация malloc и можно реализовать свои
Show new и delete


Что ещё?


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

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


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

Зарегистрирован: 01 фев 2013, 02:21
Сообщения: 256
Вот в 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
Сообщения: 113
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
Сообщения: 1979
Разве это не задача компилятора создавать (вставлять вызовы) на конструкторы и деструкторы?
new и delete тут ни при делах, ИМХО.
Их задача - память выделить(очистить) и передать указатель.


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

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 1979
Есть проект, рабочий, написан грамотным товарищем
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
Сообщения: 2385
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
Сообщения: 2416
Pingvin писал(а):
Хочу использовать STL с её контейнерами.

Зачем?


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

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


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

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

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

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

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


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

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 1979
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
Сообщения: 2416
Pingvin писал(а):
Да нет у меня задачи переписать стандартные библиотеки.
Если будет работать со штатными - отлично.

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

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


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

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 1979
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
Сообщения: 2416
Pingvin писал(а):
Основная цель - изучение плюсов, желательно применимо к контроллеру.
Ну и удобно контейнеры использовать для своих классов.
Сортировать, присваивать, сравнивать, создавать...

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


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

Зарегистрирован: 15 ноя 2015, 12:11
Сообщения: 113
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 часов


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

Сейчас этот форум просматривают: VladislavS


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

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

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