ВАРИАНТ ТЕСТА ПОСЕГМЕНТНОЙ ПРИВЯЗКИ
бит ОЗУ к реальным сегментам для индикатора на основе контроллера НТ1621
с применением адуринки.
Довольно часто попадаются ЖКИ дисплейчики с различными конструктивами и разводкой сегментов индикатора относительно внутреннего содержимого ОЗУ контроллера HT1621.
Производитель может подключать сегменты в любом, выгодно-оптимальном с точки зрения производства и/или особенностей применяемого в устройстве-доноре программного обеспечения.
По факту нам уже достается какое-то готовое изделие, которое надо с максимальной пользой для себя обратить в прикладную самоделку.
Протокол и подключение внешних шин управления обычно явно известны, в вот какому сегменту какой бит ОЗУ соответствует и в какой последовательности они на реальном дисплее следуют — это и есть задача прикладного теста.
Далее на основе полученных данных можно и конкретный прикладной знакогенератор строить и соответствующие прожки обработки данных.

Для теста привязки нам понадобится ардуинка (нано или про-мини или еще какая из простейших), собственно сам дисплейчик, терминалка (встроенная в ардуино IDE или стороннего производителя) и распечатка шаблона с сегментным полем и полем адресного пространства ОЗУ HT1621.

Суть теста.
Прогоняя по ОЗУ последовательно активную единичку, сопровождаемую выводом в окно терминала записи о номере ячейки с активной единицей отмечаем карандашиком на карте сегментов и на карте адресов ОЗУ соответствие вручную.
Информация в окошке терминала обновляется через 1-2 секунды в кольцевом режиме.
Заранее стоит отметить, что не всем позициям ячеек ОЗУ будет соответствовать физический сегмент ЖКИ.
Также не следует ожидать непрерывности размещения данных — это уж как изготовитель заложил, так и будет.

В самом тесте используется программный ногодрыг.
Для работы с загрузчиком НТ1621 принимаем упрощенный протокол, каждый раз высылающем в дисплей ВЕСЬ массив ОЗУ (а не потетрадную загрузку) с всего лишь одним командным словом. Также используется однократно блок начальной инициализации дисплея и функции Serial.
ОЗУ индикатора представляем не как тетрады, а как единое пространство в 128 бит, представленное 16 байтовым буфером outbuf.

Итак...
Пустографка (в моем случае 10-позиционный 7-сегментный индикатор (файл kasdis_stest0 в splan) ).
http://img.radiokot.ru/files/20529/1kjtd4jdeq.GIF
Собственно схемка макета:
http://img.radiokot.ru/files/20529/1kjtd5hok2.GIF
она же в файле ard168_stest в формате splan в приложениях.
Теперь собственно сама программа...

Спойлер

Предполагается вывод на консоль терминала данных о положении текущего активного сегмента.
С этой части программы и начнем.
Собственно нам необходимо с определенной периодичностью выводить на дисплей терминала сообщение типа « в данный момент активен сегмент соответствующий биту» и значение номера бита в формате 0хNN.
Благо предоставленный средой арсенал средств позволяет это сделать весьма просто.

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

В верхней части оставим местечко для объявления констант и самодельных функций (легче будет при «окультуривании» в дальнейшей доработке программы).
У меня там закомментированная строчка для будущей доработки.
В разделе setup активируем последовательный интерфейс терминала:

Код:

void setup() {
   Serial.begin(9600); // запуск последовательного интерфейса
  // put your setup code here, to run once:
 }

В разделе основной прожки создадим

Код:

void loop() {
  // put your main code here, to run repeatedly:

  for (byte a=0; a<256; a++)
  {
  Serial.println("в данный момент активен сегмент, соответствующий биту");
  Serial.print("0x"); Serial.print(a,HEX); Serial.println("");
 
  delay(500);
  }
}

Проверим, скомпилируем и зальем этот тест в ардуинку.
После запуска должна выводится строчка сообщения и текущий двоичный код байта счетчика в диапазоне 0x00 – 0xFF .

При компиляции вылезло замечание по поводу byte в качестве определения типа для счетчика.
Пришлось для “кошерности» поменять на int.
Итогом получилось

Код:

 for (int a=0; a<256; a++)

в остальном тест вывода контрольного сообщения прошел вполне успешно.

