EDL-C-Firmware

Alles rund um die Software der elektronischen digitalen Last
Allack
kann c't-Lab-Bausätze bestellen
kann c't-Lab-Bausätze bestellen
Beiträge: 12
Registriert: 30.06.2009, 13:28
Kontaktdaten:

Re: EDL-C-Firmware

Beitrag von Allack » 04.09.2009, 08:59

Hallo!

Hab mir gedacht, dass diese Symbole nur zu Versuchszwecken da waren, eben weil sie auskommentiert sind. Das mit der Arbitration kann man ja einfach so lassen, der Code stört ja nicht ;)

----------

Bin grad wieder beim Review und hab da etwas bemerkt. Es geht um die Datei edl-hw.c in Zeile 45. Dort setzt Du ADIF auf 1, was aber der Interruptflag ist (der auch hardwareseitig zurückgesetzt wird). Ich denke, hier wolltest Du ADIE, also den Interruptenable, auf 1 setzen.

----------

Datei edl-panel.c

Zeile 181: Der hintere Ausdruck müsste

Code: Alles auswählen

"Modify == ModifyVolt"
heißen.

Eher unwichtig:

Zeile 85: Der Kommentar müsste "3" heißen.
Zeile 258: Hier könnte man auch die nicht auskommentierte if- Funktion auskommentieren und somit einfach direkt

Code: Alles auswählen

return 0x00
machen. Spart vielleicht nochmal ein paar bytes oder wird je nach dem sowieso wegoptimiert.

Zeile 362 wird ModifyVoltagePos mit -1 initialisiert und dann wird in Zeile 659 abgefragt, ob es -1 ist, um es dann auf 5 zu ändern. Gleiches gilt für ModifyCurrentPos in Zeile 633 und 664 auf den Wert 3. Man könnte die Initialisierungswerte dann auch gleich auf "5" bzw "3" ändern und somit die beiden Änderungen, die ja in jedem Fall beim ersten Aufruf dieser Funktion stattfinden, überspringen.

Außerdem: Die Funktionsheader sollte man, zwecks Übersichtlichkeit und Informationstreue, entweder anpassen oder komplett entfernen. Viele passen nicht (mehr) auf die Funktion, die sie beschreiben. Da in den anderen Dateien auch keine sind, würde ich vorschlagen, sie komplett zu entfernen. So wie es aktuell ist, verwirrt es manchmal schon. Aber das kann ja dann in der "allgemeinen Aufräumaktion" passieren ;)

----------

Datei edl.c

In der Funktion RecallDefaultParamSet (Zeile 275) würde ich auch noch

Code: Alles auswählen

wModeRange = Params.ModeRange;
einfügen.
Ansonsten könnte man sich überlegen, die beiden Funktionen RecallUserParamSet und RecallDefaultParamSet zusammenzuführen, um Speicher zu sparen. Bei Gelegenheit kann ich da mal einen Versuch wagen, jetzt mach ich aber erst mal das Review ;)

Die Pins sind in der C- FW anders initialisiert als in der Pascal, aber ich vermute, das wird Absicht sein. Zum Vergleich:

Code: Alles auswählen

  
//CFW            PASCAL
DDRA  = 0x00; // =0x00
PORTA = 0x03; // =0x00

DDRB  = 0xBB; // =0xBB
PORTB = 0xD7; // =0xFD

DDRC  = 0xFC; // =0xFC
PORTC = 0x0F; // =0xC3

DDRD  = 0x0C; // =0x0C
PORTD = 0xEC; // =0xFF
Die Unterschiede im Einzelnen:
PB1, PC2,3: in C als Output (init high), in Pascal als Output (init low)
PB3,5, PC7: in C als Output (init low), in Pascal als Output (init high)

PA0,1: in C als Input mit internem Pullup, in Pascal als Input mit Tristate
PD0,1: in C als Input mit Tristate, in Pascal als Input mit internem Pullup

andere Unterschiede betreffen die nicht benutzten Pins PC6 und PD4

