Приус 20 монитор андроид

Медиасистема для Toyota Prius (рестайл)

Эта первая (вводная) статья серии о том, как я собираюсь доработать медиасистему автомобиля. Сам проект в процессе, времени, как и у всех — нет, поэтому, дорогие читатели, запаситесь терпением, ибо часто клепать статьи не обещаю.

А началось все с того, что у меня появился Prius.

И первое, что бросилось в глаза — проблемы с обновлением навигации. Следующее — весьма скудные, но местами необходимые возможности устройства с названием «Многофункциональный дисплей» (в простонародье — голова). И это на фоне огромного количества китайских радио с Android на борту, и множеством приятностей. Но их установка на штатное место подразумевает лишение таких «плюшек», как диаграмма распределения энергии и управление климатом.

Родилась идея как-то соединить Android магнитолу с автомобилем более плотно, чем предлагают братья-китайцы. Об этом и статья.

Исходная ситуация

Итак. На борту имеется около 7-дюймовый дисплей с резистивным тач-скрином, соединенный с прочей электроникой линиями TX+ и TX-. И таких пар от головы идет аж 3. В схеме это чудо поименовано AVC-LAN, и выглядит следующим образом:

Часть 1: Осматриваемся внутри

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

Убрав все лишнее, получим примерно следующую блок-схему устройств:

Размышления

Была мысль просто заменить блок навигации на что-нибудь андроидное, однако она угасла, когда я глубже разобрался, как они общаются с головой. Помимо AVC-LAN эти модули соединены так же линией GVIF (Gigabit Video InterFace), причем этот самый фэйс у производителей конвертеров может случайно треснуть, если еще и я куплю преобразователь видеосигнала в GVIF за более, чем 100 долл. «Жить без лица — быть может трудно, но..» — прозвучало в голове на мотив известной песни, и решение мне не понравилось.

Встречались в сети решения с установкой китайской магнитолы вместо радиоресивера. Это меня не устроило тем, что два дисплея — необоснованная избыточность. Имхо.

Решение

Родилось следующее решение: заменить целиком голову, и доработать андроид-магнитолу, подружив ее с Prius-ом, для чего:

1. Разработать аппаратный конвертер USB AVC-LAN
2. Разработать firmware к нему, чтобы он подключался, как USB-HID.
3. Сделать его composite, чтобы одна из функций детектировалась, как обычная аппаратная клавиатура (с целью использовать в качестве нативного управления с кнопок на панели)
4. Разработать Android-приложение с функционалом, аналогичным (или превосходящим) родной, приусовский
5. Согласовать работу задней камеры
6. Решить задачи по механической части (установка на штатное место)

В процессе предстит разработать еще одно приложение для андроид — обыкновенный снифер, чтобы удобнее было реверсить пакеты по AVC-LAN. Заодно и потренироваться.

Выглядеть это все должно следующим образом:

В качестве аппаратной основы было решено использовать обучающую плату на SM32F103:

заказанную с AliExpress за $2.05.

Чем она мне нравится:

• Аппаратный модуль USB(Device) на борту у процессора
• Адекватный USB-стек от производителя (в отличие от Freescale-овского, не к ночи будь помянут).
• Свободные порты GPIO, которые можно использовать для подключения штатных кнопок по бокам монитора. Возможно, это позволит скрыть под панелью аппаратные кнопки магнитолы. Я пока не знаю, какой она будет
• И на нее можно навесить конвертер AVC-LAN в логические уровни

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

В любом случае, статей планируется несколько, в разных хабах. Проект получается уж сильно FullStack — от аппаратного подключения до андроид-приложения.

Часть 2: USB, HID, дескрипторы, и все, чтобы получить пилотный прототип

Первым этапом я хотел получить связку устройства и телефона, причем чтобы устройство могло передать пакет на телефон, а тот — отобразить его в приложении.
Как говорил Гагарин: Поехали!

USB HID Composite device на STM32

За что я решил взяться — это адаптировать пример от ST моим задачам, и получить USB устройство, которое опознается хостом, как составное из клавиатуры и «чего-то еще» — RAW HID Device. Первое, как я уже говорил, предназначено для нативного управления андроидом, второе — для прямого обмена AVC-LAN пакетами с программой на устройстве.

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

USB, Composite, HID

Буквально несколько слов на эту тему. Предполагается, что Вы более или менее знакомы со стандартом USB. Если нет — лучше сначала ознакомится и поэкспериментировать с примерами из CubeMX.

Стек USB от STM и пример реализации мыши. Там у нас настроены какие-то дескрипторы и функциональная конечная точка. Это помимо пары 0x00 и 0x80 для управления устройством целиком.

Для реализации моего проекта требуется, чтобы конечная точка клавиатуры была двунаправленной (не знаю, зачем — пригодится) и еще пара конечных точек, которые будут использованы для обмена данными со второй — RAW — функцией. Добавляем их.

Делаем точку двунаправленной, добавляя в дескриптор точку OUT:

