EDL-C-Firmware

[psclab38]

Hallo c't-lab-Fans,
speziell diejenigen mit einem EDL-Modul.

Ich möchte Euch mitteilen, was vielleicht schon aus ein paar Andeutungen bekannt geworden ist: Es gibt ab sofort eine C-Variante der EDL-Firmware!

Diese Firmware beeinhaltet alle Features der letzten Pascal-Variante (sofern ich nichts übersehen habe) sowie diese Features:

- Ein generell wirkender Strombegrenzungsparameter, der die angeschlossene Quelle vor zuviel Strom schützt, vor allem interessant für P- und R- Betriebsart (neuer Parameter 30 & 172)
- Drei Benutzer-Parametersets, die man individuell mit eigenen Parametern laden und abrufen kann. Sehr nett bei Panelbedienung (neuer Parameter 180)
- Auswahl, mit welchem der Parametersets das Modul bootet (Default oder eines der drei Benutzer-Parametersets, neuer Parameter 181)
- Der LM75 Temperatursensor arbeitet auch unter 0°C

Diese Firmware habe ich auf Basis des DCG-Codes von amd-65 aufgesetzt, weil die Grundkonfiguration der Module recht ähnlich ist. In den letzten Monaten hab ich da so manche Stunde reingesteckt und bin recht zufrieden mit dem Ergebnis. Das heißt jetzt nicht, daß alle Arbeit getan ist, vielmehr hoffe ich auf Euer Feedback zu den Features und natürlich auch zu Bugs, die mir nicht aufgefallen sind .

Das hex-File findet Ihr hier: http://dcg-firmware.cvs.sourceforge.net ... -firmware/
und die dazugehörigen Quellen hier: http://dcg-firmware.cvs.sourceforge.net ... ware/edl2/

Bitte beachten: in dem Repository gibt es je ein Unterverzeichnis EDL und EDL2. Die EDL (ohne 2) ist nur für die Hardwarevariante verwendbar, die amd-65 auf seinem Labortisch stehen hat. Die EDL-2-Variante ist für alle mit der standardmäßigen Hardware von c't/cm.

Bevor Ihr diese Firmware einspielt, rettet bitte Eure Kalibrierparameter mit dem ParamBackupRestore.vi (eep-Auslesen mit dem Programmer geht auch, aber diese Daten könnt Ihr nicht direkt mit der C-Firmware verwenden). Die mit ParamBackupRestore.vi ausgelesenen Daten sollten auch mit der C-Firmware passen, bei mir war das jedenfalls so.

Ich hoffe, Ihr findet die zusätzlichen Features nützlich und meldet Euch zahlreich.

Viele Grüße
Paul

[Marcel]

ich habe (noch) kein EDL, finds aber toll, dass du dir die mühe gemacht hast. sobald ich mir ein EDL leisten kann kommt 100% deine Software drauf

[amd-65]

Ich möchte Euch mitteilen, was vielleicht schon aus ein paar Andeutungen bekannt geworden ist: Es gibt ab sofort eine C-Variante der EDL-Firmware!

So wie es aussieht, wird es im ATMega32 ziemlich eng. Da ja bei der EDL ein µC im (gesockeltem) DIP Gehäuse verwendet wird, sollte man gleich auf einen ATMega644(P) umsteigen.

Gruß
amd-65

[psclab38]

ich habe (noch) kein EDL, finds aber toll, dass du dir die mühe gemacht hast. sobald ich mir ein EDL leisten kann kommt 100% deine Software drauf

Danke für die Vorschußlorbeeren

So wie es aussieht, wird es im ATMega32 ziemlich eng. Da ja bei der EDL ein µC im (gesockeltem) DIP Gehäuse verwendet wird, sollte man gleich auf einen ATMega644(P) umsteigen.

Naja, im Augenblick ist das (noch) nicht wirklich nötig, ein paar hundert Bytes sollten schon noch frei sein, mit dem richtigen Compiler. Dann kann man noch die Optimierungsoption auf maximal setzen, dann sind noch so gut 10 % frei. Das hab ich nur nicht gemacht, weil dann der Debugger besser läuft.

Und dann gibt's nochmal eine Möglichkeit, all-in-one zu linken, das spart nochmal ein bißchen (siehe batchfile bei den Sourcen).
So im Allgemeinen hab ich schon versucht, Platz zu sparen.

Viele Grüße
Paul

[ompf]

mit dem richtigen Compiler.

Richtig, Du solltest die Versionsnummer vom verwendeten WinAVR angeben oder das Paket gleich mit einchecken.

Falls diese schreckliche Fließpunktarithmetik wieder drin ist: da gab's vor ca einem Jahr eine Überarbeitung. IIRC ist die neue Bibliothek schneller, braucht aber mehr Speicher.


