[Plain 168]

1 час назад, DAndy_boy сказал:

из-за оптопар, которыми они развязывали UART в шкафу

Легко — если подтяжки жабоудушенные, то, выходом из насыщения и ёмкостями, длины уровней будут взаимоизменяться. Единственный доступный вариант — отключить усреднение.

[DAndy_boy 0]

38 минут назад, vov4ick сказал:

Возможно, в старом [:]||||[:] не было длинных посылок и фаза за время приёма не успевала сдвинуться до критического значения.

У меня было, тоже на 485 шине, что у разных МК противоположные по знаку тепловые коэф. ухода частоты RC-генераторов (кварцев не было). Стоило одно из устройств подогреть, связь пропадала. Исправилось сначала костылём - изменением частоты передачи чтобы в рабочем диапазоне температур диапазоны частот приёмопередатчиков перекрывались. Но это было единственное опытное устройство для комнатных условий.

были длинные посылки. на одном и том же Шкафу ставили и старый Баян и новый. На старом все работает, на новом -нет. Все проверяли по несколько раз в одном часе, в одном месте на одном и том же Шкафу, чтобы никто не придрался на фазу луны, марса, суток, температуры дня и т.д. 

[jcxz 184]

2 часа назад, DAndy_boy сказал:

И мы знаем что многие другие устройства, и например, просто ПК точно нормально распарсит ответ.

При постоянном отклонении битовой скорости UART на +-20% никакое устройство не распарсит ответ. Это невозможно в принципе. Чтобы это понимать, достаточно знать - что такое UART и как он работает.

Если же отклонение не постоянное, а гуляет бит-к-биту, со средней накопленной ошибкой к концу байта = ~20% - то да, приём возможен. Но в этом случае нельзя говорить об уходе частоты. В этом случае говорить нужно о "нестабильности длительностей битов +-20%". Но в этом случае и GD должен принимать, скорее всего, если всё правильно настроено. Например - oversampling выставлен в стандартный 16, а не урезанный 8.

[Arlleex 131]

1 час назад, DAndy_boy сказал:

1МГц

Зарядите максимально возможную частоту, и выложите скрины в норм качестве, а то приведенные выше - 10 шакалов из 10 - ничего нормально не разглядеть.

И правильно ли я понял, что Баян-2 (на GD32) отправляет запросы и Шкаф их видит и адекватно парсит, а вот ответы от Шкафа Баян-2 уже не видит?

Выкладывайте код настройки UART, код приема и т.д. А вообще, под отладчиком если смотреть в MCU Баян-2, какие символы наблюдаются в приемном буфере? Условно: выложите ответ Шкафа (в виде последовательности шестнадцатеричных данных) и то, как он принялся в буфер в GD32.

[DAndy_boy 0]

15 минут назад, Arlleex сказал:

Зарядите максимально возможную частоту, и выложите скрины в норм качестве, а то приведенные выше - 10 шакалов из 10 - ничего нормально не разглядеть.

И правильно ли я понял, что Баян-2 (на GD32) отправляет запросы и Шкаф их видит и адекватно парсит, а вот ответы от Шкафа Баян-2 уже не видит?

Выкладывайте код настройки UART, код приема и т.д. А вообще, под отладчиком если смотреть в MCU Баян-2, какие символы наблюдаются в приемном буфере? Условно: выложите ответ Шкафа (в виде последовательности шестнадцатеричных данных) и то, как он принялся в буфер в GD32.

Да, вы правильно поняли.... причем мелкие пакеты в ответе он видит. А чем длиннее ответ тем более испорченные байты идут к концу пакета. Сейчас нет возможности повторить эксперимент. В приложении лог. Код не могу выложить, уж извините. Надо время чтобы выпилить то что надо из него.capture.dsl

[jcxz 184]

13 минут назад, DAndy_boy сказал:

Да, вы правильно поняли.... причем мелкие пакеты в ответе он видит. А чем длиннее ответ тем более испорченные байты идут к концу пакета.

Значит дело не в UART-е GD. Так как UART - интерфейс асинхронный, то при плавании длительностей битов, вероятность корректного приёма байта никак бы не зависела от количества байт в кадре.

Скорее всего - что-то с землями в шкафу или с питанием или с оптопарами (или их питанием) и т.п. Возможно проседает питание какой-то оптопры или ещё какого то посредника между UART-ами.

[DAndy_boy 0]

28 минут назад, jcxz сказал:

