[РЕШЕНО] FreeRTOS Отладка задач (v9 stm32f1)

Qic

Немного модифицировал стоковую vTaskGetRunTimeStats

КОД

Код:

   void CustomGetRunTimeStats( char *pcWriteBuffer )
   {
      TaskStatus_t *pxTaskStatusArray;
      volatile UBaseType_t uxArraySize, x;
      uint32_t ulTotalTime, ulStatsAsPercentage;
      char cStatus;

      *pcWriteBuffer = 0x00;
      uxArraySize = uxCurrentNumberOfTasks;
      pxTaskStatusArray = pvPortMalloc( uxCurrentNumberOfTasks * sizeof( TaskStatus_t ) );

      if( pxTaskStatusArray != NULL )
      {
         uxArraySize = uxTaskGetSystemState( pxTaskStatusArray, uxArraySize, &ulTotalTime );
         ulTotalTime /= 100UL;

         sprintf( pcWriteBuffer, "TaskName \tSt. \tCPU \tPr. \tFree \tNum \r\n");
         pcWriteBuffer += strlen( pcWriteBuffer );

         if( ulTotalTime > 0 )
         {
            for( x = 0; x < uxArraySize; x++ )
            {
               ulStatsAsPercentage = pxTaskStatusArray[ x ].ulRunTimeCounter / ulTotalTime;
               pcWriteBuffer = prvWriteNameToBuffer( pcWriteBuffer, pxTaskStatusArray[ x ].pcTaskName );

               switch( pxTaskStatusArray[ x ].eCurrentState ) // NEW
               {
                  case eReady:      cStatus = tskREADY_CHAR; break;
                  case eBlocked:      cStatus = tskBLOCKED_CHAR; break;
                  case eSuspended:   cStatus = tskSUSPENDED_CHAR; break;
                  case eDeleted:      cStatus = tskDELETED_CHAR; break;
                  default:         cStatus = 0x00; break;
               }

               if( ulStatsAsPercentage > 0UL )
               {
                  //sprintf( pcWriteBuffer, "\t%u\t\t%u%%\r\n", ( unsigned int ) pxTaskStatusArray[ x ].ulRunTimeCounter, ( unsigned int ) ulStatsAsPercentage );
                  sprintf( pcWriteBuffer, "\t%c\t%u%%\t%u\t%u\t%u\r\n", cStatus, ( unsigned int ) ulStatsAsPercentage, ( unsigned int ) pxTaskStatusArray[ x ].uxCurrentPriority, ( unsigned int ) pxTaskStatusArray[ x ].usStackHighWaterMark, ( unsigned int ) pxTaskStatusArray[ x ].xTaskNumber );
               }
               else
               {
                  //sprintf( pcWriteBuffer, "\t%u\t\t<1%%\r\n", ( unsigned int ) pxTaskStatusArray[ x ].ulRunTimeCounter );
                  sprintf( pcWriteBuffer, "\t%c\t<1%%\t%u\t%u\t%u\r\n", cStatus, ( unsigned int ) pxTaskStatusArray[ x ].uxCurrentPriority, ( unsigned int ) pxTaskStatusArray[ x ].usStackHighWaterMark, ( unsigned int ) pxTaskStatusArray[ x ].xTaskNumber );

               }

               pcWriteBuffer += strlen( pcWriteBuffer );
            }
         }
         else
         {
            mtCOVERAGE_TEST_MARKER();
         }

         vPortFree( pxTaskStatusArray );
      }
      else
      {
         mtCOVERAGE_TEST_MARKER();
      }
   }

Никак не пойму откуда выдернуть величину стека задачи, сколько ему именно выдано, чтобы посчитать процент использования стека.
Есть vTaskGetInfo в которой кусок

Код:

   TCB_t *pxTCB;

      /* xTask is NULL then get the state of the calling task. */
      pxTCB = prvGetTCBFromHandle( xTask );

от которого можно вызвать pxTCB->pxStack;
но получаю я кажется адрес(?).

