Александр Кузнецов: ваша мысль ясна. Ну у меня изначально является отдельным классом специально для потока. Так как у меня не один поток. Поэтому и взял только Task, который быстрее работает в асинхронном режиме. Но ваше предложение возьму на заметку, если всё-таки пойдёт не так хотелось бы. Просто с помощью заглушки я выяснил, что данные всё-таки передаются, но с интересной спецификой принятия условия. Например, сейчас у меня первым читается условие Commands.HasFlag(Ядро_хххх.BasicStructures.Command.NotOperation), значит, данные Commands будут пропускаться. Но если поставить первым вот такой вариант: Commands.HasFlag(Ядро_хххх.BasicStructures.LoadFPGAAll) - , то работает нормально, данные принимаются сразу. И никаких зависаний. Значит, у меня всё-таки есть ошибка в алгоритме, которую надо исправлять.
Александр Кузнецов: мда... внезапно вернулся в норму... Теперь данные пошли по старому. Правда, пока без чтения и записи. Придётся мне перепроверить свой код.
Thread.Sleep(1) добавлял - без толку. Для отладки решил просто тупо отключить чтение и запись и проверить механизм цикла в том методе, где данные приходили. И заметил, что поток продолжает работать, но почему-то становится потоком UI-интерфейса, отсюда и зависания приложения (тот же эффект вызывает при нажатии на кнопку с бесконечным в методе без потока).
Ну у меня нет точки входа данных. Данные располагаются прямо в классе. Данные передаются двунаправленно: ReadData и WriteData, а также дополнительные данные управления потоком. Судя по вашему примеру вы предлагаете мне вынести механизмы чтения и записи в отдельный класс? В общем, подумаю над вашим вариантом.
Я пробовал сделать подобному варианту: https://msdn.microsoft.com/ru-ru/library/x13ttww7.aspx Приложение игнорирует такой подход. Честно говоря, я удивлён, что это перестало работать. Этот же код нормально работал в предыдущем проекте. Даже сейчас используется тот же подход.
cmds - он исключительно внутренний для отладки, когда обнаружил, что данные не передаются в Commands. В реальности как это выглядит. Я нажимаю на кнопку. В методе присваивается некоторое значение Commands. А Commands объявлен в классе, где и находится метод потока. А поток, по идее, уже должен попутно подхватить новый параметр в классе.
Полем на данный момент является cmd для отладки. А так - это Command. Просто я расставил точки останова, чтобы поймать данные. Изначально они без volatile. Раньше как-то работало без этого прекрасно. Только большие данные надо было пинком передать. Потом после вашего упоминания про volatile решил разобраться с этим. Да, volatile действительно может чем-то помочь. Сумел-таки поймать в точках останова. Правда, они немного странно действуют. Придётся проанализировать алгоритм. Сейчас с volatile у меня программа виснет. Просто у меня изначально потоком является Task. Так как он проще и производительней.
Почему нет команд? Вот есть сайт-справочник: looch-disasm.narod.ru/refe20.htm Там написано, при каких условиях можно прыгать на другие участки кода. А вот команду cmp 0,5. Я так и не понял. Там не может быть выполнения с двумя значениями без регистра.
Кстати, у клавиатуры приёмник на каком расстоянии находится от модулей Bluetooth/WiFi? Просто у меня был схожий опыт от другой фирмы. Заметил я тогда, что приёмник начинает вести неадекватно уже с расстояния на 10 см от модулей WiFi/Bluetooth. Переместил на большее расстояние, эффекты пропали. Попробуйте опытным путём установить причину этого явления. Судя по всему, ваша клавиатура работает на той же частоте на каком-то из каналов, пересекающих с WiFi/Bluetooth.
rromm: и? Вы серьёзно предполагаете, что USB 3.1 будет использовать только 10 жил? USB 3.1 использует 16 линий. Если добавилась ещё пара дифференциальных пар, то, соответственно будет больше линий. Зеркало понимается, когда Rx1+/Rx1- может стать Rx2+/Rx2- и обратно. Для Tx1+/Tx1- и Tx2+/Tx2- тоже самое. Это позволяет человеку подключать то одной стороной, то другой. Это и есть зеркало. D+/D- исключительно дублируются на другой стороне. А остальные имеют один и тот же тип, и подключаются к одной линий, соответствующей ей типу.
rromm: в таблице автор из Википедии забыл добавить пару контактов: B6 и B7, не уточнив, что они соответствуют A6 и A7, поэтому в таблицу не попали. Подсчитал, всё правильно. Например, общая земля занимает сразу 4 контакта, что и подтверждается на разъёме (их там четыре). Питание тоже. Дифференциальные линии сигналы описали отдельно. Потому что они разные по описанию. Например: "Экранированная дифференциальная пара #1, negative", а "Экранированная дифференциальная пара #1, positive" - это одна дифференциальная пара (Tx+ / Tx-) или (Rx+ / Rx-). Здесь я немного ошибся в числе дифференциальных пар. Тут их четыре, а не два, как в USB 3.0:
1) Tx1+, Tx1-
2) Rx1+, Rx1-
3) Tx2+, Tx2-
4) Rx2+, Rx2-
А так не вижу никаких ошибок в описании.
rromm: я добавил ещё одну картинку, чтобы вы поняли, что есть провод, а есть контакты, которые соединяются к жилам. Некоторые контакты дублируются. В одних задачах для надёжности передаваемого сигнала, в других задачах для избежания ошибок неверного подключения контакта. Вот в USB 3 используется второй случай.
rromm: вы читали в таблице "Цвет оболочки проводника"? Он указывает, какие контакты к нему подключены. Здесь вообще только две дифференциальные пары. (Tx1+ Tx1-), (Tx2+ Tx2-) - это одна дифференциальная пара на четыре контакта, (Rx1+ Rx1-), (Rx2+ Rx2-) - вторая дифференциальная пара на четыре контакта. В той же таблице даже чётко указана.
