Помогите определиться с дизайном схемы... Опции

[Regressor]

Здравствуйте... У меня следующая задача - неспешно делаю переферийную железку в свое авто (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. Правда не уверен шо она все это вытянет.

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

[rvk]

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

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

[zltigo]

... по CANу. Он ничем не отличается от UART, только рядом с мегой стоит драйвер CAN шины....

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

[rezident]

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

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