Qic

Сделал "сортировку", приятнее глазу, строчки не скачут. Насколько я понял по исходникам FreeRTOS нигде не хранит глубину стека которая используется только при инициализации.
Есть идеи как её получить?

КОД

Код:

   void CustomGetRunTimeStats( char *pcWriteBuffer )
   {
      TaskStatus_t *pxTaskStatusArray;
      volatile UBaseType_t uxArraySize, x, y;
      uint32_t ulTotalTime, ulStatsAsPercentage;
      char cStatus;

      TCB_t *pxTCB;
      unsigned int ulStackUsage;

      *pcWriteBuffer = 0x00;
      uxArraySize = uxCurrentNumberOfTasks;
      pxTaskStatusArray = pvPortMalloc( uxCurrentNumberOfTasks * sizeof( TaskStatus_t ) );

      if( pxTaskStatusArray != NULL )
      {
         uxArraySize = uxTaskGetSystemState( pxTaskStatusArray, uxArraySize, &ulTotalTime );
         ulTotalTime /= 100UL;

         sprintf( pcWriteBuffer, "TaskName \tSt. \tCPU \tPr. \tFree \tStack \tNum \r\n");
         pcWriteBuffer += strlen( pcWriteBuffer );

         if( ulTotalTime > 0 )
         {
            for( y = 0; y < uxArraySize; y++ )
            {
               x = 0;
               while ( (y+1) != ( unsigned int ) pxTaskStatusArray[ x ].xTaskNumber) x++;

               ulStatsAsPercentage = pxTaskStatusArray[ x ].ulRunTimeCounter / ulTotalTime;
               pcWriteBuffer = prvWriteNameToBuffer( pcWriteBuffer, pxTaskStatusArray[ x ].pcTaskName );

               pxTCB = prvGetTCBFromHandle( pxTaskStatusArray[ x ].xHandle ); /* xTask is NULL then get the state of the calling task. */
               ulStackUsage = pxTCB->pxTopOfStack - pxTCB->pxStack ;// - 0xFFFFFF00;

               switch( pxTaskStatusArray[ x ].eCurrentState ) // NEW
               {
                  case eReady:      cStatus = tskREADY_CHAR; break;
                  case eBlocked:      cStatus = tskBLOCKED_CHAR; break;
                  case eSuspended:   cStatus = tskSUSPENDED_CHAR; break;
                  case eDeleted:      cStatus = tskDELETED_CHAR; break;
                  default:         cStatus = 0x00; break;
               }

               if( ulStatsAsPercentage > 0UL )
               {
                  //sprintf( pcWriteBuffer, "\t%u\t\t%u%%\r\n", ( unsigned int ) pxTaskStatusArray[ x ].ulRunTimeCounter, ( unsigned int ) ulStatsAsPercentage );
                  sprintf( pcWriteBuffer, "\t%c\t%u%%\t%u\t%u\t%u\t%u\r\n", cStatus, ( unsigned int ) ulStatsAsPercentage, ( unsigned int ) pxTaskStatusArray[ x ].uxCurrentPriority, ( unsigned int ) pxTaskStatusArray[ x ].usStackHighWaterMark, ulStackUsage, ( unsigned int ) pxTaskStatusArray[ x ].xTaskNumber );
               }
               else
               {
                  //sprintf( pcWriteBuffer, "\t%u\t\t<1%%\r\n", ( unsigned int ) pxTaskStatusArray[ x ].ulRunTimeCounter );
                  sprintf( pcWriteBuffer, "\t%c\t<1%%\t%u\t%u\t%u\t%u\r\n", cStatus, ( unsigned int ) pxTaskStatusArray[ x ].uxCurrentPriority, ( unsigned int ) pxTaskStatusArray[ x ].usStackHighWaterMark, ulStackUsage, ( unsigned int ) pxTaskStatusArray[ x ].xTaskNumber );

               }

               pcWriteBuffer += strlen( pcWriteBuffer );
            }
         }
         else
         {
            mtCOVERAGE_TEST_MARKER();
         }

         vPortFree( pxTaskStatusArray );
      }
      else
      {
         mtCOVERAGE_TEST_MARKER();
      }
   }

