Контроллер AiNet

Ок, по результатам "смеха ради" отпишитесь, посмеемся вместе.

---------- Сообщение добавлено 25.02.2011 в 19:03 ----------

И по Вашему описанию протокола AiNet, я конечно, могу ошибаться, давно дело было, но просматривая старые логи, я бы назвал id 0x50 не просто головным устройством, команды с этим id появляются при нажатии кнопок на ГУ, у себя я этот адрес идентифицировал как кнопки лицевой панели, а адрес 0x7F скорее не широковещательный, а адрес индикатора на лицевой панели головы, во многих протоколах выдача broadcast пакетов подразумевает прием этих сообщений всеми устройствами на шине и подтверждение приема не выдается, здесь же адрес 0x7F выдает in frame response , т.е. это, скорее всего функциональное устройство со своим адресом на шине. В остальном респект.

Сообщение от gamma-ukr

Ок, по результатам "смеха ради" отпишитесь, посмеемся вместе.

IMHO: Вопрос представляет довольно академический интерес, поскольку строить сложную систему на старых ГУ без монитора -- очень специфическая задача. Проверю как будет свободное время, но явно без спешки.

Сообщение от gamma-ukr

И по Вашему описанию протокола AiNet, я конечно, могу ошибаться, давно дело было, но просматривая старые логи, я бы назвал id 0x50 не просто головным устройством, команды с этим id появляются при нажатии кнопок на ГУ, у себя я этот адрес идентифицировал как кнопки лицевой панели,

Все не так просто. ГУ Alpine транслируют в AiNet не нажатия физических кнопок, а готовые логические команды другим, предварительно обнаруженным, устройствам. Это более высокий логический уровень. Например, один и тот же энкодер может рулить как громкостью/балансом/фейдером (id 0x02), так и уровнем саба (id 0x50).
Похоже, что базовые функции отправляются от id 0x02, а все посложнее (саб, пресеты, управление ченджером) -- от 0x50. Прямой связи с аппаратными кнопками тут не прослеживается.

Сообщение от gamma-ukr

а адрес 0x7F скорее не широковещательный, а адрес индикатора на лицевой панели головы, во многих протоколах выдача broadcast пакетов подразумевает прием этих сообщений всеми устройствами на шине и подтверждение приема не выдается, здесь же адрес 0x7F выдает in frame response , т.е. это, скорее всего функциональное устройство со своим адресом на шине. В остальном респект.

Опять же, не совсем так. H700/701 отправляет пакеты устройству 0x7F всегда, даже когда на шине он совсем один (работает в stand alone). При этом IFR также присутствует, то есть подтверждает корректность этих пакетов сам процессор. Так что 0x7F -- id процессора, используемое для рассылки сообщений о его текущем состоянии. Типичный broadcast, только реализованный не совсем обычно.

Сообщение от Nik1976

IMHO: Вопрос представляет довольно академический интерес, поскольку строить сложную систему на старых ГУ без монитора -- очень специфическая задача. Проверю как будет свободное время, но явно без спешки.

На самом деле, вопрос представляет чисто академический интерес, т.к. актуальность инсталляций в эти автомобили стремится к нулю. Да и ainet , по-большому счету, не сильно актуален.

По-поводу остального спорить не буду, как уже сказал, дело было давно, я работал с какой-то древней головой и с 600-м и 400-м процессорами, возможно с тех пор, по мере усложнения устройств, в протоколе появились какие-то изменения. У меня, кстати, получалось, что если процессора на шине нет, 40-м адресом на шине встает встроенный в голову процессор, и IFR присутствует только в пакетах от или к внешним устройствам на шине, "внутренние" адреса головы IFR не выставляют, только 0x7F.

