c't-Lab

Hallo c't-Lab-Freunde,

wie schon an anderer Stelle hier im Forum erwähnt, habe ich vor einiger Zeit neben der C-Firmware-Version für die EDL (EDL2) auch einige neue Features in die DCG-C-Firmware eingebaut. Dies ist quasi die Fortsetzung dieses alten Threads: http://thoralt.ehecht.com/phpbb/viewtop ... f=12&t=179.

Damals nur als ZIP-File hier im Forum (immerhin 22 mal runtergeladen), ist seit heute der aktuelle Code als DCG2 (man beachte die >2<) im CVS auf Sourceforge: http://dcg-firmware.cvs.sourceforge.net ... ware/dcg2/
Zur Unterscheidung: DCG ist der Original-Code von amd-65, an dem habe ich nicht gerührt.

Es gibt neben einigen Bugfixes in DCG2 (siehe changelog.txt) auch diese Änderungen als Backport von EDL2:
- 3 User Parameter sets, wahlweise manuell oder automatisch beim Einschalten selektierbar
- Beim Einstellen mit dem Encoder keine automatische Änderung der Auflösung mehr (Wer hat nicht aus Versehen bis Null gedreht und mußte dann die Auflösung wieder einstellen? )
- Beim Einschalten wird die Auflösung automatisch auf die zweite Stelle gesetzt, wenn möglich. Auch das erhöht m. E. etwas die Bedienungsfreundlichkeit.

Ich würde mich über Feedback freuen, ob Euch die Änderungen zusagen. Speziell bitte ich einen Freiwilligen mit DCG+DCP (also die 2A-Version mit Relais), ob die Relaisansteuerung noch korrekt funktioniert, speziell im Ripple-Mode. Ich hab kein DCP und werde mir auch keines zulegen.

Bis zum Feedback, daß die Relais ordentlich funktionieren, werde ich keine hex-Files zur Verfügung stellen. Wagemutige mit Lizenz zum Compilieren vor! Als Compiler verwende ich V1.6.2 (20080610).

