kaczakat

Użycie WDT w kodzie to dwie linijki (no trzy z biblioteką, cztery jak również go wyłączasz): /* 1 s WDTO_1S ATMega 2 s WDTO_2S ATMega 4 s WDTO_4S ATMega 8 s WDTO_8S ATMega wdt_enable(WDTO_4S); wdt_disable(); wdt_reset(); */ #include <avr/wdt.h> void setup() { // put your setup code here, to run once: Serial.begin(115200); wdt_enable(WDTO_4S); Serial.println("Program został uruchomiony na nowo."); } void loop() { // put your main code here, to run repeatedly: wdt_reset(); static int zmienna=0; delay(1000); Serial.print("Program dziala od sekund: "); Serial.println(zmienna++); delay(zmienna*100); } W komentarzu we wstępie jest zestawienie przydatnych opcji. Program tak musi być napisany, bo do pierwszego polecenia w loop wracał nie rzadziej niż czas do resetu. Jeśli używasz gotowej płytki Arduino to usypianie tak średnio się opłaca. Jeden led może zużyć więcej prądu niż uC, a jeszcze ustawiony tak jak proponuje marek1707 to już w ogóle...

WDT ma dwie główne funkcje, jedną z nich jest wybudzanie procesora z trybu SLEEP_MODE_PWR_DOWN, drugą to dbanie o ciągłość pracy programu. W trybie uśpienia nic Ci się nie zawiesi (bo wszystko przecież sam zatrzymałeś) i korzystasz z funkcji wybudzania, po ponownym wznowieniu działania programu możesz go "ustawić" w tryb ochrony przed zawieszeniem - do ewentualnego generowaniem resetu. W trybie uśpienia budzisz uC co max 8s, bo tyle max można ustawić czas WDT, jak potrzebujesz ustawić spanie na ~60s to możesz go uśpić na 15x4s lub 8x8s. Gdy to nie jest to właściwe przebudzenie to natychmiast usypiasz go ponownie. Gdy uC nie ma się okresowo wybudzać to po prostu wyłączasz WDT, włączasz po ponownym wybudzeniu. Dzięki temu można zejść ze zużyciem prądu w czasie uśpienie poniżej 200nA. Z włączonym WDT zużycie prądu sporo rośnie, coś w końcu musi działać. No i generalnie to "sporo" ma znacznie na swojej płytce, ewentualnie w PRO MINI z wylutowanymi LED, w UNO i tak działają ledy/mostki/itp, które nawet jak wyjmiesz Atmegę z płytki zjadają kilkadziesiąt mA. Opis użycia do wybudzania: http://www.gammon.com.au/forum/?id=11497 , przy okazji sporo informacji jak to robić by uzyskać te 100-200nA, jak wyłączyć naprawdę wszystko.

Sprawdź jakie napięcie dostajesz za regulatorem 3.3V, dla mnie jest tu razem ze swoja otoczką głównym podejrzanym. Cena tej płytki <1.5$ nie wzięła się znikąd, mam ich kilka i raz USB nie łączy, raz piny krzywe, ludzie piszą, że te procki to w ogóle jakaś podróbka STM. No ale jakoś tam ostatecznie to działa. Niestety na początku jest to problem gdy nic nie wiesz - bo nie wiesz czy źle podłączasz, źle programujesz, czy płytka do bani. Ostatnio też się okazało, że i narzędzie do konfiguracji CubeMX bywają wadliwe, no jeszcze koła, szyny i podwozie...

Dopóki masz go na stykówce po prostu zostaw sam kwarc i wywal kondensatory, jak procesor rusza to znaczy że problemu szukać trzeba gdzie indziej. Mam nawet taki układ polutowany na płytce uniwersalnej i działa bez problemu na samym kwarcu, testowałem od 1-20 (i 32) MHz, UART po kabelkach i BT, również niekorzystne baudrate jak 115200 -500000 i wszystko działa OK. Pewnie z kwarcem 12pF byłoby lepiej, ale właśnie też takiego nie miałem.

22pF to wartość maksymalna, zajrzyj jeszcze raz do noty katalogowej, tam jest coś-22pF. Jak doliczysz pojemność z blaszek w stykówce to może się okazać, że właśnie dlatego bez tych 22pF działa lepiej.

Nawet moduł z elektroniką jest tylko dla tych, którzy wiedzą co robią - napięcie 230V. Nie możesz tego podłączyć pod piny uC, jedyne co będzie wspólne to zasilanie Arduino i płytki przekaźnika (jak ją zrobisz) z zasilacza 5V. Płytka z napięciem 230V powinna być odpowiednio zaprojektowana. Do lampki nocnej wystarczy przekaźnik SSR.

Ostatnio ktoś się chwalił LCD z zamienionymi pinami DATA i CLOCK, tak że można to sprawdzić. Wymiana kabelków też czasami pomaga. I warto sprawdzić połączenia miernikiem.

Dzięki za potwierdzenie moich podejrzeń. Każdy projekt zrobiony z pluginem 5.1 tak się właśnie u mnie zachowuje, znika realna wielkość po kompilacji, zostaje 8 bajtów. Zacząłem się tym bawić kilka tygodni temu i nie wiedząc co robię źle wrzuciłem płytkę do lodówki. To samo mam z Blue PILL, Nucleo i STM32F407VET6. Dzisiaj podjąłem walkę od nowa, zainstalowałem AC6, a potem wersję niezależną cubeMX 5.2.1 i na razie sobie radzi ze zmianami, ale projekt zepsuty pluginem już zostaje zepsuty. Projekty nieuszkodzone można było przenieść do nowszej wersji opcją "Migrate". Jak ktoś ma linka do starszego/nowszego pluginu, który działa prawidłowo z Eclipse/AC6 SystemWorkbench to proszę o info. I może dodać ostrzeżenie o tym do kursu, bo ze strony STM nie można raczej ściągnąć innej wersji?

