Форум arduino.ua

Ну gdb-multiarch має ж якось взнати, що є ttyACM0, на якому його будуть слухати.

Магічний пристрій і є монітор, який реалізує протокол gdb-сервера. В "класичній" конфігурації цю роль виконує openocd, який в свою чергу вже спілкується з залізом по іншом протоколу, наприклад, по JTAG.

Gdb бере elf на вхід. З нього ж таблицю символів читає для дебага, і дебажні символи, якщо є, і цільову архітектуру для multiarch.
Сирий бінарик прошити можна командою restore.

Та яка там магія. Заголовок, секції з атрибутами, таблиця символів. Avrdude ж теж elf шʼє.

А "monitor reset" працює?

WCH-LinkE теж вміє живленням смикати. Корисно коли нема NRST.

Дивно, в README picorvd пишуть же:

Скоріш за все той аргумент x зник ще на етапі компіляції. Але чому gdb в неіснуючу памʼять лізе, замість того щоб сказати value optimized out - то вже х.з. 
Взагалі, щоб більш-менш адекватний рантайм дебаг отримати, потрібно збирати з -Og, або хоча б -fno-omit-frame-pointer.
UPD: А, бачу, воно вже з -O0 компілиться. Але ж агрумент все одно через регістр передається: https://godbolt.org/z/o5YYEjYEK

Ну 2 з них - UART, як і в ардуіні. Атмегу ж теж можна хоч по ISP, хоч одним проводом по debugWIRE прошивати, але не всі хотять додаткові провода, хотять бутлоадер і аплоад з IDE. В деяких випадках так зручніше.
Колись хотів детально розібратись, які там є доступні варіанти прошивки окрім SWIO, але руки не дійшли. З WCH-LinkE запрацювало, цього було достатньо. Але надибав такий опис: WCH CH32V003 Factory Bootloader - The Missing Manual.

Ну як мінімум як USB-UART адаптер має працювати А можна заморочитись і спробувати перешити його додатково під інший протокол, зробити 1-Wire / debugWIRE адаптер, чи I²C, чи повільний напівдуплексний SPI. Дивлячить на якому МК і як він там зроблений. А AVR ISP, мабуть, без хірургічного втручання не вийде, бо 4 лінії потрібно.

А, просто else забули.
Ну якщо Shag приймає тільки два значення, 1 і 2, то можна без другого if:

if (Shag == 1) {
    ...
} else {
} ...

Або просто в кінці гілки робити return;

Ні, там ніякого асемблера нема, тільки C++. Навіть ніяких особливостей від ++ не використовується, як C код він теж валідний.

А де ви обчислюєте значення для OCR після скидання піна, щоб наступне переривання виникало через потрібний проміжок часу?

Це якщо з одним перериванням, як в Servo, і як ви зараз робите. А можна з двома.
Щоб фаза для кожного канала була постійна, зробіть тайм-слот для кожного канала. Для 4 каналів рівномірно - по 5 мс виходить. На початку тайм-слота виставляєте пін у високий рівень та програмуйте OCR, в кінці тайм-слота скидайте пін у низький рівень.
Початок тайм слота - по перериванню COMPA, значення OCR1A визначає тривалість всього тайм-слота - 5 мс.  Кінець - по COMPB. Значення OCR1B визначає тривалість високого рівня.
Там іще є варіанти, але поки не буду ускладнювати.

Зовсім не зрозуміло, як це логіка роботи залежить від виду конструкції розгалуження. Щось там не так.

4 канала, для кожного канала пін потрібно змінювати 2 раза. Виходить 4*2 = 8 станів.

Serv на кожному виклику циклічно приймає значення від 0 до 7: 0, 1, 2, 3, 4, 5, 6, 7, 0, 1, 2, 3, 4, 5, 6, 7, 0, ...

Із цього значення обчислюєм номер канала, від 0 до 3:

    uint8_t channel = idx / 2;

І номер крока, від 0 до 1 (по факту - інвертований стан піна).

    uint8_t state = idx % 2;

Їхні значення виходять такі

Serv   channel   state

 0        0        0
 1        0        1
 2        1        0
 3        1        1
 4        2        0
 5        2        1
 6        3        0
 7        3        1
 0        0        0
 1        0        1
 2        1        0
...

Виставляєм пін, що відповідає поточному каналу, у відповідний стан:

digitalWrite(pins[channel], !state);

Програмуєм OCR на наступну ітерацію:

OCR1A = ocr[channel][state];

Тривалість високого рівня на каналі k визначається значенням ocr[k][0] (аналогічно як у вашому коді Serv_1_1, Serv_2_1 і т.д.), тривалість низького рівня - ocr[k][1] (у вашому коді Serv_1_2, Serv_2_2 і т.д.).

Та з макросами теж можна намудрити, якщо зловживати. Хіба так багато місць у програмі де конфігурується таймер, чи потрібно перемикатись між декількома конфігураціями в рантаймі?
Якщо хочеться високорівневих абстракцій, то краще вже робити засобами C++. Ну то таке, якщо нема вимог до стилистики коду, то справа особистих вподобань.

Саме так. А при зсуві signed:

6.5.7 Bitwise shift operators

Суть не в long, а в unsigned. Поведінка (1 << 15) при 16-бітному int не визначена стандартом. Те ж саме з (1 << 31) на платформах з 32-бітним int.

1UL. В avr-libc просто 1.

Одне іншому не заважає, а навіть допомагає. "Красиво" - це не мета, а наслідок коректності, зрозумілості та ефективності коду.

Так в чому проблема залишити все там само і так само, тільки записувати значення в регістр один раз замість чотирьох? 

Вище наведено приклади, як можна написати щоб було і зручно, і правильно.

Так всі гілки однакові, відрізняються лише значення змінних. Навіщо їх дублювати?
Нумеруйте все з нуля, окрема змінна Shag стає непотрібною. Всі ваші if та case перетворюються на:

static const uint8_t pins[4] = { 2, 4, 7, 8 };
static volatile uint16_t ocr[4][2];

ISR ...
{
    uint8_t idx = Serv;
    Serv = (idx + 1) % 8;

    uint8_t channel = idx / 2;
    uint8_t state = idx % 2;

    digitalWrite(pins[channel], !state);
    OCR1A = ocr[channel][state];
}

Тільки не забувайте, що змінні, які читаються в обробнику переривань та більші за 8 біт, з основної програми потрібно оновлювати з вимкеними перериваннями. Ви ж тільки шматок коду показали, тому я не знаю, який там у вас тип у Serv_1_1 та інших.

Справа не в беззмістовній операції, а в тому, що якби було би, наприклад,

    TCCR1B |= (1 << CS10); 
    TCCR1B |= (0 << CS11);
    TCCR1B |= (1 << CS12);

то по закінчені цього коду таймер би уже натікав більше ніж треба.
Для покращення читабельності можна ще, наприклад, так:

    uint8_t tmp = (1 << WGM12);
    tmp |= (1 << CS10); 
    tmp |= (0 << CS11);
    tmp |= (1 << CS12);
    TCCR1B |= tmp;