Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: LIN интерфейс - что за зверь?
Форум разработчиков электроники ELECTRONIX.ru > Сайт и форум > В помощь начинающему
ALARM
Поискал информацию на форуме по этому интерфейсу и нашел только одну тему.
По описанию понял, что CAN и LIN - "родственники", хотя бы по признаку применения в автомобильных делах. Понял, что он однопроводный, высоковольтный (12В) и реализуется на дешевых процах.
Вопросы у меня такие:
1.Какова максимальная длина линии/кол. девайсов на линии.
2.Каково минимальное потребление в режиме ожидания запроса (наверное это зависит от драйвера?).
Мне приходилось иметь дело с 1-WIRE. Может кто скажет, в чем у них основные отличия. И есть ли преимущества у LIN?
iosifk
Цитата(ALARM @ Sep 25 2008, 09:02) *
Поискал информацию на форуме по этому интерфейсу ....

Могу предложить статейку о микроконтроллерах NEC для автомобилей, часть-2, там есть описание работы LIN.
Находится у меня на сайте, раздел "статьи"..
Удачи!
Alex B._
Цитата(ALARM @ Sep 25 2008, 09:02) *
1.Какова максимальная длина линии/кол. девайсов на линии.

40 метров, 1 master и до 15 slave устройств на линии

Цитата(ALARM @ Sep 25 2008, 09:02) *
2.Каково минимальное потребление в режиме ожидания запроса (наверное это зависит от драйвера?).

Вообще говоря, у LIN энергопотреблению довольно много внимания уделено. Мастер может перевести слейв в режим энергосбережения специальной командой. Потребление действительно зависит в основном от драйвера - это ~10-30 мкА в режиме прослушивания (передатчик и встроенный регулятор (если он есть) напряжения выключены). А дальше все зависит от чипа - если он умеет просыпаться по фронту на RX - то его можно вгонять в совсем глубокую спячку, это + 1-5 мкА.

Цитата(ALARM @ Sep 25 2008, 09:02) *
Мне приходилось иметь дело с 1-WIRE. Может кто скажет, в чем у них основные отличия. И есть ли преимущества у LIN?

LIN это по сути расширенный UART, который поддерживает детектирование фронта на RX и автоматическое определение скорости - это краеугольный камень LIN, так как предполагается, что в слейвы - это простенькие девайсы, в которых стоят чипы, тактируемые от внутреннего или внешнего RC. Так что 1-wire тут непричем, это совсем другое. Как впрочем и CAN.

Основные преимущества LIN вытекают из этого ответа: низкое потребление узлов сети, использование простых дешевых контроллеров без кварца. Ну еще можно добавить хорошую EMC совместимость со штатным оборудованием (при использовании совместимых драйверов). Если EMC и низкого потребления не требуется - можно юзать K-Line драйвер (2 транзистора) - тоже плюс.
ALARM
Цитата(iosifk @ Sep 25 2008, 13:18) *
Могу предложить статейку о микроконтроллерах NEC для автомобилей, часть-2, там есть описание работы LIN.
Находится у меня на сайте, раздел "статьи"..
Удачи!

Прочитал статью с интересом. Спасибо за Ваш труд.

Цитата(Alex B._ @ Sep 25 2008, 14:00) *
40 метров, 1 master и до 15 slave устройств на линии

Для моих задач малО и расстояние и количество. А задача такова: на 2-х проводную линию посадить порядка ста микромощных спящих приборов (~10uА каждый), а длина такой линии порядка 300 м. И чтоб каждые 2 сек происходил полный цикл опроса наличия и состояния всех девайсов. А состояний у каждого девайса =4. И еще , чтобы все девайсы запитывались по той же самой линии. Ну прям ТЗ для золотой рыбки smile.gif.
Седой
Цитата(ALARM @ Sep 25 2008, 16:54) *
Для моих задач малО и расстояние и количество. А задача такова: на 2-х проводную линию посадить порядка ста микромощных спящих приборов (~10uА каждый), а длина такой линии порядка 300 м. И чтоб каждые 2 сек происходил полный цикл опроса наличия и состояния всех девайсов. А состояний у каждого девайса =4. И еще , чтобы все девайсы запитывались по той же самой линии. Ну прям ТЗ для золотой рыбки smile.gif.


Ну и в чем проблема, возмите другой физ. уровень и используйте LIN протокол. Кстати, я думаю, и штатный LIN приемопередатчик может 300м потянуть, если подобрать нагрузку и емкость линии, вам же не требуется четкое соблюдение требованиям спецификации LIN.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.