evsi

Qic писал(а):

Есть идеи как её получить?

Насколько я понимаю, стек под задачи распределяется из какого-то общего буфера. Если так, то можно попробовать отсортировать указатели на стек, взять между ними разницу и выровнять ее на какую-то границу (зависит от гранулярности с которой выделяется место под стек). Впрочем, это не гарантирует правильности полученного результата. Например, если гранулярность 1К, задаче выделено 2К и она уже использовала больше 1К, то при вычислении получится ошибка (использованный стек зачтется как пустой следующей задаче). А так самое простое - слегка допилить FreeRTOS и сохранять начальный размер стека в структуре задачи.

Qic

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

x893

Это не то ?
http://www.freertos.org/Stacks-and-stac ... cking.html
http://www.freertos.org/uxTaskGetStackH ... rMark.html
Но размер стека и freertos не очень связаны.
Только при переключении задачи rtos нужно место в стеке.
А потом как вы его будете использовать - дело ваше личное.

Qic

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

Чуть позже допишу и выложу task.c task.h, впрочем переделка там мизерная. Всё ради буковок и циферок в терминале на манер диспетчера задач.
А позднее там появится еще и прогресс бар и даже цветное оформление, но это уже жир :)

P.S. А ведь раньше для меня исходники FreeRTOS были чем-то магическим и суперсложным.

BusMaster

А вы никогда не интересовались структурой стека задач в частности, и работой аллокатора heap1, heap2 в общности? Откройте браузер памяти, посмотрите. В начале каждого стека задачи идет блок TCB - Task Control Block. Он содержит инфу, определенную в качестве структуры при создании задачи (просмотрите исходники этой ф-ции). Размер TCB постоянен. 72 бйата на ARM. Аллокатор модели heаp1 работает последовательно, выделяя память от начала кучи (heap) и до ее конца, без промежутков. ...кароче, просто откройте браузер памяти и посмотрите.

Qic

Пока еще не интересовался.
У нас есть кодер который бывает пишет хуки и подобные им штуки глядя в дамп памяти в артмани, а я пока такое не могу.
Сделал стек задачи 32 слова для наглядности. Нагляднее особо не стало. Название задач вижу. У меня на пальцах получилось 248 байт из кучи на одну задачу.
Как в этом разбираться?

Вложение:

ZInBvuV8icw.jpg [ 237.06 Кб | Просмотров: 1825 ]

P.S. Если что у меня CoIDE и st-link. Отлаживаю но в память пока лезть не приходилось, и к сожалению я не вижу такой возможности в кокосе.
Не представляю на что менять чтобы из коробки сразу и настроенная отладка была, и прошивало нормально по сети через usbip.

MasterAlexei

Qic писал(а):

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

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

Qic писал(а):

Чуть позже допишу и выложу task.c task.h, впрочем переделка там мизерная. Всё ради буковок и циферок в терминале на манер диспетчера задач.
А позднее там появится еще и прогресс бар и даже цветное оформление, но это уже жир :)

P.S. А ведь раньше для меня исходники FreeRTOS были чем-то магическим и суперсложным.

Очередной велосипед?
Приглядитесь к Segger System Viewer. Он показывает, почти в реальном времени, какая задача, сколько выполнялась, сколько стояла, какие прерывания в этот момент вызывались, какие прерывались. Если свой код немного доинструментировать, то можно и ваши собственные ивенты глядеть.
Это все как для безОСовой системы, так и с FreeRTOS (там надо чуток ее доработать, подробно об этом в доке к проге описано), так и с SeggerOS.

Очень рекомендую.
PS. Забыл добавить, что оно, к сожалению, толко с J-Link работает. Но о том, как переделать ST-Link в нормальный J-Link, тут уже пол форума исписано.