Bitte unbedingt beachten:Je nach Hardware-Option DUAL-DAC (siehe http://www.heise.de/ct/projekte/machmit ... on%20Board) oder eben Original-DCG-Hardware in config.h für die Original-DCG-Hardware auskommentieren. Sonst funktioniert die Ansteuerung der DACs für die Sollwerte nicht.

Viele Grüße
Paul

Hallo Forum,

na, irgendwelches Feedback bis jetzt?
Besteht überhaupt Interesse, daß ich die Firmware öffentlich weiterpflege? Die Resonanz hier war ja bislang exakt Null.

Viele Grüße
Paul

P.S: Es gibt einen kleinen Bugfix in der Displayanzeige: Ripple ist nicht bei 100%, sondern bei 0% "Off". Das ist bei der EDL leider genau anders rum.

Ich verfolge deine Arbeit mit großem interesse .. da ich leider (noch) kein DCG habe kann ich nur kein Feedback leisten. Auch wenn sich kaum wer meldet, laß dich nicht abbringen weiter zu machen

psclab38 hat geschrieben:Hallo Forum,

na, irgendwelches Feedback bis jetzt?
Besteht überhaupt Interesse, daß ich die Firmware öffentlich weiterpflege? Die Resonanz hier war ja bislang exakt Null.

Ich wollte diesen Sommer mal die Umstellung auf C "überdenken".
Und müsste mich dann mal kümmern was die verschiedenen DCG-C's eigentlich sollen und können.
Schön währe es wenn CM die Hand darüber hält was voraussetzt das ihr alle fließend die Sprache Konferenzschaltung beherrscht.

Auch muss ich deshalb wohl doch DCG (16bit ohne S&H) EDL ein "modifiziertes" Hochspannungs/Strom-Netzteil (HCP45, HVG500 und HVO100???) bestellen und aufbauen, wenn die ISO Geschichte noch Konturen annehmen sollte. Da muss ja denn C drauf.

Ich bin noch nicht so weit das ich selber was umschreiben könnte egal ob C oder Pasc(k)al, also ist mir die CM FW Lösung momentan noch sicherer auch weil CM sicherlich noch länger zu kontaktieren ist sollte mal was umgeschrieben werden müssen.

Meine Erfahrung ist, das Studies manchmal einfach "weg sind" und das war es dann.
Bei Hochschullehrern etc. ist das meist anders die kümmern sich auch noch nach Jahren sollten mal "verspätete" Fragen aufkommen.

Ich denke das diese ungeklärten Fragen abschrecken und welcher Hardwarelastige kompiliert gerne selber wenn die Source auch noch Extern gelagert wird? Ich traue mich jedenfalls nicht so einfach da ran selbst wenn schon alles fertig ist.

Grüsse

ich würds ja testen, aber ohne hex-files kann ich das nicht. im zweifelsfall schick mir die dateien für die single-dac version (DCG+DCP übrigens) per mail, dann teste ich das gerne nächste woche ausführlich an meinen beiden DCGs.

Marcel hat geschrieben:ich würds ja testen, aber ohne hex-files kann ich das nicht. im zweifelsfall schick mir die dateien für die single-dac version (DCG+DCP übrigens) per mail, dann teste ich das gerne nächste woche ausführlich an meinen beiden DCGs.

Ja, das ist doch mal ein konstruktiver Vorschlag. Ich habe nicht gedacht, daß das Compilieren das Problem ist. Ich werde dann doch zwei Hexfiles bereitstellen, für die Standard- und die DualDAC-Hardware. Mach ich dann später und melde mich nochmal...
Bei der Konfiguration kann ich auch nur auf Parameterebene helfen, ich hab' kein DCP und damit keinen vorgefertigten Parametersatz. Es hat aber früher schon mal mit der 2A-Version mit DCP funktioniert, es geht nur darum erst nochmal zu checken, ob nix verschlimmbessert wurde. Ab einem gewissen Punkt ist man mit Ausprobieren schneller am Ziel.

Roddot hat geschrieben:Ich bin noch nicht so weit das ich selber was umschreiben könnte egal ob C oder Pasc(k)al, also ist mir die CM FW Lösung momentan noch sicherer auch weil CM sicherlich noch länger zu kontaktieren ist sollte mal was umgeschrieben werden müssen.

Über die Zu- oder Abneigung zu C oder Pascal ist schon viel geschrieben worden. Ich denke, die C-Firmwaren für das c't Lab sind in dem Gedanken entstanden, so viel wie möglich mit Open-Source zu machen, weil der Schaltungsentwurf ja auch öffentlich ist. Pascal ist für mich etwas gewöhnungsbedürftig für Embedded-Systeme, aber das ist meine persönliche Meinung (nix für ungut, CM ) . Wir hatten bislang auch nur ein Forumsmitglied außer CM, das einen kommerziellen Pascal-Compiler hatte.

Roddot hat geschrieben:Meine Erfahrung ist, das Studies manchmal einfach "weg sind" und das war es dann.
Bei Hochschullehrern etc. ist das meist anders die kümmern sich auch noch nach Jahren sollten mal "verspätete" Fragen aufkommen.

Es soll vorgekommen sein, daß sich im Forum aktive Mitglieder parallel zum Beruf WIEDER in ein Studium geworfen haben. Ich bin aber schon seit 15 Jahren kein Student mehr. Ich habe aber früher beruflich Hardware entwickelt und mit Firmware zu tun gehabt. Irgendwie hab ich das dann vermißt und hab' hier meinen Spaß dran.

Roddot hat geschrieben:Ich denke das diese ungeklärten Fragen abschrecken und welcher Hardwarelastige kompiliert gerne selber wenn die Source auch noch Extern gelagert wird? Ich traue mich jedenfalls nicht so einfach da ran selbst wenn schon alles fertig ist.

Die Dateien sind auf dem CVS, da kannst Du anonym rangehen und Dir auf Knopfdruck von allen Dateien den letzten Stand holen. Der Compiler ist frei verfügbar, und die Entwicklungsumgebung kann entweder ein einfacher oder aufwendigerer Editor sein, oder das kostenlose AVR-Studio von Atmel. Da mußt Du nur Geld ausgeben, wenn Du einen Emulator einsetzen willst.

psclab38 hat geschrieben:Mach ich dann später und melde mich nochmal...

Tut mir leid, hat leider etwas gedauert. Ich hab noch Debugausgaben eingebaut, um eventuelle Probleme leichter dokumentieren zu können.


So, jetzt hab ich die beiden Hexfiles hochgeladen. guckst Du hier: http://dcg-firmware.cvs.sourceforge.net ... -firmware/
Die Standardparameter, die die Firmwaren mitbringen, sind für DCG -only, also müssen diejenigen mit DCG+DCG ein bißchen feintunen. Ich denke, für die 16-bit Version sollte Parameter 167 auf "7" und Parameter 170 auf "12.5" eingestellt werden. (Param 169 gibt's hier nicht, der wird intern berechnet)


Eine Bitte an die Mutigen: Rettet vor dem Update Eure derzeitigen Einstellungen, z.B. mit Dump von eep und hex.
Speziell um den Umstieg leichter zu machen, wäre es außerdem sinnvoll, die Parameter aus der Pascal-FW auch noch mit ParamBackupRestore.vi zu retten und als ersten Versuch einfach in die C-FW zurückzuspielen. Evtl. stimmen die Kalbrierdaten nicht ganz, die anderen Parameter sollten aber kompatibel bleiben.

Um es anders zu formulieren: die C-FW hat nur mehr Parameter (bis auf die Ausnahme 169, s.o.), die alten Parameter von der Pascal-FW sollten aber passen. U.U. bis auf die exakte Kalibrierung.

Um Mißverständnissen vorzubeugen: die eep-Daten der Pascal-FW bitte NICHT einspielen. Die können nicht passen. Die C-FW belegt das EEPROM automtaisch mit Werten für DCG vor, es gibt keine eep-File.



Inzwischen habe ich nochmal nachvollzogen: CM hat in der Pascal-FW zwischen Version 2.842 und 2.91 die Umschaltung der Relais speziell für den Ripplemode geändert. Das Verhalten habe ich soweit mal übernommen, will es aber erläutern:

Mit der DCG+DCP gibt's bis ca. 12,5V die Versorgung über die erste Trafowicklung. Wenn die >>Sollspannung<< höher liegt, dann wird auf die höhere Trafowicklung hochgeschaltet. Soweit, so gut.

Wenn jetzt am Ausgang aufgrund von Strombegrenzung die >>GEMESSENE<< Spannung unter die Schaltschwelle fällt, dann schalten die Relais um, damit die Verlustleistung am Transistor verringert wird. Wenn der Überstromzustand wieder aufglöst wird, dann schaltet das Relais wieder hoch. (Das war vorher anders: Ging die >>GEMESSENE<< Spannung wieder über die Schwelle (+Hysterese), dann schalten die Relais wieder hoch.)

Im Falle des Ripplemodus ist das etwas komplizierter. Je nach Ripple-Einstellung ist die Ausgangsspannung und damit die gemessene Spannung nur ein Bruchteil der 100%-Sollspannung. Da aber je nach Meßzeitpunkt die gemessene Spannung mal die hohe und mal die niedrige Spannung sein kann, könnten die Relais jetzt wild hin- und herschalten. Um das zu vermeiden, hat die Pascal-FW von CM eine Änderung bekommen, die gemessene Spannungen runter bis zur niedrigen Ripplespannung erlaubt. Das führt in erster Linie zu höherer Verlustleistung am Transistor, je nach Tastverhältnis. Der Effekt ist bei Pascal und C-Firmware aber gleich. Ich kann nicht beurteilen, ob das eventuell Probleme machen könnte, da ich keine DCP habe. Bei extremem Tastverhältnis, und hohem Rippleanteil dürfte der Leistungstransistor ordentlich warm werden.

Die DCG2-Firmware ist bezüglich der Relaisumschaltung damit auf gleichem Stand wie die Pascal-Version, bis auf dies: Wenn ich die Pascal-Firmware richtig verstanden habe (ich hab's nicht ausprobiert), dann würden im Ripplefall die Relais nicht bei 12V runterschalten, wenn man die Sollspannung runterdreht, aber der Rippleanteil > 0 ist. Das habe ich hier noch geändert.

Spätestens jetzt dürfte ich alle Klarheiten beseitigt haben.

Um die korrekte Funktion zu testen, bitte ich Euch mal genau hinzusehen und das Ding in allen Lebenslagen zu prüfen. Für alle Fälle (um ein eventuelles Debuggen zu erleichtern) habe ich eine Debugausgabe zur Relaisumschaltung auf der Seriellen eingebaut. Da werden ein paar Settings- und Meßwerte ausgegeben, falls es Probleme geben sollte. Dieses "Feature" kommt natürlich wieder weg.

psclab38 hat geschrieben:Um die korrekte Funktion zu testen, bitte ich Euch mal genau hinzusehen und das Ding in allen Lebenslagen zu prüfen. Für alle Fälle (um ein eventuelles Debuggen zu erleichtern) habe ich eine Debugausgabe zur Relaisumschaltung auf der Seriellen eingebaut. Da werden ein paar Settings- und Meßwerte ausgegeben, falls es Probleme geben sollte. Dieses "Feature" kommt natürlich wieder weg.

Eventuell wäre es von Vorteil, wenn der Debug-Modus ein- und ausschaltbar wäre. Entweder per Befehl über die RS232 oder alternativ, wenn man während dem Einschalten z.B. einen bestimmten Taster gedrückt hält. Somit könnte man auch später, wenn es mal Probleme geben sollte, den Debug Modus schnell aktivieren.
Diese Vorgehensweise benutze ich schon länger bei selbstgeschriebenen Programmen für meine Mikrocontroller und es hat mir schon öfters gut geholfen, wenn mal Probleme aufgetreten sind.

Ciao,
Rainer

Rainer hat geschrieben:Eventuell wäre es von Vorteil, wenn der Debug-Modus ein- und ausschaltbar wäre. Entweder per Befehl über die RS232 oder alternativ, wenn man während dem Einschalten z.B. einen bestimmten Taster gedrückt hält. Somit könnte man auch später, wenn es mal Probleme geben sollte, den Debug Modus schnell aktivieren.
Diese Vorgehensweise benutze ich schon länger bei selbstgeschriebenen Programmen für meine Mikrocontroller und es hat mir schon öfters gut geholfen, wenn mal Probleme aufgetreten sind.

Hi Rainer,

im Prinzip gebe ich Dir vollkommen recht, möchte das aber aus ein paar Gründen so und jetzt nicht machen:
- Zeitmangel -> Konzentration auf Features für die Nutzer und Funktion. Meiner Meinung nach schreit z.B. auch die DIV nach einer C-FW.
- Die Debugausgaben hier sind auf den Relais-Umschaltpunkt zugeschneidert und sonst wenig aussagekräftig
- Ein durchgängiges Debug-Feature-Konzept ist mir zu aufwendig und so in der FW bislang nicht vorgesehen. Ich hab aber noch nicht ernsthaft darüber nachgedacht. Ich mache spezielle Debugausgaben (siehe hier) oder habe notfalls einen ICE-Debugger
- Die Verbreitung einer Beta-Version soll eingeschränkt sein, solange nicht viel Erfahrung damit gemacht wurde. Und das geht vielleicht ganz gut, wenn das Debug-Feature hier ein wenig stört.

Viele Grüße
Paul

Hallo DCG-Freunde,

ihr habt bestimmt die Vorgänge in den anderen Threads verfolgt. Aufgrund der neuesten "Entwicklungen" habe ich mich entschlossen, ein neues Hexfile zum Download anzubieten:
Siehe hier: "http://dcg-firmware.cvs.sourceforge.net ... -firmware/"

Wie schon mehrfach erwähnt, ich habe "nur" 16-bit Dual-DAC-DCG-Hardware, ohne DCP. Daher bitte ich Mutige um ein wenig Mitarbeit und entsprechendes Feedback.

Gegenüber der letzten bereitgestellten Version gibt es folgende Änderungen:
- Arbitrary-Sequenzen im ROM, derzeit 4 verschiedene.

* Parameter 182: Ein- und Ausschalten der Arbitrary-Funktion (Werte 0/1)
* Parameter 183: Auswahl der Sequenz aus dem ROM (Werte derzeit 0..3)
* Parameter 184: Anzahl der Zyklen, für die die mit Parameter 183 ausgewählte Sequenz wiederholt werden soll. Die Ausgangsspannung bleibt auf dem Spannungswert des >ersten< Samples der Sequenz stehen (das sollte sowieso den gleichen Wert haben wie das Stopsample (mit Dauer 0) ). Mit Parameter 184 auf Wert 255 wird die Sequenz kontinuierlich wiederholt.

* Die Kurvenform ist komplett skalierbar über den Standardparameter 20 "DCVoltMod", 0...100%, über den Bus.

- Bugfix für den Einschalt-Peak, der sich vermutlich immer beim Aktivieren der DCG-Ausgangsstufe ergibt. Die Softwareänderung schwächt den Peak ab, aber zusätzlich ist ein zusätzlicher Kondensator parallel zu R37 empfehlenswert. (siehe auch http://thoralt.ehecht.com/phpbb/viewtopic.php?f=3&t=374)

Falls sich jemand über den unaufgeräumten Code wundern sollte, ich wollte den Zwischenstand erst mal sichern. Da ist noch Arbeit nötig, das ist mir klar.

Dann bitte ich nochmals um Eure Mitarbeit und Euer Feedback.

Viele Grüße
Paul

Hallo Paul,

nicht wirklich getestet aber mal mit den Knöpfen am Panel gespielt. (DCG+DCP)
Was mit aufgefallen ist (alles ohne Last)

bei Istwert von 10,00V wechselt die Panelanzeige zwischen "10,00 V" und "10,000 "
bei Panelaneige "OnReset" sind in der 2.Zeile nur Hyroglyphen zu sehen und das Panel
funktioniert nicht mehr sobald der Drehgeber bewegt wurde

die Spannungsumschaltung vom DCG ist fix bei 12,60V, mit Pascal FW wird bei 12,60V zugeschaltet
und erst bei 12,00V wieder abgeschaltet

das zurückspielen der gesicherten Abgleichdaten mit ParamBackupRestore.vi hat bei mir nicht funktioniert
die Effekte waren bei 2 Versuchen unterschiedlich 1x war der Spannungs-Istwert am Panel fix auf 0V das
andere mal irgendetwas anderes.
Teste ich nochmal, habe gerade beim Flashen der Pascal FW bemerkt das sich das EEPROM bei angeschlossenem DCP nicht programmieren läßt.

Gerhard

gewo hat geschrieben:Hallo Paul,

nicht wirklich getestet aber mal mit den Knöpfen am Panel gespielt. (DCG+DCP)

Hi Gerhard, erstmal danke für's Mitspielen !
Die Sachen schau' ich mir dann morgen abend an. Man wird betriebsblind und kann nicht alles testen. Das Panel funktioniert hier aber prima. Komisch.

Bis morgen!
Viele Grüße
Paul

EDIT:
kurze Nachfrage:

gewo hat geschrieben:die Spannungsumschaltung vom DCG ist fix bei 12,60V, mit Pascal FW wird bei 12,60V zugeschaltet
und erst bei 12,00V wieder abgeschaltet

Die C-Firmware hat eine fest eingebaute Hysterese mit 0.5V und den Parameter 170, während die Pascal-FW zwei getrennte Parameter 169+170 hat. Könnte es so rum sein? Auf welchem Wert steht der 170er bei Dir? Was sagen die Debugausgaben auf dem Bus?

gewo hat geschrieben:bei Istwert von 10,00V wechselt die Panelanzeige zwischen "10,00 V" und "10,000 "

Bei der ganz normalen Ist-Spannungsanzeige? Kann ich gar nicht reproduzieren.

gewo hat geschrieben:bei Panelaneige "OnReset" sind in der 2.Zeile nur Hyroglyphen zu sehen und das Panel funktioniert nicht mehr sobald der Drehgeber bewegt wurde

Böses Foul! Hab ich aber schon gefunden.

Hallo Gerhard,

also ich muß mich wirklich bedanken! Auch wenn Du "einfach nur am Encoder gedreht" hast, bin dadurch zwei Fehlern auf die Spur gekommen, die bei mir nie in Erscheinung getreten sind.

gewo hat geschrieben:bei Panelaneige "OnReset" sind in der 2.Zeile nur Hyroglyphen zu sehen und das Panel funktioniert nicht mehr sobald der Drehgeber bewegt wurde

Das war zwar für Dich offensichtlich, aber ich hatte die letzte Zeit den Controller so eingestellt, daß das EEPROM beim Codenachladen nicht gelöscht wurde. Damit hab ich gar nicht feststellen können, daß ich OnReset gar nicht mit "0", also Default initialisiert hatte.
Bei der Gelegenheit konnte ich auch noch die Verarbeitung der User-Parametersets über die Bus-Kommandos deutlich verbessern.

gewo hat geschrieben:bei Istwert von 10,00V wechselt die Panelanzeige zwischen "10,00 V" und "10,000 "

Das konnte ich zuerst gar nicht nachstellen. Erst nachdem ich die Kalibrierdaten NICHT verwendet hatte, sah ich's dann auch. Da ist schon die Meßauflösung sehr grob und es ist Zufall durch die Kalibrierung, ob ein kritischer Meßwert überhaupt auftritt.
Ein echt verstecktes Problem hinter den Kulissen: Eine Routine versucht rauszukriegen, wieviele Vor- und Nachkommastellen der anzuzeigende Double-Wert hat. Und die Verarbeitung war halt nicht identisch zu der Rundungsfunktion von sprintf, das dann zur eigentlichen Ausgabe verwendet wird. Wenn dann zunächst aus 9.9999 eine Vorkommastelle und damit eine Anzeige von 9.999 ermittelt wurde, dann machte die Anzeigefunktion 10.000 daraus, mit insgesamt einer Stelle zuviel.

gewo hat geschrieben:die Spannungsumschaltung vom DCG ist fix bei 12,60V, mit Pascal FW wird bei 12,60V zugeschaltet
und erst bei 12,00V wieder abgeschaltet

EDIT: Dieses Thema ist mehr, was ich eigentlich von Euch testen lassen wollte. JETZT seh' ich's auch. Hast recht. Ich bin mir aber sicher, daß es schon mal funktioniert hat. Das kommt von mal eben schnell! Änderung kommt, jetzt schau' ich nochmal genau hin. EDIT2: So die Hexfiles sind auch mit dem Bugfix online. Asche auf mein Haupt!

Deine Probleme mit dem EEPROM sind mir auch noch ein Rätsel. Vielleicht scheitert das Zurückspielen der Parameter an ein paar Feinheiten. Mal sehen.

Die Änderungen von heute Abend sind schon eingecheckt!

Vielen Dank für Deine Unterstützung!
Viele Grüße
Paul

Hallo Paul,

habe mal weiter gespielt und deine aktuelle FW geflasht.
OnReset funktioniert jetzt und auch die Relais-Spannungsumschaltung funktioniert jetzt wie bei der
Pascal-FW. (nur ohne Parameter 169)
Das zurückspielen der Abgleichdaten mit ParamBackupRestore.vi hat auch funktioniert. Abgleich paßt
nicht ganz, ist aber nahe dran.

Gerhard

gewo hat geschrieben:OnReset funktioniert jetzt und auch die Relais-Spannungsumschaltung funktioniert jetzt wie bei der Pascal-FW. (nur ohne Parameter 169)

Da bin ich aber beruhigt.

gewo hat geschrieben:Das zurückspielen der Abgleichdaten mit ParamBackupRestore.vi hat auch funktioniert. Abgleich paßt nicht ganz, ist aber nahe dran.

Ist ja auch schon mal nicht schlecht. C und Pascal unterscheiden sich halt doch ein wenig.

Wenn noch was ist (und das wird so sein) dann hab ich immer ein offenes Ohr.

Viele Grüße
Paul