Hey, Ich werde nun mein erstes größeres (Schaltnetzteil) Projekt in Angriff nehmen, bei dem ein uC (TI F28335) zum Einsatz kommt. Die Aufgaben des uC sind entsprechend der Prioritäten gegliedert: 1. Implementierung einer Strom - und Spannungsregelung und PWM Generierung 2. Überstromabschaltung 3. Messen und Abschalten bei zu hoher Kühlkörpertemperatur Da ich aus dem Hardware Bereich komme und nur bedingt Erfahrungen mit dem Coden habe, stelle ich mir nun die Frage, wir man geeignete Testpunkte zum debuggen des Codes (im laufenden Betrieb) implementiert. Mir fallen spontan zwei Möglichkeiten ein. 1. Die gemessenen Parameter (Strom, Spannung etc) über einen DAC ausgeben und mit einem Oszilloskop messen. So kann man z.B. die Messspannung mit der Referenz aufm Oszilloskop vergleichen, oder den Ausgang des Reglers direkt ausgeben etc. 2. Einen GPIO des uC toggeln, wenn eine Bedingung innerhalb der ISR wahr wird (z.B. wenn die Temperatur am Kühlkörper einen bestimmten Wert überschreitet. Meine Frage an die Erfahrenen unter euch: Habt ihr noch weitere Hinweise und Tipps, wie man den Code debug freundlicher machen kann? Vielen Dank. Gruß,
Debug-Tip #1: Fang mit was "kleinerem" an und sammle Erfahrung.
Carl D. schrieb: > Debug-Tip #1: > Fang mit was "kleinerem" an und sammle Erfahrung. Gut, dann nehme ich einen 12V buck converter, der die Ausgangsspannung auf 5V regeln soll. Weitere Hilfe würde ich trotzdem sehr schätzen, da ich die Leiterplatte selbst herstelle und entsprechend DAC etc. ohne große Probleme auf der Leiterplatte verbauen kann. Wenn die Leiterplatte erstmal fertig ist, stelle ich es mir schwieriger vor.
Hallo, ich persönlich würde wohl selbst "bei einem so kleinen Projekt" eine serielle Schnittstelle für das Debuggen vorsehen. Es gibt nämlich nichts schöneres, als wenn der Code einem erzählt, was er macht (oder auch nicht macht). Wo ich nämlich am PC einfach ein print einfüge fehlt die Möglichkeit am µC ohne Schnittstelle komplett. Gruß Kai
Ich weiß nicht was "größer" heißt, ich denke mal mehr als 1kW? Aus eigener Erfahrung kann ich dir sagen, dass du mit Punkt 2 beginnen solltest. Also deine Hardware bzw. auch die Software so gestalten, dass diese den Wandler im Fehlerfall sofort abschalten. Wenn du beispielsweise eine Strommessung hast, und diese einen Komparator für die Überstromerkennung triggert, der wiederum die PWM abschaltet (= MOSFETS abschalten, nicht floaten) solltest du genau solche Funktionen zuerst implementieren und v.a. auch testen. Gleiches gilt für Überspannung (v.a. bei Boostreglern). Das ganze setzt natürlich voraus, dass du die Spannungen und Ströme richtig misst, aber da sollte dir dein Debugger helfen. Das spart dir Nerven, Bauteile, Zeit und Geld.
die Sicherheitsabschaltung würde ich mit einer eigenen Standardschaltung machen. uCs haben leider die Eigenschaft im Fehlerfall abstürzen zu können und das wars dann mit der Sicherheit. Zumindest die wegen der Sicherheit kritischen Dinge wie Überstrom und Übertemperatur sollten eigens gelöst sein, den Rest kann man dann über den uC machen.
Das Buch „Linux Device Drivers“ (ISBN 0-596-00590-3, online z.B. unter https://lwn.net/Kernel/LDD3/) enthält im Kapitel 4 eine ganz gute Einführung in die Problematik. Vieles ist natürlich Linux-spezifisch, aber die Prinzipien lassen sich durchaus übertragen.
Das Ding hat doch 3 Uarts. Was spricht dagegen, einen zu benutzen und darauf Debugausgaben zu machen? Ich hatte auch man einen ähnlichen 2810 programmiert. Den konnte man über die TI-Entwicklungsumgebung auch im Einzelschritt-Modus betreiben. Also den Jtag herausführen und Debugger einschalten.
@ Harry May (harry4516) >die Sicherheitsabschaltung würde ich mit einer eigenen Standardschaltung >machen. uCs haben leider die Eigenschaft im Fehlerfall abstürzen zu >können und das wars dann mit der Sicherheit. Nicht wirklich. Gerade diese Controller vonb TI (C2000 Familie, siehe PICCOLO) sind EXAKT für sowas gemacht, incl. Sicherheitsabschaltung durch HARDWARE im Controller. >Zumindest die wegen der Sicherheit kritischen Dinge wie Überstrom und >Übertemperatur sollten eigens gelöst sein, den Rest kann man dann über >den uC machen. Quark. Übertemperatur ist für den Controller eine schnachlangsame Funktion, die kann im Sekundenbereich reagieren. Die muss nicht im xx kHz Interrupt überwacht werden. Überstrom dagegen schon, der wird sinnvollerweise mit einem Hardwarecomparator IM Controller überwacht. Das alles kann der uC. @ Alexander >1. Die gemessenen Parameter (Strom, Spannung etc) über einen DAC >ausgeben und mit einem Oszilloskop messen. So kann man z.B. die >Messspannung mit der Referenz aufm Oszilloskop vergleichen, oder den >Ausgang des Reglers direkt ausgeben etc. Kann man machen, aber nur, wenn der Controller einen echten DAC integriert hat. Ansonsten wird es zu aufwändig und wenig brauchbar. Ich hab mir für diverse Zwecke einen Mini-Logger eingebaut, der auf ein Triggersignal hin diverse ADC-Werte in ein Array schreibt. Das kann man dann Offline auswerten. >2. Einen GPIO des uC toggeln, wenn eine Bedingung innerhalb der ISR >wahr wird Ja. Ich hab das vor allem zur Messung der kritischen, weil hochfrequenten (100kHz) ISRs genutzt, damit man weiß, wieviel CPU-Zeit die brauchen. > (z.B. wenn die Temperatur am Kühlkörper einen bestimmten Wert >überschreitet. Das nun gerade nicht, denn das ist ein schnarchlangsames Ereignis, das man mit jeder x-bliebigen, LAAAAAANGSAMEN Debugfunktion anzeigen kann (LED, UART etc.). >Habt ihr noch weitere Hinweise und Tipps, wie man den Code debug >freundlicher machen kann? Bei so einem Controller ist es meist nicht ratsam, den Code anzuhalten, dann dann kracht es. Aber diese Controller haben vorgesorgt, man kann diverse Funktionen (PWMs etc.) beim Debugger-HALT weiterlaufen lassen oder sofort auf den sicheren Zustand, meist LOW, schalten lassen. Außerdem kann man kritische ISRs weiterlaufen lassen. Siehe Doku. Das ist ein schöner Controller, viel Spaß und Erfolg damit!
> 1. Die gemessenen Parameter (Strom, Spannung etc) über einen DAC > ausgeben und mit einem Oszilloskop messen. So kann man z.B. die > Messspannung mit der Referenz aufm Oszilloskop vergleichen, oder den > Ausgang des Reglers direkt ausgeben etc. Der Debugger vom Code Composer kann einen Real-Time-Mode. (Eigentlich sogar zwei: Rude Real-Time und Polite Real-Time.) Es ist in einem laufenden Programm kein Problem, auch mehrere Variable im Debugger grafisch darzustellen. > 2. Einen GPIO des uC toggeln, wenn eine Bedingung innerhalb der ISR > wahr wird (z.B. wenn die Temperatur am Kühlkörper einen bestimmten Wert > überschreitet. Besser: Mit einem R2R-DAC an den GPIOs Aufrufe der ISRs visualisieren. Statt Debug-Ausgaben ueber UART, die einfach zu lange brauchen: Wichtige Ereignisse in ein Speicherarray loggen. Auch dabei auf kurze Laufzeit achten. Also keine printf-Konsorten, eher Binaer-/Integerwerte und die dann vom Debugger formatieren lassen.
Das Erste ist die benoetigte Hardware Funktionalitaet zu testen, also TimerTick, Kommunikationsschnittstellen, Debug Schnittstellen. Dann ADC, DAC, Tasten, Display, Dann die Safe-State Modi, zB Endstufe abschalten. Wichtig, beim Design : Was geschieht, zB beim Powerup im Reset, wenn der Programmer dran ist ? Dann sollte zB eine End-/Steuerstufe nicht schon Verbraucher einschalten. Was geschieht, wenn durch einen Programmfehler immer wieder ein Reset kommt ? Dann sollte zB kein Relais zu klappern beginnen. Was geschieht bei Unterspannung, wenn es fuer den Controller reicht, fuer den Rest aber nicht ? Wenn ein Ansteuerfehler die Spannung zusammenreisst. Kann ein Steuerfehler einen Schaden verursachen, welche Auswirkungen hat der, wie kann er vermieden werden ? Welches ist/sind der Safe State ? In den/die man bei einem Fehler gehen muss. Was geschieht dann ?
Vielen Dank euch allen. Ich werde mich mal vermehrt mit den Debugger-Möglichkeiten vom Code Composer Studio auseinandersetzen. Ferner werde ich mich mit dem UART Betrieb vertraut machen. Das ist sicherlich ein guter und wichtiger Schritt. Auf dem ersten Blick scheint das keine schwarze Magie zu schein. Ich danke euch für euren Input - ich werde bei Gelegenheit die Ergebnisse meiner Arbeit posten. Gruß, Alexander
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.