Gruß
Patrick

[psclab38]

Hi Patrick,

Richtig, Du solltest die Versionsnummer vom verwendeten WinAVR angeben oder das Paket gleich mit einchecken.

Die Compilerversion, die ich verwendet habe, steht im Changelog.txt.

Falls diese schreckliche Fließpunktarithmetik wieder drin ist: da gab's vor ca einem Jahr eine Überarbeitung. IIRC ist die neue Bibliothek schneller, braucht aber mehr Speicher.

Deshalb ist die nötige Compilerversion auch etwas älter. Ich hab nicht versucht, das Rad neu zu erfinden, sondern einen Kompromiss zwischen Aufwand und Ergebnis zu finden.

Viele Grüße
Paul

[Allack]

Hi!! Erstmal Danke für deine Bemühungen!!

Da ich sehr oft mit C programmiere, ist diese Sache für mich sehr viel besser als die Pascal- Version, denn bei der Pascalsyntax gibt es immer wieder Kleinigkeiten, die ich nicht ganz verstehe. Das C- Programm allerdings sollte mir besser in der Hand liegen.

Zunächst habe ich noch eine Frage: Ist es auch möglich, die ganzen Sourcefiles als Archiv bereitzustellen, gleich ob es nun RAR, ZIP oder sonst was ist? Dann hätte man es als Anwender sehr viel leichter, weil man nicht jede Datei einzeln laden muss.

Bis dann, Grüße,

Allack

[psclab38]

Hi Allack,

Erstmal Danke für deine Bemühungen!!

Gerne!

Ist es auch möglich, die ganzen Sourcefiles als Archiv bereitzustellen, gleich ob es nun RAR, ZIP oder sonst was ist? Dann hätte man es als Anwender sehr viel leichter, weil man nicht jede Datei einzeln laden muss.

Im Prinzip ja, kann ich gerne bei Gelegenheit machen wenn ich mal wieder ein neues hex-file hochlade.
Bislang war das Repository hauptsächlich für die Leute gedacht, die sich an der Entwicklung beteiligen und die haben ihren CVS-client mit einem Mausklick dazu gebracht, das ganze Verzeichnis auf einen Rutsch zu aktualisieren. Das geht übrigens auch als "anonymous user", halt nur read-only.

Seit der Veröffentlichung tauchen in der Repository-Statistik ja paar Read-Transactions auf. Gibt's denn inhaltlich/funktional irgendein Feedback? Ich glaub nicht, daß da keine Bugs mehr zu finden wären...

Viele Grüße
Paul

[Allack]

Ich habs versucht, per CVS zu erledigen, allerdings bringt mein Client immer nur "Unknown Host". Deshalb, als Alternative für solche Fälle, bin ich an einem zusätzlichen Archiv interessiert.

Zum Programm selbst kann ich noch nichts sagen, hab den Code nur mal kurz überflogen. Aber ich werd mich demnächst damit beschäftigen.

[thoralt]

Ich habs versucht, per CVS zu erledigen, allerdings bringt mein Client immer nur "Unknown Host". Deshalb, als Alternative für solche Fälle, bin ich an einem zusätzlichen Archiv interessiert.

Nun, bei mir funktioniert es auf die folgende Art schnell und unkompliziert: Lade Dir den CVS-Command-Line-Client herunter. Kopiere die entpackte cvs.exe in Dein C:\Windows. Öffne eine Kommandozeile (Windowstaste+R, "cmd", Enter) und begib Dich mittels "cd" zu einem Verzeichnis Deiner Wahl. Dann starte einen Checkout:

Code: Alles auswählen

cvs -z3 -d:pserver:anonymous@dcg-firmware.cvs.sourceforge.net:/cvsroot/dcg-firmware checkout -P edl2

Im aktuellen Verzeichnis wird ein Unterverzeichnis mit dem Namen "edl2" angelegt, welches nach Abschluss aller Vorgänge die Quelltexte enthält. Wenn Du dann später nur aktuelle Änderungen herunterladen willst, begib Dich auf der Kommandozeile in das Verzeichnis "edl2" und führe "cvs update" aus.

Ich glaube, schneller geht's nicht, denn eine grafische Oberfläche musst Du erstmal installieren. Für häufigere Nutzung kann natürlich eine GUI (z. B. TortoiseCVS) deutlich angenehmer sein.

Generell bin ich der Meinung, dass es sich nicht lohnt, jedesmal bei Änderungen an den Quelltexten auch ein Archiv zu erzeugen, welches die kompletten Quelltexte enthält. Nun wäre das bei den c't-Lab-Projekten noch vertretbar, da sie z. Z. nur von Einzelpersonen betreut werden. Aber sobald mehrere Leute häufig Änderungen einchecken, ist das mit dem Quelltextarchiv unpraktisch. Dafür gibt's eben CVS (oder, was mir eigentlich lieber wäre, SVN).