Qic

MasterAlexei писал(а):

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

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

MasterAlexei писал(а):

Очередной велосипед?

Вот знаете, захотелось чтобы в терминале с железкой по команде "делай раз" железка сообщала состояние.
На счёт Segger пробовал но как-то вскользь, Segger System Viewer не пробовал. Спасибо.

MasterAlexei

Qic писал(а):

MasterAlexei писал(а):

Очередной велосипед?

Вот знаете, захотелось чтобы в терминале с железкой по команде "делай раз" железка сообщала состояние.
На счёт Segger пробовал но как-то вскользь, Segger System Viewer не пробовал. Спасибо.

Оличие System Viewer от вашего "по команде "делай раз" " в том, что у вас на это тратится драгоценное время процессора, а у System Viewer затраты минимальные, так как используется SWD интерфейс и RTT механизм, который очень даже незаметно работает, не тратя при этом никакой переферии (ну кроме SWD пинов).

MasterAlexei

Qic писал(а):

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

Так и в чем проблема то? Знаете, где стек начинается, знаете, где заканчивается. Знаете, чем он изначально заполнен. Так и "по команде" с конца стека идете пока в нем вдруг не появятся какие то левые значения, отличные от того маркера (0xAA или 0x55), вот вам и место, до куда доходит использование. Вычитываем адрес конца от найденного адреса несоответствия, и получаем процент.

Qic

MasterAlexei писал(а):

тратится драгоценное время процессора, а у System Viewer затраты минимальные, так как используется SWD интерфейс и RTT механизм, который очень даже незаметно работает, не тратя при этом никакой переферии (ну кроме SWD пинов).

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

MasterAlexei писал(а):

Так и в чем проблема то? Знаете, где стек начинается, знаете, где заканчивается. Знаете, чем он изначально заполнен. Так и "по команде" с конца стека идете пока в нем вдруг не появятся какие то левые значения, отличные от того маркера (0xAA или 0x55), вот вам и место, до куда доходит использование. Вычитываем адрес конца от найденного адреса несоответствия, и получаем процент.

Я не думаю что такое "сканирование памяти" стоит проворачивать постоянно. Проще уж исходники поправить и запоминать явный размер стека при создании задачи.

MasterAlexei

Qic писал(а):

Я не думаю что такое "сканирование памяти" стоит проворачивать постоянно. Проще уж исходники поправить и запоминать явный размер стека при создании задачи.

Я не совсем понимаю вашу проблему, если честно. При создании задачи ваш стек вам и так известен. Это параметр в функцию создания задачи. Вы же сами его туда и записали, при программировании вызова создания задачи.
Этот параметр - это размер стека, который надо умножить на 4, чтоб в байтах получить его.

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

Qic

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

BusMaster

Не-не, господа, не путайте АРМ-стек функций и стек РТОС. У них разное назначение и разные точки отсчета. Стек РТОС не управляется аппаратно, в отличие от стека ядра. Стеком РТОС управляет менеджер памяти (одна из моделей heap1, heap2 и тд), и "растет" вверх от начала кучи. Я на форуме ранее несколько раз выкладывалскрины стеков, там было наглядно видно.
Во-вторых, все переменные в функции задачи, помеченные как static (либо глобальные), будут размещены не в стеке задачи, а в области статичных переменных, находящейся вне кучи (heap).
Под браузером памяти я имел ввиду другой, который в ПО отладки. И на CoIDE далеко не уедешь...

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

MasterAlexei

BusMaster писал(а):

... Стеком РТОС управляет менеджер памяти (одна из моделей heap1, heap2 и тд), и "растет" вверх от начала кучи.

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

BusMaster писал(а):

Под браузером памяти я имел ввиду другой, который в ПО отладки. И на CoIDE далеко не уедешь...

Ozone рекомендую. От того же зеггера.

BusMaster писал(а):

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

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

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

siarzhuk

BusMaster писал(а):