Теперь можно приступить к созданию собственно теста.
Объявления констант, переменных и определение функций public вида размещаем в верхней части исходника
ДО вызова
void setup(){ }
а реализацию функций public вида пишем ниже завершающей скобки

void loop() {
}

Тем самым наши заготовки подпрограмм будут выведены за пределы основных циклов программы и более подготовлены к выносу во внешние файлы.

Итак...
начнем со схемки.

Подключение дисплея проводится во трем линиям:

WR\ - строб записи конкретного бита, активный уровень 0, запись выполняется по заднему фронту (переход из 0 в 1). Исходное состояние =1 (линия деактивирована).
DATA — собственно линия данных. Исходное состояние =1 (линия деактивирована). Во время обмена на данной линии находится состояние текущего бита данных.
CS\ - строб выборки кристалла,активный уровень 0 дает возможность доступа к линиям WR\ и DATA со стороны управляющей системы. Исходное состояние =1 (линия деактивирована).

Сама HT1621 имеет весьма развитую систему команд.
Собственно даташит в файле HT1621.pdf приложений.
Однако для тест-контроля и простейшего применения достаточно команд начальной инициализации и блочной записи.
Исходя из вышеуказанного...

Объявляем константы (НЕ переменные!) в соответствии с именами линий управления/ввода

Код:

 #define  data 10 // соответствие номеру вывода D10
 #define  wr 11 // соответствие номеру вывода D11
 #define  cs 12 // соответствие номеру вывода D12

объявляем константы в соответствии с применяемыми в тесте командными словами

Код:

 #define  biass  B00101000 // LCD 1/2 bias option, 4 common option
 #define  clc_on  1 // пуск системного генератора
 #define  lcd_on  3 // turn ON  LCD bias generanor

объявляем переменные общего доступа

Код:

  byte ln_dat = data; // переменная со значением номера вывода линии данных
  byte ln_wr = wr; // переменная со значением номера вывода линии строба записи
  byte ln_cs = cs; // переменная со значением номера вывода линии строба выборки кристалла
  byte bufout[ ] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}; // массив буфера данных для пакетной загрузки

объявляем примитив-функции для операций обмена

Код:

// начальный статус линий интерфейса (он же и заглушка завершения пакета)
  void stop_pack ();

// строб сопровождения данных
  void data_clock();

// запись заголовка с составляющими командными словами для активации режима дисплея
  void wr_uksda(byte a,byte b,byte c);

// запись байта команды
  void trs_com(byte);

// запись пакета bufout (в комплекте с командным заголовком)
  void wr_ksda();

// блок вращения бита в массиве
  void rotor_16();

В разделе setup добавляем (с расчетом на возможне перемещение в блок сетапа драйвера для библиотеки в будущих вариантах реализации программы):

Код:

     pinMode(ln_dat, OUTPUT);
     pinMode(ln_wr, OUTPUT);
     pinMode(ln_cs , OUTPUT);

Теперь переходим к самим функциям, вернее в самый них исходника и создаем РАЗДЕЛ РЕАЛИЗАЦИИ:

Код:

/*
    здесь размещаем реализацию наших функции - подпрограммок
    используемых в вышерасположенных void setup() , void loop() а также
    наши самодельные функции поменьше, используемые при реализации более крупных
    собственно всего того, что заявлено выше в разделе
    описанием (определением) применяемых в программе самодельных функций
*/

// начальный статус линий интерфейса (он же и заглушка завершения пакета)
//подразумевается, что линия  ln_wr уже установлена в 1 или при начальной
// инициализации или по завершении строб-импульса

  void stop_pack ()
{
  digitalWrite(ln_dat, HIGH);
  delayMicroseconds(6);
  digitalWrite(ln_cs, HIGH);
}


// строб сопровождения данных
  void data_clock()
{
     digitalWrite(ln_wr, LOW);
     delayMicroseconds(3);
     digitalWrite(ln_wr, HIGH);
     delayMicroseconds(3);
}

