FPGA und Optobus

[magicroomy]

Hallo zusammen,

ich spiele immer noch mit dem FPGA herum und versuche krampfhaft Daten über den Optobus, den ATMega und per SPI in das FPGA zu bekommen.
Auslesen funktioniert gut (Hab ich in meinem Frequenzzählerbeispiel schon benutzt). Irgendwie landet aber alles was ich reinschreibe nicht in den Flipflops (SPI32_IN.sch).
Ich benutze als Basis die Schematics aus dem DDS DemoProjekt.
SPI32_IN, SPI32_OUT...

Hatte CM schon per mail gefragt, aber leider noch keine Antwort bekommen.

Hat da sonst schon jemand Erfahrungen gesammelt?

Gruss
Magic Roomy

[cm]

Schreibe grad eine Anleitung.

Die Beispiele sind aktualisiert, vielleicht helfen die neuen.

Offizielle 1.0-Version der Firmware gibts in wenigen Stunden/Tagen.

cm

[magicroomy]

Hallo,
danke für die Antwort. Ich hab schon gesehen, daß Sie mit EDL und DCG etwas beschäftigt waren.

Ich habe mir das DDS ISE Beispiel nochmal heruntergeladen aber leider ist mein Problem immer noch da.
Ich hänge mal mein Beispielprojekt an, welches mir Kopfschmerzen bereitet.
Ich hab wie gesagt die SPI IN/OUT Ports direkt verbunden und würde also erwarten, das ich mit einem Befehl
0=1234! etwas in die Register schreiben kann, was ich mit
0? wieder erhalte. Ich bekomme aber nur 0 zurück.
Für meine Tests hab ich auch mal einen konstanten Wert angelegt. Wenn ich also sage
3? bekomme ich tatsächlich den entsprechenden Wert.
Das Auslesen scheint also zu funktionieren nur das schreiben ins FPGA nicht.
Damit ich sehe, daß das FPGA programmiert wurde hab ich die BlinkLED mal dringelassen. Die hat aber weiter keine Funktion.


Ich hab auch noch ein Bild angehängt in dem zu sehen ist wo es im Schematic von SPI32_IN noch einen Verdrahtungsproblem gibt.

MfG
Magic Roomy

[HSiebrecht]

Hallo Volker,

cm hat gerade, vor 1 Stunde, Release 1.0 bereitgestellt, eventuell hilft es ja.

[HSiebrecht]

Nachtrag, Info für alle "Updatewilligen".

Zur Zeit gibt es keine zip-Datei im c't Wiki, also alle Dateien einzeln runterladen. Aber Achtung.

- Die FPGA.hex ist OK

- Die FPGA.eep ist die hex und eep, also normalerweise .eine e2p = Device-File. Also nur in .e2p umbenennen und als Device-File laden.

- Die FPGA.e2p ist kein Release 1.0, ist wohl cm's backup aus Release 0.9

- Der neue EEPROM hat sich gegenüber Release 0.9 geändert, also besser nicht die alte .eep verwenden.

[magicroomy]

Hallo Helmut,
eine Frage zu den Formaten.
Hab mir hex, eep und e2p mit dem Texteditor angesehen.
hex und eep sind Intel Hex und fast gleich groß. e2p ist irgendwas binäres mit der Anfangskennung e2p (ASCII) .

Kann ich also tatsächlich die eep in e2p umbenennen und brutzeln? Das Format ist ja ein ganz anderes ?

Gruss
Volker

[magicroomy]

Hat sich vermutlich erledigt. Es gibt eine neue Version im Subversion.
hex, eep und e2p sehen gut aus.
Dank an CM

Gruss
Volker

[HSiebrecht]

Hallo Volker,

also habe es gerade noch einmal getestet. Du musst die .eep nicht in e2p umbenennen und Du musst auch nicht im PonyProg als Device File öffnen.

Es reicht die .eep als Flash File zu öffnen und dann das "Device" flashen. Du hast dann die hex und eep in einem Rutsch gebruzelt.

Wenn Du nur die .hex nimmst, fehlt ja der EEPROM Bereich.

Es gibt aber seit heute Version 1.01 mit einem Zip File. Jetzt haben die Files auch keine verwirrende Größe mehr.

Uuupppsss, da war der Volker schneller.

[cm]

@magicroomy:

Nimm mal das DDS.BIN. Dort ist bei Reg. 2 Eingang und Ausgang miteinander verbunden.

Wenn ich mit
2=12345!
was reinschreibe, bekomme ich es auch so wieder heraus:
2?
#0:2=12345

Reg. 3 führt eine Konstante (hex. $12345678)

0.9 hatte noch den Fehler, dass man einen Befehl nicht mit "!" abschließen durfte, sonst war der Parameter immer 0. Ist mit 1.0 behoben.


cm

[magicroomy]

Danke für den Tipp,
hab es jetzt mal mit Firmware 0.9 und 1=1234 probiert (ohne !).
Funktioniert wie erwartet. Wunderbar. SPI funzt also prinzipiell.

Hab gesehen Du hast eine neue Firmware reingestellt.
Ist das die 1.0?

Mein AVM Dragon verweigert leider die Programmierung.
Ich setze das Device auf ATMega 644, dann sagt er mir beim Programmierversuch mit dem HEX.
"Contents of Hexc-File does not fit in selected Device"

Wenn ich das das Flash aus dem ATMega auslese, in ein Hex schreiben lasse und dieses wieder bruzzle klappt das aber.

Sachdienliche Hinweise wären sensationell.

Gruss
Magic Roomy

[labhack]

Ich hatte das Problem mit mit der '... doesn't fit..' Meldung auch.
Offensichtlich ist die aktuelle .hex (Rev. 403) nicht sauber (enthält vermutlich nun auch EEPROM-Daten). Meine Lösung: Die .hex aus Revision 400 geholt und die .eep aus Revision 403. Damit klappt's auch mit dem AVR
-Studio und AVR STK500.
Vielleicht kann cm die Dateien ja noch mal aktualisieren.

[amd-65]

Ich hatte das Problem mit mit der '... doesn't fit..' Meldung auch.
Offensichtlich ist die aktuelle .hex (Rev. 403) nicht sauber (enthält vermutlich nun auch EEPROM-Daten).

Du kannst die Datei mit einem Editor selber bereinigen. Alles ab der Zeile mit der erweiterten Adresskennung bis zur letzten Zeile vor der Ende-Kennung muß entfernt werden.

Code: Alles auswählen

:1088700000001000000001000010000000010000D6
:1088800000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF7
:020000021000EC                             -> Löschen
       xx-----------> erweiterte Adresse   
:100000000000000055AA00040033000000000000BA -> Löschen
:0B0010000000000000000000000000E5           -> Löschen
:00000001FF
       xx-----------> Endekennung

Allerdings sind die EEPROM-Bytes im Hex-File und im EEP-File unterschiedlich.

Gruß
amd-65

[magicroomy]

Danke für den Tipp,
hat funktioniert. Zumindest hab ich ein FPGA mit der IDN Meldung 1.01
Es tut auch das was ich von ihm erwarte..

Gruss
Magic Roomy