Pull to refresh

Comments 9

Спасибо очень интересная статья.
Есть так же пара вопросов:
1) Динамическая память нужна для работы самой ОС или вы собираетесь использовать её для пользовательского кода?
2) Постоянно 2.4% процессорного времени затрачивается только на ОС, или там есть ещё какие то постоянно работающие пользовательские задачи?

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

middleware тоже организует свои пулы и не нуждается в пулах памяти предоставляемых пользователем.

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

По второму вопросу есть некая неясность что считать затратами на ось.
Можно сказать что сама ось вообще ничего не делает, она в sleep когда нет задач.
Но я считаю такой расчет не верным.
Я считаю что если есть задачи и middleware которые не реализуют полезный прикладной алгоритм, а нужны только для поддержки коммуникаций, сервисов реального времени и диагностики, то это издержки операционной системы

Задач в демо-приложении вот столько:

И вот это всё потребляет 2.5%

Тут видно что основное время уходит на задачу IDLE и расчет в ней загрузки процессора.
Не будь этой задач, то процент уменьшился до 1% , а не будь FreeMaster с USB то и меньше 0.5..0.2 % Но это все нужно, поэтому я это отношу на счет RTOS как издержки.

1.5% на расчёт загрузки процессора? Как производится этот расчёт?

Это очень приблизительная цифра. И само измерение приблизительное.
Оно основано на референсном значении времени в переменной ref_time.
Референсное значение берется на старте RTOS когда еще не запущены никакие задачи и прерывания.

/*-----------------------------------------------------------------------------------------------------
  Измеряем длительность интервала времени заданного в милисекундах
-----------------------------------------------------------------------------------------------------*/
uint64_t Measure_reference_time_interval(uint32_t time_delay_ms)
{
  ULONG   tickt1;
  ULONG   tickt2;
  uint64_t diff;

  tickt1 = tx_time_get();
  DELAY_ms(time_delay_ms);
  tickt2 = tx_time_get();

  diff = ((tickt2 - tickt1)*1000000ull)/(TX_TIMER_TICKS_PER_SECOND);
  return diff;
}

/*-----------------------------------------------------------------------------------------------------
  Тело задачи IDLE
-----------------------------------------------------------------------------------------------------*/
static void Thread_idle(ULONG initial_input)
{
  uint64_t  t;
  uint64_t  dt;

  for (;;)
  {
    t = Measure_reference_time_interval(REF_TIME_INTERVAL);
    if (t < ref_time)
    {
      dt = 0;
    }
    else
    {
      dt = t - ref_time;
    }
    g_cpu_usage =(1000ull * dt) / ref_time;
    g_cpu_usage_fp = (float)dt*100.0f/(float)ref_time;
  }
}
Возможно ли измерить время точнее, например в микросекундах или вообще в тактах?
И какой получился результат?

Тут как в принципе неопределённости Гейзенберга, если точно знаете процент, то не знаете когда он был таким. Т.е. процент плавает. Лучше знать его максимальное значение. А для этого надо иметь максимальное количество задач и объектов синхронизации.
Такой проект я еще не создал.

Sign up to leave a comment.

Articles