На обоих контроллерах стоят одинаковые приложения.Оба контроллера
программируются.Скорость передачи одинаковая.При начале передачи
одного на входе другого появляются импульсы.Приема данных не вижу.
Даже в режиме "только чтение" на втором не получаю данных.
Проверить осциллографом ack на втором Tx не догадался .Спасибо
Сейчас проверю.CANINTF сигнализирует две ошибки.Посылка с ошибкой.
Это связано с подтверждением ack.И ошибка линии.Как он выявляет эту
ошибку?

Я не знаю, что означает этот режим для CAN.


Я об этом выше писал.


Так это надо документацию на MCP смотреть, в каких случаях контроллер эту ошибку выставляет.

Еще совет, посмотрите 2 лучевым скопом сразу сигналы на Tx одного и Rx другого на предмет временнЫх задержек, завалов фронтов и т.п.. Что-там видно?

Какая эта скорость? если не секрет...



Чем это пытаетесь определять?
Считыванием регистров или по сигналу прерывания?
Формирование сигнала прерывания разрешено?

Разобрался с ошибками.Регистр CANINTF указывал на регистр EFLG.
Тот указывал на ошибку "Передатчик в пассивном состоянии сч.ошибок >127"
Ошибка "Посылка с ошибками" указывала , что приемный буфер переполнен.
Что-то я запутался.Счетчик ошибок отключает передатчик.При передаче одной
посылки набегает столько ошибок?Наверно помехи.Сейчас буду разбираться.
Надо немного перепаять схемы.Это я смотрел на закоротку предложенную sfj.

Посылка передается до тех пор паке не будет передана без ошибок или не переполнится счетчик ошибок. Это по спецификации, да и в доке на контроллер должно быть описано.

Такая ситуация возникает когда на шине только один контроллер, остальные

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

Передатчик переходит в пассивное состояние, если при передаче зафиксировано больше 127 ошибок. Также передатчик будет переходить в пассивное состояние и там оставаться, если он не получил 127 подтверждений ACK от других CAN контроллеров на шине.
То есть однозначно у вас передатчик не слышит приемника, либо приемник вообще не принимает.


Это в каком контроллере, том же который передает?


Нет, в CAN же аппаратное подтверждение приема пакетов. Поэтому единожды начав передавать сообщение CAN контроллер будет его пытаться передать, пока оно не будет подтверждено другими CAN контроллерами в сети.
Если других CAN контроллеров в сети нет, или они не работают, то передатчик попытается передать сообщение 128 раз, каждый раз добавляя ошибку передачи, и потом перейдет в пассивный режим. Как он будет в пассивном режиме работать, не помню, нужно спецификацию CAN смотреть, там эта ситуация описана.


Вы сначала убедитесь, что второй CAN контроллер у вас принимает пакеты и подтверждает их ACK. Третий раз уже советую это сделать.

Скорость 50 бит/с. Я в программе вижу состояние всех регистров MCP2510.
Если я разрешил прием всех посылок, то хочу увидеть появление данных
в буфере 0 приемного регистра.Или это не так?Это мой первый пуск CANа.

<<Это в каком контроллере, том же который передает? >>
Да это выдает каждое приложение.Кажется до меня начинает доходить.
Вы правы со счетчиком. Второй контроллер должен ответить.Значит
сообщение должно быть для него.Все дело в фильтрах и масках.

<<Вы сначала убедитесь, что второй CAN контроллер у вас принимает пакеты и подтверждает их ACK. Третий раз уже советую это сделать. >>
Сейчас этим занимаюсь.Перепаиваю схемы.

CAN контроллер должен подтверждать все сообщения. Маски здесь не при чем. Фильтры и маски - они только для того, чтобы приложения не загружать прерыванием на каждое сообщение из CAN. то есть можно настроить так, чтобы аппаратно прерывания генерились только на нужные сообщения, не более того.
У вас проблема явно ниже, сам CAN контроллер не принимает сообщения.
Ответьте на вопрос, у вас ACK на Tx есть на принимающем контроллере или нет?

Зачем там перепаивать, нужно скопом посмотреть на ноге Tx принимающего контроллера. Как только там увидите ack - значит CAN контроллер слышит шину. Пока там подтверждения не добьетесь, работать ничего не будет.

Andy Mozzhevilov

На 2 дня выпал из обсуждения.Спасибо за вашу настойчивость.
Посмотрел осциллографом и не увидел посылок.По сигналу
WriteCAN вижу появление одного импусьса.Вероятно ack, но
не вижу всей посылки.Раньше все это видел.Что-то намудрил
с программой.Сейчас разберусь.

Все заработало.
Моя схема схема драйвера шины имеет много недостатков.
1.На приемный транзистор наводятся большие шумы.
Поборол блокировочным конденсатором 0.33 мкФ включенным в базу.
2.У импульсов сильно завалены фронты.Можно было поработать с
транзисторами, но не стал.Купил на радиорынке 82С250.
Простая схема соединения предложенная spf не работает с MCP2510.
При начале передачи вывод Tx генерит непрерывную последовательность
импульсов.Без всякого протокола.Вероятно происходит завязка с Rx
входом.
С сигналом ack тоже проблематично.Если все нормально , то посылка так
быстро проскакивает ( хотя я снизил скорость до 10 Кбит/с) , что ничего не
разберешь.Если отключаешь второе устройство , то сигнала подтверждения
просто нет.
Тему можно закрыть.

Ну и славно...

И все же, рекомендую сделать гальваническую развязку.
Для надежности. Не рекомендую кузова(общий провод) двух PC соединять через свое устройство.

Спасибо за рекомендации и ссылки.Все полезно.У нас сейчас идет "атака " на CAN.Переориентировал заявку в коммерческом отделе на TJA1050.