[ustas]

SEREGA FRG, спасибо! Эта информация у меня уже была, но сохранить ссылки - всегда полезно.

Теперь еще небольшие траблы (точнее, пока непонятки).

На текущий момент в железе сделано так, что один МК рулит двумя CAN-интерфейсами. (пару-тройку постов выше писал и приводил фото). Оба интерфейса работают.

Проверял следующим образом: сделал отправку в один интерфейс строки "Hello car", в другой: "Hello disp"

Теперь если в диагностический разъем подключать один или второй интерфейс - выводятся на дисплей разные сообщения (т.е. аппаратно - все работает).

Но вот фокус, который хотелось сделать - чтобы мой девайс был "в разрыв" между машиной и дисплеем - не очень пока увенчался успехом:
Со стороны машины все работает, как хотелось...
А вот дисплей, подключенный к интерфейсу (любому интерфейсу моей платы) - молчит, как партизан. Видимо, просто MCP2551 недостаточно, чтобы оно "взлетело" (в машине есть что-то "шинообразующее").

с кабелем и подключением дисплея (внешнего) - все точно в порядке - если его напрямую подоткнуть к диагностическому разъему - он тут же начинает принимать сообщения машины и отображать ровно то же самое, что "штатный".

 WP_20141006_00_12_45_Pro.jpg (475.12К)
Количество загрузок:: 66

Может, кто-то уже сталкивался с этим? Может требуется куда-то подтянуть MS_CAN_L и MS_CAN_V?

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

[_Michail_]

У меня тоже есть вопрос, есть ли команда для, дисплея или другого устройства, типа брейк и адрес устройства, чтобы дисплей перестал выводить информацию на определенное время, ото всех устройств кроме необходимого? Если такое есть, то городить два кан-порта и ненужно будет

Сообщение отредактировал _Michail_: 28 October 2014 - 19:40

[ustas]

к сожалению, такой команды по логам не видно.

На адреса дисплея валятся только сообщения о том, что выводить...

[SEREGA FRG]

Мужики посмотрите у матрёхиных рулевых
Там больше инфы
http://mazda3.ru/board/

[ustas]

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

[ustas]

Есть подозрение, что проблема "изолированного от машины стенда" состоит в том, что "новосозданная" шина (состоящая всего из двух "узлов": моей платы и дисплея) не обладает необходимым сопротивлением. В разных источниках указывается, что шина должна быть обязательно "терминирована" с каждой стороны резистором в 120Ом. Т.е. "нормальное" сопротивление шины - около 60Ом.

Измерил сопротивление между CAN_L и CAN_H дисплея - около 50кОм, сопротивление между CAN_L и CAN_H на моей плате - тоже около 50кОм. Попробовал тупо воткнуть между проводниками шины резистор на 60Ом - не завелось.... еще погуглил - http://www.carflood....mon/91-can.html - тут говорится о том, что для шины комфорта нормальное сопротивление от 2 до 3.5кОм... пробовал резистор 2к4 - тоже не завелось.

Надо, видимо, в машину идти и измерять сопротивление на шине... тогда уже пробовать дальше. Похоже, я просто "лабораторную" CAN-шину недоделал...

[ustas]

Надо, конечно, ложиться спать ... но пока не забыл, вот что нашел:

You can send the 3 frames with the following IDs:
0x28F: LCD settings and probably some other settings (you just send the same data you receive in a normal 0x28f frame).
0x290: 0xC0 (first byte) followed by first 5 alfanum signs
0x291: 0x85 (first byte) followed by the next 7 alfanum signs

all of them, just after you receive the 0x291 frame id sent by the HU. This will make your text being visible with almost no flicker at all.
The reason for sending the 0x28F is that it is required for displaying the 0x290 and 0x291 text, otherwise the LCD seems to simply ignore the 0x290 and 0x291.
Another method would be to set a timer with a 150ms interrupt and send the 3 frames described above.

...

0x28F frame content that I have used:
hex: D1 00 00 00 80 00 00 01


щас быстренько пытался что-то делать по полученным данным:
1. адрес 28F, насколько понял - отвечает за надписи DISK IN, ST, AF и т.п.
2. шину надо чинить (в какой-то момент дисплей моргнул и показал строку, которую должен был выводить)

[_Michail_]

Судя по картинки нужно делать именно так:



