20.06.2016

Power-System-Management mit Linduino

Die meisten Entwicklungen f├╝r das Power-System-Management folgen einem ÔÇ×Einsetzen und danach Vergessen ModellÔÇť. Die Installation und das debuggen von Bausteinen f├╝r das Power-System-Management (PSM) werden mit LTpowerPlay einfach und wenn dies noch mit einer umfassenden Programmierl├Âsung kombiniert wird, gibt es keinen Bedarf an spezieller Firmware. Viele gro├če Systeme ben├Âtigen jedoch einen Board-Management-Controller (BMC), was die Frage aufwirft: Was kann Firmware f├╝r PSM tun?



 

Autor: Michael Jones, Applications Engineering Manager, Linear Technology Corporation

 


Die Grundlage einer PSM-Firmware ist der PMBus; die Grundlage des PMBusses ist der SMBus; und die Grundlage des SMBusses ist I┬▓C. Der Aufbau eines BMC, der einen Mehrwert ├╝ber PSM-Firmware hinzuf├╝gt, erfordert eine gewisse Kenntnis ├╝ber jedes dieser Protokolle, oder eine bereits bestehende Bibliothek, die den Entwickler von dieser Detailarbeit befreit.

 

Die Linduino-Bibliotheken handhaben jeden Protokoll-Layer und bieten eine applikationsspezifische Schnittstelle (API), die das Schreiben von PSM-Firmware sehr einfach macht. Linduiono-PSM ist aber kein Ersatz f├╝r einen BMC, sondern ein Satz an Bibliotheken und Beispielen, die kompatibel mit einer typischen BMC-Firmware sind.

 

Linduino kann zu Lernzwecken auch mit den Demo-Schaltungen von Linear Technology verwendet werden. Viele BMC-Designs haben bereits eine SMBus-API und alles, was man noch ben├Âtigt ist es, kurz zu studieren, wie der PMBus arbeitet. Es ist ziemlich ├╝blich, dass Ingenieure Linduino-Codeabschnitte kopieren, in eine bestehende Applikation einf├╝gen und verwenden. Es ist aber auch m├Âglich, einen der Linduino-Layer zu implementieren und die komplette Bibliothek wieder zu verwenden, einschlie├člich: 

  • Erkennung von Baustein und Spannungspegel,
  • Befehls-API,
  • Fehlerspeicher-Decodierung,
  • In-System-Programmierung.

Dieser Artikel stellt die Linduino-Bibliotheken, das Programmieren des Power-System-Managements, Aufbau und Einsatz von Linduino-PSM mit Demoschaltungen und PSM-Debugging-Techniken vor. Detaillierte Informationen ├╝ber die Protokolle und allgemeine Fragen zur Programmierung findet man in der Applikationsschrift 135 von Linear Technology ÔÇ×Implementing robust PMBus Software for the LTC3880, and the industry standards for I┬▓C/SMBus/PMBusÔÇť.

Linduino-PSM-Hardware

Die Linduino-PSM-Hardware besteht aus einem Linduino (DC2026) und einer Abschirmung zur Verbindung (DC2294) der I┬▓C-Pins des Linduino mit einem PMBus/SMBus/I┬▓C-Bus eines Demo- oder Produkt-Boards zu verbinden.

 

Zum optimalen Lernen startet man mit einem DC2026 (Linduino), einem DC2294 (Abschirmung), einem DC1962 (Power-Stick) und einem Total-Phase-Beagle (I┬▓C-Sniffer). Dies erm├Âglicht die Programmierung, das Debuggen und Erlernen des Controllers (LTC388X) und des Managers (LTC297X).

Bild 1: Evaluierung der Hardware 

Bild 1 zeigt die miteinander verbundene empfohlene Evaluierungs-Hardware. Um diese Hardware zu nutzen, verbindet man den Linduino und Beagle ├╝ber zwei USB-Kabel mit einem Computer. Wenn man den Beagle nicht ├╝ber USB verbunden hat, entfernt man das Beagle-Flachbandkabel vom DC2294, um Interferenzen des PMBus-Verkehrs zu und vom DC1962 zu vermeiden.

 

Wenn man es mit einem System-Board verbindet, dann arbeitet ein DC2086 in den meisten F├Ąllen.

Bild 2: Systemhardware 

Der DC2086 (Bild 2) akzeptiert eine Verbindung vom DC2294 und unterst├╝tzt Flachbandkabel mit 12, 14 und 4 Leitungen. Der DC2086 unterst├╝tzt auch eine externe Stromversorgung f├╝r System-Boards, die mehr Leistung ben├Âtigen, als es der Linduino liefern kann.

Linduino-PSM-Sketches

Bevor wir beschreiben, wie die PMBus-Bibliothek arbeitet, kl├Ąrt die kurze Erl├Ąuterung eines DC1962-Sketches die allgemeine Verwendung des Nutzungsmodells von Linduino-PSM. Sie zeigt auch, wie einfach es selbst f├╝r Nicht-Programmierer ist, Code zu schreiben.

Bild 3: Dialog zum Finden von Pr├Ąferenzen 

