Спасибо, глянул. Но опять таки, если использовать какой либо системный таймер, то я смогу каждому пакету сопаставить время прихода, т.е. даже узнать временную задержку между пакетами. Можно просто сделать счетчик, 1.2.3.4.5 итп с зацикливанием, т.е. просто раставить пакеты в порядке прихода, насколько нужно точное время прихождения пакета ? или достаточно порядка прихождения ?

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

Высовольтные выводы лучше не делать, кому надо поставят усилители. И взаимозаменяемость будет.
Корпус лучше поменьше. 64 выводный это процентах в 90 куча неиспользованых выводов.

ИМХО: Фиксация времени получения пакета бесполезная фишка, т.к. не несет в себе никакой информации. Стандарт не гарантирует время доставки сообщения.

По моему мнению если нужно сделать универсальный контроллер стоит делать его как можно проще, т.е. из всех наворотов выбирать только те, которые невозможно или тяжело организовать програмно, остальное делать по минимуму(в разумных пределах). Например:
Корпус 48
АЦП - желательно не менее 5-8 разрядностью 8
ЦАП - ненужно, лучше сделать ШИМ
Таймеры - 2 или 3. Если выйдет дешевле, то лучше 2. Лишний таймер можно и програмно сделать.
Капчуре - если как в микрочиповских с ШИМ, то лучше сделать
Память программ - 4К-8К
ОЗУ - 128-256
EEPROM - 64-128

буферов для CAN - 2 - даже если в программе есть моменты с высокой степенью загрузки процессора, когда он не может выделить время на обработку сообщений, всегда можно найти несколько микросекунд, чтобы перегрузить буферы в ОЗУ по прерыванию.
UART - 1-2
SPI/MI2C - 1

Это в какое ОЗУ? которое можно сказать отсутствует в Вашей конфигурации

RAM: от 1K
Flash: от 16K

Иначе ничего стоящего с CAN не сделать... только байты пересчитывать в ОЗУ и программе...

Если камень все равно будет стоить гору денег, то в него надо набить всего и побольше...

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

Конечно чем больше вего, тем лучше, но до тех пор пока существенно не влияет на конечную цену.

Уж лучше такое не делать... Надежность всей системы будет определяться самым ненадежным элементом, которым является SPI интерфейс.

дабл пост

Сообщение отредактировал AnyWay - Aug 23 2006, 10:03

из этой ситуации всегда можно выкрутится и надежность интерфейса повысить. А вот ставить дорогой 64 ногий процессор с ОЗУ -1К, ПЗУ-16 только для мониторинга 5-10 кнопок/регуляторов со вспомогательного ПДУ или управления зеркалом/стеклоподьемником/замком, как-то совсем не катит.

Докладываю.

В результате работ был разработан 8-ми разрядный МК с интерфейсом CAN и LIN - 1886ВЕ5

Приемо-передатчик интерфейса CAN - 5559ИН14

Приемо-передатчик интерфейса LIN - 5559ИН15

Пока еще черновые спецификации в прикрепленных файлах.

Все можно попробовать, есть демоплата, семплы посылаются заинтересованным предприятиям, есть среда разработки, отладка, С компилятор итп

Приступаю к разработке 32-х разрядного МК на базе ядра ARM Cortex-M3 c 2 контроллерами CAN и многим другим.

Все таки не стали встраивать в МК приемо-передатчики, хотя собирались.
Почему отказались от своей идеи? ;)

Думаю для возможности гальвано изоляции

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