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

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

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

Ну а смысл-то какой в AVR? За большие(ну или равные) деньги получить всего меньше. Ну и? Типа на немного знакомом ASM писать ? Использовать ранее полученные сокровенные знания по работе GPIO от Atmel ?


Ну для периферийного устройства типа "кнопка на CAN" почему-бы и нет, а для "центрального" микроконтроллера зачем такие изыски...

Да почему? На Си.

Просто человек явно задумал некоммерческое устройство, пусть делает на чем хочет - ближе ему AVR, пусть будет AVR. Незнаком с ARM - не стоит и браться за него в таком проекте, вместо удовлетворения от реализации будет глюки ловить, происходящие от незнания предмета. С другой стороны, при желании факультативно изучить ARM, можно взять и его, главное, за лесом увидеть деревья

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

Rst7 прав... Штука некоммерческая. AVR ближе, плюс на него уже есть наработки, которые не хотелось бы переписывать (большую часть проекта по частям уже изобразил - настало время сложить все вместе). Следить за тем, чтобы два проца одновременно не передавали в шину нет никакого желания, поэтому пускай будет MCP2515/MCP2551 (кстати почему кал ? Есть какие-то подводные камни ?). Вопрос я так понимаю исчерпан.

Для того, чтобы следить чтобы два или несколько процессоров не передавали одновременно, нужно реализовать программно одну единственную вещь, чтобы основной комп передавал на шину запросы, а остальные ему отвечали. И даже при работе с MCP Вам также придется организовать работу, где мастер это
комп под сидушкой, а меги все отвечают на его запросы. Т.е. пакет компа видят все процы, а отвечает только тот, чей адрес в пакете.
Вам в любом случае нужно будет оформлять информацию в пакеты данных. Неважно, используете Вы MCP2515 или нет. Только MCP2515 за Вас сам
определит адрес пакета, а в моем варианте это сделает mega. Это не супер сложная операция, сравнить байт адреса принятого по CAN шине.
Но я не навязываю решение, только предлагаю как один из вариантов.

Тот же модуль кондиционера должен знать температуру двигателя с диагностики, чтобы не включать печку при прогреве двигателя. А еще эту температуру должен знать модуль IF (у которого есть свой маленький LCD, на который он выводит информацию с парктроников, и который следит за параметрами двигателя подавая сигнал спикером в случае проблемм), а еще модуль IF должен знать текущий расход, который считается отдельным процессором. CAN же вроде позволяет multimaster режим ?

З.Ы. Комп может быть отключен - мало ли что. Поэтому в случае его отсутствия критические данные (парктроник, температура двигателя, часы, расход горючки) должны быть доступны через тот же LCD.

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

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

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

Спасибо за аргументированный ответ

zltigo, а дорого это в каком смысле ? Для серии дорого или вообще дорого ? Мне кажется мое единичное изделие если я начну на арм переползать выйдет дороже только потому, что мне придется лепить программатор, новые макетки, тратить время на изучение ARM.

И из вашего последнего поста я так понял вы ответили на мой вопрос - в пределах блока CAN контроллерам драйвера шины не нужны ? Я правильно понял ?

Дорого практически ВСЕГДА. Цену LPC236x http://mt-system.ru/index.php?store_search=lpc236&id=5 в услових российской розницы я привел. А сколько стоит "голый" AVR128? Программатор не нужен - все приличное из мира ARM содержит bootloader-ы и заливается по RS232/USB. Если не уперлись когда-то у эпоху 8bit+пару сот байт памяти в ASM и пишите на 'C', то собственно в первом приближеии изучения ARM нет. Ну а макетки.. это уже Ваши проблемы - надо было раньше думать, хотя цена вопроса готовых китов долларов 60 - http://starterkit.ru, например...

Могут быть использованы любые решения обеспечивающие доминирование "низкого" уровня на шине. В пределах 19" блока с этим успешно справляется банальный "открытый коллектор".

Млян... Я обычно на чип-дипе цены смотрел - думал порядок цен везде примерно одинаковый. Фига се разница. Млян млян млян....
Пишу на C. Пошель читать даташиты. Встроенный USB и CAN мне как-то сильно хочется.

