CAN + CPU low cost Опции

[cebotor]

Ищу максимально дешевый вариант, для простейшего переферийного модуля CAN.
Задача - отправить статус входа в CAN и наоборот - выставить выход по команде.

Рассматривал несколько вариантов -


LPC2119 6.9 уе

SAM7 10 уе
(SAM7A3 - с ним уже
работал и CAN там
реализовывал,
проблем не знал)

AVR + MCP2515 3.5 уе

Думал также (не смейтесь) о софтварной реализации CAN,
на той же AVR-ке. на самом деле, как мне кажется ничего особо
сложного и глючного не должно получиться , тем более , что
планируется использовать устройство только на шине c
длиной бита около 10 МКС.
тогда цена снизиться до 1.5 долларов

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

Пока додумался до следующего -

SAM7 отпадает изза цены.

LPC2119 - уже значительно лучше , но все же дорого ,
а главное - в CAN контроллере этого чипа увесистая еррата , и
основной баг там - прощелкивание пакетов , при
arbitration lost - обходить которое очень гемморойно, как мне кажется.

Остаются варианты AVR + MCP и софтварный.
Может есть еще какие нибудь предложения ?
Если нет , то как считаете на чем остановиться ?

[spf]

AVR + MCP2515 3.5 уе

XC886C от Infenion будет стоить столько же.

Думал также (не смейтесь) о софтварной реализации CAN,
на той же AVR-ке. на самом деле, как мне кажется ничего особо
сложного и глючного не должно получиться , тем более , что
планируется использовать устройство только на шине c
длиной бита около 10 МКС.
тогда цена снизиться до 1.5 долларов

Если бы это было возможно, то давно бы было сделано до тебя,
Почитай внимательно спецификацию. Ни один МК за 1.5 бакса его не сможет реализовать на рабочем уровне, а очень медленный CAN смысла не имеет (ИМХО).
Если цена определяющая, то надо подумать о другой сети.

Остаются варианты AVR + MCP и софтварный.

О софтварным даже не и не думай. Уж лучше тогда подумать о LIN.

[cebotor]

XC886C от Infenion будет стоить столько же.


Если бы это было возможно, то давно бы было сделано до тебя,
Почитай внимательно спецификацию. Ни один МК за 1.5 бакса его не сможет реализовать на рабочем уровне, а очень медленный CAN смысла не имеет (ИМХО).
Если цена определяющая, то надо подумать о другой сети.


О софтварным даже не и не думай. Уж лучше тогда подумать о LIN.

насчет невозможности я не совсем согласен .
10 мкс на 20 мегагерцах это порядка 200 тактов на бит. Спецификацию я читал _очень_ внимательно,я не первый раз с CAN ом работаю. Даже учитывая то , что один бит в CANе делиться на несколько секций, при условии того , что устройство будет рассчитано только на одну частоту передачи - считаю что реализачия возможна.

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

За инфинион спасибо большое. я на него даже не смотрел.

[spf]

насчет невозможности я не совсем согласен .

"Овчинка выделки не стоит."
Какая партия устройств?
На написание и отладку уйдет пара месяцев (в лучшем случае), т.е. на ЗП будет истрачено не менее 2000$. Что не дает никакой экономии и гарантии работоспособности при партии в 1000шт.

PS: Не у всех производителей и аппаратная-то реализация работает без запинок, а тут программную в два счета замахнулись сделать
Если такое сделаете, то можно будет продавать по 1$ за установку на МК

[cebotor]

"Овчинка выделки не стоит."
Какая партия устройств?
На написание и отладку уйдет пара месяцев (в лучшем случае), т.е. на ЗП будет истрачено не менее 2000$. Что не дает никакой экономии и гарантии работоспособности при партии в 1000шт.

PS: Не у всех производителей и аппаратная-то реализация работает без запинок, а тут программную в два счета замахнулись сделать
Если такое сделаете, то можно будет продавать по 1$ за установку на МК

понятно - да наверное овчинка не стоит ... хотя и партия будет pyfxbntkmyj больше чем 1000 , да и зп тоже
насчет производителей и аппаратной реализации - это точно - с NXP наелся глюков.
а продавать не удастся в любом случае ибо это ж не полнофункциональная реализация получиться а сильно ограниченная по таймингам.
наверное все таки или инфинеон или авр плюс микрочип контроллер кана

[KRS]

А филипс собирается выпускать еще LPC2109
вариант LPC2129 только с 1 CAN и флеша и SRAM меньше.
он наверное самым дешевым и окажется

[cebotor]

А филипс собирается выпускать еще LPC2109
вариант LPC2129 только с 1 CAN и флеша и SRAM меньше.
он наверное самым дешевым и окажется

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

[KRS]

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

Честно говоря у меня эта ошибка ни разу не проявилась! Похоже у нее очень мала вероятность.
К тому же уже выходит LPC21x9 ревизия 1 там будет вроде FAST IO, ну и ошибки пофиксят

[Andy Mozzhevilov]

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

Да ничего там нет страшного. Просто принимать свои пакеты приходится и разгребать программно
(или можно аппаратный фильтр настроить на не прием переданных ID).

[spf]

Да ничего там нет страшного. Просто принимать свои пакеты приходится и разгребать программно
(или можно аппаратный фильтр настроить на не прием переданных ID).

Какие красивые кастыли

[Andy Mozzhevilov]

Какие красивые кастыли

Какие еще костыли?
Это хромированная инвалидная коляска

[cebotor]

Да ничего там нет страшного. Просто принимать свои пакеты приходится и разгребать программно
(или можно аппаратный фильтр настроить на не прием переданных ID).

у меня в предыдущем проэкте была ситуация когда передаваемые и принимаемые пакеты могли быть с одинаковым арбитражом как, впрочем , и с содержимым. что тут сделаешь ?

[Andy Mozzhevilov]

у меня в предыдущем проэкте была ситуация когда передаваемые и принимаемые пакеты могли быть с одинаковым арбитражом как, впрочем , и с содержимым. что тут сделаешь ?

Вообще, в CAN такого не должно быть, что-то с проектированием протокола тут неладно.

[spf]

Вообще, в CAN такого не должно быть, что-то с проектированием протокола тут неладно.

+1
При проектировании стоит посмотреть на готовые протоколы высокого уровня (CANopen и т.п.), в брошюрах к ним на картинках все разрисовано.

[cebotor]

+1
При проектировании стоит посмотреть на готовые протоколы высокого уровня (CANopen и т.п.), в брошюрах к ним на картинках все разрисовано.

извините , у каждого свои задачи ,я например не разрабатываю систему с нуля , а внедряюсь в уже работающую. И должен имитировать статусы реально функицонирующего агрегата , не отключая его. какие предложения ?