Tomset91, физически каналы приёма и передачи данных разделены (контакты 2 и 3 разъёма COM) Приём данных и запись их в буфер происходит независимо от пользователя, когда пользователь подаёт команду на приём -- читается не сам порт, а его буфер -- самые первые байты в количестве, которое указал пользователь в своей команде. (Буфер не бесконечен, по умолчанию 512 байт, поэтому между скоростью порта, частотой считывания и количеством считываемых байт должно быть соответствие, например при установленной скорости 9600 бит/сек, что равно 960 байт/сек (байт=8 бит + 1 старт + 1 окончание=10 бит/байт) и установленном размере считывания 32 байта, период считывания должен быть не менее 1/(960/32)=32 миллисек. Чаще обращатся к порту -- излишне нагружать компьютер, реже -- в буфере пропадут не считанные данные.
Только в случае соединения контактов "2" и "3"
порта, или открытия одного порта дважды, один на передачу, второй на приём и "тихо сам с собою вести беседу"

Леонид, если этот буфер есть то почему не запоминает? Запускаю программу отправляю данные в порт, потом жму кнопку sent тем самым активирую передачу и приём данных но почему то в окне приёма пусто, тоесть данные не считываются из буфера как будто его там и нет... они считываются если постоянно отправлять данные в порт и в этот момент кликать кнопкой sent и то срабатывает не при каждом нажатие, есть потери... А вот и нет, программа ведёт себя аналогично... тоесть считывает данные с контроллера причём ошибок нет, но передаю всего по одному байту с перерывом 1с для наглядность появления цифр в окне приёма.

[offtop]
Ну, честно говоря, они в буфер не попадают вообще, они просто не регистрируются. Причина в наглом упрощении спецификации RS232 в 99.9% популярных устройств: не используются по назначению шины DSR и DTR. Шины закорачиваются и даже порою используются для питания логики. Естественно, отсылающая сторона думает, что принимающая всегда готова и шлёт напропалую. По работе приходилось не раз иметь дело вообще с двумя проводками - общим и замкнутыми RX и TX, этакая симплексная шина, бюджетный вариант.[/offtop]

Так всё же мне до сих пор не понятна связь между onWrite и doRead, по сути и она тут не нужна, я просто должен кликать точку doRead чтобы прочитать порт, причём чтобы не потерять данные - скорость кликанья должна быть высокой а это нагрузка на компьютер... Но как работают другие терминалы если там использую теже самые TX и RX, буферы как отметил товаришь 1nd1g0 не регистрируются, а данные считываются все до единого без потерь и нагрузки на комп как таковой я вообще не вижу... А если вспомнить: А это говорит о том что компонент сделан вообще неправильно... и точка doRead в нём и ненужна вообще, данные он должен считывать не когда кто-то кликнет по doRead, а когда они поступят в порт тем самым произойдёт прерывание.

А вот предвидя такой поворот разговора я и говорил Вам с самого начала темы, в самом первом посте: это - СИНХРОННЫЙ вариант работы с портом, если Вы хотите, чтобы порт САМ обращался к Вашей программе, когда ему есть что сказать - добро пожаловать в ПОИСК по форуму, сверху этой страницы. Ищите НЕСТАНДАРТНЫЕ компоненты для АСИНХРОННОЙ работы с портом. И готовьтесь к тому, что Вам светят серьёзные подводные камни, так как там в дело вступает многопоточное программирование, потенциальные конфликты доступа к данным и т.д. Разработчики не по глупости оставили синхронный вариант, подозреваю, им просто было лень ловить многочисленные глюки и отвечать на сотни жалоб на форуме по поводу побочных эффектов колбэков из параллельных потоков с другим контекстом.

Редактировалось 2 раз(а), последний 2025-01-09 16:06:07

Редактировалось 2 раз(а), последний 2025-01-09 16:06:07

[flood]
Строго говоря это зависит от операционной системы, современная тенденция - отключать все прерывания, которые только можно (можно, правда, не все) и эмулировать их работу, но на старых системах такое утверждение ещё справедливо, так что не буду цепляться к словам и читать нотации, по теме я ему ответил.[/flood]

Почему бы этим разработчикам не создать простой компонент с одним выходом который регистрирует прерывания IRQ4 и IRQ3 (выбираем в свойствах) и при подключении ко входу doRead превращает компонент в полноценный ком порт с которым можно работать, а глюки устраняются запрешением прерываний в ответственных местах а также push / pop

Tomset91, а можно переопределить события на другие прерывания?

А вот действительно не могу понять зачем в справке они взязаны к тому же через задержку, когда onWrite - всего лишь число переданных байт и не нужно его никада привязывать. А doRead вход кликая который мы вызываем чтение данных поступающих в порт.
------------ Дoбавленo в 22.17:
непонимаю смысла сообщения? прерывание вроде и есть событие можно вроде только само прерывание привязать к другой подпрограмме которое его обработает..

золотые слова! И что? Делать компонент регистрирующий все прервывания в системе?

Было бы не плохо если кто-то сделает, а вообще меня пока интересуют только два IRQ4 и IRQ3... хотя если компонент то просто в свойствах выбирать IRQ1 - IRQ(n), и надо наверно ещё делать второй компонент который будет эти прерывания запрещать/разрешать на отдельных участках как вообще все полностью все, так и какое то одно указанное..

Tomset91, можно сделать по всякому, но нужно принимать компоненты HiAsm такими, какие есть, хотя бы на этапе знакомства.
Утановите на doRead таймер и Вы получите данные из порта в непрерывном режиме без всякого "прерывания" (связь между временными установками выше).
может и так (по теории), но на практике HiAsm-а (в своё время проверял имея на борту два COM порта) при меньшей скорости считывания пропадают не новые данные, а выданные раньше.

Tomset91, у компонента есть ещё две точки, которые служат для управления : doDTR и doRTS.
А для любимых IRQ4 и IRQ3 примени IC (если система позволит)