In Zeile 1241 wird der StartTimer überprüft. Die letzte Aktion findet statt, wenn er 40 ist. Hier könnte man dann die entweder Abfrage dahingehend verändern, dass der StartTimer nur bis 41 oder etwa 50 läuft, oder ihn beim erreichen von 40 auf 254 ändern ( nach dem jobFaultCheck() ), um somit die unnötigen weiteren Einsprünge in die if- Anweisungen zu unterbinden. Könnte dann so aussehen:

Code: Alles auswählen

if (StartTimer < 255)
            {
                if (StartTimer == 4)
                {	
                    // ...
                }
                else if (StartTimer == 40)
                {
                    jobFaultCheck();
                    StartTimer = 254;
                }
                StartTimer++;
            }
----------

Einige Sachen sind hier eher unwichtiger Natur. Diese hab ich nur notiert, weil sie mir aufgefallen sind, eben der Vollständigkeit halber ;)
Hab das Review hiermit beendet, was aber keinesfalls heißen soll, dass nun alle Fehler verbannt sind ;)

Gruß, Allack
ctLab mit 250W- EDL
aktuell Tests für Wechselspannungen an den Klemmen

psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 892
Registriert: 25.01.2008, 23:34

Re: EDL-C-Firmware

Beitrag von psclab38 » 04.09.2009, 21:00

Hi Allack,

Du hast Dir doch nicht etwa die ganze Nacht um die Ohren geschlagen? 8)
Allack hat geschrieben:Es geht um die Datei edl-hw.c in Zeile 45. Dort setzt Du ADIF auf 1, was aber der Interruptflag ist (der auch hardwareseitig zurückgesetzt wird). Ich denke, hier wolltest Du ADIE, also den Interruptenable, auf 1 setzen.
Ähm, ehrlich gesagt: hab ich einfach übernommen. Das ist in allen C-Firmwaren so drin und scheint zu funktionieren. Muß ich mir bei Gelegenheit mal genauer ansehen. Oder weiß ein Experte das schon so?
Allack hat geschrieben: Datei edl-panel.c
Zeile 181: Der hintere Ausdruck müsste

Code: Alles auswählen

"Modify == ModifyVolt"
heißen.
Da hast Du eine SEHR unschöne Stelle gefunden, weil ich da Obst und Gemüse in der gleichen Variable verwurstet hab, je nach Aufruf. Mußte schnell gehen, wenn ich mich recht erinnere. :P Wird bald etwas weniger unschön. :wink:
Allack hat geschrieben: Zeile 85: Der Kommentar müsste "3" heißen.
Stimmt auffallend.
Allack hat geschrieben: Zeile 258: Hier könnte man auch die nicht auskommentierte if- Funktion auskommentieren und somit einfach direkt

Code: Alles auswählen

return 0x00
machen. Spart vielleicht nochmal ein paar bytes oder wird je nach dem sowieso wegoptimiert.
Ja, mach ich auch. Ich hatte da noch eine Markierung, daß ich da nochmal ran wollte ("*****"). Der Compiler ersetzt übrigens den ganzen Aufruf durch >Nichts<. Da wird eh' schon optimal Code gespart. :D
Allack hat geschrieben: Zeile 362 wird ModifyVoltagePos mit -1 initialisiert und dann wird in Zeile 659 abgefragt, ob es -1 ist, um es dann auf 5 zu ändern. Gleiches gilt für ModifyCurrentPos in Zeile 633 und 664 auf den Wert 3. Man könnte die Initialisierungswerte dann auch gleich auf "5" bzw "3" ändern und somit die beiden Änderungen, die ja in jedem Fall beim ersten Aufruf dieser Funktion stattfinden, überspringen.
Ist noch aus der Historie, muß ich nochmal durchdenken, wofür das gut ist. Vielleicht kann man das auch größtenteils entsorgen.
Allack hat geschrieben: Außerdem: Die Funktionsheader sollte man, zwecks Übersichtlichkeit und Informationstreue, entweder anpassen oder komplett entfernen. Viele passen nicht (mehr) auf die Funktion, die sie beschreiben. Da in den anderen Dateien auch keine sind, würde ich vorschlagen, sie komplett zu entfernen. So wie es aktuell ist, verwirrt es manchmal schon. Aber das kann ja dann in der "allgemeinen Aufräumaktion" passieren ;)
Entsorgen ist gut, ganz meine Meinung. Das File ist eh' schon gigantisch lang.
Allack hat geschrieben: Datei edl.c

