Стоит следующая задача на LPC2366 попытаться ограничить количество попыток отправить пакет одному из устройств.

По умолчанию сообщение будет отсылаться отправлять до 255 раз пока CAN не перейдет в режим "Bus OFF". Можно конечно настроить регистр CANEWL чтобы получить прерывание при достижении определенного количества ошибок, но насколько я понял, этот счетчик ошибок инкрементируется при возникновении любой ошибки, связанной с работой CAN, включая борьбу за шину между несколькими устройствами. Поэтому если я установлю маленькое значение, а наступит момент когда несколько устройств будут пытаться захватить шину, то моему устройству может не хватить попыток передать сообщение, а если я настрою большое значение, то при свободной шине и недоступности устройства, которому предназначен пакет, он все равно будет пытаться отправляться большое число раз.

Как резюме, может кто подскажет как научить CAN считать только отстуствие ACK от устройства назначения!!!?

Я просто сбрасываю контроллер как когда ES в CANGSR устанавливается в "1" по заданному количеству ошибок.
Тем не менее, любую ошибку можно посмотреть в CANICR биты 16:20 , в том числе и ACK...
Можно сделать так -- включить прерывание по шинной ошибке в CANIER (бит 7) и определять в прерывании тип ошибки и код ошибки по CANICR.
Пить пиво...

Но в этом случае процессору придется отвлекаться на обработку прерываний при каждой возникшей ошибке и вести собственный счетчик ошибок. Хотя возможно другого пути и нет

Поразмыслив, я пришел к следующему алгоритму работы с устройствами:
1) Разрешаю прерывания по:
- приему
- передаче
- ошибке на шине
- пассивной ошибке
2) При возникновении ошибки на шине, проверяю ERRBIT регистра CANICR и если ошибка соответствует ошибке слота ACK, то считаю, что этого устройтсва нет. В этом случае, возможно, надо несколько раз попробовать передать сообщение, если устройство все же не отвечает, то отбрасываю посылку и выставляю флаг того, что устройтсво недоступно. Во всех остальных ошибках шины ничего не делаю.
3) При возникновении пассивной ошибки, останавливаю отправку сообщения и выставляю флаг - ошибка шины и сбрасываю TXERR, готовясь к следующей посылке.

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

Вроде все так, но есть одно "НО". После перехода в режим "Error Passive" необходимо сбрасывать счетчик TXERR, чтобы ошибки по доставке сообщения конкретному устройтсву не влияли на обмен с другими устройствами. Для этого необходимо перевести CAN контроллер в Reset Mode. Но это ведь может нарушить прием сообщений, который в данный момент ведется. На что лучше ориентироваться, чтобы безболезненно сбрасывать счетчики ошибок не нарушая работу CAN!?

На регистр состояния CAN:-)

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

Это не так! Только отсутсвие ACK - превдет к ERROR PASSIVE, а в этом режиме счетчики ошибок на отсутствие ACK не увеличиваются и пакет будет передаваться бесконечно к BUS OFF это не приведет, если нет других ошибок! К тому же, насколько я помню в активном режиме, отсутсвие АСК увеличивает tx error сразу на 8!




НИКАК!!!
если вы получили АСК - это значит что все устройства на CAN шине, независимо от фильтров, получили ваш пакет правильно, было ли в данный момент нужное устройство на шине или нет неизвестно. В дальнейшем все контроллеры могли выкинуть этот пакет по фильтрам и он не дошел до приложения, по ACK об этом вы не узнаете.

Да, действительно Вы правы, пришлось поднять вчера спефикацию на CAN2.0 и там вычитал, что практически все ошибки увеличивают счетчик на 8, а не на 1, а вот декрементируются они на 1. И что после перехода в Error Passive режим, ACK перестает учитываться как ошибка, поэтому если на шине нет не одного устройства, то до Bus OFF действительно не добраться и сообщение будет отсылаться вечно, что я на этапе отладки программы и видел осцилографом.


А вот это для меня НОВОСТЬ!!!!! Я считал, что ACK генерит только то устройство у которого совпал ID по фильтрам. По Вашим словам, достаточно быть на шине одному устройству и кому бы я не отсылал сообщение ошибок не будет вовсе. Можете подкрепить свое высказывание ссылкой на документ где это написано!? По даташиту на LPC я такого не обнаружил!!!!

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

bookevg, KRS, Step_ARM,

Спасибо всем отклинувшимся, на этом наверное тему можно закрывать. К сожалению, подход, который я планировал применить, оказался неприменим . Получается что удостовериться в наличии устройства с конкретным ID можно только обеспечив с ним полноценный ЗАПРОС-ОТВЕТный механизм, т.е. я ему что-то посылаю, он мне должен ответить в течении заданного таймаута, но это уже задача Прикладного Уровня, написанием которого я сейчас и займусь!!!