Да, кстати, если используется CAN2, то эти дефайны не правильные. Да и вообще похоже они вырваны с разных мест.
Цитата(Danis @ May 20 2012, 00:01)

[code]#define CAN_GPIO_PORT GPIOD
#define CAN_RX_SOURCE GPIO_PinSource0
#define CAN_TX_SOURCE GPIO_PinSource1
#define CAN_AF_PORT GPIO_AF_CAN1
#define CAN_RX_PIN GPIO_Pin_5
#define CAN_TX_PIN GPIO_Pin_13
Цифра в PinSource должна соответствовать, цифре GPIO_Pin. На порту GPIOD нет CAN'a. GPIO_AF_CAN1 заменить на GPIO_AF_CAN2
Цитата(Danis @ May 28 2012, 10:21)

т.е. Вы убеждены, что введение внешней Loop back не приемлемо? С внутренней Loop back все же работает….
Для этого и сделан режим Loop back, чтобы смотреть что отправляешь и по идее там не просто RX на TX закорочен, а еще изменяется алгоритм работы контроллера. Да я убежден, что внешняя Loop Back роли не играет. Например, если обратиться к википедии и почитать
описание CAN, в частности арбитраж и посмотреть на блок схему драйвера, то можно увидеть, что внутри RX и TX (грубо говоря) соединены. Значит, следуя Вашим рассуждениям в нормальном режиме мы должны получать, то что отослали на TX, но этого не происходит......почему???? Да потому что во время отправки происходит арбитраж, на TX пине бит выставляется, а RX пином контроллер следит какой уровень на линии получился, если отличный от TX, значит он проиграл арбитраж. Таким образом прием во время передачи не возможен!! А Loop Back режим вносит некоторые изменения в алгоритм работы контроллера, а не тупо закорачивает ножки.
Почитайте описание CAN.
Цитата(PoReX @ May 28 2012, 09:38)

У меня RX -> GPIO_Mode_IPU
Ошибочка, это для F103, а для F2 у RX и TX GPIO_Mode_AF.