Hallo Leute Ich habe da eine vermutlich einfach zu beantwortende Frage... Das ganze soll mal ein 7-Segment-Displaycontroller werden. Im Anhang ist der Eingangsteil und der soll erstmal die Daten seriell entgegen nehmen. Im Prinzip legt der Mikrocontroller das erste Bit an dataINP und aktiviert danach uCsend worauf der CPLD das Bit in das Schieberegister legt und mit ack den Empfang quitiert ... soweit so gut. Mir fehlt nur ein kleiner Denkanstoß für das ack Signal. Vielleicht könnte mal jemand in den Code schauen (das Auskommentierte würde sinngemäß wiederspiegeln was ich meine) Danke Cpt
brauchst du überhaupt das Ack Signal? Bei einer steigenden Flanke von uCSend werden die Daten übernommen und das ist bekannt. Ich würde das Ack Signal weglassen.
Wenn ich ein bestimmtes Timing beachte brauche ich ack nicht. Genaugenommen auch uCsend nicht. Allerdings wollte ich die Übertragung asynchron halten und dazu wären die zwei Hilfssignale schon gut. Und das Problem an sich kann doch nicht so schwierig zu lösen sein oder doch? Trotzdem danke Cpt
Ein bestimmtes Timing wirst du immer befolgen müssen. Genauso wirst du auch ein Signal brauchen mit dem du deiner Schaltung sagst, dass neue Daten anliegen, d.h. du brauchst das ucSend Signal.
Wenn ich die Übertragung synchron gestalten würde könnte ich mich auf eine Übertragungsrate festlegen und mit einem Start/Synchronisationsbit das ganze abgleichen und die Clock Signale (getrennt) als Datenübernahmeflanke nutzen. Somit bräuchte ich nur EINE Leitung für die Daten. Aber wie gesagt: Die Übertragung soll asynchron verlaufen und deshalb ist es nicht nötig ein Timing zu beachten, da über die Kontrolleitungen alles geregelt wird.
Bei jedem SRAM, das auch ein asychrones Interface hat, ist immer ein Timingdiagramm im Datenblatt angegeben ist. Dort muss auch ein Timing einhalten, damit die Daten korrekt ein- bzw. ausgelesen werden. Warum willst du die Schaltung aynchron aufbauen? Das Design das du angehängt hast, ist zudem synchron.
Ok ich glaube wir reden gerade leicht aneinander vorbei :-) Laut meinen Unterlagen gibt es zwei grundlegende Prinizipien der asynchronen digitalen Schnittstelle: -------------------------------------------------------------------- 1.Taktfrequenz FEST vereinbart -> Startbit senden um Phasenlage der Clocksignale zu synchronisieren --> feste Übertragungsrate aber wenige (bis 1) Leitung. 2.Handshaking -> Datenbit anlegen (Leitung 1) -> Data Valid Signal ausgaben(Leitung 2) -> Verarbeitung beim Empfänger -> Datenbit erkannt ACK ausgeben(Leitung 3) -------------------------------------------------------------------- Und um die Sache abzurunden: Synchron bedeutet für mich: Leitung 1: Takt Leitung 2: Daten Leitung 3: Data Valid als Beispiel würde ich hier den SPI Bus anführen Im Grunde genommen ist Variante 1 der asynchronen Übertragung dann wohl nur ein Emulation der synchronen :-)) So zumindest behauptet mein Professor verhält sich die Geschichte mit digitalen Schnittstellen. Wenn besagtes asynchrones RAM nun Variante 1 benutzt, dann muß natürlich ein gewisses Timing eingehalten werden. Siehst du das genau so? Grüße Cpt P.S. bevor wieder irgendwer meckert: NEIN dieses VHDL-Projekt ist keine Hausaufgabe für die Uni sondern wird aus Interesse an der Materie durchgeführt! Danke
Also zum Asynchronen Interface mußt Du Dir ein vernünftiges Handshake-Verfahren aussuchen. Du kannst ein 4-Phasen Handshake machen: REQ aktivieren -> ACK aktivieren -> REQ deaktivieren -> ACK deaktivieren Du solltest außerdem mit metastabilen Zuständen rechnen. Dazu habe ich schon in dem FIFO Thread einige Literaturangaben gepostet. http://www.mikrocontroller.net/forum/read-9-139800.html Und als letzten Hinweis: Wenn irgendmöglich, dann vermeide sowas. Das sieht im ersten Moment schick und einfach aus, zieht dann aber einen ganzen Rattenschwanz an Problemen nach sich. ciao, Stefan.
Wenn es ein MC ansteuern soll, dann brauchst Du ihm die Sache doch nicht unnötig schwer zu machen. Nimm irgendein serielles Standardprotokoll, z.B. SPI oder I2C. Allerdings braucht man für 7-Segmentanzeigen nie im Leben die Geschwindigkeit eines CPLD. Da reichen 100Hz Multiplexfrequenz dicke aus und das kann jeder MC ganz nebenbei mit im Timerinterrupt machen. Daher ist das Ganze wohl eher eine Designstudie, um in CPLDs und VHDL hinein zu riechen. Peter
@Stefan Mit den Problemen dürftest du Recht haben ... es fängt schon an :-) Aber ich finde es immer hilfreich solche Probleme zu erkennen und dann später zu vermeiden. Danke für den Link @Peter 1.Später möchte ich auch ein Standartprotokoll implementieren, aber dazu muß ich dann ja nur noch einen Block austauschen und ich fange lieber klein an. 2.Ja du hast Recht ein CPLD ist sicher überdimensioniert für eine solche Aufgabe. Ich habe aber gerade das Problem 14 7-Segment anzeigen zu multiplexen und das wird mit einem ATMega8 bei 4Mhz schon hakelig. Ich löse lieber konkrete Probleme als irgendwelche erdachten Aufgaben ... und da bietet es sich für den Anstieg gut an.
Ich stimm dir du. Ich bin kein Fan von asychronen Schaltungen. Das letzte Mal als ich mir eine asynchrone Schaltung eingehandelt habe, gab es nur Probleme. Deshalb würde ich, wie Peter schon vorgeschlagen hat, ein sychrones Interface nehmen. Jörn
Also die Probleme sind ja bekannt und es gibt auch Auswege aus der Situation. Ganz verteufeln sollte man das also nicht. Nur sollte man wissen worauf man sich da einläßt. Wenn einem Metastabile Zustände schon nix sagen, dann sollte man lieber die Finger von lassen. Aber ich glaube das muß jeder mal schmerzhaft durchmachen, sonst glaubt man ja gar nicht, welche Probleme da auftauchen. Ich habe meinem Prof. nicht geglaubt und bin dann auf die Nase gefallen. Ich habe allerdings auch eine Menge gelernt. Fazit: Blutige Nase, aber ein bisschen schlauer. ciao, Stefan.
>1.Später möchte ich auch ein Standartprotokoll implementieren, aber >dazu muß ich dann ja nur noch einen Block austauschen und ich fange >lieber klein an. Dann nimm doch SPI, da hast du weniger Probleme: Takt, Daten, Latch: Man schiebt die Daten seriell über den Takt rein, mit Latch werden diese übernommen. fertig. Da braucht man kein kompliziertes Handshaking usw. >2.Ja du hast Recht ein CPLD ist sicher überdimensioniert für eine >solche Aufgabe. Ich habe aber gerade das Problem 14 7-Segment anzeigen >zu multiplexen und das wird mit einem ATMega8 bei 4Mhz schon hakelig. Guter Witz... Ich steuere mit einem AT89C2051 mit 24MHz (=2MIPs) ein 12 stelliges Display an. Nebenher lasse ich ihn noch eine Reihe Taster abfragen, die 12 Stellen zu einer 32bit Zahl zusammenfassen und noch ein paar 48bit Divisonen machen, ehe er das ganze überträgt, damit sich der uC nicht langweilt... Außerdem kommt das ganze viel billiger: Ein uC ist flexibler und kostet weniger als ein CPLD. Da würde ich eher einen AT90S1200 oder 2313 als LED Controller nehmen.
Also Handshake nimmt man grundsätzlich nur, wenn der Empfänger ein MC ist, da dieser ja gerade mit was anderem beschäftigt sein kann. Ein CPLD arbeitet aber grundsätzlich parallel, da ist ein Handshake nicht nur völlig überflüssig, sondern würde alles nur noch unnötig kompliziert machen. Einfach ein Schieberegister der nötigen Länge programmieren und fertig ist das SPI-Interface. Zum Starten eines neuen Datenpakets nimmt man entweder ein Chipselect-Signal oder ein Startbit, d.h. Du brauchst nur 2 oder 3 Leitungen zum MC. Benedikt hat natürlich recht. Zum flimmerfreien Darstellen reichen 100Hz aus, das sind dann bei 8 Segmenten 800Hz Interruptfrequenz und das lastet selbst einen 1MIPS-MC (=1250 Zyklen) auch nicht annähernd aus. Peter
So ich habe mich etwas näher mit dem SPI beschäftigt und glaube, daß es vermutlich die einfachste und beste Lösung für den Anfang ist. Danke allen für die Hinweise. Kritik möchte ich an dieser Stelle aber auch loswerden. In diesem Forum scheint es irgendwie üblich zu sein nicht das Problem selbst zu beantworten sondern es in Frage zu stellen. Versteht mich nicht falsch, es war ja auch durchaus nützliches dabei. Allerdings ist mir durchaus bewusst, daß ein uC diese Aufgabe erledigen kann usw. (hat schonmal jemand darüber nachgedacht, daß der übrige Code vielleicht auch aus vielen Interrupts bestehen könnte und noch ein paar mehr ein übeles Gewirr anrichten ... etc.) Auch wenn ich jetzt eine andere Version der Schnittstelle verfolge würde es mich durchaus interessieren wie das anfängliche Problem gelöst wird. Danke an alle Cpt
Falls du Interesse hast, kann ich dir meine SPI zur Verfügung stellen (Master/Slave) Für das Empfangen/Bestätigen würde ich eine State Machine nehmen: 4 States: IDLE -> Empfangen -> Verarbeiten -> Ack senden -> IDLE Gruss Jörn
Hi Cpt, Habe ich doch kurz skizziert. Du brauchst ein vernünftiges Handshakeverfahren (4-Phasen Handshake oder 2-Phasen Handshake) und mußt die durch asynchrone Signale entstehenden metastabilen Zustände abfangen. Dann kannst Du auch ein asynchrones Interface benutzen. ciao, Stefan.
Hallo zusammen Hat ein wenig gedauert aber jetzt bin ich um einiges weiter (ob das wohl daran liegt, daß wir State-Maschines behandelt haben ...) und hätte gerne eure Meinung bzw. Verbesserungen zum Anhang. Ich denke es könnte funktionieren :-) Und ... so richtig asynchron ist es jetzt aber auch nicht mehr. @Jörn Ja an dem SPI Interface wäre ich interessiert! Dann könnte ich mir mal anschauen wie man so etwas löst. @Stefan Ja du hast es skizziert. Hatte es nur nicht richtig erkannt. sorry Danke Cpt
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.