Um weiter voran zu schreiten, sind zwei Downloads erforderlich: der Arduino-Tools und des Linduino-Sketchbooks. Die Arduino-Tools k├Ânnen von www.arduino.cc und das Linduino-Sketchbook von www.linear.com/linduino herunter geladen werden.

 

Die Arduino-Tools laufen auf mehreren Plattformen. Dieses Applikations-Beispiel wurde mit Arduino 1.6.4 erstellt, das auf Ubuntu 14 TLS lief.

Fangen wir nun an:

Schritt 1: Konfiguration

Wenn die Arduino-Software das erste Mal l├Ąuft, wird sie ein voreingestelltes Sketchbook benutzen und nicht das von www.linear.com herunter geladene Linduino-Sketchbook.

 

Um zum Linduino-Sketchbook zu wechseln, nutzt man die Auswahl File / Preferences in der Men├╝leiste Finding Preferences Dialog, wie in Bild 3 gezeigt.

Bild 4: Pr├Ąferenzen-Dialog 

Bild 4 zeigt, dass sich der Ort des Sketchbooks oben auf der Dialogbox befindet. Nun nutzt man die Browse-Schaltfl├Ąche, um zum LTSketchbook zu navigieren, die von www.linear.com/linduino herunter geladen wurde. Es ist ebenfalls hilfreich, die Zeilenanzahl des On-Displays zu pr├╝fen und die Lognachrichten w├Ąhrend der Kompilierung zu zeigen. Die letztere Einstellung scrollt Kompilerbotschaften auf der Befehlszeile, wo sie einfacher zu sehen sind.

 

Nach dem Einstellen des Pfades m├╝ssen alle Arduino-Fenster geschlossen werden und die Arduino-Software muss erneut gestartet werden. Wenn Arduino nochmals gestartet ist, scannt es erneut die Sketchbook-Directory und erstellt die Arduino-Men├╝s. Wenn die Arduino-Software nicht neu gestartet ist, spiegeln die Men├╝s das LTSketchbook nicht wider und zeigen stattdessen auf das vorherige Sketchbook.

Schritt 2: Laden des ersten Sketchs

Bild 5: hello.world laden

Laden des hello_world-Sketchs durch imitieren von Bild 5. Nachdem der Sketch geladen ist, erscheint ein Fenster mit dem Sketch, wie in Bild 6 dargestellt.

Bild: 6 Sketch-Fenster

Schritt 3: Kompilieren und ablaufen

Man kompiliert den Sketch durch dr├╝cken der ÔÇ×checkmarkÔÇť auf der Werkzeugleiste, wie in Bild 7 gezeigt.

 

Der Pfeil, der nach rechts zeigt, kompiliert den Sketch und l├Ądt ihn in die Linduino-Hardware. Die Lupe stellt den Ausgang des Sketchs dar. Man denke sich den Pfeil als senden des Codes an die Display-Konsole oder kompilieren und senden des Codes an die Linduino-Hardware, so dass die Display-Konsole etwas hat, zu dem sie sprechen kann.

Bild 7: Arduino-Toolbar 

Anmerkung: Der Typ des Arduino-Boards sollte auf Arduino-Uno eingestellt sein und auch der Port ausgew├Ąhlt. Siehe Tools-Menu.

 

Nachdem der Sketch geladen ist, dr├╝ckt man die Lupe auf der rechten Seite der Werkzeugleiste, um das Konsolenfenster zu ├Âffnen. Man setzt das Ende der Zeilen auf Carriage return und die Baudrate auf 115200, um mit Bild 8 ├╝berein zu stimmen.

Bild 8: Arduino-Befehlsfenster 

Um mit dem Sketch zu interagieren, bewegt man den Cursor in der Box an das obere Ende (links von der Sende-Schaltfl├Ąche), tippt eine Zahl aus dem Men├╝ und dr├╝ckt dann die Sendeschaltfl├Ąche oder <CR>. Der Sketch wird dann den Befehl ausf├╝hren und das Men├╝ erneut anzeigen.

Schritt 4: Untersuchen der Men├╝punkte

Das Bild 9 zeigt, was passiert, wenn man 1 dr├╝ckt, um das Basic-Commands-Fenster zu ├Ąndern, gefolgt von dr├╝cken von 1 f├╝r Read All Voltages. Die gemessenen VOUT-Werte aller Versorgungsspannungspegel des DC1962 werden gelesen und ausgedruckt.

Bild 9: Sketch-Men├╝s

 

Der Sketch l├Ąuft solange, bis die Konsole geschlossen wird indem das X in der oberen linken Ecke gedr├╝ckt wird. Wenn die Konsole erneut ge├Âffnet wird, wird auch der Sketch wieder gestartet.

 

Wenn man mit Beagle vertraut ist, kann man nun die anderen Men├╝-Optionen untersuchen, einige Traces ablaufen lassen und die Bustransaktionen pr├╝fen.

Schritt 5: Modifizieren von Code

Der Sketch hat zwei Zugangspunkte. Es gibt eine setup()-Funktion, die einmal aufgerufen wird und eine loop()-Funktion, die immer wieder in einer Schleife aufgerufen wird. Beide sind Teil der Arduino-Kodierumgebung. Wenn man ein erfahrener C-Programmierer ist, wird man sich wahrscheinlich wundern, wo main() ist? Die Arduino-Bibliotheken haben eine vordefinierte main(), die setup() und eine unendliche Schleife, genannt loop(), aufruft.

 

