DCG2 Firmware Update

[siegiathome]

Hallo Forum,

Sommerloch beendet

Habe heute versucht, die DCG2 Firmware in Betrieb zu nehmen:
- Sourcen von Sourceforge heruntergeladen
- Unter AVR Studio 4.18 mit WinAVR-20090313 compiliert
- In config.h Optionen angepasst (EEP_12BIT_CM, kein DUAL_DAC)

Ohne Fehler compiliert:
Program: 31904 bytes (97.4% Full)
Data: 1521 bytes (74.3% Full)
EEPROM: 675 bytes (65.9% Full)

Hardware: DCG (12 Bit) und DCP + PM8

Ich bekomme auf fast alle Befehle (ausser z.B. IDN und SBD) als Antwort nur ein ? als Wert.

z.B.
1:VAL0?
-> Antwort #1:0=?

oder

1:OPT16?
-> Antwort #1:166?

1:IDN?
-> Antwort #1:254=1.0 [DCG2 by HB + PSC]

1:WEN=1
-> Antwort (zwei Zeilen):
7:0=?$3f
7:1=?$3e

Auf dem Display des PM8 stehen auch nur die Werte:
? V
?mA

Ausgangsspannung ist 5V, Ausgangsstrom 20mA (I-Led schaltet auch ein, wenn mehr als 20mA) , Menü ist bedienbar.

Was mache ich falsch? Eigentlich wollte ich ja nur das DCG in Zukunft auch als Arbiträrgenerator nutzen...

Siegi.

[HSiebrecht]

Hallo Siegi,

was mir bei Dir sofort auffällt, DCG 12 bit und DCP.

Wenn ich mich recht entsinne gibt es bei dieser Kombination immer Probleme mit den Parametern.
Parameter 167 : DCP enable

ist der bei dir gesetzt.

Warum kompilierst Du alles neu ?
Gibt es auf Sourceforge keine fertigen .hex Files ?
Habe selbst noch die Pascal FW drauf.

Schau auch mal in diesen Thread:

viewtopic.php?f=12&t=526&hilit=dcg+12+bit+dcp+eep

Wenn es nicht hilft, am besten auf Paul warten.


Viel Glück bei der Fehlersuche

[psclab38]

Hi Siegi,

Ich bekomme auf fast alle Befehle (ausser z.B. IDN und SBD) als Antwort nur ein ? als Wert.

ich weiß leider auch nicht, was da falsch läuft. Aber auch wenn ich eine andere Hardware habe und die von Dir genannten Änderungen mache, dann kommt da kein Fragezeichen. Weder im Display noch auf dem Bus.
Probier' mal den Hexcode (mit Deinen Optionen) aus. Wenn der funktioniert, dann liegts am Compilieren.

Grüße
Paul

PS: Du linkst schon die printf-Floatingpoint-Bibliotheken (libprintf_flt.a) mit, ja? Das wäre bezüglich der Ausgaberoutinen ganz hilfreich.

[siegiathome]

Hi,

danke erstmal für die Antworten

Parameter 167 : DCP enable
ist der bei dir gesetzt.

ich kann mich im Nachhinein noch schwach daran erinnern, dass OPT17 als Ergebnis 0 zurückgeliefert hat, muss ich mal probieren.

Warum kompilierst Du alles neu ?
Gibt es auf Sourceforge keine fertigen .hex Files ?
Habe selbst noch die Pascal FW drauf.

Warum selbst komilieren? Aus dem gleichen Grund warum selbst bauen! Spieltrieb, dazulernen, so umbauen, dass man auch mal einen Debugger dranhängen kann (habe sowieso nie kapiert, wie man so eine Software ohne Debugger zum Laufen bekommt, ist mir echt ein Rätsel)
Habe bisher auch noch die Pascal FW (2.91) benutzt, will aber die Arbiträrgenerator Funktionen nutzen.

PS: Du linkst schon die printf-Floatingpoint-Bibliotheken (libprintf_flt.a) mit, ja? Das wäre bezüglich der Ausgaberoutinen ganz hilfreich.

Ja, wird mitgelinkt.

Werde dann mal das DCP Flag setzten und die fertig kompilierte HEX draufnageln.

