Форум arduino.ua

Можна порівняти напругу в ненавантаженому стані та в навантаженому на кілоомний резистор. А також, про всяк випадок, на цей же резистор, тільки підтягнутий до 5В. Це якщо там раптом відкитий колектор, але транзистор PNP з підтяжкою до землі.   

Хм, як же так? Про що думали розробники?

Тоді треба поставити. На компараторі, або мікросхему логіки з ТШ на вході, або з двох транзисторів зліпити. Ну і glitch filter той на GPIO увімкнути.

Можна і програмно-апаратний гістерезис реалізувати: підʼєднати до входу інший GPIO вихід через резистор на кілька десятків кілоом, подати на нього нуль. Як тільки задетектили на вході високий рівень - видати на цей GPIO одиницю. Як задетектили низький - видати знову нуль, і т.д.. Але цей метод працюватиме лише в комплексі з маскуванням переривання на період обробки.

Ну, одна справа - ловити переривання і викликати обробник, але нічого в ньому не робити, а інша - вимикати це переривання взагалі.
На перший погляд різниці ніякої, але в деяких специфічних випадках краще вимикати.

Якщо там на вході нема ТШ, то й мілівольтних пульсацій в живленні може бути достатньо, щоб на "чистому" сигналі ловити хибні фронти. Конденсатор в такому випадку навпаки робить гірше.

Ну, дивлячись що аналізатор сприймає за спад. Якщо ESP32 сприймає низький рівень вже при половині живлення (1.6 В), а аналізатор, наприклад, лише при 0.8 В, то воно так і буде відображатись.

Верхній кінець R23 до джерела імпульсів підключений? У джерела пушпульний вихід чи відкритий колектор з підтяжкою?

Не шарю в фреймворку ESP32, тому питання: цей обробник в контексті переривання виконується чи в контексті задачі?
Якщо в контексті переривання, то так:

робити не варто.
Крім того, всі інші функції, які викликаються з обробника, також має бути дозволено викликати в контексті переривання.

Можна програмний debouncing реалізувати. Як задетектували очікувану подію, вимкніть це переривання. Потім по таймеру знову вмикайте. Тільки якщо там не level-triggered переривання, а лише edge-triggered, то звісно, перед вмиканням потрібно атомарно перевірити, чи вже не сталась очікувана подія, щоб її не пропустити.

В якості кишенькового користуюсь FNIRSI 1C15. Інтерфейс не дуже зручний, але в решті більш-менш норм.

Ну, по входу GPIO він уже вбудований має бути. Також у ESP32C3 наче ж є hardware glitch filter.

10 mA - це в районі максимума CTR. І то, максимум може бути від 5 до 15 мА, в залежності від виробника та версії.

Ось PC817S, 0x55 на 9600 бод,
TX: CP2102 3.3 В, резистор 2.2 кОм,
RX: CH341A 5 В, резистор в колекторі 2.2 кОм:

Два трансивера взяв навмисне, щоб були різні тайм референс. Все на макетці зі жмутом проводів.

Може у вас від ESP32 TX через якийсь послідовний резистор, або десь велика паразитна ємність.

Ну, запрацювало, то й добре. Лише майте на увазі, якщо у вас працює лише на максимумі, при постійній інтенсивній передачі через кілька років кристал деградує, і може перестати працювати.

Між чим і чим ви хочете гальванічну розвʼязку?
Вважаючи, що

то поки складається враження, що між ESP32 та DS2480B. Тоді до чого тут розширювач портів?

9600 бод через PC817 у мене пролазили без жодних проблем.

Ну ось вам пайтон скрипт, що передає дві послідовності позмінно кожні півсекунди:

#!/usr/bin/env python

import sys
import serial
import serial.tools.list_ports
import time

if len(sys.argv) > 1:
    port = sys.argv[1]
else:
    port = next((
        port.device for port in serial.tools.list_ports.comports()
    ), None)

if not port:
    print('No ports found', file = sys.stderr)
    sys.exit(1)

print(f"Using {port}")

ser = serial.Serial(port, 115200)

delay = 0.5

try:
    while True:
        ser.write(bytes.fromhex('AE 01 FF FF 00 00 02 03 3C FF FF 0A FF EF'))

        time.sleep(delay)

        ser.write(bytes.fromhex('AE 01 FF 00 00 FF 02 03 3C FF FF 0A FF EF'))

        time.sleep(delay)

except KeyboardInterrupt:
    sys.exit(0)

finally:
    ser.close()

Порт можна вказати аргументом командного рядка, а якщо запущено без параметрів, то пише у перший знайдений порт.

Деякі протоколи передають колір в HSV форматі, або RGB і HSV одночасно. Також можуть передаватись бітові поля вимкнено/увімкнено, номери еффектів і т.д..

Ось загуглив по такому запиту: "Tuya or similar LED control subprotocol, payload 12 or 14 bytes, RGB HSC and effects bit fields. Command values: 0xAE, 0x7E. Subcommand values for 0xAE: 0x01, 0xA4, 0xA1".
ШІ видало, поміж іншого:

