может течёт на плохом линке?
 

#!/bin/bash
z='172.16.100.204'
p='10050'
t='0.1'
k="sys.all"

while [ 1 ]
do
  echo `date`
  echo $k1 | nc $z $p
  sleep $t
done

#include "ESP8266WiFi.h"


const char* ssid = "TestingAP";
const char* password =  "xx-xx-xx";

WiFiServer wifiServer(10050);

void setup() {

  Serial.begin(74880);

  WiFi.begin(ssid, password);

  Serial.print("Connecting to WiFi ");
  while (WiFi.status() != WL_CONNECTED) {
    delay(1000);
    Serial.print(".");
  }
  Serial.print(" IP:"); Serial.println(WiFi.localIP());

  wifiServer.begin();
}

void loop() {

  WiFiClient client;
  //  client.setDefaultSync(true);
  int32_t ramPrev = ESP.getFreeHeap();
  Serial.println(ramPrev);
  while (1) {
    yield();
    client = wifiServer.available();
    if (client) {
      while (client.available() == 0);
      while (client.available() > 0) {
        char charC = client.read();
        //Serial.print(charC);
        client.write(charC);
      }
      int32_t ramNow = ESP.getFreeHeap();
      int32_t delta =  ramPrev - ramNow;
      client.print("\n========== "); client.print(ramPrev); client.print("-"); client.print(ramNow); client.print("="); client.print(delta); client.println(" ==========\n\n");
      client.stop();
      Serial.print("Heap prev: "); Serial.print(ramPrev);
      Serial.print(", now: "); Serial.print(ramNow);
      Serial.print(", delta: "); Serial.println(delta);
      ramPrev = ramNow;
    }
  }
}

{"upTime":20259,"sysRamFree":47880,"sysRamFreeMin":44808,"sysVcc":2954,..., "wifiRssi":-39}

При реконнекте не очищается уже занятая память ?

Было подобное, в scada использовал ESP 8266 , на одном станке неделю работает (wifi+modbus/tcp), на другом через два часа падает.
Искать беду не стал, проще ребутить, раз в 15 мин, для системы некритично

Посмотрел код. Вроде без криминала. Могу залить у ся проверить, но думаю нет смысла. Потому как моя реализация в общем такая же, за исключением пары мелочей: нет стр.35 и цикл стр.31 я "развернул" чтоб луп всегда по кругу бегал. А меморилики контролю постоянно. И их нет. Куча  40КБ+-2КЬ крутится.

А ESP портом в "мир" светит? Дело в том что стоит открыть порт наружу, как в него, без рекламы и приглашений, начинает приходить заметное кол-во стремных подключений. До десятка в день. И далеко не все они просто придут-уйдут. Многие висят долго. Это и может быть причиной утечек. А на работе их не пускало просто в локалку.

То, что в ESP без чертей китайских не обходится - факт. В общем хожу на устройство с ПК и с планшета и телефона. С каждого могу 100500 раз заходить хоть подряд, все ОК. Но если после захода по локалке с ПК достаточно быстро зайти с мобильного устройства, ну за пару минут, то ответа нет. И не будет, пока не зайду с ПК. Тогда ответит сразу обоим ))) Разбор показал - в такой ситуации даже запрос до ESP не доходит. А дальше все работает как обычно. Китайский куцый играется ))))

Да код этот наколеночный, я просто покрыл основные потенциально проблемные места - открытие сокета, работу с ним и его закрытие.

ESP никуда не светит, я её с дебиана в локалках бомблю. Вайршарком посмотрел несколько обменов - всё ОК, похоже, заканичвается сессия штатно, через TCP RST ACK.

Провел ещё одну манипуляцию: взял TL-WR702N, настроил в режиме бриджа. Т.е. теперь программная часть вообще неизменна - ESP всегда коннектится к TPLink-у, на расстоянии вытянутой руки. Запустил комплект Node-M+WR702N дома - течёт память, притащил на работу - не течёт. Значит не в соединении дело...