Dann mal gute nacht
Siegi.

[psclab38]

PS: Du linkst schon die printf-Floatingpoint-Bibliotheken (libprintf_flt.a) mit, ja? Das wäre bezüglich der Ausgaberoutinen ganz hilfreich.

Ja, wird mitgelinkt.

Werde dann mal das DCP Flag setzten und die fertig kompilierte HEX draufnageln.

Mit der Floatingpoint-Unterstützung stimmt jedenfalls was nicht. Vielleicht hilft Dir das:
http://www.mikrocontroller.net/articles ... AVR-Studio

Grüße
Paul

[siegiathome]

Hi Paul,

stimmt, da war was, werde es mal checken.
Habe übrigens das HEX File programmiert, läuft, allerbesten Dank für die schnelle Unterstützung (wie immer)
Irgendwie war aber der Parametersatz für die 16-Bit Version im EEPROM, habe erst mal alles noch manuell umkonfiguriert, da ich vergessen hatte, die Parameter vorher zu sichern...

Siegi.

btw: Gibts eigentlich ein Komamndo um die Arbitrary-Sequenzen zu starten?

[psclab38]

Hi Siegi,

stimmt, da war was, werde es mal checken.
Habe übrigens das HEX File programmiert, läuft, allerbesten Dank für die schnelle Unterstützung (wie immer)

Gerne (wie immer )

Irgendwie war aber der Parametersatz für die 16-Bit Version im EEPROM, habe erst mal alles noch manuell umkonfiguriert, da ich vergessen hatte, die Parameter vorher zu sichern...

Äh, tja, die Parameter mit den #define für 12/16 bit haben keine Wirkung. Der Code nimmt andere Startwerte (aus Params). Mir scheint, da gibt es noch was zu tun... .

btw: Gibts eigentlich ein Komamndo um die Arbitrary-Sequenzen zu starten?

- Such' mal im Code nach "Parameters for operation of arbitrary sequence mode", da habe ich das Prinzip erklärt.
- Hast Du im Repository schon das "ArbitraryTool_V1.3.xls" entdeckt? Damit kannst Du Dir (wenn Du vorsichtig bist) eigene Sequenzen zusammenklicken und abspeichern. In JLab hat Volker freundlicherweise einen Menüpunkt eingebaut, mit dem man dann die Sequenz ins RAM oder EEPROM des DCG Moduls runter (oder hoch?) laden kann. Habe aber bislang kein Feedback bekommen, vielleicht kämpfst Du Dich ja soweit vor.

Übrigens: wie ich grade feststelle, ignoriert die DCG2-C-Firmware das Bit 3 des OPT167 komplett. Das DCP-Feature wird nur über die Relaisschwellenspannung OPT170 aktiviert. OPT 169 gibt's auch nicht. Wenn Du die Einstellungen aus der Pascal-Firmware übernommen hast, sollte aber trotzdem alles funktionieren.

Grüße
Paul

[siegiathome]

Hi Paul,

- Such' mal im Code nach "Parameters for operation of arbitrary sequence mode", da habe ich das Prinzip erklärt.

Prinzip schon verstanden

Hast Du im Repository schon das "ArbitraryTool_V1.3.xls" entdeckt?

ja, schon entdeckt, habe leider nur eine ältere Excel Version, hab aber mal schnell eine kleine Software geschrieben, um ein Textfile mit den Daten zum DCG zu schicken, kann ich mal aufbohren und hier reinstellen.

Werde auch mal versuchen, wenn mal wieder Zeit ist, den JTAG Port freizukriegen, damit das Ganze debug fähig ist (evtl. temporär Addresspins opfern und dafür eine feste Adresse vergeben)

siegiathome wrote:
btw: Gibts eigentlich ein Komamndo um die Arbitrary-Sequenzen zu starten?

- Such' mal im Code...

was ich wollte (per Software die Sequenz ablaufen zu lassen), funktioniert mit x:188=2 (ohne vorher ein x:WEN=1 zu schicken)

Siegi.

[psclab38]

Hi Siegi,