Я бы не гнался за дешевизной. Завтра захочется подключить чего-нить внешнее. Или случайно замкнуть проводочки интерфейса. Драйвер защищен от десятков вольт, а транзистор - нет. Только что запускал первое устройство, сделанное производством. В половине разъемов шины монтажники напутали провода.

Для связи с комьпьютером в Вашем случае рекомендую Ethernet а не USB.



Контроллеры по нынешним временам имеют несколько CAN контроллеров на борту. В моем случае межблочные и блочные это разные интерфейсы. Более того, внутри блока два (резервирование) CAN на OD и два на "обычных" выходящих за пределы блока. На шине блока масса и других сигналов, но естественно с защитой и организацией hotswap. Ну а дешевизна...., когда только в одном в блоке 24*2*на пару баксов.... есть о чем подумать.

Вообще я изначально хотел Ethernet (я сам с компьютерными сетями работаю по основной работе, мне это ближе) и даже сделал на макетике интерфейсик на пробу ENC28J60 + разъем с трансом, но покрутил, подумал... И плюсов по сравнению с usb не нашел (хотя у материнки два RJ-45 на борту), а минусов куча - аппаратно сложнее, софтовая часть сложнее (причем на обеих сторонах). Вот и решил, что будет USB. Или в пользу ethernet есть какие-то аргументы, про которые я ни сном ни духом ?


З.Ы. Почитал по диагонали даташит на LPC2364... Впечатлился... Он один вытянет все, что я хотел сделать на трех аврах. Уйма UARTов, уйма I2C, два CAN, USB, 70 ног, ADC/DAC, управление питанием выглядит поприличнее атмег, собственный RTC батарейный (хотя наверное не 2ppm как в ds3232), потребление при той же частоте чуть больше АВРа (без переферии примерно одинаково).

А как у него с надежностью ? Камней подводных нету ? А где-нибуть pcb design notes можно взять ?
И еще глупый вопрос - пошарил по mt-system.ru и так и не понял поставляют они детальки розницей по интернету или нет...

Угу... Встроенная гальваническая развязка, что может оказаться решающим в условиях помех.

Два камня, как минимум. Первый, это где Вы его планируете разместить рядом с датчиками или в салоне автомобиля. Если в салоне, то как Вы собираетесь
протянуть провода от датчиков к процессору, в смысле напрямую, через драйверы или еше как. Если процессор будет не в салоне,
то где?
Второй, это температурный диапазон, максимум 85С, если поставите под капот, летом может перегреться, думаю рядом с мотором
температура легко поднимется до 85С.

Аппаратно сложнее на собственно PHY. Программно ... программно скорее проще можно и IP стек не поднимать в работать в пределах сегмента голых фреймах (RAW Socket со сторны писишки). Со сторны PC поддержка железа, считай, готовая - где Вы там увидели соложность ума не приложу. Дальше гальваническая развязка, расстояния, большая реалтаймовость, опять-же не точка-точка. Если к этому добавить по жизни приглючивающие реализации USB драйверов/профилей на стороне PC, то..... Не для НЕ для подключения гаджетов я не буду USB использовать без жестокой на то необходимости.

Мысля понятна... Буду думать. На голых фреймах мне кажется как-то некрасиво Лучше с ip стеком все-таки.
Оказывается UART у LPC тянет только фреймы 8бит... а надо 9N1 - придется извращаться с битом четности

Кому это надо? Может Вам просто UART не нужен, а нужен SPI? I2S?

Э.... Это уже имеющиеся парктроники компании РИТМ. Две штуки - один вперед, а другой назад. Там два блока - основной на pic16f676, который с датчиками работает, и дисплей. Основной блок передает дисплею данные софтовым последовательным интерфейсом - 9N1 посредством двухпроводной линии (т.е. на моей стороне нужен только RXD пин). Дисплей меня понятное дело не устраивает - не очень хочется кругом эти коробочки со светодиодами иметь, а компьютер будет выводить данные парктроников вместе с изображением камеры заднего вида (пищалка в контроллере). Поэтому и придется извращаться. Тут уж ничего не поделаешь . Плюс у самого диагностического интерфейса машины скорость 7812 8N1 - lpc это вроде как потянет (делитель дробный).