jcmvbkbc

почему переход от 0 на 1 при ввключении устройства не интерпретируется, а при переходе с 0 на 1 в конце передачи интерпретируется именно как стоп-бит

Sneiksus, интерпретация состоит в том, что бит принимается и проверяется, что он -- "1", иначе -- ошибка фрейминга при приёме байта. То что в этом месте ожидался стоп-бит приёмник понимает просто считая принятые биты после старта.

почему тогда переход от стоп бита на лог. 1 интерпретируется?

Sneiksus, как интерпретируется? Стоп-бит это тоже 1.

То есть до получения стартового бита( перехода с 1 на 0) он не начинает работу?

В первом приближении -- да.
Есть ещё BREAK, когда в линию выдаются непрерывно нули, но это детали фрейминга более высокого уровня.

передатчик выключен а приемник вклюен, и на rx пине у него лог. 0 а когда включается передатчик в режиме ожидания и у него сразу появляется лог. 1 Такую ситуацию он как интерпретирует?

Никак не интерпретирует, это нарастающий фронт.

Получится сделать задержку каждых 104 микросекунды с тактовой частотой чипа 2мгц,

Не вижу с этим проблемы.

И еще, если все вже использовать задержку длино 1мс, то это не будет работать на меьшей скорости?

Никакой стандартной скорости это не соответствует. 1200 немного быстрее, 300 существенно медленнее.

Когда ставишь скорость 9600 то чип прям ожидает что сигнал будет меняться точно с такой скоростью? Просто стало интересно если например подрят идут две логические единицы, то как он понимает что это два разных бита, а не один и тот же или переход в режим ожидания.

Приёмник синхронизируется по спадающему фронту в начале стартового бита и ожидает что следующие информационные биты, бит чётности и стоповые биты прийдут с настроенной скоростью. Обычно приёмник самплит сигнал на повышенной частоте (мне встречались варианты до x16) и выбирает отсчёты из середины временного диапазона отведённого биту. Это позволяет передатчику использовать не точное значение битовой скорости, а приближённое, пока ошибка накопленная за время передачи всех битов одного байта не превышает ~20% одного битового интервала.

Павел Соколов, можно начать с того, что выкинуть из картины неизвестное -- UART на верилоге, а оставить только UART на PC подключенный сам к себе (RX - TX, CTS - RTS, DTR - DSR) и вашу программу и убедиться, что она работает как ожидается.

Я не просто так указал verilog здесь

Павел Соколов, толку от этого указания нет, виндовому коду всё равно что на той стороне. Верилог в тегах имеет смысл указывать, если вопрос про верилог.

при созданном файле с флагом overlapped

Павел Соколов, зачем открывать его с этим флагом?

как я понял мне нужно убрать указатель на число обозначающее сколько было записано/прочтено, но оставить GetOverlappedResult для асинхронного порта

Павел Соколов, можно сделать так. Можно сделать наоборот, код станет ещё проще.

Это и есть причина таких смещений и ошибок?

Это сомнительно выглядящее место в предоставленном куске кода. Это может быть причиной.

то есть ReadFileEx должно упростить и исправить ситуацию?

Павел Соколов, чем плох просто ReadFile?

Проверка чтения идет по возвращаемому DWORD.

В возвращаемом DWORD будет мусор, если операция чтения не завершилась, а проверки на это нет.

Я уберу GetOverlappedResult

Только если вместе с параметром overlapped функций ReadFile/WriteFile.

Сложно потому что IO_PENDING, OVERLAPPED в асинхронном режиме должна быть не NULL в WriteFile

Зачем здесь асинхронный режим, если синхронный вызов

GetOverlappedResult(port_handle, &overlap, &NumOfWritten, TRUE)

идёт сразу следом за WriteFile?

DWORD ComIface::read_block(byte* buffer, int size) должна за 1 ReadFile заполнить byte[N]

Ничто в приведённом коде на это не указывает. Совместная передача &NumberOfBytesRead и &overlap в ReadFile не рекомендуется, см. Отсутствие проверки результата вызова ReadFile выглядит стрёмно.

вышла ошибка
Как исправить эту ошибку

Приведи текст сообщения об ошибке.

Я пытаюсь получить имя моего телефона, с помощью Python

нужен код.

Вместо имени телефона, я получаю "localhost" или другую несуразицу.

обычно у хоста множество имён и "localhost" -- одно из них.

Lynn «Кофеман», вопрос, как я понимаю, в том, используют ли RSA в качестве сенсового ключа.

Имя, в этом примере ты собираешься хранить компоненты addr -- вместо этого храни uint32_t addr целиком.

uint32_t' {aka 'long unsigned int'}

Сергей Соловьев, long unsigned int не может быть 32 бита на 64-битной машине, только в модели LLP64.

я специально посмотрел в исходники и…
typedef unsigned int __uint32_t;

чот как-то невнимательно посмотрел?

conversion from 'uint32_t' {aka 'long unsigned int'}
протестировал это … на x86_64

автор собирает 32-битный код, судя по всему

Таким образом мы только можем получить ксор всех этапов. Т.е. первых х байт из всех 16 этапов. Это не даёт никаких преимуществ потому, что мы не можем знать полный хеш

Савва Насыров, ты ошибаешься. Попробуй зашифровать своим алгоритмом буфер состоящий из одних нулей, а потом побайтово поксорь полученным результатом какой-нибудь зашифрованный тем же паролем текст.

я думаю что не стоит рассматривать ситуации, когда большая часть текста является раскрытой. Это просто не имеет смысла

Это имеет смысл, потому что шифруемые сообщения могут иметь структуру, а значит не всё их содержимое может контролироваться отправителем.

одно я понял точно: универ, где я учусь, параша: нас учили использовать в таких случаях fflish(stdin)

70-C9-4E-54-03-2F, по хорошему универ вообще не должен "учить" деталям такого уровня. Но, увы, ровно то же самое говорили и мне в студенчестве в моём универе, 25 лет назад.

и у всех как ни странно работало

Я помню у меня тоже работало, в Borland C для MS/DOS.

с какой операционной системы или что у вас за терминал

Уверен, что имеет значение только то, какая используется libc -- в моём случае это glibc 2.36, но для полноты картины: моя ОС -- Debian 12.

так ваш вариант с пробелом после спецификатора формата в scanf не работает должным образом

70-C9-4E-54-03-2F, я знаю. И я написал вариант на замену который считаю более хорошим, вот здесь.

и да будет вам счастье с ожидаемым поведением, описанное стандартом и чем-угодно

Вы поймите, я же не просто так это написал. Я поделился практическим наблюдением, что fflush(stdin) не работает и показал, что этому есть обоснование в мануале (кстати, в стандарте C99 вообще написано, что fflush для потока ввода -- UB). Не нужно из-за этого чувствовать себя уязвлённым, так работает этот сайт: люди указывают вам на ваши ошибки, а вы им -- на их.