[HOT] LCD am AVR-Status und Fragen

Hi Dirk,

eher HOT als HOT. Ich meine natürlich überhaupt nicht half OT.

Siehe diesen thread hier

Bedarf ist also da. Du mußt jetzt nur noch Deinen Text, Rahmen, einen Kreis und ein paar linien zu einer Uhr zusammensetzen und Du machst schon ein paar Leute glücklich.

Na, ja es gehört natürlich etwas mehr dazu. Auf den obigen thread bezogen, bedeutet das, der AVR müßte Uhr spielen solange keine Daten von graphlcd kommen. Dann braucht man noch ein universelles Protokoll zur Datenübertragung vom vdr zum Display.
Als Schnittstelle würde sich USB ganz gut eignen (da ist bestimmt bei jedem noch ein freier Port), aber wie willst Du USB am AVR auswerten? Kenne mich da auch nicht so gut aus, aber ich denke mal rs232 ist einfacher zu programmieren - auf PC- wie auch auf der AVR-Seite.
Vom Kabel her ist seriell unbedingt dem parallel-port vorzuziehen. Vor allem bei einem externen Display (dünneres und längeres Kabel möglich).
Dann könnte man auch noch über die implementierung von anderen Display-controllern nachdenken. Aber das ist noch Zukunft.

Das waren mal so meine Gedanken zu diesem Thema.

Bei dem hw-problem kann ich Dir leider nicht helfen.

Clemens

Grunsätzlich besteht meinerseits schon Interesse an dem source-code. Ich muß mich aber erst in c einarbeiten (bzw. lernen) - irgendwann muß man ja mal anfangen. Das ist dann endlich ein richtiger Grund. Ich denke, über Weihnachten ist da bestimmt mal Zeit. Ich würde dann auch den Treiber für den SED1335 übernehmen.

Zitat

Original von #267
Ack. Vielleicht waere ein USB->RS232-Wandler das richtige? Wie sieht's denn bei den Teilen mit der Geschwindigkeit aus? Wird wahrscheinlich zu knapp, wenns nicht nur Text sein soll.

Die Wandler sind aber nicht gerade sehr billig. Außerdem gibt es für diese Teile extra Treiber für win. Ob es die für linux gibt, weiß ich nicht. Also bleiben wir bei rs232?

zur Geschwindigkeit:
Angenommen, man benutzt ein 256x128'er Display. Das macht für einen kompletten Bildschirmaufbau 4kB Daten. 115kBit/s entsprechen ca 12kB/s. Das heißt, man kann 3x pro sec einen kompletten screen-refresh machen. Würde für den Anfang ausreichen. Man kann später natürlich drüber nachdenken, ob man nur die Teile des screens refresht, die sich ändern.

kannst Du mir bitte mal den source-code, den Du schon hast, zukommen lassen?

Danke,
Clemens

Hi,

seriell wäre sicher die einfachste Lösung, aber:

Gerade im Bereich der sogenannten Legacy Ports (Ser, par, ..) ist die Tendenz doch so, das diese Ports früher oder später nicht mehr auf den Boards zu finden sein werden. Im Grunde hat man heute doch schon Probleme wenn man mal ein MicroATX Board kauft....die haben meist nur noch einen Com-Port, dafür aber zum Glück IRDA onBoard.

Meiner Meinug nach wäre USB die beste Lösung für die Zukunft, da man davon doch eine reichliche Anzahl Ports auf jedem aktuellen Board geboten bekommt, incl. interner Ports.

Meine zweite Wahl wäre der IRDA-Port....das sollte machbar sein wenn man ein wenig im RCU-Code von Klaus "spickt". Allerdings gibts leider auch hier Probleme: Die Unterschiedlichen IR-Standarts....FIR, SIR, CIR....und die dann noch in verschiedenen Konfigurationen. Meist werden diese nämlich nicht über das Bios konfiguriert, sondern müssen über einen Treiber realisiert werden um die Register in den I/O-Chips für den "richtigen" Mode zu setzen. Hab ich selbst gestern erst erlebt als mein RCU am neuen Board nicht lief....

Andy

Moin,