Перечитал, хоть это и чисто теоретический вопрос, насчет адреса 7F, наверное поспорю, режим стэнд алон - нетипичный режим работы устройств с шинной организацией - на шине никого больше нет, и устройства индикации в том числе, то что проц сам себе шлет подтверждения ни о чем не говорит, кроме странностей организации стэка . Типичный широковещательный пакет предполагает, что он адресован всем устройствам на шине, и кто должен слать подтверждение непонятно, попробуйте подумать, как написать программу работы какого-то устройства на шине, чтобы оно, не зная что твориться у других отсылало подтверждение приема, если должны отсылать все - как синхронизировать, чтобы никто друг-другу не мешал? В ie-bus, например, при broadcast-посылке слэйвы даже ask не отсылают, т.к. непонятно, кому именно это нужно делать.

Ок, обидную фразу стер, но сути-то это не меняет, признайтесь, что таких ссылок нет , ведь это правда?
Документы присылайте, гляну чем смогу помочь, за экспериментальные разработки с не 100 процентной вероятностью результата с людей предоставивших машины, я обычно денег не беру, в случае положительного решения проблемы - только стоимость затраченных материалов.

Сообщение от andr_l

если считать до запятой - то конечно ссылки нет, но если счатать по смыслу - то до нас и до вас эта работа была начата, и про нее есть данные в интернете, а значит это можно было найти так что и вам тоже придеться признаться например в неумении до конца пользоваться таким ресурсом как интернет (я специально именно так сформулировал фразу, что формально вам придеться признаться, но по сути )

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

Сообщение от andr_l

к сожалению, похоже придеться делать удаленно - вряд ли я смогу пригнать в киев машину из москвы

Я поэтому и написал, что Вы вряд-ли согласитесь, над такими проектами удаленно работать невозможно, железо должно быть на столе, без этого за такую работу ни один разработчик не возмется, увы. А если и возмется, Вы представляете себе процесс отладки девайса с бесконечными пересылками м/д Киевом и Москвой?

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

Написал что намудрили потому что реализация протоколов что ainet, а , тем более, ibus не такая сложная, у меня помещалась в гораздо более слабый процессор, чем у Вас сейчас задействован, и советовать делить задачи по процессорам, на мой взгляд не стоит, тем более, что речь там идет, если я правильно понял, об установке в бмв, очень просто задействовать uart этого процессора на работу с I-BUS ,преобразователь уровня можно на 1 микросхеме сделать, а протокол там простой и хорошо описанный, внешнее управление по rs232 в этом случае не нужно, а Вы начинаете меги128-е и армы обсуждать, нерационально.

Я писал уже, проект заглох потому что я заболел, почти год не имел возможности ничем заниматься.

За подсказку спасибо, я это видел, о датах я Вам уже написал, вообще, я для себя ситуацию уже прояснил, Вы тоже, а если это интересно еще кому-то кроме нас с Вами, написано вполне достаточно, чтобы каждый желающий разобрался сам.

Сообщение от gamma-ukr

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

Написал что намудрили потому что реализация протоколов что ainet, а , тем более, ibus не такая сложная, у меня помещалась в гораздо более слабый процессор, чем у Вас сейчас задействован, и советовать делить задачи по процессорам, на мой взгляд не стоит, тем более, что речь там идет, если я правильно понял, об установке в бмв, очень просто задействовать uart этого процессора на работу с I-BUS ,преобразователь уровня можно на 1 микросхеме сделать, а протокол там простой и хорошо описанный, внешнее управление по rs232 в этом случае не нужно, а Вы начинаете меги128-е и армы обсуждать, нерационально.

Я писал уже, проект заглох потому что я заболел, почти год не имел возможности ничем заниматься.

Почитайте внимательнее историю проекта в моей машине (линк в первом посте). Контроллер для IBUS разрабатывался когда AiNet еще и в планах не было. Потом просто не видел смысла его выбрасывать чтобы морочиться с интеграцией всего в одну AtMega.
Без обид, но "Чего-то Вы ребята намудрили" выглядело несколько высокомерно. Да, я не профессионал, код не выглядит произведением искусства и будет правиться еще не раз. Принципиальный момент в том, что мы сделали пока остальные теоритизировали.
Не мне вам рассказывать какая пропасть лежит между пониманием протоколов и готовой железкой, стабильно работающей хотя бы в двух разных системах.