Die Men├╝s sind als Helferfunktionen innerhalb des Sketchs kodiert und loop() ruft das Hauptmen├╝ auf. Jedes Men├╝ wird mit einer Case-Anweisung unterst├╝tzt, wobei jeder Fall (case) eine Men├╝zahl handhabt.

 

Okay, genug der Programmiersprache. Das Modifizieren der Applikation ist einfach, indem man ├╝ber die gelieferte API ├änderungen an den Case-Statements in dem Sketch macht. Die Funktionen (API) in dem Sketch, der PMBus-Befehle erstellt, kommen aus einer separaten Bibliothek und haben einfache Namen, die so klingen wie das, was man m├Âchte, dass der Code ausf├╝hrt. Beispielsweise bedeutet:

voltage = pmbus->readVout(0x30,false); ├Â

nutze die PMBus-API, lese die Ausgangsspannungen an der Adresse 0x30, ohne polling, und gebe sie in eine Variable mit Namen voltage ein.

 

Nun sollte man einige Änderungen vornehmen. Z.B. addiert man einen Menüpunkt, um die Ausgangsleistung zu lesen und auszudrucken. Wenn man jetzt immer noch nicht fertig ist, liest man einfach weiter, um mehr über das Schreiben von Code zu erlernen. Wenn man fertig ist, hier ein Hinweis:

float readPout(unit8_t address, bool polling);

Dies versucht man auf dem LTC3880 bei Adresse 0x30 auf dem Power-Stick. Um zu belegen, dass es funktioniert, addiert man mehr Widerstand oder eine Stromlast an Kanal 0 auf dem Power-Stick und verifiziert, dass es mit dem ├╝bereinstimmt, was der Sketch ausdruckt.

Die Linduino-PSM-PMBus-Bibliothek

Die PMBus-Bibliothek befindet sich im LTSketch-Baum in der Directory LTSketchbook/libraries/LT_PMBus. Diese Bibliothek ist geschichtet: sie startet mit TWI (Two Wire Interface), dann folgen I┬▓C, SMBus und schlie├člich der PMBus. Es gibt eine ganze Reihe von Konvertierungs-APIs, um Werte von L11/L16 (PMBus-Formate) nach/von Flie├čpunkt zu konvertieren. Und schlie├člich gibt es noch Gruppenbefehl, Protokollunterst├╝tzung, Baustein- und Spannungspegelerkennung, Fehlerspeicher-Decodierung und sogar die In-System-Programmierung.

 

Jede Schicht ist eine einfache C++-Klasse, ├Ąhnlich so, wie Arduino eine Klasse f├╝r serielle und weitere I/O-Funktionen nutzt. Wenn die Endumgebung C ist ÔÇô keine Sorge. Das hei├čt nur, dass man entweder die C++-Klasse ohne einen gro├čen Overhead an Speicher benutzen kann oder die Klasseneinteilung entfernt und sehr einfach als pures C nutzen kann. Die C++-Einteilung vereinfacht nur den Applikationscode und erleichtert es f├╝r Nicht-Programmierer.

Bild 10: Klassendiagramm LT_PMBus 

F├╝r Programmierer, die nur wissen m├╝ssen, was sich ÔÇ×unter den HaubeÔÇť verbirgt, sind die SMBus-Klassen hierarchisch (Bild 10) eingeteilt, so dass der Anwendungs-Code unabh├Ąngig vom Ein- und Ausschalten von PEC ist und das portieren f├Ârdert. Die LT_2C.h, LT_SMBus.h und LT_PMBus.h formen Schichten von APIs. Um die Linduino-PSM-Bibliotheken zu portieren, kann man jede dieser APIs w├Ąhlen und sie, unter Einsatz eigener Bibliotheken auf die eigene Plattform implementieren. Der g├Ąngigste Port re-implementiert die LT_SMBus-Base-Klasse und dann arbeitet sowohl die PMBus-Klasse, als auch die mathematische Konvertierung und auch alle anderen Funktionen und Beispiele ebenfalls.

Nutzen der PMBus-Bibliothek

Die Bibliothek kann auch ohne das Verst├Ąndnis all dieser Klasseneinteilungen eingesetzt werden; nur einige wenige Importe und statische Variable und der Sketch ist bereit f├╝r Aktionen.

Bild 11: Include-Bibliothek 

Normalerweise wird die Bibliothek mit dem in Bild 11 dargestellten Men├╝ zum Sketch hinzugef├╝gt, aber die wichtigsten Einf├╝gungen sind in Bild 12 gezeigt.

Bild 12: Wichtige Grundeinf├╝gungen 

Ein Sketch hat mindestens zwei statische Variable, eine f├╝r den SMBus und einen f├╝r den PMBus, wie in Bild 13 gezeigt ist. Die SMBus-Variable ist entweder die Pec- oder die NoPec-Version. Eine n├╝tzliche Eigenschaft der sauber getrennten Schichten ist, dass man Applikations-Code als SMBus- oder PMBus-Code schreiben kann, abh├Ąngig von den Bed├╝rfnissen des jeweiligen Projekts. Das Schreiben einer Applikation mit der PMBus-API verdeckt die Details des Befehlscodes und Datenformatierung und das Schreiben einer Applikation mit der SMBus-API erlaubt den Zugriff auf alle m├Âglichen Befehlscodes und direkten Zugriff auf Rohwerte.

