Guten Abend, ich möchte gerne die Ansteuerung von einem billigen 3,5" TFT (http://www.ebay.de/itm/3-5-Raspberry-Pi-LCD-Module-320-480-TFT-Resistive-Touch-Display-SPI-for-B-B-/181631856718?hash=item2a4a1a304e:g:EhgAAOSwZVhWTIXH) für den Pi entschlüsseln damit ich dieses auch ohne die closed source Treiber verwenden kann. Die Ansteuerung erfolgt über SPI (8 MHz) über 3 kaskadierte Schieberegister HC595. Die Sampletiefe von nem OLS ist leider zu klein um da sinnvoll mitschneiden zu können, ein Saleae-Clone leider zu langsam (bekomme da mit Pulseview nur max. 12MHz Sample Rate) Idee: Die 3 HC595 mit nem FPGA nachbilden und die parallelisierten Daten im Block RAM speichern. Soweit kein Problem, aber wie bekomme ich die Daten einfachst dann auf den PC? Verwende div. Cyclone II/IV mit Quartus. Gibts da eine Möglichkeit den Speicherinhalt per USB Blaster auszulesen?
Gast
#4629238
Gibt es bei Quartus nicht den SignalTap? Mit dem solltest du doch einfach dein SPI mitschneiden können.
Ich möchte nicht das Rohsignal mitschneiden (enthält viel Pausen und Leerbytes) sondern das was am Ende von 3*595ern rauskommen würde. Die quasi aufbereiten Daten würde ich im RAM puffern. Das Rohsignal kann ich einfacher mit nem Open Logic Sniffer sampeln aber durch die Pausen und Leerbytes wird auch mit RLE viel Speicher vergeudet.
Gast
#4629244
nein, wenn Du den Trigger richtig setzt, wird gar nichts verschwendet.
Gast
#4629251
Du kannst doch deine SR implementieren. Und immer, wenn ein Byte durch ist, erzeugst du dir ein Signal, welches deinen SignalTap triggert und den Inhalt des SR sampelt... Ich verstehe nicht so ganz, was daran verschwenderischer ist, als es manuell in ein RAM zu kopieren..
Ich habe das so verstanden dass ich mit SignalTap das Rohsignal sampeln soll. Werde das mal mit dem SR probieren :) Der Trigger hilft mir zwar den Anfang festzulegen aber er hilft nicht um das uninteressante das auf dem SPI zwischendurch passiert auszulassen. Oder habe ich da in OLS was falsch verstanden? Will möglichst viele Daten fürs TFT mitschneiden.
Funktioniert mit Signal Tap II. Vielen Dank :))))
Gast
#4630508
:-) Offensichtlich bist du zwischenzeitlich selbst drauf gekommen, wie ich es gemeint habe. Prima, dass alles klappt.
Ja, wusste nicht, dass der diese Funktionalität enthält nur die "relevanten" Ereignisse mitzuschneiden.
Gast
#4630520
Naja, du kannst auf jedes beliebige Ereignis triggern. Und somit kannst du ja selbst entscheiden, WAS für dich interessant ist ;-)
Das triggern war einfach, aber die Möglichkeit auch zu entscheiden wann ein Wert gespeichert wird ist im Gegensatz zu meinem günstigen Openlogic Sniffer genial. Das einzige wo ich hing waren die Register die immer leer waren. Liegt wohl daran, dass Quartus "leere" Logik wegoptimiert.
Gast
#4630531
das kann sein, dasss Quartus das weg optimiert.. Aber dann könntest du einfach das letzte Bit auf einen Pin legen und Quartus sollte nichts mehr weg optimieren.. Du scheinst es dann doch ein bisschen anders gelöst zu haben, als ich mir vorstellte. Ich dachte dass du ein SR baust und immer dann, wenn das SR "voll" ist, einen Impuls erzeugst. Und dieser Impuls ist dein Sample-Takt für Signal Tap. Aber offenbar kann man auch noch zusätzliche Triggerbedingungen definieren. Ist schon sehr lange her, dass ich mit Signal Tap gearbeitet habe. Daher wusste ich das nicht mehr (oder vielleicht ging das damals auch noch gar nicht. Aber umso besser, wenn das geht. Das macht die Sache natürlich noch einfacher
Das unbekannte LCD wird auf der Platine durch 3 kaskadierte 595 angesteuert und geben ihren Inhalt bei steigendem CS vom Pi an das LCD weiter, dessen Belegung und Typ ich nicht kenne. Da durch die Kaskade mehr als 24bit rauschen ist für mich das einsynchronisierte CS_rising der Trigger. Im Signal-Tap habe ich dann die Möglichkeit gefunden, dass man für die Speicherung der Daten auch einen "Trigger" festlegen kann. Somit starte ich beim ersten CS_rising und speichere dann bei jedem CS_rising. Auf die Idee, das CS_rising als Sample-Takt zu nehmen bin ich gar nicht gekommen. Morgen mal probieren :)
Gast
#4630553
Na wenn das so geht, ist das sicher die bessere Methode, da alles schön synchron bleibt. Wenn du CS als Takt für deinen SignalTap verwendest, dann könnte Quartus auf jeden Fall "schlau" genug sein, dass es erkennt, dass zwischen den SR und der SignalTap-Logik ein Domänenübergang ist. Da der Takt für den Signaltap aber abgeleitet ist, sind Quartus theoretisch alle Parameter bekannt, um eventuelle Setup- und Hold-Probleme selbst zu lösen.. Na ja, aber es ist halt Quartus... vielleicht sollte man da nicht zu viel erwarten..
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.