Несколько о задержках — ардуинка на основе меги с кварцем в 16 МГц штука весьма быстроходная по сравнению с НТ1621. Посему добавлены маахонькие задержки в операциях дрыголапа.
Почему именно программный дрыголап, а не функция Serial или shiftOut ?
В одном случае аппаратная привязка к линиям обмена да и сигналы обмена иные, в другом не совсем байтовый протокол и возможность свободно управлять нужными в собственном определении линиями.
Вобщем некритично — при отсылке пакета можно и shiftOut добавить после командного заголовка — это на усмотрение повторяющих/модернизирующих базову прожку под свои интересы.

Код:

// запись байта команды (может быть выполнена как shiftOut)
  void trs_com(byte com_word)
{
  digitalWrite(ln_dat, bitRead(com_word,7));
  data_clock();
  digitalWrite(ln_dat, bitRead(com_word,6));
  data_clock();
  digitalWrite(ln_dat, bitRead(com_word,5));
  data_clock();
  digitalWrite(ln_dat, bitRead(com_word,4));
  data_clock();
  digitalWrite(ln_dat, bitRead(com_word,3));
  data_clock();
  digitalWrite(ln_dat, bitRead(com_word,2));
  data_clock();
  digitalWrite(ln_dat, bitRead(com_word,1));
  data_clock();
  digitalWrite(ln_dat, bitRead(com_word,0));
  data_clock();
  data_clock(); // стробирует девятый бит командного слова (его состояние безразлично)
}

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

Код:

 #define  clc_on  1

Код:

// запись заголовка с составляющими командными словами для активации режима дисплея
  void wr_uksda()
{
  digitalWrite(ln_cs, LOW);
  delayMicroseconds(6);
  data_clock(); // линия  ln_dat предварительно была в состоянии 1 !!!
  digitalWrite(ln_dat, LOW);
  data_clock();
  data_clock(); // преамбула "запись команд" 100
   trs_com(biass); // LCD 1/2 bias option, 3 common option
   trs_com(clc_on); // пуск системного генератора
   trs_com(lcd_on); // включить LCD bias generator
   stop_pack();
}

Хотя... а почему бы те параметры не ставить при вызове самой wr_uksda?

Тогда несколько изменим и объявление и реализацию:

добавим три значения команд размером в байт

Код:

  void wr_uksda(byte,byte,byte);

и изменим реализацию – заявим три переменных byte a,byte b,byte c а затем подставим эти внутренние переменные как константы при вызове функций trs_com(...)

Код:

 void wr_uksda(byte a,byte b,byte c)
{
  digitalWrite(ln_cs, LOW);
  delayMicroseconds(6);
  data_clock();
  digitalWrite(ln_dat, LOW);
  data_clock();
  data_clock(); // преамбула "запись команд" 100
   trs_com(a); // LCD 1/2 bias option, 3 common option
   trs_com(b); // пуск системного генератора
   trs_com(c); // включить LCD bias generator
   stop_pack();
}

Следующая подпрограммка пересылает ВЕСЬ массив данных из bufout в контроллер дисплея

Код:

/* пересылка данных в ОЗУ дисплея из ОЗУ  bufout
* без разрушения содержимого  bufout
 */
 void wr_ksda()
{
  digitalWrite(ln_cs, LOW);
  delayMicroseconds(6);
  data_clock();
  digitalWrite(ln_dat, LOW);
  data_clock();
  digitalWrite(ln_dat, HIGH);
  data_clock(); // преамбула "запись ОЗУ" 101
  digitalWrite(ln_dat, LOW);
  for (byte cnt=0; cnt<=5; cnt++)
      {
          data_clock(); // начальный адрес (6бит) = 0
      } // отсылаем начальный адрес пакета
//заголовок-преамбула завершен, далее собственно пошли данные
  for (byte cnt=0; cnt<=15; cnt++)
  {
    // неразрушающая обработка байта с пересылкой
    digitalWrite(ln_dat, bitRead(bufout[cnt],0)); // бит 0 текущего байта
    data_clock();
    digitalWrite(ln_dat, bitRead(bufout[cnt],1)); // бит 1 текущего байта
    data_clock();
    digitalWrite(ln_dat, bitRead(bufout[cnt],2)); // бит 2 текущего байта
    data_clock();
    digitalWrite(ln_dat, bitRead(bufout[cnt],3)); // бит 3 текущего байта
    data_clock();
    digitalWrite(ln_dat, bitRead(bufout[cnt],4)); // бит 4 текущего байта
    data_clock();
    digitalWrite(ln_dat, bitRead(bufout[cnt],5)); // бит 5 текущего байта
    data_clock();
    digitalWrite(ln_dat, bitRead(bufout[cnt],6)); // бит 6 текущего байта
    data_clock();
    digitalWrite(ln_dat, bitRead(bufout[cnt],7)); // бит 7 текущего байта
    data_clock();
  }
  stop_pack();
}

