UART für die Fehlersuche in Embedded-Geräten: Bewährte Vorgehensweisen für energiesparende Geräte
Während USB für die meisten Peripheriegeräte verwendet wird, ist UART in der Welt der eingebetteten Systeme immer noch lebendig und wird zum Debuggen von GPS-Modulen bis hin zu Raspberry Pi und Arduino Boards verwendet.
Da wir jedoch die Grenzen von extrem energiesparenden Designs immer weiter ausreizen, fragen sich viele oft: Ist UART ein Batteriekiller? Die kurze Antwort: Nein, das muss nicht sein. Wie bei jedem guten Werkzeug kommt es darauf an, wie man es einsetzt. Schauen wir uns das mal genauer an.
Behalten Sie den TX/RX-Leckstrom im Auge
Eine einfache Möglichkeit, unnötigen Stromverbrauch zu vermeiden, ist die Behebung von Leckströmen in den TX- und RX-Kanälen. Obwohl hohe Leckströme nicht sehr häufig sind, ist es immer besser, mögliche Probleme frühzeitig zu erkennen und zu beheben, um einen unerwarteten Stromverbrauch zu vermeiden.
Schreiben und Ausführen von Code mit Fokus auf Energieeffizienz
Stellen Sie sich UART wie Ihr Schweizer Taschenmesser vor - superpraktisch während der Entwicklung, aber Sie würden es nicht ständig offen in der Tasche herumtragen. Ein kluger Schachzug ist es, ein #define in Ihrem Code zu verwenden, um UART zum Debuggen einzuschalten und auszuschalten, wenn Ihr Gerät in Produktion geht. Es ist ein einfacher Trick, aber er kann Sie vor echten Albträumen bewahren.
Stellen Sie sich Folgendes vor: Sie und Ihr Team sind darauf bedacht, den Stromverbrauch zu minimieren. Sie führen kontinuierliche Strommessungen durch und sehen große Fortschritte. Während der Entwicklung lassen Sie UART für das Debugging aktiviert und nehmen den vorübergehenden höheren Stromverbrauch in Kauf. Aber dann fügt jemand diesen Code versehentlich in den Hauptzweig ein - UART ist immer noch aktiviert - und er wird drahtlos auf Millionen von Geräten geflasht. Plötzlich leert Ihr einst effizientes Design die Batterien wie ein Spielautomat, und Sie haben einen Haufen unzufriedener Kunden.
Die Lösung? Richten Sie ein kontinuierliches Integrationssystem mit Benchmarks zum Stromverbrauch ein. Auf diese Weise können Sie Probleme wie diese erkennen, bevor sie zu kostspieligen Fehlern werden. Betrachten Sie es als ein automatisches Sicherheitsnetz, das die zusätzlichen Ampere in Schach hält, bevor Ihr Code die Produktion erreicht.
Stellen Sie sicher, dass Sie alles ausschalten
Die Aktivierung von UART kann mehrere Teile Ihrer Software aktivieren, einschließlich verschiedener MCU-Blöcke und Taktgeber. MCUs sind oft so konzipiert, dass alles standardmäßig eingeschaltet ist, um die Entwicklung zu erleichtern. Es ist jedoch wichtig, nicht benötigte Komponenten zu deaktivieren, bevor die MCU in den Ruhezustand geht. Wenn die UART-Takte aktiviert bleiben, können sie die MCU daran hindern, den tiefsten Ruhezustand zu erreichen, was zu einem höheren Stromverbrauch führt. Überprüfen Sie Ihr Taktsystem und stellen Sie sicher, dass alle mit UART verbundenen Komponenten ordnungsgemäß ausgeschaltet sind, wenn sie nicht benötigt werden.
Otii-Experiment in Aktion
Vergleichen wir zwei Firmware-Versionen, die auf demselben Gerät laufen, dem Seeed Studio XIAO nRF52840 von Seeed Technology. Wir haben ein Beispielskript vorbereitet, das das Modul initialisiert, den Flash-Speicher einrichtet, eine kurze LED-Blinksequenz ausführt und dann das Modul in den niedrigsten Energiemodus versetzt. Bei der einen Version ist UART aktiviert, während die andere ohne UART läuft. Mit Otii Ace Pro von Qoitech haben wir den Stromverbrauch gemessen, um den Stromverbrauch der beiden Versionen bei verschiedenen Spannungsstufen zu analysieren und zu vergleichen.
In Abbildung 1 sehen Sie, wie das Gerät aktiv UART-Nachrichten sendet, während Abbildung 2 die MCU im Ruhezustand zeigt. Die blaue Linie zeigt an, dass UART aktiviert ist, während die orange Linie anzeigt, dass es deaktiviert ist. Der Unterschied verdeutlicht die Auswirkungen, die UART auf den Stromverbrauch haben kann.
Abbildung 1: Aktives SeeedStudio XIAO nRF52840 mit UART-Kommunikation | Aktiviert (blauer Graph) | Deaktiviert (orangefarbener Graph). (Bildquelle: Qoitech)
Abbildung 2: XIAO nRF52840 im Modus für geringeren Stromverbrauch (ausgewählter Teil des Diagramms) mit UART-Kommunikation | Aktiviert (blauer Graph) | Deaktiviert (orangefarbener Graph). (Bildquelle: Qoitech)
Im aktiven Modus stieg der durchschnittliche Stromverbrauch von 460 μA auf 1,34 mA (siehe Abbildung 1). Im Ruhemodus sinkt der Stromverbrauch von 2,27 μA auf 2,19 μA (Abbildung 2). Dies mag zwar als unbedeutender Unterschied erscheinen, aber die langen Ruheperioden, die für IoT-Geräte typisch sind, machen diesen Anstieg für die Batterielebensdauer bedeutsam. Die Firmware ist eindeutig für den Fall optimiert, dass UART deaktiviert ist.
Schätzung der Batterielebensdauer mit Otii
Um die Auswirkungen auf die Akkulaufzeit zu veranschaulichen, haben wir den Battery Life Estimator in der Otii Desktop App verwendet. Wir gingen von einer aktiven Periode pro Stunde aus, in der das Gerät aufwacht, die Blinksequenz durchläuft und dann für fast 3600 Sekunden schläft.
In Abbildung 3 ist UART deaktiviert, in Abbildung 4 ist UART aktiviert, was den erheblichen Unterschied in der Batterielebensdauer zeigt, je nachdem, ob UART verwendet wird oder nicht.
Abbildung 3: Schätzung der Batterielebensdauer bei deaktivierter UART-Kommunikation. (Bildquelle: Qoitech)
Abbildung 4: Schätzung der Batterielebensdauer bei aktivierter UART-Kommunikation. (Bildquelle: Qoitech)
Der Unterschied ist ziemlich groß! Die geschätzte Batterielebensdauer sinkt von 5,9 Jahren auf nur 11,6 Tage, wenn UART aktiviert bleibt.
Das Wichtigste ist, dass alles, was mit UART zu tun hat, ausgeschaltet wird, bevor die MCU in den Ruhemodus geht. Wenn Sie dies in Ihren kontinuierlichen Integrationsprozess mit der Otii Product Suite integrieren, können Sie versehentliche Freigaben mit aktiviertem UART verhindern, die die Batterielebensdauer Ihres Geräts drastisch verkürzen könnten.
Have questions or comments? Continue the conversation on TechForum, Digi-Key's online community and technical resource.
Visit TechForum




