Hallo, ich muss dringend einen MCP3021 mit einem ESP32 zum laufen bekommen.
Leider habe ich das Problem, dass die Daten schlicht nutzlos sind, die ich erhalte.
Die Spannung am Analog Pin ist sauber von 0 - ca. 2.5V in dem Bereich, wo ich ihn nutze. Vdd ist 3.3V.
Das Resultat ist immer höchst wechselhaft, nur in einem kleinen Bereich linear, z.B. Wert 600-700, dann bin ich plötzlich wieder bei 500, wenn ich die Spannung weiter erhöhe.
Hardwaremässig kann man ja denke ich nicht viel falsch machen. Habe trotzdem noch ein Bild angehängt. Pullups sind natürlich auch dran an SCL und SDA (10k).
Der Code ist ja auch extrem simpel:
uint16_t result = mcp3021.readADC();
Serial.print("Value: ");
Serial.println(result);
Für die mkuniac Library.
Hat jemand eine Idee oder funktionierenden Code für Arduino?
Wäre sehr dankbar, ansonsten muss ich wohl ein SO-8 IC auf den SOT23 Footprint basteln, da ich diesen erfolgreich getestet habe. Dies möchte ich sehr gerne vermeiden.
Und wo ist der Schaltplan und der Aufbau? Ich fürchte sehr dass
du über die Speisespannung massive Störungen hereinbekommst,
auch wenn ich bisher keine Schaltung gesehen habe. Selbst
dein Spannungsteiler für den ADC Input hat keinerlei weitere
Dämpfungsmechanismen für Störungen und ist sehr hochohmig. Kann
also viel passieren, zumal die Referenz des ADC offensichtlich
auch gleich die Versorgungsspannung ist. Der ESP32 wird deine
Versorgung nicht "in Ruhe lassen". Wenn jetzt dein UBat geteilt
durch den Spannungsteiler zufällig höher ist als deine Versorgungs-
spannung dann ist die Kacke auch am Dampfen ....
Und wo ist der Schaltplan und der Aufbau? Ich fürchte sehr dass
du über die Speisespannung massive Störungen hereinbekommst,
auch wenn ich bisher keine Schaltung gesehen habe.
Hi, das ganze ist ein Custom PCB, wird von einer 12V Batterie gespeist, geht dann erstmal durch einen externen 12V Regler für den hochstromteil (LED-Controller, um konstante Helligkeit zu erreichen bei gleicher Ansteuerung), der ESP32-WROOM und die Peripherie bekommt eine stabile 3.3V Spannung aus einem Schaltregler. (Anhang)
Ich habe auch ein paar andere I2C Komponenten, die problemlos laufen.
Als Spannungsquelle nutze ich momentan ein Labornetzgerät, das ich auch vorher schon benutzt habe.
Hi, das ganze ist ein Custom PCB, .........
...........
Aus dieser scheiss Prosa sollen wir uns jetzt den kompletten
Schaltplan zusammenreimen? Ja was jetzt? Batterie oder
Netzteil? Von wo nach wo? Jede Menge Ungwägbarkeiten.
LED-Controller, Schaltregler, jede Menge Quellen für Störungen
Hast du ein Oszilloskop mit dem du deine Versorgung mal ansehen kannst ?
digitale schaltungen stören sich nicht dran wenn die Versorgung bisschen schwankt, aber deiner analogen Bude verhagelt es halt das Ergebnis.
Hast du ein Oszilloskop mit dem du deine Versorgung mal ansehen kannst ?
digitale schaltungen stören sich nicht dran wenn die Versorgung bisschen
schwankt, aber deiner analogen Bude verhagelt es halt das Ergebnis.
Leider gerade nicht zur Hand, hätte irgendwo noch ein altes, analoges rumliegen.
Da steht unter anderem in Kapitel 6: Der Baustein hätte gerne eine niedrige Eingangsimpedanz.
In 6.2 steht 10kOhm Pullup des I2C ist für 100kHz, bei 400kHz sollten es eher 2K2 sein.
Eine weitere Möglichkeit für Fehler könnte eine schlechte Masseführung sein, falls größere Ströme über die gleiche Masse führen an der der Baustein hängt, der Eingangsspannungsteiler aber nicht.
So eine PWM eines LED Drivers die die Masse ein paar 100mV hochzieht könnte solche Effekte z.B. herbeiführen.
Eine weitere Möglichkeit wäre dass das Netzteil das zum testen verwendet wird bei PWM in Überlast kommt oder warum auch immer schwingt. Die Schaltung funktioniert durch den Spannungsregler noch, aber man misst halt unterschiedliche Spannungen wegen der Schwingung.
Da steht unter anderem in Kapitel 6: Der Baustein hätte gerne eine
niedrige Eingangsimpedanz.
In 6.2 steht 10kOhm Pullup des I2C ist für 100kHz, bei 400kHz sollten es
eher 2K2 sein.
Eine weitere Möglichkeit für Fehler könnte eine schlechte Masseführung
sein, falls größere Ströme über die gleiche Masse führen an der der
Baustein hängt, der Eingangsspannungsteiler aber nicht.
So eine PWM eines LED Drivers die die Masse ein paar 100mV hochzieht
könnte solche Effekte z.B. herbeiführen.
Das I2C Interface läuft auf 100kHz, da ich die Standard Wire library verwende.
Der PWM Output ist im Moment auch nicht aktiv, die Störungen können also auch nicht von da kommen.
Das Resultat ist immer höchst wechselhaft, nur in einem kleinen Bereich
linear, z.B. Wert 600-700, dann bin ich plötzlich wieder bei 500, wenn
ich die Spannung weiter erhöhe.
Zu welcher vbat gehören diese Werte? Ich vermisse einen Tiefpass/Pufferkondensator am Eingang des ADC.
Wenn ich richtig sehe, dann hat der von dir gewählte Tantal den doppelten ESR von dem im Datenblatt des MIC4680? Ich denke außerdem, dass die Versorgung überdimensioniert ist. Der wird viel im lückenden Betrieb laufen was viel Ripple auf den 3.3V bedeutet. Auch ist der MIC recht lahm bei Transienten, davon erzeugt gerade der ESP viele. Gegen Schwankungen suf der Versorgung ist der ADC allergisch. Du solltest auf jeden Fall einen LC Filter vor den ADC setzen, besser wäre eine separat stabilisierte Versorgung/Referenz. Der Hinweis mit den 10uF im Datenblatt des ADC steht da nicht zum Spaß.
Stimmt, den 10uF habe ich offenbar weggelassen. Ob es daran liegt?
Ja, der Regler ist überdimensioniert für den ESP32. Ich wollte noch Reserve haben für allfällige Peripheriemodule, die nachgerüstet werden. Ich wusste nicht, dass dies das Regelverhalten negativ beeinflusst.
Getestet habe ich den Bereich von ca. 4V - 12V, aber die Werte machen keinen logischen Sinn. bis ca. 6V ändert sich der Wert nicht grossartig von ca. 350, danach gehts auf einmal auch wieder zurück auf 250, später bei ca. 8v sprungweise auf 700, wo es dann für ein paar 100mV einen linearen Eindruck macht, um danach wieder kleinere Werte auszugeben.
Getestet habe ich den Bereich von ca. 4V - 12V, aber die Werte machen
keinen logischen Sinn. bis ca. 6V ändert sich der Wert nicht grossartig
von ca. 350,
Der MIC läuft doch erst ab 4V an, kommen bei 4V vbat überhaupt noch 4v am MIC an? Der externe 12V Regler wird ja auch noch was brauchen?
Ich würde mir erstmal Gedanken um die 3.3V machen. Mal mit dem Oszi draufschauen. Mehr als ein paar mV Ripple darf da nicht sein. Wie oben schon geschrieben könnte auch dein Labornetzteil oder Dein 12V Regler schwingen, Schaltregler haben eine negative Impedanz am Eingang...
Vielleicht gibt es auch Konflikte auf dem I2C? Ohne Oszi kommst Du da nicht weiter...
Der MIC läuft doch erst ab 4V an, kommen bei 4V vbat überhaupt noch 4v
am MIC an? Der externe 12V Regler wird ja auch noch was brauchen?
Kann sein, dieser Bereich ist auch nicht relevant, habe halt schnell durchgetestet mit dem Labornetzteil. Relevant ist, dass von 8-13V korrekte Messwerte vorliegen. Der Analogeingang vom ADC kommt aber direkt von der Eingangsseite des 12V Reglers, nur die Versorgungsspannung wird danach abgegriffen. Es ist ein China Buck-Boost Regler, bis runter auf 8V gibt er die 12V aus.
Danke für die Tipps, ich werde am Wochenende das Oszilloskop besorgen und die 3.3V anschauen. Auch noch testweise den fehlenden 10uF Kondensator anlöten über der Speisung vom ADC.
Der 12V Regler sollte nicht das Problem sein. Zumindest hatte ich es zuvor schon mit einem anderen ADC erfolgreich betrieben (MCP3426). Da hatte ich aber auch noch einen 3.3V Linearregler anstelle des Schaltreglers.
Ich habe danach viele Hardwareänderungen gemacht, u.a. aus Effizienzgründen auf den Schaltregler gewechselt, da das Ganze möglichst wenig Strom von der Batterie verbrauchen soll.
Du bist dir sicher das Masse am Eingang des Daygreen mit der am Ausgang verbunden ist? Das ist bei Buck/Boost normalerweise nicht der Fall (außer es ist ein SEPIC)
Du bist dir sicher das Masse am Eingang des Daygreen mit der am Ausgang
verbunden ist? Das ist bei Buck/Boost normalerweise nicht der Fall
(außer es ist ein SEPIC)
Weiss ich nicht sicher, aber würde es schaden, sie trotzdem zusammenzuhängen?
Dein Code nutzt von den 10 bits des Wandlers nur die untersten 8, die zwei höchstwertigen werden durch die 6bit - Schiebeaktion entsorgt. Das macht nur sinn, wenn die zu messende Spannung < VDD/4 ist.Wenn die Referenz 3.3 V ist, ist also bei ca. 0.8V Schluss und die Zählung fängt wieder bei 0 an.
Hardwaremässig kann man ja denke ich nicht viel falsch machen. Habe
trotzdem noch ein Bild angehängt. Pullups sind natürlich auch dran an
SCL und SDA (10k).
Bei 3.3 Volt sollten die Pullups viel kleiner sein, schau Dir mal die Flanken mit dem Oszi an.
Habe leider keine richtige Messsonde mehr gefunden für das Oszi, ich vermute, ohne Teiler kann ich nicht in den mV Bereich gehen, weil dann das Bild über das Fenster hinausschießt (ist lange her, dass ich das letzte Mal so ein Teil angeschmissen habe).
Werde mir wohl so ein USB Teil besorgen.
Bei 0.5V / Div zumindest sehe ich überhaupt keinen Ripple auf 3.3V.
Also ich geb' es echt auf mit diesem ADC. Wurde der eigentlich schonmal erfolgreich eingesetzt? Hätte ich gewusst, was für eine Diva von einem ADC das ist, hätte ich es mir noch mindestens 7 Mal überlegt, den ADC zu wechseln.
Ich habe noch den 10uF Kondensator über der Speisung vom ADC angeschlossen, I2C Widerstände auf 4k7 gewechselt, gleiches Resultat.
Diese Werte haben nichts mit einem "mimosenhaften IC" zu tun, die sind schlicht und einfach Müll. Keine Linearität, einfach Mist. Irgendwas an deinem Aufbau und/oder Programm ist verkehrt.
Geh halt mal systematisch vor: mit einem (batteriebetrieben!) Multimeter Pin 2+1 messen (3.3V da?). Als nächsten Pin 2+3 - ca 1/5 der Batteriespannung da? Verschiedene Werte ausprobieren, das Verhältnis Batteriespannung zu Messwert muß konstant sein. Wohlgemerkt, wirklich die Pins am IC messen, nicht irgendwelche Testpunkte!
Wenn das stimmt, mit dem Oszi den I2C-Bus aufnehmen (wenn möglich die anderen I2C-Slaves entfernen). Stimmt die Adresse und das R/W-Flag. Werden Daten übertragen, passen sie zum Messwert und stimmen sie mit denen des Programms überein?
Kannst dir Testweise auch mal die empfangenen Rohbytes ausgeben (am besten, bevor du sie ins RAM schreibst - ich traue deinem "i" nicht - überprüfen, ob das wirklich 2 wird!).
Sinn ergibt die API eh nicht. Entweder das requestfrom ist synchron, dann braucht es den available nicht. Ist es asynchron, muß für jedes Byte per available gepollt werden, bis es da ist.
Wie auch immer, deine Methode, bei available==0 abzubrechen, kann im Fehlerfall nicht richtig sein (entweder du bekommt weniger als 2 Bytes und lieferst Zufallszahlen zurück oder es kommen mehr und du überschreibst dir das RAM). Und falls die API asynchron ist (die Doku lässt sich darüber nicht aus), kommt auch im Normalfall nur Müll raus.
Werde ev. Zu späterem Zeitpunkt nochmals auf Fehlersuche gehen wie du es beschrieben hast. Jetzt muss ich erstmal das Projekt abliefern. Habe mir dazu eine externe Lösung per UART verbunden, was jetzt funktioniert. Habe zum Glück eine zusätzliche UART Schnittstelle eingeplant.
Sinn ergibt die API eh nicht. Entweder das requestfrom ist synchron,
dann braucht es den available nicht. Ist es asynchron, muß für jedes
Byte per available gepollt werden, bis es da ist.
Sympathisch ist mir die Library auch nicht. Vor allem wie du gesagt hast, kaum dokumentiert.
Warum benutzt du sie dann? Es kann doch nicht so schwer sein, einen ADC
"zu Fuß" abzufragen.
Das ist überhaupt nicht schwer, ich frage mich warum man dafür
überhaupt eine Lib braucht. Die behindert eher als dass sie hilft,
weiss man doch (als Arduino-Jünger) nicht was die im Hintergrund
bzw. im Inneren so tut.
Protokoll im Datenblatt verstehen und SPI Protokoll anwenden....
Die behindert eher als dass sie hilft,
weiss man doch (als Arduino-Jünger) nicht was die im Hintergrund
bzw. im Inneren so tut.
Die kann man aber einsehen und analysieren. Die liegt nämlich als Quellcode vor (wie in einem anderen Beitrag von Jona S. zu sehen).
Sein Problem liegt wohl eher allgmeine an mangeldem Wissen (böse Unterstellung).
Der Code ist doch minimal, was soll in der Lib falsch sein?
Wie ist denn Geschwindigket des AD Wandler, wird der evtl. zu schnell ausgelesen? Was passiert mit einem Delay von ein paar ms zwischen aufrufen?
Wie ist denn Geschwindigket des AD Wandler, wird der evtl. zu schnell
ausgelesen?
Der ist lt. DB und meiner Rechnung schnell genug, um während der Übertragung des ACK und dann der vier binären Nullen des ersten Antwortbytes selbst bei 400kHz I2C-Geschwindigkeit mit dem Sampling und der Konversion fertig zu werden.
Der [ADC] ist lt. DB und meiner Rechnung schnell genug, um
Und woher weißt du, ob die Lib auch langsam genug ist? ;-)
Die Schleifen-Endebedingung mit available() > 0 ist grundsätzlich ein extrem grober Fehler und kann bei zu schneller Lib leicht zu Zufallswerten führen, wie sie der OP beobachtet hat.
Und woher weißt du, ob die Lib auch langsam genug ist? ;-)
Weil in Wire.requestFrom() schon die gesamte Kommunikation stattgefunden hat, und mit Wire.available() nur noch aus einem internen Puffer des uC gelesen wird.
Genau, ich habe einen Verpolungsschutz per MOSFET realisiert, bei dem
das Ground unterbrochen wird. Danach ist aber alles auf dem gleichen
Ground.
Und vorher schon werden die Absolute Maximum Ratings einiger Bausteine verletzt...
Kurz: es ist die absolut schlechteste Idee, rinem Baustein die Bezugsmasse zu nehmen. Der sucht sich dann irgendeine andere. Und nimmt dabei evtl. bleibenden Schaden.
Dann miss mit dem Oszi, was auf dem Bus an den Pins der beteiligten Komponenten bezogen auf ihren jeweiligen GND-Pin los ist, und schau, ob das zum Datenblatt passt.
Weil in Wire.requestFrom() schon die gesamte Kommunikation stattgefunden
hat, und mit Wire.available() nur noch aus einem internen Puffer des uC
gelesen wird.
Gut, wenn das in der vom OP benutzten Lib so ist, dann sollte das Programm trotz des Schleifenfehlers funktionieren.
Auch wenn dies hier nicht das Problem ist, sind die Widerstände für
meinen Geschmack zu hochohmig.
Woher willst du wissen, welche Kapazität der Bus bei Luca hat?
Hast du schon einmal in die I2C-Bus Spezifikation reingeguckt?
Abb. 41 und 42 geben Maximal- und Minimalwert in Abhängigkeit von Buskapazität bzw. Spannung an.
https://www.nxp.com/docs/en/user-guide/UM10204.pdf
10kΩ sind danach bis 100pF Buskapazität noch in Ordnung.
10kΩ sind danach bis 100pF Buskapazität noch in Ordnung.
Und Abbildung 42 sagt, dass bei 3 Volt der Mindest-Widerstand 0,5 kOhm sei und bei 5 Volt knapp 2 kOhm (Standard und Fast Mode). Die 3 mA in der Abbildung 42 sind übrigens der Mindest-Strom, höhere Ströme sind nicht verboten. Im Interesse steiler Flanken würde ich da mit den Widerständen eher nach unten gehen. Wie oben schon gesagt, da muss ein Oszi her.
Kurz: es ist die absolut schlechteste Idee, rinem Baustein die
Bezugsmasse zu nehmen. Der sucht sich dann irgendeine andere. Und nimmt
dabei evtl. bleibenden Schaden.
So ist es. Zumal auch nicht klar ist, was im inneren des ominösen China DC/DC passiert. Vermutlich ist der MCP schon von vorherigem rumgespiele hinüber.
Bei 0.5V / Div zumindest sehe ich überhaupt keinen Ripple auf 3.3V.
AC Messung wurde ja schon gesagt, Trigger korrekt einstellen und Zeitbasis muss auch passen. Es gibt übrigens auch einen Regler für das Offset. Wenn Du keinen Ripple misst, misst Du falsch. Jeder DC/DC hat prinzipbedingt Ripple. Die Frage ist nur, wie groß ist er. Ripple auch während der Messung durch den ADC gemessen? Ripple auch bei verschiedenen Eingangsspannungen gemessen?
Und vorher schon werden die Absolute Maximum Ratings einiger Bausteine
verletzt...
Kurz: es ist die absolut schlechteste Idee, rinem Baustein die
Bezugsmasse zu nehmen. Der sucht sich dann irgendeine andere. Und nimmt
dabei evtl. bleibenden Schaden.
Habe ich so auf mikrocontroller.net gefunden und übernommen. Nur ist zu beachten, dass das ja normalerweise nie der Fall ist. Man hängt das Gerät an und fertig. Nur falls sich der Kunde gar nicht achtet und falsch herum anhängt, wird die Masse eben nicht "freigegeben".. Funktioniert zumindest auch.
Vermutlich ist der MCP schon von vorherigem rumgespiele
hinüber.
Also ich muss ehrlich sagen, ich habe es noch seeehr selten geschafft, einen Hardwarebaustein zu zerstören. Da muss man doch meist mit dem Hammer draufhauen oder eine komplett falsche Spannung anlegen
Weiss auch nicht, welches "rumgespiele" du meinst. Ansteuerung per I2C?
Habe ihn übrigens auch schon ausgetauscht mal. Mit dem gleichen Resultat. Wird also wohl ein SW-Problem sein, was ich nicht sehe. Aber ich habe jetzt eine alternative Lösung erarbeitet.
Ist so, aber man muss halt manchmal auch etwas Effizienzdenken dazunehmen. Meistens funktioniert es ja. Habe vorher geschaut, für welche ADCs ich mehrere Arduino-kompatible Libraries finde, habe gedacht, etwas davon wird wohl funktionieren.
Mal eine ganz andere Frage: Warum überhaupt diesen ADC? Der hat lt. Datenblatt einen Auflösung von 10 Bit, die im ESP32 eingebauten dagegen 12 Bit ...?
Das Ziel beim I2C sind nicht möglichst steile Flanken, sondern ein sicher definierter Pegel in dem Moment, wo der jeweilige Empfänger das Signal von der Leitung liest. Genau diese Anforderung wird durch die Abb. 41 abgedeckt.
Die 3 mA in der Abbildung 42 sind übrigens der Mindest-Strom, höhere
Ströme sind nicht verboten.
Die 3mA sind der Strom, bei dem die Spannung am Ausgangstreiber spezifiziert ist, d.h. solange man die 3mA NICHT überschreitet, garantiert das Datenblatt den angegebenen Low-Level am Treiberausgang (VOL1). Der Low-Level wird also schlechter, wenn man zu Gunsten steilerer Flanken die 3mA ÜBERSCHREITET.
Mit höherem Strom speist du auch mehr Energie ein, so das zusammen mit steilen Flanken Signalreflektionen entsprechen kritischer werden.
Eine Diskussion über Serienwiderstände (7.3 Series protection resistors in den Specs) würde hier jetzt allerdings zu weit führen.
Inwieweit man durch hohen Ströme die Quellimpedanz für den High-Level zu Gunsten einer höheren Störunempfindlichkeit verringert, hängt von den jeweiligen Anforderungen ab.
Nachdem ich hier keinen Aufbau gesehen habe scheint der TO es
ja auch nicht für nötig zu erachten mal einen Blick auf sein
Werk richten zu lassen. Da ist alles perfekt ("am Öl kann's
nicht gelegen haben, war ja keins drin").
Hier im weiteren Fortgang scheint auch niemand Zweifel am
physikalischen Aufbau der Schaltung (nicht der prinzipiellen
Verschaltung) zu haben. Oder habe ich im Wust von Kommentaren
etwas übersehen?
Na denn, dann ist ja alles in Butter. Oder doch nicht?
Hier im weiteren Fortgang scheint auch niemand Zweifel am
physikalischen Aufbau der Schaltung (nicht der prinzipiellen
Verschaltung) zu haben. Oder habe ich im Wust von Kommentaren
etwas übersehen?
Wenn man eine Schaltung für mögliche Mängel kritisiert, ohne sie konkret gesehen zu haben, wird man als alter Meckersack beschimpft. Und zwar jedes Jahr mehr als zuvor. Im Zeitalter von "ist doch ganz einfach" und "du kannst alles" Videos, wird Fachwissen weniger wert geschätzt.
Dazu kommt, dass die alten Meckersäcke wirklich älter werden. (Wer hätte das gedacht?). Vor einiger Zeit war hier auch das Wort "Bedenkenträger" in Mode. Ja, alte Leute bedenken mehr. Das nennt man: weise werden.
Ich habe mir beide Libraries angeschaut. Beide sind Schrott. Die erstere initialisiert die Variablen nicht anständig, zweitere führt Schiebeoperationen auf Signed Integern durch was UB/IB sein kann. Und beide hoffen drauf, das niemand anderes zwischen requestFrom() und read() auf den I2C zugreift.
Verstehe sowieso nicht wozu man zum Lesen von 2 Byte via I2C ne extra Library benötigt.
Beim ESP32 kann man mit Shifts auch ziemlich auf die Nase fallen. Bei der Tensilica CPU führen "<<" und ">>" auf 32 Bit Variablen um mehr als 32 Bits zu anderen Ergebnissen als man es kennt. Ist nach C/C++ auch UB, also zulässig. Ist mir bisher so nur beim ESP32 aufgefallen.
Ich habe mir beide Libraries angeschaut. Beide sind Schrott. Die erstere
initialisiert die Variablen nicht anständig, zweitere führt
Schiebeoperationen auf Signed Integern durch was UB/IB sein kann. Und
beide hoffen drauf, das niemand anderes zwischen requestFrom() und
read() auf den I2C zugreift.
Was ist den UB/IB?
Ich habe allerdings nur einen Master, sollte daher auch nichts auf dem Bus sein in der Zwischenzeit.
Verstehe sowieso nicht wozu man zum Lesen von 2 Byte via I2C ne extra
Library benötigt.
Schon, aber ich habe mir angeschaut, was gemacht wird mit den 2 Bytes und es ausgewertet auf einem Blatt, bin darauf gekommen, dass es Sinn machen sollte.
Habe ich so auf mikrocontroller.net gefunden und übernommen.
Man sollte so etwas, was man gefunden hat erst dann übernehmen, wenn man es verstanden hat.
Der Witz an diesen Verpolschaltungen ist, dass sie genau für den Fall gemacht und gedacht sind, dass keine andere Leitung zwischen den beiden "Schaltungsteilen" verläuft. Sie funktionieren also dann super, wenn man sie quasi "zur Batterie gehörig" betrachtet, Sie machen quasi aus einer "normalen Batterie" eine "garantiert richtig gepolte Batterie". Und da dahinter kommt dann die eigene Schaltung.
Wenn du eine zusätzliche Verbindung da reinmachst, dann musst du dir die Konsequenzen näher anschauen.
Bei den zweien ist das nur ein springendes Bit, das könnte doch auf den
I2C-Bus hinweisen.
Serielle Busse nimmt man folgendermaßen in Betrieb:
man kontrolliert, ob die Pegel der Signale zum Datenblatt passen
man kontrolliert, ob die Flanken sauber aussehen und zum Datenblatt passen
wenn es 2 zusammengehörige Signale gibt (wie z.B. I2C->SCL/SDA oder SPI->SCLK/MOSI/MISO), dann kontrolliert man, ob das Timing der Signale zueinander und zum Datenblatt passt
man kontrolliert, ob die Bits in der laut Datenblatt nötigen Reihenfolge auf dem Bus auftauchen
man kontrolliert beim I2C, ob das Timing bei der Busübergabe (z.B. ACK) funktioniert
dann erst kommt die Inbetriebnahme in der Software auf Protokoll-Ebene
Und genau so sind auch die Datenblätter aufgebaut.
Wenn man blind irgendwo irgendwas herkopiert, die Punkte 1-5 weglässt und gleich bei 6 anfängt, dann ist das, wie wenn man ein Autorennen fährt und nicht vorher seine Hardware kontrolliert (Öl, Luftdruck) und in Betrieb nimmt. Und dann muss man sich nicht wundern, wenn es einen Kolbenfresser gibt oder die ganze Karre irgendwie in der Gegend herumschlingert.
Schon, aber ich habe mir angeschaut, was gemacht wird mit den 2 Bytes
und es ausgewertet auf einem Blatt, bin darauf gekommen, dass es Sinn
machen sollte.
Naja, also bis man die Libraries zusammengesucht hat und dann geprüft hat, ob sie tun was sie sollen("und es ausgewertet auf einem Blatt") hat man das hier doch schneller selbst implementiert? Am Ende ist es eine Funktion die ca 5. Zeilen Code hat. Die ist schneller implementiert als die Suche im Webbrowser gemacht ist.
Was würdest du denn konkret anders machen?
Hier nicht auf Arduino SDK setzen. Arduino ist gut, wenn man mal schnell was probieren will und sich möglichst auf den 8 Bittern bzw. Arduino Hardware bewegt von denen Arduino herkommt. Wenn ich einen ESP32 verwende, dann nutze ich das Espressif SDK, das kommt direkt vom Hersteller und ist näher an der Hardware.
Desweiteren würde ich keinen externen ADC einsetzen. Der ESP32 hat einen internen ADC der für diesen Anwendungsfall hier vollkommen ausreichend ist. Es gibt hier keinen Grund was externes dranzupappen.
Thema Verpolungsschutz hatte ich schon gesagt, da wäre ein P-Channel auf der positiven Spannungsseite besser gewesen. Es fehlt auch eine Sicherung. Ein modernerer Buck für die 3.3V der im MHz Bereich taktet. Den hätte ich dann auch direkt von der Batterie gespeist. Den komischen 12V Regler dann nur für die Led-Versorgung. Und den eigentlich auch weg: 24V Led + PWM fähigen Boost DC/DC. Am ESP32 fehlt der JTAG zum Debuggen. Benutzt du eigentlich WLAN? Wenn nein, dann hätte ich statt dem ESP nen nRF von Nordic benutzt.
Naja, also bis man die Libraries zusammengesucht hat und dann geprüft
hat, ob sie tun was sie sollen("und es ausgewertet auf einem Blatt") hat
man das hier doch schneller selbst implementiert?
Desweiteren würde ich keinen externen ADC einsetzen. Der ESP32 hat einen
internen ADC der für diesen Anwendungsfall hier vollkommen ausreichend
ist. Es gibt hier keinen Grund was externes dranzupappen.
Hatte ich zuerst vor, dann habe ich mich zum Thema eingelesen und bin darauf gestoßen, dass dieser höchst nichtlinear und unpräzise sein soll, ev. gab es noch andere limitierende Gründe (Pins, Hardwaremodule, die nicht funktionieren, wenn xy..). Um die Batteriespannung zu messen hätte es aber vermutlich ausgereicht, wie du geschrieben hast.
Und den eigentlich auch weg:
24V Led + PWM fähigen Boost DC/DC.
Kann ich mir das so vorstellen, dass dieser eine Datenleitung zur Steuerung hat und dann direkt ein PWM Signal ausgibt? Gibt's die auch für bis ca. 8A Strom?
Screenshot_2023-09-14_150222.png
(13 KB)