Bild 13: Statische Variable 

Sind die beiden Variablen einmal initialisiert, ist die vollst├Ąndige SMBus-API via smbus-> und die vollst├Ąndige PMBus-API via pmbus-> verf├╝gbar. Es ist m├Âglich, beide APIs in der gleichen Applikation zu benutzen.

Die LT_PMBusMath

Die Klasse LT_PMBusMath ist eine hoch optimierte Bibliothek zur Zahlenwandlung zu und von L11/L16 und Flie├čkomma. Flie├čkomma ist f├╝r PMBus-Code nicht erforderlich und einige Applikationen von Endanwendern sind nur mit ganzen Zahlen geschrieben, besonders, wenn Spannungs- und Stromwerte vorzeitig bekannt sind, oder wenn die Flie├čkommawandlung auf einem kleinen Mikrocontroller zu langsam ist. Wenn die Wandlungen von der Firmware nicht ben├Âtigt werden, k├Ânnen sie immer noch von einer Offline-Applikation verwendet werden, um ganze Zahlen f├╝r die Applikation zu generieren. Es ist jedoch wesentlich einfacher Code zu schreiben, wenn Funktionen Flie├čkomma verwenden.

Die LT_I2C-Bibliothek

Die LT_I2C_Bibliothek unterscheidet sich von der L2C-Klasse in der PMBus-Bibliothek. Die Version in LT_PMBus ist zus├Ątzlich zur Unterst├╝tzung von gro├čen Block-Operationen byteweise f├╝r PMBus optimiert. Die I2C-Klasse in der LT_PMBus-Bibliothek basiert auch auf der Wire-Bibliothek und ist besonders auf andere Arduino-Boards portierbar. Sie arbeitet z.B. auf einem Arduino Mega 2560.

 

Alle Nicht-PSM-Sketche nutzen die LT_I2C-Bibliothek. Es ist am besten, die LT_I2C-Bibliothek nicht f├╝r PSM/PMBus-Bausteine zu verwenden und es gibt auch keine Notwendigkeit daf├╝r.

Das Schreiben eines einfachen Sketches

Die beste Art zu lernen, ist es Code von Grund auf neu zu schreiben und das wird in diesem Abschnitt beschrieben. Das folgende Beispiel ist am hilfreichsten, wenn man diese Schritte einen nach dem anderen selbst einmal ausf├╝hrt und die Ergebnisse ├╝berpr├╝ft, wenn man voran schreitet.

 

Dieser Beispiel-Sketch nutzt einen DC1962 und die andere Hardware, die im 1. Abschnitt beschrieben wurde. Dieses Beispiel akzeptiert f├╝nf einfache Befehle: 

  1. Drucke Spannungen
  2. Marge
  3. Ein/Aus
  4. Bus-Probe
  5. Reset.

Schritt 1: Erstellen eines neuen Sketches

Einen neuen Sketch erstellt man, indem man das Men├╝ File/New, wie in Bild 14 gezeigt, ausw├Ąhlt. Man sieht dann einen leeren Sketch, wie im Bild 15 zu erkennen.

Bild 14: Neuer Sketch

Bild 15: Leerer Sketch

Bild 16: Save AsÔÇŽ

Dann verwendet man das Men├╝ File/Save AsÔÇŽ und w├Ąhlt den Pfad f├╝r den neuen Sketch. Man muss sicherstellen, dass der Ordnername und der Sketchname zusammen passen, wie in Bild 16. Der Pfad muss unter dem LTSketchbook und der gleiche Pfad sein, der im File/Preferences-Dialog ist, damit er im Sketchbook-Men├╝ erscheint.

Schritt 2: Includes hinzuf├╝gen

Dazu nutzt man das Men├╝Sketch/Include/Include Library, und w├Ąhlt die nacheinander die folgenden Bibliotheken: 

  • User-Interface
  • Linduino
  • LT_PMBUS

Bild 17 zeigt, wie man die LT_PMBUS-Bibliothek ausw├Ąhlt. Alle Bibliotheken befinden sich im selben Include-Library-Men├╝.

Bild 17: Einf├╝gen 

An die oberste Zeile der Datei f├╝gt man folgendes Include-Statement ein:

#include <Arduino.h> 

Nun addiert man statische Variable f├╝r die Adressen und SMBus/PMBus-Objekte. Man addiert Setup-Code, um die Variablen und seriellen Busobjekte zu initialisieren und sichert den Code mit File/Save. Zuletzt dr├╝ckt man die Pr├╝fschaltfl├Ąche auf der Werkzeugleiste, um den Code zu kompilieren.

 

Der Code sollte dann so aussehen, wie der in Bild 18. 

Bild 18: Initialisieren von Code

 

Schritt 3: Men├╝-Setup

Ein Men├╝ ben├Âtigt verschiedene Druckm├Âglichkeiten und muss auf die Auswahl des Anwenders antworten.

 

