Да, спасибо, вроде я всё это уже изучил и понял проблему. Свойство Stopwatch.Frequency возвращает true, значит, у меня таймер высокого разрешения. И вышеприведённый код я уже проверил на измерении времени выполнения расчётов в цикле - он показывает микросекунды. Например, код
Stopwatch stopWatch = new Stopwatch(); double f = 0; stopWatch.Start(); for (int i = 0; i < 10000; i++) { f += (double)i / 3; } stopWatch.Stop(); label1.Text = ((double)stopWatch.ElapsedTicks / (double)Stopwatch.Frequency).ToString(); label2.Text = f.ToString();
всегда выдаёт примерно 5E-05 . То есть, это 50 мкс. Если менять количество циклов, то время тоже меняется через микросекунды, а не миллисекунды, как с функциями COM-порта. То есть, это реально более точный способ, но именно для задачи в статье ничего особо не изменилось.
Скорее всего намного быстрее, но это же будет не универсальное решение. То есть, такой режим используется только в API драйвера, который у каждой фирмы свой. Тогда программу надо затачивать на конкретную микросхему. В этом плане лучше будет использовать специализированные версии типа CP2104 и CH341, у которых есть дополнительные GPIO. Статья же про стандартный COM порт и его выводы:)
Да, мне тоже CP2102 не подходят именно из-за корпуса. Одну кое-как припаял, но дальше перешёл на CH340 :) Хотя для устройств такой миниатюрный корпус это скорее преимущество, но не для самодельщиков:)
Всегда показывает ноль:) Но если добавить какой-то большой цикл с делением между считываниями, то, действительно, время почти всегда кратно 1 мс, хоть и не ровно.
Вроде бы это должно показывать время в секундах. Как результат - примерно то же самое: в среднем функция выполняется 2 мс для CP2102. То есть, вы правы насчёт точности DateTime.Now.Ticks , но в итоге результаты те же и со Stopwatch(); Попробовал и другие функции - тоже результат совпадает и так же значения постоянно прыгают с шагом примерно в мс.
То есть, функции реально медленные и привязаны к мс, поэтому особенно ничего не изменилось при переходе на более точный метод. Или я что-то не так сделал и тут:)
Вы имеете ввиду, что микросхемы USB-UART автоматически перестанут передавать данные, если на CTS будет 0? Что-то мне кажется, это не работает, иначе нужно было бы обязательно подтягивать эти входы к питанию. Если это самому можно отслеживать в своей передающей программе, тогда это неплохой вариант использования. Правда можно просто пореже передавать данные, чтобы не переполнять буфер устройства.
Насчёт ресета девайса: возможно, можно придумать какую-то хитрую логическую схему, чтобы устройство не сбрасывалось случайно при подключении и отключении USB. Например, можно выводить через DTR и RTS специальные комбинации для ресета устройства и активации бутлоадера при необходимости обновить прошивку. Я это продумывал для программатора STM32, но это достаточно сильное усложнение и проще заставить пользователя переключателем выбирать режим "работа" или "прошивка". Хотя для каких-то проектов это может быть актуально.
У меня есть два модуля FT232 с аликспресса и оба работают некоторое время, потом подвисают на полсекунды и заново начинают работать. Причём модули куплены в разное время. Для статьи я нашёл совсем другой модуль FT232, купленный очень давно, наверное лет 5 назад:) Он хорошо работает.
Судя по описанию функции DateTime.Now.Ticks, она выдаёт таймкод с шагом 100 нс. Это очень даже точно для моих задач:) Я её немного протестировал вместе с осциллографом и вроде бы она вполне точно показывает отсчёты как для измерения времени, так и для организации задержки в цикле.
Если бы функции COM-порта работали значительно быстрее, тогда, действительно, лучше было бы использовать специальные методы. Но тут я уже знал, что функции работают медленно (так как видел на осциллографе задержки в миллисекунды), поэтому такого таймера вполне достаточно.
Ничего не понятно, но выглядит круто:) Пока читал ваш комментарий, пришла идея: можно через DTR и RTS управлять электронными ключами (типа DG408 или 74HC4066), чтобы "нажимать" отдельные кнопки на плате от клавиатуры или других устройств. То есть, получается программное нажатие, но распознаваться будет как реальное от пользователя.
Не уверен, что проще, вроде бы это делается через SDK от FTDI, а не через функции COM-порта. То есть, надо будет что-то ставить и изучать другие функции. Да и решение будет не универсальным. Хотя, конечно, так было бы больше возможностей. Но так то и дешёвый микроконтроллер поставить на UART не так уж сложно:)
Да, спасибо, вроде я всё это уже изучил и понял проблему. Свойство Stopwatch.Frequency возвращает true, значит, у меня таймер высокого разрешения. И вышеприведённый код я уже проверил на измерении времени выполнения расчётов в цикле - он показывает микросекунды. Например, код
Stopwatch stopWatch = new Stopwatch();
double f = 0;
stopWatch.Start();
for (int i = 0; i < 10000; i++)
{
f += (double)i / 3;
}
stopWatch.Stop();
label1.Text = ((double)stopWatch.ElapsedTicks / (double)Stopwatch.Frequency).ToString();
label2.Text = f.ToString();
всегда выдаёт примерно 5E-05 . То есть, это 50 мкс. Если менять количество циклов, то время тоже меняется через микросекунды, а не миллисекунды, как с функциями COM-порта. То есть, это реально более точный способ, но именно для задачи в статье ничего особо не изменилось.
Скорее всего намного быстрее, но это же будет не универсальное решение. То есть, такой режим используется только в API драйвера, который у каждой фирмы свой. Тогда программу надо затачивать на конкретную микросхему. В этом плане лучше будет использовать специализированные версии типа CP2104 и CH341, у которых есть дополнительные GPIO. Статья же про стандартный COM порт и его выводы:)
А, вот зачем нужно это свойство порта:)
Да, мне тоже CP2102 не подходят именно из-за корпуса. Одну кое-как припаял, но дальше перешёл на CH340 :) Хотя для устройств такой миниатюрный корпус это скорее преимущество, но не для самодельщиков:)
Да, похоже, вы правы, хотя у меня код:
Int64 start_time1 = DateTime.Now.Ticks;Int64 start_time2 = DateTime.Now.Ticks;label1.Text = (start_time2 - start_time1).ToString();Всегда показывает ноль:) Но если добавить какой-то большой цикл с делением между считываниями, то, действительно, время почти всегда кратно 1 мс, хоть и не ровно.
Попробовал такой вариант:
Stopwatch stopWatch = new Stopwatch();stopWatch.Start();bool b = MyPort.CtsHolding;stopWatch.Stop();label1.Text = ((double)stopWatch.ElapsedTicks / (double)Stopwatch.Frequency).ToString();label2.Text = b.ToString();Вроде бы это должно показывать время в секундах. Как результат - примерно то же самое: в среднем функция выполняется 2 мс для CP2102. То есть, вы правы насчёт точности
DateTime.Now.Ticks, но в итоге результаты те же и соStopwatch();Попробовал и другие функции - тоже результат совпадает и так же значения постоянно прыгают с шагом примерно в мс.То есть, функции реально медленные и привязаны к мс, поэтому особенно ничего не изменилось при переходе на более точный метод. Или я что-то не так сделал и тут:)
Идея, конечно, гениальная:) Правда светодиоды CapsLock и NumLock вполне полезны. И ещё они включаются, когда нажимаешь на соответствующие кнопки.
Но можно добавить переключатель, который активирует эту скрытую функцию лампочек на клавиатуре:)
Вы имеете ввиду, что микросхемы USB-UART автоматически перестанут передавать данные, если на CTS будет 0? Что-то мне кажется, это не работает, иначе нужно было бы обязательно подтягивать эти входы к питанию. Если это самому можно отслеживать в своей передающей программе, тогда это неплохой вариант использования. Правда можно просто пореже передавать данные, чтобы не переполнять буфер устройства.
Насчёт ресета девайса: возможно, можно придумать какую-то хитрую логическую схему, чтобы устройство не сбрасывалось случайно при подключении и отключении USB. Например, можно выводить через DTR и RTS специальные комбинации для ресета устройства и активации бутлоадера при необходимости обновить прошивку. Я это продумывал для программатора STM32, но это достаточно сильное усложнение и проще заставить пользователя переключателем выбирать режим "работа" или "прошивка". Хотя для каких-то проектов это может быть актуально.
У меня есть два модуля FT232 с аликспресса и оба работают некоторое время, потом подвисают на полсекунды и заново начинают работать. Причём модули куплены в разное время. Для статьи я нашёл совсем другой модуль FT232, купленный очень давно, наверное лет 5 назад:) Он хорошо работает.
Судя по описанию функции
DateTime.Now.Ticks, она выдаёт таймкод с шагом 100 нс. Это очень даже точно для моих задач:) Я её немного протестировал вместе с осциллографом и вроде бы она вполне точно показывает отсчёты как для измерения времени, так и для организации задержки в цикле.Если бы функции COM-порта работали значительно быстрее, тогда, действительно, лучше было бы использовать специальные методы. Но тут я уже знал, что функции работают медленно (так как видел на осциллографе задержки в миллисекунды), поэтому такого таймера вполне достаточно.
Спасибо, это подробнейший обзор микросхем и их фишек!
Ничего не понятно, но выглядит круто:) Пока читал ваш комментарий, пришла идея: можно через DTR и RTS управлять электронными ключами (типа DG408 или 74HC4066), чтобы "нажимать" отдельные кнопки на плате от клавиатуры или других устройств. То есть, получается программное нажатие, но распознаваться будет как реальное от пользователя.
Да, эта миниатюрная версия мне очень нравится, она прям создана для каких-то портативных устройств.
Не уверен, что проще, вроде бы это делается через SDK от FTDI, а не через функции COM-порта. То есть, надо будет что-то ставить и изучать другие функции. Да и решение будет не универсальным. Хотя, конечно, так было бы больше возможностей. Но так то и дешёвый микроконтроллер поставить на UART не так уж сложно:)
Спасибо. Я эти модули видел, но как-то не рассмотрел на них дополнительные выводы.
Спасибо. Я эти модули видел, но как-то не рассмотрел на них дополнительные выводы.
Да, возможно, и на CP2102 есть подделки. Китайцы очень умелые в этом деле:)