In der Funktion RecallDefaultParamSet (Zeile 275) würde ich auch noch

Code: Alles auswählen

wModeRange = Params.ModeRange;
einfügen.
Wollte ich ursprünglich eigentlich nicht machen, seh' ich aber inzwischen anders. Irgendein Veto?
Allack hat geschrieben: Ansonsten könnte man sich überlegen, die beiden Funktionen RecallUserParamSet und RecallDefaultParamSet zusammenzuführen, um Speicher zu sparen. Bei Gelegenheit kann ich da mal einen Versuch wagen, jetzt mach ich aber erst mal das Review ;)
Einen entsprechenden Kommentar hatte ich ja dort hinterlassen. Es sieht aber nur auf den ersten Blick simpel aus.
Allack hat geschrieben: Die Pins sind in der C- FW anders initialisiert als in der Pascal, aber ich vermute, das wird Absicht sein. Zum Vergleich:

Code: Alles auswählen

  
//CFW            PASCAL
DDRA  = 0x00; // =0x00
PORTA = 0x03; // =0x00

DDRB  = 0xBB; // =0xBB
PORTB = 0xD7; // =0xFD

DDRC  = 0xFC; // =0xFC
PORTC = 0x0F; // =0xC3

DDRD  = 0x0C; // =0x0C
PORTD = 0xEC; // =0xFF
Die Unterschiede im Einzelnen:
PB1, PC2,3: in C als Output (init high), in Pascal als Output (init low)
PB3,5, PC7: in C als Output (init low), in Pascal als Output (init high)

PA0,1: in C als Input mit internem Pullup, in Pascal als Input mit Tristate
PD0,1: in C als Input mit Tristate, in Pascal als Input mit internem Pullup

andere Unterschiede betreffen die nicht benutzten Pins PC6 und PD4
Da hast Du deinen Finger in eine Wunde gelegt. Da hab ich wohl nur symptomatisch operiert. Ich werde weitgehend die Werte aus der Pascal-FW übernehmen, obwohl sich funktional nix ändert.

PA0, PA1 laß ich auf Pullup, für den Fall, daß kein Panel dran ist. Dann kann da nichts floaten
PD0, PD1 laß ich auch im Prinzip aus demselben Grund, aber die Initalisierung des USART "überfährt" ja sowieso die Konfiguration dieser Pins

PB1 selektiert die Spannungs bzw. Strommessung für ADC16. Das wird sowieso später im Timerinterrupt synchronisiert => low
PB3,5 sind eigentlich default high für den DAC (speziell PB3) => high

PC2,3 selektieren den Strombereich, wird auch später synchronisiert => low
PC7 ist default high für Trigger-out, wie ich jetzt gesehen habe =>
die entsprechende Logik hab ich dann auch umgedreht, war nach Murphy genau falsch rum.

Bis auf den letzten Punkt gibt's keine sichtbare Änderung.
Allack hat geschrieben: In Zeile 1241 wird der StartTimer überprüft. Die letzte Aktion findet statt, wenn er 40 ist. Hier könnte man dann die entweder Abfrage dahingehend verändern, dass der StartTimer nur bis 41 oder etwa 50 läuft, oder ihn beim erreichen von 40 auf 254 ändern ( nach dem jobFaultCheck() ), um somit die unnötigen weiteren Einsprünge in die if- Anweisungen zu unterbinden. Könnte dann so aussehen:

Code: Alles auswählen

if (StartTimer < 255)
            {
                if (StartTimer == 4)
                {	
                    // ...
                }
                else if (StartTimer == 40)
                {
                    jobFaultCheck();
                    StartTimer = 254;
                }
                StartTimer++;
            }
