Уважаемые, кто работал с CAN или LIN микроконтроллерами.

Приступаем к разработке 8-ми разрядного микроконтроллера с EEPROM памятью программ и контроллерами CAN и LIN интерфейсов. Основная фича (и фича ли это???) это встроенные CAN и LIN аналоговые приемопередатчики. Тип корпуса 48 или 64 ноги. Производительность 8-10 MIPS.

Какие еще возможность, фича вы хотелибы видеть в новом микроконтроллере ?

Не вижу смысла встраивать унутрь аналоговую часть...
Сможите повторить все свойства TJA 1050 для CAN? в том числе и по помехам и защитам?

Какой размер (тип корпуса, расстояние между ногами)?
Какая цена?

Заказчик - военные. Цена соответсвенная.
Корпус металлкерамика H16.48 предварительно.
Быстро глянул на TJA, струтура примерно такая CAN трансивера и предполагается
Вообще изначально смотрели на ATA6660. Свойства будем повторять, как минимум, ESD по российским методикам будет 2К, как оно сооотносится с ихними body model 4К, чесно сказать не знаю.
Почему интегрированная аналоговая часть, ну начиная от один корпус или три и заканчивая, что опять таки так надо проводить испытания для 3 новых микросхем, а так для одной.

Сколько нулей хоть скажите ;-)
Какое ядро?
Планируется делать для "простых смертных"?


В металлкерамике не спец. 16.48 - размер квадрата?


Одним словом прихоти военных...

C примкой "5" стоимость будет думаю гдето около 80-100$,
для смертных запоковав в пластмасу и не проводя всякие дорогие испытания можно ужаться в 15-25, но не менее, опустится до 5-8 (стоимости аналогов) скорее всего не сможем. Но это уже после того как сделаем для военных, будем смотреть.
Ядро - функ аналог PIC17xxxxx от Microchip

Размер занимаемый корпусом примерно 2.2 мм на 2.2мм, это если 48 ног, если в пластмассе LQFP64 то примерно 1.2 на 1.2 мм, планары.

Ядро - функ аналог PIC17xxxxx от Microchip
Если не секрет, чем обусловлен выбор ядра ? Прихоти военных ?

Размер занимаемый корпусом примерно 2.2 мм на 2.2мм, это если 48 ног, если в пластмассе LQFP64 то примерно 1.2 на 1.2 мм, планары.
Наверное всё таки сантиметров ?
Каой предполагается тех.процесс ? Не предполагается ли спецстойкость ?
[/quote]

[quote name='grumbler' date='Aug 17 2006, 12:27' post='145330']
Ядро - функ аналог PIC17xxxxx от Microchip
Если не секрет, чем обусловлен выбор ядра ? Прихоти военных ?

Размер занимаемый корпусом примерно 2.2 мм на 2.2мм, это если 48 ног, если в пластмассе LQFP64 то примерно 1.2 на 1.2 мм, планары.
Наверное всё таки сантиметров ?
Каой предполагается тех.процесс ? Не предполагается ли спецстойкость ?
[/quote]
[/quote]

Ядро уже есть и отработано. Применено в 4 уже выпушенных кристаллах, новый кристалл продолжение линейки.
конечно же сантимаметры. Процесс 0.6 мкм.

По спец стойкости, какие уровни вам нужны?

По спец стойкости, какие уровни вам нужны?
[/quote]
Я бы не назвал себя покупателем, скорее интересуюсь,
вдруг где пригодится.
А если и интересует то не менее 50КРАД и устойчивость к одиночным событиям.

Пока вроде самый маленький МК c CAN - MB90F387: 7мм*7мм (по корпусу, 9*9 по ногам)
http://www.fme.gsdc.de/products/mb2.htm
У него есть фича - "wake-up" по входу CAN-RX.
Цена 7-8$.

[quote name='grumbler' date='Aug 17 2006, 13:42' post='145369']
По спец стойкости, какие уровни вам нужны?
[/quote]
Я бы не назвал себя покупателем, скорее интересуюсь,
вдруг где пригодится.
А если и интересует то не менее 50КРАД и устойчивость к одиночным событиям.
[/quote]

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

------------------------------------------------------------
В результате испытаний СБИС МК на стойкость к воздействию спецфакторов ГОСТ РВ 20.39.414.2 установлено (с учетом норм испытаний):
• уровень стойкости СБИС МК к воздействию спецфактора с характеристикой 7.И6 составляет от 0,5.1Ус до 2Ус для различных образцов и определяется тиристорным эффектом, катастрофических отказов не обнаружено вплоть до предельного уровня облучения 5Ус.
• УБР при воздействии спецфактора с характеристикой 7.И6 (характеристика 7.И8) составляет 0,05.1Ус.
• уровень стойкости СБИС МК к воздействию спецфактора с характеристикой 7.И7 составляет 0,5.2Ус.
• уровень стойкости СБИС МК к воздействию спецфактора с характеристикой 7.С4 составляет 0,1.1Ус.
------------------------------------------------------------

Что это означает, я не знаю, так как допуска не имею (и слава богу). Но насколько я понял, это не есть радиационно стойкая СБИС.