Man f├╝gt eine print_prompt()-Funktion hinzu, um ein Prompt zu drucken und es aus der Setup-Funktion aufzurufen, um den Men├╝-Prompt zu drucken, wenn der Sketch l├Ąuft. Der Code sollte dann so aussehen, wie in Bild 19, dargestellt.

Bild 19: Prompt 

Dann sichert und kompiliert man, um sicherzustellen, dass der Code fehlerfrei ist.

Schritt 4: Men├╝antworten hinzuf├╝gen

Wenn man eine Men├╝-Option in die Konsole eingetippt hat, muss der Code gelesen und darauf geantwortet werden.

 

Die Loop-Funktion behandelt die Eingabe des Anwenders. Zuerst muss sie pr├╝fen, ob der serielle Bus verf├╝gbar ist. Dann muss sie die Eingabe lesen und in ein Schalt-Statement weitergeben. Innerhalb des Schalters muss sie einige Funktionen ausf├╝hren und dann die Prompt-Funktion aufrufen. Der Code f├╝r jeden Befehl wird innerhalb eines jeden Falls des Schalt-Statements geschrieben und danach die Prompt-Funktion aufgerufen. Das Code-Framework sollte dann so aussehen, wie Bild 20.

 

Bild 20: Anwendereingabe 

Dann sichert und kompiliert man, um sicherzustellen, dass keine Fehler vorhanden sind.

Schritt 5: Spannungen lesen

Nun ist es an der Zeit, den aktuellen PMBus-Code zu schreiben, der etwas Sinnvolles macht.

Bild 21: Spannungen lesen 

Bild 21 zeigt den Code, der s├Ąmtliche Spannungen liest. Dieser Code ist innerhalb des Falls (Case) in den Zeilen 57 und 58 dargestellt. Das Drucken nutzt die Standard-Arduino-Funktion Serial.printÔÇŽ. Das () um die Strings herum schiebt sie in den Flash, so das sie kein wertvolles RAM belegen. F├╝r jeden Baustein weist ein for loop durch die Seiten durch Aufrufen der pmbus->setPage(ÔÇŽ) gefolgt vom Lesen der Spannung ├╝ber pmbus->readVout(ÔÇŽ). Dann druckt der Code die Spannungen unter Nutzen des DEC-Typs dezimal aus. Man kann s├Ąmtliche Erkl├Ąrungen der API-Funktionen, die man in der LT_PMBus-Bilbliothek benutzt, im PMBus-File oder in der Doxigen-Dokumentation finden.

Schritt 6: Margeneinstellung und Ein/Aus

Der Code zur Margeneinstellung (margening) ist einfacher als der Spannungs-Code, weil die Operationen global sind, was bedeutet, dass alle Bausteine auf einen Befehl antworten k├Ânnen und das Seitenregister nicht ben├Âtigt wird. Dar├╝ber hinaus gibt es auch nichts zu drucken.

 

Bild 22: Margeneinstellung und Ein/Aus 

Bild 22 zeigt den Code. Case 4 ist die Men├╝auswahl No Margin. Es mag seltsam erscheinen, sequenceONGlobal() zu benutzen, um das Margening zu beenden. Unter der Haube ist der daf├╝r benutzte PMBus-Befehl der Befehl OPERATION (0x01).

Bild 23: OPERATION-Befehl 

Bild 23 aus dem Datenblatt des LTC3880, zeigt, dass es keinen speziellen Befehl gibt, um die Margeneinstellung zu beenden. Das Margening wird mit dem Wert 0x80 ausgeschaltet, was einschalten bedeutet. Dies deshalb, weil pmbus->sequenceOnGlobal() verwendet wird, um die Margeneinstellung auszuschalten.

Schritt 7: Bus-Untersuchung und Reset

Das Untersuchen des Busses ist Teil der SMBus-API, weil schlie├člich nicht alle PMBus-Bausteine sind. Bild 24 zeigt, dass das Probing ein Aufruf f├╝r smbus->probe(0) ist. Diese Null ist der Befehl, mit dem untersucht wird, was der PAGE (0x00)-Befehl ist. Die Probe testet alle g├╝ltigen Adressen und kehrt zur Liste der Bausteine zur├╝ck, die gefunden wurde. Sie findet alle Bausteine, die einen Lese-Befehl 0x00 ACK k├Ânnen.

Bild 24: Probe und Reset 

Der Reset-Befehl ist weniger eindeutig. Die Bausteinfamilien LTC388X und LTC297X resetten nicht auf die gleiche Weise. Die LTC388X Bausteine unterst├╝tzen einen MFR_RESET (0xFD)-Befehl, die LTC297X-Bausteine aber nicht. Auf einem LTC2977 ist z.B. command 0xFD MFR_TEMPERATURE_MIN aber nicht MFR_RESET vorhanden. Die korrekte Art einen Manager zur├╝ck zu setzen, ist durch wiederherstellen des RAMs von NVM, weil nach der ├ťbertragung der Baustein zur├╝ckgesetzt wird.

 

