Не, сохранение в файл я еще не сделал.
Тут все таки напоролся на неприятный момент.
Штатный драйвер винды usbser.sys все таки изредка выдает сообщение USBD_STATUS_CANCELED и все рушится.
Придется еще с этим разбираться.
Но однако это странно. Вы ж начали с того что ищите программу, которая быстро могла бы качать по виртуальному COM порту.
Я как бы вам сообщил предельные возможности таких програм. И даже спасибо не слышу.
Но вам повезло, так как я сейчас как раз занят такой же проблемой.
Только что протестировал скорость виртуального UART-а у моего модуля . Там стоит HS USB 2.0 и через него два COM порта организовано.
Прокачал 500 мегабайт (524 288 000 байт) со скоростью 7 606 215 байт/сек (т.е. перекачал весь блок за 69 сек) без квитирования и контроля потока!
Еще не забудьте про ограничение прав для нижнего приоритета, ограничение полосы пропускания памяти для них, ограничение на доступ и получите хостовую ос в виде того же линукса.
Т.е. бред.
Это фишка виртуального моста. Он может буферизировать неограниченное количество байт, хоть всю RAM виндов зарезервировать под это.
Поэтому передатчик все передал, а приемник может получать хоть весь день и даже после выключения и включения компьютера похоже мост сохраняет данные.
Ну и скорость передачи гуляет очень сильно.
Во первых, шедулер виндов даже после установки максимального приоритета не дает процессу больше 25-42% процентов времени. Сколько точно даст зависит от того как карты лягут.
Во вторых в функции API ReadFile можно задать размер блока до 0xFFFFFFFF , что я и делал чтобы достичь максимальной скорости чтения. И она получалась максимальная до 70 мегабайт/сек.
При размере блока 512 байт скорость снижается до 2.8 мегабайт/сек (Win 10 Home 1803, i7-6700HQ 3 GHz, 16.0 GB RAM)
Шедулер виндов довольно хитрый. Увеличение блока до нескольких гигабайт не обязательно даст максимальную скорость.
Там есть где-то оптимальный размер блока.
А я продвинулся с виртуальным мостом.
Поскольку думаю сначала нужно сделать надежную программу приемник на PC, а потом уже разбираться что да как на интерфейсах.
Так вот под чистой консолью, в 64-х битном режиме с максимальной оптимизацией, с максимальным приоритетом процесса и потока, без всякого flowcontrol, на чистом Windows API, с чтением одним гигантским блоком в 500мег мне удалось сделать приемник на 560..480 мбит/c.
Передатчик правда в это же самое время работает на скорости 1440..1200 мбит/с
Вот пример командного файла запуска консольных передатчика и приемника - Run_all.cmd.
Консольное приложение - VS_CommTest.exe
Работает идеально, ни одного сбоя. Хоть гигабайтами качай. (но не больше 2Г, счетчик- int32_t )
Да, сам виртуальный мост я взял на https://www.hhdsoftware.com/virtual-serial-ports
А WinRT API оказывается не умеет открывать порты на виртуальных мостах.
А почему бы и нет.
Там во первых может стоять не менее 4-х процессоров, 3-и из них в режиме lock-step (троирование) и один телеметрический. И вот телеметрический может держать в себе линукс. Ну это так, предположение.
А уж как не согласятся пользователи смартфонов с камерами. Я первый не соглашусь.
Но это не отменяет первый закон - сторонние приложения убивают риалтайм. Поэтому Cаnon и не дает API или штатных средств загрузки приложений.
Ну сказки-то не сочиняйте. Это реальные авиационные приборы, симулируются там только воздействия на них.
Ходил я тут недавно посмотреть на авиасимуляторы.
В Европе нынче кризис пилотов, и открылись школы, которые за два года пилотов боингов-айрбасов готовят.
Ну вот так это выглядит для неновой модели айрбаса:
Так там этих операционок - море.
Где-то среди них может и есть огрызки линуксов.
Магнит потребуется размером не меньше чем сантиметров 10 в диаметре марки N45
Если магнит 1..2 см, то с расстояния 30 см его учуят только чувствительные GMR сенсоры типа TLI5012
Так вам же сказали. Поделите мощность на напряжение.
Напряжение знаете.
А мощность складывается из мощности электрических потерь и мощности на механической нагрузке включая потери на трение.
Мощность потерь считаете измерив сопротивление обмоток статора и ротора.
Потери на трение как функцию скорости и проч. факторов должны были узнать эмпирически, тут формул не бывает.
Мощность на нагрузке измеряют динамометром и тахометром.
Однако закон сохранения энергии и никакой магии.
А здесь как раз все и начинается.
Когда вы наконец поняли что дело в виндах, надо начинать искать пути решения этой проблемы.
Сперва надо вспомнить что есть Win API и есть WinRT API. Вы какой API использовали?
Ну вам то вижу до таких скоростей, как до луны.
А мне удалось таки прокачать 500 мег в память по виртуальному мосту на скорости 120 Мбит/c.
Хотя процесс после этого сразу рухнул.
Сделайте хотя бы так, а то унылая дискуссия какая-то получается.
И WireShark тож мучить не надо.
Научно доказано, что он также теряет пакеты как и все остальные.
Удивляет меня только святая вера в некие волшебные драйвера под виндой способные работать на любой скорости.
При этом кого ни спроси все будут клясться, что винда не риалтаймная.
Однако стандартное поведение драйверов винды - затирать данные не прочитаные в юзерспейсе новыми.
Не, аппаратура тут не при чем.
Просто винда как не риалтаймная операционка имеет право терять ивенты.
А нет оконных ивентов - нет приема в вашем процессе.
Т.е. начиная с мегабитных скоростей вы легко можете пропустить пакеты просто потому что вам не дошло сообщение от драйвера.
Эт легко проверить тестируя мосты между виртуальными портами.
Никакое железо и кабеля там вообще не используются, а сбои в передаче однако происходят.
И да, подъем приоритета процесса до максимального не помогает. Даж скорость не увеличивается.
