Uppdatering gav problem? ESP32 - Arduino IDE

[FormerMazda]

Jag har ett långtidsprojekt som ÄNTLIGEN började närma sig slutet.

Detta är en ESP32 med en lite OLED och DS18B20 mm som ska sitta i rummen i huset.
Jag började för längesen att bygga dessa och egentligen var utvecklingen klar och fungerande för över ett år sen, men nu byggde jag ihop de sista modulerna.

Så allt löddes ihop, en och en programmerades dom för att verifiera att allt funkar, men ingen lyckas längre läsa tempgivaren?
Mycket felsökning senare så upptäcker jag att det måste bero på en uppdatering i nåt bibliotek eller "board" i arduni IDE.
För det som slutligen gav det svaret var att jag kunde ta en gammal fungerande pryl, ladda ner samma program i den och den slutade funka..

Jag använder bibliotek OneWrie.h och DallasTemperature.h för givaren.
Bägge dessa har jag provat att backa rätt många versioner.
Sen använder jag esp32 boards från espressif, även den har jag testat att backa.
Men nu är det bara tyst på den pinnen som DS18B20 är ansluten på.

Så hur gör man nu? Hur hittar man vad som är fel?
Google ger inget mer än exempel på inkoppling och kod, och det är samma än.

Det enda som inte känns helt klockrent är att jag har en uC som är märkt ESP-WROOM-32D, och exakt den finns inte i boards, men nästan vilken ESP32 man tar så verkar det funka.
Allt annat funkar, OLED, analog och digital in, adresserbar LED, mm mm. Men inte DS18B20.

Tips?

[Icecap]

Har du definierat rätt pinne? Och använder den pinna BARA ett ställe?

[FormerMazda]

Japp och yes.
Koden är oförändrad sen sista utgåva i princip.
Testade att byta pinne, men det var lika tyst på den.

Och som sagt, hade en sen innan programmerad enhet, fullt trafik på pinnen, tryckte ner programmet igen och då blev det tyst.

[Skogen]

Kan det vara samma problem/lösning?:
https://forum.arduino.cc/t/onewire-libr ... /1266351/8

[FormerMazda]

Jag vet varken ut eller in längre..

Jag har nog testat allt jag kunnat läsa mig fram till.
Så jag har backat boards till tidiga v2, bytt OneWire till OneWireNG, allt i olika kombos av nya och gamla utgåvor.
Det är EXAKT samma resultat, kan inte ens få nåt mer att sluta funka.

Ytterligare en "kul" grej är att en av mina moduler säger -128,0°C, medan alla andra säger -127,0°C.
Så hur i hela friden den kan säga så, det vetefåglarna.. Men jag börjar tappa tro och hopp här.

Jag har alltså 7st likadana byggen, alla med delar beställda från samma leverantör februari 2022.
Två av dom byggdes ganska snart som lite beta-test, och dessa funkar. Trafik på data-pinnen och värden kommer.
Ingen av de andra fem har trafik på data-pinnen, och en av de som funkade slutade funka när jag tryckte ner programmet igen, data-pinnen blir tyst.

Men om man nedgraderar alla libs och boards så mycket som går så borde det ju hoppa igång igen, men icke.

Får nog sova på saken, för nu börjar jag få slut på idéer.

[Icecap]

Ja, det är en orsak till att jag aldrig användar färdiga libbar...

Men har du källkoden till libbet kan du ju hitta felet.

[rvl]

Har inte satt mig in i hur lätt/svårt det är att dumpa minnet från en ESP32. Kunde ju vara intressant att klona den fungerande till en nu icke fungerande.

Skriver programmet nåt i Serial Monitorn? Kunde vara en väg att debugga. Exempelvis om programmet fastnar tidigt på att inte kunna logga in på din router, då kanske det inte händer så mycket mer efter det.

[FormerMazda]

Om jag visste vilket LIB som bråkar.

Dessa använder jag nu:
#include <SPI.h> //För OLED
#include <Adafruit_SSD1306.h> //För OLED
#include <ModbusRTU.h> //Modbushanteringen
#include <OneWire.h> //Onewiredriver
#include <DallasTemperature.h> //Interface DS-givare
#include <Preferences.h> //Persistent variabler
#include <FastLED.h> //För LED

Och faktiskt, kör jag test projektet i DallasTemperature (som inkluderar OneWire) så funkar det!
Men kör jag mitt stora projekt så funkar det inte.
Så nåt av de andra includesen i kombo med DallasTemperature skapar oreda.

Jag har trippelkollat att jag inte försöker använda min pinne 19 till annat än DS18B20, även genom att kolla på de suspekta LIBsen och vad de kan ha för default pin-definitioner.
Men jag hittar inget.

Ska nog testa att köra test projekt på de andra LIBsen och kopiera in testet från DallasTemperature och se om det krockar till slut med nåt av dom.

rvl:
Jag känner inte till nåt sätt att dumpa, men jag har nog inte kunskap att tolka nåt ur en eventuell dump ändå.
Jag har ingen "debug" aktiv i mitt program, men allt snurrar på med OLED, LED, modbus mm. Så jag antar att allt annat snurrar på.

[hawkan]

Divide and conquer.
Dela upp koden, uteslut så mycket det går för att renodla.
Om inte det hjälper, uteslut mera.
Ta ett renodlat exempel för att se om saker fungerar utanför dina kod.

