-=Sergei=- 0 22 августа, 2006 Опубликовано 22 августа, 2006 · Жалоба Кто как посаветует в новом контроллере CAN интерфейса просто для справки глянуть на НЕК. Там есть 8-ми битники с CAN и LIN. http://www.ee.nec.de/applications/automotive/index.html Можно опробовать на стартовых наборах... Удачи! Спасибо, глянул. Но опять таки, если использовать какой либо системный таймер, то я смогу каждому пакету сопаставить время прихода, т.е. даже узнать временную задержку между пакетами. Можно просто сделать счетчик, 1.2.3.4.5 итп с зацикливанием, т.е. просто раставить пакеты в порядке прихода, насколько нужно точное время прихождения пакета ? или достаточно порядка прихождения ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AnyWay 0 22 августа, 2006 Опубликовано 22 августа, 2006 · Жалоба Можно просто сделать счетчик, 1.2.3.4.5 итп с зацикливанием, т.е. просто раставить пакеты в порядке прихода, насколько нужно точное время прихождения пакета ? или достаточно порядка прихождения ? Точное время прихождения пакета в большинстве случаев не нужно и обрабатывать пакеты в последовательности отличной от последовательности получения тоже. Поэтому лучше сделать счетчик с зацикливанием. Если вдруг понадобится точное время прихода сообщения, всегда можно воспользоваться прерыванием по получению, если оно конечно есть. Спрашиваю здесь, так интересует именно опыт применения этих интерфейсов. Например, так как мы интегрируем высоковольтные приемопередатчики, то может сделать сразу какое то число выводов высоковольтными (до 27-30 вольт) что бы прям ногами микроконтроллера например реле управлять или еще чем. Высовольтные выводы лучше не делать, кому надо поставят усилители. И взаимозаменяемость будет. Корпус лучше поменьше. 64 выводный это процентах в 90 куча неиспользованых выводов. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
spf 0 22 августа, 2006 Опубликовано 22 августа, 2006 · Жалоба насколько нужно точное время прихождения пакета ? или достаточно порядка прихождения ? ИМХО: Фиксация времени получения пакета бесполезная фишка, т.к. не несет в себе никакой информации. Стандарт не гарантирует время доставки сообщения. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AnyWay 0 22 августа, 2006 Опубликовано 22 августа, 2006 · Жалоба Интресует другое, например: по CAN Сколько буферов делать? Как эти буфера отображать ядру (отобразить все буфера в общую память или через порты (один регистр на один буфер) сделать доступ как к FIFO)? Что еще кроме CAN/LIN требуется в этих кристаллах АЦП разрядность/число каналов/скорость? ЦАП, какие? USART - сколько? С учетом того что один совмещен с LIN Таймеры? Сколько какие? Капчуре? Сколько? Память программ? Сколько ? ОЗУ сколько ? EEPROM данных ? Понятно, что все скажут все давай. Но ограничение по площади и по ногам? 64 ноги максимум!!!! В качестве аналогов как раз майкрочиповские блоки и рассматриваем. Фуджицу - слижком жирные контроллеры. Другая весовая категория. Заказчик клонит в проблемы своего девайса, нам же надо сделать универсальный контроллер. Спрашиваю здесь, так интересует именно опыт применения этих интерфейсов. Например, так как мы интегрируем высоковольтные приемопередатчики, то может сделать сразу какое то число выводов высоковольтными (до 27-30 вольт) что бы прям ногами микроконтроллера например реле управлять или еще чем. Еще например различные датчики поставляются сразу с предустановленной ПЗУшкой где поправочные коэфециенты прописаны, по каким интерфейсам с этими ПЗУ общаются, так как USART, SPI, I2C. По моему мнению если нужно сделать универсальный контроллер стоит делать его как можно проще, т.е. из всех наворотов выбирать только те, которые невозможно или тяжело организовать програмно, остальное делать по минимуму(в разумных пределах). Например: Корпус 48 АЦП - желательно не менее 5-8 разрядностью 8 ЦАП - ненужно, лучше сделать ШИМ Таймеры - 2 или 3. Если выйдет дешевле, то лучше 2. Лишний таймер можно и програмно сделать. Капчуре - если как в микрочиповских с ШИМ, то лучше сделать Память программ - 4К-8К ОЗУ - 128-256 EEPROM - 64-128 буферов для CAN - 2 - даже если в программе есть моменты с высокой степенью загрузки процессора, когда он не может выделить время на обработку сообщений, всегда можно найти несколько микросекунд, чтобы перегрузить буферы в ОЗУ по прерыванию. UART - 1-2 SPI/MI2C - 1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
spf 0 22 августа, 2006 Опубликовано 22 августа, 2006 · Жалоба Память программ - 4К-8К ОЗУ - 128-256 буферов для CAN - 2 - даже если в программе есть моменты с высокой степенью загрузки процессора, когда он не может выделить время на обработку сообщений, всегда можно найти несколько микросекунд, чтобы перегрузить буферы в ОЗУ по прерыванию. Это в какое ОЗУ? которое можно сказать отсутствует в Вашей конфигурации ;) RAM: от 1K Flash: от 16K Иначе ничего стоящего с CAN не сделать... только байты пересчитывать в ОЗУ и программе... Если камень все равно будет стоить гору денег, то в него надо набить всего и побольше... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AnyWay 0 23 августа, 2006 Опубликовано 23 августа, 2006 · Жалоба Иначе ничего стоящего с CAN не сделать... Почему не сделать? На один мощьный CAN узел приходится 3-4 которые просто информацию от датчиков из одной части машины в другую перегоняют, или управляют какими нибудь стеклоотчистителями. Поэтому для большинства задач моя конфигурация подходит. В остальных случаях можно поставить еще один процессор и перегонять на него информацию по SPI. Конечно чем больше вего, тем лучше, но до тех пор пока существенно не влияет на конечную цену. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
spf 0 23 августа, 2006 Опубликовано 23 августа, 2006 · Жалоба В остальных случаях можно поставить еще один процессор и перегонять на него информацию по SPI. Уж лучше такое не делать... Надежность всей системы будет определяться самым ненадежным элементом, которым является SPI интерфейс. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AnyWay 0 23 августа, 2006 Опубликовано 23 августа, 2006 (изменено) · Жалоба дабл пост Изменено 23 августа, 2006 пользователем AnyWay Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AnyWay 0 23 августа, 2006 Опубликовано 23 августа, 2006 · Жалоба Уж лучше такое не делать... Надежность всей системы будет определяться самым ненадежным элементом, которым является SPI интерфейс. из этой ситуации всегда можно выкрутится и надежность интерфейса повысить. А вот ставить дорогой 64 ногий процессор с ОЗУ -1К, ПЗУ-16 только для мониторинга 5-10 кнопок/регуляторов со вспомогательного ПДУ или управления зеркалом/стеклоподьемником/замком, как-то совсем не катит. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
-=Sergei=- 0 24 апреля, 2008 Опубликовано 24 апреля, 2008 · Жалоба Удачи! Докладываю. В результате работ был разработан 8-ми разрядный МК с интерфейсом CAN и LIN - 1886ВЕ5 Приемо-передатчик интерфейса CAN - 5559ИН14 Приемо-передатчик интерфейса LIN - 5559ИН15 Пока еще черновые спецификации в прикрепленных файлах. Все можно попробовать, есть демоплата, семплы посылаются заинтересованным предприятиям, есть среда разработки, отладка, С компилятор итп Приступаю к разработке 32-х разрядного МК на базе ядра ARM Cortex-M3 c 2 контроллерами CAN и многим другим. 1886__5________.pdf 5559__14.pdf 5559__15.pdf Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
spf 0 25 апреля, 2008 Опубликовано 25 апреля, 2008 · Жалоба Докладываю. В результате работ был разработан 8-ми разрядный МК с интерфейсом CAN и LIN - 1886ВЕ5 Приемо-передатчик интерфейса CAN - 5559ИН14 Приемо-передатчик интерфейса LIN - 5559ИН15 Все таки не стали встраивать в МК приемо-передатчики, хотя собирались. Почему отказались от своей идеи? ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
walsv 0 25 апреля, 2008 Опубликовано 25 апреля, 2008 · Жалоба Все таки не стали встраивать в МК приемо-передатчики, хотя собирались. Почему отказались от своей идеи? ;) Думаю для возможности гальвано изоляции Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
-=Sergei=- 0 25 апреля, 2008 Опубликовано 25 апреля, 2008 · Жалоба Думаю для возможности гальвано изоляции Много причин, гальваническая развязка, маркетинговые шаги, с приемопередатчиками, легче выйти на рынок, тупо упрошали проект, неуверенность, если что то не получиться - рухнет весь проект, сертификация в том виде как она сейчас существует - проверяет МК и приемопередатчики отдельно, нас бы просто не смогли сертифицировать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
