Закусила меня эта тема. Пока не докопаюсь до истины, дык спать не буду спокойно. Вот сегодня, например, спал очень плохо - все гонялся за какими то битами, дружил их, и все тёр глаза, словно одел мутные очки, через которые все никак не мог рассмотреть на экране осциллографа нужный мне фрагмент осциллограммы с этими битами.
Сегодня написал письмо тому serg22, на странице которого я скачал исходники примеров чтения/записи RFID-меток E-Marine EM-4100. Он ответил, что код, который вещает брелок, можно записать с помощью звуковой карты компьютера и потом спокойно рассматривать WAV-файл в каком нибудь музыкальном редакторе, как на запоминающем осциллографе. Это просто замечательная идея! И действительно - а почему нет? Скорость передачи там не большая, и сравнима со скоростью, с которой в конце 80х с магнитофона загружались игрушки в знаменитый SPECTRUM.
В архиве
с примером лежал файл RFID-045-51384.wav с записанным ответом RFID-брелка и файлик для эмулятора "Протеус" со схемой. Я совсем забыл то, что в этой замечательной программе есть возможность подоткнуть WAV-файл и скормить тем самым этот сигнал напрямую МК, минуя необходимость использовать реальный брелок и реальное "железо". Так и сделал! Включаю эмулятор "Протеус", в нем запускается схема reader-a и через 5 секунд он распознает код брелка, который записан в файле WAV! Замечательно! Там же включаю осциллограф и вижу всю битовую последовательность, которая летит с брелка в МК. Моя задача увидеть на экране осциллографа не просто какие то биты, а определенную комбинацию, после чего я буду считать, что манчестерский код я понимаю верно, и смогу объяснить в этой осциллограмме каждую закорючку. Это свидетельство 100% ясности и понимания темы на данном этапе. Главное - с самого начала быть уверенным, что сигнал не отображается в инверсном виде, иначе можно зря потерять время. В Протеусе, после безуспешных попыток, таки пришлось применить транзистор и инвертировать сигнал - и сразу все встало на свои места!
Но прежде я таки еще раз обратился к
мануалу EM4100. Там есть очень хороший пример того, как выстраивается вся битовая посылка - от первого бита до последнего.
Вложение:
screenshot.7.png [ 2.92 КБ | Просмотров: 26339 ]
Пример приведен для брелка с кодом
06001259E3, где 06 это номер версии брелка или customer ID (как в iButtons код семейства), а 00 12 59 E3 есть не иначе, как уникальный код брелка, состоящий из 4х байт.
Передача все этого безобразия начинается с передачи девяти логических единичек - это есть стартовый паттерн (header bits, выделено красным), так сказать приглашение приемнику выслушать брелок. По скольку такой комбинации больше ни при каких ситуациях не может быть, то это приглашение молча и быстро принимается приемником. Если вдруг он "прослушал" это приглашение, то все, что пойдет следом он пропустит, пока брелок не начнет передавать всю пачку сначала.
Вложение:
screenshot.5.png [ 20.14 КБ | Просмотров: 26339 ]
Сразу после приема последовательности "111111111", начинается передача кода семейства (выделено желтым). Передача начинается со старших его четырех бит (биты D0....D03 в мануале) и заканчивается посылкой бита проверки четности (для отправленных битов это бит Р0). Логика этого бита проста, как морковка: если в первых отправленных четырех битах было четное количество единичек (0-2-4), то брелок посылает ноль; а если количество единичек было не четным (1-3) то высылает единичку. Видите как все просто? Сразу за битом четности с кодом Р0 брелок высылает младшую часть байта (биты D04-D07), и сразу же за ними бит четности Р1. Принцип формирования этого бита такой же.
Итого: байт 06h разбивается на две половинки, то есть на 0 и 6. В битах это будет 0000 и 0110 соответственно. По скольку в первой половинке нет единичек вообще, то бит четности Р0 будет равен нулю. Бит четности Р1 тоже будет равен нулю, потому что количество отправленных единичек было четное. Всего, после 9 единичек, брелок отправит комбинацию бит 0000 0 0110 0
Сразу после этого отправляются 4 байта уникального кода брелка (выделено голубым цветом). Принцип разбиения байта, передачи и подсчета битов четности абсолютно идентичен с отправкой байта кода семейства.
Доходим до последней строчки в таблице - битов с названием РС0-РС4. Если биты Р0-Р9 нужны для контроля ошибок по строкам, то это есть контроль ошибок по столбцам. Вычисляются эти биты, в общем то, не так сложно, и по такому же принципу. Итак, для подсчета бита РС0 нужно посчитать количество отправленных единичек в первом столбце (биты D00, D04, D08, D12, D16, D20, D24, D28, D32, D36). Если их количество будет четным, то брелок отправит 0, а если не четным, то 1. В нашем случае по этому столбцу было отправлено всего 2 единички - число четное, значит на месте того бита будет ноль. Точно так же вычисляется бит РС1 по второму столбцу и так далее до РС03
Последним отправляется стоп-бит, то есть нуль и отправка всего пакета начинается заново. На всякий случай создайте сами всю последовательность битовой посылки, а затем сверьтесь с картинкой "
screenshot.7.png"
Все это справедливо только для того брелка с конкретным кодом. В вышеуказанном же архиве с примером брелок имеет код 0x4B002DC8B8, соответственно битовая последовательность и осциллограммы будут другими. Вооружился экселем, составил точно такую же последовательность всех битов и байтов, но для кода брелка 0x4B002DC8B8. Даже нарисовал часть осциллограммы, которую я должен увидеть:
Вложение:
screenshot.8.png [ 2.12 КБ | Просмотров: 26339 ]
Вложение:
screenshot.2.png [ 988 байт | Просмотров: 26339 ]
и вот что я в итоге увидел на экране осциллографа:
Вложение:
screenshot.4x.png [ 117.64 КБ | Просмотров: 26339 ]
Сравните планируемую осциллограмму с реальной - 100% сходство! Такого попадания в десятку я не ожидал! Теперь то конечно ощущаешь крылья за спиной, а так же понимаешь, что все это очень и очень легко. Но видели бы вы меня прошлой ночью..
Ну и напоследок хочу сделать пояснения на счет стрелочек на картинке с осциллографом. Конечно составить последовательность передачи бит на бумаге это одно, а вот передать их на реальное устройство... Дело в том, что приемник должен обязательно иметь возможность синхронизации с передатчиком, что бы не запутаться в данных. В шинах i2C или SPI всегда присутствует тактирующий сигнал CLOCK, от которого все и пляшет. Но у нас всего один провод, да и тот протянут через радиотракт. Следовательно нужно придумывать какие то особенные сигналы, по которым приемник будет понимать что происходит в данный момент. Хороший пример - стартовая последовательность из 9 единичек, которая больше никогда не повторяется. Но этого мало, ибо нужно иметь какие то другие ориентиры для приемника. Такими ориентирами служит сознательное увеличение длины импульса с 300мкС до почти 600мкС. Если при этом сигнал был равен лог.единице, то это значит для приёмника, что все дальнейшие импульсы нужно регистрировать не по нарастающему фронту, а по спадающему, а так же принимать все последующие спадающие фронты как нули. При этом нуль будет засчитан уже при окончании этого длинного импульса (то есть его нарастающий фронт был считан как 1, а спад уже будет считан как нуль)
Все это будет до тех пор, пока увеличенный по длине импульс не окажется лог.нулем, что будет интерпретировано приемником прямо противоположно ситуации с принятием длинного импульса лог.единицы, а именно: все последующие импульсы регистрировать по нарастающему фронту и читать их как единицу, начиная с текущей позиции. Остается только еще раз перечитать весь этот лепет и всмотреться в manchester_encoding.jpg и скриншот осциллографа. Или
почитать подробней про манчестерский код.
PS. Прошу не бейте дубинками, если где то допустил неверную трактовку, термин или формулировку. Информации много, тема для меня новая, а время позднее. Основную суть я передал. Надеюсь, что мои умозаключения кому то помогут.