C-Firmware UNI-C

dg1vs
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 138
Registriert: 20.12.2009, 22:26

C-Firmware UNI-C

Beitrag von dg1vs »

Hallo zusammen,

ich habe nach längerer Zeit mich doch noch mal an die C-Firmware für das UNI-C Modul gewagt. Idee dahinter war, ein System zu bauen, wo die FPGA-Bridges und das DACRAM-Modul als Frequenzgenerator und auch als Frequenzzähler benutzt wird. Mit einer kurzen Verbindung zwischen den Steckverbindern sollte es funktionieren und die Idee war U/f Kennlinie von VCO aufzunehmen. Aber FPAG ist noch ein Thema, wo ich etwas Hilfe bräuchte…dazu später.
Aktuelle habe ich einen Stand der Firmware den mal zum ersten Testen verteilen kann.
Was geht: Was geht nicht:
  • Ich bekomme die Software speziell den SD-Karten Driver nicht auf der 20 MHz-Version zum Laufen, deswegen hatte ich die Software auch dann irgendwann liegen lassen. Da muss irgendwo noch was im Code liegen --> deswegen nur 16 MHz!
  • Der Frequenzzähler im AVR habe ich noch nicht umgesetzt.
  • Korrektes Auslesen und Schreiben der FPGA-Register. Wer kennt sich mit der Logik im FPGA aus kann mir kurz helfen. Das wäre aktuell mein nächster Schritt.
Die Firmware liegt als Source zum Selberkompilieren im CVS. Bitte Tag beta_03 benutzen
Feedback und Änderungswünsche sind willkommen.
Grüße Karsten
dg1vs
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 138
Registriert: 20.12.2009, 22:26

Re: C-Firmware UNI-C

Beitrag von dg1vs »

Hallo zusammen,

so die FPGA-Geschichte hat mich jetzt doch einige Zeit gekostet. cm hat beim Umstieg von FGPA zum UNIC anscheinend die Adressierung der Adressregister von 8 auf 16 bit geändert. Das hat mir etwas Zeit gekostet um komplett dahinter zu steigen.

Im FPGA-Directory befindet sich nun eine Startkonfiguration (basierend auf dem pwm Beispiel von cm), die auch mit der aktuellen Software im CVS zusammenspielt. Dafür habe ich die ISE Design Suite Version 14.7 benutzt. Mit dem folgenden Tipp bekommt man es auch unter Windows 10 zum Laufen http://www.youtube.com/watch?v=ttPbEcNjdo8

So jetzt müsste ich noch genügend Wissen für die FPGA Umsetzung des Frequenzzählers/ Frequenzgenerators und eines DDS-Systems zusammenbekommen…kommt Zeit, kommt Rat…

Grüße Karsten
73 de dg1vs
psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 942
Registriert: 25.01.2008, 23:34

Re: C-Firmware UNI-C

Beitrag von psclab38 »

Hallo Karsten,

super, dass Du die Portierung durchgezogen hast! Ich hab zwar kein UNI-C, aber ich bin froh, dass ein weiteres Modul unsere C-Unterstützung bekommt.
dg1vs hat geschrieben: Die Firmware liegt als Source zum Selberkompilieren im CVS. Bitte Tag beta_03 benutzen
Magst Du nicht auch noch ein Hex-File hinterlegen? Meine Erfahrung aus den zurückliegenden Portierungen ist, dass die wenigsten Leute einen C-Compiler starten wollen. Das Hex-File auszuprobieren hingegen war meist die kleinere Hürde.

Grüße
Paul
dg1vs
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 138
Registriert: 20.12.2009, 22:26

Re: C-Firmware UNI-C

Beitrag von dg1vs »

Hallo Paul
psclab38 hat geschrieben: super, dass Du die Portierung durchgezogen hast! Ich hab zwar kein UNI-C, aber ich bin froh, dass ein weiteres Modul unsere C-Unterstützung bekommt.
Offen ist immer noch die 20 MHz Geschichte, wenn ich nicht damals darüber gestolpert wäre, dann wäre die C-Unterstützung zeitiger fertig geworden
psclab38 hat geschrieben: Magst Du nicht auch noch ein Hex-File hinterlegen? Meine Erfahrung aus den zurückliegenden Portierungen ist, dass die wenigsten Leute einen C-Compiler starten wollen. Das Hex-File auszuprobieren hingegen war meist die kleinere Hürde.
Erledigt. Kompiliert für 16 MHz und den 644. Wichtig für Leute die selbst kompilieren wollen, ist es den 644 einzustellen und JTAG_DEBUG zu entfernen. Ich habe eine etwas windige Konstruktion um den Debugger anzuschließen und entwickle für 1284P. Deswegen auch die Idee, das die Leute selbst kompilieren. Puristen behaupten zwar der einzig wahre Debugger ist printf, aber JTAG ist schon ganz gut.

