Расширение для vs code, обеспечивающее работу с nodemcu lua

Ситуация запутывается.
1. Плата не шьется через Flash Download Tool.
2. Разобрал часы, отпаял от всю периферию. Голая плата.
3. Результата никакого.
4. Подпаялся к UART:



5. Плата прошилась.
6. VSCode в этой комбинации не видит порта, видимо не рассчитан на FT232. То есть все что не NodeMCU но ESP VSCode видеть не будет?
7. VSCode так и неконнектится с этой перепрошитой платой без всякого кода в ней через родной USB.


Вот такая ситуевина

 

Теперь должно соединиться с FTDI 232. Пробуй. Файл в приложении, версию не менял.

 

Всё, что удалось найти про ошибку 31, относящееся к данной ситуации, это то, что Windows не может найти драйвер для последовательного устройства. То есть, ошибка генерируется где-то на верхнем уровне. Но, тогда непонятно как esplorer коннектится.

Какой тип у этого 'плохого' wemos?
PS C:\WINDOWS\system32> nodemcu-tool devices
[device] ~ Device filter is active - only known NodeMCU devices (USB vendor-id) will be listed.
[device] ~ Connected Devices | Total: 1
[device] ~ - COM4 (wch.cn, USB\VID_1A86&PID_7523\6&1BCB92EB&0&1)

Нет ли в перечне устройств в Device Manager какого-либо неопознанного устройства с похожим PID? И из-за этого драйвер не тот цепляется.

 

Бинго! Через FT232.


Промежуточная победа

 

Там зачем-то стоял жёсткий контроль на подключение только заранее определённых vendor ID. Я не знаю с какой целью это было сделано, но думаю, что надо разрешать коннектится всему что попало. В следующей версии уберу контроль.

 

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



С этими настройками и шил часы, просто не обратил внимание.

 

Если раскрыть свойства порта, то выбрать скорость 921600 возможности нет.
Может быть дело как-то связано с этим. Это предположение.

 

Я полагаю, что это определяется драйвером. Может он такую скорость обеспечить, или нет. Нам всё равно нужно 115200.
Я посмотрел для CH340 у меня не даёт выбрать выше 128000. А на FTDI можно 921600.

Вот что ещё нашел про ошибку 31

Всё таки, надо будет проверить - работает ли плата с nodemcu-tool. Потому что nodemcu-tool использует ту же библиотеку serialport, что и расширение VS Code. Если работает, то ошибка в расширении, если нет, то где-то ещё.

 

Это я уже часы накатал.

 

???
nodemcu-tool devices

 

И я того же мнения. В pyserial зашиты BAUDRATES = (50, 75, 110, 134, 150, 200, 300, 600, 1200, 1800, 2400, 4800, 9600, 19200, 38400, 57600, 115200). Если другая программа установила его, например, в 14400 может быть ошибка. Ну и на всякий случай ссылка на последний драйвер от 2023-03-16, у меня стоял от 2019 и Windows 10 его не обновляет

 

Вроде только в одном месте скорость выставляется.

Код (Javascript):

    protected constructor(path: string) {
        this._port = new SerialPort({ path, autoOpen: false, baudRate: 115200 })
    }

 

Это я посмотрел по поводу ошибок в ESPTool (python). В JavaScript почти ничего не понимаю, но насколько вижу node-serialport обращается к bindings-cpp. Как Windows устанавливается скорость передачи я с наскоку не разобрался, а в Linux тоже нет скорости 14400, но есть 921600, как в примере ИгорьК. Так, что до корректного вызова new SerialPort может дело не дойти.

 

Обновление драйвера не помогло. Видимо что-то особенное в работе микросхемы USB-UART СН340. Но что-то пока нет желания включать ЛА и смотреть что там происходит

Победа!

1. Удаляем драйверы тем что по ссылке @ZAZ-965
2. Перегружаемся.
3. Устанавливаем драйверы.
4. Перегружаемся.

Вот оно, необъятное чувство радости:

 

И все было хорошо ровно до того момента, как вновь спаял часы
ESPlorer работает, VSCode - нет.

Буду опять разбирать Сколько надо

 

Да, всё верно.
Ошибка перехватывается в момент запроса Connect, но события все асинхронные. Если фраза "...до корректного вызова new SerialPort может дело не дойти" подразумевает, что ошибка происходит раньше, где-то в недрах Windows, то похоже, что так и есть.

