Вспомнил, как в 2017м разбирал пакеты от ЭБУ F3R на москвиче. Тоже все оказалось не сложно, т.к. был софт DDT2000 и там в ini-файлах были все битовые расшифровки.
Из проблем - инициализация обмена должна была проходить на скорости в 5 бод (Карл!!).
Еще раз внимательно посмотрел обмен и описание на контроллер ST7565 и увидел следующее:
Для верхних строк приходят команды в формате 0xB0 0x10 0x05, а для нижних строк 0xB0 0x12 0x05, но в описании контроллера указывается, что второй и третий байт – это Most significant column address и Least significant column address соответственно.
Получается, что для верхних строк указатель приходит на 5-й столбец, а для нижних на 37-й. Запомним это.
Далее все числа следует считать в HEX:
После основного кадра приходят:
B0 10 00 (столбец 0) и B0 12 00 (столбец 32), затем 5 нулевых байт данных для обеих половин, затем не меняя строки
1D 05 (столбец 213) и 1F 05 (столбец 245) и затем 11 нулевых байт.
B1 10 00 и B1 12 00, затем 5 нулевых байт данных для обеих половин, затем не меняя строки
1D 05 и 1F 05 и затем 11 нулевых байт
,,,
9я посылка идет
B8 10 и B8 12, а затем 224 нулевых байт
В настройках верхняя часть экрана настраивается:
A2 A0 C0 E4 28 E1 40 A6 EE AF
Нижняя часть экрана:
A2 A1 C8 E4 28 E1 40 A6 EE AF
Расшифруем:
A2 – Sets the LCD drive voltage bias ratio 1/9 bias
A0/A1 – Sets the display RAM address SEG output correspondence 0: normal, 1: reverse
С0/С8 – Select COM output scan direction 0: normal direction 8: reverse direction
E4 – Oscillation Frequency Select Typical 31.4 KHz
28 – Power Control Set, voltage follower turns off, voltage regulator turns off,voltage booster turns off
E1 – Test Command – это какая-то специфичная команда, которой нет в NT7534
40 – Display Start Line Set. Specifies RAM display line for COM0
A6 – RAM Data “H” LCD ON voltage (normal)
EE – Cancels Read-Modify-Write mode and returns column address to the original address
AF – Display ON
Получается, что контроллер очень похож на NT7534, кроме одной команды.
Физический размер экрана 218x138 пикселей.
Максимально адресуемый, по протоколу, размер экрана 224x128 (или 224x144 если учитывать адресацию дополнительных строк через B8 – Page8)
Ощущение, что адресация фейковая и сделана так, что при прямом обращении по номеру столбцов, запись идет по маске 0b000X_XXXX, а при обращении к нижней половине (инверсия по столбцам) 0b001X_XXXX. где единичка сделана как индикатор инверсии, так как реальный кадр всегда начинается с 0x05 или 0x15
Да, первая мысль была - гнать битовый поток по какому-то uart, а дальше декодировать/оцифровывать на ПК, но:
Для отображения данных с HDMI на матрице экрана (через LVDS) используется плата на специализированной микросхеме RTD2662 (она используется, в так называемом "народном" китайском контроллере, так называемая плата скаляр).
Этот контроллер умеет переключаться между различными видеовходами - AV/VGA/HDMI. Переключаться планирую с кнопок руля (тут тоже придется ловить данные с can) шины.
Подумал, что зачем городить лишний мост на CarPC (да когда я его ещё соберу), когда можно напрямую гнать картинку на монитор. В теории это будет надёжней. Даже если не будет CarPC, то информация с бортового компьютера будет доступна.
Вкратце: чтобы не разбирать все-все возможные комбинации системных пакетов на can шине, я решил просто грабить картинку напрямую с выводов штатного экрана, который всю полезную информацию уже выводит. А передавать эту картинку в виде видеосигнала на цветной монитор, у которого можно переключать входы: в данном случае между выводом сграбленной информации с родного экрана, камерой заднего вида и CarPC
Не, "приключение на 20 минут" - это шуточная фраза из "Рик и Морти", когда они отправились по-быстрому на 20 минут - туда и обратно, а вернулись изученными через несколько недель.)))
Честно говоря, мне не понятная данная претензия. Если ко времени, то да, действительно - я это сделал по вечерам за неделю, а потом ещё около 6 часов в выходной писал статью и делал скриншоты. Из работы других людей - только тест модуля для вывода CVBS, но и его я переписал (ну да, по аналогии). Если мы не берём в расчет используемые разработанные САПРы, разработанную готовую отладочную плату циклона, разработку ЛА/осциллографа и т.п, то по времени все верно.
Упомянутое сообщество про анализ CAN шины вдохновило на эту деятельность, сам с CAN шиной в астре я не работал.
Мне не попадались готовые проекты с такой реализацией на Астру/Вектру. Но с учетом того, что есть проекты подобного шлюза на другие авто, то при поверхностной оценке, считаю задачу выполнимой. Когда буду разрабатывать модули для перехвата "индикации включения задней передачи" (для автоматического переключения на камеру заднего вида) или "нажатия кнопок на руле" (для мультимедиа) с CAN-шины, то оценю весь обмен.
Отличный виртуальный ассистент)))
Вспомнил, как в 2017м разбирал пакеты от ЭБУ F3R на москвиче. Тоже все оказалось не сложно, т.к. был софт DDT2000 и там в ini-файлах были все битовые расшифровки.
Из проблем - инициализация обмена должна была проходить на скорости в 5 бод (Карл!!).
Планирую собрать на Radxa X4 (на intel n100). очень малый размер. Есть ещё интересные модули, вроде LattePanda Mu x86, но цена кусается.
Циклон у меня на китайской отладке. В данный момент продумываю компоновки своей платы, чтобы можно было подключить родную плату GID через шлейфы.
UPD: В 9 посылке:
B8 10 00 и B8 12 00, а затем 224 нулевых байт
Я просто душный )
К сожалению, нет, но если во время поиска информации по CAN случайно попадется информация - я обязательно тегну.
Дополнительно:
Еще раз внимательно посмотрел обмен и описание на контроллер ST7565 и увидел следующее:
Для верхних строк приходят команды в формате 0xB0 0x10 0x05, а для нижних строк 0xB0 0x12 0x05, но в описании контроллера указывается, что второй и третий байт – это Most significant column address и Least significant column address соответственно.
Получается, что для верхних строк указатель приходит на 5-й столбец, а для нижних на 37-й. Запомним это.
Далее все числа следует считать в HEX:
После основного кадра приходят:
B0 10 00 (столбец 0) и B0 12 00 (столбец 32), затем 5 нулевых байт данных для обеих половин, затем не меняя строки
1D 05 (столбец 213) и 1F 05 (столбец 245) и затем 11 нулевых байт.
B1 10 00 и B1 12 00, затем 5 нулевых байт данных для обеих половин, затем не меняя строки
1D 05 и 1F 05 и затем 11 нулевых байт
,,,
9я посылка идет
B8 10 и B8 12, а затем 224 нулевых байт
В настройках верхняя часть экрана настраивается:
A2 A0 C0 E4 28 E1 40 A6 EE AF
Нижняя часть экрана:
A2 A1 C8 E4 28 E1 40 A6 EE AF
Расшифруем:
A2 – Sets the LCD drive voltage bias ratio 1/9 bias
A0/A1 – Sets the display RAM address SEG output correspondence 0: normal, 1: reverse
С0/С8 – Select COM output scan direction 0: normal direction 8: reverse direction
E4 – Oscillation Frequency Select Typical 31.4 KHz
28 – Power Control Set, voltage follower turns off, voltage regulator turns off,voltage booster turns off
E1 – Test Command – это какая-то специфичная команда, которой нет в NT7534
40 – Display Start Line Set. Specifies RAM display line for COM0
A6 – RAM Data “H” LCD ON voltage (normal)
EE – Cancels Read-Modify-Write mode and returns column address to the original address
AF – Display ON
Получается, что контроллер очень похож на NT7534, кроме одной команды.
Физический размер экрана 218x138 пикселей.
Максимально адресуемый, по протоколу, размер экрана 224x128 (или 224x144 если учитывать адресацию дополнительных строк через B8 – Page8)
Ощущение, что адресация фейковая и сделана так, что при прямом обращении по номеру столбцов, запись идет по маске 0b000X_XXXX, а при обращении к нижней половине (инверсия по столбцам) 0b001X_XXXX. где единичка сделана как индикатор инверсии, так как реальный кадр всегда начинается с 0x05 или 0x15
Да, первая мысль была - гнать битовый поток по какому-то uart, а дальше декодировать/оцифровывать на ПК, но:
Для отображения данных с HDMI на матрице экрана (через LVDS) используется плата на специализированной микросхеме RTD2662 (она используется, в так называемом "народном" китайском контроллере, так называемая плата скаляр).
Этот контроллер умеет переключаться между различными видеовходами - AV/VGA/HDMI. Переключаться планирую с кнопок руля (тут тоже придется ловить данные с can) шины.
Подумал, что зачем городить лишний мост на CarPC (да когда я его ещё соберу), когда можно напрямую гнать картинку на монитор. В теории это будет надёжней. Даже если не будет CarPC, то информация с бортового компьютера будет доступна.
Вкратце: чтобы не разбирать все-все возможные комбинации системных пакетов на can шине, я решил просто грабить картинку напрямую с выводов штатного экрана, который всю полезную информацию уже выводит. А передавать эту картинку в виде видеосигнала на цветной монитор, у которого можно переключать входы: в данном случае между выводом сграбленной информации с родного экрана, камерой заднего вида и CarPC
Не, "приключение на 20 минут" - это шуточная фраза из "Рик и Морти", когда они отправились по-быстрому на 20 минут - туда и обратно, а вернулись изученными через несколько недель.)))
Думаю, что тут тоже будет "веселье"
Честно говоря, мне не понятная данная претензия. Если ко времени, то да, действительно - я это сделал по вечерам за неделю, а потом ещё около 6 часов в выходной писал статью и делал скриншоты. Из работы других людей - только тест модуля для вывода CVBS, но и его я переписал (ну да, по аналогии). Если мы не берём в расчет используемые разработанные САПРы, разработанную готовую отладочную плату циклона, разработку ЛА/осциллографа и т.п, то по времени все верно.
Упомянутое сообщество про анализ CAN шины вдохновило на эту деятельность, сам с CAN шиной в астре я не работал.
Спасибо. Сам я никак до CAN шины не доберусь, нужно тоже спаять CanHacker. Думаю, что это тоже будет "приключение на 20 минут" )
Я сидел в сообществе в режиме "ReadOnly" и тоже с восхищением наблюдал за процессом
Да, оно. Это вырезка из большого списка id пакетов. Есть таблицы по всем шинам LS/MS/HS
Как пример от того-же автора https://github.com/JJToB/Car-CAN-Message-DB/blob/master/Opel/Astra/H/LS-CAN/ALL_TYPES.md
Сообщество собирает данные в большие таблицы.
Мне не попадались готовые проекты с такой реализацией на Астру/Вектру. Но с учетом того, что есть проекты подобного шлюза на другие авто, то при поверхностной оценке, считаю задачу выполнимой. Когда буду разрабатывать модули для перехвата "индикации включения задней передачи" (для автоматического переключения на камеру заднего вида) или "нажатия кнопок на руле" (для мультимедиа) с CAN-шины, то оценю весь обмен.
Ракурс съемки. Рамка не очень удачная, экран слишком утоплен. Буду моделировать рамку, в т.ч. менять наклон экрана
Спасибо!
Большое спасибо за статью, очень пригодилась.
Пробовал в 623 строке, как у вас делать импульс длительностью 2,35мкс - 120 тактов (при 50МГц)
21'd1990400: temp_sync_1 <= 1'b0;21'd1990520: temp_sync_1 <= 1'b1;и 4,7мкс, как по стандарту - разницы в отображении не было.
Искал что не так, когда поймал баг, который я так и не смог решить:
Если попытаться вывести чередуя строки белая-черная-белая, то вместо чередующихся строк - будет мерцание экрана.
Возможно это проблема конкретно на моем контроллере с видеовходом, но похоже что происходит восприятие по формату как на картинке:
И когда дошел до 623 строки, подумал что все, баг найден, но баг не ушел)
В целом, можно, но сейчас уже продаются кейкапы для таких свичей. По гравировке, меня не сильно устроило качество полученного результата.
Эти магические числа формируются в соответствии со стандартом usb
в конце статьи в UPD есть ссылка на гит, там в архиве Soft весь проект CubeMX+Keil
Cube лучше не настраивать, при пересборке проекта, все изменения в usb перетираются.
в usbd_hid.c:
USBD_ClassTypeDef USBD_HID =
{
USBD_HID_Init,
USBD_HID_DeInit,
USBD_HID_Setup,
NULL, /EP0_TxSent/
NULL, /EP0_RxReady/
USBD_HID_DataIn, /DataIn/
USBD_HID_DataOut, /DataOut/
NULL, /*SOF */
NULL,
NULL,
USBD_HID_GetHSCfgDesc,
USBD_HID_GetFSCfgDesc,
USBD_HID_GetOtherSpeedCfgDesc,
USBD_HID_GetDeviceQualifierDesc,
};