Ich hoffe, Du kannst damit was anfangen.

@psclab38: Vielen Dank für Deine Mühe mit den EDL2-Quelltexten. Ich würde mich am Test beteiligen, nur fehlt mir dazu noch die EDL Echte Fortschritte sind bei mir erst im nächsten Jahr möglich, zur Zeit kulminiert der Hausbau (und das noch bis November).

Viele Grüße
Thoralt

[Allack]

Nun, bei mir funktioniert es auf die folgende Art schnell und unkompliziert: Lade Dir den CVS-Command-Line-Client herunter. Kopiere die entpackte cvs.exe in Dein C:\Windows. Öffne eine Kommandozeile (Windowstaste+R, "cmd", Enter) und begib Dich mittels "cd" zu einem Verzeichnis Deiner Wahl. Dann starte einen Checkout:

Code: Alles auswählen

cvs -z3 -d:pserver:anonymous@dcg-firmware.cvs.sourceforge.net:/cvsroot/dcg-firmware checkout -P edl2

Im aktuellen Verzeichnis wird ein Unterverzeichnis mit dem Namen "edl2" angelegt, welches nach Abschluss aller Vorgänge die Quelltexte enthält. Wenn Du dann später nur aktuelle Änderungen herunterladen willst, begib Dich auf der Kommandozeile in das Verzeichnis "edl2" und führe "cvs update" aus.

(...)

Ich hoffe, Du kannst damit was anfangen.

Danke für den Hinweis mit dem CMD- Tool. Leider hat auch das bei mir nicht funktioniert. Mein PC verträgt sich wohl nicht mit dem Sourceforge- CVS. Ich habs auch mit CrossVC und Tortoise probiert, jedesmal ohne Erfolg. Es erscheint entweder eine "Connection- Timeout" oder "Connection refused" Meldung. Aber ich werd da mal den Systemadmin in meinem Betrieb kontaktieren. Generell funktioniert das CVS bei mir, verwende es auch für den Beruf immer wieder. Aber das ganze gehört ja eigentlich nicht in diesen Thread

Grüße,
Allack

[Allack]

Hallo!!

Hab mal etwas über die Software geschaut. Zwei Sachen sind mir bisher aufgefallen:

1.) Triggerausgang
Du schreibst im Log, der Triggerausgang sei nicht implementiert, in der Pascal- FW ebenfalls nicht. Allerdings ist er in der Pascal- FW implementiert. Dort gibt es in der Date EDL-HW.pas die beiden Umstellungen, einmal in Zeile 278 und noch in Zeile 311. Der Ausgang wird mit der Pascal- FW auf jeden Fall angesteuert, hab das dann auch mal getestet. Dort erscheint der entsprechende TTL- Pegel.


2.) Inkrementalgeber
Entweder hab ich irgendwas übersehen, oder der eine Wert ist falsch. In der Funktion jobEncoder() in encoder.c wird am Ende folgende Abfrage gemacht:

Code: Alles auswählen

switch (ucNewState & 0xF0 )
		{
			// ...
			case 0x04:  // invalid next step, encoder likely to be turned faster than software can follow.
						EncState = next;
						break;
                 }

Das müsste nach meiner Ansicht

Code: Alles auswählen

... case 0x40 ...

heißen.


Ansonsten melde ich mich wieder, falls ich etwas bemerke.

Gruß, Allack

[psclab38]

Hallo Allack!!

Ein Codereview, klasse! Endlich ein Bug! Herzlichen Dank!

1.) Triggerausgang
Du schreibst im Log, der Triggerausgang sei nicht implementiert, in der Pascal- FW ebenfalls nicht. Allerdings ist er in der Pascal- FW implementiert. Dort gibt es in der Date EDL-HW.pas die beiden Umstellungen, einmal in Zeile 278 und noch in Zeile 311. Der Ausgang wird mit der Pascal- FW auf jeden Fall angesteuert, hab das dann auch mal getestet. Dort erscheint der entsprechende TTL- Pegel.

Ja, jetzt, wo Du's sagst. Ist aber auch echt gut versteckt. Ich hab mich schon gewundert, daß im EDL.pas das TRGOUT gar nicht verwendet wurde. Ich hab's im C-Code schon eingebaut, ist genauso unspektakulär wie bei Pascal.

2.) Inkrementalgeber
Das müsste nach meiner Ansicht

Code: Alles auswählen

... case 0x40 ...

heißen.

