Jump to content

    

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

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

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

Share this post


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

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

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

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

 

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

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

Share this post


Link to post
Share on other sites

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

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

 

Share this post


Link to post
Share on other sites
Жаль что никто не может внятно ответить...

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

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Zltio, ну вот вы скажите, сколько реально получить скорость при описанной ситуации?

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

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

Share this post


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

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

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

 

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

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

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

 

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

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

Share this post


Link to post
Share on other sites
И в линухе и где угодно у Вас будут те же самые проблемы

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

Share this post


Link to post
Share on other sites
Вы неспециалист не по железу, а неспециалист в программировании под винду.

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

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

 

Share this post


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

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

Share this post


Link to post
Share on other sites
Что посоветуете, как специалисты, почитать из книг по виндам относительно моей задачи?

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

Share this post


Link to post
Share on other sites
Что посоветуете, как специалисты, почитать из книг по виндам относительно моей задачи?

 

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

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

Share this post


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

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

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

Share this post


Link to post
Share on other sites
Почему просто не подождать, пока ReadFile не вернет управление основной программе?

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

 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this