Доброго времени суток!

Есть небольшой проектик в котором я расчитывал передавать по RS485 данные на ПК со скоростью более 115200.
Первую прикидку делал в CodeVision:
// USART0 initialization
// Communication Parameters: 8 Data, 1 Stop, No Parity
// USART0 Receiver: On
// USART0 Transmitter: On
// USART0 Mode: Asynchronous
// USART0 Baud rate: 115200
UCSR0A=0x02;
UCSR0B=0x98;
UCSR0C=0x06;
UBRR0H=0x00;
UBRR0L=0x05;

Так вот при передачи данных с Atmega128 на ПК - получаю коверканые данне.
А при передачи с ПК на Atmega128 - ничего не получаею 8(

У когото был положительный опыт такой передачи?

ЗЫ:
Кварц 11,0592Мгц
На компе пробовал как родным COM портом так и USB-RS232(Ftdi)
В данный момент не могу посмотреть осцилографом 8(

А ваш COM-порт на PC "умеет" принимать данные на такой скорости? На более низкой скорости, скажем 115200, прием-передача идет нормально? И какой вы все же интерфейс испытываете? Вначале сообщения про RS485 вроде упоминается, а в реальности что? Если RS485, то какой конвертор RS485-RS232 используете?

Скорее всего комп не поддерживает скорость выше 115200.
Кстати, на 115200 пробовали?

Странно, но 230400 для Fosc=11059200 соответствует UBRR = 0x002. А вобще, пробовал вплоть до 921600, всё шло как надо.

На случай если сильно расходятся частоты, как может быть в случае с ft(2)232, могу лишь посоветовать ставить на ПК 2 стоп-бита, на МК - один и отправлять очередной байт с МК не по UDRE, а по UTXC, и может даже добавить небольшую задержку, удлинняющую стоповый бит - это чтобы не накапливалась ошибка расхождения частоты.

Ну ясен перец. что на 115200 я пробовал и передача шла нормальная!!!
Драйвер RS485 - поддерживает скорость до мегабита.
Приемная часть на ПR FT232BM + 485-й драйвер.

Спасибо "man with no name" за ответ по существу.
Сегодня попробую этот вариант.

А временнЫе паузы задержек переключения драйвера RS485 передача/прием и задержки выдачи ответа выдерживаются?

Ну ясен перец 8)
Я же сказал, что все работало на 115200...

А соедините вход и выход у FTDI (или у COM-порта), и попробуйте передавать данные. Сразу будет видно, где грабли - в ПК или в Меге. Попадались мне платы, которые не хотели понимать скорость больше, чем 115200. Хотя, FTDI вроде до 8 Мбит работает ... Может, её драйверы поток байтов разгребать не успевают.

Дык, а мне не ясно, откуда этот перец? Ведь не работает же
Кроме того, что многие UART в PC не поддерживают работу на скорости выше чем, 128000 бит/с, могу сказать, что я не видел вашу схему конвертора. Каким способом переключается направление передачи в конверторе USB-RS485?
Собственное "эхо" на выбранной скорости оба устройства (PC с конвертором USB-RS485 и МК с RS485) ловят? Проверить это можно, если не отключать приемник RS485 на время передачи, например, для MAX485 нужно управлять только сигналом DE, а RE просто "приземлить". Если "эхо" ловится нормально, то какие временные паузы у вас:
- удержания линии RS485 после передачи
- задержки передачи ответа после приема пакета?
Они постоянные или рассчитываются в зависимости от скорости передачи?

попробуйте согласно AN232B-05_BaudRates(FTDI appl. note) исправить одну из маленьких скоростей на ту что нужно вам.
мне однажды это помогло.

Добрался до железа.
Повозился - завёл.
Что ни говори а усиленное штудирование мануалов - прочищает 8)

Железо:
Atmega128 - 11.0592MGz
Драйвер RS485
линия передачи
Драйвер RS485
FT232BM c подключенным TXDEN к RXEN и TXEN на драйвере RS485.
Скорость 230400.
Передача данных работает.
Байтики бегают и принимаются.

