Hallo, viele Leute die ich gefragt habe meinen ein normales Text Display (2x16) mit HDxxx Controller sei per µC viel einfacher anzusteuern als mit einem FPGA? Das konnte ich nicht glauben... Haber gerade mal geschaut.... Xilinxs Starterboard 3E verwendet einen Softcore um das Display anzusteuern, es gibt aber auch VHDL Code im Netz. Ist das wirklich soooo schwierig? Was macht es schwieriger?
Hi, habe einige LCD-Integrationen gemacht, aus meiner Sicht also: Die Initialisierung ist meist der springende Punkt. Es macht einfach auch keinen Sinn, die Init-Sequenzen "hart" zu implementieren, besonders, wenn mal der betreffende LCD nicht mehr verfügbar sein sollte. Meistens stimmt auch was beim Timing nicht, dann sucht man erst mal eine lange Zeit den Fehler. Es geht deutlich schneller, einen simple Software-CPU wie z.B. die ZPU einzubinden. Gibt hier einige interessante Anwendungen: http://forum.gadgetfactory.net/index.php?/page/articles.html/_/papilio/quadrature-encoders-and-lcd-r20 http://forum.gadgetfactory.net/index.php?/topic/1220-lcd-experiments/page__st__10
In VHDL ist ein sequenzieller Ablauf (auch mit Verschlachtelungen) sehr einfach zu implementieren, wenn man sich einiger Hilfsmittel bedient. Solche Sachen kann man leicht mit Excel machen, das als Codesynthesizer fungiert und die Enumeration von states, die Abfragen und die Sprünge zu den nächsten states automatisch deklariert und den Code erzeugt. Das hat aber seine Grenzen, weil es früher oder später unübersichtlich wird und nicht so gut pflegbar ist. Alles, was langsam genug ist, sollte mit einer flexiblen state machine bedient werden, die den Ablauf von der Generation des Timings trennt, weil sich der Code sonst sehr schnell aufbläht und die Zusammenfassung von Redundanz durch die Synthese zu oxorbtanten Synthesezeiten führt. In der Ablaufsteuerung sitzen dann abstrakte Codes=Befehle, ihrerseits sequenziell abgearbeitet werden und die durch den Einsprung in die states der untergeordneten state machine den Ablauf regeln. Das bläht zwar die Verwaltung auf, führt aber letztlich zu quantitav weniger Code. Es wird quasi in code-Intelligenz investiert und nicht in die Menge. Die Frage ist dann immer, ob man das alles selber implementieren muss, oder ob die Komplexität soviele "Befehle" erfordert, dass man nicht besser auf einen vorgefertigen Softcore zurückgreift. Bei einem einfachen LCD Controller, der nur ein bischen was anzeigt, würde ich es noch in VHDL machen. Aufwändige Init kann man mit einem sequenziell ablaufenden ROM-zugriff erschlagen. Wenn aber ständig unregelmässige Aktualisierungen vorkommen und auch noch unterschiedliche Arten von Anzeigeoptionen (Fliesstext, blinkender Text, Rolltext), verwendet werden, dann wird die Steuerung einfach zu komplex und man muss irgendeine Art von Softcore implementieren. Wenn man über dies noch mit virtuellen Datenstrukturen arbeitet und z.B. String-Verarbeitung braucht, ist ein dedizierter Softcore unerlässlich, weil man dann die Methoden- und Strukturunterstützung in Sachen Variablen der jeweiligen Hochsprache verwenden kann.
J. S. schrieb: > die Enumeration von states, die Abfragen und die Sprünge zu > den nächsten states automatisch deklariert und den Code erzeugt. Wie sieht denn das genau aus? Hast du mal ein Beispiel oder ein Template dafür? Das würde mich echt interessieren, weil ich gerade an einem ähnlichen Problem sitze.
Du machst Dir ein Excel in der vorne die Zeilennummern der Excelzeile, dann die Quell- und die Ziel-states stehen. Mit Zahlen2Text-Konversion kannst Du diese automatisch nummerieren. Oder schreibst die state namen manuell vorne hin und adressierst den ausprung per "=XY". Den gesamten VHDL Konstrukt baust du ein einer Zeile auf. Geht alles mit Textsynthese. dito schrieb: > oder ein Template Mehrere. Die haben aber Zeit gekostet und stellen einen Teil meines Knowhows dar, das ich den Kunden verkaufe :-)
J. S. schrieb: > Du machst Dir ein Excel in der vorne die Zeilennummern der Excelzeile, > dann die Quell- und die Ziel-states stehen. Mit Zahlen2Text-Konversion > kannst Du diese automatisch nummerieren. Oder schreibst die state namen > manuell vorne hin und adressierst den ausprung per "=XY". > > Den gesamten VHDL Konstrukt baust du ein einer Zeile auf. Geht alles mit > Textsynthese. Ja, so ähnlich mache ich das auch. Dachte schon ich wäre damit alleine. Schön zu sehen, dass andere das auch machen ;-) J. S. schrieb: > Mehrere. Die haben aber Zeit gekostet und stellen einen Teil meines > Knowhows dar, das ich den Kunden verkaufe :-) Na gut, dann will da mal nicht weiter nachbohren.
habichvergessen schrieb: > Ist das wirklich soooo schwierig? Was macht es schwieriger? So schwer ist es nicht, außer man versucht es "stur nach Anleitung" wie in einer Programmiersprache, es geht aber auch recht einfach über einen Zustandsautomaten siehe: Beitrag "[VHDL] 16x2 LCD Textcontroller / HD44780" (sehe gerade das Lothar ein ähnlichen Ansatz verfolgt hat). Wichtig dabei ist nur sich klar zu machen, dass "mindestens 40µS" nicht bedeutet dass man nicht auch länger warten könnte.
J. S. schrieb: > Solche Sachen kann man leicht mit Excel machen, das als Codesynthesizer > fungiert und die Enumeration von states, die Abfragen und die Sprünge zu > den nächsten states automatisch deklariert und den Code erzeugt. Excelbasierter Spagetticode Generator? Seriously? Ich hoffe ich muss nie an einem Projekt arbeiten, an dem du vorher gesessen hast ;-)
Klaus schrieb: > Excelbasierter Spagetticode Generator? Seriously? Ich hoffe ich muss nie > an einem Projekt arbeiten, an dem du vorher gesessen hast ;-) Es geht darum, sich in den Fällen, in denen man normale FSMs nutzt, die Tipperei und eventuelle Fehler zu ersparen. Das Einfügen um Umnummerieren von states, geht einfacher und ohne Copy&paste-Fehler. Dasselbe gilt bei rechnenden pipelines mit ihren verzögerten Werten, die zwischengespeichert werden müssen, um sie in Folgetakten zu verarbeiten. Da habe ich in 15 Jahren kein besseres Entwurfsystem gefunden. dito schrieb: > Wenn er die Excel-Datei mitliefert, ist es doch die beste Dokumentation. Eben, die ist aussagefähiger, als das Gewirr von Pfeilen in vielen state diagrammen und eignet sich sehr gut, um die Übersicht zu behalten, weil auf dem ersten Blatt nur die wesentlichen Dinge zu sehen sind, und Code-Konstrukte nicht sichtbar sind.
> Excelbasierter Spagetticode Generator? Seriously
Also ich würde ja auch gern mal ein Beispiel dazu sehen.
Meine States in meinen FSM haben keine Nummern, sondern lesbare Namen.
Und bei rechnenden Pipelines, gibt es zu jedem Wert das passende
enable und es wird erst weitergerechnet, wenn das enable hinten
wieder rauskommt. Da ist es egal ob die Berechnung zwei, drei oder 100
Takte braucht.
Zum Originalposter:
Mit zwei aufeinander aufbauenden FSM läßt sich auch ein Textdisplay
relativ übersichtlich ansteuern. Das ist aber nur bedingt
Einsteigertauglich.
1 | type lowlevel_state_t is (INIT, RESET, RESET2, RESET3, SET_MODE, WAIT_FOR_READY, READY, LCD_COMMAND, LCD_DATA, NIBBLE, LCD_CLEAR, LCD_HOME); |
2 | type state_t is (LOWLEVEL_INIT, SET_DISPLAY, SET_ENTRY, CLEAR, LINE1, NEW_LINE, LINE2, IDLE); |
Duke
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.