[Abrams 0]

Доброго дня!

Пишу программу на С# для считывания данных с контроллера через последовательный порт. Считывать данные нужно каждые 50 мс.

Для формирования временных интервалов отправления запросов в контроллер использую компонент Timer, но как и ожидается, реальное время запросов получается на 50 мс, а от 53 до 65 мс.

Каким способом и есть ли возможность в С# организовать формирования более точного интервала? Желательно +-2 мс.

[Harvester 0]

Мне кажется это неверный подход.

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

[x893 35]

Перенесите 50mS в контроллер или в разрыв TX/RX микроконтроллер. Попробуйте под линукс, но гарантий нет.

[AlexandrY 3]

20 minutes ago, Abrams said:

Пишу программу на С# для считывания данных с контроллера через последовательный порт. Считывать данные нужно каждые 50 мс.

Стоит раскопать этот порт до уровня USB и там использовать протокол по прерываниям. 

[xvr 12]

2 hours ago, Abrams said:

Каким способом и есть ли возможность в С# организовать формирования более точного интервала?

C# работает на платформе .net, которая в свою очередь работает на OS Windows, которая в свою очередь не является ОС реального времени. Т.е. если даже вы с помощью всяческих ухищрений сумеете отмерить ровно 50ms на C#, Windows может вам испортить малину в любой момент, просто прервав выполнение вашей программы как раз в эти самые 50ms, и занявшись более важными 9с её точки зранеия) делами

 

[_4afc_ 25]

Написать драйвер на прерывание от часиков. Часики можно настроить вплоть до 1\8192 в секунду на x86

Считанное буферезировать в драйвере.

[Forger 17]

Буферизировать данные, как предложил Harvester, но вместе с данными присылать еще и номер сэмпла в качестве временнОй метки, на случай, если какой-то из замеров потерялся по пути.

Т.е. проектирвоать некий, пусть и простой, но протокол.

ВременнЫе метки должен формировать контроллер, он это сможет сделать гораздо точнее винды.

[jenya7 0]

6 hours ago, Abrams said:

Доброго дня!

Пишу программу на С# для считывания данных с контроллера через последовательный порт. Считывать данные нужно каждые 50 мс.

Для формирования временных интервалов отправления запросов в контроллер использую компонент Timer, но как и ожидается, реальное время запросов получается на 50 мс, а от 53 до 65 мс.

Каким способом и есть ли возможность в С# организовать формирования более точного интервала? Желательно +-2 мс.

не используйте компонент Timer. используйте System Timer он точнее.

[iosifk 3]

4 часа назад, xvr сказал:

C# работает на платформе .net, которая в свою очередь работает на OS Windows, которая в свою очередь не является ОС реального времени. Т.е. если даже вы с помощью всяческих ухищрений сумеете отмерить ровно 50ms на C#, Windows может вам испортить малину в любой момент, просто прервав выполнение вашей программы как раз в эти самые 50ms, и занявшись более важными 9с её точки зранеия) делами

 

Я немного добавлю. 

Был реальный случай. Заказчика передвался разработанный Прибор, который тестировал память DIMM и на хосте строил картинку рабочих и неисправных ячеек. Причем в "правилах игры" хост считался "любым компьютером заказчика".

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

В результате построение диаграммы было медленным и Заказчик прибор не принял...

[Abrams 0]

4 hours ago, jenya7 said:

не используйте компонент Timer. используйте System Timer он точнее.

System Timer - https://docs.microsoft.com/en-us/dotnet/api/system.timers.timer?view=netframework-4.7.2

Вы об этом компоненте?

Я в С# пока "очень" начинающий, прошу не пинать...

 

10 hours ago, Harvester said:

Мне кажется это неверный подход.

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

Контроллер в режиме ведомого, тут без вариантов.

Изменено 29 октября, 2018 пользователем Abrams

[jcxz 187]

11 часов назад, Abrams сказал:

Контроллер в режиме ведомого, тут без вариантов.

И что? Это не отменяет справедливого совета Harvester.

[iosifk 3]

54 минуты назад, jcxz сказал:

И что? Это не отменяет справедливого совета Harvester.

Я добавлю. 

По-моему, если уж имеете готовый контроллер, который только "Контроллер в режиме ведомого" то гораздо проще и дешевле добавить в канал, как было сказано "в разрыв TX/RX микроконтроллер". Такой дополнительный контроллер не может дорого стоить, а проблем снимет кучу. Причем, чтобы начальник понял, не обязательно это может быть только UART-UART. Поставьте UART-Ethernet и затраты многократно окупятся.... Причем сразу и без головной боли. А иначе вляпаетесь в Виндовые заморочки, и получите ситуацию подобную той, что я описал...

[Forger 17]

1 minute ago, iosifk said:

Причем, чтобы начальник понял... Поставьте UART-Ethernet и затраты многократно окупятся

Это такой подход принят у профи - писать ТЗ, составлять бизнес-планы и т.п.

Но мне что-то подсказывает, что ТС сам себе "начальник", а речь идет про саморазвитие на базе какой-нибудь платки ардуино :)

 

[iosifk 3]

2 минуты назад, Forger сказал:

Это такой подход принят у профи - писать ТЗ, составлять бизнес-планы и т.п.

Но мне что-то подсказывает, что ТС сам себе "начальник", а речь идет про саморазвитие на базе какой-нибудь платки ардуино :)

 

Я конечно не хочу спамить, но чтобы ТС понял о чем речь идет...

Проработав 7 лет в техподдержке, могу сказать, что больше половины вопросов были заданы неправильно. Ну, то-есть сначала выбирался заведомо неверный путь, потом выяснялось, что на нем очень много трудностей. И исполнитель начинал их преодолевать. Вот к примеру, один парень написал, что хочет сделать прослушку Ethernet и ему надо подключить к каналу только Rx. А Tx запрещает подключать их Заказчик. И все бы хорошо, да вот пришлось его огорчить, что это не RS232 и просто так ничего не получится. И надо ставить свитч в разрез проверяемой линии, и подключать не только Rx но и Tx, а иначе линк не встанет. А вот линии Tx можно отключить уже после трансивера. И это для него было нелегко принять. Но это "стандарт", который будет гарантированно работать, а не "самопал", с которым можно получить прорву проблем...

[jenya7 0]

On 10/29/2018 at 10:04 PM, Abrams said:

System Timer - https://docs.microsoft.com/en-us/dotnet/api/system.timers.timer?view=netframework-4.7.2

Вы об этом компоненте?

Я в С# пока "очень" начинающий, прошу не пинать...

 

Контроллер в режиме ведомого, тут без вариантов.

 

посмотрите тут.

я помню на System.Diagnostics.StopWatch добивался неплохих результатов.