При правке дескриптора следите за индексами и размерами.
(2c5cf968121f0d8fa43a6755c09e15ef3a317791):

И добавляем еще пару точек:

Это был дескриптор конфигурации. Теперь хост будет уверен, что у нас есть некое составное HID-устройство, и во все эти точки можно слать данные. Но это пока не так.
Для того, чтобы это стало правдой:

1. В нашем контроллере есть специально выделенный кусочек памяти, который тактируется вместе с модулями CAN и USB. Учитывая, что модуль USB самостоятельно занимается процессом приема/передачи пакета данных, нужно задать ему буферы в этом кусочке памяти для каждой отдельно взятой конечной точки:

Адреса буферов произвольные, лишь бы не пересекались.

Почему-то стек от ST написан из расчета, что в устройстве будет не более одной двунаправленной конечной точки, потому чуть дорабатываем стек:

Передача

Процедуру USBD_HID_SendReport переименовываем в USBD_HID_SendReportEP, добавляя еще один параметр — номер конечной точки. Процедуру со старым именем оставляем для обратной совместимости, но в теле вызываем USBD_HID_SendReportEP с константой в виде конечной точки. Решение пока не самое эстетичное, но для эксперимента сойдет, и даже если и останется — конкретному проекту это жить мешать не будет.

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

Финализация

Порядка ради ищем по проекту и вызываем USBD_LL_CloseEP еще раз, но для вновь созданных конечных точек.

Прием

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

У меня в коде получилась вот такая вот некрасивая каракатица:

Т.е. я исходил из того, что номера конечных точек идут подряд. Это плохо, имхо. Не делайте так. Впрочем, и как ST тоже не делайте.

Дальше остается только сходить в файл usbd_hid.c, а конкретно в функцию USBD_HID_DataOut, и позаботится о том, чтобы вызов обработчика принятых данных соответствовал вашим личным представлениям о прекрасном. У меня получилось тоже не очень, поэтому код и описание получатся длинными и непонятными. Проще сделать самому.

Репорт

Все, в этом месте мы получили композитное устройство, которое способно обмениваться данными через две двунаправленные точки. Последним штрихом «затыкаем» любопытство драйверу HID, описывая такой вот дескриптор репорта:

Этот репорт говорит HID-драйверу: тут будут какие-то 31 байт данных. Не нужно разбираться, что за они — просто отдай их открывшей это устройство программе. В физическом репорте нулевой байт будет равен индексу репорта (REPORT_ID (2)). Соответственно, всего придет 32 байта.

Источник

Медиасистема для Toyota Prius (рестайл)

Эта первая (вводная) статья серии о том, как я собираюсь доработать медиасистему автомобиля. Сам проект в процессе, времени, как и у всех — нет, поэтому, дорогие читатели, запаситесь терпением, ибо часто клепать статьи не обещаю.

А началось все с того, что у меня появился Prius.

И первое, что бросилось в глаза — проблемы с обновлением навигации. Следующее — весьма скудные, но местами необходимые возможности устройства с названием «Многофункциональный дисплей» (в простонародье — голова). И это на фоне огромного количества китайских радио с Android на борту, и множеством приятностей. Но их установка на штатное место подразумевает лишение таких «плюшек», как диаграмма распределения энергии и управление климатом.

Родилась идея как-то соединить Android магнитолу с автомобилем более плотно, чем предлагают братья-китайцы. Об этом и статья.

Исходная ситуация

Итак. На борту имеется около 7-дюймовый дисплей с резистивным тач-скрином, соединенный с прочей электроникой линиями TX+ и TX-. И таких пар от головы идет аж 3. В схеме это чудо поименовано AVC-LAN, и выглядит следующим образом:

Часть 1: Осматриваемся внутри

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

Убрав все лишнее, получим примерно следующую блок-схему устройств:

Размышления

Была мысль просто заменить блок навигации на что-нибудь андроидное, однако она угасла, когда я глубже разобрался, как они общаются с головой. Помимо AVC-LAN эти модули соединены так же линией GVIF (Gigabit Video InterFace), причем этот самый фэйс у производителей конвертеров может случайно треснуть, если еще и я куплю преобразователь видеосигнала в GVIF за более, чем 100 долл. «Жить без лица — быть может трудно, но..» — прозвучало в голове на мотив известной песни, и решение мне не понравилось.

Встречались в сети решения с установкой китайской магнитолы вместо радиоресивера. Это меня не устроило тем, что два дисплея — необоснованная избыточность. Имхо.

Решение

Родилось следующее решение: заменить целиком голову, и доработать андроид-магнитолу, подружив ее с Prius-ом, для чего:

1. Разработать аппаратный конвертер USB AVC-LAN
2. Разработать firmware к нему, чтобы он подключался, как USB-HID.
3. Сделать его composite, чтобы одна из функций детектировалась, как обычная аппаратная клавиатура (с целью использовать в качестве нативного управления с кнопок на панели)
4. Разработать Android-приложение с функционалом, аналогичным (или превосходящим) родной, приусовский
5. Согласовать работу задней камеры
6. Решить задачи по механической части (установка на штатное место)