[Icecap]

Kan ju vara att 1-Wire kräver någon timer som något ANNAT lib läggar vantan på.
Alltså en resurs som är tänkt att vara för enbart 1 funktion - men 2+ gör anspråk på den.

[JimmyAndersson]

Från första inlägget:
”För det som slutligen gav det svaret var att jag kunde ta en gammal fungerande pryl, ladda ner samma program i den och den slutade funka..”

Jag är inte riktigt med. Har det fungerat tidigare? När slutade det fungera?

När det gäller libraries: Oavsett om de kommer från nätet eller är egna så kan man ju testa dem.
Det är ju oftast [input]—>[funktion]—>[output]
Därför bör det gå att logga vad som åker in och vad som kommer ut, och kika så det inte är totalt orimligt.
Rvl är inne på samma spår.

[Borre]

-27 är en errorkod från DallasTemperature-biblioteket:
// Error Codes
#define DEVICE_DISCONNECTED_C -127

Så fungerar det med bara det biblioteket så borde det vara nått annat som ställer till det med den pinnen eller liknande.

[CPMS]

Prova att köra programkoden i ChatGPT, den är ganska bra på att hitta fel och föreslå förbättringar.

[FormerMazda]

Nu är man tillbaka i internetigheten igen, så här är ett par svar på senaste kommentarer:

JimmyAndersson: Samma kod som var nedladdad i en modul funkade till jag i test ladda ner den igen, nu med uppdaterade LIBs.

Borre: Japp, för nåt ställer till det för <OneWire.h> eller <DallasTemperature.h>. Detta kan jag anta då dessa två LIBs används i ett exempel från DallasTemperature och funkar om jag kör enbart det.

Så med hawkans princip ska jag försöka hitta det. Genom att köra DallasTemperature exempelkoden, sen lägga på LIBs och funktioner till det inte funkar mer.
Men när jag hittar två som inte funkar ihop så vetefåglarna vad jag ens gör då. Funkar inte LIBs för OLED och DallasTemperature ihop så faller liksom hela idén med denna modul.
Den bron får jag korsa när den kommer.

[pi314]

1. "Dumpa minnet".
Jag uppfattar det som att det som rvl menar är at läsa ut programmet från en fungerande enhet och läsa in det i en nu icke-fungerande och se om den också fungerar med det "gamla, fungerande" programmet.
Jag har gjort det någon gång, men det var länge sedan och jag har glömt hur jag gjorde. Jag hittade den här instruktionen nu, för Arduino. Det var inte den metoden som jag använde. Jag använde ett program, som jag inte minns vad det heter. Jag vet inte om det går och hur man i så fall gör med ESP32.
https://www.instructables.com/How-to-Ge ... m-Arduino/

2. Olika bibliotek.
Jag har flera gånger råkat ur för att olika bibliotek inte fungerar tillsammans. Ibland fungerar dom inte alls tillsammans. Ibland kan det vara att när en del av min kod blir för stor eller tar för lång tid, så slutar ett bibliotek fungera.

3. OLED och DS18B20
Jag har kört dessa två tillsammans en del i Arduino. Jag har använt DallasTemperature.h, men har gjort ett eget bibliotek för OLED. Det var ett tag sedan jag gjorde OLED-biblioteket, men som jag minns var orsakerna till att jag gjorde det, att dom jag hittade och testade:
– Fungerade dåligt eller inte alls tillsammans med DallasTemperature.h.
– Inte erbjöd dom alternativ för visning som jag ville ha. Bl.a. teckenset och teckenstorlek.
– Var för stort (tog upp för mycket minne).

Jag har inte gjort det (ännu), men jag har för mig att jag inte var nöjd med DallasTemperature-biblioteket heller. Att jag tänkte skriva ett eget. Men, jag har inte gjort det ännu.

Det här är dom "include" som jag har i ett program som läser effekt från elmätaren, temperatur från en eller flera D18B20 och växelvis visar resultaten på en OLED-display. "OLEDmin" är mitt OLED-bibliotek. "min" är kort för "minimalt". Jag har kört det på Uno och på Mega 2560.

Kod: Markera allt

#include <OneWire.h>
#include <DallasTemperature.h>
#include <OLEDmin.h>                // Small OLED library prefix.

Jag har övervägt att lägga upp OLEDmin på Github, men kod, kommentarer och dokumentation är inte i sådant skick att jag vill sprida det. Det krävs lite "städning" och dokumentation först.

4. Bibliotek som inte fungerar eller inte fungerar tillsammans med andra bibliotek.
Detta är nog det som gett mig mest huvudvärk när jag hållit på med Arduino. I några olika former.
(a) Ett bibliotek fungerar inte alls. Är det inte kompatibelt med min hårdvara?
(b) Två bibliotek fungerar inte tillsammans.
(c) Två bibliotek slutar fungera tillsammans när min kod blir "tillräckligt" stor eller tidskrävande.

Oftast har jag hittat ett annat bibliotek, som har löst problemen. Just för OLED gjorde jag ett eget. Jag har för mig att orsaken till att jag vill göra ett eget för DS18B20 är för bättre hantering av flera DS18B20 och för att minska "upplåsning" av processorn.

/π