Митя
Завсегдатай
- Регистрация
- 13 Сен 2016
- Сообщения
- 869
- Баллы
- 632
- Возраст
- 40
- Ф.И.О.
- Митя
- Авто
- БМВ 525i
В прошлой части мы узнали много нового, что такое FA, идентификаторы опций и каким образом всё это влияет на значения параметров в блоках управления.
В этой части мы поговорим о том, каким образом происходит кодирование, какие данные реально отправляются в блок управления, что такое вообще кодировочные файлы (индексы) и зачем они.
NETTODAT
Всякий раз, когда вы делаете чтение данных из блока управления, открывается блокнот Windows, в котором написаны какие-то непонятные строчки. Большинство тех, кто занимается кодированием, вообще не представляет, что это такое и зачем оно нужно. Просто закрывают окно и работают с файлами FSW_PSW.TRC и FSW_PSW.MAN.
Вот к примеру файл NETTODAT.TRC, который получается при чтении блока FLA с индексомFLA_E65.C05:
NETTODAT.TRC
Не очень понятно, да?
Файл NETTODAT.TRC отражает то, как сохранены данные в блоке управления. Память блока управления похожа на память компьютера или телефона, она точно также состоит из байтов, каждый из которых имеет свой адрес (порядковый номер). Даже обычный файл на вашем компьютере — отдельный кусочек памяти. Его можно открыть в шестнадцатиричном редакторе:
OS X 0xED
В левой колоночке у нас указан адрес первого байта в конкретной строчке. Адрес в данном случае указан относительно начала самого этого файла. По центру у нас, собственно, сами байты в hex-виде — двухзначное шестнадцатиричное число. А справа — текстовое отображение в заданной кодировке. Примерно такую же белиберду можно увидеть в текстовом редакторе, если в нём открыть этот файл. Память в блоке такого понятия как «файл» не имеет. Вся память сама по себе, грубо говоря, один большой такой файл, в котором лежит сразу всё.
Но если открытый в hex-редакторе файл представляет собой одну сплошную последовательность из байт, то файл NETTODAT.TRC описывает в текстовом виде только определённые участки памяти: по какому адресу какие данные лежат. Состоит он из строчек вида:
B XXXXXXXX,YYYY,ZZ, ZZ, ZZ, ZZ, …ZZ
Эта строка описывает последовательность из байт, их количество и адрес:
— XXXXXXXX — адрес нашей последовательности в hex-виде (шестнадцатиричном);
— YYYY — длина последовательности в том же hex-виде;
— ZZ, ZZ, …, ZZ — сами данные, те самые байты, через запятую. Количество этих ZZ соответствует указанной длине последовательности.
NB: Суффикс «h» в числах означает, что число представлено в шестнадцатиричном значении (hex-виде). В языках программирования применяется вариант с префиксом «0x», но здесь и далее будет использоваться «h».
Первая строчка в файле NETTODAT.TRC (см. скриншот вверху):
B 00300000,0010,17,00,03,00,00,00,00,00,00,00,00,00,00,00,00,00
Означает, что по адресу 00300000h, т. е. начиная с 3 145 728-го байта у нас идёт последовательность из 0010h байтов (16), ну и сами байты, содержащие значения параметров блока управления. Кстати говоря, ни в одном из блоков, которые я смотрел, первый блок с данными не начинался ранее 00300000h, т. е. первые три мегабайта памяти (3 145 728 байт) у всех блоков чем-то ещё заняты.
В строчке выше мы видим последовательность байтов: 17,00,03,00,00,00,00,00,00,00,00,00,00,00,00,00. Мы знаем, что первый байт (17h) этой последовательности находится по адресу 00300000h. Следующий байт (00h), очевидно, имеет адрес 00300001h. Адреса всех байтов можно разложить в столбик:
00300000: 17,
00300001: 00,
00300002: 03,
00300003: 00,
00300004: 00,
00300005: 00,
00300006: 00,
00300007: 00,
00300008: 00,
00300009: 00,
0030000A: 00,
0030000B: 00,
0030000C: 00,
0030000D: 00,
0030000E: 00,
0030000F: 00
А что дальше? Рассмотрим следующую строку:
B 00300100,0010,04,01,00,03,04,09,18,1A,00,00,00,00,00,00,00,00
Опа, а здесь первый байт имеет адрес уже 00300100h, т. е. следующая последовательность начинается через 100h байт (256 байт) относительно начала первой. Первая строка описывает всего 16 байт, а что там идёт от 00300010h до 003000FFh-го байта — неизвестно. Зато во второй строке известно, какие данные содержат 16 байт памяти от 00300100h до 0030010Fh, ещё ниже очередные 16 байт от 00300200h до 0030020Fh. Таким образом, нам известно 48 байт данных.
Возникает вопрос, зачем у нас при этом так много неизвестных участков? Нельзя ли последовательно описать эти 48 байт без пропусков? Можно. Хотя блок FLA и использует всего по 16 байт в каждом таком блоке, такое разделение — функциональное/смысловое. На каждую группу параметров выделено 256 байт, этого должно быть достаточно для любой группы. Даже если сейчас нужно всего 16 байт, в будущем может потребоваться 20, 30 и т. д. Чтобы будущие изменения в одной группе не затронули другие, каждой выделяется заведомо достаточный кусок памяти для хранения параметров. Это — задел на будущее.
Если открыть более навороченный NETTODAT.TRC, полученный из CIC (индекс CIC.C1A), то данных там куда больше:
CIC.C1A NETTODAT.TRC
Здесь у нас в блоке в 256 байт описано 120 байт: последовательно 7 строчек по 16 байт и ещё одна строчка на 8 байт. Следующий блок стартует с уже привычных 00300100h.
NETTODAT и FSW_PSW
Теперь вы знаете, как устроен файл NETTODAT.TRC, знаете адрес каждого байта, но скорее всего ещё не понимаете, для чего всё это нужно и что с этим можно сделать. Пора приоткрыть завесу тайны.
Тот самый файл FSW_PSW.TRC, который получается при чтении блока является человеко-понятной интерпретацией NETTODAT.TRC. Т. е. из этих вот байтов собирается большой текстовый файл, который мы можем редактировать. А когда мы нажимаем кнопку кодирования, происходит обратный процесс, из текстового файла собираются байтики и записываются в блок. Никаких текстовых файлов в блоках управления не хранится, там лишь байты.
В процессе конвертации как раз участвуют те самые кодировочные файлы, а точнее индексы. Слово «индекс» следует интерпретировать как «каталог» или «оглавление» (это одно из определений слова index), а не как порядковый номер, хотя и это тоже подразумевается в некоторых случаях.
Что такое кодировочный индекс? Это файл-описание или файл-каталог. В нём хранится информация об адресах параметров, вариантах их значений, соответствующие им данные, условия применения и человеко-понятные названия.
Возьмём наш уже любимый STREETLAMP_COUNT из FLA_E65.C05. Примерно так хранится информация о параметрах:
…
Адрес: 00300107h
Параметр: STREETLAMP_COUNT
Длина: 01h байт
Маска: FFh
Варианты значений:
1) Название: wert_01;
Данные: 1Ah (26 в десятичном представлении);
Условие применения: !(!FLA_CI_05,FLA_CI_05+US)
2) Название: wert_02;
Данные: 40h (64);
Условие применения: !FLA_CI_05,FLA_CI_05+US
Адрес: 00300108h…
…
Всё это можно увидеть в NCS Dummy:
Дословно звучит так: по адресу 00300107h хранится значение параметра STREETLAMP_COUNT, значение имеет длину 1 байт и допустимы два значения: 1Ah и 40h, условия такие-то. Одно из двух значений будет выбрано если будут выполнены соответствующие условия, это мы уже знаем из прошлой части. Т. е. значения wert_01 или wert_02 меняют один единственный байт по адресу 00300107h в памяти блока.
Где этот байт находится в NETTODAT.TRC? А вот в этой строчке:
B 00300100,0010,04,01,00,03,04,09,18,1A,00,00,00,00,00,00,00,00
Как видите, выделенный байт имеет адрес 00300107h. 1A соответствует текстовому значениюwert_01. Если мы изменим в FSW_PSW значение параметра на wert_02, в блок вместо 1Aзапишется 40.
Таким образом, имея информацию из кодировочного индекса, мы можем конвертировать байты из NETTODAT.TRC вот в такой текст:
FSW_PSW.TRC
Это уже привычный нам текст. Конвертация работает в обе стороны, из байтов в текст и обратно.
Кодировочные индексы при кодировании «по умолчанию» (так называемый заводской профиль или просто пустой FSW_PSW.MAN) позволяют определить правильные значения всех параметров блока с учётом списка опций в автомобиле. Помимо этого, используя NCS Dummy, вы знаете, какие вообще значения доступны для каждого параметра.
NCS Dummy и trace-файлы
trace-файлы — это те самые файлы с расширением TRC и именами FSW_PSW (текстовая интерпретация) или NETTODAT (бинарный вид). Есть ещё другие трейсы, но сейчас мы ограничимся этими двумя.
После считывания FSW_PSW.TRC или NETTODAT.TRC, можно загрузить один из двух в NCS Dummy и работать с этим. Только для начала вам необходимо знать точный кодировочный индекс, который используется для чтения блока. Узнать его можно из окна NCS Expert сразу после нажатия кнопки Read ECU и завершения операции чтения (т. е. когда откроется блокнот с содержимым NETTODAT.TRC):
Окно NCS Expert после чтения ЭБУ (Read ECU)
Ага, для чтения использовался FLA_E65.C05. Следовательно, надо выбрать этот индекс в окне NCS Dummy, а затем загрузить trace-файл. Предусмотрены быстрые ссылки на соответствующие трейсы из папки C:\NCSEXPER\WORK\:
Загрузка
После загрузки простой список параметров и значений превратится в список с галочками:
Загружен FSW_PSW.TRC
Установленные галочки отражают текущие значения параметров. Можно переставить галочки на нужные значения и экспортировать сразу в FSW_PSW.MAN:
Экспорт в FSW_PSW.MAN
Весьма удобно, не правда ли? Сразу можно выполнить кодирование и получить результат. Но это скучная работа, это умеют все, кто хоть раз что-то кодировал.
NCS Dummy работает также и с NETTODAT-трейсом, можно загрузить и его и станет доступен экспорт в NETTODAT.MAN, который можно закодировать вместо FSW_PSW.MAN, хотя я не понимаю, почему эта функция недоступна при загрузке FSW_PSW. Для обычного кодирования такая процедура не очень нужна, поэтому о том, как выполнить NETTODAT-кодирование, я расскажу позднее. А сейчас мы вернёмся к кодировочному индексу.
Битовые маски
Наверное, это будет самая тяжелая и непонятная тема, но без понимания оной никак нельзя приступать к работе с NETTODAT.
Как я уже говорил, один байт — это число от 0 до 255, которое в двоичной системе описывается восемью битами. Каждый бит может иметь только два значения: 0 или 1. Одно и то же значение можно представить несколькими способами, в hex-виде (шестнадцатиричном) или binary-виде (двоичном), например число 37:
37 = 25h = 00100101b
NB: Суффикс «b» означает, что число представлено в бинарном (binary) виде.
Это всего лишь разные системы счисления (см. Википедию), которые представлют одно и то же число. Привычное нам десятичное представление, затем шестнадцатиричное и наконец двоичное. Каждый числовой знак в системе может иметь N значений, где N соответствует типу системы. Т. е. в десятичной числовой знак принимает значение от 0 до 9 (10 значений), в шестнадцатиричной от 0 до F (0-9 и от A до F, 16 значений) и в двоичной всего два: 0 или 1.
Конечно, в уме переводить из одной системы в другую весьма сложно, поэтому нам на помощь придёт встроенный в операционную систему калькулятор, который может работать в разных режимах: обычный, научный и режим для программистов. Последний режим нам как раз и понадобится. Я покажу калькулятор из системы Mac OS X, особой разницы с вариантом из Windows нет. Выглядит программерский калькулятор вот так:
OS X Calculator (Programmer mode)
Справа вверху можно увидеть кнопки переключения системы счисления: восьмеричный, десятичный и шестнадцатиричный. Одновременно с отображением числа на табло в выбранной системе, это же число всегда отображается в двоичном виде ниже. Для числа выделено 64 бита (8 байт), этого достаточно для представления весьма больших чисел, а мы с вами вообще не будем работать с числами длиннее 8 бит (т. е. не более 1 байта).
Зачем нам вообще все эти нолики, единички и прочая ересь? Всё дело в том, что программисты по натуре своей весьма ленивые и при этом экономные люди. Они не будут тратить целый байт на то, чтобы узнать, включена определённая функция или нет. Ну, во всяком случае так поступают только хорошие программисты
Так вот, для хранения значения типа вкл/выкл достаточного всего одного бита. А в одном байте их целых 8! Т. е. в один байт можно сохранить 8 выключателей различных функций. А если у нас что-то работает в одном из четырёх режимов, то для хранения номера режима достаточно двух бит:
(десятичная) = (двоичная)
0 = 00b
1 = 01b
2 = 10b
3 = 11b
Весьма экономно, не правда ли?
Допустим, у вас есть умный дом с блоком управления освещением. В доме шесть комнат, каждая из которых пронумерована, но по странному стечению обстоятельств не от единицы до 6, а от 0 до 5 включительно. Ну вот такой вот дом. При этом, в каждой комнате есть потолочная лампочка, но в комнатах 1 и 3 есть ещё и настольная. Наступил вечер, свет горит так:
Комната 0 = выкл
Комната 1 = верхняя выкл, настольная горит
Комната 2 = вкл
Комната 3 = горят обе лампы
Комната 4 = выкл
Комната 5 = вкл
Для четырёх комнат нам достаточно одного бита, чтобы сохранить состояние, включен свет или выключен. А вот для двух оставшихся нужно уже два бита. Разряды в числах у нас традиционно идут справа налево, т. е. самый младший разряд в числе — справа. В байте биты считаются также справа налево, т. е. самый крайний справа — нулевой (младший). Из двух бит пусть младший отвечает за потолочную лампу, а старший за настольную. Тогда для комнат биты будут такие:
Комната 0 = 0b
Комната 1 = 10b
Комната 2 = 1b
Комната 3 = 11b
Комната 4 = 0b
Комната 5 = 1b
Всё это можно слепить в целый байт, приняв комнату с номером 0 за самую младшую (справа):
1 0 11 1 10 0 = 10111100b = BCh
Если мы в комнате 1 зажгём ещё и верхний свет, то её биты 10 поменяются на 11:
1 0 11 1 11 0 = 10111110b = BEh
А если ещё выключим потолочную лампу в комнате №3, то:
1 0 10 1 11 0 = 10101110b = AEh
Получается, чтобы сохранить информацию о включенных лампах, нужно всего 8 бит или 1 байт. Последнее состояние соответствует числу AEh и оно у нас хранится в блоке управления освещением.
Калькулятор операционной системы позволяет наглядно «пощёлкать» битами:
Можно кликать на нолики и единички и они будут переключаться между собой, изменяя отображаемое на табло число.
Если бы блок управления освещением в доме разрабатывали в BMW, то NETTODAT такого блока управления при чтении текущего состояния выглядел бы так:
B 00300000,0001,AE
Вот такой вот короткий NETTODAT, один байт на весь свет в доме. Но как будет выглядеть текстовый трейс (FSW_PSW)? А вот так:
zimmer_0
nicht_aktiv
zimmer_1
alle_lampen
zimmer_2
aktiv
zimmer_3
tischlampe
zimmer_4
nicht_aktiv
zimmer_5
aktiv
Наверняка у вас сразу возникнет вопрос: как так, в трейсе 6 параметров, а в NETTODAT всего один байт? Очень просто. То самое свойство параметра «Маска» указывает нам на те биты в байте, в которых хранится значение параметра. Это позволяет на один байт завести от 1 до 8 параметров.
Поэтому маски для перечисленных выше параметров будут такие:
zimmer0: 00000001b = 01h (нулевой бит указывает на свет в комнате 0)
zimmer1: 00000110b = 06h (биты 1 и 2 указывают на лампы в комнате 1)
zimmer2: 00001000b = 08h (бит 3 указывает на свет в комнате 2)
zimmer3: 00110000b = 30h (биты 4 и 5 указывают на лампы в комнате 3)
zimmer4: 01000000b = 40h (бит 6 указывает на свет в комнате 4)
zimmer5: 10000000b = 80h (бит 7 указывает на свет в комнате 5)
Шестнадцатиричные значения вы можете самостоятельно получить, «накликав» соответствующие единички и нолики в калькуляторе.
Если на значение параметра отводится целиком один байт (например всё тот жеSTREETLAMP_COUNT), то маска для такого параметра равна 11111111b = FFh, т. е. мы отметили маской все доступные биты в байте. Если же на значение выделяется даже более одного байта, то маска всегда будет FFh, ввиду того, что она сама по себе занимает всего один байт и не в состоянии описывать биты в следующем байте. Это ограничение системы.
Маска и данные
Помимо маски у каждого значения параметра есть свойство «Данные» («Data» в NCS Dummy). Это именно то значение, те биты, которые будут записаны в блок, если будет выбрано это значение. Для наших комнат с одной лампой доступны такие варианты:
aktiv: 1b = 01h
nicht_aktiv: 0b = 00h
А для комнат с двумя лампами такие:
nicht_aktiv: 00b = 00h (всё выключено)
aktiv: 01b = 01h (включена потолочная лампа)
tischlampe: 10b = 02h (включена настольная лампа)
alle_lampen: 11b = 03h (включены обе лампы)
Количество бит, которое отводится для значения, ограничено маской. Если в маске подряд отмечены 3 бита, значит мы можем задать всего 7 разных значений, от 000b до 111b:
000b = 00h
001b = 01h
010b = 02h
011b = 03h
100b = 04h
101b = 05h
110b = 06h
111b = 07h
Обратите внимание, что данные для этих значений не зависят от того, в каком месте байта в памяти находятся выделенные под них биты. Просто мы берём отмеченные маской биты и прям в них вписываем значение. Пример:
Маска: 0Ch (00h . . 03h) = 00001100b (00b . . 11b)
Значение: 02h = 10b
Будет записано: xxxx10xxb
Где «x» — остальные биты от других значений параметров. Ещё пример:
Маска: F0h (00h . . 0Fh) = 11110000b (0000b . . 1111b)
Значение: 0Ah = 1010b
Будет записано: 1010xxxxb
Оба этих примера зададут в одном байте следующие биты:
101010xxb
Оставшиеся биты «x» с номерами 0 и 1 пойдут ещё на какой-нибудь параметр.
Возьмём теперь живой пример из NCS Dummy, всё тот же FLA_E65.C05:
Параметр TYP_FRONTSCHEIBE_FLA (тип ветрового стекла, климакомфорт или обычное) имеет адрес 00300100h, длина 1 байт, маска 04h. По умолчанию NCS Dummy показывает маски в hex-виде, но куда более понятен двоичный режим, который можно выбрать, кликнув правой кнопкой мыши по кнопке HEX-DEC:
Binary Mask
И тут мы видим, что третий справа бит в байте отвечает за то, какое у нас стекло. И варианты данных там либо 0 (обычное стекло), либо 1 (климакомфорт). В скобках справа от маски указан диапазон допустимых значений для неё. Т. к. маска тут всего один бит, то и значений всего два: 0 или 1.
Есть ли у нас параметры-соседи по байту? Есть: TYP_LENKUNG (тип рулевого управления) иVILLAGE_TYP (режим поведения распознавания города) находятся в том же байте по адресу 00300100h, но имееют маски 00000001b и 00010000b соответственно:
TYP_LENKUNG
VILLAGE_TYP
Стало быть, в байте по адресу 00300100h у нас есть три параметра, которые задают значения в битах 0 (TYP_LENKUNG), 3 (TYP_FRONTSCHEIBE_FLA) и 5 (VILLAGE_TYP) (исходя из нумерации справа налево).
В нашем уже изъезженном вдоль и поперёк NETTODAT.TRC байт по адресу 00300100h является первым во второй строке:
B 00300100,0010,04,01,00,03,04,09,18,1A,00,00,00,00,00,00,00,00
Разложим его на биты:
04 = 00000100b
Итого у нас справа налево TYP_LENKUNG = 0b (linkslenker, левый руль),TYP_FRONTSCHEIBE_FLA = 1b (klimakomfort, климатическое стекло) и VILLAGE_TYP = 0b (wert_01, Европа).
Остальные биты в этом байте помечены как UNBELEGT — незанятые биты или байты. Например, крайние слева незанятые три бита:
UNBELEGT
Адрес байта тот же, отмечены в маске три крайних бита (с диапазоном записи от 000b до 111b), но записаны туда нолики. Никаких иных вариантов кроме записи ноликов туда не предусмотрено. Остальные биты между известными параметрами также вынесены в UNBELEGT-параметры. Если вместо NETTODAT.TRC загрузить FSW_PSW.TRC, строчки с UNBELEGT-параметрами исчезнут, т. к. при работе с FSW_PSW незанятые параметры не отражены в нём.
Закономерность следования параметров простая: по байтам мы движемся слева направо, а по битам справа налево, от младшего к старшему.
Другой пример, параметр VERTIKAL_BILD_OFFSET (программный угол наклона камеры FLA, см.пост по теме):
VERTIKAL_BILD_OFFSET
Маска у него 01111111b, т. е. семь бит из байта по адресу 00300102h задают угол наклона. Диапазон, стало быть, от 0000000b до 1111111b или от 00h до 7Fh в hex-виде, или в десятичном от 0 до 127 включительно. В описании к параметру сказано, что угол в градусах считается по формуле ANGLE_º=DATA/10, т. е. мы делим заданное число на 10 и получаем угол в градусах. Так, выделенное на скриншоте значение wert_06 соответствует данным 00001100b или 0Ch, или 12 в десятичном представлении. Переключаться между представлении поможет кнопка HEX-DEС. Поделив 12 на 10, получим 1,2º. Максимальное же значение у нас 127, что соответствует углу 12,7º, который, тем не менее, вряд ли достижим программным способом.
Помимо угла у нас есть ещё параметр, отвечающий за знак, т. е. в какую сторону от вертикали мы отклоняем камеру. Параметр называется RICHTUNG_BILD_OFFSET:
RICHTUNG_BILD_OFFSET
Маска у него 10000000b, это восьмой бит из того же байта, в котором записан сам угол. Значение может быть соответственно 0 (+, вверх) или 1 (-, вниз). Стало быть, в одном байте по адресу 00300102h записаны два параметра: угол и знак. Заняты все 8 бит, поэтому рядом нет никаких UNBELEGT-параметров. В моём случае по этому адресу записано 00h:
B 00300100,0010,04,01,00,03,04,09,18,1A,00,00,00,00,00,00,00,00
Т. е. программный угол равен +0º. Всё потому что на Южанке угол наклона камеры FLA задаётся физически и программная коррекция не нужна.
Любопытны строчки по этим параметрам из файла-исходника кодировочного индекса:
FLA_E65.C05 source
Тут всё наглядно видно: адрес, название параметра, маска, варианты названий значений и данных, которые им соответствуют. А самое ценное — комментарии разработчика. Исходные файлы индексов в свободном доступе не найти, не в последнюю очередь потому что в этих же файлах описаны и те области памяти, которые кодируются исключительно на заводе и не подлежат кодированию через NCS Expert.
* * *
Кстати, обратите внимание на изменяющийся цвет фона в списке параметров. Цветом выделяется группа параметров, причём сама группа имет даже название:
AUTOPARAMETER
Группа, как мы видим, тоже имеет адрес и длину, в данном случае выделено 16 байт по адресу 00300100h. Это как раз вся вторая строчка из NETTODAT.TRC!
Стало быть, блоки по 256 байт, о которых я писал в начале статьи, выделены на группы параметров. Но группа не обязана занимать сразу все 256 байт, можно и меньше, например 16, как в данном случае. Все байты и биты, которые не используются в группе, но входят в неё, выделяются в UNBELEGT-параметры. Т. е. даже если что-то в группе не используется, всё равно вся группа описана от первого до последнего байта и бита.
* * *
На этой ноте, пожалуй, закончу повествование. Теперь вы должны лучше понимать, как хранятся данные в блоке управления, как задаются значения параметров, во что они превращаются при кодировании, как они «упаковываются» в байты, как из байтов получить значения для каждого параметра и т. д. Желающие могут поэксперементировать: можно взять какой-нибудь навороченный кодировочный индекс, считать с помощью него трейс-файлы с машины, поочерёдно позагружать их в NCS Dummy, поменять какие-нибудь параметры и сделать экспорт вNETTODAT.MAN, потом сравнить, как изменились байты по сравнению с исходнымNETTODAT.TRC.
В следующей части мы попробуем не только читать, но и записывать нужные нам параметры, в том числе в обход доступных значений в кодировочном индексе, изменять сам кодировочный индекс и, если получится, заглянем в недоступные простым смертным участки памяти.
Чтобы не превращать бортовой журнал в «Технику молодёжи» и филиал журнала «Хакер», посты будут разбавляться более приземлёнными темами и куда более относящимися к машине, чтобы никто не заскучал
В этой части мы поговорим о том, каким образом происходит кодирование, какие данные реально отправляются в блок управления, что такое вообще кодировочные файлы (индексы) и зачем они.
NETTODAT
Всякий раз, когда вы делаете чтение данных из блока управления, открывается блокнот Windows, в котором написаны какие-то непонятные строчки. Большинство тех, кто занимается кодированием, вообще не представляет, что это такое и зачем оно нужно. Просто закрывают окно и работают с файлами FSW_PSW.TRC и FSW_PSW.MAN.
Вот к примеру файл NETTODAT.TRC, который получается при чтении блока FLA с индексомFLA_E65.C05:
NETTODAT.TRC
Не очень понятно, да?
Файл NETTODAT.TRC отражает то, как сохранены данные в блоке управления. Память блока управления похожа на память компьютера или телефона, она точно также состоит из байтов, каждый из которых имеет свой адрес (порядковый номер). Даже обычный файл на вашем компьютере — отдельный кусочек памяти. Его можно открыть в шестнадцатиричном редакторе:
OS X 0xED
В левой колоночке у нас указан адрес первого байта в конкретной строчке. Адрес в данном случае указан относительно начала самого этого файла. По центру у нас, собственно, сами байты в hex-виде — двухзначное шестнадцатиричное число. А справа — текстовое отображение в заданной кодировке. Примерно такую же белиберду можно увидеть в текстовом редакторе, если в нём открыть этот файл. Память в блоке такого понятия как «файл» не имеет. Вся память сама по себе, грубо говоря, один большой такой файл, в котором лежит сразу всё.
Но если открытый в hex-редакторе файл представляет собой одну сплошную последовательность из байт, то файл NETTODAT.TRC описывает в текстовом виде только определённые участки памяти: по какому адресу какие данные лежат. Состоит он из строчек вида:
B XXXXXXXX,YYYY,ZZ, ZZ, ZZ, ZZ, …ZZ
Эта строка описывает последовательность из байт, их количество и адрес:
— XXXXXXXX — адрес нашей последовательности в hex-виде (шестнадцатиричном);
— YYYY — длина последовательности в том же hex-виде;
— ZZ, ZZ, …, ZZ — сами данные, те самые байты, через запятую. Количество этих ZZ соответствует указанной длине последовательности.
NB: Суффикс «h» в числах означает, что число представлено в шестнадцатиричном значении (hex-виде). В языках программирования применяется вариант с префиксом «0x», но здесь и далее будет использоваться «h».
Первая строчка в файле NETTODAT.TRC (см. скриншот вверху):
B 00300000,0010,17,00,03,00,00,00,00,00,00,00,00,00,00,00,00,00
Означает, что по адресу 00300000h, т. е. начиная с 3 145 728-го байта у нас идёт последовательность из 0010h байтов (16), ну и сами байты, содержащие значения параметров блока управления. Кстати говоря, ни в одном из блоков, которые я смотрел, первый блок с данными не начинался ранее 00300000h, т. е. первые три мегабайта памяти (3 145 728 байт) у всех блоков чем-то ещё заняты.
В строчке выше мы видим последовательность байтов: 17,00,03,00,00,00,00,00,00,00,00,00,00,00,00,00. Мы знаем, что первый байт (17h) этой последовательности находится по адресу 00300000h. Следующий байт (00h), очевидно, имеет адрес 00300001h. Адреса всех байтов можно разложить в столбик:
00300000: 17,
00300001: 00,
00300002: 03,
00300003: 00,
00300004: 00,
00300005: 00,
00300006: 00,
00300007: 00,
00300008: 00,
00300009: 00,
0030000A: 00,
0030000B: 00,
0030000C: 00,
0030000D: 00,
0030000E: 00,
0030000F: 00
А что дальше? Рассмотрим следующую строку:
B 00300100,0010,04,01,00,03,04,09,18,1A,00,00,00,00,00,00,00,00
Опа, а здесь первый байт имеет адрес уже 00300100h, т. е. следующая последовательность начинается через 100h байт (256 байт) относительно начала первой. Первая строка описывает всего 16 байт, а что там идёт от 00300010h до 003000FFh-го байта — неизвестно. Зато во второй строке известно, какие данные содержат 16 байт памяти от 00300100h до 0030010Fh, ещё ниже очередные 16 байт от 00300200h до 0030020Fh. Таким образом, нам известно 48 байт данных.
Возникает вопрос, зачем у нас при этом так много неизвестных участков? Нельзя ли последовательно описать эти 48 байт без пропусков? Можно. Хотя блок FLA и использует всего по 16 байт в каждом таком блоке, такое разделение — функциональное/смысловое. На каждую группу параметров выделено 256 байт, этого должно быть достаточно для любой группы. Даже если сейчас нужно всего 16 байт, в будущем может потребоваться 20, 30 и т. д. Чтобы будущие изменения в одной группе не затронули другие, каждой выделяется заведомо достаточный кусок памяти для хранения параметров. Это — задел на будущее.
Если открыть более навороченный NETTODAT.TRC, полученный из CIC (индекс CIC.C1A), то данных там куда больше:
CIC.C1A NETTODAT.TRC
Здесь у нас в блоке в 256 байт описано 120 байт: последовательно 7 строчек по 16 байт и ещё одна строчка на 8 байт. Следующий блок стартует с уже привычных 00300100h.
NETTODAT и FSW_PSW
Теперь вы знаете, как устроен файл NETTODAT.TRC, знаете адрес каждого байта, но скорее всего ещё не понимаете, для чего всё это нужно и что с этим можно сделать. Пора приоткрыть завесу тайны.
Тот самый файл FSW_PSW.TRC, который получается при чтении блока является человеко-понятной интерпретацией NETTODAT.TRC. Т. е. из этих вот байтов собирается большой текстовый файл, который мы можем редактировать. А когда мы нажимаем кнопку кодирования, происходит обратный процесс, из текстового файла собираются байтики и записываются в блок. Никаких текстовых файлов в блоках управления не хранится, там лишь байты.
В процессе конвертации как раз участвуют те самые кодировочные файлы, а точнее индексы. Слово «индекс» следует интерпретировать как «каталог» или «оглавление» (это одно из определений слова index), а не как порядковый номер, хотя и это тоже подразумевается в некоторых случаях.
Что такое кодировочный индекс? Это файл-описание или файл-каталог. В нём хранится информация об адресах параметров, вариантах их значений, соответствующие им данные, условия применения и человеко-понятные названия.
Возьмём наш уже любимый STREETLAMP_COUNT из FLA_E65.C05. Примерно так хранится информация о параметрах:
…
Адрес: 00300107h
Параметр: STREETLAMP_COUNT
Длина: 01h байт
Маска: FFh
Варианты значений:
1) Название: wert_01;
Данные: 1Ah (26 в десятичном представлении);
Условие применения: !(!FLA_CI_05,FLA_CI_05+US)
2) Название: wert_02;
Данные: 40h (64);
Условие применения: !FLA_CI_05,FLA_CI_05+US
Адрес: 00300108h…
…
Всё это можно увидеть в NCS Dummy:
Дословно звучит так: по адресу 00300107h хранится значение параметра STREETLAMP_COUNT, значение имеет длину 1 байт и допустимы два значения: 1Ah и 40h, условия такие-то. Одно из двух значений будет выбрано если будут выполнены соответствующие условия, это мы уже знаем из прошлой части. Т. е. значения wert_01 или wert_02 меняют один единственный байт по адресу 00300107h в памяти блока.
Где этот байт находится в NETTODAT.TRC? А вот в этой строчке:
B 00300100,0010,04,01,00,03,04,09,18,1A,00,00,00,00,00,00,00,00
Как видите, выделенный байт имеет адрес 00300107h. 1A соответствует текстовому значениюwert_01. Если мы изменим в FSW_PSW значение параметра на wert_02, в блок вместо 1Aзапишется 40.
Таким образом, имея информацию из кодировочного индекса, мы можем конвертировать байты из NETTODAT.TRC вот в такой текст:
FSW_PSW.TRC
Это уже привычный нам текст. Конвертация работает в обе стороны, из байтов в текст и обратно.
Кодировочные индексы при кодировании «по умолчанию» (так называемый заводской профиль или просто пустой FSW_PSW.MAN) позволяют определить правильные значения всех параметров блока с учётом списка опций в автомобиле. Помимо этого, используя NCS Dummy, вы знаете, какие вообще значения доступны для каждого параметра.
NCS Dummy и trace-файлы
trace-файлы — это те самые файлы с расширением TRC и именами FSW_PSW (текстовая интерпретация) или NETTODAT (бинарный вид). Есть ещё другие трейсы, но сейчас мы ограничимся этими двумя.
После считывания FSW_PSW.TRC или NETTODAT.TRC, можно загрузить один из двух в NCS Dummy и работать с этим. Только для начала вам необходимо знать точный кодировочный индекс, который используется для чтения блока. Узнать его можно из окна NCS Expert сразу после нажатия кнопки Read ECU и завершения операции чтения (т. е. когда откроется блокнот с содержимым NETTODAT.TRC):
Окно NCS Expert после чтения ЭБУ (Read ECU)
Ага, для чтения использовался FLA_E65.C05. Следовательно, надо выбрать этот индекс в окне NCS Dummy, а затем загрузить trace-файл. Предусмотрены быстрые ссылки на соответствующие трейсы из папки C:\NCSEXPER\WORK\:
Загрузка
После загрузки простой список параметров и значений превратится в список с галочками:
Загружен FSW_PSW.TRC
Установленные галочки отражают текущие значения параметров. Можно переставить галочки на нужные значения и экспортировать сразу в FSW_PSW.MAN:
Экспорт в FSW_PSW.MAN
Весьма удобно, не правда ли? Сразу можно выполнить кодирование и получить результат. Но это скучная работа, это умеют все, кто хоть раз что-то кодировал.
NCS Dummy работает также и с NETTODAT-трейсом, можно загрузить и его и станет доступен экспорт в NETTODAT.MAN, который можно закодировать вместо FSW_PSW.MAN, хотя я не понимаю, почему эта функция недоступна при загрузке FSW_PSW. Для обычного кодирования такая процедура не очень нужна, поэтому о том, как выполнить NETTODAT-кодирование, я расскажу позднее. А сейчас мы вернёмся к кодировочному индексу.
Битовые маски
Наверное, это будет самая тяжелая и непонятная тема, но без понимания оной никак нельзя приступать к работе с NETTODAT.
Как я уже говорил, один байт — это число от 0 до 255, которое в двоичной системе описывается восемью битами. Каждый бит может иметь только два значения: 0 или 1. Одно и то же значение можно представить несколькими способами, в hex-виде (шестнадцатиричном) или binary-виде (двоичном), например число 37:
37 = 25h = 00100101b
NB: Суффикс «b» означает, что число представлено в бинарном (binary) виде.
Это всего лишь разные системы счисления (см. Википедию), которые представлют одно и то же число. Привычное нам десятичное представление, затем шестнадцатиричное и наконец двоичное. Каждый числовой знак в системе может иметь N значений, где N соответствует типу системы. Т. е. в десятичной числовой знак принимает значение от 0 до 9 (10 значений), в шестнадцатиричной от 0 до F (0-9 и от A до F, 16 значений) и в двоичной всего два: 0 или 1.
Конечно, в уме переводить из одной системы в другую весьма сложно, поэтому нам на помощь придёт встроенный в операционную систему калькулятор, который может работать в разных режимах: обычный, научный и режим для программистов. Последний режим нам как раз и понадобится. Я покажу калькулятор из системы Mac OS X, особой разницы с вариантом из Windows нет. Выглядит программерский калькулятор вот так:
OS X Calculator (Programmer mode)
Справа вверху можно увидеть кнопки переключения системы счисления: восьмеричный, десятичный и шестнадцатиричный. Одновременно с отображением числа на табло в выбранной системе, это же число всегда отображается в двоичном виде ниже. Для числа выделено 64 бита (8 байт), этого достаточно для представления весьма больших чисел, а мы с вами вообще не будем работать с числами длиннее 8 бит (т. е. не более 1 байта).
Зачем нам вообще все эти нолики, единички и прочая ересь? Всё дело в том, что программисты по натуре своей весьма ленивые и при этом экономные люди. Они не будут тратить целый байт на то, чтобы узнать, включена определённая функция или нет. Ну, во всяком случае так поступают только хорошие программисты
Так вот, для хранения значения типа вкл/выкл достаточного всего одного бита. А в одном байте их целых 8! Т. е. в один байт можно сохранить 8 выключателей различных функций. А если у нас что-то работает в одном из четырёх режимов, то для хранения номера режима достаточно двух бит:
(десятичная) = (двоичная)
0 = 00b
1 = 01b
2 = 10b
3 = 11b
Весьма экономно, не правда ли?
Допустим, у вас есть умный дом с блоком управления освещением. В доме шесть комнат, каждая из которых пронумерована, но по странному стечению обстоятельств не от единицы до 6, а от 0 до 5 включительно. Ну вот такой вот дом. При этом, в каждой комнате есть потолочная лампочка, но в комнатах 1 и 3 есть ещё и настольная. Наступил вечер, свет горит так:
Комната 0 = выкл
Комната 1 = верхняя выкл, настольная горит
Комната 2 = вкл
Комната 3 = горят обе лампы
Комната 4 = выкл
Комната 5 = вкл
Для четырёх комнат нам достаточно одного бита, чтобы сохранить состояние, включен свет или выключен. А вот для двух оставшихся нужно уже два бита. Разряды в числах у нас традиционно идут справа налево, т. е. самый младший разряд в числе — справа. В байте биты считаются также справа налево, т. е. самый крайний справа — нулевой (младший). Из двух бит пусть младший отвечает за потолочную лампу, а старший за настольную. Тогда для комнат биты будут такие:
Комната 0 = 0b
Комната 1 = 10b
Комната 2 = 1b
Комната 3 = 11b
Комната 4 = 0b
Комната 5 = 1b
Всё это можно слепить в целый байт, приняв комнату с номером 0 за самую младшую (справа):
1 0 11 1 10 0 = 10111100b = BCh
Если мы в комнате 1 зажгём ещё и верхний свет, то её биты 10 поменяются на 11:
1 0 11 1 11 0 = 10111110b = BEh
А если ещё выключим потолочную лампу в комнате №3, то:
1 0 10 1 11 0 = 10101110b = AEh
Получается, чтобы сохранить информацию о включенных лампах, нужно всего 8 бит или 1 байт. Последнее состояние соответствует числу AEh и оно у нас хранится в блоке управления освещением.
Калькулятор операционной системы позволяет наглядно «пощёлкать» битами:
Можно кликать на нолики и единички и они будут переключаться между собой, изменяя отображаемое на табло число.
Если бы блок управления освещением в доме разрабатывали в BMW, то NETTODAT такого блока управления при чтении текущего состояния выглядел бы так:
B 00300000,0001,AE
Вот такой вот короткий NETTODAT, один байт на весь свет в доме. Но как будет выглядеть текстовый трейс (FSW_PSW)? А вот так:
zimmer_0
nicht_aktiv
zimmer_1
alle_lampen
zimmer_2
aktiv
zimmer_3
tischlampe
zimmer_4
nicht_aktiv
zimmer_5
aktiv
Наверняка у вас сразу возникнет вопрос: как так, в трейсе 6 параметров, а в NETTODAT всего один байт? Очень просто. То самое свойство параметра «Маска» указывает нам на те биты в байте, в которых хранится значение параметра. Это позволяет на один байт завести от 1 до 8 параметров.
Поэтому маски для перечисленных выше параметров будут такие:
zimmer0: 00000001b = 01h (нулевой бит указывает на свет в комнате 0)
zimmer1: 00000110b = 06h (биты 1 и 2 указывают на лампы в комнате 1)
zimmer2: 00001000b = 08h (бит 3 указывает на свет в комнате 2)
zimmer3: 00110000b = 30h (биты 4 и 5 указывают на лампы в комнате 3)
zimmer4: 01000000b = 40h (бит 6 указывает на свет в комнате 4)
zimmer5: 10000000b = 80h (бит 7 указывает на свет в комнате 5)
Шестнадцатиричные значения вы можете самостоятельно получить, «накликав» соответствующие единички и нолики в калькуляторе.
Если на значение параметра отводится целиком один байт (например всё тот жеSTREETLAMP_COUNT), то маска для такого параметра равна 11111111b = FFh, т. е. мы отметили маской все доступные биты в байте. Если же на значение выделяется даже более одного байта, то маска всегда будет FFh, ввиду того, что она сама по себе занимает всего один байт и не в состоянии описывать биты в следующем байте. Это ограничение системы.
Маска и данные
Помимо маски у каждого значения параметра есть свойство «Данные» («Data» в NCS Dummy). Это именно то значение, те биты, которые будут записаны в блок, если будет выбрано это значение. Для наших комнат с одной лампой доступны такие варианты:
aktiv: 1b = 01h
nicht_aktiv: 0b = 00h
А для комнат с двумя лампами такие:
nicht_aktiv: 00b = 00h (всё выключено)
aktiv: 01b = 01h (включена потолочная лампа)
tischlampe: 10b = 02h (включена настольная лампа)
alle_lampen: 11b = 03h (включены обе лампы)
Количество бит, которое отводится для значения, ограничено маской. Если в маске подряд отмечены 3 бита, значит мы можем задать всего 7 разных значений, от 000b до 111b:
000b = 00h
001b = 01h
010b = 02h
011b = 03h
100b = 04h
101b = 05h
110b = 06h
111b = 07h
Обратите внимание, что данные для этих значений не зависят от того, в каком месте байта в памяти находятся выделенные под них биты. Просто мы берём отмеченные маской биты и прям в них вписываем значение. Пример:
Маска: 0Ch (00h . . 03h) = 00001100b (00b . . 11b)
Значение: 02h = 10b
Будет записано: xxxx10xxb
Где «x» — остальные биты от других значений параметров. Ещё пример:
Маска: F0h (00h . . 0Fh) = 11110000b (0000b . . 1111b)
Значение: 0Ah = 1010b
Будет записано: 1010xxxxb
Оба этих примера зададут в одном байте следующие биты:
101010xxb
Оставшиеся биты «x» с номерами 0 и 1 пойдут ещё на какой-нибудь параметр.
Возьмём теперь живой пример из NCS Dummy, всё тот же FLA_E65.C05:
Параметр TYP_FRONTSCHEIBE_FLA (тип ветрового стекла, климакомфорт или обычное) имеет адрес 00300100h, длина 1 байт, маска 04h. По умолчанию NCS Dummy показывает маски в hex-виде, но куда более понятен двоичный режим, который можно выбрать, кликнув правой кнопкой мыши по кнопке HEX-DEC:
Binary Mask
И тут мы видим, что третий справа бит в байте отвечает за то, какое у нас стекло. И варианты данных там либо 0 (обычное стекло), либо 1 (климакомфорт). В скобках справа от маски указан диапазон допустимых значений для неё. Т. к. маска тут всего один бит, то и значений всего два: 0 или 1.
Есть ли у нас параметры-соседи по байту? Есть: TYP_LENKUNG (тип рулевого управления) иVILLAGE_TYP (режим поведения распознавания города) находятся в том же байте по адресу 00300100h, но имееют маски 00000001b и 00010000b соответственно:
TYP_LENKUNG
VILLAGE_TYP
Стало быть, в байте по адресу 00300100h у нас есть три параметра, которые задают значения в битах 0 (TYP_LENKUNG), 3 (TYP_FRONTSCHEIBE_FLA) и 5 (VILLAGE_TYP) (исходя из нумерации справа налево).
В нашем уже изъезженном вдоль и поперёк NETTODAT.TRC байт по адресу 00300100h является первым во второй строке:
B 00300100,0010,04,01,00,03,04,09,18,1A,00,00,00,00,00,00,00,00
Разложим его на биты:
04 = 00000100b
Итого у нас справа налево TYP_LENKUNG = 0b (linkslenker, левый руль),TYP_FRONTSCHEIBE_FLA = 1b (klimakomfort, климатическое стекло) и VILLAGE_TYP = 0b (wert_01, Европа).
Остальные биты в этом байте помечены как UNBELEGT — незанятые биты или байты. Например, крайние слева незанятые три бита:
UNBELEGT
Адрес байта тот же, отмечены в маске три крайних бита (с диапазоном записи от 000b до 111b), но записаны туда нолики. Никаких иных вариантов кроме записи ноликов туда не предусмотрено. Остальные биты между известными параметрами также вынесены в UNBELEGT-параметры. Если вместо NETTODAT.TRC загрузить FSW_PSW.TRC, строчки с UNBELEGT-параметрами исчезнут, т. к. при работе с FSW_PSW незанятые параметры не отражены в нём.
Закономерность следования параметров простая: по байтам мы движемся слева направо, а по битам справа налево, от младшего к старшему.
Другой пример, параметр VERTIKAL_BILD_OFFSET (программный угол наклона камеры FLA, см.пост по теме):
VERTIKAL_BILD_OFFSET
Маска у него 01111111b, т. е. семь бит из байта по адресу 00300102h задают угол наклона. Диапазон, стало быть, от 0000000b до 1111111b или от 00h до 7Fh в hex-виде, или в десятичном от 0 до 127 включительно. В описании к параметру сказано, что угол в градусах считается по формуле ANGLE_º=DATA/10, т. е. мы делим заданное число на 10 и получаем угол в градусах. Так, выделенное на скриншоте значение wert_06 соответствует данным 00001100b или 0Ch, или 12 в десятичном представлении. Переключаться между представлении поможет кнопка HEX-DEС. Поделив 12 на 10, получим 1,2º. Максимальное же значение у нас 127, что соответствует углу 12,7º, который, тем не менее, вряд ли достижим программным способом.
Помимо угла у нас есть ещё параметр, отвечающий за знак, т. е. в какую сторону от вертикали мы отклоняем камеру. Параметр называется RICHTUNG_BILD_OFFSET:
RICHTUNG_BILD_OFFSET
Маска у него 10000000b, это восьмой бит из того же байта, в котором записан сам угол. Значение может быть соответственно 0 (+, вверх) или 1 (-, вниз). Стало быть, в одном байте по адресу 00300102h записаны два параметра: угол и знак. Заняты все 8 бит, поэтому рядом нет никаких UNBELEGT-параметров. В моём случае по этому адресу записано 00h:
B 00300100,0010,04,01,00,03,04,09,18,1A,00,00,00,00,00,00,00,00
Т. е. программный угол равен +0º. Всё потому что на Южанке угол наклона камеры FLA задаётся физически и программная коррекция не нужна.
Любопытны строчки по этим параметрам из файла-исходника кодировочного индекса:
FLA_E65.C05 source
Тут всё наглядно видно: адрес, название параметра, маска, варианты названий значений и данных, которые им соответствуют. А самое ценное — комментарии разработчика. Исходные файлы индексов в свободном доступе не найти, не в последнюю очередь потому что в этих же файлах описаны и те области памяти, которые кодируются исключительно на заводе и не подлежат кодированию через NCS Expert.
* * *
Кстати, обратите внимание на изменяющийся цвет фона в списке параметров. Цветом выделяется группа параметров, причём сама группа имет даже название:
AUTOPARAMETER
Группа, как мы видим, тоже имеет адрес и длину, в данном случае выделено 16 байт по адресу 00300100h. Это как раз вся вторая строчка из NETTODAT.TRC!
Стало быть, блоки по 256 байт, о которых я писал в начале статьи, выделены на группы параметров. Но группа не обязана занимать сразу все 256 байт, можно и меньше, например 16, как в данном случае. Все байты и биты, которые не используются в группе, но входят в неё, выделяются в UNBELEGT-параметры. Т. е. даже если что-то в группе не используется, всё равно вся группа описана от первого до последнего байта и бита.
* * *
На этой ноте, пожалуй, закончу повествование. Теперь вы должны лучше понимать, как хранятся данные в блоке управления, как задаются значения параметров, во что они превращаются при кодировании, как они «упаковываются» в байты, как из байтов получить значения для каждого параметра и т. д. Желающие могут поэксперементировать: можно взять какой-нибудь навороченный кодировочный индекс, считать с помощью него трейс-файлы с машины, поочерёдно позагружать их в NCS Dummy, поменять какие-нибудь параметры и сделать экспорт вNETTODAT.MAN, потом сравнить, как изменились байты по сравнению с исходнымNETTODAT.TRC.
В следующей части мы попробуем не только читать, но и записывать нужные нам параметры, в том числе в обход доступных значений в кодировочном индексе, изменять сам кодировочный индекс и, если получится, заглянем в недоступные простым смертным участки памяти.
Чтобы не превращать бортовой журнал в «Технику молодёжи» и филиал журнала «Хакер», посты будут разбавляться более приземлёнными темами и куда более относящимися к машине, чтобы никто не заскучал