www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Grundl. Problem


Autor: Cpt (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Cpt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Cpt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Cpt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan May (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Cpt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Jörn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan May (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Cpt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan May (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Cpt (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.