USB wär' schon schön...
Das müsste eigentlich auch mit der USB-Implementation für einen AVR (Igor-Plug)
zu schaffen sein (http://www.cesko.host.sk/IgorPlugUSB/IgorPlug-USB%20(AVR)_eng.htm)
Mit einem At90S2313 für 2,50 EUR sollten damit bis zu 8 KByte/s möglich sein (wenn ich mich nicht irre)

Gruß
Stefan

Zitat

Original von DXR3chef
USB wär' schon schön...
Das müsste eigentlich auch mit der USB-Implementation für einen AVR (Igor-Plug)
zu schaffen sein (http://www.cesko.host.sk/IgorPlugUSB/IgorPlug-USB%20(AVR)_eng.htm)
Mit einem At90S2313 für 2,50 EUR sollten damit bis zu 8 KByte/s möglich sein (wenn ich mich nicht irre)

das gefällt mir auch. hier nochmal der korrekte link.
würde auch helfen Kosten zu sparen. Wenn man einen mega-controller nimmt, dann könnte man die Ansteuerung des Displays vielleicht gleich mit integrieren.
Bräuhte man nur noch einen entsprechenden Treiber für Linux. Der für Windows wird ja mitgeliefert.

Zitat

Original von #267
Aber auch mit dem 1kB Daten wird's knapp beim ATMega16 (exakt 1K Ram). Ich muss mir ohnehin mal anschauen, wie das GraphLCD-Plugin das Ding ansteuert -- vielleicht laesst sich der Text ja vordefinieren und spart dann Speicherplatz. Ist halt alles noch ganz am Anfang.

Die Daten kann man doch gleich direkt ins RAM vom Display schreiben. Warum das des controllers verschwenden? Mein controller mit dem SED1335 hat sogar soviel RAM, daß der komplette Bildschirminhalt mehrfach abgelegt werden kann. Der SED1335 bietet die Möglichkeit, diese Bereiche umzuschalten. Da kann man 'in aller Ruhe' ein Bild aufbauen, und wenn das fertig ist, einfach Umschalten.

Zitat

Original von #267
Der Quelltext besteht momentan eigentlich nur aus den Libs der avr-lib und einer kleinen Demo-Funktion. Ich lade ihn heute Abend von zu Hause aus hoch.

Ich freu mich schon drauf.

Clemens

Zitat

Original von #267
Ja, das klingt verlockend. Es gibt da auch noch ein Projekt namens avrusb, liegt/lag bei Savannah

Hoffentlich sind die bald wieder auf der Leitung.

vielleicht hat's einer, der hier mitliest und kann es zur Verfügung stellen. So wie ich rausgefunden habe, ist das direkt für linux. das wäre natürlich ideal.

Clemens

Moin,

sorry für den falschen Link, aber ihr habt es ja trotzdem gefunden.
Soweit ich das verstanden habe, soll das Projekt AVRUSB auf Savannah einen Linux-USB Treiber für das Igor AVR-Projekt entwickeln.
Leider scheint da aber im Moment nicht viel los zu sein.
Ich habe mal den IgorPlug mit einem AT90S2313 realisiert. Das funktioniert tatsächlich, aber die verbleibenden Resourcen sind dann schon stark dezimiert. Die Ansteuerung des Displays sollte sich also auf das Notwendigste beschränken (Keine Kreis- oder sonstwie Algorithmen auf dem AVR).
Wenn man als Grundlage für einen AVR-Linux-USB-Treiber den vom Linux-System mitgelieferten USB-Skeleton-Treiber verwendet, dann sollte man auch relativ schnell was auf die Beine bekommen können.

Gruß
Stefan.

Zitat

Original von #267
so, es geht weiter. Nach Einbindung anderer Libs (von Gregor Horvat) und einigen Hardware-Saeuberungen ist das AVR-GLCD bereit. Neue Funktionen sind fast fertig, dazu noch ein paar Fragen an GLCD-Insider (Sibbi?):

schön, das es weitergeht!

Zitat

Original von #267
- Hat jemand sinnvolle Ideen fuer ein einfaches Protokoll via UART? Mein Vorschlag:

also doch erstmal rs232? Habe damit jetzt auch mal ein wenig experimentiert: mein 16x2 Dotmatrix-Display kann ich jetzt über die serielle ansteuern. Zwar sehr rudimentär, aber es funktioniert! Und immerhin mit 19200 Baud. Für höhere Baudraten brauche ich noch einen anderen Quartz als den 4,000000 MHz.
Bei der glatten Frequenz wird der Fehler zu hoch.

Zitat

Original von #267
Die Trennung von Commands und Data halte ich fuer notwendig, um laengere
Strings uebergeben zu koennen. Das duerfen dann fuer vordefinierte
5x7-Schriften ASCII-Zeichen sein, ansonsten wird die Zeile byteweise
vollgeschrieben. Der Protokolloverhead sollte sich bei laengeren Strings
auch in Grenzen halten.

Ich halte es für sinnvoll, wenn man sich an einem Protokoll orientiert, was bei komerziellen seriellen Displays benutzt wird. Auch wenn diese sehr teuer sind, hat man immerhin dann die Möglichkeit, eines anzuschließen. Habe mir dazu mal dieses Datenblatt angesehen. Man muß ja nicht den kompletten Befehlssatz nachbilden. Esreicht ja aus, die wichtigen Sachen zu übernehmen.
Interessannt finde ich auch die Baragraphen-Funktion und die zum 'uploaden' von images.

Wenn (Deine) meine Vermutung stimmt, dann wird das Bild vom jetzigen glcd-plugin ja mit - einfach ausgedrückt - kompletten screen-refresh's aufgebaut.
Das umzusetzen, wäre jetzt erstmal der einfachere Weg. Wenn man aber die Möglichkeit einbaut, Zeichensätze zu verwenden, dann könnte man die Datenmenge, welche über die Schnittstelle muß, erheblich verringern. Ist natürlich aufwändiger zu programmieren.
Ich würde die zweite Variante bevorzugen. Dann bleibt auch noch etwas Luft auf der Datenleitung für andere Sachen, wie z.B. lirc undwasweißichwasunsonstnochsoeinfällt

Zitat

Original von #267
Auf Kommentare wartend,

Dirk

hier mal mein Kommentar, damit Du nicht so lange warten mußt.

Clemens

so,

nachdem ich mich jetzt erstmal ein bischen C gelernt habe, hier meine bisherigen Ergebnisse:

kann jetzt mit dem AVR mein Display mit einem SED1335-controller initialisieren, Pixel setzen und Text ausgeben. Will aber nicht verschweigen, daß der Text nur mit dem integrierten Zeichensatz funktioniert und nicht besonders schön aussieht (geht ja erstmal nur ums Prinzip).

So wie ich gesehen habe, benutzt das glcd-plugin sowieso nur die 'Refresh'-Funktion, um das Display zu beschreiben.

Im Klartext heißt das,

Man müßte z.B. den hd61830.c-Treiber so umschreiben, daß die Daten auf der seriellen Schnittstelle ausgegeben werden. Das Display selber braucht nur zwei Kommandos verstehen:
-Display-Adresse setzen (Grafik-Speicher)
-Daten-Byte(s) an die entsprechende Stelle(n) schreiben

Über die refresh-Funktion wird dann entweder nur der Teil des Displays beschrieben, der sich verändert hat und in bestimmten Abständen wird der komplette screen neu geschrieben. Das macht aber schon das Plugin. Somit wird die Datenrate auch gering gehalten.

Das Protokoll kann man so machen wie Du schon vorgeschlagen hast, Dirk.
Man muß zwischen Kommandos und Daten unterscheiden. Das geht nur sicher mit einem speziellen Bit. Dann bleiben aber effektiv nur 7 Bit für Daten übrig. Da es sich aber um binär-Daten handelt, müssen diese noch z.B. mit mime kodiert und im AVR wieder dekodiert werden.

Dirk,
Bist Du schon etwas weiter gekommen?

Clemens

Moin,

wenn ich mich mal einklinken dürfte.

Ich würde vorschlagen ein etwas abstrakteres Protokoll zu verwenden.
(Im Sinne von DrawBar, DrawRoundedBar, DrawCircle, etc...)
Diese Befehle müssten dann vom AVR "gezeichnet" werden.
Das würde die erforderliche Datenmenge erheblich reduzieren....

Was meint Ihr?

Cu UloPe

Auch Moin,

das setzt dann aber voraus, dass das darzustellende Bild auch in selbigem Format, also nicht als Bitmap, vorliegt.
Weiterhin muss dann der AVR schon ein bisschen mehr Power und Resourcen haben um auch wirklich einen Vorteil zu bringen.

Ich finde den derzeitigen Ansatz gar nicht so verkehrt und das passt auch ganz gut zum GraphLCD-plugin.
Ich denke ja immer noch über den AT90S2313 als Low-Cost USB-Controller nach. Der hätte neben USB immer noch genügend IO-Leitungen, um einen SED1335 anzusteuern.

Gruß
Stefan

Zitat

Original von UloPe
wenn ich mich mal einklinken dürfte.

gerne! - ich hab schon gedacht, es gibt keine Interessenten für dieses Projekt. Vielleicht sollte man mal ein neues Topic mit einem etwas bezeichnenderen Titel aufmachen.

Zitat

Original von UloPe
Ich würde vorschlagen ein etwas abstrakteres Protokoll zu verwenden.
(Im Sinne von DrawBar, DrawRoundedBar, DrawCircle, etc...)
Diese Befehle müssten dann vom AVR "gezeichnet" werden.
Das würde die erforderliche Datenmenge erheblich reduzieren....

Was meint Ihr?

das wäre für den AVR nicht wirklich das Problem. Linien, Rechtecke und Kreise funtionieren schon. Ein spezieller Zeichensatz ist in Planung.
In dem glcd Plugin müßten dann aber grundsätzliche und etwas aufwendigere Änderungen gemacht werden.
Dazu müßte man mal wissen, wieviele Interessenten es gibt.

Ein einfaches kopieren des kompletten screens ist da wesentlich einfacher zu realisieren, da dieser schon als bitmap vorliegt. Wenn das dann funtioniert kann man immer noch über eine Erweiterung des Befehlssatzes nachdenken.

Clemens