Але випитати у нього, з якого документа чи кода взята ця інформація, мені не вдалося. Посилань ніяких не дає.

Цей опис наче частково співпадає з тим, що спостерігається у вас, але не повністью. Розробники могли взяти його за основу, але повикидати якісь одні поля і додати інші.
До того ж, такі фрейми з опису передаються як payload в Tuya Serial MCU Protocol, із заголовком який містить поле довжини. Тобто MCU знає розмір фрейма. У вас же фрейми без цих заголовків, так що мабуть, їх довжина фіксована для кожної підкоманди.   

Шанси знайти адекватну інформацію зростуть, якщо шукати по назві виробника і конкретній моделі LED-контролера. Контролера як цільного виробу, а не чіпа MCU який в ньому використовується.

Так це ж треба звідти експортувати ті байти, порівнювати, тобто проводити повноцінну дослідницьку роботу.

Вибачте, але ні.

Тут ідуть по два пакети "AE A4" та "AE 01".
А чи передається в цей час щось у зворотній бік, на іншій парі TX/RX?

EF, скоріш за все - маркер кінця пакета.

Тут уже тільки "AE 01 ..."

Зауважте, при перемиканнях видно пакети з іншим початком та довжиною:

7E FF 04 01 FF FF FF FF EF // 10
7E FF 05 03 00 FF 00 FF EF // 20
7E FF 05 03 00 00 FF FF EF // 30
7E FF 05 03 FF FF FF FF EF // 40
7E FF 01 31 00 FF FF FF EF // 50
7E FF 01 2A 00 FF FF FF EF // 50
// потім при увімкненні білого, декілька поспіль кожні чверть секунди: 
7E FF 01 04 00 FF FF FF EF
7E FF 01 13 00 FF FF FF EF
7E FF 01 3A 00 FF FF FF EF
7E FF 01 5E 00 FF FF FF EF

за якими також зʼявляється "AE A1 ..."

AE A1 0A FF FF FF FF FF FF FF FF FF FF EF

Також зустрічається

0x6F 0xF6 0xFE 0x7E 0xF6 0xFE 0x6E 0x7F 0x76 0xB7 0x76 0xB7 0x36 0x36 0x36 0x36 0xFE

але не дуже зрозуміло, чи це теж якісь команди, чи глюки синхронізації.

Якийсь пропрієтарний протокол, тисячі їх. Можете скормити ці данні якій-небудь LLMці, може знайде, що хтось уже розколупав саме такий і виклав у відкритий доступ. Успіхів у декодуванні.

А, побачив архів з осцилограмою. Так, там serial 115200 бод.
Передається по дві посилки по 14 байт. Імовірно, що:

AE - заголовок
A4/01 - якийсь ідентифікатор. Можливо, адреса призначення.
12 байт - 3 канала RGBW або 4 канала RGB, або якийсь інший формат. Потрібно дивитись, як ці значення корелюють із тим, що виставляєте з телефону.

Схоже на проприєтарний Tuya LED subprotocol, що йде як payload в "Tuya Cloud Universal Serial Port Access Protocol". Тільки там аргументи для підкоманди 01 інші.

Мабуть же DMX512 (напис на платі натякає). Але це не точно.

Що таке "звичайне RGB-підсвічування"? 3-канальна ШІМ?

Наскільки можу зрозуміти з картинки, ті "байти" - це те, що аналізатор спробував декодувати як звичайний asynchronous serial. А там зовсім не факт що саме serial. Потрібно дивитись осцилограму і розпізнати, що там за протокол. Може й serial, але на іншому бодрейті, може якийсь інший стандартний, а може й проприєтарний. Це реверс інженеринг.
У цього блока є назва? Є якийсь опис чи user manual? Пошукайте по назві, може хтось уже розколупав його.

Те ж саме: потрібно сніфити bluethooth трафік і розпізнати, що там за протокол керування. Або шукати в інтернеті, може ця інформація вже є у відкритому доступі.

Поки щось не дуже зрозуміло, що ви хочете. У вас є якийсь безпровідний DMX контролер. Ви хочете замінити один із його MCU на зовсім інший, і щоб LLM написав для нього прошивку, яка би повторювала функції оригінального контролера і реалізовувала додаткові? Та ще й з використанням arduino фреймворка? Так воно навряд чи буде.
Для початку потрібно розуміти, які саме функції виконує цей девайс в оригінальному вигляді. Що там на вході "5-го контакту другої ST17H66B", DMX512?

Тому що в них присутні посилання на сторонні сторінки, форум таке чомусь іноді не пропускає.
Якщо на попередньому повідомлені натиснути "Цитувати", то деякий час їх можна побачити внизу.

Опція "--version" була видалена в esptool 5.0.0. Мабуть, thonny чи якийсь плагін для нього розраховує на esptool старішої версії.
Якби мені було потрібно розібратись в точній причині тієї помилки, під лінуксом я би відслідкував, хто там кого з якими параметрами запускає. Але як то у віндовс зробити, нажаль, не знаю.
Ну запустилось, то й добре

Ну питання було - чи можна скомпілювати різні частини з різними опціями, а не як зменшити розмір бінарика