Um jedoch alle Bausteine zur gleichen Zeit zur├╝ckzusetzen, wird das Group-Command-Protocol verwendet. Dies gruppiert alle Operationen in eine einzige Transaktion, in der alle Befehle von den PSM-Bausteinen beim STOP bet├Ątigt werden.

 

Bild 24 zeigt wie man eine Group-Protocol-Transaktion einstellt. Diese Transaktion ist begrenzt von den Aufrufen

 

pmbus->startGroupprotocol()

und

pmbus->executeGroupProtocol().

Schritt 8: Testen

Es ist nun an der Zeit, die Applikation zu kompilieren und laufen zu lassen, um sicherzustellen, dass auch alles richtig arbeitet.

 

Wenn die Anwendung l├Ąuft, aber sensible Daten nicht druckt, hat man wahrscheinlich einen Fehler gemacht. Man kann dann die nachfolgenden Debug-Techniken verwenden, um sie zu debuggen. Oder, wenn man ungeduldig ist, kann man nochmals ├╝berpr├╝fen: 

  • Adressen,
  • Seiten,
  • Break-Statements.

Debugging

Es gibt mehrere Wege eine Linduino-PSM-Applikation oder jede Firmware-Applikation f├╝r diese Aufgaben zu debuggen: 

  • Drucken,
  • Spy-Tools,
  • Debugger.

Dieser Artikel geht nicht auf die letzte Option ein. Sie ist f├╝r einfache Sketches ├╝blicherweise nicht n├Âtig. Wenn man jedoch mehr ├╝ber Debugger erfahren m├Âchte, gibt es die Foren auf der Arduino-Webseite, um zu sehen, welche Werkzeuge andere Leute einsetzen.

 

Man hat das Drucken in den genannten Beispielen gesehen. Man kann, durch das Hinzuf├╝gen weiterer Druck-Statements debuggen. Dazu gibt man jedoch immer Strings in das F()-Macro ein, damit kein RAM verbraucht wird. Wenn man Text und Zahlen druckt, sollte man sie in zwei Aufrufe separieren, so dass der Textanteil in das Flash kommt.

 

Die PSM-Bibliotheken nutzen diese Technik. Fehler, wie NACK und PEC werden im Befehlsfenster gedruckt. Deshalb ist das Fehlerdrucken ├╝blicherweise auf den Anwendungs-Code beschr├Ąnkt.

 

Es wurde bereits das Drucken mit DEC beschrieben. Man kann dazu aber auch HEX und andere Formate verwenden. Dazu konsultiert man die Arduino-Dokumentation f├╝r Formatierungshilfen.

 

Der ultimative Debugger f├╝r den PMBus ist ein Spy-Tool. Ein Spy-Tool ist gut geeignet, weil man damit den Datenverkehr auf dem Bus sehen und einen Trace zusammen mit dem Code an den LTC-FAE (field application engineer) senden kann, wenn man Hilfe ben├Âtigt.

 

Dieser Artikel konzentriert sich auf Daten, die von der Applikation ÔÇ×Total Phase Data CenterÔÇť generiert und an einen Total Phase Beagle gesendet werden. Es gibt Informationen auf der Total-Phase-Seite, die dabei helfen, die Data-Center-Applikation zu installieren (www.totalphase.com).

 

Der einfachste Weg zu beginnen ist es, den Bus mit dem Sketch zu ├╝berwachen, den man gerade kreiert hat. Dazu wird die Men├╝auswahl 3, read voltages, benutzt.

Bild 25: Beagle-Trace 

Bild 25 zeigt die Daten. Steigen wir hier ein und entschl├╝sseln einige Transaktionen und nutzen den Index um den ├ťberblick zu behalten, wo wir sind.

 

Bei Index #1 (I1) und #6 (I6) gibt es zwei Byte-Transaktionen. Im SMBus ist dies das Write Byte Protocol. Die Adresse ist 0x30 f├╝r den LTC3880, wie man aus dem Code erkennen kann. Das erste Byte ist der Befehl, entsprechend 0x00, was dem PAGE-Befehl entspricht (Bild 26).

Bild 26: PAGE-Befehl 

Das Datenblatt des LTC3880 zeigt in Tabelle 2 den PAGE-Befehl. Diese Tabelle ist ein schneller Weg die Beagle-Daten zu decodieren. Man beachte, dass die Type-Spalte R/W Byte angibt. Dies bedeutet, dass das Register ein Read/Write-Byte-Protokoll ist, so dass beide Richtungen unterst├╝tzt werden.

 

Blickt man auf I1 und I6 zur├╝ck ist das zweite Byte 0x00 bzw. 0x01. Der Code setzt das PAGE-Register auf 0 und 1. Bezug nehmend auf Bild 21, Zeile 63, ist es dort, wo die Seite eingestellt ist. Man sollte die Spannung sehen, die direkt danach bei I1 und I6 gelesen wird.

 

Man sieht:

Write 0x8B, Read 0x9A 0x0D

Write 0x20, Read 0x14

0x8B ist ein READ_VOUT-Befehl. Tabelle 1 im Datenblatt zeigt, das es ein R-Word-Protokoll im L16-Format ist.

 

0x20 ist ein VOUT_MODE-Befehl. Tabelle 2 im Datenblatt zeigt, das es ein R-Byte-Befehl ist.

 