Замечание:
Команды и адреса пересылаются СТАРШИМИ битами вперед, а данные — МЛАДШИМИ!

Блок пересылки только для теста — в реальности из-за возможных вариаций с привязкой бит к конкретным сегментам вероятнее всего потребуется дополнительный модуль «перетасовки» и/или несколько измененный передатчик (с учетом незначащих, но требуемых к пересылек бит массива).

Следующая прожка основа «бегущей 1» - смещение бита в массиве.
Под ассемблером эта задача весьма легко решается, а вот в Си без использования библиотек и ассемблерных вставок (простоначинающему) достаточно досадки доставляет...

Код:

// блок вращения бита в массиве
  void rotor_16()
{
  byte b = 0; static byte a = 0; // описываем  и проводим начальную инициализацию передаточных флагов
        // как  static переменной a - флаг предыдущего переноса из бита 7,
        //  и обычной переменной b — флаг (рвх) текущего переноса из бита 7
  byte c; // буфер обработчика
   for (int x=0; x<=15; x++)
    {
       c = bufout[x]; // читаем элемент массива в буфгр обработки
       b = bitRead(c,7); //  b может принять значения 0 иди 1
       c = c << 1; // сдвиг данных
       c = c | a; // запись содержимого а (0000000N) в бит 0 с
       bufout[x] = c; // вернуть новое значение в элемент массива
       a = b; // скрпируем текущий флаг переноса из  b в а
     }; // и повторим это для всех 16 байт массива
 }

Вот пока все компоненты собраны.
Можно прожку теста продолжить. Чего выявится по ходу работ добавим.

В разделе setup
добавляем начальную инициализацию состояния выволов:

Код:

  digitalWrite(ln_cs, HIGH); // исходное состояние = 1
  digitalWrite(ln_wr, HIGH); // исходное состояние = 1
  digitalWrite(ln_dat, HIGH); // исходное состояние = 1

Далее нужно запустить работу индикатора и ввести туда исходное значение «все сегменты погашены»

Код:

   wr_uksda(biass, clc_on, lcd_on);
   wr_ksda(); // начальная инициализация дисплея "все погашены"
   Serial.println("Test of the determination of the segment to bit OZU"); // Тест посегментной привязки бит ОЗУ
   Serial.println("For indicator on base of the controller HT1621"); // Для индикатора на основе контроллера НТ1621
   
  delay(1000);

Далее пишем сам «вечно вертящийся по кругу» тест в разделе loop

Код:

 bufout[15] = 0x80; // начальная активация для предустановки значения static byte a = 0
   rotor_16(); // дубль - аналог перемещения бита из последней ячейки буферного ОЗУ
   // для устранения ошибок положения бита в цикле
  for (int a = 0; a <=127; a++)
  {
    rotor_16(); // перемещаем бит в следующую позицию
    Serial.println("at present active segment, corresponding to bit");
                 // "в данный момент активен сегмент, соответствующий биту"
    Serial.print("0x"); Serial.print(a, HEX); Serial.println("");
    wr_ksda(); // проводим вывод пакета в дисплей и сообщения в окно терминала
    delay(3500); // и после задержки в … секунды снова повторяем
  }

Нажимаем проверку м получаем заключение без всяких замечаний компилятора
3034 байт памяти и 355 байт ОЗУ...
…
ну да надо б проверить на макетке...
заливаю сей скетч в мою платку...

Сегменты забегали.
Но с такой скоростью...

Меняю задержку на 3500

Код:

delay(3500); // и после задержки в … секунды снова повторяем

и снова перекомпилируем и перезагружаем.
Теперь можно спокойненько следить и за сообщениями терминмла и за сегментами дисплея.
Заносим данные в пустографку.

Однако такой алгоритм не есть хорошо — в цикле все время выполняется начальная перезагрузка

