Форум arduino.ua

Так, щось типу такого:

    unsigned char pkt[] =
    //       0     1     2     3     4     5     6
        { 0xFF, 0xFF, 0x07, 0x00, 0x07, 0x00, 0x00 }; // cmd STAT, no data

    for (int id = 1; id <= 20; ++id) {
        pkt[3] = id;
        pkt[5] = 0;   // zero check_sum_1
        pkt[6] = 0;   // zero check_sum_2

        unsigned char checksum = 0;
        for (int i = 2; i < sizeof(pkt); ++i) {
            checksum ^= pkt[i];
        }

        pkt[5] = checksum & 0xFE;
        pkt[6] = ~pkt[5] & 0xFE;

        send_packet(pkt, sizeof(pkt));
        wait_response();
    }

Дивний і ненадійний алгоритм контрольної суми, але так написано 

Я би все-таки спробував той протокол, що для A1-16. Тільки не сторонньою програмою, а своєю, щоб гарантовано видавала правильно сформований пакет. Наприклад, STAT для ID 1: 0xFF 0xFF 0x07 0x01 0x07 0x01 0x00. З перебором ID від 1 до 20 і перерахуванням байтів контрольної суми. Також з перебором чотирьох бодрейтів. І дивитись, чи прийде відповідь хоч на один. Всього-то 80 варіантів Ну або впевнетись, що альтернативні програми генерують пакет, відповідний протоколу.

А видно маркування мікросхеми? Чи можна змалювати схему, хоча б частково, куди подається вхід, земля і живлення? Або фото плати?

А він точно з керуванням по послідовному протоколу?
На сайті виробника по назві DM0900 знаходиться два серво:
DM0900 10.5KG Digital Metal Gear Servo
Digital Metal Gear Servo DM0900
Обидва з PWM-керуванням. У маркетологів PWM також вважається "digital"

Може в описі товару тупо переплутали, написавши про послідовну шину. Таке буває.

Так, програма у вас видає Dynamixel Protocol 1.0.
Ще є Protocol 2.0. А на сторінці товару посилання на даташит для A1-16, де протокол схожий, але несумісний ні з Dynamixel 1.0, ні з 2.0. Кожен виробник модифікує протокол як хоче, аби було несумісно з продукцією конкурентів.

Теоретично, якщо зі сторони серво відкритий колектор з підтяжкою, то одного діода Шотткі з серво на TX має бути достатньо. Принаймні debugWIRE для AVRок у мене так працює без проблем.

Але мені все ж здається, що там не послідовний протокол, а звичайний PWM.

Доречі, в прошивці для Attiny не бачу конфігурування CLKPR. Якщо Attiny працює від внутрішнього осциллятора на 9.6 МГц і фʼюз CKDIV8 не скинуто, то його тактова частота - 1.2 МГц. Один такт - це біля 10% від такту для 115200 бод. Далеко не всякий UART буде нормально працювати при такій похибці.

Якщо вірити даташиту зі сторінки цього серво, пакет має бути в форматі:

У вас після хідера 0xFFFF іде 0x01, що не схоже на коректне значення поля size. І двох байтів контрольної суми теж немає.
Не та версія протокола?

// Attiny в ролі буфера з відкритим колектором - це сильно 

Покажіть cхему підключення і код керування. Чи відповідає servo ID в коді дійсному ідентифікатору серво? Покажіть дамп трафіку пакетів. Чи видає серво підтвердження прийому пакетів? Чи пробували різні бодрейти UART: 9600, 19200, 57600, 115200?

https://www.youtube.com/watch?v=S0tb3jnfdw4&t=1s тут прекрасно все описано если непонятно и не заработает отпешитесь