Здравствуйте... У меня следующая задача - неспешно делаю переферийную железку в свое авто (Suzuki Escudo). Делать хочу на AVR ибо его вроде немного знаю и инструментарий под него уже есть. Пока макетирую на коленке требуемые функции по отдельности. И думаю как соединить все это вместе. Задачи железки следующие:

1. Расчет потребления горючки: брать сигналы с форсунок (длительность открытия) - порядка миллисекунд и датчика скорости - около 2тыс импульсов/км а также с датчика давления в топливной рейке.
2. Собирать информацию с дополнительных датчиков на двигателе (темп. масла, давление масла, темп декстрона, уровень тормозухи и жидкости гур, датчики дверей, датчик света)
3. Получать информацию с двух парктроников (uart 8900 бод, 9n1 на каждый, только прием, передача не нужна) - на макете протокол вроде отладил
4. Получать информацию с диагностического интерфейса (uart 7812 бод, 8n1) - тоже вроде в порядке
5. Получать информацию с TPMS (контроль давления в шинах) - (serial софтовый скорость в районе 9600, пока точно не определился)
6. Часы реального времени - DS3132 (уже куплены, там же сохранение данных - battery backed 240 bytes)
7. Полная замена климат-контроля (т.е. отслеживание 4 датчика температуры (i2c), 2 влажности (i2c), шим-контроль вентилятора, контроль серводвигателей заслонок)
8. Вывод информации на двухстрочный символьный LCD (hd44780) и управление его подсветкой в зависимости от освещения + клавиатура (не больше 6 кнопок)
9. Управление силовой частью (автоматическое включение фар например, или закрытие дверей при начале движения) - порядка 10 каналов
10. Общение с автомобильным компьютером по USB (AVR UART <---> FT232RL). Это передача всей инфы на компьютер (8 раз в секунду примерно по 300байт) и прием команд (например управление климат-контролем, установка времени, управление силовой частью)
11. Управление зарядкой/разрядкой дополнительного АКБ (вторая отключаемая АКБ в багажнике, датчик тока CSLA1EL на генераторе и в зависимости от нагрузки на генератор и напряжения на первой АКБ подключение и отключение зарядки и нагрузки второй, при этом должен определяться факт наличия второй АКБ и при ее отсутствии ее нагрузка должна переключаться на первый). Пока предпологаю 3 ключевых элемента с помощью которых можно подключать отключать обе батареи и переключать их нагрузку. Только там в пике до 400 ампер (стартерный ток) поэтому пока не знаю что за ключи ставить.
12. Управление блоком питания компьютера и выдвижным монитором - на прогреве от сигналки например комп должен будет запуститься, но монитор не выезжать пока с сиги машина не снимется (т.е. еще один вход с сиги) - иначе стекла повыбивают и монитор сопрут.

Возможно будет что-то еще по мелочи (т.е. штук 5 ног надо в запасе оставить). Пока навскидку вижу это следующим образом (возможно можно сделать гораздо проще):

