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

[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. Правда не уверен шо она все это вытянет.

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

[vvvv]

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

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

[zltigo]

я работал с CAN по самостийным протоколам, не моим конечно, Меркурий 230

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

[vvvv]

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

Нет я все понимаю, СуперМодератор, Гуру, орденов как у Брежнева, но что за тон высокомерный из сообщения в сообщение. Меркурий 230 действительно
содержит CAN драйвер, и для работы с ним действительно приходилось со своей стороны ставить PCA82C251, дело было давно, может сейчас они
сменили интерфейс. Вы похоже Меркурии видели только на картинке сайта. Бывает. Ответьте по существу чем решение AVR+PCA82C251 простейший
вариант по физическому CAN не подходит для данной домашней разработки. Аргументированно,без раздувания щек, просто и по существу.
Я предлагаю решение которое позволит завязать хоть 20 процессоров AVR всего по трем проводам, и не изучать всю спецификцию CAN.
Главное, следить за тем, чтобы два проца одновременно не передавали данные в шину. Это же так просто. И недорого.

Сообщение отредактировал vvvv - Jan 14 2009, 06:26

[zltigo]

Ответьте по существу чем решение AVR+PCA82C251 простейший вариант по физическому CAN...

Вы можете связываться как хотите и с кем хотите, рожать любые протоколы или утверждать, что работаете вообще без них:

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

Только не называйте эту поделку CAN только по той причине, что Вы прицепили некий приемопередатчик один из множества удовлетворяюших CAN протоколу и это при том, что CAN вообще не нормирует реализацию физического уровня. У меня, например, CAN в пределах блока работает без всяких (упорно поминаемых Вами в качестве аргумента того, что Вы CAN "родили") PCA82C251 и подобных.

Это же так просто. И недорого.

Просто и не дорого использовать, например, ARM контроллер на 72MHz c CAN контроллером на борту (Ethernet, USB до кучи тоже. Добавите доллар будет LCD контроллер)за 120 рублей (в розницу). Использовать AVR для чего-либо значительно отличающегося от "контроллера светодиода" это уже СЕГОДНЯ в большинстве случаев просто ДОРОГО.