Das würde ich gerne so lassen, wie's ist. Dann ist das in allen C-Firmwaren weitgehend gleich. Ob da ein paar mal mehr oder weniger das RAM-Byte hochgezählt wird, wärmt höchstens den Chip etwas auf :lol:
Allack hat geschrieben: Einige Sachen sind hier eher unwichtiger Natur. Diese hab ich nur notiert, weil sie mir aufgefallen sind, eben der Vollständigkeit halber ;)
Hab das Review hiermit beendet, was aber keinesfalls heißen soll, dass nun alle Fehler verbannt sind ;)
Herzlichen Dank an Dich, daß Du Dir die Mühe gemacht hast. Ein paar Bugs hast Du ja gefunden, Hut ab!

Und an alle anderen Mitleser: wenn Ihr Anregungen habt oder Fehler gefunden habt, dann bitte hier vermelden!

Viele Grüße
Paul

psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 892
Registriert: 25.01.2008, 23:34

Re: EDL-C-Firmware

Beitrag von psclab38 » 04.09.2009, 22:03

Nachtrag zu dem ADIF-Bit im edl-hw.c:

Im Manual zum ATmega32 steht Folgendes:

********************
ADCSRA • Bit 4 – ADIF: ADC Interrupt Flag

This bit is set when an ADC conversion completes and the Data Registers are updated.

The ADC Conversion Complete Interrupt is executed if the ADIE bit and the I-bit in SREG are set.
ADIF is cleared by hardware when executing the corresponding interrupt handling vector.

Alternatively, ADIF is cleared by writing a logical one to the flag.
********************

So wie ich das verstehe, benutzt unser Code die zweite Variante, indem eine 1 ins ADIF bit geschrieben wird. Dann wird's gelöscht. Irgendwie komisch, scheint aber zu stimmen.

Viele Grüße
Paul

Benutzeravatar
Marcel
kann c't-Lab-Module umbauen
kann c't-Lab-Module umbauen
Beiträge: 91
Registriert: 31.12.2008, 17:26
Wohnort: Siegen

Re: EDL-C-Firmware

Beitrag von Marcel » 04.09.2009, 23:56

