На примере приведенного лога и отловленных изменений попробую «потренироваться» с попутным объяснением своих действий. Итак, допустим, что в первом байте 378h сообщения (на самом деле в протоколах и байты и биты обозначаются начиная с 0-го, то есть, в 0-м байте) произошли изменения при нажатии на педаль газа. То есть, до нажатия было 00h а стало 22h (не забываем, что речь идет о 16-ричной СС, поэтому и приставляем буковку “h”, чтобы не спутать с 10-ричной). Вообще, ПО, которое идет вместе с анализаторами позволяет отображать данные и в 10-чной СС (и даже в ASCII), однако, ниже покажем, что в случае с CAN это, как правило, далеко не всегда удобно при дальнейших операциях. Итак, мы заметили, что при плавном нажатии на педаль газа, 0-ой байт также плавно начинает изменяться от 00h до 22h, при этом, мы понимаем, что нажали педаль совсем немного, по ощущениям точно не более половины и даже трети. Тут хорошо бы сделать отступление и сказать, что хорошо бы нажимать педаль на разную величину и одновременно снимать данные с байта (скажем, примерно на ¼, на ½, на ¾, на «полную», и одновременно записывать показания байта в этих положениях).
Тогда, запустив обычный виндовый калькулятор, и, выбрав режим его работы «Программист», отмечаем «8 байт» и «Hex» (16-ричный), пишем «22», тыкаем «Dec» (переводим в десятичную СС) и видим: 34. Имея другие «точки» засечки с другими положениями педали газа, убеждаемся, что данный байт – нажатие педали газа в %. То есть, буквально для нашего случая, – педаль газа нажата на 34%.
Более сложный случай, где уже просто необходима «16-тиричность» представления данных:
Допустим, в первом положении ключа зажигания у нас были нули в первых двух байтах, а после того как машину завели и нажали педаль газа, стало соответственно в 0-м байте 22h, в 1-м 3Ah (как в реальном логе). Отсюда можно сделать предварительный вывод – на какой-то параметр, который связан с нажатием на газ отведено 2 байта. (Опять же, лучше отметить несколько точек с разным нажатием на педаль.) Хорошо, поняли что меняются два байта и с уверенностью 99% то, что эти два байта означают одну аналоговую величину. Далее делаем следующее – просто «составляем» вместе эти значения, получаем 3A22h. Почему именно в таком порядке (на самом деле может быть и наоборот – 223Ah, зависит от того, как общие договоренности осуществлены в протоколе обмена), но, как правило, старшие байты идут вначале, младшие – в конце. Итак, с помощью калькулятора переводим 3A22h в десятичную СС, получаем 14882. То есть, если запись данных занимает более 1-го байта (а бывает и 3 и 4, и даже 8 байт для записи некой величины), то составить верное значение можно только в 16-ричном виде. Потом уже составленное можно (а для анализа и нужно) перевести в 10-чное. Теперь, что же может означать 14882? Конечно, необходимы и косвенные признаки – наличие нескольких точек. Например, на холостом ходу были значения байтов 0-го и 1-го соответственно 40h и 1Fh. Составили, перевели в десятичное, получили 8000. Теперь с определенной долей уверенности можем сказать, что в первых двух байтах сообщения 378h содержатся данные о частоте оборотов двигателя (умноженные на 10 – для повышенной точности)…
Вот так и вычислять пытаться, а что делать? :wink:
Попозже поговорим о дискретных сигналах.
|
