Вопросы настройки, программирования, прошивки микроконтроллеров и микросхем программируемой логики
Тема закрыта

Сниффинг SPI шины дисплея GDM0801(g)

Вс июл 22, 2012 22:57:24

Добрый всем вечер
стал перед следующей задачей.
есть некое устройство, в котором используется знакосинтезирующий (1 ряд и 8 символов(в каждой 5x8 точек)) дисплей GDM 0801 G(именно версии G ) который управляется не по параллельной шине, а по SPI (судя по всему)
ДШ нет. есть только на похожие (версии a,b,c,d) но все они оказались с параллельной шиной.
на этот дисплей выходит различная цифро-текстовая и иногда символьная (стрелочки) информация.
мне же нужно с помощью контроллера (пока что pic12f675) сниффить информацию которая идёт только в последний сегмент дисплея. причём интересуют только цифры от 1 до 9 включительно. буквы и другое не нужны.
далее нужно записать код этой цифры , а потом я её загоняю и сравниваю в case ... of и делаю , что мне нужно..

теперь подробнее о том , что творится на шине дисплея.
ради этого даже пришлось логический анализатор собрать.
судя по всему идут команды по SPI , так как обнаружил тактовый сигнал CLK, сигнал начала передачи CS и сами данные MOSI
также удалось декодировать то , что там творится.
при включении дисплея происходит инициализация 3-мя посылками по 8 бит (почти такаяже как инициализация KS0066 (парочка бит вроде не совпала), но по SPI), после инициализации идут посылки с инфой которую нужно отображать на дисплее.

пример посимвольно, "_" - на дисплее это пробел . нужная нам информация - цифра 2 в последнем сегменте
K _ - -_ _ _ 2
и теперь скрин из анализатора (там и декодирована посылка сразу)
Изображение

т.е. сразу CS=0 потом идёт посылка 0x01 потом опять CS=1 , потом снова CS = 0 и уже идут бесперерывно 72 бита (9 байт) и первый всегда 0x87 , а последующие и есть 1-8 символ дисплея в кодировке ASCII. из этой посылки нужен последний 9-ый байт (64-72 биты)

вопрос- как принять именно этот байт?
с программированием микроконтроллеров мало знаком. из языков турбопаскаль изучал лет 6 назад (и то, отрывками), и два года назад колупался в исходниках cvavr на C
наглядно понимаю , что и как. но подробно с мк , многое непонятно.
алгоритм приёма на словах могу расписать, но вот три дня бьюсь головой, но не могу понять как реализовать на контроллере.
получается как, следим за CS, когда она становится =0 -> начинаем считать каждый CLK=0 , досчитываем до 64 и начинаем считывать MOSI при каждом CLK=0 и задвигать биты в байт при каждом CLK=0
при этом, если в процессе считывания импульсов CLK, CS cтал равен 1 до того как прошло 64 импульса на CLK , счётчик импульсов CLK обнуляем, опускаем флаг приёма и возращаемся заново. (это нужно для того, чтобы исключить приём байтов инициализации, и байта (0x01) который идёт перед каждой пачкой 9 байт с инфой которая будет отображаться на дисплее)
если приняли успешно , подымаем флаг приёма
и далее идёт сравнение оператором case...of (если 0x31 то уровень=1, если 0x32 то уровень=2 и т.д. до 9) , это я уже реализовал в mikropascal и вроде работает как надо.

похоже надо реализовать через прерывания, вот с ними я и немогу разобраться

Re: Сниффинг SPI шины дисплея GDM0801(g)

Пн июл 23, 2012 11:16:36

Каким логическим анализатором пользовались?

Вы не указали частоту CLK
Вероятно лучше использовать аппаратный модуль SPI контроллера в режиме slave вместо программного декодирования.
Кроме того, желательно убедиться, что первый байт посылки именно 0х87, это установка курсора, желательно также разобраться с сигналом А0 (он наверное выведен отдельным выводом). Иначе можно словить неправильные данные в тех посылках, которые инициализируют индикатор или загружают пользовательские символы

Re: Сниффинг SPI шины дисплея GDM0801(g)

Пн июл 23, 2012 14:54:28

koyodza писал(а):Каким логическим анализатором пользовались?

Вы не указали частоту CLK
Вероятно лучше использовать аппаратный модуль SPI контроллера в режиме slave вместо программного декодирования.
Кроме того, желательно убедиться, что первый байт посылки именно 0х87, это установка курсора, желательно также разобраться с сигналом А0 (он наверное выведен отдельным выводом). Иначе можно словить неправильные данные в тех посылках, которые инициализируют индикатор или загружают пользовательские символы


