Перейти к содержанию
    

RS-232 на скоростях 115200 и х2

Даже если сформировать массив из 11520 байт и одной посылкой отправить с СОМ-порт, то все равно между передаваемыми байтами будут некоторые временные интервалы.

В зависимости от железа может составлять от 1 до 4-х битовых интервалов, без учета прочих временных задержек.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Даже если сформировать массив из 11520 байт и одной посылкой отправить с СОМ-порт, то все равно между передаваемыми байтами будут некоторые временные интервалы.

Ню-ню... с чего бы это? Сказки рассказываете.

Интересно почему это у меня тогда получается между моим виндовым приложением и устройством получать 11520 б/сек? :rolleyes:

Осциллограф развеет Ваши заблуждения.

 

В зависимости от железа может составлять от 1 до 4-х битовых интервалов, без учета прочих временных задержек.

А ещё - в зависимости от фаз луны. А скорее - кривости рук кодера.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Жаль что никто не может внятно ответить кто виноват и как быть.

Какая же все таки скорость возможна при описанных условиях? 400 байт/с это же явно очень мало.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Жаль что никто не может внятно ответить...

Вообще-то, на самом деле, это "кто-то" совершенно не хочет НИЧЕГО понимать из более чем внятных объяснений и рекомендаций :( :( :(

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Zltio, ну вот вы скажите, сколько реально получить скорость при описанной ситуации?

Неизвестны условия работы, так что неизвестен результат.

Если пользоваться на незагруженной машине и компилировать с помощью граммотно написанных примочек (напроимер, для C++Билдера встроенные либы не годятся, нужно внешние подключать) - то при передаче пакета увидете 115200. Да и то, все может упереться в размер аппаратного буфера порта.

При передаче отдельных байт- скорее всего, увиденные Вами 200-400 байт в секунду и будут пределом, зависит от сотни причин.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ситуация понятна.

Изначально я ориентировался на опубликованные скорости, считая, что могу получить через порт требуемое количество ОБРАЩЕНИЙ (запись-чтение) за секунду с помощью программы, скомпилированной в Builder C++. Задача именно в этом и состоит - получить максимально возможное количество ОБРАЩЕНИЙ за секунду через порт посредством программных средств верхнего уровня.

Понятно, что драйвера и система Windows съели ресурс времени, потому я получаю с помощью своей программы совершенно смешное количество обращений через порт.

Я не такой специалист по железу, как некоторые местные гуру-пупки, программирую в Builder, потому не знаю многих тонкостей железа.

Ясно одно - реально расчёт количества ОБРАЩЕНИЙ за секунду через порт нельзя вести по стандартной формуле, которая дана в популярной литературе.

И для достижения заявленных характеристик порта для программы из Builder требуется "чистый", не загруженный Windows, и ещё чёрт знает чего...

Интересно, а в Линуксе такая же песня, как и в Windows, по моей задаче?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

передаче пакета[/b] увидете 115200. Да и то, все может упереться в размер аппаратного буфера порта.

Никуда не упрётся. Поднимаете хоть до 921600 бод - при грамотной работе через WinAPI без всяких левых библиотек запросто получается скорость 92160 б/сек.

Обмен с функциями WinAPI конечно в отдельном треде (даже - 3-х отдельных тредах: отдельный для RX, для TX и для обработки событий порта WaitCommEvent()), а не в main-треде приложения.

 

Я не такой специалист по железу, как некоторые местные гуру-пупки, программирую в Builder, потому не знаю многих тонкостей железа.

Вы неспециалист не по железу, а неспециалист в программировании под винду.

Тут уже раз сто популярно разжевали.

 

Интересно, а в Линуксе такая же песня, как и в Windows, по моей задаче?

И в линухе и где угодно у Вас будут те же самые проблемы :laughing:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

И в линухе и где угодно у Вас будут те же самые проблемы

В DOS возможно их не будет, если через прерывание и FIFO работать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вы неспециалист не по железу, а неспециалист в программировании под винду.

Тут уже раз сто популярно разжевали.

Что посоветуете, как специалисты, почитать из книг по виндам относительно моей задачи?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Задача именно в этом и состоит - получить максимально возможное количество ОБРАЩЕНИЙ за секунду

Почитайте про мультимедиа таймеры - разрешение до 1 мс обеспечивают. Если этого мало - Thread и PerformanceCounter может быть выжмут больше

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Что посоветуете, как специалисты, почитать из книг по виндам относительно моей задачи?

Вы своей конечной задачи так и не описали. Судя по всему, она не состоит в передаче данных, т.к. про то, что нужно сделать для нормальной передачи и приема вплоть до 900 кбит/с, вам уже рассказали . Для какой задачи нужно считать число обращений к порту за секунду? Просто по максимуму загрузить проц? Просто учебная задача без внятного смысла?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Что посоветуете, как специалисты, почитать из книг по виндам относительно моей задачи?

 

Тут уже и намекали и впрямую советовали обратить внимание что пишите под виндой, а драйверы винды созданы с учетом пакетной работы устройств ввода-вывода, к коим относится и ком-порт, вы же пытаетесь размер пакета ужать до 1 символа, соотв. крайне нерационально используете данные вам методы. Если так уж прижало обмениваться по 1 байту, что считаю полным бредом, пишите свой драйвер под DDK или под досом, тогда получите прямой доступ к УАРТу и получите свои заветные скорости, даже на 1 байте...

Данный вопрос так же не актуален при программировании на микроконтроллерах...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Обмен с функциями WinAPI конечно в отдельном треде (даже - 3-х отдельных тредах: отдельный для RX, для TX и для обработки событий порта WaitCommEvent()), а не в main-треде приложения.

Интересно, почему простой синхронный обмен в потоке основной программы не годится?

Если нет необходимости выполнять какие-либо операции в процессе ожидания получения данных, то какой смысл создавать новый поток? Почему просто не подождать, пока ReadFile не вернет управление основной программе?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Почему просто не подождать, пока ReadFile не вернет управление основной программе?

Если у Вас одна единственная программа во всем компьютере, то можете и ждать :) и не пущать никого пока не отберут время силой. Ну а по хорошему надо отдавать ненужное время добровольно.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...