1. С FT232 работает ATmega8 (назовем ее IF - интерфейсная, часы на 8мгц внутр), которая рулит LCD и принимает данные с двух парктроников и диагностики (рядом по i2c два самых мелких attiny с USI, которые работают с парктрониками (или это проще все софтом вытянуть ?). На FT232 смотрит аппаратный UART atmega8. Общение с диагностическим интерфейсом (полудуплекс 7812бод 8N1) - софтверной реализацией UART на той же меге. Ну и клавиатура там же.
2. Климат-контролем занимается отдельная мега (тоже 8мерка, хотя тут наверное можно что-нибуть попроще поставить), которая с интерфейсной общается по SPI.
3. Остальным занимается mega32-16мгц. Часы реального времени с памятью тоже на ней - ей больше всего помнить надо. Интерфейсная мега периодически ее опрашивает тоже по SPI. Правда не уверен шо она все это вытянет.

Может гуру подскажут в ту ли я иду степь и правильной ли дорогой... А то по части аппаратной реализации сильные сомнения.

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

По поводу аппаратной реализации. Я не гуру, но мысли у меня такие. Есть два пути. Сделать кучу мелких мег, и заставить их общаться по общей шине. Там где сегодня три меги, завтра будет шесть. Для этого придумали автомобильную шину CAN, предлагаю в первую очередь заставить меги общаться друг с дружкой по CANу. Он ничем не отличается от UART, только рядом с мегой стоит драйвер CAN шины, и в итоге все RS232 можно объединить парой проводов. RS232 могут быть софтовые. Тогда в системе будет один мастер, например IF, остальные слейвы, отвечают по запросу.
Сразу снимется вопрос их взаимодействия. SPI тут не пойдет, лучше всего RS232.
Второй вариант, вывести все провода со всех датчиков на лицевую панель или в салон машины. Потратить на это время, конечно. Зато можно потом
все это завести на одну плату бортового компа на АРМе, и тогда все сказки мира к Вашим услугам. Цветной LCD дисплей, супер графика, и прочее,
и прочее. А главное, для замены компа, не нужно будет лазить по всей машине, и менять каждый узел. Все в одном месте.
Второй вариант лучше еще и тем, что комп будет внутри отапливаемого салона работать, в отличие от мег, которые возможно где нить под капотом,
в жару и на морозе пашут. Но зато помехи от датчиков не словят. Возможно придется делать комбинированный вариант.
Т.е. мощный проц на бортовой комп, и мелкие на местах, откуда провода с датчиков не протянуть, нужны цифровые данные.
Тогда все это объединит шина CAN, ей помехи нипочем. И вывод будет на красивый LCD.

Вариант с CAN я как-то не рассматривал... Надо будет глянуть. Комп автомобильный - обычный miniITX под седушкой (Kontron 986LCD/mITX + CoreDuo). Уже лежит собраный - пишу головной софт. Сам переферийный блок будет не под капотом - хочу его разместить под торпедой (прям на ECU повешаю), место вроде есть.

Кстати я так понимаю можно и без IF меги обойтись если к компу организовать CAN-USB. Тогда комп сможет опрашивать каждый микроконтроллер из набора напрямую? А та же мега8 на 8мгц (внутр. генератор) вытянет четыре софтовых UART (два парктроника, TPMS, CAN) ? Это как-нибуть примерно прикинуть можно ?

Верно, нужно либо купить, либо спаять переходник CAN-USB, можно купить RS232-USB и переделать на CAN, и подключать машину прямо к USB
порту. Если есть порты, тогда CAN RS232. Вообщем есть где мысли развернуться.
С другой стороны у Atmel есть целая серия чипов специально для Automotive приложений.
Например AT90CAN32, встроенный CAN контроллер, плюс два UART, правда не знаю как с доставаемостью.

Да эта IF мега не нужна, если есть целый комп.
Мега8 может потянуть до трех программных UART на 9600, по идее. Другое дело, что на каждый программный UART нужен таймер и компаратор. Поэтому больше четырех врядли удастся сделать на одном чипе. То есть три программных, один аппаратный. Правда на мой взгляд,
это нагрузка, которую нужно проверять.
Я например, на первый дизайн, взял бы сразу ATMega64, покупается один раз, если нормально сделать, она там долго проработает. У нее два аппаратных UART, куча выводов. Она точно потянет два софтовых UART плюс два аппаратных.

CAN ничего общего с UART не имеет. Совсем ничего. Это я не к тому, что его не надо использовать - именно его и надо.
A вот AVR c CAN - не надо.

А что плохого или неудобного в CAN AVR? Сам понемного приглядываюсь к авр с CAN на борту, поэтому хотелось бы знать ньюансы применения и возможные проблемы

ИМХО очень туманно (двусмыленно, неоднозначно) выразились. Я только с третьего прочтения понял смысл предложения и что надо, а что не надо

Абсолютно неадекватная цена и/или заброшенное старье.



Уточняю CAN отличная вещь. AVR ценой более нескольких баксов использовать обычно неразумно. AVR с CAN по стоимости/ресурсы не лезут ни в какие ворота.

Ну в общем почитал про CAN, пошукал по части драйвера/контроллера CAN. Остановился на MCP2515/MCP2551 от микрочипа, которые в чипдипе стоит порядка 100/120руп соответственно. Никто с ними не работал ? Их обязательно надо парой ставить? Или на малых расстояниях (в пределах платы) контроллеры можно напрямую соединить ?

Контроллеры-то можно соединить. Но есть ли смысл тогда в их использовании? Связь ведь получится точка-точка.
И как тогда Ваша плата будет общаться с другими устройствами системы?

Не нужны Вам контроллеры CAN, не нужен протокол обмена. Просто соедините RS232 выводы процессоров с микросхемами, драйверами CAN,
а выводы CAN всех драйверов объедините в одну шину. И обменивайтесь информацией напрямую по собственному усмотрению.
Как будто Вы соединили все процы в один общий RS232. Поменялась только среда физическая, а формат данных остается
все тот же 9600 8N1. В этом вся прелесть CAN, можно все устройства повесить на три провода.

Еще один абсолютно, ну скажем так, некомпетентный и "совет"

Дайте компетентный, я работал с CAN по самостийным протоколам, не моим конечно, Меркурий 230, и чем это не подходит для самодельной системы на авто? Что тут такого абсолютно неверного. На фига весь навороченный протокол CAN и специализированные контроллеры, когда достаточно подключить к меге драйвер за 1.5$ и самодельный пакет с контрольной суммой CRC16.

Сообщение отредактировал vvvv - Jan 13 2009, 19:55

Видете-ли единственная поделка имеющая в своем названии "Меркурий 230" является электросчетчиком и работали Вы с ним по RS232/485 интерфейсу, который, естественно, никакого отношения к CAN не имеет. Или через "Адаптер" CAN содержащий, хоть это и осталось для Вас неведомым и микроконтроллер и CAN контроллер и "весь навороченный протокол".

Не надо этот кал использовать, извините за прямоту. Возьмите ARM с CAN'ом или, несмотря на мнение zltigo, AVR с CAN'ом на борту, в единичном экземпляре цена камня без разницы. Ну софтовый CAN предлагать не буду, могут не понять Хотя лично я, если бы делал серийное устройство, не побрезговал бы и таким решением. Както даже начинал делать, но забросил на полпути. Причем, совсем не из-за каких-либо технических проблем. Просто стало лениво заканчивать.