Прием CAN2.0B на скоростях 250 и 500kbit/s, Подскажите если кто сталкивался Опции

[idle1]

Вот, возникла задача написать прием и передачу в CAN шину на контроллере тини2313. На первый взгляд ничего сложного, протокол документирован и понятен, НО есть но! Это времена, к примеру на 500кбит/с один бит передается за 2мкс, а на 250 за 4мкс, т.е имеем максимум 40 циклов на обработку одного бита, при этом еще нужно выкинуть мусор из сигнала. Я использовал контроллер на частоте 20Мгц.
Я пробывал уже следующие варианты: И чтение с задержкой в 2 и 4мкс соответственно -> вывод из-за длительности посылки, примерно в 100-150 бит, время уплывает, а так же ещё из-за ветвлений (1-2 цикла в один бит -> ~0.10мкс), провал!
Второй вариант со счетчиком при изменении с 1 на 0 и с 0 на 1 с последующей записью времени для анализа и расчета кол-ва бит, провал по непонятной мне причине, это загадочное отставание счетчика и непредсказуемость его показаний, при расчетной погрешности в 1.1мкс (цикл ожидания), наблюдаются отставания в две и даже 3мкс! Для связи с CAN шиной использую MCP2551 микрочипа.
Может кто писал что подобное? Если не трудно отзовитесь! Контроллер сменить немогу *TAUP*. Может у кого есть алгоритм?

[SasaVitebsk]

Я выравнивал ветвления. Прерывание само сожрёт 10-11 тактов, что из 40 - уже очень прилично. При такой задаче я бы прерывания не делал. Подстройку сделать можно, правда, конечно всё это будет несопоставимо с аппаратной реализацией.

Короче в общем мысль такая, что реализовать то можно, вот только контроллер при этом будет задействован донемогу. то есть он сможет обслуживать при этом ну очень простые задачи и очень медленные процессы. Обычно в CAN системе бродит туча сообщений, а ваших там очень мало, но обработать то требуется всё (при таком подходе).

Конечно CAN128 - дорогая микруха, но сейчас альтернатив уже полно. Это и LPC и ST32 и AT91SAM7. Да, совсем забыл. Есть PICи очень недорогие с CAN. В том числе малоногие. Правда там с CAN не удобно работать, но всё равно.