Witam
Takie pytanie, jak zasilacie wemosy, 3,3V czy 5V. Pytam bo mam takie dziwne objawy, przy zasilaniu 5V bezpośrednio z USB udało mi się tylko raz załadować program, każda kolejną próba kończyła się błędem ( nie mam teraz logów) ale był komunikat o zamknięciu portu. Przy zasilaniu 3.3v płytka działa poprawnie i można ładować konfigurację przez wifi. I teraz właśnie chodzi o podpięcie bezpośrednio do USB. Praktycznie wszyscy sprzedawcy twierdzą że wystarczy tylko kabel mikro USB czyli sugeruje to zasilanie 5V, ale jak wspomniałem wcześniej tylko raz poszła konfiguracja bez błędów a w zasadzie za pierwszym razem, każdy kolejny już powodował błąd.
Chyba szukasz dziury w całym, taki opis problemu wiele nie daje.
Nikt nie przeanalizuje tego problemu jeśli nie podasz konkretów do analizy.
Są wprawdzie kiepskie klony (podróbki) D1 mini, gdzie montowano stabilizator o obciążalności 100mA (ale on odcięcie zwarciowe ma dopiero przy 0.3A), a nawet oryginały WeMOS’a w niektórych wersjach płytek (bo było ich sporo) mają kontrowersyjny stabilizator, który przy ciągłym obciążeniu raczej nie uciągnie więcej niż 0.2A, ale jak dotąd nikt nie zgłaszał problemów dotyczących flashowania z tego powodu - nie da się oczywiście tego wykluczyć - tu wyznacznikiem może być prosty eksperyment - jeśli za każdym razem masz problem, to odłącz płytkę od zasilania na kilkanaście minut, daj wystygnąć stabilizatorowi, uruchom OTA i mniej więcej na etapie linkowania firmware podepnij USB do zasilacza 5V.
Ale nawet jeśli w ten sposób uzyskasz sukces za każdym razem to jeszcze nie jest 100% dowodem na przegrzewanie regulatora LDO, a to z tego powodu, że za każdym razem będziesz miał płytkę po sprzętowym restarcie.
Masz multimetr?
Jakie peryferia zasilasz z LDO na płytce?
PS Wątek otagowałem esphome ale nawet nie podałeś jakiego firmware problem dotyczy…
PPS
Jako, że łatwiej o zasilanie 5V to przeważnie 5V (zwykle wykorzystuję fabryczne gniazdko USB do zasilania z typowych ładowarek od telefonów).
Wbudowując jakąś płytkę ESP do innego urządzenia to już zależy do warunków zastanych.
Przeprowadziłem kilka testów na płytce D1-mini.
Moduł nowy odpakowany z folii podpięty bezpośrednio do portu USB raspberry (zasilanie 5V) nie wykazuje żadnej reakcji, brak możliwości zaprogramowania, port USB się nie wykrywa, brak na liście, jako urządzenie do odczytu moduł LD2410B odpięty na czas programowania. Płytkę programuje takim skryptem (kojarzę że nazywa się to inaczej, ale nie pamiętam jak)
esphome:
name: pierwszy-d1
friendly_name: Pierwszy D1
esp8266:
board: esp01_1m
# Enable logging
logger:
# Enable Home Assistant API
api:
encryption:
key: "VO7/dIDBfZLa2ReqWJNcFSEGy6Eoy4q8s81qML0OCcg="
ota:
password: "e22666ac1ca3ee6e5707cb06a2a7a1d7"
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Pierwszy-D1 Fallback Hotspot"
password: "p1YQ4d2hjmIe"
uart:
tx_pin: TX
rx_pin: RX
baud_rate: 256000
parity: NONE
stop_bits: 1
# Example configuration entry
ld2410:
timeout: 30s
max_move_distance : 3m
max_still_distance: 0.75m
g0_move_threshold: 50
g0_still_threshold: 20
g1_move_threshold: 50
g1_still_threshold: 20
g2_move_threshold: 40
g2_still_threshold: 40
g3_move_threshold: 40
g3_still_threshold: 40
g4_move_threshold: 40
g4_still_threshold: 40
g5_move_threshold: 40
g5_still_threshold: 40
g6_move_threshold: 30
g6_still_threshold: 15
g7_move_threshold: 30
g7_still_threshold: 15
g8_move_threshold: 30
g8_still_threshold: 15
captive_portal:
sensor:
- platform: ld2410
moving_distance:
name : Moving Distance
still_distance:
name: Still Distance
moving_energy:
name: Move Energy
still_energy:
name: Still Energy
detection_distance:
name: Detection Distance
binary_sensor:
- platform: ld2410
has_target:
name: Presence
has_moving_target:
name: Moving Target
has_still_target:
name: Still Target
Moduł nie pozwala się zaprogramować, zmiana portu lub kabla też nic nie daje, kabel sprawny.
Zmiana sposobu zasilania
Zasilanie bezpośrednio z raspberry z goldpinów 3,3V plus kabel podpięty do raspberry (dowolny port USB).
Podczas programowania port wykryty układ zaprogramowany, odczyty z LD poprawne, brak błędów.
Zmiana sposobu zasilania.
D1-mini zasilany bezpośrednio z ładowarki telefonu (5V 2A)
Brak możliwości zaprogramowania modułu. LD odpięty na czas programowania.
INFO ESPHome 2023.5.5
INFO Reading configuration /config/esphome/kamerka-test.yaml...
WARNING GPIO0 is a Strapping PIN and should be avoided.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq.html#why-am-i-getting-a-warning-about-strapping-pins
WARNING GPIO4 is a Strapping PIN and should be avoided.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq.html#why-am-i-getting-a-warning-about-strapping-pins
INFO Generating C++ source...
INFO Compiling app...
Processing kamerka-test (board: esp32cam; framework: arduino; platform: platformio/espressif32@5.3.0)
--------------------------------------------------------------------------------
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
- toolchain-xtensa-esp32 @ 8.4.0+2021r2-patch5
Dependency Graph
|-- AsyncTCP-esphome @ 1.2.2
|-- WiFi @ 2.0.0
|-- FS @ 2.0.0
|-- Update @ 2.0.0
|-- ESPAsyncWebServer-esphome @ 2.1.0
| |-- AsyncTCP-esphome @ 1.2.2
|-- DNSServer @ 2.0.0
|-- ESPmDNS @ 2.0.0
|-- noise-c @ 0.1.4
| |-- libsodium @ 1.10018.1
Compiling /data/kamerka-test/.pioenvs/kamerka-test/src/main.cpp.o
Linking /data/kamerka-test/.pioenvs/kamerka-test/firmware.elf
RAM: [= ] 13.9% (used 45436 bytes from 327680 bytes)
Flash: [====== ] 57.5% (used 1054501 bytes from 1835008 bytes)
Building /data/kamerka-test/.pioenvs/kamerka-test/firmware.bin
Creating esp32 image...
Successfully created esp32 image.
esp32_create_combined_bin(["/data/kamerka-test/.pioenvs/kamerka-test/firmware.bin"], ["/data/kamerka-test/.pioenvs/kamerka-test/firmware.elf"])
Wrote 0x112db0 bytes to file /data/kamerka-test/.pioenvs/kamerka-test/firmware-factory.bin, ready to flash to offset 0x0
========================= [SUCCESS] Took 45.91 seconds =========================
INFO Successfully compiled program.
INFO Resolving IP address of kamerka-test.local
ERROR Error resolving IP address of kamerka-test.local. Is it connected to WiFi?
ERROR (If this error persists, please set a static IP address: https://esphome.io/components/wifi.html#manual-ips)
ERROR Error resolving IP address: Error resolving address with mDNS: Did not respond. Maybe the device is offline., [Errno -5] No address associated with hostname
Wifi brak połączenia
Zmiana sposobu zasilania
Zasilanie D1 mini bezpośrednio z goldpinów raspberry (3.3V)
Układ zaprogramowany, odczyty z LD obecne bez błędów.
INFO ESPHome 2023.5.5
INFO Reading configuration /config/esphome/pierwszy-d1.yaml...
INFO Starting log output from pierwszy-d1.local using esphome API
INFO Successfully connected to pierwszy-d1.local
[15:06:41][I][app:102]: ESPHome version 2023.5.5 compiled on Jun 14 2023, 15:01:18
[15:06:41][C][wifi:505]: WiFi:
[15:06:41][C][wifi:363]: Local MAC: CC:50:E3:E9:0E:2E
[15:06:41][C][wifi:364]: SSID: [redacted]
[15:06:41][C][wifi:365]: IP Address: 192.168.1.44
[15:06:41][C][wifi:366]: BSSID: [redacted]
[15:06:41][C][wifi:368]: Hostname: 'pierwszy-d1'
[15:06:41][C][wifi:370]: Signal strength: -66 dB ▂▄▆█
[15:06:41][C][wifi:374]: Channel: 1
[15:06:41][C][wifi:375]: Subnet: 255.255.255.0
[15:06:41][C][wifi:376]: Gateway: 192.168.1.1
[15:06:41][C][wifi:377]: DNS1: 62.179.1.62
[15:06:41][C][wifi:378]: DNS2: 62.179.1.63
[15:06:41][C][logger:301]: Logger:
[15:06:41][C][logger:302]: Level: DEBUG
[15:06:41][C][logger:303]: Log Baud Rate: 115200
[15:06:41][C][logger:305]: Hardware UART: UART0
[15:06:41][C][uart.arduino_esp8266:102]: UART Bus:
[15:06:41][C][uart.arduino_esp8266:103]: TX Pin: GPIO1
[15:06:41][C][uart.arduino_esp8266:104]: RX Pin: GPIO3
[15:06:41][C][uart.arduino_esp8266:106]: RX Buffer Size: 256
[15:06:41][C][uart.arduino_esp8266:108]: Baud Rate: 256000 baud
[15:06:41][C][uart.arduino_esp8266:109]: Data Bits: 8
[15:06:41][C][uart.arduino_esp8266:110]: Parity: NONE
[15:06:41][C][uart.arduino_esp8266:111]: Stop bits: 1
[15:06:41][C][uart.arduino_esp8266:113]: Using hardware serial interface.
[15:06:41][W][uart.arduino_esp8266:127]: You're using the same serial port for logging and the UART component. Please disable logging over the serial port by setting logger->baud_rate to 0.
[15:06:41][C][ld2410:012]: LD2410:
[15:06:41][C][ld2410:014]: HasTargetSensor 'Presence'
[15:06:41][C][ld2410:014]: Device Class: 'occupancy'
[15:06:41][C][ld2410:015]: MovingSensor 'Moving Target'
[15:06:41][C][ld2410:015]: Device Class: 'motion'
[15:06:41][C][ld2410:016]: StillSensor 'Still Target'
[15:06:41][C][ld2410:016]: Device Class: 'occupancy'
[15:06:41][C][ld2410:019]: Moving Distance 'Moving Distance'
[15:06:41][C][ld2410:019]: Device Class: 'distance'
[15:06:41][C][ld2410:019]: State Class: ''
[15:06:41][C][ld2410:019]: Unit of Measurement: 'cm'
[15:06:41][C][ld2410:019]: Accuracy Decimals: 0
[15:06:41][C][ld2410:020]: Still Distance 'Still Distance'
[15:06:41][C][ld2410:020]: Device Class: 'distance'
[15:06:41][C][ld2410:020]: State Class: ''
[15:06:41][C][ld2410:020]: Unit of Measurement: 'cm'
[15:06:41][C][ld2410:020]: Accuracy Decimals: 0
[15:06:41][C][ld2410:021]: Moving Energy 'Move Energy'
[15:06:41][C][ld2410:021]: Device Class: 'energy'
[15:06:41][C][ld2410:021]: State Class: ''
[15:06:41][C][ld2410:021]: Unit of Measurement: '%'
[15:06:41][C][ld2410:021]: Accuracy Decimals: 0
[15:06:41][C][ld2410:022]: Still Energy 'Still Energy'
[15:06:41][C][ld2410:022]: Device Class: 'energy'
[15:06:41][C][ld2410:022]: State Class: ''
[15:06:41][C][ld2410:022]: Unit of Measurement: '%'
[15:06:41][C][ld2410:022]: Accuracy Decimals: 0
[15:06:41][C][ld2410:023]: Detection Distance 'Detection Distance'
[15:06:41][C][ld2410:023]: Device Class: 'distance'
[15:06:41][C][ld2410:023]: State Class: ''
[15:06:41][C][ld2410:023]: Unit of Measurement: 'cm'
[15:06:41][C][ld2410:023]: Accuracy Decimals: 0
[15:06:41][C][ld2410:028]: Firmware Version : 1.7.3492122
[15:06:41][C][captive_portal:088]: Captive Portal:
[15:06:41][C][mdns:108]: mDNS:
[15:06:41][C][mdns:109]: Hostname: pierwszy-d1
[15:06:41][C][ota:093]: Over-The-Air Updates:
[15:06:41][C][ota:094]: Address: pierwszy-d1.local:8266
[15:06:41][C][ota:097]: Using Password.
[15:06:41][C][api:138]: API Server:
[15:06:41][C][api:139]: Address: pierwszy-d1.local:6053
[15:06:41][C][api:141]: Using noise encryption: YES
[15:06:43][D][binary_sensor:036]: 'Moving Target': Sending state ON
[15:06:43][D][binary_sensor:036]: 'Still Target': Sending state OFF
[15:06:43][D][sensor:093]: 'Moving Distance': Sending state 30.00000 cm with 0 decimals of accuracy
[15:06:43][D][sensor:093]: 'Move Energy': Sending state 100.00000 % with 0 decimals of accuracy
[15:06:43][D][sensor:093]: 'Still Energy': Sending state 1.00000 % with 0 decimals of accuracy
[15:06:44][D][sensor:093]: 'Moving Distance': Sending state 58.00000 cm with 0 decimals of accuracy
[15:06:45][D][binary_sensor:036]: 'Moving Target': Sending state OFF
[15:06:45][D][binary_sensor:036]: 'Still Target': Sending state ON
[15:06:45][D][sensor:093]: 'Moving Distance': Sending state 30.00000 cm with 0 decimals of accuracy
[15:06:45][D][sensor:093]: 'Move Energy': Sending state 0.00000 % with 0 decimals of accuracy
[15:06:45][D][sensor:093]: 'Still Energy': Sending state 0.00000 % with 0 decimals of accuracy
Czyli jaki z tego wniosek, że zasilanie 5V jest nieodpowiednie, czy coś namieszałem.
No to Cię poniosło, RPi wręcz słyną z niespełniania specyfikacji USB… ale raczej nie tu jest problem.
Ja się nie podejmuję analizy, zajmie to za dużo czasu. Tu pojawia się za wiele zmiennych, masz w ogóle multimetr?
Jeśli tak to mierz napięcia. Zasilacz zasilaczowi nierówny.
Wniosek jest taki, że po podłączeniu do zasilacza 5V/2A , nie sprawdziłeś nic , np wartości napięcia 3,3V
Zasilanie z 3,3V pomiaja regulator napięcia , więc nic nie można wywnioskować.
Podłącz chciaż zaprogramowany modył do zasilania 5V i sprawdz co będzie, jak nie masz multimetru - miernika.
A dlaczego zakładasz że nie sprawdziłem zasilania
Pomiary na pinach 5,12V (z ładowarki) i 3,31V (po stabilizatorze)
Przy zasilaniu 5V obojętne czy z portu USB czy z ładowarki moduł nie odpowiada. Nie pisałbym tego gdyby nie fakt że mam sześć takich modułów i jak dotąd cztery z nich działają tak samo.
Bo nie napisałeś, że to zmierzyłeś.
Podłącz ten moduł do 5V i zostaw na 10 min , po tym czasie dotknij regulator palcem, jeśli będzie bardzo gorący, pozostaje zasilać te moduły z 3,3V .
Przerzuciłem takich wemos kilkadziesiąt szt, i kilka od strzała miały uwalony regulator.
- podłącz Wemos po USB do kompa i zobacz co wykryje Windows?
- jakiego “programatora” używasz?
- w jaki sposób programujesz przy 3.3V?
Jeśli programujesz bezpośrednio prze piny Rx/Tx to po podaniu zasilania przez USB zasilasz mostek, który nie pozwoli na programowanie.
Jeśli przez piny 3.3V nie zasilasz mostka i można wtedy piny Rx/Tx używać normalnie.
Sugerowałem autorowi, żeby zaprogramował moduł nawet z 3V i podłaczył do zasilania 5V , ale nie ma odzewu w tej kwestii. To by wyjaśniło, czy problem jest z wydajnością regulatora napięcia, czy to błędy przy próbach flashowania, o których piszesz.
Znaczy że działają czy nie działają?
Może podrzucę coś istotnego - schematy oryginalnych płytek WeMos (trudno znaleźć, bo na aktualne oficjalnej stronie są podlinkowane tylko najświeższe wersje)
CH340C jest podpięty zarówno do zasilania 3V3 jak i do UART0 ujmijmy to “na krótko”, to samo dotyczy też wielu innych płytek z mostkiem UART (np. NodeMCU v2 i pochodnych) - ich zaleta w postaci łatwego programowania jest równocześnie strzałem w kolano przy próbie wykorzystania sprzętowego UARTa w MCU (można masakrować płytkę, ale lepiej odpuścić sprzętowy UART na pinach TX i RX na korzyść programowego na dowolnych innych pinach) swoją drogą nie można mieć nic do TR/RX podpiętego jeśli chcemy programować z użyciem portu szeregowego (OTA jest możliwe, bo nie używa tych pinów, ale i tak trzeba mieć w głowie, że część pinów w trakcie programowania czy rebootu zachowuje się specyficznie).
Druga kwestia to często dramatyczna jakość klonów Wemosa (w tym czasem spotykane “słynne” stabilizatory 3.3V o znamionowej obciążalności 100mA).
PS przy pierwszym programowaniu czasem trzeba po prostu mieć GPIO0 pociągnięte do masy, bo płytki miewają fabrycznie firmware niezgodne z tym co chcemy wgrać.
PPS klony mogą mieć inne mostki niż CH340, ale linux raczej je wszystkie poznaje (z innymi systemami bywa różnie, ale widząc co wlutowano można sobie sprawić odpowiednie sterowniki).
Trochę to trwało, bo wszystkie moduły działały po 15 min na zasilaniu zewnętrznym 5V i w żadnym module nie zauważyłem jakiegoś nadmiernego przegrzewania się. Wszystkie moduły które mam (6 sztuk) zachowują się tak samo. Przy próbie wgrania podstawowej konfiguracji, z postu 3 pomijając uart i LD, zawsze jest to samo. Przy zasilaniu bezpośrednio z RPI nie można zaprogramować modułów, RPI nie widzi portu na którym jest wpięty moduł. Przy zasilaniu 3,3 wszystkie moduły się programują bezpośrednio z RPI, port się wykrywa, przy dopisaniu uart i LD też wszystkie moduły można zaprogramować, działają bez błędów. Czyli mam sześć modułów do których podpięte są LD, które działają poprawnie. Po przełączeniu zasilania na zewnętrzne źródło 5V, moduły nie działają, brak komunikacji wifi czyli brak odczytów LD i brak możliwości zaprogramowania. Po powrocie do zewnętrznego zasilania 3,3v wszystkie moduły ponownie działają bez problemów.
@RobinI30
Programuje bezpośrednio z homeassistant, z opcji “pług into the computer running esp” tak jak wszystkie inne moduły które mam (esp8266, C3, esp32-cam). Teraz jeszcze taka ciekawostka po podpieciu 5V bezpośrednio do pinów na płytce moduł działa, problem pojawia się po podłączeniu modułu przez USB-C, wtedy przy zasilaniu 5V moduł nie reaguje.
Dobra to może inaczej, bo trudno się porozumieć, kolega @RobinI30 nie pytał o sposób wgrywania, tylko o sprzęt do tego wgrywania, przewód przy wgrywaniu przez USB, albo mostek- “programator” jeśli używasz połączenia bezpośrednio do TX, RX. Jaki ten sprzęt nie jest, to skoro możesz wgrać firmware, proponuję zrobić test z LED status.
Wgraj taki prosty yaml
esphome:
name: test
friendly_name: test
esp8266:
board: d1_mini
# Enable logging
logger:
# Enable Home Assistant API
api:
encryption:
key: "3R9REI2u+DAhMNkZNfq7Qsya9d0vcsJ9EBJP2CpKoFA="
ota:
password: "7eb6fc148b15346e918cb0c7f497f4fb"
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Test"
password: "12345678"
captive_portal:
status_led:
pin: GPIO2
Podłącz moduł jak na foto i napisz co się dzieje
Nigdy się nie dogadamy, bo w tym co znalazłem w logu to
- albo wcale nie jest płytka WeMos D1 mini tylko klon na bazie ESP32
- albo autor próbuje na ESP8266 wgrać soft skompilowany dla ESP32
to co jest w tamtym poście zrobiło mi całkowity szaszor w mózgu
to fragment pierwszego drugiego loga (nie działa, moim zdaniem nie może bo softu dla ESP32 nie da się upchnąć w ESP8266)
a tu kawałek działającego (log drugi trzeci) czyli tu już zdefiniowano jakąś płytkę ESP8266, z innych logów widać że ESP-01
1 polubienie
Ok … po tym co napisał @szopen wszystko sobie poukładałem i logicznie można wytłumaczyć hipotezę słabego stabilizatora.
Ja dla odmiany zrozumiałem, że przy zasilaniu 3.3V program wykonuje się prawidłowo, a po przełączeniu na 5V już nie.
Led mruga kilka razy poczym świeci cały czas, i właśnie poszedł dymek ze stabilizatora, po zasileniu 3,3V moduł działa poprawnie
@RobinI30 bardzo dobrze to zrozumiałeś.
Sorki kolego, ale autor pisze, że przy zasilaniu 3,3V moduł żyje i ma odczyty z sensora radarowego.
Sugeruje to poprawną wersję softu, ale dajmy szansę samemu autorowi, niech zobaczy foto, porówna co ma , a najlepiej sprawdzi zgodnie z sugestią.
@bodesowski Czyli wracamy do punktu gdzie prosiłem o sprawdzenie temp tego stabilizatora
Rano nie miałem czasu na analizę, teraz też nie mam, ale zacząłem przeglądać logi od postów na początku i widzę że była próba wgrania bina skompilowanego dla ESP32 do ESP8266, to się nie mogło udać…
Więc problemów na starcie jest więcej niż jeden.
A problemy ze stabilizatorami w klonach D1 są w zasadzie już słynne - niektóre podróbki mają montowane stabilizatory tańsze o centa czy 2 od tych które były w projekcie, co kończy się jak się kończy.
Może tak być z powodu tego, że w chwili łączenia się Wifi prąd pobierany przez moduł rośnie znacznie powyżej prądu stabilizatora i moduł się resetuje, Trwa to na tyle krótko, że miernikiem tego nie zobaczysz.
1 polubienie
Nie, nie wracamy, pomyłka w podłączeniu. kolejna płytka działa poprawnie przy zasilaniu 5V lub 3,3V ale tylko gdy zasilanie jest podłączone do goldpinów, przy podłączeniu przez kabel (USB-C_ moduł nie odpowiada, sprawdzałem na kilku przewodach więc uszkodzenie przewodu wykluczam, nie wiem może na gnieździe się coś masuje. Pod lupą nie widać żadnych uszkodzeń.