Der Linduino-Aufruf, der dies veranlasst, ist in Bild 21 dargestellt.

Bild 27: VOUT-Code lesen 

Warum veranlasst ein einziger Funktionsaufruf zwei Transaktionen? Um dies zu erkennen, muss man auf dem Code hinter der API blicken, wie in Bild 27 gezeigt.

 

Vout_L16 = smbus_.readWord(address, READ_VOUT);

exp = (int8_t)

(smbus_.readByte(address, VOUT_MODE) & 0x1F);

Return math_.lin16_to_float(vout_L16, exp);

Dieser Code zeigt einen smbus_.readWord(address, READ_VOUT) gefolgt von einem smbus_.readByte(address, VOUT_MODE) und 5 Bit werden aus dem Modus extrahiert und in die Variable exp. ├╝bergeben. Die Math-Wandlung konvertiert dann unter Verwendung des Exponenten exp. von L16 auf Flie├čkomma.

 

Grunds├Ątzlich ist der Code zum Lesen der Spannung generischer Code, der den Exponenten liest, der benutzt wird, um L16 in Flie├čkomma umzusetzen. Die Bausteine LTC388x und LTC297x verwenden einen unterschiedlichen Exponenten. Deshalb gibt es die beiden Transaktionen.

 

Man beachte: Code kann mit Kenntnis des Exponenten geschrieben werden und dann ein wenig schneller ablaufen. Generischer Code hat jedoch weniger Fehler und ist einfacher f├╝r den Schreiber der Applikation. Dies ist ein Kompromiss, den man machen muss, wenn man seinen eigenen Code schreibt.

 

Bevor man zur Zusammenfassung kommt, betrachtet man eine deutlich interessantere Transaktion: den Reset.

Bild 28: Reset-Trace 

Betrachtet man Bild 28 bemerkt man, dass es drei Schreibtransaktionen gibt. In der S/P-Spalte gibt es zwei S und einen SP. Dies bedeutet, dass I1 ein Start, I2 ein wiederholter Start und I3 ein wiederholter Start, gefolgt von einem STOP ist. Zus├Ątzlich sind auch die Adressen unterschiedlich: 0x30, 0x32 und 0x33.

 

Dies ist ein Group-Command-Protocol. Alle Befehle werden am Ende von I3, dem STOP, ausgef├╝hrt. Dies stimmt mit dem in Bild 24, Zeilen 110 bis 114, dargestellten Code ├╝berein.

 

Wenn man f├╝r das eigene Decodieren des Beagle-Trace etwas Zeit aufwendet, gewinnt man ein tieferes Verst├Ąndnis der PMBus-Befehle von PSN-Bausteinen. Andererseits, wenn es das Ziel ist, den Code lauff├Ąhig zu machen, sind die PSM-Bibliotheken sehr gut geeignet, den Hauptanteil dieser Arbeit zu erledigen.

Fortschrittliches Debugging mit LTpowerPlay

In der Einleitung wurde gesagt, dass die meisten Systeme aufgebaut und dann gleich wieder vergessen werden, und einige Systeme ein BMC besitzen. Die Wahrheit ist, dass Systeme mit einem BMC eine Kombination der ÔÇ×Aufbau-und-VergissÔÇť-Firmware sind. Warum ein BMC mit der kompletten Setup-Verantwortung belasten? Es ist wesentlich einfacher, eine Basiseinstellung in PSM-Bausteine zu programmieren und dann die BMC-Firmware nur f├╝r Funktionen zu benutzen, die einen Mehrwert bieten. Dies resultiert auch in einem deutlich zuverl├Ąssigeren System, weil der Gro├čteil der Firmware ├änderungen in der Telemetrie und den Margen liest und kleine Spannungs├Ąnderungen macht, und deshalb keine Notwendigkeit besteht, dass es kritische Funktonen wie das Sequencing oder PWM-Frequenzen steuert, die immer statisch sind.

 

Weil LTpowerPlay ein universelles Werkzeug f├╝r die Entwicklung, das Debugging und das Einsetzen von PSM-Systemen ist, muss Debugging-Firmware mit einem anderen PMBus-Master auf den physikalischen Takt- und Datenleitungen konkurrieren.

 

Bevor man auf die praktischen Folgen von zwei Mastern eingeht, ist es am Besten, zu ├╝berdenken, was passiert, wenn ein PMBus zwei Master hat. Der PMBus basiert auf dem SMBus, der mehrere Master akzeptiert.

 

Die Takt- und Datenleitungen sind Open-Drain. D.h., dass jeder Baustein, ob Master oder Slave, eine Leitung nach low, aber nicht nach high ziehen kann. Es gibt eine Regel, die besagt, dass wenn ein Master die Datenleitung nicht nach unten zieht, und feststellt, dass die Datenleitung auf low ist, er annimmt, dass ein anderer Master die Datenleitung auf low zieht und seine Transaktion abbricht, was es dem anderen Master erlaubt, seine Transaktion fortzusetzen.

 

Diese Technik wird manchmal Bit-Dominanz-Arbitration genannt, was ein einfacher Ausdruck daf├╝r ist, dass der Master, der eine Null in den Daten aktiviert, immer gewinnt.

 