FT232BM сам регулирует прием перачу и задержки.
Мега работает так:
Висим в приеме.
Как только приняли пакет данных - переключаемся на передачу.
Передаем данные.
Ждем 1мс
переключаемся в прием.

Но вот, что вылезло:
Время от отправки пакета (10 байт) до получения ответа (5 байт) составляет 15-16мс (замерял Visual Studio)

Что-то многовато 8(
Появилось подозрение на дрова FTDI 8(

Скачал последнюю версию.
Поигрался с Latency Timer в настройках драйвера. По умолчанию - 16 мс. Поставил на 1мс.
Слегка помогло. Но теперь каждые 5-6 запрос/ответ отрабатывает по старой схеме (15-16мс на цикл опроса).

Никто не сталкивался с подобной ситуацией?
Или для это FT232BM нормальная ситуация?

ну так это ж USB...

Здесь ошибка. Нужно выждать гарантированную паузу, чтобы уже мастер был готов к приему ответа. В вашем случае FT232 видимо быстро в готовность переходит, а другому оборудованию может потребоваться до десятков мс, чтобы перейти в режим приема ответа. Тем более когда линия связи весьма протяженная и на линии присутствуют репитеры RS485. А такой вариант исключать никогда нельзя.
Здесь тоже должна быть временнАя задержка пропорциональная скорости передачи длительностью хотя бы в один символ. Хотя 1мс задержки переключения передатчика RS485 на прием достаточно вплоть до скорости 9600, но если вы только не "настольный" вариант делаете, то все эти паузы и задержки должны быть настраиваемыми под конкретное оборудование (контроллер/конвертор), скорость передачи и линию связи.

Я разве говорил про какое-то стороннее оборудование?
Ничего такого нет и не предвидится. А мне нужно получить наибольшую скорость передачи данных.
Да и все пакеты приходят гарантированно сбоев нету.
Есть какая-то задержка!!!

ЗЫ:
Комментарии полезные (за них спасибо) но не по существу 8(

Если вы спрашиваете "как уменьшить паузу м/у приёмом и передачей менее 15мс на PC", то ответ - никак! Это обсуждалось уже. Даже из под ДОСа у вас будут просечки. А из под винды и подавно. Более того, чтобы обеспечить равномерность и единообразность работы на разном железе, я бы рекомендовал увеличить данный интервал до 20-25мс.

Для увеличения общей скорости необходимо увеличивать длину пакетов либо переходить на другой интерфейс. Например непосредственно на USB.

зайди на сайт FTDI и прочитай AN232B-04_DataLatencyFlow.pdf

Поздравляю, Вы опытным путем установили такт Вашей операционки Windows...
Он оказался 15-16мс...
Хотя чтобы это понятять не нужно было такие сложные тесты придумывать
А как с этим бороться, это уже совсем другой и очень непростой вопрос...

Ну я бы так не сказал 8)
Абсолютно правильный ответ дал yuldash
А по поводу такта ОС - сильно сомневаюсь 8)

+1
+1
+1
Кстати, когда я первый раз увидел подобное обсуждение, я удивился - о каком таком козырьке какой такой задержке идёт речь? У себя несколько раз скопом лазил - никаких задержек в кучу милисекунд не видел.
Потом дошло - я гораздо раньше обмен для просто COM-порта сделал через OVERLAPPED с отмашкой по EventCharacter (и выставил его на SLIP_END), чтобы поток ком-порта всплывал по концу пакета, а не на каждый байт. А драйвер VCP аккуратно передал этот код из DCB в ft232 и всё бегало так быстро, как могло.

В чем сомневаетесь ? В том что такт у Windows от 10 до 20 мс ?
Это легко можно померить, у меня на одном компе 10мс на другом ~16мс.
Правда например у Windows Server такт 1-3мс
Ну и еще есть проги которые меняют такт Windows до 1-3мс ни у кого не спрашивая и
никого не предупреждая, например так ведет себя Qip.