То что ставилось одно сопротивление на 60ом это несколько не та схема включения

Что касается сопротивления согласования:



То оно должно быть уже на плате устройства.

Сообщение отредактировал _Michail_: 29 October 2014 - 09:49

[_Michail_]

И все таки есть что-то типа брейка
bus arbitration
арбитраж шины
Процедура арбитража необходима для разрешения ситуаций, когда
несколько узлов пытаются получить одновременный доступ к шине.
После ее выполнения доступом к шине обладает лишь один узел. В
CAN протоколе используется алгоритм арбитража CMSA/CD
(множественный доступ с обнаружением несущей / детектирование
коллизий) совместно с AMP (арбитраж по приоритету сообщения).
Этот протокол позволяет проводить арбитраж без разрушения
сообщений.

Вот отсюда:

http://www.can-cia.d...onary-v2_ru.pdf

[_Michail_]

Воооо что надумал Можно ли сделать так:

1 ничего в разрыв не включать.
2 Слушать необходимые коды, интересные нам.
3 Вытаскивать из данных кодов данные, менять на код, который может принять дисплей и посылать данные.

По идее дисплей должен показать принятые данные от вашего устройства, а после вернуть данные которые шлет балалайка

[_Michail_]

Нашел интересный документик, может еще кто займется
http://www.soel.ru/cms/f/?/441058.pdf

[ustas]

_Michail_, начну по порядку:

1. про "схему шины" - согласен, попробую, должно заработать (тем более, что вчера я уже разок увидел нужное сообщение на дисплее)
2. про арбитраж - это реализуется на аппаратном уровне, насколько я понял - нельзя сказать конкретному устройству "заткнись". Здесь просто на шине устраняется "балаган", когда все одновременно орут и толком никто ничего не слышит - просто наводится порядок в сообщениях и сообщения начинают доходить до адресатов - не более того
3. про "слушать коды" и отправлять в дисплй - с этого я и начал.. но вот представь себе стиуацию (штатная балалайка есть):
- балалайка флудит вывод на дисплей примерно раз в 150мс
- платка что-то там приняла (пусть для определенности это будет средний расход)
- платка отправила дисплею команду - "нарисуй расход"
- дисплей это принял и исполнил
- балалайка в очередной раз отправила команду - напиши название станциии

и... наше сообщение перетерто..

именно с этой проблемой "перетирания" я и борюсь.

4. документик хороший - он рассказывает об основах (аппаратный уровень, разрешение коллизий, коррекция ошибок и т.п.).. но в нашем случае это не так интересно, поскольку мы саму шину не реализуем - она у нас уже есть как данность (в машине), а за "низкоуровневую" реализацию отвечает MCP2515 и MCP2551 (а вот разработчики этих микросхем собаку съели на подобных документах). В своем устройстве я могу оперировать только адресами устройств, длинной пакета и его содержимым.. могу читать (фильтровать, преобразовывать и т.п.), могу передавать.... но при этом совершенно не заморачаваясь на тему "как оно там коллизии обходит".

[_Michail_]

Ну, эт понятно... Вы же эту стадию прошли раньше, а я сейчас по вашим стопам... просто мысли в слух Чтоб по граблям не бегать А еще попутный вопрос, нет ли параметра жизни/отображения сообщения? Типа показать в течении 15 секунд, не смотря на флуд других..
И еще вопрос, программно можно нажать на кнопку?

[ustas]

К сожалению, "времени жизни" сообщения - нет (или я не знаю, куда смотреть). Но судя по тому, что магнитола флудит без умолку каждый 150мс - этого "времени жизни" просто нет.

Про программное нажатие кнопок - тут надо пробовать... вроде как нажатие кнопок на руле - должно транслироваться в CAN-шину (что подтверждается тут: http://www.madox.net...omment-page-1/) - соответственно, можно своим устройством отправить аналогичную команду - и будет "нажатие".

Аналогично, думаю, можно "слушать" сообщения о нажатии кнопок и эту информацию использовать для управлению разрабатываемым устройством (к примеру - переключиться в режим AUX - это можно отловить по сообщению для отображения на дисплее) и дальше слушать нажатие кнопки "mode" на руле (в этом режиме она не используется, но, надеюсь, информация о ее нажатии будет в шине). Аналогично с другими кнопками на руле - тогда можно будет и дату-время подстраивать и переключаться между режимами отображения информации и проч.).