Код:

   bufout[15] = 0x80; // начальная активация для предустановки значения static byte a = 0
   rotor_16(); // дубль - аналог перемещения бита из последней ячейки буферного ОЗУ

желательно бы от оной избавится...
Возможно на основе замены цикла на основе FOR на цикл на основе IF или
DO – While дабы получить полноценный кольцевой цикл перемещения битика.

Исходник несколько подправлен заменой текста сообщение на латиницу — дабы на любом компе и с любым терминалом читалось одинаково.
НО...ТО уже опосля первомайских застолий...

и все вышеизложенное в архивчике

А вот и несколько "более прилизанная" версия с уменьшенным объемом расходов памяти
(2730 байт ПЗУ и 356 байт ОЗУ)

Кстати...
Сама адуринка УЖЕ имеет инструменты для реализации встроенного ICD - внутрисхемного отладчика для контроля за работой программки (СКОТтча)...
А ни в одной из "популярных" книж о том ... ни полслова ни намяка...

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

Если речь о debugWIRE то во первых, ArduinoIDE не поддерживает отладку, а во вторых есть ограничения. С такими ограничениями, отладка может быть не такой простой как хотелось бы.

Документацию на МК нужно читать.

Организация питания на основе надежных литиевых аккумуляторов EVE и микросхем азиатского производства

Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.

Подробнее>>

Речь идет об использовании средств, заложенных в обязательном минимуме АРДУИНО IDE (программный ICD), а не об аппаратном варианте реализации ICD.
А посему и ограничения зависят ТОЛЬКО от мозга программиста и описание не в даташите, а у составителя программы (СКОТча) узнать можно.

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

Что-то я не заметил в ArduinoIDE возможности отладки. Или речь про отправку данных в USART? Это вовсе не внутрисхемная отладка, в том смысле в каком она обычно подразумевается. К микроконтроллеру подключается аппаратный отладчик и программа выполняется под его управлением.

Верно в том, что не аппаратный модуль, а программный интерактивный обмен через порт , используемый для связи с терминальной программой.
Однако результат для практики весьма существенный.
И во многом подобен по функционалу аппаратному - все зависит от программиста.

Можно расставить программные ловушки - маркеры и или ограничится пересылкой контрольных параметров в точках останова или добавить свой вариант обратной связи при отсылке данных из терминла ПК.
Собственно базовые функции обмена у нас имеются. А сама платка ардуино представлена в виде самостоятельного изделия.
Не воспользоваться такой возможностью - великая УПУЩЕНИЯ (мягко говоря).

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

При если нужно добавить или убрать их или переместить в другое место программы, потребуется вносить изменения в код и перекомпилировать программу. С аппаратным отладчиком, ничего этого не нужно. Просто кликаете по строке с кодом и аппаратный отладчик сообщит отладочному модулю внутри МК что при выполнении инструкции с определенным адресом нужно остановить программу, т. е. точки останова аппаратные и их можно ставить и/или убирать во время отладки без остановки программы и ее перекомпиляции.
А представьте что вам потребуется посмотреть что находится в одной или нескольких переменных или регистрах (в каких заранее неизвестно), при условии что нельзя перезапустить программу (допустим отслеживаете редко происходящий сбой). Аппаратная отладка позволит посмотреть что находится в любой переменной или регистре без перезапуска программы.
Понимаете в чем разница?

Верно - "истинным" аппаратным не пользовался, а вот встроенным в код программы - весьма часто.

Насчет сложности - единственно с необходимостью перезагрузки программ дополнительная проблема.
Так после теста все равно контрольный участок или переделывать или тест дальше перемещать надо.
Под ассемблером весьма мощное средство.

В отношении адуринки даже такой способ (встроенные тест-точки) весьма эфективен ибо в самой IDE дебаггера ни программного ни аппаратного нету.
А скомпилированный без ошибок исходник (отсутствие замечаний компиляятора) не всегда выполняет необходимые функции в макете - в таком случае метод программных точек контроля с использованием уже существующего аппаратного интерфейса и функций поддержки обмена данными с встроенным терминалом IDE представляется весьма полезным инструментом.

В продолжение садизма над адуринкой и моим вариантом НТ1621 с "дырчато-разбросанными" по ОЗУ сегментами

Однако по затратам мозговремени строчка удачного кода мало отличается от строчки под ассемблером сотворенной...

