Witam. Jakie piny połączyć ze sobą pomiędzy ESP32 Wroom a CC1101 868mhz?
mosi > GPIO13
miso > GPIO12
sck > GPIO14
csn > GPIO2
gdo0 > GPIO5
gdo2 > GPIO4
W taki sposób?
Coś mi się tu nie klei - chyba nie jesteś takim hardkorem by używać “gołego” modułu ESP-WROOM-32 (goły=nie wlutowany w jakąś gotową płytkę prototypową).
Dany projekt może mieć zdefiniowane jakieś domyślne (default’owe) piny, wtedy ich nie musisz deklarować jawnie (o ile właśnie z nich skorzystasz).
Podałem tu nazwy spotykane na rysunkach i schematach (bywają jeszcze inne), ale skrótów użyj zgodnych z dokumentacją projektu!
Optymalnie, gdy piny MOSI (=SI; =DIN - tylko w odniesieniu do Slave; =DOUT - tylko w odniesieniu do Mastera), MISO (=SO; =DOUT- tylko w odniesieniu do Slave; =DIN - tylko w odniesieniu do Mastera), SCK(=CLK ) i SS (=CSN; =CS) - wykorzystują domyślne piny GPIO dla danej konstrukcji (czyli te o takich samych oznaczeniach dla VSPI lub dla HSPI - zdecyduj którą magistralę SPI użyjesz) oraz gdy na płytce prototypowej nie jest do nich podłączone na stałe coś innego (np. LED).
Ta ostatnia zasada dotyczy też 2 pozostałych pinów.
Nie wiem czy to twoja płytka prototypowa (ale wiele innych podobnych ma podobny układ wyprowadzeń, oczywiście użyj dokumentacji pasującej do płytki!) - tu HSPI jest na GPIO 12,13,14,15 a VSPI na 5, 18, 19 i 23, zalecam użyć HSPI
Cześć. Dzięki za odpowiedź.
Moja płytka różni się od tej.
Wyprowadzenia wyglądają tak:
ESP32 Wroom Devkit 1 ( ← źródło)
W zakresie pinów, które obrysowałem w czerwone ramki nie ma istotnych różnic, nawet kolejność jest z grubsza ta sama (a poza ramkami są albo piny i tak nie do wykorzystania, albo zasilanie/masa), jak pisałem wcześniej - oznaczenia bywają różne i akurat na obrazku który podlinkowałeś są inne, ale numery GPIO są dość jednoznaczne.
Podłączyłem:
mosi_pin: GPIO23
miso_pin: GPIO19
clk_pin: GPIO18
cs_pin: GPIO5
gdo0_pin: GPIO13
gdo2_pin: GPIO14
Ale ESP wchodzi w bootloopa.
Bootloop mówi:
E (43397) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time: E (43397) task_wdt: - loopTask (CPU 1) E (43397) task_wdt: Tasks currently running: E (43397) task_wdt: CPU 0: IDLE E (43397) task_wdt: CPU 1: loopTask E (43397) task_wdt: Aborting. abort() was called at PC 0x400fc7d8 on core 0 Backtrace:0x4008391d:0x3ffbe9cc |<-CORRUPTED ELF file SHA256: 0000000000000000 Rebooting…
Przestaje dopiero gdy odłączę pin 5
Chyba coś źle robię
GPIO5 jest jednym z pinów bootstrapu, możesz użyć jakiś inny, swoją drogą wcale nie podpiąłeś tak jak sugerowałem (właśnie z jego powodu sugerowałem użyć HSPI a nie VSPI).
Dobrze rozumiem, że HSPI to te piny?
No niezupełnie, przecież pisałem wyżej GPIO 12-15, zauważ, że CC1101 używa magistrali SPI (optymalnie gdy ona jest na “fabrycznych” pozycjach w MCU, ESP32 umożliwia przemapowanie pinów, ale nie należy z tego korzystać jeśli nie ma przymusu, bo można doprowadzić do nieprzewidywalnego zachowania) oraz 2 wysyłających dodatkowe dane GDO, które możesz podpiąć na takich pinach by nie było konfliktów (ktoś gdzieś sugerował by je podpinać na pinach zwykle opisywanych SCL/SDA zapewne dlatego, że one zazwyczaj nie wywołują konfliktów, bo nie kojarzę że ESP32 ma sprzętowy I2C edit: jednak ma i to 2 ale ich piny można podobno śmiało przemapowywać)
Czyli MOSI 12
MISO 13
CLK 14
CS 15
GDO0 5
GDO2 4
?
Wybacz, ale nie jestem za dobry w tych sprawach. Umiem lutować i trochę programować
Skoro pisałeś, że użycie GPIO5 wywołuje bootloopa to czemu się na niego upierasz?
Czyli MOSI 12
MISO 13
CLK 14
CS 15
GDO0 np. pin 2
GDO2 4
?
Jak byś mi napisał które piny byłbym wdzięczny. Mógłbym sobie wtedy przeanalizować schemat i więcej z tego bym zrozumiał.
Np. GPIO2 jest często wykorzystywane do wysterowania LED
i sądząc po schemacie na twojej płytce jest…
biorąc pod uwagę wskazanie na sugerowane przez niektórych SCL/SDA jako 2 ostatnie piny bym użył GPIO 21 i 22
a w ogóle zajrzałeś na ten rysunek u góry - bez przemapowania to raczej
MOSI 13
MISO 12
CLK 14
CS 15
Z tego co napisałem nie wyśledzisz “co i dlaczego” sugeruję tak, a nie inaczej, ale jeśli przeczytasz taki bryk o ESP32 (w całości, nie czytaj wyłącznie urywków, bo istotne informacje są rozrzucone po całym artykule)
to będziesz wiedział czemu sugerowałem taki układ i dlaczego GPIO5 (i parę innych) “jest złe mimo, że jest dobre” - rozdział Strapping Pins (też jest w nim to opisane jedynie “po łebkach”, więcej jest w dokumentacji, no ale skoro bryk to musi być krótki).
Podłączyłem jak sugerowałeś i zaprogramowałem czyli:
mosi_pin: GPIO13
miso_pin: GPIO12
clk_pin: GPIO14
cs_pin: GPIO15
gdo0_pin: GPIO21
gdo2_pin: GPIO22
I jest dalej bootloop.
Log:
[I][logger:258]: Log initialized [C][ota:469]: There have been 6 suspected unsuccessful boot attempts. [D][esp32.preferences:113]: Saving 1 preferences to flash… [D][esp32.preferences:142]: Saving 1 preferences to flash: 0 cached, 1 written, 0 failed [I][app:029]: Running through setup()… [C][wifi:037]: Setting up WiFi… [C][wifi:038]: Local MAC: 30:C6:F7:2C:B3:3C [D][wifi:386]: Starting scan… [D][wifi:401]: Found networks: [I][wifi:445]: - ‘SYRION16262’ (78:98:E8:34:FA:5A) [redacted]▂▄▆█ [D][wifi:446]: Channel: 5 [D][wifi:447]: RSSI: -66 dB [I][wifi:445]: - ‘SYRION16262’ (10:27:F5:B0:6B:55) [redacted]▂▄▆█ [D][wifi:446]: Channel: 1 [D][wifi:447]: RSSI: -71 dB [I][wifi:445]: - ‘SYRION16262’ (10:27:F5:B0:69:12) [redacted]▂▄▆█ [D][wifi:446]: Channel: 10 [D][wifi:447]: RSSI: -76 dB [I][wifi:257]: WiFi Connecting to ‘SYRION16262’… [I][wifi:518]: WiFi Connected! [C][wifi:362]: Local MAC: 30:C6:F7:2C:B3:3C [C][wifi:363]: SSID: ‘SYRION16262’[redacted] [C][wifi:364]: IP Address: 192.168.254.243 [C][wifi:366]: BSSID: 78:98:E8:34:FA:5A[redacted] [C][wifi:367]: Hostname: ‘esp32-parter’ [C][wifi:369]: Signal strength: -63 dB ▂▄▆█ [C][wifi:373]: Channel: 5 [C][wifi:374]: Subnet: 255.255.255.0 [C][wifi:375]: Gateway: 192.168.254.254 [C][wifi:376]: DNS1: 192.168.254.254 [C][wifi:377]: DNS2: 192.168.254.254 [D][wifi:527]: Disabling AP… [C][ota:093]: Over-The-Air Updates: [C][ota:094]: Address: esp32-parter.local:3232 [C][ota:097]: Using Password. [W][ota:103]: Last Boot was an unhandled reset, will proceed to safe mode in 4 restarts [C][api:025]: Setting up Home Assistant API server… [C][sntp:028]: Setting up SNTP… E (23958) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time: E (23958) task_wdt: - loopTask (CPU 1) E (23958) task_wdt: Tasks currently running: E (23958) task_wdt: CPU 0: IDLE E (23958) task_wdt: CPU 1: loopTask E (23958) task_wdt: Aborting. abort() was called at PC 0x400f803c on core 0 Backtrace:0x400838d5:0x3ffbe9cc |<-CORRUPTED ELF file SHA256: 0000000000000000 Rebooting…
Straszny bałagan jak kopiowałeś te logi, że to taka sieczka?
To ESPHome?
Jakkolwiek moim zdaniem masz uszkodzony wsad (więc póki co nie widzę powiązania z GPIO)
Kompilowałeś kiedyś ten wsad skutecznie?
Aktualizowałeś może ESPHome?
(coś mi się wydaje, że kwietniowe wydanie ma sporo przełomowych zmian, masz możliwość cofnięcia wersji tj. backup?).
Skompiluj na próbę bez komponentu powiązanego z CC1101 i sprawdź czy nadal się wywraca.
Ponieważ wcześniej próbowałem włączyć deepsleep w programie Arduino IDE.
Niestety kod który wgrałem nie włączał mi z powrotem wifi i bluetooth. A jak chciałem wrócić do poprzednich ustawień to się nie dało.
Dlatego wgrywałem nowy z tego poradnika: GADGETS#138 - ESP32 WROOM FLASH - YouTube
Wolałbym abyś opisał własnymi słowami co robisz, bo linkowanie do YT nic nie daje, a oglądanie zabiera za dużo czasu.
Odpowiesz chociaż na cześć pytań, czy mam sobie pozgadywać co robisz i jak?
(bo mam wrażenie że to logi z ESPHome)
Ok od początku:
Chciałem, żeby moje ESP32 Wroom działało na baterii i ładowało się z paneli solarnych.
Z racji tego, że w trybie aktywnym pobiera dużo prądu, próbowałem zrobić taki myk, żeby działał w trybie deep sleep. Włączał wifi i i bluetooth tylko na określoną ilość czasu i je wyłączał.
Pomysł nie wypalił, bo po wejściu w deep sleep mój kod, który utworzyłem w Arduino IDE w pliku TimerWakeUp.ino nie włączał z powrotem wifi i bluetooth. Próbowałem wyłączyć deep sleep, ale się nie udało.
Wziąłem więc i wgrałem wg tego poradnika z youtube 3 pliki:
ESP32_bootloader.bin 0x1000
ESP32_partition-table.bin 0x8000
ESP32_firmware_V1.4_210408 0x1000
Z ustawieniami:
80mhz, DIO,32Mbit, DoNotChgBin
Operacja się powiodła.
Następnie podłączyłem płytkę do komputera.
W programie ESPHOME w Home Assistant doddałem tą płytkę i wgrałem jej podstawowy yamlowy config.
W Home Assistant zainstalowałem i skonfigurowałem dodatek Wmbusmeters.
Następnie w ESPHOME do configu ESP32 Wroom dodałem wpisy do wmbus.
Podłączyłem do ESP32 Wroom CC1101.
Dalej już wiesz. Bootloop.
A żeby nie było działam cały czas na ładowarce od telefonu 5V 1A. Z baterii i paneli zrezygnowałem.
Większość tych wszystkich kroków mogłeś sobie darować - mając prawidłowy skompilowany wsad w ESPHome i tak nadpisujesz cały flash, więc wgrywanie wcześniej jakiegoś randomowego firmware nie miało żadnego sensu.
Zależnie od tego jakie wybierzesz opcje kompilacji w ESPHome powinieneś wybrać flasher
- dla formatu modern
https://web.esphome.io/ - dla formatu legacy
Releases · esphome/esphome-flasher · GitHub - albo skorzystać z opcji jakie daje IDE ESPHome (de facto “Manual download” to te 2 opcje opisane powyżej), przy czym OTA oczywiście nie jest możliwa jeśli na sprzęcie nie pracuje już firmware ESPHome, więc masz możliwość podłączenia po porcie szeregowym (za pośrednictwem USB) albo do hosta na którym pracuje IDE ESPHome czyli zapewne maszyny HA/HAOS, albo do lokalnego komputera gdzie zapewne zostaniesz przekierowany do ESPHome-web (też linkowanego powyżej)
W obu wypadkach otrzymujesz w wyniku kompilacji jeden wielki plik (zawierający wszystkie składniki), tylko te pliki są różne (dla większości metod generowany jest format modern).
Mając już wgrany “pusty” wsad ESPHome (ze standardowymi opcjami) masz już dostępne OTA (więc o ile nie wysmarujesz firmware, które będzie zawieszało/“uwałało” ESP, to będziesz miał opcje flashowania OTA).
Czyli rozumiem, że przez to właśnie
wpada w bootloopa?
Czyli przez co?
Przecież jest oczywiste, że po randomowym wsadzie nic nie powinno było zostać we flashu.
Niestety przemilczałeś dalsze kroki, więc nie wiem co i jak wgrałeś, ale jakieś dziwne ruchy w tym względzie owszem mogły prowadzić do uszkodzonego ELFa.
Generalnie lecisz z grubej rury, zamiast po drodze zastosować “pusty” wsad (tj. taki skompilowany w ESPHome który zawiera minimum podstawowych opcji), coś w tym stylu
esphome:
name: testowy
friendly_name: testowy
esp32:
board: esp32doit-devkit-v1
framework:
type: arduino
# Enable logging
logger:
# Enable Home Assistant API
api:
encryption:
key: "3MPUPHlyZuRv4iGdnrMeHuNn/j7yaGRBSqairar1ZLk="
ota:
password: "b428977669e6ea494f9fb24265c920da"
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Testowy Fallback Hotspot"
password: "mzrZYRpJ8E0K"
captive_portal:
# dalej możesz dokładać własny YAML, to powyżej powinno raczej zostać,
# oczywiście hasła są randomowe (do zmiany na własne),
# ale to tylko przykład YAMLa wygenerowanego kreatorem,
# jakkolwiek dopasowałem go do twojej płytki (definicja pasująca do tej, którą pokazałeś wyżej)
i na nim przetestować stabilność samego układu (zawsze trzeba się liczyć z wadliwym sprzętem), jak rozumiem ten krok wykonałeś, więc kolejne flashowanie już może być przez OTA (o ile nie zmieniasz frameworka).
A dopiero potem się brać za jego rozbudowę (stosujesz zapewne komponent niestandardowy, więc wszelkie aktualizacje ESPHome mogą wpływać na to co uzyskasz w wyniku kompilacji, ba, nawet jeśli używasz tylko “standardowe” komponenty to aktualizacje mogą mieć wpływ - to jest projekt, który rozwija się może nieco wolniej niż HA ale i tak bardzo szybko, więc zmiany są nieuniknione).