Da Linduino und LTpowerPlay (DC1613) Multi-Master-f├Ąhig sind, k├Ânnte man glauben, damit ist alles gut auf der Welt. Es gibt jedoch eine weitere wichtigere Abw├Ągung.

 

Der PMBus definiert einen PAGE-Befehl (0x00), der wie eine Adresswandlung in Daten ist. Seiten sind wie Kan├Ąle. Ein LTC2977 kann z.B. acht Stromversorgungen managen; er hat acht Kan├Ąle, die jeder vom Page-Register/Befehl adressiert werden.

 

Praktisch bedeutet dies, dass es zwei Transaktion ben├Âtigt, um Werte, wie die Spannung zu lesen: eine f├╝r PAGE und eine f├╝r READ_VOUT. Wenn zwei Master versuchen die Telemetriedaten zur selben Zeit vom selben Slave zu lesen, und ein Master einen Page-Befehl zwischen dem Page-Befehl und dem Telemetrie-Befehl eines anderen Masters ausgibt, wird er die falsche Page lesen.

 

Wenn LTpowerPlay eingeschaltet ist und l├Ąuft, liest es prim├Ąr die Telemetriedaten, was seinen Anzeigezustand aktuell h├Ąlt, so das man Plots von Ausg├Ąngen, Fehlern und anderen wichtigen Informationen erhalten kann. Sch├Ątzen Sie was die Firmware typischerweise macht? Sie liest Telemetriedaten!

 

Noch schlimmer, angenommen eine VID-Funktion (Voltage Indentification) wird w├Ąhrend des Hochfahrens (booten) ausgef├╝hrt. Was ist, wenn die Software einen Spannungswert in die falsche Seite geschrieben hat, weil LTpowerPlay das Page-Register modifiziert hat? Das System kann dann ausfallen oder noch schlimmer, sogar etwas besch├Ądigen oder zerst├Âren. (Gl├╝cklicherweise verhindern die VOUT_MAX-Register ├╝blicherweise Systemzerst├Ârungen).

 

Das grundlegende Problem des Page-Befehls liegt in der PMBus-Spezifikation. Es betrifft nicht nur die Power-Management-System-ICs von LTC und man muss damit umgehen.

 

Es gibt zwei grundlegende Arten zu erlauben, dass LTpowerPlay und Firmware ÔÇ×zusammenlebenÔÇť und das PAGE-Problem vermeiden. Die erste ist einfach, man l├Ąsst die beiden Master nicht zur selben Zeit sprechen. Die zweite ist der Einsatz des PAGE-PLUS-Protokolls und weiterer Tricks f├╝r den einen oder den anderen Master.

 

Man sollte PAGE-PLUS aus dem Weg gehen, denn es wird nicht h├Ąufig eingesetzt. PAGE-PLUS erlaubt eine nicht mehr teilbare (winzig kleine) Transaktion, die PAGE und COMMAND in einer Transaktion enth├Ąlt. Weil er nicht von allen Bausteine unterst├╝tzt wird, wird er typischerweise nur in speziellen F├Ąllen eingesetzt, so dass dieser Artikel nicht auf PAGE-PLUS und weitere esoterische Tricks eingeht. Hat man allerdings keine andere Wahl dieses Problem zu l├Âsen, so liest man entweder das LTC-PSM-Datenblatt oder bittet den lokalen Feldapplikationsingenieur um Hilfe.

Bild 29: LTpowerPlay Start/Stopp 

├ťblicher ist es, zu verhindern, dass LTpowerPlay und Firmware gleichzeitig zu Slaves sprechen. LTpowerPlay hat eine sehr einfache Methode sein Verhalten zu kontrollieren. Bild 29 zeigt den Telemetrie-Plot, der einen quadratischen roten Bedienknopf in seiner Toolbar hat.

Bild 30: LTpowerPlay angehalten 

Wird dieser Bedienknopf gedr├╝ckt, werden alle Telemetrie- und LTpowerPlay-Aktivit├Ąten auf dem Bus gestoppt. Er wechselt dann zum gr├╝nen Pfeil, wie in Bild 30 gezeigt.

 

Ungl├╝cklicherweise hat Firmware nicht immer einen Mechanismus implementiert, der den Bus anh├Ąlt. Deshalb empfiehlt LTC einfach entweder die Entwicklung neuer Firmware mit einem eingebauten Anhaltemechanismus, oder einen Hardware-Busschalter/MUX oder Jumper zu integrieren.

 

Gibt es eine Methode entweder den BusMaster, LTpowerPlay oder die Firmware zu deaktivieren, ist das debuggen - wenn n├Âtig - eine Angelegenheit zwischen zwei Werkzeugen zu wechseln.

 

In Summe gibt es zwei M├Âglichkeiten:

1. Nur einem Master zu erlauben zu einer bestimmten Zeit auf den Bus zu sprechen.

2. Sich durch die Details von PAGE-PLUS und anderer fortschrittlicher Techniken mit der Hilfe von Feldapplikationsingenieuren von LTC zu arbeiten.

F├╝r neue Entwicklungen ist Methode 1 immer die bessere Wahl.


 


--> -->