Постораюсь ясно изложить мысль:
МК (мега8) занимается управлением камерой по LANCпротоколу (тот же самый UART со стороны камеры, но с открытым коллектором ), со стороны МК отслеживаем старт-биты и подаем команды притягиванием линии к земле. Передается фреймами по 8 байт, во время передачи команды (одно и то же повторяем несколько фреймов - может затянутся на насколько секунд) нельзя пропускать фреймы.
То есть МК занят, на остальную работу остается порядка 9милисек (промежуток между фреймами)
Все бы ничего, но параллельно надо принимать другую команду, длительностью порядка 44 милис.
Есть идея по фронту внешней команды запускать capture timer на время 45 мс и после оценивать состояние регистра ICR.
Покритикуйте идею.

Непонятно ,а что мешает МК принимать данные по УСАРТ по прерыванию?

Прерывание УСАРТ возникает при окончании приема, а мне нужен старт-бит

Тогда старт бит ловим по INT и в обработчике прерывания делаем команды.
Можно также по INT запускать таймер для другой команды и по нему же останавливать если не требуется суперточности.

Это напоминает обычный программный УАРТ, и действительно, легко реализуется по прерыванию по стартовому биту. Далее запускается таймер на длительность бита с поправками на длительность прерывания и поехали. Вопрос в параметрах - какова длительность бита, и какой допустимый джиттер. Реализовать абсолютно фоновый УАРТ на двух прерываниях получается достаточно просто.

то есть вы предлагаете вплотную занятся приемом "длинной "команды как основной, а УАРТ обрабатывать в фоновом режиме по прерываниям?
Длительность длинная - 104мкс (9600).

Если добавить примерно 1$ можно мегу 8 заменить на мегу 162. Там 2 УАРТа. Можно без извращенных методов фсе реализовать и спать спокойно. Влдожения окупаются с лихвой на экономии времени. Если конечно не учитывать потерянного сонительного удовольствия от акта отладки левых алгоритмов...

а зачем мне вообще 2 нардварных УАРТА?

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

Я всего лишь утверждаю, что на микроконтроллере АВР вполне реализуем вариант двух программных УАРТов, работающих в фоновом режиме со скоростью 9600. Во всяком случае, один на 19200 получился просто, джиттер меньше 5 процентов, экстраполируя на два УАРТа 9600, я предполагаю вполне хорошие результаты.

Кстати, а что, только прием команд? Тогда задача еще проще - в прерываниях не нужно анализировать режим порта.
Да, еще по поводу использования логики захвата. Действительно, можно упростить фоновый алгоритм - писать в буфер содержимое таймера, когда входной сигнал поменял полярность, а потом анализировать. Я так делал для приема посылок по радио, очень прозрачно и удобно.

можно попробовать делать опрос что на линии по прераванию от таймера, а хардуарт использовать для "нормальной" команды.

В первом посте неправильно выразился, "другая команда" это не УАРТ, там свой протокол. Минимальная длительность импульса 1мс, максимальная - 6мс. Вот на 44мили и набегает.

Ну неважно, обработка вряд ли принципиально отличается от программного УАРТа - поймать первый фронт (по прерыванию от порта) а потом с привязкой по времени (прерывания от таймера) считывать состояние входа (или менять при передаче).
Я программными УАРТами измерял ресурсы. Как попугаями - удава

1ms - это вагон времени. У меня фоновое прерывание таймера, в котором клавиатура и прочие сервисы, работает с периодом 1 мс.

Интересно, чем это МК занят при передаче по уарту? Толкнул 1 байт на передачу и спи 1 мс, потом следующий байт. По-моему, МК у вас просто простаивает...

После посылки байта остается спать 250мкс (LANC такой).
Я боюсь, что в прерывании по обнаружению старт-бита с ЛАНКа, пропущу
внешнюю команду

Так говорилось же уже сварганить передачу LANC на двух прерываниях.
По спаду старт-бита - прерывание запуска процесса, лучше всего - ICP. В этом прерывании инициализируем передачу команды в камеру (счётчик бит, ...) и делаем
OCR1A = ICR1 + длина_полутора_бит; /* таймер 1 бежит свободно */
В прерывании по OCR1A выталкиваем бит и делаем для следующего прерывания
OCR1A += длина_бита;
Итого процессор будет свободен кучу времени, иногда (не чаще раза на бит) совсем ненадолго отвлекаясь на LANC. Период бита 104мкс @ 9600, при 8 мегагерцах такта это больше 800 тактов, прерывание OCR1A уложится в несколько десятков, более 90% времени процессор гуляет.