Hallo zusammen, ich habe in meinen Augen ein großes Problem mit der CPLD Programmierung. Die Angeschlossenen LEDs leuchten nicht im Zähltakt wie gewollt, sondern wahllos und ohne erkennbaren Sinn durcheinander. A U F B A U Platine mit Tastern und LEDs: - Taster schalten Masse auf die CPLD Eingänge und sind über 10k auf 3.3V aufgehangen - LEDs werden über Transistoren angesteuert (RB=3.3k daher 1mA aus einem CPLD Ausgang; RC=470 Ohm als LED vorwiderstand) - 12V Taster gehen direkt auf die SPS Platine mit CPLD: - 12V (OUT SPS) => 3.3V (IN CPLD) über Spannungsteiler Widerstand und Z-Diode (parallel dazu 10k Pull down) - Es befindet sich auch noch ein Analoger MUX drauf (IC-Baustein); diese Pins sind angeschlossen, bei dieser Schaltung aber nicht verwendet (Ich nehme an, dass nicht benutze Eingänge den CPLD nicht beeinflussen?!) B I S H E R I G E T E S T S Die Kommunikation zwischen den Komponenten wurde schon erfolgreich getestet. Das heisst die Tastersignale gingen durch den CPLD zur SPS. Diese schlaltete dann die Signale wieder durch den CPLD zu den LEDs. Das hat alles super funktioniert. Auch ein Blinken der LEDs durch den SPS clock wurde erfolgreich getestet. Daher nehme ich an das alle Kabelwege passen. Habe den Counter auch schon mit JK-FF aufgebaut mit dem selben Effekt. P R O B L EM Wie oben beschreiben blinken die LEDs wahllos und ohne Sinn durcheinander. In der Simulation mit ISE funktioniert alles super. Hoffe es ist nur eien Einstellung im CPLD. UCF-file sieht so aus NET "CLK" LOC = "5"; NET "Q0" LOC = "39"; NET "Q1" LOC = "43"; NET "Q2" LOC = "44"; NET "Q3" LOC = "28"; Bin gerade echt ratlos und hoffe mir kann hier jemand weiterhelfen. Muss in 3 Wochen meine Bachelorarbeit abgeben und jetzt so ein Mist :-( . Danke schon mal im Vorraus an alle die mit helfen. MfG Mario
Angehängte Dateien:
-
CB4CE.png
6,1 KB
Taster entprellt?
Hatte ich am Anfang gemacht mit 100nF Kondensatoren. Die haben sich aber glaube nicht mit den Buffern vertragen und es kam nur signalwirrwar raus. Habe sie wieder entfernt und mit den internen Buffern gearbeitet. Funktionierte super. Da ich den Clock aber von der SPS einspeise ist das doch denke ich nicht so wichtig oder? Die Schalter sind dabei komplett ungenutzt. Aber danke für die Antwort und den Tipp. Korrigiere mich bitte wenn ich falsch liege mit meine Annahmen.
Benutze mal die SuFu. Ohne entprellung wird das nix.
Auch wenn ich den Taster garnicht nutze? Der Eingang bekommt dann über einen Widerstand definierte 3.3V (high). Das inputsignal kommt von der SPS direkt über den internen Clock. Muss ich den auch puffern? Wenn ich den direkt durchschleife, durch den CPLD, Blinkt die LED wunderbar. Nach einigem suchen mittlerweile habe ich eher das #gefühl, dass es an dem ucf-File liegt und den Pineinstellungen. Viel weitergekommen bin ich da aber auch noch nicht. Wenn ich das mit dem Kondensator mache, sollte es ja reichen, den einfach von Pin auf Masse zu legen oder nicht? So hatte ich es vorher. Allerdings nicht unmittelbar in der nähe vom CPLD. Ich werd das nachher mal versuchen. Und auch an dich eine schönen Dank für die Unterstützung. Lösung wird selbstverständlich am Ende geschrieben. Ich hoffe ich / wir finden Eine :-D MfG
Ach so vielleicht sollte ich noch erwähnen, dass die LEDs zwar wahllos blinken, aber im Takt der SPS.
Mario schrieb: > Ach so vielleicht sollte ich noch erwähnen, dass die LEDs zwar wahllos > blinken, aber im Takt der SPS. Das sieht so aus, weil der Zähler bei jeder Taktflanke von der SPS mehrfach getriggert wird, z:b. wegen Reflexionen oder zu langsamen Flanken ohne Schmitt-Trigger. Der Xilinx kann sicher mehrere 100 MHz, und dafür muss auch die Verbindung ausgelegt sein. Ein fliegendes Kabel ist da z.B. nicht.
Mario schrieb: > NET "CLK" LOC = "5"; Müsste das beim nicht-BGA Gehäuse nicht LOC = "P5" usw. heißen? Hatte das noch so in Erinnerung.
Danke. Das war mir zwischendurch auch schon aufgefallen. Funktioniert aber beides soweit. Zumindest werden die Eingänge angesteuert. Ich versuche den UCF-File jetzt immer über das Pace anzulegen.
So also ich gebe mich geschlagen. Es liegt sicher nicht an der Programmierung. Beim nochmaligen Probieren mit dem Taster, konnte man ein prinzipielles Zählen erkennen. Wie bekomme ich nun das Flattern weg? Ich dachte der CPLD bräuchte nicht an jedem Pin einen Pull up oder down und am besten noch nen Kondensator dazu. Hat jemand eine gute Idee wie ich das lösen kann?. Habe jetzt erstmal dem Eingang für Clock einen 100nF verpasst. Brachte auch minimale Besserung. Wenn man aber mit einem Schraubendreher oder Draht aug den Terminalschrauben am Rand der Platine rum spielt, schalten die Ausgänge fröhlich umher. Sollten die nicht einen Pull down drin haben?
Lass mal den Quatsch mit den Kondensatoren völlig weg, das ist Unsinn. Hier steht wie es gemacht wird: http://www.lothar-miller.de/s9y/categories/5-Entprellung
Vielen dank, dass klingt sehr interessant. Leider habe ich nicht wirklich eine Ahnung von VHDL. Aber zu dem thema wird es sicher noch andere Beiträge geben. Ich habe bei kurzem Anhalten auch festgestellt, dass ein Kondensator eher schlechter ist. Ein Problem konnte ich schon ausbessern. Wenn ich eine Terminalschraube berühre flackern keine Leds mehr. Mein 12V Netzteil hat wahrscheinlich so etwas wie eine galvanische trennung verursacht. Hab den Minus einfach auf den SPS 24V Minus gelegt und Ruhe. die 24v verwende ich ja nicht aber die Masse oder eben der Minus hat einen guten Dienst getan. Des Weiteren habe ich festgestellt, dass eine direkte Ansteuerung der LEDs über den CPLD bessere ergebnisse erziehlt als diese über eine Trasistor anzusteuern. Der transistor braucht zwar nur 115µA Basisstrom und schont damit den CPLD extrem, ist aber für Störeinflüsse sehr anfällig. Also habe ich jetzt ein paar LED als "sink" angeschlossen. Da schafft der CPLD mehr. Manches hört sich hier sicher sehr einfach an. Allerdings ist sowas für mich doch Neuland. Was mich aber noch Stutzen lässt ist, wenn ich den SPS Clock, der in den CPLD geht, mit einem Schieberegister puffer, wie soll die SPS dann wissen wie weit jetzt im CPLD gezählt wurde?! Bei den Tastern verstehe ich das ja, aber bei dem SPS clock nicht ganz. Am Ende soll mal mit dem clock ein Counter im CPLD angesteuert werden, der dann einen MUX steuert. Einige werden jetzt sicher denken "Warum nimmst du nicht gleich einen Mikrokontroller?" Das war halt Projektvorgabe mit der SPS und da habe ich auch mehr Erfahrung. Nur mal so neben bei ;-) MC programmieren muss ich auch noch mal lernen :-D Zurück zum Thema. Ich habe auch immer noch das gefühl das die FlipFlops oder Gates im CPLD nicht synchron angesteuert werden. Ich habe auch schon den BUFG (global clock buffer) verwendet. Das bringt minimale besserung, doch das richtige Erfolgserlebnis blieb bisher aus. Vieleicht kennt sich hier ja jemand mit den Innereien von so einem Teil aus. Ich berichte dann mal von den schieberegister Resultaten. MfG Mario
Mal ne andere Frage, welchen CPLD (incl. Bauform) verwendest Du? Die CPLD und FPGA haben spezielle Clock-Eingänge, die den Takt sicher durch den Chip routen, normale Eingänge sind da nicht so günstig. Wie hoch ist der Takt? Ein Schaltplan wäre auch nicht schlecht, da du ja auch Probleme mit der Störfestigkeit hast.
OK, Clock hängt am richtigen Eingang. Die wichtigen Daten in der Überschrift zu verstecken, wo sie niemand finden kann, ist aber auch eine absolute Frechheit ;-) Bei dir scheint der Aufbau das Problem zu sein.
Sorry ;-) Aber sonst habe ich glaube viel reingeschrieben ;-) Hatte ja am Anfang kein plan von CPLDs und jetzt gleich so ein Projekt. Aber egal es funktioniert jetzt. War kurz davor aufzugeben und hatte den Rechner schon runtergefahren. Dann habe ich noch ein wenig mit einem 100nF Kondi am CPLD rumgespielt und siehe da, aud einmal ging es. :-D Ich habe den Clock-Eingangspin (P5) mit dem Ausgang (Bit 0) des Counters verbunden. Dann lief er einwandfrei. Beim verwinden mit dem Bit 1 liefen nur noch Bit 1-3. Ein kumpel der das selbe Projekt macht hat gemeint das die Risetime der SPS ziemlich lang ist. Vielleicht rührt der Fehler daher. Denke mal das der Koni beim Steigen der Flanke den Eingang auf den Ausgang schaltet. Dies wiederum beeinflusst auch die anderen Aussgäne oder das Zählen insgesamt im CPLD positiv. Warum kann ich auch nicht sagen. Ich komm mit meinen Multimererspitzen nicht ganz an die Makrozellen im Chip ran ;-) Des Weiteren meinte er das es mit einem Signalgenerator, der wahrscheinlich ein besseres Rechteck liefert, funktioniert hat. Ich kann das leider nicht testen, da ich sonst die SPS (die ohne Strom immer alles vergisst) von zu Hause mit in die Schule nehmen müsste. Mit einem Taster funktioniert es jetzt auch super. Sogar wenn ich einen nutze der nicht auf einen speziellen Clock-Eingang geht. Ging sogar ohne I/O Buffer glaube ich. Habe jetzt aber nicht jeden Versuch den ich unternommen habe im Kopf. Also nochmal die Kurzfassung. 100nF |----------------||----------------------| | | Clock SPS ---> Pin 5 CPLD (GCK) ---> [CPLD intern] ---> Pin a ---> LED Bit3 ---> Pin b ---> LED Bit2 ---> Pin c ---> LED Bit1 ---> Pin d ---> LED Bit0 Pin a, b, c, d sind frei Wählbar. Hoffe das geht als Skizze durch ;-) Danke an alle die mit geholfen haben :-D MfG Mario Bei weiteren Fragen einfach schreiben.
Ein kleiner Nachteil ergibt sich sehe ich gerade. Der Ausgang (Bit 0) Blinkt im selben Takt wie die SPS. Heisst also wenn ich nur Steigende Flanke haben will muss ich noch nen vorteiler reinmachen. Aber hauptsache es Zählt ;-)
Hab gerade gesehen das der Plan ziemlich verschoben wurde. Jetzt sollte
es passen ;-)
|------------||-----------|
| 100nF |
| |
Clock ---> Pin5 CPLD(GCK) ---> [CPLD] ---> Pin a ---> LED Bit3
---> Pin b ---> LED Bit2
---> Pin c ---> LED Bit1
---> Pin d ---> LED Bit0
Mario schrieb: > Ein kumpel der das selbe Projekt macht hat gemeint das die Risetime der > SPS ziemlich lang ist. Wenn das der Fall ist, dann schalte ein paar Gatter mit Schmitt-Trigger-Funktion (74HC14 o.ä.) davor. Duke
@ Duke: Danke für den Hinweis :-D Das ist ihm dann auch noch eingefallen. Da rührt auch der Fehler her. Die SPS hat eine Abfallzeit von etwas mehr als 10ms. Autsch. Wer verbindet auch eine SPS mit solchen Bausteinen?! ;-) Werd dann gleich mal einen Schmittrigger aufbauen und mal schauen wie sich das Ganze auswirkt. Resultate gibt es dann hier später.
Die Abfallzeit eines SPS Ausgang ist natürlich ewig, weil der Ausgang üblicherweise p-schaltend ist. D.h. die 1-0 Flanke ist sehr undefiniert. Abhilfe schafft ein Lastwiderstand gegen GND. Aber als Taktsignal würde ich sowas nicht verwenden...
Mario Sachse schrieb: > Die SPS hat eine Abfallzeit von etwas mehr > als 10ms. Autsch. Wer verbindet auch eine SPS mit solchen Bausteinen?! > ;-) Ich, bzw. mein Kollege. Dort funktioniert das mit den Schmitt-Trigger (bisher) tadellos. Duke
@ Duke Scarring (Gast) >> Die SPS hat eine Abfallzeit von etwas mehr >> als 10ms. Autsch. Wer verbindet auch eine SPS mit solchen Bausteinen?! >Ich, bzw. mein Kollege. Dort funktioniert das mit den Schmitt-Trigger >(bisher) tadellos. Wenn davor auch ein passender RC-Filter sitzt, ist dass voll OK.
Oh man, den Beitrag hatte ich garnicht mehr weiterverfolgt. Ich weiss es ist etwas spät aber um das Thema mal abzuschließen. Die Lösung von Duke hat super funktioniert. Habe damals einen 555 Timer als Schnmitt-Trigger genutzt und es ging. Also ein etwas verspätetes "Danke" :-) MfG Mario
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.