Ciii, nie wszystko na raz .

Jeśli przekopiowanie tych tych 3 linijek do swojego programu to problem #include <avr/wdt.h> void setup() { wdt_enable(WDTO_4S); } void loop() { wdt_reset(); } to faktycznie trzeba żyć z zawieszkami.

Niestety temat wygląda tak, że mając problem z nierówną pracą silnika i gaśnięciem auta w losowych momentach przymierzasz się do rozwiązania problemu montując zestaw nitro. Jeśli nie ogarniesz Arduino AVR do pracy dokładnie tak jak tego oczekujesz to po dołożeniu/zamianie na ESP będzie "nieco" trudniej. Do Arduino z AVR masz tu kurs, pewnie jest sporo użytych tych elementów z kitu. Z DHT odczyt nie ma sensu częściej niż fabryka przewidziała, bo tracisz na to w każdej pętli 250ms, a on sobie wewnątrz scalaka i tak nic nowego nie wymyśli w te 2s, masz więc 1 odczyt z nową informacją i 7 powtórzonych, co dodatkowo negatywnie wpływa na stabilność jego pracy. Oczywiście czujnik ma jeszcze taki parametr jak "Response Time", czyli nawet jeśli warunki się zmienią, to czujnik potrzebuje 1-20s żeby to zauważyć, DHT ma około 5s. Tutaj można porównać różne czujniki: http://www.kandrsmith.org/RJS/Misc/Hygrometers/calib_many.html, z własnych obserwacji wiem, że odczyt HTU21D i Si7021 trwa około 50ms, a BME280 po około 2ms. Co do dokładności pomiarów to podzielam zdanie tego testu z linka. Mam teraz podłączone te czujniki i jak znajdę wzorcowany miernik to dopiszę jakie są odchyłki, na razie DHT jest mocno z boku innych odczytów, no ale może akurat on ma racje - nie wiem.

Ja używam do dużych uC Atmega16/32/644/1284 https://github.com/MCUdude/MightyCore.

@hazi18, jeśli ten program używasz od dwóch lat to trochę zakopałeś te swoje 2 talenty. Jest do poprawy na wielu poziomach. Po pierwsze WDT, to tylko 3 linijki dodatkowe, jeśli to Arduino się zawiesi to rozwiąże problem, przykład: https://circuits4you.com/2018/01/24/tutorial-on-arduino-watchdog-timer-setup/. Kolejne to czujnik, jest niestety kiepskim wyborem, odczyt trwa ~250ms, lubi się powiesić. Nie używam go na co dzień, ale leży w szufladzie to sprawdziłem. W przykładzie jest jak zweryfikować czy w ogóle działa, Ty tego nie masz: if (isnan(h) || isnan(t) || isnan(f)) { Serial.println("Failed to read from DHT sensor!");, chyba warto zweryfikować czy w ogóle należy używać odczytanych wartości w dalszej części programu. Warto też dodatkowo sprawdzić, czy nie są jakieś trzepnięte, np. mniejsze niż 15oC czy większe niż 50oC, bo to w tym wypadku też byłoby podejrzane. Jak czytałem na forum sam reset układu Arduino + DHT często nie pomaga, trzeba odłączyć zasilanie by wszystko znowu zaczęło działać, chodzi zapewne od odłączenie czujnika, bo sam uC Atmega pracuje wg mnie bardzo stabilnie w porównaniu np. do ESP8266 czy ESP32, no w porównaniu z nimi to jest jak skała, wg mnie nie w tym leży problem. WDT w ESP czasami niewiele daje, gdy problemem jest jakiś spadek napięcia i procesor po prostu nie wstaje. W AVR domyślnie jest włączony BOD, który działa wg mnie znacznie pewniej. Dla DTH rozwiązaniem jest zasilenie go z pinu procesora, pobór prądu DHT rzędu kilku mA to pikuś dla AVR, po resecie z WDT wystarczy profilaktycznie wstrzymać program na 2s ze stanem niskim dla nóżki VCC DHT i masz czujnik zresetowany. Czyli po prostu zasil DHT jakbyś zaświecał leda, też można dać rezystor R=100. Odczyt DHT nie ma sensu częściej niż co 2s, w ogóle w programie nie zarządzasz czasem. Tu na blogu jest kurs Arduino, uzupełnij wiedzę o millis(). 3 ekrany nie mają sensu, wystarczy na jednym przez sekundę pokazywać np. 23.3C, potem przez sekundę 44.4H, potem ewentualnie stan licznika timeup sekund czy minut od resetu, by zauważyć czy był jakiś reset od WDT. Można też wymienić na jakiś z I2C. Trzy ekrany powinny też bez problemu działać na jednym pinie zegara jak zauważył @ethanak, jednak ta biblioteka ma kaprysy, ja sobie podłączyłem do pinów 11 i 13 i nie ruszyła w ogóle, piny są OK, bo inna biblioteka zadziałała. Przepiałem na domyślne 2 i 3, potem na 4 i 5 - tu było OK. Nie wiem o co jej chodzi.

Wystarczy dodać do Arduino WDT jako pierwszą ochronę przed przegrzaniem, a mechaniczny termostat jako stopień drugi. Padnie Internet i znowu będzie BALUT na obiad.

Komunikaty błędów kopiuj i wklejaj jako tekst/code/spojler. Na razie przesuń sobie bibliotekę do ESP8266 z katalogu Libraries gdzieś w inne miejsce i spróbuj ponownie. W niektórych projektach core ESP8266 2.5.cośtam mi nie działa, cofnąłem sobie do wersji 2.4.cośtam.