Как из "грязного" исходника сделать чуток более "кошерный" и с более многоцелевым применением (добавление библиотек в текущей папке проекта).

Это больше тренировочный проектик для освоения навыков обращения со средствами IDE по собственному усмотрению (а не копипастить чужие скотчи/библиотеки).

Тест платки 8-разрядного 7-сегментного дисплейчика на основе MAX7219 и адуринки-нано.
Режим декодера двоично-десятичных тетрад, черновик.

Добавлю ешше один "тестик с заковыркой" - собственно идея добавки так любимого секундного таймера (параллельный процесс на прерываниях) сделанного с учетом ранее оговоренных ограничений ("использование исключительно того, что предлагается средствами IDE").
В схемку добавлена перемычка (синенькая на рисунке). Пока только отсчет без кнопы управления ибо там также некоторые отличия от типового ассемблерного варианта должны бысть.
Собственно проектик:



А вот и "полноценный секундомер" с кнопкой, последовательное нажатие на которую выполняет функционал
"старт" - "стоп" - "сброс" и по кругу за сбросом - следующий старт.

На просторах инета нашел весьма неплохой учебничек по ардуиньевой IDE
"Справочник языка для программирования Ардуино"
https://flprog.ru/uchebnyj-centr/dokume ... ammirovan/
одно плохо - нормально открывается только на мониторе при разрешении от 1280*1024...
При стандартном 1024*768 "сжирается" вторая половинка разворота книжи вместе с управляющими кнопами...


Начальный период разгрызания "Си для ардуиний" в объеме для смаостоятельной работы с прикладной схемотехникой можно считать оконченным.


Относительно "кошерности" в оформлении исходников (СКОТчей)...
Вынос материала в подключаемые файлы (за пределы основного файла) выполняется по стандартной схеме "рамочной заготовки".
Сами файлы могут размещаться как в папке проекта (тогда они видимы во вкладках собственного редактора IDE при открытом проекте), так и в виде отдельных папок в каталоге
C:\Documents and Settings\User\Мои документы\Arduino\libraries
в этом случае их можно сопроводить еще файликом определения подсветки синтаксиса keyword.txt
В самом файле проекта для подключения библиотек можно воспользоваться или соответствующей кнопой IDE или оставить те же строки, что и при создании начальной заготовки проекта.
Как пример ранее изготовленный сегментный тест для НТ1621 с вынесенными в отдельные папочки библиотеками драйвера зсгрузки дисплея (myHT1621) и обработчиком знакогенератора (znak7).