Aktuell versuche ich die FPGA-Geschichte zu verstehen. Und das hat cm potentiellen "Nach-Entwicklern" m.M. unnötig schwergemacht. Das beginnt beim Umstieg von 8 bit Register-Adressen auf 16 bit Register-Adressen vom FPGA zum UNIC-Modul, wobei die oberen 8 bit nur ein "Nutzbit" enthalten und mit 8 bit schon 256 Register adressierbar sind. Was es dazu kommt, ist dass es mir extrem schwer fällt, die zu den Labview-Programmen jeweils passenden bit-Files zu finden (für das FPGA-Modul).

Grüße Karsten
francis
kann c't-Lab-Bausätze löten
kann c't-Lab-Bausätze löten
Beiträge: 28
Registriert: 27.05.2009, 21:11

Re: C-Firmware UNI-C

Beitrag von francis »

Hallo zusammen,

ich bekomme die c-Firmware nicht zum Laufen.
Sowohl mit dem fertigen hex File als auch den selber erzeugten.
Ich arbeite mit dem Atmel Studio 7 und dem Pololu Programmer (verhält sich wie STK500).
Das flashen des hex Files funktioniert grundsätzlich.
Jedoch funktioniert das uni-c dann nicht mehr.
Display keine Anzeige und auch sonst keine Funktionalität.
Beim flashen des eep bekomme ich zwar eine Fehlermeldung: File contents does not map to any valid device memory for programming EEPROM.
Habe ich auch mal weggelassen, ohne dass es etwas geändert hat.

Mit der Orginal ct Firmware, hex+eep, 16MHz ist alles ok.

Die Fuses sind:
BODLEVEL = DISABLED
OCDEN = [ ]
JTAGEN = [ ]
SPIEN = [X]
WDTON = [ ]
EESAVE = [ ]
BOOTSZ = 4096W_7000
BOOTRST = [ ]
CKDIV8 = [ ]
CKOUT = [ ]
SUT_CKSEL = FSOSC_16KCK_0MS_XOSC_BODEN

EXTENDED = 0xFF (valid)
HIGH = 0xD9 (valid)
LOW = 0xD7 (valid)

Mein Uni-C ist 16 MHz.

Grüße Franz
dg1vs
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 138
Registriert: 20.12.2009, 22:26

Re: C-Firmware UNI-C

Beitrag von dg1vs »

Hallo Franz,

das ist komisch. Ein 644 avr mit 16 Mhz sollte eigentlich problemlos funktionieren. Ich muss aber gestehen, dass ich mit einem Debugger arbeite und nicht mit einem Programmer. Muss ich morgen selber mal versuchen.

Passiert überhaupt nichts? Überhaupt keine Anzeige im Display?

Eine Idee habe ich noch. Könntest Du den EEPROM mal komplett löschen. Nicht das die Uni-C-Firmware versucht mit den EEPROM der Pascal-Firmware zu starten.

Grüße Karsten
francis
kann c't-Lab-Bausätze löten
kann c't-Lab-Bausätze löten
Beiträge: 28
Registriert: 27.05.2009, 21:11

Re: C-Firmware UNI-C

Beitrag von francis »

Hallo Karsten
dg1vs hat geschrieben:Hallo Franz,

das ist komisch. Ein 644 avr mit 16 Mhz sollte eigentlich problemlos funktionieren. Ich muss aber gestehen, dass ich mit einem Debugger arbeite und nicht mit einem Programmer. Muss ich morgen selber mal versuchen.

Passiert überhaupt nichts? Überhaupt keine Anzeige im Display?

Eine Idee habe ich noch. Könntest Du den EEPROM mal komplett löschen. Nicht das die Uni-C-Firmware versucht mit den EEPROM der Pascal-Firmware zu starten.

Grüße Karsten
Ja, im Display keine Anzeige.

Das EEPROM habe ich auch schon komplett gelöscht. Hat aber nichts geändert.

Gruß Franz
dg1vs
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 138
Registriert: 20.12.2009, 22:26

Re: C-Firmware UNI-C

Beitrag von dg1vs »

