ATtiny441 и UART. Не могу разобраться

[akegor]

Deniska407, почему бы Вам было не указать в явном виде скорость обмена? Лениво мне, как-то, ковыряться в ДШ...
Откуда взяты 5мс задержки после загрузки байта в УДР ? Вообще-то, гораздо беспроигрышней отлавливать событие "передача байта окончена" по соответствующему флагу.
Вы дрыгаете ножкой направления для каждого байта. А почему бы не сделать прием-передачу через кольцевой буфер на прерываниях? В этом случае ставить на передачу можно один раз на все байты буфера, а переключать на чтение после передачи последнего байта.
У меня все работает именно так.

[tsb]

Deniska407, не забывайте, что интерфейс RS485 является полу-дуплексным, т.е. в каждый момент направление передачи данных может быть только одно: от "мастера" к "слейву" или наоборот. Это значит, что "мастер" и "слейв" должны передавать данные строго по очереди, но не одновременно. Этот принцип присутствует в протоколе Modbus RTU, но в Вашей программе он пока не соблюдается. Насколько я понял из приведенного текста программы, передача от устройства ("слейва") активируется в главном цикле через каждые 5 сек, при этом никак не отслеживая, окончился уже прием от "мастера" или нет. Возможно в этом причина описанной "нестабильности" приема...

[ForcePoint]

... не стабильная тактовая частота из-за отсутствия кварца.

Она достаточно стабильна, по крайней мере для "комнатных условий". На 38400 Бод работало устойчиво от внутреннего RC-генератора, откалиброванного по app. note Atmel.
А вот записан-ли байт калибровки генератора в OSCCAL - надо проверить.

[mike-y-k]

tsb, таки они и полнодуплексными бывают (с двумя парами линий).
Собственно правило слушать линию на предмет правильности переданного никто не отменял - так и ошибки, и коллизии отлично детектируются.

Deniska407, анализ происходящего на линии нужно выполнить в первую очередь.
При этом обеспечить нормальное терминирование RS485 (даже на 0.3м). Возьмите это за правило - потом будет меньше печалей.
Осциллограф заодно покажет шумовую картину на линии.
Проверьте осциллографом потенциалы при отсутствии земли между устройствами и при ее подключении.
Какие трансиверы RS485 использованы?
Линии с отдельным внутренним питанием и заземлением изолированных трансиверов показывают лучшие характеристики по помехоустойчивости. 12V/24V с понижением на каждой плате до 5V. Для дома это будет излишеством, но…

[tsb]

tsb, таки они и полнодуплексными бывают (с двумя парами линий).

Чего только, "в принципе", не бывает... Но мы же рассматриваем конкретный случай:

Для приема в терминал использую китайский переходник с UART на RS-485 и переходник - RS-485 - USB.

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

Как это "правило" можно реализовать в данном конкретном случае - не совсем понятно...

[usr10000]

Если есть у кого какие мысли

Есть мысль, что у Вас скорость выбрана с большой погрешностью. Получается около 8900. Если хотите 9600, то ставьте бит U2X, а делитель ставьте 12.

[mike-y-k]

tsb, полудуплексные обычно с раздельным управлением приём-передача (Rx_En, Tx_En). При передаче включаем приём и проверяем принятое после каждой передачи.
Аппаратное echo получается.
Из-за этого был вопрос по использованному чипу в конце цепочки USB-UART-RS485 и его подключению.
У ТС вполне может стоять и полнодуплексный чип. Была такая "неожиданность" пару раз при покупке плат и модулей трансиверов на aliexpress , правда у нескольких вторая пара отказалась жить

ТС для начала физический уровень привести в соответствие со стандартом стоит, а потом уже двигаться дальше. Метания в поиске причин между возможными вариантами обеспечивают слабую сходимость процесса к итогу. Тут только на повезёт можно расчитывать и только для однофакторной ошибки…

[parovoZZ]

Она достаточно стабильна,

Я даже на ЛА вижу джиттер от 441/841. Разумеется, на не калиброванном осцилляторе.

[tsb]

tsb, полудуплексные обычно с раздельным управлением приём-передача (Rx_En, Tx_En). При передаче включаем приём и проверяем принятое после каждой передачи.
Аппаратное echo получается.

Это Вы говорите о контроле передачи со стороны микроконтроллера ("слейва"). Но в приведенных примерах полученных посылок от "слейва" контрольные суммы (два последних байта) - везде правильные (с учетом значений первого "нестабильного" байта). Значит у ТС искажение данных происходит на участке передачи от ПК ("мастера") к "слейву".

[Deniska407]

Уважаемые Коллеги!

Я не ожидал что мой вопрос будет кому то интересен и кто то будет на него отвечать. Я увидел столько от ВАС ответов и советов и очень приятно удивлен! ОГРОМНОЕ ВАМ ВСЕМ СПАСИБО ЗА ПОДДЕРЖКУ!

Задачу я решил следующим образом - правильно инициализировал UART:

void USART_Init()
{
    UBRR0H = 0;
    UBRR0L = 12;                    // ‹----
    
    UCSR0A = (1 ‹‹ U2X0);     // ‹----
    
    UCSR0B = (1‹‹RXEN0)|(1‹‹TXEN0)|(1‹‹RXCIE0);
    UCSR0C = (1‹‹USBS0)|(3‹‹UCSZ00);
} 

Ошибок больше не ловил! Буду пилить программу дальше! Теперь, когда я начал принимать без ошибок, то столкнулся со следующей трудностью:
Телеграмма ModBUS RTU состоит из (например) из Адреса устройства (0х10), Номера ф-ции (0х03), Адреса (0х01 и 0х00) и Данных (0х00 и 0х01) и заканчивается все это CRC (0хХХ и 0хХХ). Всего телеграмма состоит из 8-ми байт. Моя же программа принимает только ОДИН ...

Вопрос: как из буфера UART по прерыванию наполнить массив frame[i] 8-ю байтами. Вот код, отвечающий за прием:

ISR (USART0_RX_vect)
{
    
        i=0;
                while ( !(UCSR0A & (1‹‹RXC0)) );
                do
                      {
              frame[i] = UDR0;   //  ‹--- 
                      i++;                      //  ‹--- 
                      }
        while( я не знаю что тут писать за условие);
} 

Видимо тут нужно организовать цикл и принимать в frame[i] до тех пор из буфера, пока а) что то еще принимается и б) i‹32, иначе переполнится буфер массива frame[i] ......

Вот во вложении что получилось в анализаторе ...