Кстати, для тех, у кого нет штатной балалайки я уже готов сделать девайс по отображению информации маршутного компа (ну и даты-времени, если надо). Есть желающие?
перед запуском мелкого производства нужен хотя бы один "подопытный" - чтобы я подключил свой прототип к диагностическому разъему и проверил, что все работает (заодно и "подопытный" сможет подтвердить, что это не просто разговоры ))

[_Michail_]

Наткнулся на схему шины, я думаю что пригодится:

[al4630z]

Кстати, для тех, у кого нет штатной балалайки я уже готов сделать девайс по отображению информации маршутного компа (ну и даты-времени, если надо). Есть желающие?

Я готов. Но маршрутник есть. Ранее писал хотелки. И с доставкой

[_Michail_]

Я тут по изучал чуток, и пришел к выводу что:

1 Если врезаться между КАН шиной и дисплеем, нужно писать много коду, и следить за всеми сообщениями, но, есть преимущество, минимум переделок при подключении.
2 Если, смириться с некоторой доделкой, то по мне, проще врезаться между штатной балалайкой, и контролировать только ее сообщения, и уже будет по барабану, штатная голова стоит или нет. Глушить по необходимости ненужные на текущий момент сообщения, и выводить свои.

[ustas]

al4630z, хорошо, что-нибудь придумаем... но пока желающих маловато самому плату делать - лень (хотел заказать в Китае, как уже делал неоднократно, но там от 10 плат )... посмотрим, может, наберем хотя-бы 5-6 желающих - тогда можно будет сделать. Доставка - не проблема.

_Michail_, тут как посмотреть.. про "много кода" - ну да, на пару-тройку строк больше.. зато гибкость и можно реализовать максимально похоже на "штатное" (к примеру - отображается какое-то "нештатное" сообщение, а ты нажимаешь кнопку увеличения громкости - это отражается на дисплее (как и при штатном варианте), а потом все возвращается в исходное состояние)...
Кстати, можно схему с двумя интерфейсами (тот вариант, что я прорабатываю) подключить и между магнитолой и шиной - и тоже можно реализовать максимально похожее на штатное поведение.

В принципе, есть вариант поступить "по тупому" - поставить релюху между шиной и магнитолой, которая будет банально отрубать магнитолу от шины (соответственно, "глушить" ее сообщения в шину). Примерно так:


Но я все-таки хочу сделать "полную версию". Тем более, что сегодня все-таки победил "лабораторную" шину и у меня дома на столе система уже заработала.

Проблем в моем "стенде" оказалось две:
1. Нужен был "терминатор" (хватило одного резистора на 120Ом) - поставил у дисплея
2. По каким-то непонятным мне причинам подохла одна микросхема MCP2551 (сравнивал сигналы осциллографом на двух интерфейсах своего устройства). Заменил ее и все заработало.

Сейчас "лабораторный" стенд работает в полном объеме. Тестовая прошивка на один интерфейс выводит "Hello car", на другой "Hello disp". Теперь уже можно писать полный код для вывода полезной информации.

P.S. кстати, если оставить у дисплея подключение только к MS_CAN - не работает блок отображения климата.

P.P.S. вообще круто сделать три CAN-интерфейса: первый смотрит на высокоскоростную шину (там много чего о моторе можно узнать), второй - на среднескоростную (магнитола, управление климатом?, маршрутник и т.п.).. а третий - на дисплей, чтобы можно было все отображать как хочется

Сообщение отредактировал ustas: 30 October 2014 - 00:22

[al4630z]

Есть машинка с нештаткой и отсутствием маршрутника, о чём хозяин сетовал. Позвоню сегодня ему, думаю согласится.
По поводу сбыта можно и матрёшкинцев заинтересовать, разницы как я понимаю нет.

[annik]

Тоже готов быть испытателем. Мне тоже кажется, что 10 платок разойдутся как горячие пирожки. А какой порядок цен если заказывать 10-20-30-40-50 плат? Не обязательно же собирать все платы сразу- пусть лежат и по мере востребованности собирать. Возможно смогу поддержать проэкт материально. С удовольствием слежу за темой, в разговор не вмешиваюсь из-за нехватки знаний в данной области.