francis hat geschrieben:Hallo Karsten
Ja, im Display keine Anzeige.

Das EEPROM habe ich auch schon komplett gelöscht. Hat aber nichts geändert.

Gruß Franz
Hallo Franz,

ich kann das Verhalten bestätigen. Ich habe es mit einem 644P nachgestellt, und es passiert nichts. Bei dem von mir benutzten Controller 1284P funktioniert auch das ISP-Flashen sowohl mit elf als auch hex problemlos.
Komisch, es müsste eigentlich reichen den Controller-Typen im AVR-Studio umzustellen :?: :?: :?: . Ich suche das Problem.

Grüße Karsten
dg1vs
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 138
Registriert: 20.12.2009, 22:26

Re: C-Firmware UNI-C

Beitrag von dg1vs »

Oh je,
wieder mal eine nette Kombi von eigener Dummheit und Dreckstools...

AVR-Studio ändert scheinbar beim Umstellen auf einen anderen µC nicht sauber alle Einstellungen. Es wurde weiter fleißig mit -mmcu=atmega1284p übersetzt. Sorry dafür. Warum das dann aber so fatal endet ist mir noch nicht ganz klar. Bis auf mehr Speicher und einen zusätzlichen Timmer sind sich 644 und 1284 doch sehr ähnlich :?:. Aber lieber fatal als schleichend, da sucht man sonst noch länger.

Anbei das neue (aktuellste) hex-File. Sollte auch nun im git liegen.

Grüße Karsten

PS: Kennt jemand einen Weg sich ein "ordentliches" Makefile aus AVR-Studio generieren zu lassen. Zum Bauen und Verteilen ist ein Makefile doch der bessere Weg. Ich mag nur nicht bei null anfangen…
Dateianhänge
UNICFirmware_16_644p.hex
(133.28 KiB) 178-mal heruntergeladen
francis
kann c't-Lab-Bausätze löten
kann c't-Lab-Bausätze löten
Beiträge: 28
Registriert: 27.05.2009, 21:11

Re: C-Firmware UNI-C

Beitrag von francis »

Hallo Karsten,

besten Dank für die schnelle Abhilfe.
Das hex File funktioniert. :D
Ich habe dann mal in der unic.cproj mit einem Editor 1284p durch 644p ersetzt.
Damit bekomme ich dann auch ein funktionierendes hex File. :D :D
Eine Änderung beim target device wird offensichtlich vom Atmelstudio nicht umgesetzt.

Gruß Franz
dg1vs
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 138
Registriert: 20.12.2009, 22:26

Re: C-Firmware UNI-C

Beitrag von dg1vs »

Hallo Franz,

freut mich. Änderungswünsche und Fehler gleich an mich. Gerne direkt oder hier. Ich habe Dir eine PN mit meiner Adresse geschickt.

