Atmega128 UART на 230400, Не получается завести Atmega128 UART на 230400 кбит/с... Опции

[anpilog]

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

Есть небольшой проектик в котором я расчитывал передавать по 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(

[TinyQ]

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

[anpilog]

Добрался до железа.
Повозился - завёл.
Что ни говори а усиленное штудирование мануалов - прочищает 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 нормальная ситуация?

[singlskv]

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

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

[anpilog]

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

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

[ReAl]

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

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