Значит дело не в UART-е GD. Так как UART - интерфейс асинхронный, то при плавании длительностей битов, вероятность корректного приёма байта никак бы не зависела от количества байт в кадре.

Скорее всего - что-то с землями в шкафу или с питанием или с оптопарами (или их питанием) и т.п. Возможно проседает питание какой-то оптопры или ещё какого то посредника между UART-ами.

Я же говорю, подключаем Баян1, все ок, тут же ставим Баян2 - проблема.подкчение обоих Баянов одно и тоже.

[Arlleex 131]

Ну, глядя на диаграммы, выдаваемые Шкафом (знать бы еще, хотя бы в одном кадре, какие данные там ожидаются), собирать комиссию и писать гневную рекламацию руководству разработчиков Шкафа, что UART не соответствует требованиям по точности временных интервалов. То, что оно работает на STM32 сейчас, ровным счетом, чистое везение. Завтра оптроны на солнышке подогреются посильнее, и на STM32 прием обломается.

Но если задача "что-то с этим сделать", то только периодически (например, раз в 5 секунд) настраивать ножку RX на вход захвата таймера (а это, возможно, повлечет переразводку/сопляж-монтаж), оценивать реальную длительность нулевого и единичного битов, брать некую серидину, высчитывать актуальную скорость, и на следующем такте обмена после отправки но перед приемом быстро перенастроить предделители на уточненную скорость.

[x893 35]

Записываете сигнал, который приходит от ШКАФА к Баянам при длинном пакете.

Дома воспроизводите и смотрите чем отличаются сигналы на ноге RX процесора у Баянов. Делаете выводы.

Ответ подробнее не могу выложить, уж извините. Выпилил то, что не надо из него.

[DAndy_boy 0]

4 минуты назад, Arlleex сказал:

Ну, глядя на диаграммы, выдаваемые Шкафом (знать бы еще, хотя бы в одном кадре, какие данные там ожидаются), собирать комиссию и писать гневную рекламацию руководству разработчиков Шкафа, что UART не соответствует требованиям по точности временных интервалов. То, что оно работает на STM32 сейчас, ровным счетом, чистое везение. Завтра оптроны на солнышке подогреются посильнее, и на STM32 прием обломается.

Но если задача "что-то с этим сделать", то только периодически (например, раз в 5 секунд) настраивать ножку RX на вход захвата таймера (а это, возможно, повлечет переразводку/сопляж-монтаж), оценивать реальную длительность нулевого и единичного битов, брать некую серидину, высчитывать актуальную скорость, и на следующем такте обмена после отправки но перед приемом быстро перенастроить предделители на уточненную скорость.

Боюсь это не вариант. Проблема в том что один байт примерно нормальный. А вот длины бит в нутро него гуляют. Изменение все частоты на приёме не поможет.

[Arlleex 131]

Поставьте oversampling 16, как тут уже писали, попробуйте.

И вдобавок (не знаю, сделано ли такое в GD32), поставьте однобитный метод семплирования.

[Plain 168]

О чём здесь вообще говорят? На картинках частота абсолютно одинаковая, ответ от посылки отличается дополнительным стоп-битом.

[Arlleex 131]

3 минуты назад, Plain сказал:

О чём здесь вообще говорят? На картинках частота абсолютно одинаковая, ответ от посылки отличается дополнительным стоп-битом.

По диаграмме видно, что длительность старт-бита, отправляемого Баяном-2, ~ правильная (104 мкс, что примерно есть 9600 бод).

А вот Шкаф отвечает длительностью старт-бита 86 мкс, за ним 118 мкс передача единички, а дальше вообще расколбас.

Не зная эталонных данных весьма сложно сказать, что там должно было быть.

[Freibier 3]

47 минут назад, Arlleex сказал:

Шкаф отвечает длительностью старт-бита 86 мкс

т.е. длительность стартового бита меньше необходимого на ~ 17%

Стандарт RS232 как-то регламентирует допустимую девиацию длительности одиночного имупульса?

[DAndy_boy 0]

20 минут назад, Freibier сказал:

т.е. длительность стартового бита меньше необходимого на ~ 17%

Стандарт RS232 как-то регламентирует допустимую девиацию длительности одиночного имупульса?

Я вот конкретно стандарта где это указано не нашёл. И тем не менее проблему придётся решать со стороны Баяна. Все что можно было в настройках уарта в GD все попробовали.... не помогает.