Werde auch mal versuchen, wenn mal wieder Zeit ist, den JTAG Port freizukriegen, damit das Ganze debug fähig ist (evtl. temporär Addresspins opfern und dafür eine feste Adresse vergeben)

Die JTAG-Anschlüsse sind leider auf die Bereichsumschaltemimik verdrahtet. Beim DCG hab ich den Debugger gar nicht verwendet, glaube ich. Bei DIV, EDL, und ADA aber schon, unter temporärem Verzicht auf Funktionalität. Beim FPGA hat man gar keine Chance, weil da das SD-Interface dransitzt. Muß man halt "Programmieren durch Nachdenken", hätte mein früherer Chef wohl gesagt. Geht auch.

ja, schon entdeckt, habe leider nur eine ältere Excel Version, ...

Wenn ich das xls unter Excel5/95 abspeichere, dann geht leider die "WriteToTxt"-Funktion verloren.

... hab aber mal schnell eine kleine Software geschrieben, um ein Textfile mit den Daten zum DCG zu schicken, kann ich mal aufbohren und hier reinstellen.

wie erwähnt hat JLab schon so eine Funktion, unter "Datei/Kommandoscripts ausführen"

was ich wollte (per Software die Sequenz ablaufen zu lassen), funktioniert mit x:188=2 (ohne vorher ein x:WEN=1 zu schicken)

Nein, das kann nicht stimmen (habe ich grade ausprobiert). Das Kommando 188 will mit wen=1 freigeschaltet werden, sonst "#3:255=6 [LOCKED]". Man sollte es auch ausführen, da damit der Rest des Speichers aufgeräumt wird und man aus dem Lademodus wieder rauskommt. Daß man während des Ladens die Änderungen schon am Ausgang beobachten kann, war nicht beabsichtigt und ist eigentlich ein Bug. Der ist aber m. W. unproblematisch, so daß ich ihn als Feature dringelassen habe.

Möglicherweise hast Du aber x:182=2 gemeint. Damit kann man die RAM-Sequenz einschalten; und das Kommando braucht in der Tat kein wen=1. Das ist wiederum Absicht.

Grüße
Paul

PS: Ich habe im alten Beitrag oben das hex-File ausgetauscht, gegen eine Version mit hoffentlich wirklich 12bit-Defaultwerten.
PPS: Geht das Selbstcompilieren jetzt?

[siegiathome]

Hi Paul,

PPS: Geht das Selbstcompilieren jetzt?

bin mit den Optionen (-Wl,-u,vfprintf im Linker) aber bei einer Codegröße von 33450 bytes (102.1% Full)

Irgendwas wird da noch mitgelinkt, muss mal schaun was.

Siegi.

[psclab38]

Hi Paul,

PPS: Geht das Selbstcompilieren jetzt?

bin mit den Optionen (-Wl,-u,vfprintf im Linker) aber bei einer Codegröße von 33450 bytes (102.1% Full)

Irgendwas wird da noch mitgelinkt, muss mal schaun was.

Siegi.

Hi Siegi,
in dem eingecheckten *.aps auf SF stehen diese Optionen (die hatten Thoralt und Jörg mal für die DDS-C rausgeknobelt):

Code: Alles auswählen

<OPTIONSFORALL> 
-Wall 
-gdwarf-2 
-std=gnu99 
-DUART_2X 
-DUART_BAUDRATE=38400    
-fno-inline-small-functions  
-fno-split-wide-types  
-fno-tree-scev-cprop  
-ffreestanding  
-ffunction-sections  
-mcall-prologues  
-fdata-sections 
-DF_CPU=16000000UL 
-Os 
-funsigned-char 
-funsigned-bitfields 
-fpack-struct 
-fshort-enums
</OPTIONSFORALL>

... und für den Linker:

Code: Alles auswählen

<LINKEROPTIONS>-Wl,-u,vfprintf</LINKEROPTIONS>
<LIB>libm.a</LIB><LIB>libprintf_flt.a</LIB>

Vielleicht fehlt ja nur eine Option?

Mit DUAL-DAC und dem WinAVR-20080610 komme ich auf

Code: Alles auswählen

Program:   31140 bytes (95.0% Full)
(.text + .data + .bootloader)