После распаковки архива те папки нужно из папки проекта скопировать в папку
C:\Documents and Settings\User\Мои документы\Arduino\libraries
Изолированные в отдельные папки внутри папки проекта файлы в окне редактора IDE не отображаются (если их туда не втащить принудительно кнопой "скетч" -> "добавить файл".

Попалась еше одна железячка из дисплейных мелкосхемок.
китаяска ТМ1637 (https://radiokot.ru/forum/viewtopic.php?f=61&t=155104)...
Даташиты вроде как на эту мелкосхемку имеются


Но уж столь смуторные...
Заявлена та мелкосхемка как I2C... Однако при ближайшем рассмотрении подопытного экземпляра
http://img.radiokot.ru/files/20529/1lioko5xzj.jpg
http://img.radiokot.ru/files/20529/1liokp92js.jpg
цвет свечения сегментов - зеленый.
Обнаружились досадны вопросы...
Первое отличие (как уже было сказано в вышеупомянутой теме) это передача младшими битами вперед.
О таком "нюансе" говорит разве что прожка-образец из "урезанного" даташита (в более наоом и этого нету).
Второе - некоторые вольности относительно NO ACK в конце пакета. АСК передается ИСКЛЮЧИТТЕЛЬНО ВЕДОМЫМ.
Далее - в ТМ1637 предусмотрен режим сканера клавиатуры, но в конкретной модели индикатора оного не предусмотрено.
Из шести возможных позиций дисплея используется всего 4.
Поначалу думал, что децимальные точки и точки-разделители еще одну или две позиции занимают...
Однако после посегментного теста весьма огорчился:
точки-разделители это разряд H ячейки памяти второй позиции дисплея, а децимальные точки ВООБЩЕ ОТКЛЮЧЕНЫ.
Да и яркость даже "на максимуме" не сравнить с MAX7219.
Вобщем ОГОРЧЕНИЕ однако...
Схема посегментного теста и прожка для адуринки-нано прилагается
http://img.radiokot.ru/files/20529/1liokq3f6k.GIF

а вот такая раскладка сегментов по ОЗУ у моего "подопытного мыша"
http://img.radiokot.ru/files/20529/1liokkatb4.GIF
Надо будет еще набросок счетчика примитива сделать...
Да попробовать имеется ли РАЗДЕЛЬНОЕ управление по каждому знакоместу...
Но то завтра-послезавтра... Честно качество свечения сегментов усе настроение испортило...


УПС...
В задержках поставил delay() вместо delayMicroseconds()...

Ну да и ладно - в приведенном ниже простом демо-тесте (на индикаторе последовательно-шустрый перебор от 0000 до 9999) исправлено.

Собственно там используется ранее сделанная библиотечка znak7 и активированы номера сегментов согласно моей карте раскладки.
На всякий случай положил все файлы в одну папку - дабы небыло матюков по подключаемым файлам (хотя вполне работает и с "кошерно установленной" библиотекой).

Кстати...
Вопрос по корректной обработке АСК так и остался в стадии проверок...
Именно относительно этого ТМ1637.
С графикой в даташите "не очень" а что ни прожка - то своя трактовка "в нюансах".


Однакт таки "крышу сносит" от "китайских особенностей"...
Мало того, что диаграммы смуторные... так ешшо и часть данных относительно того АСК... мягко говоря вообще на 9 строб-бит смахивает...
"кошерный" фрагмент с полным обходом квитирования (как в большнстве прожек для того ТМ1637):

Спойлер

Код:

byte data_write (byte trs_dat, byte trs_flg)
{ byte tmp=0; unsigned long tmp_er;
 pinMode(dat_pin, OUTPUT);digitalWrite(dat_pin, LOW);
 delayMicroseconds(6);digitalWrite(clk_pin, LOW);delayMicroseconds(6); // старт
 for (byte cnt=0; cnt<8; cnt++)
  {
    digitalWrite(dat_pin,bitRead(trs_dat, cnt));
    delayMicroseconds(6);
    digitalWrite(clk_pin, HIGH);
    delayMicroseconds(6); // строб бита
    digitalWrite(clk_pin, LOW);
  }
  /*
   * длительность интервала от перевода шины dat_pin в режим
   * ввода после заднего фронта CLK в документации не оговорена !!!
   */
  digitalWrite(dat_pin, LOW);pinMode(dat_pin, INPUT);
  delayMicroseconds(2);
//----------???????????----------
  tmp_er=millis();
  while (digitalRead(dat_pin)) // ждем начала импульса АСК
 {
   if ((millis() - tmp_er) >= 100)
   {
     tmp=1; // запись статуса "ошибка АСК" в возвращаемый флаг (tmp=1)
     break; // автосброс при ошибке ожидания /АСК ответа модуля более 10 миллисекунд
   }
 }
//----------???????????----------
  digitalWrite(clk_pin, HIGH);delayMicroseconds(5);
  digitalWrite(clk_pin, LOW);delayMicroseconds(4); // строб АСК
   if (trs_flg) // при trs_flg=1 отрабатывается статус СТОП
    {digitalWrite(clk_pin, HIGH);delayMicroseconds(5);
    pinMode(dat_pin, OUTPUT);digitalWrite(dat_pin, HIGH);delayMicroseconds(5);}
   return tmp; // при trs_flg=0 выход с dat_pin=INPUT
}

НО...
в работе индикатора АБСОЛЮТНО ничего не изменится, если "выкусить" все касающееся проверки появления АСК и предшествующий перевод шины данных на ввод:

Спойлер

Код:

byte data_write (byte trs_dat, byte trs_flg)
{ byte tmp=0; unsigned long tmp_er;
 pinMode(dat_pin, OUTPUT);digitalWrite(dat_pin, LOW);
 delayMicroseconds(6);digitalWrite(clk_pin, LOW);delayMicroseconds(6); // старт
 for (byte cnt=0; cnt<8; cnt++)
  {
    digitalWrite(dat_pin,bitRead(trs_dat, cnt));
    delayMicroseconds(6);
    digitalWrite(clk_pin, HIGH);
    delayMicroseconds(6); // строб бита
    digitalWrite(clk_pin, LOW);
  }
  /*
   * длительность интервала от перевода шины dat_pin в режим
   * ввода после заднего фронта CLK в документации не оговорена !!!
   */
  digitalWrite(dat_pin, LOW);  // pinMode(dat_pin, INPUT);
  delayMicroseconds(2);
//----------???????????----------
/*  tmp_er=millis();
  while (digitalRead(dat_pin)) // ждем начала импульса АСК
 {
   if ((millis() - tmp_er) >= 100)
   {
     tmp=1; // запись статуса "ошибка АСК" в возвращаемый флаг (tmp=1)
     break; // автосброс при ошибке ожидания /АСК ответа модуля более 10 миллисекунд
   }
 }*/
//----------???????????----------
  digitalWrite(clk_pin, HIGH);delayMicroseconds(5);
  digitalWrite(clk_pin, LOW);delayMicroseconds(4); // строб АСК
   if (trs_flg) // при trs_flg=1 отрабатывается статус СТОП
    {digitalWrite(clk_pin, HIGH);delayMicroseconds(5);
    pinMode(dat_pin, OUTPUT);digitalWrite(dat_pin, HIGH);delayMicroseconds(5);}
   return tmp; // при trs_flg=0 выход с dat_pin=INPUT
}

т.е. достаточно просто прижать шину данных к "gnd" и дать девятый строб.
А вот любая попытка отловить окончание нулевого уровня, генерируемого ТМ1637 обречена на "одурение" микросхемы с произвольной смесью сегментов на дисплее...

Вобщем... принял за основу "кошерный" вариант для перестраховки...

Снова напомнилось о схемке датчика нуля фазы сетевого напряжения...
https://radiokot.ru/forum/viewtopic.php ... 7#p3391077
Решил таки проверить...
Правда несколько перестрахерился, да из "подсобного материала" макет накрутил:
http://img.radiokot.ru/files/20529/1lpxqmvhjp.GIF
http://img.radiokot.ru/files/20529/1lpxkokk4n.jpg
у 4N35 добавлен резистор на базу (согласно рекомендаций по ешшо советским оптронам), диоды моста оказались (по результатам испытаний) явно завышенных параметров. Конденсатор С1 также "из подручного" 2200pF поставил (вместо 1000pF на исходной схеме).
Деталюшки моста в принципе могут бысть всего 100 вольтовыми (при 220 входного реально там вольтметр больше 5 вольт на R3 не показывает, теоретически до 20 вольт возможно). Одноватные советские резисторы (R1, R2) АБСОЛЮТНО ХОЛОДНЫЕ после 3-4 часов непрерывного включения в закрытой коробушке. При подключении от 115 вольтового трансформатора индикация работы (по светику) сохраняется, но осциллограмму не смотрел.
Осциллографом смотрел только для 220 вольтового режима - несколько "скошен" нижний конец переднего фронта импульса (в пределах логического нуля), длительность импульса примерно 0,5 mS.
Вобшшем... понравилось...
Положил в коробушку "про запас".

нусхема вообщемто извесная в 80-90х....пожже уже не применялась изза ряда причин-есть MOCсерия оптронов с детектором

Интересно было перепроверить.
Гуляло весьма много вариантов - "на запирание" как-то непривычно смотрится, да и диапазон допуска по входному напряжению интересно поглядеть.

Это для фазоимпульсных извратов с МК.

Архив с редактором DPAD из моих архивных коллекций
(да не в обиду автору проекта - к сожалению сайта-первоисточника уже давно нету, а редактор весьма удачный )
https://yadi.sk/d/oQ964HBC3Xe4Fa
разбирайте, кому интересно!

Новости от МИКРОЩИПА:
https://www.rlocman.ru/news/new.html?di=506789
"08-06-2018
Новые семейства микроконтроллеров PIC и AVR повысят эффективность замкнутых систем управления
Microchip » PIC18 Q10, ATtiny160
..."
конкретно
https://www.rlocman.ru/i/File/2018/06/1 ... 02030A.pdf
https://www.rlocman.ru/i/File/2018/06/1 ... 01945B.pdf
...

ГРЮСТЬНО...