Не-не, господа, не путайте АРМ-стек функций и стек РТОС. У них разное назначение и разные точки отсчета. Стек РТОС не управляется аппаратно, в отличие от стека ядра.

Возможно это платформенно-зависимо, но на rx600, к примеру, стеки задач "подсовываются" МК при переключении задач и ему без разницы по какому участку памяти "ходить" - по стеку супервайзора, по пользовательскому или по динамически выделенному стеку задачи. Иными словами, в конкретном случае, - нахожу больше совпадений чем различий. И, кстати, параметр ешё нужно для платформы определять portSTACK_GROWTH - либо отрицательный либо положительный, в зависимости от того как МК работает со стеком - "вверх" или "вниз". В зависимости от этого параметра последовательность выделения памяти для стека задачи и её TCB различается - чтобы стек не "переехал" свой собственный TCB и "патологоанатому" легче было постмортем аутопсиями заниматься в случае чего.

BusMaster писал(а):

Стеком РТОС управляет менеджер памяти (одна из моделей heap1, heap2 и тд), и "растет" вверх от начала кучи.

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

x893

Любят наши люди на пустом месте дискуссию разводить.

BusMaster

MasterAlexei писал(а):

У меня свой менеджер памяти, из которого FreeRTOS посредством вызова malloc запрашивает для задач области памяти для стека. и в зависимости от того, в какой момент создается задача, этот стек может лежать где угодно в области, которой заправляет мой менеджер памяти.
...
И получается, что в начале кучи могут быть так же свободные куски памяти. И в конце кучи могут быть и занятые куски памяти.

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

siarzhuk писал(а):

Возможно это платформенно-зависимо, но на rx600,.

Вы не путайте платформы. Мы тут обсуждаем ARM-Cortex, конкретно на реализации STM.

MasterAlexei

BusMaster писал(а):

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

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

Qic

В общем добавил желаемое и успокоился. Пока хватит. Всем большое спасибо за активное участие.
Может кому пригодятся task.c от FreeRTOS 9.0.0 (в частности для stm32f103ve).
Впрочем там всего лишь лишняя функция и поправленная структура. (Строки 318 и 4161)

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

UPD
Похоже дело было не в бобине. В любом случае нужно быть слегка осторожнее.

BusMaster

Возвращаясь к теме. Возможно, автора заинтересует простая функция для определения оставшегося свободного места в куче. xPortGetFreeHeapSize() - она возвращает значение свободного места в байтах. Её функционал прописан в файле модели памяти. А так же для модели heap1 есть глобальная переменная xNextFreeByte, содержащая значение занятой памяти в байтах.

Qic

Это конечно интересно, но у меня xPortGetFreeHeapSize() ссылается на

Код:

size_t xPortGetFreeHeapSize( void )
{
   return xFreeBytesRemaining;
}

потом

Код:

/* Keeps track of the number of free bytes remaining, but says nothing about
fragmentation. */
static size_t xFreeBytesRemaining = configADJUSTED_HEAP_SIZE;

далее

Код:

/* A few bytes might be lost to byte aligning the heap start address. */
#define configADJUSTED_HEAP_SIZE   ( configTOTAL_HEAP_SIZE - portBYTE_ALIGNMENT )

а они уже на дефайн из конфига

Код:

#define configTOTAL_HEAP_SIZE               ( ( size_t ) ( 32 * 1024 ) ) 

и константу

Код:

/* Architecture specifics. */
#define portSTACK_GROWTH         ( -1 )
#define portTICK_PERIOD_MS         ( ( TickType_t ) 1000 / configTICK_RATE_HZ )
#define portBYTE_ALIGNMENT         8

Это нормально или я чего-то не понимаю?

BusMaster

Да, всё в порядке, это - начальное значение. Используется модель heap2. В процессе работы переменная xFreeBytesRemaining изменяется в меньшую сторону.

Easyelectronics.ru

[РЕШЕНО] FreeRTOS Отладка задач (v9 stm32f1)

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