собрал бесплатный scanalogic на atmega 8 и кварце 20мгц. записал в нём сигнал, а потом подсунул платной проге scanastudio и там подробно проанализировал
тригер ставил на спад по CS т.е. на начало передачи, и как только проц подавал на экран новую порцию данных - срабатывал анализатор.

частота clk, если верить scanastudio = 2,399khz и как я понимаю это не очень быстро , при подробном рассмотрении импульсов, тайминги виляют +\-80-100мкс

A0 где про него можно почитать? и вроде импульсов на других ногах не было. т.к. всего 8 ног, из них две земли, 1 питание, 1 напряжение регулировки подсветки. и остаются 4 на spi -> CS CLK MOSI MISO
на miso всегда молчание было, поэтому на скрине обрезал её.

что ещё, глянул опять ДШ от подобного диспа но с параллельной шиной данных http://www.xmocular.com/Upload/Character/GDM0801AFLYBS-19062998640.pdf
там таблица есть кодов, в ней этот 0x12 является пустой клеткой , а не ячейкой пользовательских символов CGRAM, может это был резерв на дисплеи которые идут под заказ? (судя по всему этот , что мы счас анализируем и есть заказной, ибо SPI шину в серийных диспах я не нашёл)
Изображение

и вот символ с кодом 0x12 на дисплее. обведено красным
Изображение
кстати, в данный момент на экране X _ - _ _ _ _ 1


также даю файл, который можно глянуть в проге-анализаторе Scanastudio (качать там http://www.ikalogic.com/ikalogic-products/scanastudio/)
K2 SPI.zip
посылка K _ - -_ _ _ 2
(1.28 KiB) Скачиваний: 447

Re: Сниффинг SPI шины дисплея GDM0801(g)

Ср июл 25, 2012 22:59:35

А0 часто имеет другое название RS
Да, дисплей вполне может быть заказным. Символы с кодами 0х10..0х1F и 0х80..0х9F у разных производителей дисплеев выглядят по-разному, посмотрите хотя бы на МЭЛТ
Для такой низкой частоты 2,4кГц действительно реально сделать и полностью программное детектирование, но при наличии аппаратного модуля SPI в контроллере всё же лучше использовать аппаратный

Re: Сниффинг SPI шины дисплея GDM0801(g)

Ср июл 25, 2012 23:59:32

koyodza писал(а):А0 часто имеет другое название RS
Да, дисплей вполне может быть заказным. Символы с кодами 0х10..0х1F и 0х80..0х9F у разных производителей дисплеев выглядят по-разному, посмотрите хотя бы на МЭЛТ
Для такой низкой частоты 2,4кГц действительно реально сделать и полностью программное детектирование, но при наличии аппаратного модуля SPI в контроллере всё же лучше использовать аппаратный

ок, я пока остановился на 12f675(629) (ибо программа не сложная - нужно в зависимости от принятого числа (от 1 до 9) выдавать бипы между которыми идёт пауза. чем больше число - тем меньше пауза. если сталкивались с звуковым оповещением в дозиметрах (сильнее фон - чаще пищит), то это по сути тоже самое.)

в 12f675 нет аппаратного spi. как программно реализовать приём последнего байта?
откопал на казусе тему, в которой отдалённо затрагивается и моя проблема http://kazus.ru/forums/showthread.php?t=91448
там правда прерывать выполнение основного цикла нельзя было, в моей задаче это делать можно

может есть готовые решения подобной задачи для других МК?

Re: Сниффинг SPI шины дисплея GDM0801(g)

Чт июл 26, 2012 00:10:01

a-droo писал(а):как программно реализовать приём последнего байта?
может есть готовые решения подобной задачи для других МК?

Если у Вас МК больше ничем другим не занят, то это очень просто. Основную суть Вы сами описывали выше
a-droo писал(а):следим за CS, когда она становится =0 -> начинаем считать каждый CLK=0 , досчитываем до 64 и начинаем считывать MOSI при каждом CLK=0 и задвигать биты в байт при каждом CLK=0
при этом, если в процессе считывания импульсов CLK, CS cтал равен 1 до того как прошло 64 импульса на CLK , счётчик импульсов CLK обнуляем, опускаем флаг приёма и возращаемся заново. (это нужно для того, чтобы исключить приём байтов инициализации, и байта (0x01) который идёт перед каждой пачкой 9 байт с инфой которая будет отображаться на дисплее)
если приняли успешно , подымаем флаг приёма
и далее идёт сравнение оператором case...of (если 0x31 то уровень=1, если 0x32 то уровень=2 и т.д. до 9) , это я уже реализовал в mikropascal и вроде работает как надо.

похоже надо реализовать через прерывания, вот с ними я и немогу разобраться

Для такой низкой скорости и возможности монопольного использования процессора можно всё это делать без использования прерываний
Тема закрыта