Einen Punkt würde ich gerne diskutieren:
Bei der FPGA-Firmware hat cm mit 8-bit Register-Adressen gearbeitet, beim Uni-C jedoch mit 16 bit Register-Adressen (Das hat mich auch einiges an Zeit gekostet, dass zu kapieren). Entsprechend unterscheidet sich auch der VHDL-Code in beiden Projekten. Ich bin aktuell dabei ein FPGA-Projekt von Laborgeist (siehe https://github.com/JosiCoder/CtLab/ und http://www.thoralt.de/phpbb/viewtopic.php?f=25&t=393) auf das Uni-C zu portieren. Da ich mit Platz im FPGA etwas knapp bin und der Original-Code auch mit 8-bit Register-Adressen arbeitet, würde ich gerne auch den Uni-C wieder auf 8-bit Register-Adressen zurückstellen.
Gibt es da größere Einwände? Ein bissel Einheitlichkeit schadet nicht.... und ich verstehe die Intention von cm nicht. Du hattest aber geschrieben, dass Du mit dem FPGA etwas gemacht hast.

Grüße Karsten
Benutzeravatar
Bart
kann c't-Lab-Bausätze löten
kann c't-Lab-Bausätze löten
Beiträge: 45
Registriert: 11.01.2014, 10:44

Re: C-Firmware UNI-C

Beitrag von Bart »

PS: Kennt jemand einen Weg sich ein "ordentliches" Makefile aus AVR-Studio generieren zu lassen. Zum Bauen und Verteilen ist ein Makefile doch der bessere Weg. Ich mag nur nicht bei null anfangen…
Ich habe mir vor Urzeiten mal mit mfile (http://www.sax.de/~joerg/mfile/) ein Makefile erzeugt. Das wird von Projekt zu Projekt kopiert und jeweils minimal modifiziert.
Da ich mit Platz im FPGA etwas knapp bin und der Original-Code auch mit 8-bit Register-Adressen arbeitet, würde ich gerne auch den Uni-C wieder auf 8-bit Register-Adressen zurückstellen.
Ich glaube nicht, das die Register der große Platzfresser sind. Ist Dein Code irgendwo verfügbar? Kannst Du evtl. den Synthesereport online stellen und hier verlinken?
und ich verstehe die Intention von cm nicht
Vermutlich haben ihm 256 Register nicht ausgereicht...

Bart
dg1vs
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 138
Registriert: 20.12.2009, 22:26

C-Firmware UNI-C Verhalten WEN bzw. SubCh 250

Beitrag von dg1vs »

Hallo zusammen,
Franz war so nett und hat sich die UNI-C-Firmware angeschaut. Dabei ist er auf einen Punkt gestoßen, wo ich das Verhalten der Firmware absichtlich geändert habe, diese Änderung hat aber zu Verwirrungen geführt. Diesen Punkt würde ich hier gerne diskutieren:
Bei der Original-Firmware und auch bei den bisherigen C-Umsetzungen existiert mit <MainChan>:WEN=1! die Möglichkeit das EEPROM-Write-Enable-Bit zu setzen, danach einen Wert zu modifizieren, das bewirkt automatische Rücksetzen des EEPROM-Write-Enable-Bit. Das bedeutet jedoch, dass wenn viele Werte zu setzen sind, dass immer die Abfolge

Code: Alles auswählen

<MainChan>:WEN=!
<MainChan>:<SubCh>=nnn!
<MainChan>:WEN=!
<MainChan>:<SubCh>=nnn!
abzuarbeiten ist.
Ich habe als Ersatz <MainChan>:WEN=23! eingebaut und die Logik <MainChan>:WEN=1! entfernt. Das bewirkt das sofortige Persistieren _aller_ EEPROM relevanten Werte auf einmal. Ein Schreibschutz existiert nicht. Entweder man persistiert oder hat nach Reset den alten Stand wieder.
Hintergrund:
• Im Menü gibt es diese Möglichkeit auch.
• Wenn man die DAC/ADC einstellt will man erst mal probieren und dann persistieren.
• Wenn man nicht persistiert, hat man den alten gültigen Stand, man kann also gefahrlos probieren.
Das wäre meine Meinung. Ich bin da aber offen und würde mich der Mehrheit anschließen, wenn vielleicht noch eine gute Begründung dazu kommt.

Grüße Karsten
psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 942
Registriert: 25.01.2008, 23:34

Re: C-Firmware UNI-C Verhalten WEN bzw. SubCh 250

Beitrag von psclab38 »

Hallo Karsten,
dg1vs hat geschrieben:Ich habe als Ersatz <MainChan>:WEN=23! eingebaut und die Logik <MainChan>:WEN=1! entfernt.
Ich stimme Dir zu, die Sache mit dem "WEN=1!" ist sehr umständlich wenn man von Hand Kommandos über ein Terminalprogramm sendet. Andererseits halte ich es für unglücklich, wenn das UNI-C² damit inkompatibel zu den anderen C-Firmwaren wird.

Was hältst Du von dem Vorschlag:
- "WEN=1!" bleibt drin und verhält sich wie vorher.
- Es gibt ein weiteres Kommando z.B. "WEN=22!", in dem Du Deinen neuen Modus einschaltest.
- Das neue "WEN=23!" funktioniert wie von Dir vorgeschlagen, und der Modus bleibt auch aktiviert.

Wenn die Rückwärtskompatibilität erhalten bleibt, dann könnte man das auch in die anderen C-Firmwaren übernehmen. Dann würden die ganzen VI-Module für die Kalbrierung trotzdem noch brav funktionieren.

Grüße
Paul
dg1vs
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 138
Registriert: 20.12.2009, 22:26

Re: C-Firmware UNI-C Verhalten WEN bzw. SubCh 250

Beitrag von dg1vs »

Hallo Paul,
psclab38 hat geschrieben:Andererseits halte ich es für unglücklich, wenn das UNI-C² damit inkompatibel zu den anderen C-Firmwaren wird.
Gutes Argument!

Müsste so gehen, wie von Dir vorgeschlagen, wird aber erst im Lauf der nächsten Tage. Bin beruflich stark eingespannt.

Grüße Karsten
Antworten