Форум arduino.ua

Саме так. А при зсуві 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;

Дільник таймера завжди виставляйте однією операцією запису:

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

Або, якщо значення інших бітів невизначені:

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

Або, якщо за логікою заздалегідь відомо, що таймер зупинено (в CS1[2..0] нулі):

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

Та як і в багатьох бібліотеках, деякі параметри прибиті цвяхами - без модифікації коду самої бібліотеки їх не зміниш.
Там і так уже AVR-специфічний код, чому б не транслювати ардуінівські піни на регістри AVR при ініціалізації, а в обробнику лише писати в них.
При зміні значення одного каналу фаза наступних зміщується. Якщо сумарне значення тривалостей для всіх каналів перевищує 20 мс, період слідування імпульсів збільшується. Зрозуміло, що така специфіка імплементації, але її треба мати на увазі.
Дещо дивують конструкції типу

if(SERVO(timer,Channel[timer]).Pin.isActive == true)

Макроси, що посилаються на члени класу, і т.п.

Ну у вас декілька варіантів:

1. Розібратись, чому не працює зі "стандартною" Servo. Мені не вдалося відтворити ту поведінку, що ви описуєте: імпульси йдуть чітко з періодом 20 мс і очікуваною тривалістю. Значить, або ми запускаємо різний код (чи скомпільований з різними налаштуваннями), або не враховуєм якісь умови відтворення, або ви невірно описали поведінку.
Яка інформація потрібна для подальшого аналізу - вказано в попередніх повідомленнях.

2. Реалізовувати поетапно те ж саме, що робить Servo (апдейт OCR в обробнику переривання), і дивитись, на якому етапі перестає працювати. Тоді стане зрозуміло, і чому перестає, і чи можна це побороти.

3. Оптимізувати ваш варіант із відліком інтервалів по перериванню, а не по значенню TCNT. При грамотній реалізації обробник можна вмістити в декілька десятків тактів, на 8 мегагерцах де дасть роздільну здатність у порядка 200-300 кроків. Але у вас же там ще nRF24 планується, чи не так? Будуть ще переривання і затримки від SPI. Як воно із вашим кодом взаємно впливатиме - передбачити складно. Можливо, доведеться також оптимізувати і SPI.

4. Обрати іншу апаратну платформу, яка краще підходить для цієї задачі. Он пишуть, у ESP32 аж 16 апаратних jitter-free каналів PWM. Можливо, варто розглянути інший драйвер BLDC, який керується іншим способом. Якось не дуже раціонально перетворювати цифрове значення у сервоподібну PWM, яка потім драйвером перетворюється на іншу PWM вже для двигунів.
Зазвичай спочатку формулюється задача, аналізуються необхідні ресурси, вже потім обирається залізо для реалізації. А ви штучно створили собі обмеження і намагаєтесь їх героїчно подолати.

Там же Atmega328P в TQFP корпусі? Подивіться оцилом на XTAL2 (8-й пін).

При переносі скомпільованого коду чи при компіляції коду під 16 МГц плату?
Всі таймінги в одиницях часу (мілі- та мікросекунди) спираються на значення макроса F_CPU, що передається під час компіляції. Яке значення передається у вас?

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

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

Ну завантажте як файл і дайте посилання на нього.

8-МГц плат щось я у себе не знайшов, ось запустив на 8 мегагерцах наступний код на Nano з 16 МГц резонатором:

#include <Arduino.h>
#include <Servo.h>

Servo servo;

void setup()
{
    {
        uint8_t sreg = SREG;
        cli();
        CLKPR = _BV(CLKPCE);
        CLKPR = 0b0001;
        SREG = sreg;
    }

    pinMode(LED_BUILTIN, OUTPUT);

    servo.attach(6, 150, 2400);
    servo.write(0);
}

void loop()
{
    static bool state = false;

    digitalWrite(LED_BUILTIN, (state = !state));
    delay(500);
}

platformio.ini:

[env:pro8MHzatmega328]
platform = atmelavr
board = pro8MHzatmega328
framework = arduino

lib_deps =
    arduino-libraries/Servo@1.3.0

Блимання світлодіодом в loop() - це чисто щоб впевнитись, що працює на 8 МГц.

Нічого не смикається, чіткі імпульси кожні 20 мс тривалістю 150 мкс. Тривалість самих імпульсів коливається в межах декількох мікросекунд, що цілком очікувано.

Якщо підходити до задачі серйозно, то для початку потрібно визначитись із граничними параметрами: мінімальна тривалість імпульсів, максимальна тривалість, гранулярність (кількість кроків між мінімумом та максимумом, або ж тривалість одного крока), допустиме відхилення.
А також: чи допустимо генерувати імпульси послідовно, наприклад, при 4 каналах - з інтервалом по 5 мс між каналами, або ж передні фронти на всіх каналах мають бути синхронними. Скільки часу допустимо з точки зору інших компонентів ПЗ проводити в обробнику переривання (у вас же не лише PWM буде, а і якась комунікація з іншою периферією), і т.д.
При не дуже жорстких умовах напрошується очевидне просте рішення: в обробнику періодичного переривання по таймеру виставляти всі канали в одиниці, потім тупо крутити спінлок, скидаючи потрібний канал через заданий проміжок часу.