Посидел, почесал башку... Отличие теперь только в питании. Дома от зарядки айфона (5V/1A) через USB порт Node-M, на работе от трансформатерного БП (7,5V/2A) через Vin. Это последняя рабочая гипотеза :(

Еще не хватало чтоб от БП утечки были. Аппл конечно зло, но не настолько же чтоб БП так гадить мог. Разве что по USB от него чего прилетает..

Залил таки твой скетч. 

Рисунок танцев с бубном:

1. поменял ssid с паролем -  не конектица в сириале краказябы

2. поменял скорость на 1200 - в сириале fatal error  при коннекте

3. поменял паузу в цикле конекта с 1000 на 100 - законектилось, в сириале корректно типа, 

#include "ESP8266WiFi.h"



const char* ssid     =  ;
const char* password =  ;

WiFiServer wifiServer(10050);

void setup() {

  Serial.begin(1200);

  WiFi.begin(ssid, password);

  Serial.print("Connecting to WiFi ");
  while (WiFi.status() != WL_CONNECTED) {
    delay(100);
    Serial.print(".");
  }
  Serial.print(" IP:"); Serial.println(WiFi.localIP());

  wifiServer.begin();
}

void loop() {

  WiFiClient client;
  //  client.setDefaultSync(true);
  int32_t ramPrev = ESP.getFreeHeap();
  Serial.println(ramPrev);
  while (1) {
    yield();
    client = wifiServer.available();
    if (client) {
      while (client.available() == 0);
      while (client.available() > 0) {
        char charC = client.read();
        //Serial.print(charC);
        //client.write(charC);
      }
      int32_t ramNow = ESP.getFreeHeap();
      int32_t delta =  ramPrev - ramNow;


           client.println("HTTP/1.1 200 OK");
            client.println("Content-type:text/html");
            client.println("Connection: close");
            client.println();

      
      client.print("\n========== "); client.print(ramPrev); client.print("-"); client.print(ramNow); client.print("="); client.print(delta); client.println(" ==========\n\n");
      client.stop();
      Serial.print("Heap prev: "); Serial.print(ramPrev);
      Serial.print(", now: "); Serial.print(ramNow);
      Serial.print(", delta: "); Serial.println(delta);
      ramPrev = ramNow;
    }
  }
}

Ну не текет оно.

Ну так у меня тоже на работе не текёт, а дома текёт. Какой-то нечистый дух поселился что ли...

Хотя, я когда долбил ESP, то заметил, что память утекает "лесенкой" - первые 5 мин флуда всё ОК, куча вверх-вниз скачет, потом хренак - ступенька вниз, опять более-менее стабильно, затем ещё раз - вниз идёт куча. И вот так незаметно, за 20 минут вся память вытекла. 

Вобщем, заберу БП домой, финальный тест устрою. Хотя, конечно, странно так - даже если напруга проседает, то это же не повод не освобождать память сокета. Ну, ребутнись ты по brownout detector, но зачем free() не делать...

Кстати, взял от IP-телефона БП на 5V, завел на VIN - не текёт память. Что же там, в этом USB-коннекторе происходит...

Попробуй мой скетч, с хедером. ХЗ как, но оно явно влияет как минимум на обмен и потребление.

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

Ну всё, друзья, проблема решена. Принёс Node-M домой с трансформатерным БП на 7.5V, от которого платка полдня на работе профурычила, воткнул, поставил на тест, через какое-то время щёлчек, вспышка, и пиз... Пощупал - еспшка в районе стаба прям горячая, а диод какой-то почернел аццки.

Теперь, как говорится, нет платы - нет проблем. 

Последний тест по памяти в плоттере выглядел вот так, то есть всё продолжало утекать.

Скетч:

#if defined(ARDUINO_ARCH_ESP8266)
#include "ESP8266WiFi.h"
#elif defined(ARDUINO_ARCH_ESP32)
#include "WiFi.h"
#endif
x`
const char* ssid = "TP-LINK_717E66";
const char* password =  "52717E66";

// This is need to take system's VCC
#if defined(ARDUINO_ARCH_ESP8266)
ADC_MODE(ADC_VCC);
#endif

WiFiServer wifiServer(80);

void setup() {
  Serial.begin(74880);
  wdt_enable(WDTO_8S);

  WiFi.begin(ssid, password);

  while (WiFi.status() != WL_CONNECTED) {
    delay(100);
  }
  //Serial.print("Connected to WiFi. IP:"); Serial.println(WiFi.localIP());

  wifiServer.begin();
}

void loop() {
  uint32_t cmdCount = 0x00;
  char buffer[200];
  WiFiClient client;
  //client.setDefaultSync(true);
  int32_t ramMin = ESP.getFreeHeap();
  Serial.println(ramMin);
  while (1) {
    yield();
    client = wifiServer.available();
    if (client) {
      while (client.available() == 0);
      while (client.available() > 0) {
        yield();
        //char charC =
        client.read();
      }
      cmdCount++;
      int32_t ramNow = ESP.getFreeHeap();
      snprintf_P(buffer, sizeof(buffer), PSTR("{\"upTime\":%u,\"sysRamFree\":%u,\"sysVcc\":%u,\"sysCmdCount\":%u,\"wifiRssi\":%d}\n"),
                 millis() / 1000UL, ramNow, ESP.getVcc(), cmdCount, WiFi.RSSI());
      client.print(buffer);
      Serial.println(ramNow);
      client.stop();
    }
  }
}

Флуд-скрипт на баше: 

#!/bin/bash
h='192.168.0.15'
p='80'
t='0.1'
k1="sys.all"
while [ 1 ]
do
echo `date +%s`
echo $k1 | nc $h $p
sleep $t
done

Пойду открою шампанское, бл. и выкину нахер все остальные ESP-шки прям из окна. А потом буду думать, как переехать из этого проклятого места.

AVR-ки, что примечательно, работают тут годами...

Решил дожечь оставшийся Wemos D1 и, в процессе этого, тыкал куда попало в менюшки, перебирал каналы, PHY mode и пр. и др.

В ходе метаний выяснил, что существует необъяснимая пока зависимость между какими-то внешними условиями и сборкой стека lwIP.

После некоторых манипуляций, таких как, например, переключение в режим "Erase flash: All flash content" и одновременного использования "lwIP variant: v1.4 Higher Bandwith" при компиляции, ситуация стабилизировалась. Но, полагаю, возможно, что достаточно было активировать только "Erase: Sketch + WiFi Settings", либо согласиться с тем, что произошло простое совпадение. 

Возврат же обратно на любой из вариантов с lwIP v.2 приводит в моей инсталляции к постепенной утечке памяти. Реально ли помогла зачистка настроек WiFi - сказать не могу, но субъективно выглядит так, потому что ранее у меня и с v1.4 текло. Либо Wemos просто испугался того, что я его спалю так же, как и Node-M, вследствие чего начал сотрудничать с администрацией.

Проиллюстрирую результат отвратительного качества скриншотами:

До начала экспериментов в сценарии с дефолтными настройками в IDE, при которых вкомпиливается "lwIP v2.0 Lower Memory", и нечастыми запросами (~раз в 5 сек) память расходовалась за 20 мин:

Сейчас, с "lwIP v1.4 Higher Bandwith", чип держит себя в руках больше полутора часов:

P.S. Полнофункциональный тест с неизменённой исходной прошивкой, на которой я и обнаружил утечку, идёт нормально уже на протяжении двух часов... Так что селёдка начала действовать. Запитался, правда, не от зарядки, а от обычного БП на 5V. Позже перейду на эпппловскую зарядку, чтобы окончательно расставить точки над i.

P.P.S.

На эппловской зарядке система, обвешенная датчиками разными (пылевик там, CO2, CO и пр. и др.) живет нормально, без явных проблем.

"Пила" до 19-00 - прошивка на lwIP v2.0, "плато" далее - на v1.4. Скачки вверх по Free RAM (min) после 19-00 - результат ношения макетки в разные места квартиры.

Вывод - v1.4HB всё же спасает, эппл неуиновен совсем.

Садман, тебе жена не говорит, что у простых людей простые неисправности у сложных - сложные )))

Простота - хуже воровства, говорят. ;)

Все это класно, о проблемах стека 2.0 lwIP кстати известно. Не очень понятно чего одна прошивка на работе работала а дома текла.

Вот её-богу - не понимаю, как место влияло на стек.

Допускаю, что мог лопухнуться и всегда шить на вариантах 2.0 (при переключении между платформами настройки boards скидываются вроде как), но как объяснить почему на работе не текло... Проведу, пожалуй, ещё один эксперимент - зашьюсь в 2.0, которая дома живёт 20 мин, и приволоку ESP на работу.

Как рабочая гипотеза. Особенности реализации стека версии 2.0 конфликтуют с настройками или особенностями роутера домашнего. Может архитектурой сети или пакетов в ней. Т.е. привязка трабла не к БП, а к сетевой инфраструктуре.. Это менее невероятно выглядит :-) 

вот с роутерами это пожалуй мысль,я свои на openWRT перешил да систему на флэшку поставил, памяти программ - вагон, и за много лет никаких зависаний, работают как Калаш

Еще тема для размышления о сервере на ESP. Оставил я его работать сутками напролет. А хрен! Иной раз отвалится, и хоть усрись.  Молчит гад, но работает все кроме доступа по WiFi! Ребутнешь его -  оживает, снова работает. Изучение вопроса показало - банально пропадает соединение по WiFi. Ну понятное дело, радиоканал, вокруг сотни роутеров и тысячи устройств. Это без преувеличения, 500 квартир в доме и рядом такие же дома. Но все остальные устройства кратковременный дисконект переживают с пониманием и повторно конектятся. Но не ESP. Отвалится раз и до ребута ни гу-гу. В общем требуется доработка. Сделал, стало нормально. Теперь только в логе вижу что дисконекты были.

Че же получается.

1. ESP сам по себе не умеет восстанавливать соединение. Так? Или китайские черти в нем воду мутят снова )))

2. Ни в одном из примеров в сети обработки дисконекта не видел. Но пишут авторы про аптайм ну прям от рождества христова ))) Это из категории "И Вы тоже говорите"?

  у меня крутится уже 64.58 дней )))

Вот! Иллюстрация! И что WiFi ни разу не падал за 2 месяца?

Там же есть setAutoReconnect() и брат его - setAutoConnect(), который мне крови попил как-то.

нет, да, на самом деле открутился еще +7-10 дней а точнее записи в базе с 08.08.2020 +7-10 дней (высчитывал расчетным путём, ошибся немного), пока я базу допиливал, естественно всё чистил с нуля, из добавок - перед отправкой даю три пинга, для надёжности )))

Есть то в SDK, а в  проектах - нет. Например - http://arduino.ru/forum/programmirovanie/termostat-opentherm-na-esp8266 Полтора года пишут, мер по реконекту нет, у всех все работает. Как так?  Поиском по сайту аж 3 раза встречается ))) Может он по умолчанию включен когда бывает?

Может она, ESP, у них ребутится чаще, чем отрывается от вифи

Просто отличный сервер!

v2 HB на работе от USB порта, через розовый метровый шнурок... 94 минуты, напруга падала ваще неимоверно в пике, последний ребут был по ресету, а не по эксепшну.

Без нормального питалова - что хош у esp может быть. Это я из предыдущих проектов усвоил. У нее большие пики потребления при радиообмене. При не очень большом среднем. Электролит не менее 1000. 

///типа sntp_xxxx.....

Я пользую его. Нормально. Раз в 20 мин корректирую системные часы. Запускаю.

        sntp_stop();
sntp_setservername(0,"ntp.time.in.ua");
sntp_setservername(1,"pool.ntp.org");
sntp_set_timezone(2);
sntp_init();

Через 10 секунд получаю время и останавливаю.

      uint32_t Time1 = sntp_get_current_timestamp();
      sntp_stop();

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

Озаботился прерываниями сабжа. Простого примера не нашел, то либы, то выкрутасы. Прерывания таймера и пина так работают. Для esp8266-01. При перепаде на RX0 (с монитора чтото отправить) загорается светодиод но горит не дольше 500мс.

#include <ESP8266WiFi.h>

 
#define interruptPin 3 //RX0
#define LED 1          //TX0

static os_timer_t os_timer01;
 
static void  ICACHE_RAM_ATTR timerIsr(void *arg)
{
 digitalWrite(LED, HIGH); 
}

static void  ICACHE_RAM_ATTR blink () 
{
  digitalWrite(LED, LOW);
}

void setup() {
  pinMode(LED,OUTPUT);
  pinMode (interruptPin, INPUT_PULLUP);

  attachInterrupt ( digitalPinToInterrupt (interruptPin), blink, CHANGE);

   os_timer_disarm(&os_timer01);
   os_timer_setfn(&os_timer01, (os_timer_func_t *)timerIsr, NULL);
   os_timer_arm(&os_timer01, 500, 1);
   
}

 
void loop() 
{

}

Кто то их реально пользует, прерывания эти? Как впечатления? os_timer_...- это так и нужно с таймером?

Ну похоже никто их и не использует. И правильно, однако. И я не буду использовать. Потому как это хрень а не прерывания.

По порядку. Глядя на os_timer_arm(&os_timer01, 500, 1);возникает вопрос а че такое 500. Это период таймера в мсек.  А как же мксек? Есть для него оказывается похожая функция.

The Espressif SDK api referene for sdk 2.1.0, section 3.1.5, says the following about os_timer_arm_us():

void	os_timer_arm_us(os_timer_t *ptimer,
                                    uint32_t microseconds,
                                    bool repeat_flag)
os_timer_t *ptimer: timer structure. 
uint32_t microseconds: timing; unit: microsecond, the minimum value is 0x64, the maximum value allowed to input is 0xFFFFFFF. 
bool	repeat_flag: whether the timer will be invoked repeatedly or not. 

Из комментария понятно, период не менее 100 мксек. Очевидно что не этого хотелось. Как вишенька на торт - os_timer_arm_us компилятор не видит. Ну и хрен, не сильно то теперь и нужно. Хотя вроде как os_timer_arm_us заменяема на ets_timer_arm_new, ее хоть видит. Но не работает.

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

#include <ESP8266WiFi.h>

 
#define LED 1          //TX0

static os_timer_t os_timer01;
static os_timer_t os_timer02;
static os_timer_t os_timer03;

bool e;
 
static void  ICACHE_RAM_ATTR timerIsr1(void *arg)
{
 digitalWrite(LED, HIGH); 
}
static void  ICACHE_RAM_ATTR timerIsr2(void *arg)
{
   if(e)
    digitalWrite(LED, LOW); 
}
static void  ICACHE_RAM_ATTR timerIsr3(void *arg)
{
 e=!e; 
}


void setup() {
  pinMode(LED,OUTPUT);


   os_timer_disarm(&os_timer01);
   os_timer_setfn(&os_timer01, (os_timer_func_t *)timerIsr1, NULL);
   os_timer_arm(&os_timer01, 500, 1);
   os_timer_disarm(&os_timer02);
   os_timer_setfn(&os_timer02, (os_timer_func_t *)timerIsr2, NULL);
   os_timer_arm(&os_timer02, 1000, 1);
   os_timer_disarm(&os_timer03);
   os_timer_setfn(&os_timer03, (os_timer_func_t *)timerIsr3, NULL);
   os_timer_arm(&os_timer03, 5000, 1);
}

Моргает как предписано. Кому там поморгать сразу тремя светодиодами - налетай! ))

На этом я совершенно утратил интерес к прерываниям ESP82366, в т.ч. и к прерываниям от пинов, т.к. в сети жалобы на невозможность их использовать на частотах выше 50Гц. Очевидно они тоже программные, типа в переываниях таймера, рассмотренных выше, просто проверяют пины и дергают из них обработчики этих как бы прерываний пинов. Печалька.

Похоже там все программное. Взяли МК помощнее и обмазали его софтовой реализацией со всех сторон. С одной стороны, иногда и выгодно получается - I2C без извращений на почти любых ногах можно получить, а с другой... Какие-то мелочи, который древний AVR мог ещё при мамонтах делать, у ESP не выходят.

У ESP8266 в проприоретарной бинарной библиотеке зашит код работы с WiFi/TCP. Если прерывание нарушают работу этой задачи, то срабатывает аппаратный WDT и ESP уходит в перезагрузку. Причем сбросить WDT у меня не получилось. Поэтому много прерываний при включенном WiFi постоянно глючат и перезагружают контроллер.

У ESP32 все интереснее - там два ядра и по умолчанию WiFi работает на 0, а loop() и setup() на 1. Кроме того, там все это запускается как задачи FreeRTOS, поэтому об аппаратном таймере можно забыть, так как нарушит работу ядра FreeRTOS. Зато аппаратные прерывания пашут отлично, через очереди и семафоры, обработчики прерываний взаимодействуют с задачами FreeRTOS. Просто рай для программиста )))

Но этов принципе не мешает тому, чтоб свободный аппаратный таймер оставить людям в распоряжение.

Так это и на AVR без проблем. Аппаратный разве что для паталогически медленных 100КГц оправдан. У меня почти все на программном i2c.

Ну, я к тому что для ESP стоковый Wire сразу на нужные ноги кидай и не заморачивайся с доустановкой библиотеки и пр., как для AVR

Модуль https://aliexpress.ru/item/2005868831.html приводится в действие драйвером https://www.ti.com/lit/ds/symlink/ucc27324-q1.pdf у которого входное напряжение единицы от 2 вольт, поэтому он подойдет для esp. А вообще любой MOSFET можно заставить работать по полной с помощью одного - двух обычных транзисторов. Схем в гугле много. Но я обычно сдуваю MOSFETы со старых материнок - они в большинстве работают от 3 вольт. Ссылку на АЛИ скопировать и вставить в строку поиска на новой странице. Форум глючит при редиректе.

Спасибо! Этот драйвер видел сегодня, но не был уверен. Но доставка долгая очень. На Ebay не видели случайно? Просто не понятно, как его искать, названия нет.

может и хватит. Скорей всего так. Просто это уже за пределами, рекомендуемыми производителем. Попробуйте. Следите за нагревом и напряжением на открытом ключе, оно должно быть небольшим, не более десятых долей вольта. У меня насос на два ампера сидит на AO4828 и 3,3В ардуине. Хотя это тоже, судя по докам, около предела, причем не известно с какой стороны от него )).

Нет. Я не пользуюсь модулями с MOSFETами. Мне хватает с материнок. Спаять три детальки для меня не проблема. Подключение обсуждали не раз. http://arduino.ru/forum/apparatnye-voprosy/2-mosfeta-sgorevshaya-nano#comment-314535 Это сработает от ESP.

Если нет готового драйвера, то можно собрать на 555 таймере.

Тут все от Вас зависит, вашего кода, cсхемотехники, и от Wi-Fi сети.

По моим наблюдениям ESP штука надежная, хотя попадались отдельные образцы, которые изначально Wi-Fi сети видели плохо. Но в целом, я поменял свое отношение к беспроводным сетям после смены производителя точек доступа и использования ESP, сильно в лучшую сторону.

Раньше считал, что только провод - это надежность, а Wi-Fi - так, возможность для смартфона, и то не всегда подключается сам. А после того как сменил точки доступа, не вижу проблем с Wi-Fi устройствами, причем совсем!

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

Только дома порядка 20 ESP работают уже много лет. Проблем нет совсем. Eще на работе, даче, на даче родителей жены и т.д.  Все рестарты, переподключения по Wi-Fi и mqtt - фиксируются. Обычно по нулям, растут, если были выключения питания, пропадания интернета и т.п.   

Попробовал IRF520. Без нагрузки открывается нормально и напряжение показывает 12в. Но при подключении помпы, напряжение падает до 1,7в. Как я понимаю, потому что ток очень слабый после ключа. То есть он открывается совсем чуть чуть. Подумал и заказал реле на 3в. Для данной задачи самый простой вариант. 

https://www.amazon.com/gp/product/B07XGZSYJV/ref=ppx_yo_dt_b_asin_title_...

Правильно понимаете.Пока едет реле можете попробовать поднять напряжение питания. Он до 4,2В по описанию работает. А по факту и 5В иногда может. Но 5 - много, не нужно так. 

Вот нашел в инете такой вариант согласования логики 3-5в

Если это тот модуль реле, что управляется по active low и на борту имеет npn-транзистор, то мне кажется, что согласование не требуется. Пин в INPUT переводите - выключается, в OUTPUT(LOW) - включается.

С реле на 3в вопросов нет, а для ключа IRF520 такое согласование может подойти?

Для фетов с высоким напряжением затвора идеально подходит оптрон типа P817

езист

За одно и развязка от 12В будет
Светодиод на выходе по желанию

Да, так тоже делаю. Но надо учитывать, что каcкад на npn транзисторе затянет длительность фронта при открытии силового транзистора, а это нагрев мосфета. Если переключения происходят редко - не страшно. Но ШИМ не допустим. То же, но в еще большей степени касается схем с оптроном, там и линейный режим получить возможно.

Правильная схема, кроме всего прочего должна быть простой. Самый правильный вариант - найти мосфет открывающийся от 3,3В. Если дело дошло до заказа через инет, чего не заказать его сразу?

Здесь https://forum.cxem.net/index.php?/topic/179566-управление-мощной-нагрузкой-от-gpio-33v/ в конце толковый мосфет советуют, а по ходу обсуждают эту же проблему, с прыжками по тем же граблям )))

Спасибо!