DER Fehler hat sich aber echt lange gehalten, ohne aufzufallen. Beißt einen ja förmlich, oh weia! Hat aber keine spürbare (er-drehbare) Auswirkung.

Den korrigierten *.c-Code (timer.c und encoder.c) hab ich schon eingecheckt und er funktioniert hier. Vielleicht kannst Du's ja bei Gelegenheit überprüfen. Hexfile reiche ich dann nach.

Weiter so!

Viele Grüße
Paul

[Allack]

Hallo!

Ich hab nochmal ein bisschen weiter den Code angeschaut. Das erste ist kein Bug oder ähnliches, sondern einfach nur eine Anmerkung: In der lcd.c in Zeile 79 ist als Kommentar das Zeichen AmpHour angegeben, das Zeichen ist allerdings nur eine Kopie des Omega. Wenn man es wie bei WattHour machen möchte, könnte man folgendes verwenden:

Code: Alles auswählen

0x1C, 0x14, 0x1c, 0x14, 0x05, 0x07, 0x05, 0x00

----------

Datei i2c.c, Zeile 208. Da geht es um die Arbitration. Soweit ich weiß braucht man die aber nur beachten, wenn man mehrere Master am I²C hat, was hier nicht der Fall ist. Also kann man diesen case komplett weglassen.

----------

Datei edl-parser.c, Zeile 59. Folgender Inhalt:

Code: Alles auswählen

    ...
    {"trm", 240},   // Trigger-Maske, Bit 0=1 -> Freigabe Trigger Input PL6, Bit 1=1 -> Periodische Ausgabe On- und Off-Werte
    {"opt", 150},   // Parameter/Optionen
    {"trm", 250},   // Trigger In Mask
    {"wen", 250},   // Write Enable für EEPROM
    ...

Es taucht hier zwei Mal "trm" auf, beim zweiten Mal mit dem Subchannel 250, der aber schon für "wen" verbraucht ist. Hab für den Eintrag auch keine Anwendung gefunden, denke er kann entfernt werden. Allerdings fehlt ein Eintrag "tmp" auf SubCh 233.

----------

Morgen schau ich noch weiter, für heute reichts

[psclab38]

Hallo Allack,

prima, daß Du weitermachst!

Das erste ist kein Bug oder ähnliches, sondern einfach nur eine Anmerkung: In der lcd.c in Zeile 79 ist als Kommentar das Zeichen AmpHour angegeben, das Zeichen ist allerdings nur eine Kopie des Omega. Wenn man es wie bei WattHour machen möchte, könnte man folgendes verwenden:

Code: Alles auswählen

0x1C, 0x14, 0x1c, 0x14, 0x05, 0x07, 0x05, 0x00

Hmm, die drei letzten Zeilen sind auskommentiert und eigentlich für den Schrott. Ich wollte mal Zeichen sparen und die Ah und Wh in ein Zeichen auf dem Display quetschen. Sah aber nicht gut aus und dann hab ich's nicht verwendet. Die Zeilen werden später mal einer allgemeinen Aufräumaktion zum Opfer fallen.

Datei i2c.c, Zeile 208. Da geht es um die Arbitration. Soweit ich weiß braucht man die aber nur beachten, wenn man mehrere Master am I²C hat, was hier nicht der Fall ist. Also kann man diesen case komplett weglassen.

Der Code ist original von amd-65, ich muß zugeben, den hab ich gar nicht genau angeschaut; funktioniert einfach Der Code ist so in allen C-Firmwaren drin - copy/paste. Vielleicht findet amd-65 mal die Gelegenheit das "FIXME!!!" zu fixen.

Datei edl-parser.c, Zeile 59. Folgender Inhalt:

Code: Alles auswählen

    ...
    {"trm", 240},   // Trigger-Maske, Bit 0=1 -> Freigabe Trigger Input PL6, Bit 1=1 -> Periodische Ausgabe On- und Off-Werte
    {"opt", 150},   // Parameter/Optionen
    {"trm", 250},   // Trigger In Mask
    {"wen", 250},   // Write Enable für EEPROM
    ...

Es taucht hier zwei Mal "trm" auf, beim zweiten Mal mit dem Subchannel 250, der aber schon für "wen" verbraucht ist. Hab für den Eintrag auch keine Anwendung gefunden, denke er kann entfernt werden. Allerdings fehlt ein Eintrag "tmp" auf SubCh 233.

Da hast Du in der Tat einen Bug gefunden. Da wollte ich wohl einen Eintrag kopieren und hab das dann nicht fertig gemacht. Egal, dann halt jetzt. Die Zeile geändert und man kann die EDL2 jetzt auch nach der Temperatur mit TMP und nicht nur mit 233 fragen.
Ist geändert und checke ich nachher gleich ein.

Viele Grüße
Paul