[idle1 0]

Вот, возникла задача написать прием и передачу в 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*. Может у кого есть алгоритм?

[Aner 4]

... сочувствую, мы сменили контроллер, нормально не получилось.

[idle1 0]

... сочувствую, мы сменили контроллер, нормально не получилось.

А на что сменили? Если формфактор такой же (питание(10-20), кварц(4-5), UART(2-3)), может и мне подойдет..

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

[Aner 4]

... на AT90CAN128-16AU, плату тоже пришлсь переразводить. Все же не зря внутренняя CAN инжина там реализована.

Сейчас и этот чип не очень, обработку данных требуется делать, большую.

Смотрю на ST32F102...7, цены привлекательные, да и нормальный ARM там уже.

[=GM= 0]

Вот, возникла задача написать прием и передачу в CAN шину на контроллере тини2313. Может кто писал что подобное? Если не трудно отзовитесь! Может у кого есть алгоритм?

Расхождение может проявляться как за счёт ветвлений в программе (или ошибок), так и за счёт разбега частот передатчика и приёмника. В кане аппаратно осуществляется постоянная подстройка частоты путём выкусывания и вставки 1..4 квантов времени (кратных 1/25..1/8 длительности бита) в среднем на каждом втором бите, сомневаюсь, что вы сможете это сделать программно за 40МЦ.

 

Я бы вам посоветовал поставить отдельный САН контроллер, например МСР2510, и не мучаться, поскольку задача совершенно неблагодарная в смысле затрат времени и отдачи.

 

С другой стороны, технически - интересная задача для проверки своего потенциала и знания протокола кана. Так что давайте ваш код, будем посмотреть (:-). Кстати, есть ещё один вариант решения задачи - с помощью последовательного интерфейса, если интересуетесь, расскажу подробнее.

[SapegoAL 0]

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

 

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

 

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

[idle1 0]

Если бы была возможность, то я бы не задумываясь перешел на специализированный контроллер. Но задача заключается именно под 2313 :( . Сейчас иду по методу накопления данных и последующей небольшой обработки. Коррекцию времени делаю (пытаюсь делать :) ) через прерывание по нисходящему фронту (Вход CAN с MCP2551 подключил к PD3(INT1)). Большой обработки в МК не будет, нужно только передать данные и получить, обработкой занимается другое ус-во. Ветвления я так же выравнивал, но там есть засада, переход по TRUE или по ELSE отличается на 1 цикл (0,05мкс)

[idle1 0]

Может кто знает какой МК с CAN где 2-3 - UART; 4-5 - Кварц; 10-20 - Питание; ???

[kool 0]

Может покажусь старомодным, но..

У вас идет счет на такты и Вы пытаетесь все это сделать на С?? Не проще ли на ассемблере? там такты легко выравнвать.

[idle1 0]

Может покажусь старомодным, но..

У вас идет счет на такты и Вы пытаетесь все это сделать на С?? Не проще ли на ассемблере? там такты легко выравнвать.

Да на С, через AVR Studio в качестве отладчика не сложней! И CAN я уже под 2313 дописал :)

Изменено 12 октября, 2009 пользователем idle1

[SapegoAL 0]

Какой компилятор?

[DogPawlowa 0]

Кстати, есть ещё один вариант решения задачи - с помощью последовательного интерфейса, если интересуетесь, расскажу подробнее.

Рааскажите, плз. Меня очень интересует дешевый CAN-bus из-за бюджетности проекта. Совместимость собственно с CAN не требуется, требуется неразрушающая коллизия.

[idle1 0]

Какой компилятор?

В качестве компилятора использовал IAR 5.20. Отладку передавал в AVR Studio.

 

Рааскажите, плз. Меня очень интересует дешевый CAN-bus из-за бюджетности проекта. Совместимость собственно с CAN не требуется, требуется неразрушающая коллизия.

Коллизии у меня к сожалению не отслеживаются, мне требовался всего лишь проходной интерфейс. Всей обработкой занимается стороннее ус-во.

[=GM= 0]

Меня очень интересует дешевый CAN-bus из-за бюджетности проекта. Совместимость собственно с CAN не требуется, требуется неразрушающая коллизия

Ну если вгрубе, то просто подаёте данные с кана в сдвиговый регистр ведомого спи. Синхронизацию формируете сами таймером с стс модой или с помощью чм-фм шима и проводом подаёте на склк. Ну и время от времени корректируете период синхро. Для приёма байта на обозначенных скоростях требуется порядка 320-640 тактов, всё это время - ваше, успеете и битстаффинг выкусить, и цкс посчитать, и адресата проверить, и даже на си.