Что такое i bus bmw
Вывода данных компьютера BMW на магнитолу android
Все началось с того что один знакомый поменял свою штатную магнитолу, на полноценное Android устройство. И сразу же задался вопросом о выводе данных бортового компьютера BMW и не только, на экран магнитолы через приложение i-bus app.
Вот кстати известный мне перечень подходящих моделей:
BMW 3er E46 (1998-2007)
BMW 5er E39 (1995-2004)
BMW 7er E38 (1994-2001)
BMW X3 E83 (2004-2010)
BMW X5 E53 (1999-2006)
BMW Z4 E85 E86 (2002-2008)
New Mini One and Cooper R50 (2001-2006)
New Mini Convertible R52 (2005-2008)
New Mini Cooper S R53 (2001-2006)
Range Rover L30 (1999-2003)
Rover 75 R40 (1999-2005)
MG ZT X10 / ZT-T X11 (2001-2005)
Rolls Royce Phantom RR1 (2003-..)
Как показал поиск информации, задача не совсем сложная. Нужен лишь специальных адаптер который подключается в USB разъем новой магнитолы и к шине данных K-BUS.
Большинство или приобретают за немалые деньги такие адаптеры, кто-то собирает на коленке из несколько модулей с висящими проводами. А кто-то запарится и сделает все на одной печатной плате да еще и в корпус установит. Сделает даже так, что плата ровненько по корпусу будет подходить. По такому пути я и пошел.
После полной готовности схемы, приступаю к разработке печатной платы. Для начала работы, пришлось определиться с выбором корпуса для адаптера. Я остановил свой выбор на модели P3A-220805U.
В даташите я нашел все необходимы данные с размерами для будущей платы. Конечно тут пришлось повозиться, вывести каждую линию и окружности. Но все получилось очень даже не плохо. Главное, чтобы когда весь заказ на PCBWay.ru пришел, все действительно сошлось.
Да кстати, этот проект я заказал на сервисе PCBWay.ru. Для тех кто не обладает временем разбираться в этом всем, я оставлю ссылку на полностью готовый проект на их сайте. Вам просто нужно будет добавить его в свои заказы и вы получите готовое устройство.
Параметры заказа платы на самом деле стандартные, никаких супер режимов не выбираю. Как обычно 2 слоя, синий цвет паяльной маски, толщина платы 1.2 мм, белая шелкография. Так же заказал у них закупки и монтаж компонентов.
Не пропустите обновления! Подписывайтесь на нашу страницу в Instagram.
Так же у нас есть Telegram канал.
Вам понравился наш проект? Поделитесь с друзьями!
Сетевой интерфейс для BMW
В данной статье речь будет о локальной низкоскоростной сети взаимодействия блоков управления автомобиля BMW — I/K-bus. А точнее о том, как с ней могут взаимодействовать приложения из под Linux. На картинках проиллюстрирую созданный мною вариант.
Итак, передо мной встала задача расширить функциональность моего автомобиля в области информационно-развлекательной системы. Просто мне этого очень захотелось. Автомобиль хороший, но пожилой. Его создавали во времена, когда даже mp3 не был в обширном употреблении. Поэтому многих современных удобств он лишён. К тому же есть в голове дополнительные идеи, воплотив которые, я смогу подчеркнуть свою индивидуальность.
Информационно-развлекательная система выполняется на устройствах, в основе которых контроллеры с заложенными программами. Я буду здесь называть эти устройства блоками управления. Каждый такой блок управления несёт свою функциональную нагрузку, будь то поддержание температуры салона, регулировка положения сидений, воспроизведение музыки и видео, навигация и прочее. Весь этот набор блоков управления должен взаимодействовать друг с другом, управляться с места водителя и пассажиров, передавать диагностические данные. Для этой цели и была разработана сеть I-bus. В последствии появилась технически идентичная сеть K-bus и их объединение I/K-bus.
Архитектура сети I-bus выполнена по схеме «общая шина», т. е. импульсы данных от узлов (блоков управления) передаются по обычному медному проводу соединённых в одной точке. Поэтому узлы должны делить общую среду передачи и передавать данные по очереди. Как определяется эта очередь или приоритетность я не знаю, полагаю просто прослушивается шина на наличие занятости и с учётом защитного интервала и незанятости шины принимается решение о передачи. В «молчаливом» состоянии уровень потенциала на шине относительно корпуса составляет от 7 В до напряжения питания автомобиля. При подаче доминантного бита в шину потенциал снижается до 2 В и ниже. Битовая скорость взаимодействия узлов постоянная и составляет 9600 бит/с. Цифра знакомая из UART. Но не только в скорости передачи имеются сходства, также формат символов в I-bus соответствует одной из вариаций доступных в UART. Символ состоит из 11 бит: стартовый бит, 8 бит данных, бит чётности, стоповый бит. Эти особенности позволяют физически подключаться к шине через интерфейсы UART или RS-232. Только необходимо позаботиться о преобразовании уровней сигнала с помощью простенькой схемы или готового преобразователя. Для этой цели вполне сойдёт k-line адаптер известный в диагностических интерфейсах. На физическом уровне они полностью совместимы. Я кстати им и пользуюсь.
Про физический уровень сети I-bus я в общем рассказал, теперь опишу кратко канальный уровень, это если следовать последовательности многоуровневой модели OSI. Так будет логичнее. Как я упомянул ранее, для передачи используется общая среда, которую надо делить по времени и передавать данные различным адресатам. Тут можно провести аналогию с Ethernet — данные передаются кадрами в которых содержится адрес отправителя, адрес получателя, полезная нагрузка (данные) и контрольная сумма. Кадр не имеет фиксированного размера и лежит в пределах 5 — 37 символов. Формат кадра я нарисовал ниже:
Здесь TX ID — адрес отправителя, 1 символ;
LEN — размер кадра с вычетом двух первых символов, 1 символ;
RX ID — адрес получателя, 1 символ;
DATA — полезная нагрузка, 1 — 33 символа;
CK SUM — контрольная сумма, 1 символ.
Корректность принятого кадра определяется символом контрольной суммы. Отправитель не проверяет корректность принятого кадра получателем. Возможно это делается на уровне приёма собственного кадра. Если не было коллизий и других сбоев на шине, то отправитель корректно примет собственный кадр и не предпримет попыток повторной отправки. По информации найденной мною во всемирной паутине сказано, что отправитель ждет 100 мс положительной квитанции от получателя. Увы, на практике я этого не встречал. Возможно это применяется для особенно важных сообщений и в протоколах более высокого уровня.
То что входит в полезную нагрузку кадра, относится к протоколу следующего уровня. Работу с этим протоколом лучше возложить на прикладной уровень и работать с ним в приложениях. Повторюсь ещё раз, я ищу применение взаимодействия сети I/K-bus в операционной системе на ядре Linux. Функции блоков управления будут выполнять приложения в пользовательском пространстве. Внутри операционной системы организовать взаимодействия между приложениями не сложно, есть механизмы межроцессного взаимодействия (IPC). Но главная задача связать их с процессами блоков управления автомобиля. За примером обратимся к более известному варианту сети взаимодействия контроллеров — CAN. В Linux эта технология развивается в двух проектах: SocketCAN и can4linux. Первый проект основывается на драйвере сетевого устройства и протоколов, выполняющих предварительную обработку кадров и связывающих сетевое устройство с интерфейсом сокетов. Второй вариант основан на символьном устройстве, подробности реализации этого проекта не знаю, так как не работал с ним. Но полагаю аналог can4linux для I/K-bus является драйвер tty. Достаточно настроить скорость, формат символов последовательного порта и путем чтения/записси ttyS файла будет выполняться прием/отправка данных в шину. Конечно если она подключена к последовательному порту адаптером.
Мне показался более привлекательным вариант SocketCAN, и я пошёл этим же путём. Объясню почему. Драйвер выполнен из двух независимых частей: сетевого устройства и сетевого протокола. В сетевом устройстве решаются вопросы взаимодействия с аппаратной частью и множественного доступа, а в модуле сетевого протокола — фильтрация сообщений и взаимодействия с процессами пользователя. Приложения подключаются к сети I/K-bus посредством сокетов и задачи множественного доступа и фильтрации снимаются. В принципе можно возложить фильтрацию и множественный доступ на какой-нибудь сервер, подключенный к tty устройству и не лезть в ядро. В общем то да, но все равно не обойтись без межпроцессорного взаимодействия, а это как вариант тот же сокет. К тому же в сетевом стеке Linux решены многие задачи с очередями сообщений, которые придётся реализовывать в сервере. И ко всему этому использование сетевого устройства гармонично вписывается в философию администрирования операционной системы. Например командой ifconfig можно посмотреть состояние интерфейса, остановить его или запустить.
Драйвер сетевого устройства для I/K-bus я выполнил на основе slcan, который выполнен на основе SLIP. Я не застал те времена, когда IP пакеты передавались между компьютерами по последовательному порту. Их и сейчас можно передавать таким способом, но это не актуально. А вот передавать I/K- bus кадры таким способом хороший вариант. Драйвер tty сложен и доступ к низкоуровневой его части можно получить через дисциплину линии. Так делается в SLIP и slcan, так поступил и я, написав драйвер slibus. Когда через tty устройство активизируется созданная дисциплина линии, в системе появится сетевое устройство ibusN, где N — 0,1,2… Что бы было понятнее приведу схему. В ней зелёным отмечены квадраты, функции которых выполняет модуль ядра slibus.
Оранжевым цветом отмечен функционал модуля сетевого протокола. Опять же не стал изобретать велосипед и по аналогии модулей can и can_raw создал модуль af_ibus_raw. При загрузке этот модуль регистрирует новое семейство протоколов PF_IBUS и в нем же реализован RAW-сокет для полного доступа к кадру. Посредством вызова setsockopt можно включить фильтр принимаемых сообщений по идентификаторам отправителя и получателя. По умолчанию сокет принимает все сообщения из шины.
Должен сказать, что есть одна неприятность, и заключается она в том, что для возможности загрузки этих модулей необходимо патчить ядро.
А теперь давайте посмотрим как это все работает. Загрузим модули ядра, инициализируем дисциплину линии под номером, соответствующем slibus, и поднимем сетевой интерфейс ibus0. Команда ifconfig в терминале покажет нам что то подобное:
Как видим сетевой интерфейс успешно запущен и имеет статистику по трафику. Прежде чем сделать скриншот, я специально погонял данные по интерфейсу. Пользуюсь сделанными драйверами несколько месяцев, сбоев не наблюдалось. Но есть недоработки, которые еще не устранил. К ним вернусь позже, а пока работаю над приложениями по мере свободного времени.
Сильные стороны данного подхода заключаются в ряде аспектов. Приложения запущенные в операционной системе имеют полноценный доступ к шине и через неё же взаимодействуют друг с другом. Допустим в комплектации моего автомобиля отсутствует CD-чейнджер. Мне достаточно написать приложение эмулирующее это устройство. При этом оно будет воспроизводить различные форматы файлов и онлайн радио. Затем я захочу доукомплектовать телефонным модулем, которого у меня нет или не нравиться штатный. Я просто напишу ещё программку, которая по блютуз подключится к смартфону и выполнит ввод-вывод голоса и информации в штатные места. Или создать что-нибудь свое, например игра световыми приборами e-light. Таким образом приложения разрабатываются независимо друг от друга, могут устанавливаться и удаляться по желанию владельца.
На рисунке ниже показана работа программ ibusdump и ibussend. Что делают эти команды, думаю понятно из названия. Последние две строчки ibusdump показывают, что по шине передавались сообщения, которые я отправил через ibussend.
На этом остановлюсь, пожалуй. О том, что передаётся в полезной нагрузке кадра и для каких блоков управления я расскажу в другой раз.
BMW IBUS Interface
This is my 6th Version of the IBUS USB Interface.
With this interface you can connect any aftermarket Android radio to your BMW and
• display boardmonitor data
• control special lights and comfort functions
• display graphic PDC on the radio
• tons of other coding functions in the BMW with a special Android App.
It also works with Navcoder, if you like to reprogram your existing BMW Navigation system.
The interface works plug & play on any Android device (radio/tablet/handy)
OS-version 4.4 or later.
No drivers needed!
This interface is discontinued and won’t be built and sold anymore.
There will be a new and enhanced version by the end of March.
Stay tuned!
This interface enables your Android device to send and receive data from the BMW.
However, it does absolutely nothing on its own.
To make use of this interface in your car, you need the I-BUS App installed on your Android radio.
Please visit the IBUS-App site first, and read the FAQ of the IBUS-App as well.
I’m not selling the stuff myself anymore.
So please!! Do not contact me about delivery and order status.