В процессе предстит разработать еще одно приложение для андроид — обыкновенный снифер, чтобы удобнее было реверсить пакеты по AVC-LAN. Заодно и потренироваться.

Выглядеть это все должно следующим образом:

В качестве аппаратной основы было решено использовать обучающую плату на SM32F103:

заказанную с AliExpress за $2.05.

Чем она мне нравится:

• Аппаратный модуль USB(Device) на борту у процессора
• Адекватный USB-стек от производителя (в отличие от Freescale-овского, не к ночи будь помянут).
• Свободные порты GPIO, которые можно использовать для подключения штатных кнопок по бокам монитора. Возможно, это позволит скрыть под панелью аппаратные кнопки магнитолы. Я пока не знаю, какой она будет
• И на нее можно навесить конвертер AVC-LAN в логические уровни

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

В любом случае, статей планируется несколько, в разных хабах. Проект получается уж сильно FullStack — от аппаратного подключения до андроид-приложения.

Часть 2: USB, HID, дескрипторы, и все, чтобы получить пилотный прототип

Первым этапом я хотел получить связку устройства и телефона, причем чтобы устройство могло передать пакет на телефон, а тот — отобразить его в приложении.
Как говорил Гагарин: Поехали!

USB HID Composite device на STM32

За что я решил взяться — это адаптировать пример от ST моим задачам, и получить USB устройство, которое опознается хостом, как составное из клавиатуры и «чего-то еще» — RAW HID Device. Первое, как я уже говорил, предназначено для нативного управления андроидом, второе — для прямого обмена AVC-LAN пакетами с программой на устройстве.

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

USB, Composite, HID

Буквально несколько слов на эту тему. Предполагается, что Вы более или менее знакомы со стандартом USB. Если нет — лучше сначала ознакомится и поэкспериментировать с примерами из CubeMX.

Стек USB от STM и пример реализации мыши. Там у нас настроены какие-то дескрипторы и функциональная конечная точка. Это помимо пары 0x00 и 0x80 для управления устройством целиком.

Для реализации моего проекта требуется, чтобы конечная точка клавиатуры была двунаправленной (не знаю, зачем — пригодится) и еще пара конечных точек, которые будут использованы для обмена данными со второй — RAW — функцией. Добавляем их.

Делаем точку двунаправленной, добавляя в дескриптор точку OUT:

При правке дескриптора следите за индексами и размерами.
(2c5cf968121f0d8fa43a6755c09e15ef3a317791):

И добавляем еще пару точек:

Это был дескриптор конфигурации. Теперь хост будет уверен, что у нас есть некое составное HID-устройство, и во все эти точки можно слать данные. Но это пока не так.
Для того, чтобы это стало правдой:

1. В нашем контроллере есть специально выделенный кусочек памяти, который тактируется вместе с модулями CAN и USB. Учитывая, что модуль USB самостоятельно занимается процессом приема/передачи пакета данных, нужно задать ему буферы в этом кусочке памяти для каждой отдельно взятой конечной точки:

Адреса буферов произвольные, лишь бы не пересекались.

Почему-то стек от ST написан из расчета, что в устройстве будет не более одной двунаправленной конечной точки, потому чуть дорабатываем стек:

Передача

Процедуру USBD_HID_SendReport переименовываем в USBD_HID_SendReportEP, добавляя еще один параметр — номер конечной точки. Процедуру со старым именем оставляем для обратной совместимости, но в теле вызываем USBD_HID_SendReportEP с константой в виде конечной точки. Решение пока не самое эстетичное, но для эксперимента сойдет, и даже если и останется — конкретному проекту это жить мешать не будет.

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

Финализация

Порядка ради ищем по проекту и вызываем USBD_LL_CloseEP еще раз, но для вновь созданных конечных точек.

Прием

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

У меня в коде получилась вот такая вот некрасивая каракатица:

Т.е. я исходил из того, что номера конечных точек идут подряд. Это плохо, имхо. Не делайте так. Впрочем, и как ST тоже не делайте.

Дальше остается только сходить в файл usbd_hid.c, а конкретно в функцию USBD_HID_DataOut, и позаботится о том, чтобы вызов обработчика принятых данных соответствовал вашим личным представлениям о прекрасном. У меня получилось тоже не очень, поэтому код и описание получатся длинными и непонятными. Проще сделать самому.

Репорт

Все, в этом месте мы получили композитное устройство, которое способно обмениваться данными через две двунаправленные точки. Последним штрихом «затыкаем» любопытство драйверу HID, описывая такой вот дескриптор репорта:

Этот репорт говорит HID-драйверу: тут будут какие-то 31 байт данных. Не нужно разбираться, что за они — просто отдай их открывшей это устройство программе. В физическом репорте нулевой байт будет равен индексу репорта (REPORT_ID (2)). Соответственно, всего придет 32 байта.

Источник