Esplorer использует для привязки к последовательным портам свою библиотеку jssc, а приложения nodemcu-tool и nodemcu-tools библиотеку node-serialport c @serialport/bindings. Вероятно, у этих библиотек разные подходы к общению с портами под Windows.
Для того, чтобы убедиться в работоспособности библиотеки serialport, установим инструменты командной строки, и проведём эксперименты.
Подготовка.
Библиотекари из serialport в крайней версии прибили поддержку node v12. Теперь минимум node v14. Поэтому надо удалить node v12 и установить node v14, пользуясь той инструкцией, которую я раньше приводил.
Далее устанавливаем:
npm install -g @serialport/list
npm install -g @serialport/terminal
npm install -g @serialport/repl
Во Windows переменная окружения DEBUG для serialport в командной строке устанавливается вот так:
$env:DEBUG = "serialport*"
Проверяем, пользуясь инструкциями отсюда.

Спойлер: Пример обмена с рабочими портами.

Код (Bash):

PS C:\WINDOWS\system32> serialport-list
  serialport/bindings-cpp loading WindowsBinding +0ms
COM4    USB\VID_1A86&PID_7523\6&1BCB92EB&0&1    wch.cn
COM3    FTDIBUS\VID_0403+PID_6001+A51MXHR9A\0000        FTDI
PS C:\WINDOWS\system32>

PS C:\WINDOWS\system32> serialport-terminal
  serialport/bindings-cpp loading WindowsBinding +0ms
√ Select a serial port to open · COM4
√ Enter a baud rate · 115200
Opening serial port: COM4 echo: true
  serialport/stream opening path: COM4 +0ms
  serialport/bindings-cpp open +0ms
  serialport/stream _read queueing _read for after open +47ms
  serialport/stream opened path: COM4 +0ms
  serialport/stream _read reading { start: 0, toRead: 65536 } +1ms
  serialport/bindings-cpp read +49ms

PS C:\WINDOWS\system32> $env:DEBUG = "serialport*"
PS C:\WINDOWS\system32> serialport-repl COM3 115200
  serialport/bindings-cpp loading WindowsBinding +0ms
DEBUG=serialport* # enable debugging with DEBUG=serialport*
port = SerialPort({ path: "COM3", baudRate: 115200, autoOpen: false })
globals { SerialPort, SerialPortMock, path, port }
> SerialPort.list()
[
  {
    path: 'COM4',
    manufacturer: 'wch.cn',
    serialNumber: '6&1BCB92EB&0&1',
    pnpId: 'USB\\VID_1A86&PID_7523\\6&1BCB92EB&0&1',
    locationId: 'Port_#0001.Hub_#0003',
    friendlyName: 'USB-SERIAL CH340 (COM4)',
    vendorId: '1A86',
    productId: '7523'
  },
  {
    path: 'COM3',
    manufacturer: 'FTDI',
    serialNumber: 'A51MXHR9',
    pnpId: 'FTDIBUS\\VID_0403+PID_6001+A51MXHR9A\\0000',
    locationId: undefined,
    friendlyName: 'USB Serial Port (COM3)',
    vendorId: '0403',
    productId: '6001'
  }
]
> port.open()
  serialport/stream opening path: COM3 +0ms
  serialport/bindings-cpp open +0ms
undefined
>   serialport/stream opened path: COM3 +27ms

undefined
> port.write('print"a"')
  serialport/stream _write 8 bytes of data +1m
  serialport/bindings-cpp write 8 bytes +1m
true
>   serialport/stream binding.write write finished +3ms
 

 

Как то так. Та же ошибка - 31. Она же - неизвестная






А это другая плата - соединяется:

 

Хорошо, ошибку генерирует файл библиотеки bindings serialport_win.cpp вот в этой строчке. Однако, пока непонятна причина генерации ошибки.
Если происходили какие-либо изменения в процессе соедининения с устройством при смене драйверов и перезагрузке, то я предлагаю попробовать методы, предложенные на этом ресурсе.

Если принудительно установить параметры порта во Windows на 115200 8n1 flowcontrol off, изменится что-нибудь?
И, всё-таки, чем отличаются платы при успешном и не успешном коннекте? Это одна и та же плата, только с припаянной периферией и залитым софтом?

 

"Нет! На это я согласиться не могу!"

Это что касается манипуляций с системой. Не соответствует уровню проблемы.

Но проблема забавная.

Количество экспериментов ещё не переросло в возможность сделать качественные выводы.

Что можно сказать приблизительно.

1. На модуле прошивка, собранная самостоятельно.

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

3. После соединения периферии модуль тоже коннектится. Но через некоторое время связь теряется и больше не восстанавливается.

Прошить модуль через USB не удаётся. Только через UART.

4. ESPlorer работает всегда.

5. Поскольку до появления вашего расширения работал с ESPlorer, сложно сказать что было раньше.

Сейчас почти доделал часы, где вся периферия на разъемах. Буду неспешно экспериментировать дальше, но времени потребуется много. И не факт что удастся выявить хотя бы откуда ноги растут.

PS. И, кстати, по вашей ссылке ошибку 31 выдаёт винда. В нашем же случае винда ошибку не выдаёт. Похоже здесь просто совпадение.

PPS. Надеюсь, интерес к часам я у вас возбудил