[quote name='spf' post='145555' date='Aug 17 2006, 21:17']
Пока вроде самый маленький МК c CAN - MB90F387: 7мм*7мм (по корпусу, 9*9 по ногам)
http://www.fme.gsdc.de/products/mb2.htm
У него есть фича - "wake-up" по входу CAN-RX.
Цена 7-8$.
[/quote]

Кристал то без приемопередатчиков. Ток что вот.
Сделать wake-up по RX проблем нет. Сделаем.

Интресует другое, например:
по CAN

Сколько буферов делать?
Как эти буфера отображать ядру (отобразить все буфера в общую память или через порты (один регистр на один буфер) сделать доступ как к FIFO)?
Что еще кроме CAN/LIN требуется в этих кристаллах АЦП разрядность/число каналов/скорость?
ЦАП, какие?
USART - сколько? С учетом того что один совмещен с LIN
Таймеры? Сколько какие?
Капчуре? Сколько?
Память программ? Сколько ?
ОЗУ сколько ?
EEPROM данных ?

Понятно, что все скажут все давай. Но ограничение по площади и по ногам? 64 ноги максимум!!!!

>> для смертных запоковав в пластмасу и не проводя всякие
>> дорогие испытания можно ужаться в 15-25, но не менее, опустится
>> до 5-8 (стоимости аналогов) скорее всего не сможем.
А смысл тогда тут спрашивать? Тем более по периферии? Я так думаю, что заказчика нужно по этому поводу терзать =)

LIN - работал только с Microchip, там лин реализуется в UART модуле - по большому счету это же только генерация synk break, просыпание по фронту и автоматическая подстройка для ведомого.

CAN - не работал, но слышал хорошие слова про ECAN модули в микрочиповских PIC18F. Сейчас микрочип выпустил dsPIC33 с CAN модулем у которого исправлены все недостатки и добавлены новые фичи, посмотрите, может поможет чем-нибудь.

• Implementation of the CAN protocol, CAN 1.2, CAN 2.0A and CAN 2.0B
• Standard and extended data frames
• 0-8 bytes data length
• Programmable bit rate up to 1 Mbit/sec
• Automatic response to remote transmission requests
• Up to 8 transmit buffers with application specified prioritization and abort capability (each buffer may contain up to 8 bytes of data)
• Up to 32 receive buffers (each buffer may contain up to 8 bytes of data)
• Up to 16 full (standard/extended identifier) acceptance filters
• 3 full acceptance filter masks
• DeviceNet™ addressing support
• Programmable wake-up functionality with integrated low-pass filter
• Programmable Loopback mode supports self-test operation
• Signaling via interrupt capabilities for all CAN receiver and transmitter error states
• Programmable clock source
• Programmable link to input capture module (IC2 for both CAN1 and CAN2) for time-stamping and network synchronization
• Low-power Sleep and Idle mode

http://ww1.microchip.com/downloads/en/DeviceDoc/70165d.pdf

Мне внешний более симпатичней.


Если хотите сделать хороший контроллер то стоит посмотреть на реализацию последнего варианта от Fujitsu, в двух словах не описать. Присутствуют с свежих камнях, например MB91F272 (в каких MB90-х не помню), если интересно то в понедельник посмотрю и ссылки укажу.

В качестве аналогов как раз майкрочиповские блоки и рассматриваем.
Фуджицу - слижком жирные контроллеры. Другая весовая категория.
Заказчик клонит в проблемы своего девайса, нам же надо сделать универсальный контроллер.

Спрашиваю здесь, так интересует именно опыт применения этих интерфейсов.
Например, так как мы интегрируем высоковольтные приемопередатчики, то может сделать сразу какое то число выводов высоковольтными (до 27-30 вольт) что бы прям ногами микроконтроллера например реле управлять или еще чем. Еще например различные датчики поставляются сразу с предустановленной ПЗУшкой где поправочные коэфециенты прописаны, по каким интерфейсам с этими ПЗУ общаются, так как USART, SPI, I2C.

Кто как посаветует в новом контроллере CAN интерфейса делать time-stamp. Т.е. для каждого буфера надо както сопаставить момент условного времени когда он был получен. Что бы программа могла раставить в порядке прихода пакетов буфера. Т.е. есть 4 входных буфера, отправитель шлет 3 пакета по 8 байт, 1 пакет попадает в буфер 3, второй в 4, в 1 попадает пакет от другого отправителя, затем в 2 попает 3 пакет. И обработать эти буфера надо например в порядке их прихода, т.е. из 3 буфера, из 4 и затем из 2. Как организоать механихзм определения времени прихода пакета. В пике строится на базе системного счетчика, т.е. программно и с задействованием дополнительных ресурсов. Хотелось бы сделать какой либо встроенный автоматический механизм.

просто для справки глянуть на НЕК. Там есть 8-ми битники с CAN и LIN.
http://www.ee.nec.de/applications/automotive/index.html
Можно опробовать на стартовых наборах...

Удачи!

Спасибо, глянул. Но опять таки, если использовать какой либо системный таймер, то я смогу каждому пакету сопаставить время прихода, т.е. даже узнать временную задержку между пакетами. Можно просто сделать счетчик, 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 интерфейс.

дабл пост

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

Докладываю.

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

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

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

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

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

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

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

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

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