Data:       1529 bytes (74.7% Full)
(.data + .bss + .noinit)

EEPROM:      675 bytes (65.9% Full)
(.eeprom)

mit dem WinAVR-20090313 ist der Code ein wenig größer:

Code: Alles auswählen

Program:   32022 bytes (97.7% Full)
(.text + .data + .bootloader)

Data:       1529 bytes (74.7% Full)
(.data + .bss + .noinit)

EEPROM:      675 bytes (65.9% Full)
(.eeprom)

Mit einem Compiliervorgang mit allen Sourcefiles auf einen Rutsch kann man nochmal ungefähr 500 Bytes sparen:

Code: Alles auswählen

C:\Programme\WinAVR-20080610\bin\avr-gcc -mmcu=atmega32 -I. -gdwarf-2 -DF_CPU=16000000UL -I C:\Programme\WinAVR-20080610\avr\include -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wextra -Wstrict-prototypes -Wa,-adhlns=uart.lst  -std=gnu99 -fno-inline-small-functions -fno-split-wide-types -fno-tree-scev-cprop -ffreestanding -ffunction-sections -fdata-sections -mcall-prologues --combine -fwhole-program -Wl,--relax,--gc-sections,-Map=dcg.map,--cref,-u,vfprintf -MD -MP dcg-hw-asm.S parser.c timer.c dcg-hw.c dcg-parser.c encoder.c i2c.c i2creg.c lcd.c dcg-panel.c dcg.c uart.c --output dcg.elf -lprintf_flt -lm 

avr-objcopy -O ihex -R .eeprom dcg.elf dcg_allinone20080610.hex

In ein Batchfile und eventuell Pfade anpassen.

Würde mich jetzt stark wundern, wenn Du das nicht auch hinbekommst!
Gruß, Paul

[siegiathome]

Hi Paul,

hat super funktioniert....

habe mal die fehlenden Optionen der Reihe nach mit angegeben, ohne irgendwelche Abhängigkeiten zu berücksichtigen:

Code: Alles auswählen

//ohne nachfolgende Optionen:33450
-DUART_2X                   : 33454 (+4)
-DUART_BAUDRATE=38400       : 33454 (0)
-fno-inline-small-functions : 32784 (-670)
-fno-split-wide-types       : 32854 (+70)
-fno-tree-scev-cprop        : 32854 (0)
-ffreestanding              : 32880 (+26)
-ffunction-sections         : 32880 (0)
-mcall-prologues            : 32094 (-786)
-fdata-sections             : 32094 (0)

Wert (..) in Bytes.

Vielen Dank nochmal.

Siegi

[psclab38]

Hallo Siegi,

vielen Dank für die Liste.
Ich hab' da mal eben ausprobiert, was es mit den beiden Optionen auf sich hat, die nach Deiner Liste Platz kosten:

Code: Alles auswählen

-fno-split-wide-types       : 32854 (+70)

Wenn man von der kompletten Optionenliste diesen Parameter wegläßt, dann bringt das bei meinen Experimenten je nach Projekt grade mal zwischen 0 und 12 Byte mehr Platz.

Code: Alles auswählen

-ffreestanding              : 32880 (+26)

Diese Option wegzulassen kostet zwischen 28 und 84 Bytes.

Wenn man will, kann man den ersten Parameter wohl weglassen, den zweiten sollte man drinlassen. Im Großen und Ganzen ist aber die Optimierung ganz ok.

Grüße
Paul

[psclab38]

Hallo Siegi,

Du wolltest doch was gegen das Sommerloch tun:

Habe bisher auch noch die Pascal FW (2.91) benutzt, will aber die Arbiträrgenerator Funktionen nutzen.

Nachdem wir ja jetzt die Startschwierigkeiten überwunden haben, gibt's denn sonst noch Fortschritte?

Grüße,
Paul

[siegiathome]

Hi Paul,

habe das Sommerloch erstmal mit Urlaub gefüllt Bin grad an einem kleinen Tool dran, damit man eine Kurve für die Arbiträrfunktion nicht mehr per Hand eingeben muss...
Kann noch ein bisschen dauern...

Siegi.