Общие вопросы программирования в C++Builder

[MaxiMuz79]

Нужно с определенной частотой выводить график. Используя компонент Timer по табличным точкам строю график:

Код:

void __fastcall TForm1::Timer1Timer(TObject *Sender)
{
    static int i;
    static unsigned char dirCount=0;
    NumWByte=1;
    buf_out=tablsin[i];
//WriteFile(port,&buf_out,NumWByte,&WByteCount,&ovrlp);
VxADC=(unsigned int) tablsin[i];
MeasValue=(float)(MaxValue*VxADC)/MaxHC;
Series2->AddXY(Ti,MeasValue,"",clRed);
    if (i==127)
    {  dirCount=1;
    }
    else if (i==0)
    {  dirCount=0;
    }
    if (dirCount==0) i++; else i--;
    Ti++; 
    if (Ti>200)
    {   Ti=0;
        Series2->Clear();
    }
}

Ставил различные периоды вызова , и только от 100 мсек частота вызовов совпадает с заданной. При меньшем периоде наблюдается сильное отставание.
Как организовать синхронный вызов событий ?

[POV]

Имеется в виду - косяки при меньшем периоде?

[Leex]

TTimer по своей природе очень не точен, но по опыту могу сказать что эта неточность сильно проявляется при интервалах меньше 50 мс. Здесь судя по всему сам обработчик таймера достаточно тяжело дается процессору. Обрати внимание как загружается процессор (ядро) если задать скажем 50 мс.

[S0mbre]

Для большинства задач, где требуется точность и хороший отклик, лучше использовать отдельные потоки. Например, метод Execute VCL потока может быть представлен в виде цикла с вызовом паузы в конце:

Код

void __fastcall TMyThread::Execute(void)
{
   while(!Terminated && !Suspended) {
      // делаем что-то (вывод графика и т.д.)...
      Sleep(100); // пауза
   }
}
 

[MaxiMuz79]

Обрати внимание как загружается процессор (ядро) если задать скажем 50 мс.

Проц. практически работает в холостую макс. 7%

[MaxiMuz79]

Например, метод Execute VCL потока может быть представлен в виде цикла с вызовом паузы в конце:

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

[POV]

Например, метод Execute VCL потока может быть представлен в виде цикла с вызовом паузы в конце:

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

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

[POV]

Если Execute интересует, то визард билдера создаст тебе юнит класса потока. Включаешь в проект, создаешь экземпляр этого класса и запускаешь поток. Он себе крутится и делает то, что ты в нем написал.

[MaxiMuz79]

Например, метод Execute VCL потока может быть представлен в виде цикла с вызовом паузы в конце:

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

Ты бы про задачу сказал подробнее.

требуется с определенной периодичностью (1...100 мс) максимально точно во времяни выполнять какую либо операцию : выводить в порт команду и т.д. Использовал компонент Timer оказывается его interval ни фига не точен.

[POV]

1...100 мс - малореально. Я находил исходники "высокоточных" таймеров.. но гложет меня сомнение. Как вариант могу предложить тот же поток, но в нем не Sleep(), а GetTikCount() - счетчик тактовых импульсов процессора.
что-то типа:

Код

... Execute()
{
  UINT last_tik = GetTikCount();
        UINT current_tik;
    while(1)
      {
               currentk_tik = GetTikCount();
         if (current_tik-last_tik > interval)
          {
                       last_tik = current_tik;
                 ... // тут вызываем обработчик события
               }
               else
                 last_tik = current_tik;
 }
}

interval - это твои миллисекунды, умноженные на какой-то коэффициент, зависящий от тактовой

[MaxiMuz79]

interval - это твои миллисекунды, умноженные на какой-то коэффициент, зависящий от тактовой

да, похоже это условные миллисекунды зависящие от конкретной машины
Тогда и для

GetTikCount()

нужно знать чему равен длительность одного такта

[POV]

Конечно. Можно тактовую взять из винды или посчитать тактовую при запуске программы:

Код

UINT t1 = GetTikCount();
Sleep(1000);
UINT t2 = GetTikCount();
float k = (t2-t1)/1000;

Далее этот k умножай на нужный интервал в миллисекундах.

[POV]

А если хочется вообще по максимуму переложить на VCL, то вместо GetTikCount использовать Now() и метод получения числа миллисекунд в переменной TDateTime (объявлена в DatUtils):

Код

DateUtils.hpp>
 
 
 
 
... ::Execute()
{
      TDateTime last_dt = Now();
    TDateTime current_dt;
        while(1)
      {
               current_dt;= Now();
              if (MilliSecondOf(current_dt-last_dt) > interval)
           {
                       last_dt = current_dt;
                   ... // тут вызываем обработчик события
               }
               else
                 last_dt = current_dt;
   }
}

[Leex]

ребуется с определенной периодичностью (1...100 мс) максимально точно во времяни выполнять какую либо операцию

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

Для большинства задач, где требуется точность и хороший отклик, лучше использовать отдельные потоки. Например, метод Execute VCL потока может быть представлен в виде цикла с вызовом паузы в конце:

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

Конечно. Можно тактовую взять из винды или посчитать тактовую при запуске программы:

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

А разве оно надо выводить на экран с такой скоростью? Во-первых если у монитора частота обновления 60 Гц, то задержки меньше  16 мс не дадут ничего. Во-вторых на монитор смотрит человек, и он в силу физиологических особенностей ну ни как не сможет определить задержку вывода скажем на 20 мс.

Здесь нужно пересмотреть постановку задачи, с такими условиями она не решаема под виндой

[Rius]

Тот самый таймер использует часы материнской платы, которые не могут дать интервалы точнее ~50мс. Потому таймер для таких мелких интервалов не пригоден. Не говоря уж о том, что винда - не rtos.

[MaxiMuz79]

А разве оно надо выводить на экран с такой скоростью? ........
Здесь нужно пересмотреть постановку задачи, с такими условиями она не решаема под виндой

для того чтобы выводит просто инфу на экран, точность не нужна,согласен, но только задача стоит выводить команду(ы) в порт. И пусть это событие будет выполняться с задержкой к примеру +- 15...20 мс, но стабильно и с предсказуемыми , вычисляемыми промежутками во времяни

[Rius]

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

Возьмите RTOS. Или сделайте внешнее устройство на базе RTOS, управляемое с ПК. Поведение винды непредсказуемо.

[MaxiMuz79]

Или сделайте внешнее устройство на базе RTOS, управляемое с ПК.

как раз внешнее устройство по идее должен синхронизировать частично ПК.
А вообще подумаю как обойти этот косячек

[Rius]

Что за устройство? К чему там стабильность посылки запросов?

[MaxiMuz79]

Что за устройство? К чему там стабильность посылки запросов?

электронный осциллограф управляемый с компа

[POV]

как раз внешнее устройство по идее должен синхронизировать частично ПК.

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

[POV]

электронный осциллограф управляемый с компа

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

[POV]

Вообще скорее тут надо консультации у схемотехника брать, а не у программистов. Соответствующих площадок много.
Вот тут http://caxapa.ru/ я встречал обсуждения готовых USB-моделей и пара человек консультировалась по своим разработкам.