Wow, hier scheinen ja einige Profis zu sein die richtig Ahnung von der Materie haben.
Noch eine Frage nebenher: Unter welcher Lizenz steht der ganze Code? Darf man Teile davon für private Zwecke (Bastelprojekte etc) verwenden?
Stolzer Besitzer eines c`t-Lab:

1x 19" Gehäuse von Segor [ 100% ]
1x IFP ohne LAN [ 100% ]
2x DCG/DCP 16bit [ 100% ]

psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 892
Registriert: 25.01.2008, 23:34

Re: EDL-C-Firmware

Beitrag von psclab38 » 05.09.2009, 08:10

Marcel hat geschrieben:Noch eine Frage nebenher: Unter welcher Lizenz steht der ganze Code? Darf man Teile davon für private Zwecke (Bastelprojekte etc) verwenden?
Klar. Die C-Firmwaren sind unter GPL, d. h. Du kannst sie für private Zwecke immer verwenden. Ganz vereinfacht gesprochen verlangt die GPL im >kommerziellen< Anwendungsfall, daß die Änderungen am Code auch wieder veröffentlicht werden müssen. Aber wenn Du Verbesserungen hast, dann würden wir das natürlich auch gerne erfahren... 8)

Bezüglich der Pascal-Firmware und der c't-Hardware und ihrer kommerziellen Nutzung gibt es neuerdings auf der offiziellen Homepage einen neuen Absatz ganz unten. Scheinbar gab es auch kommerzielle Anfragen.

psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 892
Registriert: 25.01.2008, 23:34

Re: EDL-C-Firmware

Beitrag von psclab38 » 05.09.2009, 20:06

Hi Allack,

Du hattest doch noch wegen den "-1" Folgendes geschrieben:
Zeile 362 wird ModifyVoltagePos mit -1 initialisiert und dann wird in Zeile 659 abgefragt, ob es -1 ist, um es dann auf 5 zu ändern. Gleiches gilt für ModifyCurrentPos in Zeile 633 und 664 auf den Wert 3. Man könnte die Initialisierungswerte dann auch gleich auf "5" bzw "3" ändern und somit die beiden Änderungen, die ja in jedem Fall beim ersten Aufruf dieser Funktion stattfinden, überspringen.
Ich hab' heute nochmal drüber meditiert. Also, dabei geht's um die Initialisierungswerte für die Increments nach dem Einschalten. Die derzeite Konstellation hat historische Gründe. Ich wollte aber immer schon dran drehen und hab heute eine ganz brauchbare Lösung gefunden.

Wenn z. B. mit der bisherigen Lösung nach dem Einschalten (mit den abgespeicherten Parametern) ein Sollstrom von 5A eingestellt ist und ich drehe am Encoder, dann ist das Increment standardmäßig immer 1mA. Irgendwie unpraktisch. Das habe ich jetzt so umgebaut, daß das Increment automatisch die zweite Stelle von links ist, aber maximal 0.1V, 0.1A, 0.1W oder 0.1Ohm. Also im Falle von 5A ist das Increment 0.1A. Wohlgemerkt, das ist nur das automatisch gewählte Increment nach dem Einschalten, nachher kann man das selbst einstellen. (Diese Information geht über den Reset hinweg verloren und ich will das auch nicht im EEPROM hinterlegen.)

Speichermäßig ist das sogar so gut, daß ich 100 Bytes gegenüber vorher spare. Testweise hab ich es auch mal ausprobiert, für jeden Bereich ein eigenes maximales Increment einzuführen. Das klappt auch prima, z.B. bei Ohm ein Increment von max. 10Ohm. Allerdings spart es keinen Speicher sondern frißt nochmal extra 100 Bytes.

Was meinst Du?

Viele Grüße
Paul

Allack
kann c't-Lab-Bausätze bestellen
kann c't-Lab-Bausätze bestellen
Beiträge: 12
Registriert: 30.06.2009, 13:28
Kontaktdaten:

Re: EDL-C-Firmware

Beitrag von Allack » 07.09.2009, 08:54

Hallo Paul!

Wenn ich es richtig verstehe, geht es "nur" um die Initwerte, die dann während der Laufzeit veränderbar sind. Somit wäre ein eigenes maximales Increment für jeden Bereich eigentlich überflüssig, zumal das 100Bytes verbraucht. Wenn man allerdings auf die Komfortabilität schaut, ist es bei den verschiedenen Bereichen immer unterschiedlich günstig, wie groß das Increment ist.

In der PascalFW ist es so: Wenn man dort den Widerstandswert verändert, so wird die zweite Stelle von links modifiziert, mit einem maximalen Increment von 0,1. Stellt man allerdings zB den Strom um, so sind es immer Schritte von 10mA (für den gesamten Strombereich von 0-10A), bei der Leistung immer 0,1W und bei Spannungen 0,1V.

Also beim Einstellen von Ohm oder Watt wäre ein höheres maximales Increment vorteilhaft seitens des Komforts, allerdings, da man den Increment- Wert nacheinstellen kann, finde ich, dass man das weglassen und einen gemeinsamen Maximalwert nehmen kann. Oder man kommentiert diesen Codebereich entsprechend, so dass man das entfernen könnte, wenn Speicherengpässe entstehen würden. Solange noch Speicher übrig ist, kann man sich ruhig den Bedienkomfort erhöhen.

Grüße, Allack
ctLab mit 250W- EDL
aktuell Tests für Wechselspannungen an den Klemmen

psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 892
Registriert: 25.01.2008, 23:34

Re: EDL-C-Firmware

Beitrag von psclab38 » 07.09.2009, 22:28

Hi Allack,
Allack hat geschrieben:Oder man kommentiert diesen Codebereich entsprechend, so dass man das entfernen könnte, wenn Speicherengpässe entstehen würden. Solange noch Speicher übrig ist, kann man sich ruhig den Bedienkomfort erhöhen.
... dann schau' Dir doch mal den Code an, den ich gestern eingecheckt habe. Du must nur alles aus den Kommentaren rausholen, was mit "iMaxInitPos" zusammenhängt (und dann natürlich den statischen Check mit "5" auskommentieren.) Dann könnte man das ja zur Standardversion machen, wenn's Dir gefällt. :D

Viele Grüße
Paul

Allack
kann c't-Lab-Bausätze bestellen
kann c't-Lab-Bausätze bestellen
Beiträge: 12
Registriert: 30.06.2009, 13:28
Kontaktdaten:

Re: EDL-C-Firmware

Beitrag von Allack » 08.09.2009, 08:12

Hallo Paul!

Hab mir das ganze mal angeschaut. Es wird für jeden Bereich iMaxInitPos=5 gesetzt, nur beim Widerstand wird es auf 7 gesetzt. Könnte man dann nicht einfach

Code: Alles auswählen

if (*pModifyValuePos == -1)
{
	*pModifyValuePos = StartPos + 2;
  	if (*pModifyValuePos > 5)
	{
              if((wModeRange == RLOVOLT) || (wModeRange == RHIVOLT))
              {
                     if(*pModifyValuePos > 7)
                     {
                            *pModifyValuePos = 7;   // maximal initial increment resistance 10 ohms
                     }
               }
               else
               {
		     *pModifyValuePos = 5;  // maximal initial increment 0.1V / 0.1A / 0.1W
               }
	}
}
machen und damit iMaxInitPos komplett weglassen? Es betrifft den Code in der edl-panel.c ab Zeile 1020.

Könnte sein, dass man so dann wieder etwas Speicher spart. Was meinst Du?

Gruß, Allack
ctLab mit 250W- EDL
aktuell Tests für Wechselspannungen an den Klemmen

psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 892
Registriert: 25.01.2008, 23:34

Re: EDL-C-Firmware

Beitrag von psclab38 » 08.09.2009, 19:31

Hi Allack,
Allack hat geschrieben: Könnte man dann nicht einfach

Code: Alles auswählen

...***...
machen und damit iMaxInitPos komplett weglassen? Es betrifft den Code in der edl-panel.c ab Zeile 1020.
Könnte sein, dass man so dann wieder etwas Speicher spart. Was meinst Du?
In der Tat spart Dein Ansatz Speicher, knapp 90 Byte. Ich hab allerdings keine Ahnung wo der Compiler bei meinem Entwurf den Speicher vertrödelt hat, insbesondere die Fallunterscheidung war extrem kompakt in Assembler codiert.

Ich hab zwar noch eine Weile drüber meditiert, insbesondere weil bei meinem Ansatz alle Werte für die Funktion schön übersichtlich in der Switchanweisung aufgelistet waren, aber das isses dann auch nicht wert.

Schlußendlich hab ich dann Deinen Entwurf eingebaut und eingecheckt. Danke für's Mitdenken!

Viele Grüße
Paul

Allack
kann c't-Lab-Bausätze bestellen
kann c't-Lab-Bausätze bestellen
Beiträge: 12
Registriert: 30.06.2009, 13:28
Kontaktdaten:

Re: EDL-C-Firmware

Beitrag von Allack » 09.09.2009, 07:38

Hi Paul!
In der Tat spart Dein Ansatz Speicher, knapp 90 Byte. Ich hab allerdings keine Ahnung wo der Compiler bei meinem Entwurf den Speicher vertrödelt hat, insbesondere die Fallunterscheidung war extrem kompakt in Assembler codiert.
Ich kann mir auch nicht vorstellen, warum Dein Entwurf 90 Bytes größer ist. Eigentlich ist es ja das gleiche, nur dass Du noch eine Variable mehr hast, die allerdings als uint8 nur ein einziges Byte verschlingt. Das sind die Mysterien der Programmierung ;) Von der Übersicht und Verständlichkeit her war Dein Entwurf sicherlich der bessere.
Danke füRs Mitdenken!
Gerne!

Gruß, Allack
ctLab mit 250W- EDL
aktuell Tests für Wechselspannungen an den Klemmen

psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 892
Registriert: 25.01.2008, 23:34

Re: EDL-C-Firmware

Beitrag von psclab38 » 22.09.2009, 19:09

Hallo EDL-Freunde,

ich hab mal das Hexfile zum Code-Stand vom 8. September hochgeladen. Inhaltlich keine Änderungen, nur für diejenigen, die nicht selbst den Compiler anwerfen wollen.

Viele Grüße
Paul

Benutzeravatar
thoralt
Site Admin
Site Admin
Beiträge: 259
Registriert: 10.04.2006, 08:48
Wohnort: Chemnitz
Kontaktdaten:

Re: EDL-C-Firmware

Beitrag von thoralt » 25.02.2010, 11:33

Hallo Paul,

ich bin nun *ENDLICH* auch dazu gekommen, eine EDL in Betrieb zu nehmen. Die C-Firmware ist bereits drauf :)

Wir haben hier ein "dienstliches" Problem, welches ich mit der EDL zu lösen gedachte: Es soll die Last einer elektronischen Schaltung an einer Batterie simuliert werden. Dafür ist die EDL eigentlich genau richtig. Aber im Detail habe ich folgendes Problem: Der Laststrom hat ein Profil von 40 mA/50 ms, 100 uA/500 ms, 20 mA/5 ms, 100 uA/445 ms. Ich kann durchaus auf den kleinen Peak (20 mA/5 ms) verzichten, denn es gibt ja noch keine Arbitrary-Funktion für die EDL *G*

Wie ich feststellen musste, ist der off-Strom im Ripple-Modus nicht wirklich genau festzulegen, sondern nur als Prozentwert vom on-Strom. Ich hätte gedacht, dass es ähnlich ist, wie wir das damals im DDS für den Logik-Modus gelöst haben (getrennt einstellbare obere und untere Werte). Aus Deinem Quelltext sehe ich, dass die Ripple-Umschaltung immer im gleichen Range (d. h. mit dem gleichen Transistor) stattfindet. Meine Anforderung ist also schwierig umzusetzen (=hoher on-Wert, sehr niedriger off-Wert), da während des Ripples nicht in den kleinsten Range gewechselt wird. Ich muss also damit leben, dass ich minimal 1% einstellen kann (das wären dann rein rechnerisch 400 uA statt der gewünschten 100 uA).

Andersherum betrachtet bin ich ja mit meinen 40 mA im 200-mA-Bereich. Umgerechnet auf die 16 Bit heißt das also theoretisch ca. 3 uA Auflösung, meine gewünschten 100 uA würden also einen DAC-Wert von knapp 33 bedeuten. Ist das elektrisch überhaupt umsetzbar? Falls ja, würde ich nämlich nur quick&dirty die Prozentumrechnung in edl.c skalieren (für dieses eine Experiment) und hätte ungefähr meine 100 uA. Spricht etwas dagegen?

Längerfristig wäre es natürlich optimal, wenn für den Ripple-Modus ein Range-Wechsel möglich wäre und der off-Strom unabhängig vom on-Strom einstellbar wäre. Soweit ich micht im Code umgesehen habe, sieht das allerdings nicht nach einer einfachen Änderung in der Firmware aus. Ich könnte übrigens darauf verzichten, dass diese Werte auch über das Panel eingestellt werden, ein Opto-Bus-Befehl reicht völlig. Wenn ich Zeit hätte, würde ich es selber versuchen, aber da steht ja noch der PWM-Modus des DDS in der Pipeline :)

Viele Grüße
Thoralt
There are 10 kinds of people in this world: Those who understand binary and those who don't.

psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 892
Registriert: 25.01.2008, 23:34

Re: EDL-C-Firmware

Beitrag von psclab38 » 25.02.2010, 18:41

thoralt hat geschrieben: *ENDLICH*
...ja, wirklich endlich 8)
thoralt hat geschrieben:Die C-Firmware ist bereits drauf :)
DAS will ich doch stark hoffen! :wink:
thoralt hat geschrieben:Wir haben hier ein "dienstliches" Problem, welches ich mit der EDL zu lösen gedachte: Es soll die Last einer elektronischen Schaltung an einer Batterie simuliert werden. Dafür ist die EDL eigentlich genau richtig. Aber im Detail habe ich folgendes Problem: Der Laststrom hat ein Profil von 40 mA/50 ms, 100 uA/500 ms, 20 mA/5 ms, 100 uA/445 ms. Ich kann durchaus auf den kleinen Peak (2m mA/5 ms) verzichten, denn es gibt ja noch keine Arbitrary-Funktion für die EDL *G*
Das mit Arbitrary auf EDL wird vermutlich auch nichts, zumindest mit dem derzeitigen ATmega32. Der ist derzeit 99.5% ausgelastet, was das ROM angeht. Dann müßten wir umsteigen auf einen größeren, wie von Hartmut schon erwähnt. Is' ja einfach: DIL-Sockel. EDIT1:Ich hab nochmal nachgeschaut und - wie auch weiter oben schon geschrieben - noch nicht die volle Compiler-Optimierungsstufe -Os eingsschaltet. Damit sind wir wieder knapp unter 90% ROM-Auslastung und das ist ungefähr soviel wie bei der DCG2-C vor dem Arbitrary-Umbau. Damit ist ja noch fast alles möglich...
Aber damit ich die Arbitrary-Funktion auch auf der EDL nachziehe, muß sie schon vorher auf der DCG noch einen signifikanten "Marktanteil" erreichen...
thoralt hat geschrieben:Wie ich feststellen musste, ist der off-Strom im Ripple-Modus nicht wirklich genau festzulegen, sondern nur als Prozentwert vom on-Strom.
Naja, nach CM ist das ein Integerwert...
thoralt hat geschrieben:Andersherum betrachtet bin ich ja mit meinen 40 mA im 200-mA-Bereich. Umgerechnet auf die 16 Bit heißt das also theoretisch ca. 3 uA Auflösung, meine gewünschten 100 uA würden also einen DAC-Wert von knapp 33 bedeuten. Ist das elektrisch überhaupt umsetzbar? Falls ja, würde ich nämlich nur quick&dirty die Prozentumrechnung in edl.c skalieren (für dieses eine Experiment) und hätte ungefähr meine 100 uA. Spricht etwas dagegen?
Machbar schon, aber ist es überhaupt nötig, den niedrigen Wert so genau zu treffen? Wenn die Batterie 20mA liefern kann, dann ist DER niedrige Strom doch quasi "nahe Null".
thoralt hat geschrieben:Längerfristig wäre es natürlich optimal, wenn für den Ripple-Modus ein Range-Wechsel möglich wäre und der off-Strom unabhängig vom on-Strom einstellbar wäre. Soweit ich micht im Code umgesehen habe, sieht das allerdings nicht nach einer einfachen Änderung in der Firmware aus. Ich könnte übrigens darauf verzichten, dass diese Werte auch über das Panel eingestellt werden, ein Opto-Bus-Befehl reicht völlig.
Das ist eigentlich kein Bug, sondern ein Feature: Der Range-Wechsel geht immer mit "auschalten"-"umschalten"-"einschalten" einher, darum wird eben NICHT der Range gewechselt. Beim Umschalten bekommst Du den schönsten Lastabwurf... Die Einstellmöglichkeit in ganzen Prozenten könnte man aber schon umstellen, etwa dahingehend, daß Double-Werte aktzeptiert und gespeichert werden, aber nur gerundete ganze Werte zurückgegeben werden. Oder mit einem neuen Parameter... Kostet aber alles Platz, siehe oben.
thoralt hat geschrieben:Wenn ich Zeit hätte, würde ich es selber versuchen, aber da steht ja noch der PWM-Modus des DDS in der Pipeline :)
Ja, bitte nicht vergessen... :wink:

Viele Grüße
Paul

EDIT2:Hier gibt's auch ein Update. Die meisten Änderungen hinter den Kulissen von der DCG2-C sind hier auch drin. Auch vernüftige EEPROM-Default-Werte, insbesondere, was die Shuntwiderstände und die Strombereiche anging. Warum hat sich da bislang eigentlich noch keiner beschwert?

psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 892
Registriert: 25.01.2008, 23:34

Re: EDL-C-Firmware

Beitrag von psclab38 » 28.02.2010, 16:50

Thoralt hat geschrieben:Ich kann durchaus auf den kleinen Peak (2m mA/5 ms) verzichten, denn es gibt ja noch keine Arbitrary-Funktion für die EDL *G*
@Thoralt: Ähm, wenn Du's ausprobieren willst, dann melde Dich doch mal bei mir...
Unter Verzicht auf ein paar Details: Program: 32746 bytes (99.9% Full) mit "-Os" (jetz' isser voll!)

Bevor Fragen kommen: Nein mir war NICHT langweilig... ich wollt's wissen.

Viele Grüße

Antworten