EDL-C-Firmware
Re: EDL-C-Firmware
Du hattest im anderen Thread ja schon mit dem ATMega644 "gewunken" soll ich besser gleich welche mitbestellten wenn ich auf 16Bit (oder bit? wie war das noch bit aber Byt gross?)
Auslöten des Quad ist natürlich nichts was ich mir wünschen würde der DIP des EDL ist da ja einfacher.
Edit:
Hups; da gibt es einen 644P der ist billiger kann auch noch mehr! häh?
Auslöten des Quad ist natürlich nichts was ich mir wünschen würde der DIP des EDL ist da ja einfacher.
Edit:
Hups; da gibt es einen 644P der ist billiger kann auch noch mehr! häh?
Let's fets with Static-DC.
Re: EDL-C-Firmware
Ich hab gestern ausprobiert, ob der EDL2-C-Code auch auf ´nem 644P läuft: sieht gut aus. amd-65 hat da dankenswerterweise schon Vorarbeit geleistet, da war's ne Sache von einer Viertelstunde incl. Chiptausch. Panel, Ausgang, Bus, soweit alles unauffällig. Ich hatte aber noch keine Zeit, genau zu testen.Roddot hat geschrieben:Du hattest im anderen Thread ja schon mit dem ATMega644 "gewunken" soll ich besser gleich welche mitbestellten wenn ich auf 16Bit (oder bit? wie war das noch bit aber Byt gross?)
Auslöten des Quad ist natürlich nichts was ich mir wünschen würde der DIP des EDL ist da ja einfacher.
Edit:
Hups; da gibt es einen 644P der ist billiger kann auch noch mehr! häh?
Der 644P ist billiger und moderner als der 644. Vom Code her unterscheiden sie sich die beiden (in den Funktionen, die wir brauchen) gar nicht. Man müßte u. U. getrennt compilieren, weil die mitgelinkten Bibliotheken sich evtl. unterscheiden. Das hab ich aber nicht ausprobiert.
EDIT: ich sehe grade, der 644 und auch 644P sind beide schon "not recommended for new design", Nachfolger ist der 644PA. Das macht aber nix, die beiden alten wirds schon noch eine ganze Weile geben.
PS: Bit/Byte siehe http://de.wikipedia.org/wiki/Byte
Re: EDL-C-Firmware
Ich hab versucht den code zu kompilieren, aber wenn ich die aps datei starte mit avr studio und auf build drücke kommt nur "no build tools defined". Wenn ich mit der Bat kompeliere wir Das HEX File 91,6Kb groß und passt nicht mehr in den Mega 32. Was mach ich falsch?
Gruß Julian
Gruß Julian
Re: EDL-C-Firmware
Hi Julian,nailuj hat geschrieben:Ich hab versucht den code zu kompilieren, aber wenn ich die aps datei starte mit avr studio und auf build drücke kommt nur "no build tools defined". Wenn ich mit der Bat kompeliere wir Das HEX File 91,6Kb groß und passt nicht mehr in den Mega 32. Was mach ich falsch?
Beim aps müßtest Du kontrollieren, ob die Pfade für den C-Compiler etc. auch mit denjenigen für Dein System übereinstimmen. Die Fehlermeldung interpretiere ich jedenfalls so.
Die Größe des Hexfiles ist eigentlich völlig egal, solange die höchste Adresse unterhalb von 32k liegt, z.B.
vorletzte Zeile im Hexfile
Code: Alles auswählen
:087EAC002B204842295D000073
Start-Adresse der Daten dieser Zeile: 0x7EAC
Summe = 0x7EB4 <= 7FFF
=> paßt.
Es ist extrem wichtig, den richtigen alten (WinAVR-20080610) Compiler zu verwenden, weil die Bibliotheken sonst zu groß sind. Sonst müßtest Du gleich auf den 64k-Chip umsteigen...
Schau bitte mal nach...
Viele Grüße
Paul
PS: Du kannst testhalber mal im config.h die Zeile
Code: Alles auswählen
#define ARBITRARYMODE
Re: EDL-C-Firmware
Danke hat funktioniert mit der alten Version.
Das mit dem Hex-File hab ich noch nich ganz verstanden.
Gruß Julian
Das mit dem Hex-File hab ich noch nich ganz verstanden.
Gruß Julian
Re: EDL-C-Firmware
Hi Julian,
Also: Bei einem Binärfile stehen die Daten genauso drin wie sie im Flash zu finden sein sollen. Damit ist ein Binärfile exakt so lang wie der Flashinhalt und Du kannst direkt an der Filelänge des Binärfiles ablesen, ob das File <= 32k ist.
Beim Hexfile (genauer hier: Intel-Hexfile) sind die Flashdaten mit Overhead codiert, und zwar pro Zeile mit Länge, Adresse, Daten und Prüfsumme. Der Vorteil ist, das File ist mit normalen ASCII-Zeichen übertrag- und druckbar, das verhindert blöde Fehler bei der Übertragung.
Wenn Du beim Hexfile jetzt rausfinden willst, was die höchste Adresse der Daten ist, mußt Du Dir (etwas vereinfacht) die vorletzte Zeile genauer anschauen (die letzte enthält nur den Ende-Record)
Länge der Daten in dieser Zeile (erstes Byte) = 0x08
Start-Adresse der Daten dieser Zeile (Byte 2+3): 0x7EAC
Summe = 0x7EB4 <= 7FFF (32kByte)
=> paßt in den Mega32.
Das Hexfile ist da ungefähr 90kB groß, die beschriebenen Daten sind aber nur knapp 32k.
Jetzt ungefähr klar?
Viele Grüße
Paul
PS: In Wirklichkeit ist die Sache noch etwas komplizierter..
1) Es muß die Zeile mit der höchsten Adresse im Hexfile nicht zwangsläufig in der vorletzten Zeile stehen, die kann irgendwo vor dem Enderecord stehen. Durch die Adresse in jeder Zeile ist es trotzdem eindeutig, wenn u.U. nicht zwangsläufig offensichtlich.
2) Die Adressierung ist "nur" 2Byte. Für alle Hexfiles, die mehr als 64k Daten enthalten, gibt's noch Offset-Records, die man für die nachfolgenden Datenrecords immer dazuzählen muß.
Wer's ganz genau mag: http://de.wikipedia.org/wiki/Intel_HEX
Das hatte ich auch schwer gehofft. Wenn Du Fehler bemerkst oder Verbesserungsvorschläge hast, dann melde Dich bitte. Ich werde versuchen, kurzfristig zu antworten...nailuj hat geschrieben:Danke hat funktioniert mit der alten Version.
Kein Problem.nailuj hat geschrieben:Das mit dem Hex-File hab ich noch nich ganz verstanden.
Also: Bei einem Binärfile stehen die Daten genauso drin wie sie im Flash zu finden sein sollen. Damit ist ein Binärfile exakt so lang wie der Flashinhalt und Du kannst direkt an der Filelänge des Binärfiles ablesen, ob das File <= 32k ist.
Beim Hexfile (genauer hier: Intel-Hexfile) sind die Flashdaten mit Overhead codiert, und zwar pro Zeile mit Länge, Adresse, Daten und Prüfsumme. Der Vorteil ist, das File ist mit normalen ASCII-Zeichen übertrag- und druckbar, das verhindert blöde Fehler bei der Übertragung.
Wenn Du beim Hexfile jetzt rausfinden willst, was die höchste Adresse der Daten ist, mußt Du Dir (etwas vereinfacht) die vorletzte Zeile genauer anschauen (die letzte enthält nur den Ende-Record)
Code: Alles auswählen
:087EAC002B204842295D000073
Start-Adresse der Daten dieser Zeile (Byte 2+3): 0x7EAC
Summe = 0x7EB4 <= 7FFF (32kByte)
=> paßt in den Mega32.
Das Hexfile ist da ungefähr 90kB groß, die beschriebenen Daten sind aber nur knapp 32k.
Jetzt ungefähr klar?
Viele Grüße
Paul
PS: In Wirklichkeit ist die Sache noch etwas komplizierter..
1) Es muß die Zeile mit der höchsten Adresse im Hexfile nicht zwangsläufig in der vorletzten Zeile stehen, die kann irgendwo vor dem Enderecord stehen. Durch die Adresse in jeder Zeile ist es trotzdem eindeutig, wenn u.U. nicht zwangsläufig offensichtlich.
2) Die Adressierung ist "nur" 2Byte. Für alle Hexfiles, die mehr als 64k Daten enthalten, gibt's noch Offset-Records, die man für die nachfolgenden Datenrecords immer dazuzählen muß.
Wer's ganz genau mag: http://de.wikipedia.org/wiki/Intel_HEX
Re: EDL-C-Firmware
Ich hab die 4 Fets jetzt auf einen externen Kühlkörper verbannt, aber er erkennt den Sensor nicht. Nur den Internen. Hab jetzt gelesen, dass man OPT17 auf 12 setzen muss, aber eich finde OPT17 im Quellcode nicht . Wo finde ich OPT17 und muss ich an den zweiten LM75 auch 2 Pullups dranmachen?
Gruß Julian
Gruß Julian
Re: EDL-C-Firmware
Hi Julian,nailuj hat geschrieben:Ich hab die 4 Fets jetzt auf einen externen Kühlkörper verbannt, aber er erkennt den Sensor nicht. Nur den Internen. Hab jetzt gelesen, dass man OPT17 auf 12 setzen muss, aber eich finde OPT17 im Quellcode nicht . Wo finde ich OPT17...
ich hab auch eine EDL mit externer Leistungsendstufe. Die OPT Parameter sind im EDL2-C-Quellcode nur am Kommentar erkennbar: OPT17 = 160+17 = 167, das ist wie bei der Original-FW. Ich habe versucht, da möglichst keine Unterschiede entstehen zu lassen. Siehe auch offizielles Syntax.pdf.
Ich habe für OPT 17 = 167 den Wert 12 dezimal, also 0000 1100 binär, also interner und externer LM75 aktiv. Die Logik für die Strombereiche schaltet dann beim höchsten Strombereich automagisch auf den externen LM75. Schalttemperatur und Hysterese gilt für beide LM75 jeweils die gleiche. Ist auch identisch zur Pascal-Version.
Nö, wieso? Die SDA und SCL- Leitungen führen doch zu beiden LM75 und R9+R13 sind die Pullups für den "I2C-Bus"....und muss ich an den zweiten LM75 auch 2 Pullups dranmachen?
Wenn ich mich richtig erinnere, dann hing an der S*g*r-Platine zur DCG ein kleines LM75-Board dran. So eines habe ich verwendet und das hatte - wenn ich mich mich richtig entsinne - keine Pullups.
Grüße
Paul
Re: EDL-C-Firmware
Sry ich find das nicht.
Bei mit steht :
/*OPT*/ {.SubCh = 167, .rw = 1, .fct = 0, .type = PARAM_BYTE, .scale = SCALE_NONE, .u.s = {.ram.b = (uint8_t*)&Params.Options, .eep.b = (uint8_t*)&eepParams.Options}},
Aber wo ist da eine Binärzahl?
Gruß Julian
Bei mit steht :
/*OPT*/ {.SubCh = 167, .rw = 1, .fct = 0, .type = PARAM_BYTE, .scale = SCALE_NONE, .u.s = {.ram.b = (uint8_t*)&Params.Options, .eep.b = (uint8_t*)&eepParams.Options}},
Aber wo ist da eine Binärzahl?
Gruß Julian
Re: EDL-C-Firmware
Hi Julian,nailuj hat geschrieben:Sry ich find das nicht.
...
Aber wo ist da eine Binärzahl?
vielleicht verstehe ich auch die Frage nicht.
Die Erklärung steht nicht im edl-parser.c, sondern wie schon geschrieben im original Syntax.pdf:
Code: Alles auswählen
OPT17 = 167
Bit 0, 1 = DACtype, 0=MAX543/LTC8043, 1=AD5452, 3=DAC8811,
Bit 2 = LM75 vorhanden,
Bit 3 = LM75 extern I2C-Adr. $48
Bit2 = 1 => 4 dezimal = 0000 0100 binär
Bit3 = 1 => 8 dezimal = 0000 1000 bin
Summe: 12 dezimal = 0000 1100 bin
Du mußt da in den Quellen nichts ändern, das ist alles per Bus konfigurierbar. Um die LM75-Konfiguration zu ändern, einfach auf dem Optobus eingeben:
Code: Alles auswählen
x:wen=1!
x:167=12!
x:167?
Und wenn das letzte Kommando den Wert 12 zurückliefert, dann ist Deine EDL erfolgreich umgestellt.
Wenn Du die Konstruktion im Code suchen willst, dann mußt Du den "Variablen" Params.Options und eepParams.Options nachgehen. Das läuft auf eine Struktur raus, in der die einzelnen Bits entsprechend gemappt sind (edl.h):
Code: Alles auswählen
typedef struct
{
uint8_t DACType : 2;
uint8_t LM75int : 1;
uint8_t LM75ext : 1;
} OPTIONS;
Kommt dann auf's gleiche raus.
Grüße
Paul
Re: EDL-C-Firmware
Danke, hat funktioniert.
Gruß Julian
Gruß Julian
Re: EDL-C-Firmware
Gerne! Wenn's Probleme mit oder Fragen zur C-Firmware gibt, dann melde Dich bitte.nailuj hat geschrieben:Danke, hat funktioniert.
Gruß Julian
Viele Grüße
Paul