Autor
|
Thema: anschlussfrage reichelt 4*40lcd (Gelesen 41387 mal)
|
Klinkerstein
Gast
|
was für'n Controller hat das denn? Sieht mir aus, als hätte es eine andere Speicher-Ordnung.
|
|
|
|
|
Gespeichert
|
|
|
|
|
|
|
|
OlafSt
Global Moderator
Karma: +13/-0
 Offline
Geschlecht: 
Beiträge: 2138
Master of STLCD and LISA III
|
Das Display hat am PIO einwandfrei funktioniert, wie die Bilder beweisen. Da sich die KS0076 wie HD44780 ansteuern lassen (Hardware-technisch gesehen), stellt auch das kein Problem dar und eine falsche Verdrahtung dürfte sich auch erledigt haben, denn das Display zeigt eine im wesentlichen korrekte Darstellung und keine Hieroglyphen. Auch die Idee, das die UND-Gatter evtl. zu langsam sind, kann ich mir nicht vorstellen - die Dinger können im MHz-Bereich arbeiten (Gatterlaufzeiten von wenigen ns).
Ein Software-Problem in Sachen Ansteuerung des Displays schließe ich auch einmal aus, da es ja bereits am PIO funktionierte und sich diese Routinen nicht verändert haben. Es kann also nur noch daran liegen, das ich in STLCD irgendwie ein Problem mit der Toschaltung habe.
Bestenfalls läuft mir nur ein Bit aus dem Ruder, aber das halte ich für praktisch ausgeschlossen, da ich mit Spunkys Wonderbox und den darauf verarbeiteten roten LEDs die ganze Geschichte bis zur Vergasung getestet habe.
Schlimmstenfalls habe ich durch das Multithreading und den asynchronen USB-Bus ein Timingproblem. In diesem Falle schalte ich auf den zweiten Controller, während der IOW eigentlich noch Befehle für den ersten Controller zu verarbeiten hat. Mir ist nicht bekannt, das der IOW eine Art "Busy"-Flag besitzt, auf das man warten könnte, auch über Chipinterne Prioritäten (I/O geht vor LCD z.B.) ist mir nichts bekannt.
Das das USB-Interface eine Art Warteschlange hat, wäre mir neu. Es ist also möglich, das ich so schnell Befehle zum Warrior sende, das der nicht mehr mitkommt, und ich selbst meine eigenen Befehle "überschreibe". Mangels "Busy" habe ich auch keine Chance, auf den IOW zu warten.
Ist dem so, wäre das eigentlich der Todesstoß für die ganze Geschichte - die Timingprobleme wären abhängig von der CPU-Geschwindigkeit, dem USB-Interface, den USB-Treibern und was weiß ich noch alles. Unmöglich, da was brauchbares hinzubekommen. Eine Idee wäre es aber, die Thread-Priorität wieder etwas herunterzudrehen, um dem IOW etwas mehr Zeit zu verschaffen - was natürlich alle anderen Display-Benutzer "mitbezahlen" müßten, indem das ganze etwas zähflüssiger läuft.
Gebt mir etwas Zeit, damit ich nocheinmal die Ansteuerung der Torschaltung prüfen kann. Sollte es wirklich nicht daran liegen, diskutieren wir nochmal über Prioritäten und deren Einstellbarkeit. Sollte das auch nicht helfen, wird's wohl nix mit Dual-Controller.
Ich möchte darauf hinweisen, das der IOW eigentlich nicht für Duals gedacht ist und die Aktion mit der Toschaltung absolut blanke Theorie ist, genauso wie die Ansteuerung dieser Schaltung. Das ganze ist ein Versuch, der ebenso klappen wie fehlschlagen kann. Bitte nicht haun, wenn letzteres bei herauskommt 
|
|
|
|
|
Gespeichert
|
Erstens: Lies was da steht. Zweitens: Denk drüber nach. Drittens: Dann erst fragen
|
|
|
Falzo
Diktator vom Dienst
Administrator
Karma: +15/-0
Offline
Geschlecht:
Beiträge: 5088
|
wie wärs denn damit ne variante einzubauen, um die geschwindigkeit mit der befehle gesendet werden, manuell auf einen bestimmten meinetwegen von dir schon vorher festgelegten wert zu beschränken? sone art handbremse der datenübertragung per ini-eintrag... kommt natuerlich darauf an, ob deine verarbeitung überhaupt darauf ausgelegt ist, einfach auf blauen dunst und nach jedem gesendeten befehl mal ein paar waitstates zu durchlaufen...
das wuerde aber imho zumindest ne option bringen, das ganze auf schnellen system selber zu bremsen, wenns unbedingt nötig ist.
|
|
|
|
|
Gespeichert
|
|
|
|
|
|
OlafSt
Global Moderator
Karma: +13/-0
Offline
Geschlecht:
Beiträge: 2138
Master of STLCD and LISA III
|
Ah, sieh an... Wieder was dazugelernt. Das erklärt auch die hochspringende CPU-Last von STLCD. Wäre interessant zu fragen, was passiert, wenn die Queue überläuft.
However. Ich hab in STLCD einen weiteren Parameter eingebaut, um die Priorität des Schreibthreads einstellen zu können (Abschnitt [General], Param heißt WPrio, mögliche Werte sind -2,-1,0,1 und 2).
Bei WPrio=-2 (so, wie es bei nem PIO-LCD ist) kann man dem LCD zusehen.
Bei WPrio=-1 sieht das ganze schon akzeptabel aus
WPrio 0,1 (Default beim IOWarrior) und 2 ändern optisch nichts mehr.
Das Testen der Ansteuerung des P0.0 läuft im Moment.
[EDIT] Tests abgeschlossen. Die Ergebnisse:
- Ein Fehler in der Adreßberechnung führte dazu, das das E-Signal nicht zum korrekten Controller durchgeschaltet wurde. Nemon hat also absolut richtig gelegen.
- Erstaunlich, das das ganze mit diesem Fehler überhaupt soweit funktioniert hat, wie ich es hier gesehen habe.
Geänderte Version habe ich ins Netz gestellt, ich bitte um erneute, wohlwollende Tests. Bitte nicht gleich in die Tonne drücken
Und wieder einmal zeigt sich, das "kalte" Einbauen von Funktionen führt zu Problemen. Ic sollte es wirklich mal lernen und in Zukunft lassen 
[/EDIT]
|
|
|
|
« Letzte Änderung: Februar 22, 2004, 15:15:12 von OlafSt »
|
Gespeichert
|
Erstens: Lies was da steht. Zweitens: Denk drüber nach. Drittens: Dann erst fragen
|
|
|
Klinkerstein
Gast
|
Da das zum Thema gehört, möchte ich dich, Olaf, mal bitten hierrein zuschauen.
http://www.stlcd.de/Forum/inde...new;boardseen=1
Es geht um den Dualcontroller + Iowarrior. Es haben schon viele leute nach einem letztendlichen Plan gefragt.
|
|
|
|
|
Gespeichert
|
|
|
|
|
|
|
