Модель UG-2864HSWEG01 в Proteus 8.7 глючная?

[ProtAS-13]

Почему у вас возникла мысль что экран не надо информировать что следующий байт является командой, если это и правда команда?

Давайте разбираться. В ДШ на SSD1306 приведен формат передачи I2C (см. рис1).
Т.е. существует 2 метода передачи:

1. S -› SLAVE_ADDRESS -› { CONTROL BYTE -›   DATA BYTE } -› ... { CONTROL BYTE -› DATA BYTE } -› P
2. S -› SLAVE_ADDRESS -›   CONTROL BYTE -› { DATA BYTE } -› ... {                 DATA BYTE } -› P

Вы в свем коде используете 1-й способ, а модель в Proteus'е использует 2-й способ.
Кстати, я, вполне, их понимаю - кому придет в голову передавать в 2 раза больше данных?
Да, похоже, что и Вы это прекрасно понимаете, т.к. в CLR_SCR, да и при выдаче графики Вы вынесли CONTROL BYTE за цикл.
А вот зачем отавили его OLED_INIT? Вынесите его также за цикл, проверьте в железе. Думаю, все должно заработать.

[Donker]

Цитата из первоисточника: (https://www.radiokot.ru/articles/77/)

С первого взгляда всё логично и, вроде бы, понятно: сначала выдаём старый добрый СТАРТ, потом байт со Slave-АДРЕСом (0111100 или 0111101) дополненный нулём в младшем бите (потому что мы ничего не будем читать из дисплея, а будем только передавать ему команды или данные). Потом принимаем бит ACK подтверждения от дисплея… А потом отсылаем некий CONTROL BYTE, содержащий всего два возможных для изменения бита: 7-й ”Cо” и 6-й “D/C” (остальные всегда нули), которые изрядно попортили мне кровь, пока я разобрался, как себя с ними вести.

Вот, что мы можем почерпнуть про них из даташита:

The D/C# bit determines the next data byte is acted as a command or a data. If the D/C# bit is set to logic “0”, it defines the following data byte as a command. If the D/C# bit is set to logic “1”, it defines the following data byte as a data which will be stored at the GDDRAM. The GDDRAM column address pointer will be increased by one automatically after each data write. If the Co bit is set as logic “0”, the transmission of the following information will contain data bytes only.

Если коротко, то “D/C” может быть единицей или нулём. Первый вариант говорит дисплею, что в СЛЕДУЮЩЕМ БАЙТЕ мы собираемся передать ему данные для отображения на экране, второй – что в СЛЕДУЮЩЕМ БАЙТЕ мы будем передавать какую-то команду, т.е. собираемся им (дисплеем) управлять.

Бит “Со” равный нулю сообщает ему же, что ВСЕ СЛЕДУЮЩИЕ БАЙТЫ пойдут потоком в виде данных для вывода на экран. И всё бы хорошо, но нет ни слова о варианте, в котором этот бит мог бы быть равным единице. А такой вариант существует. И не один – их на самом деле целых два, а вот вариант с нулём оказался единственным.

В моём исходнике все три варианта определены через дефайны, как COM (СЛЕДУЮЩИЙ БАЙТ будет командой), DAT (СЛЕДУЮЩИЙ БАЙТ будет данными) и DATS (ВСЕ СЛЕДУЮЩИЕ БАЙТЫ будут данными):

#define COM 0b10000000
#define DAT 0b11000000
#define DATS 0b01000000

Итак, если мы хотим передать в дисплей команду, т.е. изменить в нём какие-либо настройки, провести инициализацию и т.п., то после бита подтверждения ACK нам необходимо отослать контрольный байт 0b10000000 (COM), после чего, получив ещё один ACK, нашу команду, а затем вновь дождаться подтверждения ACK. Соответственно, если нам необходимо последовательно передать несколько команд, то нам придётся "крутиться" по этому же алгоритму: COM, ACK, ‹8_бит_команды›, ACK, … и т.д. до бесконечности.

Перед каждым байтом команды надо передавать COM видимо разработчики контроллера монитора посчитали что команд будет немного,
а вот для байтов с данными они придумали DATS для передачи потока байтов с графикой.

Из файла main.h :

...
#define	DATS	 0b01000000	//ПЕРЕДАЧА НЕСКОЛЬКИХ БАЙТ ДАННЫХ
#define	DAT	 0b11000000	//ПЕРЕДАЧА ОДНОГО БАЙТа ДАННЫХ
#define	COM	 0b10000000	//ПЕРЕДАЧА ОДНОГО БАЙТа КОМАНДЫ
...

[ProtAS-13]

Donker.
Я так и не понял, Вы хотите решить проблему или нет?
Понимаете, сейчас сложилась хорошая ситуация - у Вас есть железка, я знаю как работает модель в Proteus - можно было бы совместными усилиями определиться, в какой мере модель не соответствует реальной железке.
Для этого, всего то, нужно провести ряд итераций на железке.
1. Вынести SEND(COM) из цикла и проверить в железке и симуляторе:

void OLED_INIT (void)  //ИНИЦИАЛИЗАЦИЯ ДИСПЛЕЯ
{
  unsigned char k;

  START();
  SEND(NAME);
  SEND(COM);
  for(k=0;k‹18;k++)
  {
    SEND(pgm_read_byte(init+k));
  }
  STOP();
}

А приводимые Вами "первоисточники" - это такие же радиогубители как и мы: заработало - зачем что-то менять.
Я просмотрел несколько библиотек, популярных "в миру" - так там различные варианты передачи данных. К примеру, популярная библиотека от Adafruit каждую команду формирует через старт-стоп.
Вот и хотелось бы определиться с вариантами, которые работоспособны и в железе и в симуляторе.
Решайтесь! На Вас смотрят все поколения радиолюбителей

[Donker]

Изменил код как вы написали, результаты:

В Протеусе кот с надписью рисуется иногда нормально иногда не дорисовывается до конца, но без эффекта смещения картинки по экрану,
бегущие цифры не отобразились ни разу.

В железе изображение смещается вниз на столько, что на экране остаётся только надпись RADIOKOT.RU в самом низу экрана, естественно, бегущих цифр либо нет, либо их не видно.


Всё это проделанно на новой библиотеке LCDPIXEL.DLL от Протеуса 8.8 (один добрый человек выложил) и теперь этот глюк исчез:
https://kazus.ru/forums/showthread.p...38#post1218538

а с UG-2864HSWEG01 без изменений.

[ProtAS-13]

а с UG-2864HSWEG01 без изменений

Еще одна итерация:

void OLED_INIT (void)  //ИНИЦИАЛИЗАЦИЯ ДИСПЛЕЯ
{
  unsigned char k;
  for(k=0;k‹18;k++)
  {
    START();
    SEND(NAME);
    SEND(COM);
    SEND(pgm_read_byte(init+k));
    STOP();
  }
}

Думаю последняя. Если и здесь ёк, то, видимо, придется покупать у китайцев дисплей.

[Donker]

Такой вариант:

В Протеусе 50% запусков симуляции кот рисуется нормально, 50% с глюками, бегущие цифры не показались ни разу.

В железе такой вариант работает нормально.

[ProtAS-13]

В железе такой вариант работает нормально

Спасибо.
На этом изыскания прекращаем, резюмируя, что использование примитива SSD1306 в I2C режиме, возможна, с условием передачи КОМАНД в старт-стопном режиме полного формата:

S -› SLAVE_ADDRESS -› CONTROL BYTE -›   DATA BYTE -› P
...
S -› SLAVE_ADDRESS -› CONTROL BYTE -›   DATA BYTE -› P

[ProtAS-13]

бегущие цифры не показались ни разу

На основе того, что мы тут наобсуждали, то для этого нужно привести код к старт-стопному формату. Я бы, к примеру, просто сделал бы отдельную функцию для передачи команд, типа:

Нажмите, чтобы открыть спойлер

void SEND_COM(uint8_t command)
{
  START();
  SEND(NAME);
  SEND(COM);
  SEND(command);
  STOP();
}

и везде, где необходимо передать команду вызывал бы ее. К примеру, формирование цифирек:

Нажмите, чтобы открыть спойлер

  for(kk=0;kk‹5;kk++)
	  {
//		  START();
//		  SEND(NAME);
		  
//		  SEND(COM);
//		  SEND(0x21);		//Set Column Address (21h)
            SEND_COM(0x21);
//		  SEND(COM);
//		  SEND(115);		//будем выводить между 115...
            SEND_COM(115);
//		  SEND(COM);
//		  SEND(126);		//...и 126 колонками
            SEND_COM(126);

//		  SEND(COM);
//		  SEND(0x22);		//Set Page Address (22h)
            SEND_COM(0x22);
//		  SEND(COM);
//		  SEND(6);		//Будем крутиться между 6-ой...
            SEND_COM(6);
//		  SEND(COM);
//		  SEND(7);		//...и 7-ой страницами (строчками)
            SEND_COM(7);

            START();
		  SEND(DATS);
		  for(k=0;k‹12;k++) SEND(pgm_read_byte(DIGIT[kk]+k));		//рисуем верхнюю часть цифры
		  for(k=12;k‹24;k++) SEND(pgm_read_byte(DIGIT[kk]+k));	//рисуем нижнюю часть цифры
		  
		  STOP();
		  _delay_ms(1000);
	  }

старые команды закомментированы, добавленные - с меньшим отступом.

[Donker]

Я хочу сначала написать версию проекта на основе аппаратной работы с I2C, но это будет не быстро, надо найти время, а потом локализировать проблему, возможно дело в неправильной имитации протокола I2C.

Затык на ровном месте:

https://www.radiokot.ru/forum/viewto...?f=57&t=157986

[ProtAS-13]

Затык на ровном месте

Cи - такой уж Си

SSD1306_I2C.h:
const unsigned char PROGMEM init[18]=    //МАССИВ ДЛЯ ИНИЦИАЛИЗАЦИИ
{ 
...
};

А затем:
в main.h добавить

#include ‹avr/pgmspace.h›

иначе опять будет ругаться, но уже по другому.