Какой-то нездоровый оптимизм. Похоже невнимательно следите за публикациями на хабре.
А почитайте-ка про Weird machine. Дело в том, что определенными воздействиями любую реальную программу можно заставить работать глючно.
Мне в этом плане понравилась вот эта статья- https://tcipg.org/sites/default/files/papers/2014_q3_tfs1.pdf
Мужики просто манипуляцией прерываниями заставляют контроллер выполнить нужный им код, которого изначально нет в прошивке.
И вычислить анализом кода этот баг невозможно.
В опенсорсах так не принято.
Нормальная практика бутлодер сразу с приложением писать, находят они друг друга через специальные сектора во Flash, линкуются одновременно.
Помню писал загрузчик для линукса, так там целые связные списки бесконечного числа опций передавались из бутлодера в линукс.
Да это не работа, а лафа.
Из софта всего один стек TCP знать надо.
Завалы могут быть только из-за софта, все остальное тюнингируется за условный день.
Так что я бы за такую работу ухватился бы обеими руками.
Что, так и застряли на одном месте? Программирование остановилось?
Не можете выбрать, как тот персонаж из парадокса Буридана?
Интересно всё таки, что вы делаете когда не можете выбрать имя.
Придумывание имен - главная работа программиста. Весь ООП есть борьба с дефицитом имен.
Стандартный путь будет создать контекстное окружение чтобы дать самое простое имя. Например R или reg или mask.
А вот окружение (структура, класс, модуль, пространство имен ...) должно именоваться так чтобы однозначно понимать имена всех вложенных простых переменных.
А рядом с объявлением переменной должен стоять толковый комментарий, чтобы всплывающая подсказка сразу его показывала.
Так хорошая экономия имен получается.
И не надо держать большой лексикон, а то это напрягает.
Кстати я даю регистрам всегда имена, как они написаны в документации. Они там часто из прописных букв, тогда их копии пишу строчными.
Не, сохранение в файл я еще не сделал.
Тут все таки напоролся на неприятный момент.
Штатный драйвер винды 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 или штатных средств загрузки приложений.
Ну сказки-то не сочиняйте. Это реальные авиационные приборы, симулируются там только воздействия на них.
Ходил я тут недавно посмотреть на авиасимуляторы.
В Европе нынче кризис пилотов, и открылись школы, которые за два года пилотов боингов-айрбасов готовят.
Ну вот так это выглядит для неновой модели айрбаса:
Так там этих операционок - море.
Где-то среди них может и есть огрызки линуксов.
