also zumindest gibt es solche verbinder, ich weiß nur nicht, wo man sie kaufen kann. hier http://www.simpex.ch/fileadmin/berei...r/kap05_02.pdf auf der 1. seite
Druckbare Version
also zumindest gibt es solche verbinder, ich weiß nur nicht, wo man sie kaufen kann. hier http://www.simpex.ch/fileadmin/berei...r/kap05_02.pdf auf der 1. seite
so, ich melde mich auch mal wieder zum thema. hab heut mal wieder en bisschen mit dem display gearbeitet und mir nen character-generator für den grafikmodus programmiert.
aber ist es nicht möglich grafikmodus und textmodus gleichzeitig zu betreiben?
:-D ist typisch, bevor man schaut, obs einfach auch geht, programmiert man mal drauf los
@Amazz
im Grafikmodus muss man alles selbermalen, dH. wenn Text erscheinen soll braucht man irgendwo das Bitmuster dafür.
Ist aber bei KS0108 auch so, Problem ist nur, das man die Libs zum KS0108 nicht brauchen kann, weil bei diesem LCD der Grafikspeicher im Prinzip um 90 Grad gedreht ist.
ja das ist mir schon klar, dass ich im grafikmodus alles selber machen muss. das hab ich auch gemacht, aber ich hab mir gedacht, dass es vieleicht möglich ist, zwischen den modi zu switchen, sodass ich die characters vom textmodus anzeigen kann und zusätzlich meine eigenen pixel setzen kann
ich hab das bei mir mit dem gemischten modus so gelöst, dass ich die bildschirmdaten im speicher erzeuge und "parallel" die ganze zeit über immer und immer wieder die daten zum display schaufle ... manchmal hat man tearing effekte aber damit kann ich leben, dafür hab ich vektorgrafik und textmodus ..m das mit dem bildern müsst ich auch mal probiern ^^
das klingt schon mal gut, bin grad dabei noch meinen plan B auszuprobieren, wenn der auch scheitert, werd ich deine methode mal anschaun.
grund meiner frage war das langsame "auf und abbauen" meine buchstaben, da ich jeden buchstabe pixel für pixel aufbaue (was auch seinen grund hatte, da ich dadurch "transparent" schreiben kann und zusätzlich meine buchstaben pixelgenau an die stelle bekomm, die ich will)
mein plan b ist jetzt die etwas aufwendigere variante, indem ich erst vom display auslese, welche pixel gerade gesetzt sind und wenn sie in meinem schriftfeld liegen, werden sie miteinbezogen(also entweder gesetzt lassen, oder negieren..). und dann wird byteweise zum display gesendet und nicht mehr bitweise.
mal sehn obs dann schneller geht.
dank euch schonmal!
die idee hatte ich auch, war aber zum scheitern verurteilt ... du musst mind. 2 mal lesen, bevor du gültige daten aus dem display bekommst ... das frisst unmengen zeit, die lösung im speicher zu arbeiten vermindert schonmal die zeit beim "zeichnen" der buchstaben, und wenn ich dann anschliessend immer wieder den speicherinhalt zum display schiebe hab ich sogar noch eine art multitasking ala round robinZitat:
indem ich erst vom display auslese, welche pixel gerade gesetzt sind
while(1) {
input/output();
drawobject();
write_ONE_byte_to_display();
}
wenn ich nur einzelne bytes schreibe kann cih getrost die verzögerung durch das display ignorieren
alternativ kann man auch das ganze display auf einmal rüberschieben, aber dann bekommtm man ne nette verzögerung
stimmt, man mus ja doppelt auslesen.. naja, ich denk aber dass es trotzdem noch schneller ist 3 mal was ans display zu senden (2xstatus +1xschreibbyte) als 8 mal was zu senden (jedes bit).
ich hab die funktion gestern noch net fertig bekommen, werds demnächst machen.
wie kommstn auf sowas ?Zitat:
als 8 mal was zu senden (jedes bit).
ich sende doch nicht jedes bit einzeln ... ich sende pro schleifendurchlauf ein ganzes byte ans display, dann inkrementiert sich im display der adresszeiger und ich meinen im array und im nächsten umlauf ist das nächste bit fällig, bis ich zum nächsten display komme
hab ja auch extra ONE_byte geschrieben und nicht bit oder whole_display XD
ich glaub wir haben aneinander vorbei geredet :-)
ich meinte mit dem "ein bit" die erste variante von mir(also jedes pixel einzeln setzen). ich muss also 8 mal ans display senden, dass es 8 pixel schreibt. in der byte variante wäre es also schneller, da man ja ein komplettes byte (also eine 8-pixel information) sendet. es gibt ja den befehl "set bzw. clear pixel" oder den befehl "write data".
mein eintrag war der vergleich von der ersten und der zweiten variante von mir.
So, ich hab nun mal die methode mit den bytes probiert (buchstaben schreiben im grafikmodus, indem man byteweise pixelsetzt) -> ist nicht erkennbar schneller. in dem fall wird wohl ceos methode die beste sein zumindest vom zeitlichen her. ich hab sie noch nicht getestet, aber das werd ich noch tun, denk ich mal.
Moin Moin
Also ich kann mich hier (leicht zeitverzögert durch Wacken + Urlaub) auch mal wieder zu Wort melden.
Ich arbeite bei meinem Display mit Fonts von http://www.mikrocontroller.net/topic/54860.
Ich wollte auch erst den ganzen Display inhalt im Speicher cachen und dann en block rüberscheiben.
Aber das war mir a) zu langsam (wegen jeder mini Änderung das ganze Display updaten ?) b) zu speicherintensiv und c) kann ich den Display speicher ja byteweise lesen und schreiben.
Weil ich auch 'Transparenz' haben wollte bin ich dazu über gegagen einfach die paar Bytes, die vom Text überdeckt würden, nacheinander auszulesen (d.h. immer nur eins) und dann mit dem Text zu überlagern, geht Problemlos.
Also ich hab keinen Probleme das der Text dann zeilenweise aufgebaut wird oderso.
Also Amazz wenn du ne Anregung brauchst :
http://sebastians-site.de/hg_repos/g...clude/lc7981.c
Guck dir mal lcd_plot_bitmap() an.
So hab ich das gelöst.
Bei mir geht das eigentlich schnell genug.
Obwohl der Code etwas tricky und um die Ecke is.
mfg Sebastian
Hallo,
Ich habe heute auch mein Display erhalten. Leider musste ich ernüchternd feststellen, dass das Display nicht per Bascom angesteuert werden kann. Da ich bisher mit Avr-gcc somit nicht viel zu tun hatte, habe ich nun sogar das Problem, das Display selbst mit vorgefertigtem Code nicht zum laufen zu bringen. Es scheitert an der Compilierung des Codes, angepasst auf einen Atmega8.
Das Problem besteht darin, dass ich beim compilieren der main.c den Fahler bekomme, dass sowohl die Funktion lcd_init und pinguin nicht deklariert sind. Soweit so gut, also geb ich nun bei der Mfile die beiden anderen *.c-Files als C-Source an. Dann wiederum bekomm ich aber den Fehler: no target "main.elf" needed by "main.elf"
Kann mir da jmd weiterhelfen?
meine kristallkugel ist in der reinigung, ich müßt schon das makefile sehen...
Tschuldigung, ganz vergessen =)
bei mir (unter linux) funktioniert das makefile.
allerdings seh ich da drin keine zusätzlichen C-files, ist das wirklich das file, das du verwendest?
cm.
Das erste Mfile war das, bei dem es zu den fehlenden Funktionsdeklarationen kommt. Dieses hier ist dann mit den zusätzlichen c-files.
hmmm... geht bei mir, wenn ich die pfadnamen auf linux umschreibe.
ist das Makefile im selben directory wie die *.c-files? das könnt das eine problem sein.
gibt's bei den LCD-sourcen keine README oder beispiele? möglicherweise hast du in deiner main.c etwas in der art
#include "lcd_graph.h"
vergessen...
Ich habe grade mal versucht anhand des Datenblatts ein kleines Programm in Bascom zu schreiben, um das Display anzusteuern.
Ich habe leider grad das Display nicht zur Hand, aber würde das nach diesem Muster in der Theorie funktionieren?
Code:$regfile "m8def.dat"
$crystal = 1000000
Config Portd = Output
Config Portb = Output
'Init
E = 1
E = 0
Rw = 0
Rs = 1
Portd = 0
Rw = 0
Rs = 0
Portd = 0b00100100
Rw = 0
Rs = 1
Portd = 0x01
Rw = 0
Rs = 0
Portd = 0b10010110
Rw = 0
Rs = 1
Portd = 0x02
Rw = 0
Rs = 0
Portd = 0x16
'(Rw = 0
Rs = 1
Portd = 0x03
')
'(Rw = 0
Rs = 1
Portd = 0x04
')
'Test ausgeben
Rw = 0
Rs = 1
Portd = 0x0c
Rw = 0
Rs = 0
Portd = 0b01010100 'T
Rw = 0
Rs = 1
Portd = 0x0c
Rw = 0
Rs = 0
Portd = 0b01100101 'e
Rw = 0
Rs = 1
Portd = 0x0c
Rw = 0
Rs = 0
Portd = 0b01110011 's
Rw = 0
Rs = 1
Portd = 0x0c
Rw = 0
Rs = 0
Portd = 0b01110100 't
End
Hallo alle zusammen,
ich bin auch recht neu hier und bin mit der C-Control zugange...
(daher ATMEL noob).
Gibt es eigentlich schon eine fertige "Bauanleitung" für das Teil/die Teile?
Oder kann ich meine CC eifach weiterverwenden, da CC ja die weiterentwicklung zur AVR(stelln die nicht die 'FritzBox!' her?) ATMEL ist?!?
Ich hab näcste Woche Geburtstag und evtl. könnt ich mir so'n Teil wünschen.
PS:
Sollte ich noch erwähnen das ich mir die CC Pro182 wünschen wollte?
Zwecks Zimmersteuerung...
Hallo alle zusammen,
habe mir das Display auch bei Pollin bestellt. Das DemoBild mit der Winamp-Trackanzeige war zu verlockend. Nun, 7€ ist ein Schnäppchen für den jenigen der sich damit besser auskennt.
Nun möchte ich dieses GLCD in meinem PC einbauen.
Leider ist in meinem PC keine LPT-Schnittstelle vorhanden. Diese könnte ich mit einer PCI Karte wiederherstellen.
Die Frage ist, wie schließe ich das GLCD an den Parallelport an? Ich möchte über dieses TouchPanel mein laufenden Winamp-Track anzeigen lassen. Eine Ansteuerung bzgl. Play/Pause/Next/.... über die Touchfolie wäre schön, muss aber fürs erste noch nicht vorhanden sein. Ich habe die Folie bereits durchgemessen. Mein Touch Panel schein ok zu sein. Eine Nacharbeitungen an den Kontakten ist daher nicht nötig.
Ich bin für jede sinnvolle Antwort sehr dankbar.
MfG Stefan
Hi,
ich bin auch im Besitz eines Pollin LCD DataVision DG-16080-11, 160x80 und benutze diesen Sourcecode aus dem Dateianhang. Verdrahtet habe ich es wie im Schaltplan (Dateianhang).
Leider kann ich bisher keinen Text ausgeben. Das Display zeigt wirre Streifen oder gar nichts. Dennoch scheint es auf den Controller zu reagieren. Ich habe verschiedene (nicht wirklich sinnvolle) Tests gemacht und gelegentlich sieht man punkte oder streifen.
Ich bin mir nicht ganz sicher wie ich den Sourcecode auf den Schaltplan anpassen muss, da ich BASCOM anfänger bin.
Eine Frage noch. Ist der Quarz (Schaltplan) denn unbedingt nötig, kann ich nicht den internen Takt nehmen. Aktuell habe ich den Quarz nicht eingebaut. Ist der nötig? wenn ja welche Werte sollten der Quarz und die 2 Kondensatoren haben?
Es wäre wunderbar, wenn ich ein Beispielprogramm bekommen könnte, welches mit dem ATMEGA32, diesem Display und der Verdrahtung wie ich Sie bereits gemacht habe funktioniert, denn ich bin mir unschlüssig ob meine Displays auch wirklich OK sind.
Ich danke für Eure Hilfe!!
Gruß
Thomas
Hey,
ich habe das Display zwar noch nicht, wills mir aber demnächst bestellen.
Deswegen habe ich ein wenig herumgesucht und folgende Seite gefunden: http://www.frozeneskimo.com/electron...t-samsung-lcd/
Es müsste eigentlich er richtige Controller sein und Funktionen wie "Pixel(x,y,status)" sind doch wirklich toll. Er hat auch eine Funktion um im Grafikmodus Text zu schreiben.
Dann will ich mal hoffen, dass bei mir der Touch noch funktioniert.
MfG C_Classic
Moin Moin ...
Wenn du das Display noch nicht bestellt hast kann ich dir einen Tipp geben.
Bestell lieber 2 oder 3. Dann hast du, nach dem was ich selber an Erfahrungen gemacht hab und was andere so berichten sicher eins mit funktionierendem Touch dabei.
Ich hab 5 bestellt und bei 3en gehts.
Zum Thema Software kann ich dir noch einen Tipp geben.
(Es ist mir durchaus bewusst dass das jetzt wie Eigenwerbung aussieht, aber irgendwie ist mein Zeug weiter vorne im Thread untergegeangen)
Ich hab mich vor ein paar Monaten mal hingesetzt und mir da selber etwas aus den Fingern gesaugt : http://sebastians-site.de/hg_repos/
Und auch gleich eine Doku getippt.
http://sebastians-site.de/hg_repos/g...lc7981_8c.html
Ich glaube auch das meine Text-Funktion etwas eleganter ist als die von froszeneskimo.
Weil da werden die Buchstaben Pixelweise übertragen, zwei byte pro Pixel, während ich 8 Pixel in 2 byte packe.
(Das wie ist im Source erklärt, hat mich fast 3 Tage Gehirnschmalz gekostet.)
Außerdem hab ich so ein paar gimicks wie automatisches Scrollen im Textmodus gebastelt.
Wär schön wenn du meine lib mal antesten könntest. Ich hatte bisher noch 0 Feedback.
Viel Spaß
Sebastian
Nabend noch mal.
Leider konnte ich mit den bisherigen Beiträgen nichts anfangen.
Ich hoffe mir kann einer Schritt für Schritt dies Display erklären.
Ich habe dieses Diesplay zu Hause liegen. Ich habe Pin 1 - 20 1:1 an einen SubD 25Pol angelötet.
Ich möchte nun gerne wissen, ob ich nun zwischen der SubD 25 Pol Schnittstelle einen Controller benötige, wenn ja, gibt es fertige Module?
Besteht die Möglichkeit, Winamp so anzuzeigen, oder war es von Pollin ein reines Lockangebot?
Hallo Sebastian,
also ich habe deine Files gerade mal runtergeladen und finde keine Makefile darunter. Also habe ich kurzer Hand eine andere heran gezogen und angepasst. Naja okay jedenfalls glaub ich das, denn ich bekomme beim kompilieren leider einen Fehler á la "No rule to make target needed by `main.elf`. Also habe ich das ganze doch noch nicht verstanden.
Ich währe dir sehr dankbar wenn du mich dort beratschlagen kannst.
MfG walkonshit
Moin Moin ....
Ja das fällt mir auch gerade auf.
Irgendwie hab ich mein Makefile verschlampt.
Ich benutze hier eclipse, das genriert automatisch welche, aber die bringen dich net weiter.
Das makefile was du da hast ist ganz schön kompliziert.
Ich denke das geht auch einfacher.
Ich setzt mich morgen mal hin und stricke was schönes.
Früher geht es leider nicht.
Sebastian
Okay ja das ist kein Problem, allerdings bin ich grad seit Stunden auf Fehlersuche, aber sie gehen mir einfach nicht aus!^^ Meine SRC-Paths waren falsch, aber nun erhalte ich vom Linker einen Fehler, der mir sagt, es gäbe eine "undefind reference to lcd_clear".
Wirst du daraus schlau?
walkonshit
Moin Moin
Ja soweit bin ich auch gerade.
Das tolle is mit dem automatischen Makefiles von eclipse gehts irgendwie.
Ich hab heut Mittag ein paar Stunden Zeit.
Also ich kann nur soviel sagen, dass die Funktion definiert ist, und auch die Deklarationen alle zu passen scheinen.
Also muss der linker da irgendwas vergurken.
(Aber was im eclipse irgendwie geht ... strange)
Update :
Ich bin einen Schritt weiter :
Ich deklariere mehrere (kurze) Funktionen die man extern benutzen kann und die auch intern in meiner Lib benutzt werden als inline.
Kostet zwar Speicher bringt aber ziemlich viel speed.
Eigentlich dachte das der Compiler die internen aufrufe inlined und alles was aus main.c c als normalen Funktionsaufruf handelt, weil er da ja keinen code zum inlinen hat (zumindest sah es so aus).
Allerdings stolpert mit dem anderen Makefile der Linker an der Stelle. (Macht ja auch irgendwie Sinn)
Mal sehen wie man das lösen könnte.
Sebastian
Naja dann ist es ja gut, dass ich mich gemeldet habe, damit du jetzt weißt was Sache ist.
Mal am Rande: Hast du für eclipse ein spezielles Plugin für AVR?
Edit: Ich habe jetzt mal in der lc7981.h das inline vor lcd_clear weggemacht, und siehe da der Fehler ist behoben. Allerdings erhalte ich immer noch einen Error Code 2. Das wird aber vermutlich daran liegen, dass der verfügbare Speicher des M8 überlaufen würde.
MfG Marcel
Zu A vr und Eclipse :
http://www.mikrocontroller.net/articles/AVR_Eclipse
Lief hier unter fedora quasi out of the box.
Zum Thema Inline :
Ich hab mich jetzt zum inline/extern/static und alle möglichen Kombinationen mal gründlich eingelesen.
Im laufe des Mittags wer ich eine neue Version soweit fertig haben, dass ich sie mit static inlines läuft und sich sogar linke lässt.
Ich mach dann hier Meldung.
Was deinen M8 angeht solltest du etwas abspecken. Ich hab das ganze auf einem atmega32 rennen.
Z.B den font 12x16_horizontal_LSB_1.h und lcd_plot_text weglassen.
Oder die writing_demo() funktion + Touch.
Sebastian
PS: Danke fürs testen.
///Update 1 :
Ich hab den Code umgeschrieben und lade jetzt die angepasste Version hoch.
Da ich DSL mit Licht hab, kann das etwas dauern.
gerne doch =). Ich bin Wiedereinsteiger in dieser Materie und in diesem Zusammenhang will ich mich von Bascom abwenden und auf C umsteigen, da wir das zur Zeit auch im Studium lernen. Daher biete ich dir hier auch meine Hilfe an, falls du irgendwann mal ein größeres Projekt planst, denn zu Zweit steigt meist die Motivation.
Edit: Habe grade mein Lehrbuch durchstöbert, und habe herraus gefunden, dass deine inline- Funktionen keinen Effekt haben dürften. Laut C-Standart darf ein Compiler selbst entscheiden, ob eine Funktion inline ist oder nicht. Inline Funktion selber müssen aber in einer Quelldatei deklariert und definiert werden. Also wird das eclipse vermutlich selbstständig kaschieren.
MfG Marcel
So upload is fertig.
Die neue Version sollte jetzt problemlos laufen.
Sebastian
nochmal eine andere Frage: Wie rum muss man den Data-Bus verbinden?
laut dem Schema hier im Thread weiter vorne geht PORTD7 auf LCD_Pin7 also DB0 (nachgemessen am LC7981). Was ist nun richtig? PORTD0 -> DB0
oder PORTD0->DB7
Update: Habe es jetzt geschafft das Display anzuschließen an nem M8, bekomme aber nur Wirrwarr in der linken obere Ecke angezeigt. Ich habe den Text "Hallo" um geändert in "Test" und siehe da, anderes Wirrwarr wieder in der selben Ecke. Ich habe grade die Leitungen noch ma auf Fehlanschluss überprüft aber nichts gefunden. =(
MfG Marcel
Moin
Also die ganzen interessanten Pins kannst du bei mir in der lc7981.h ändern.
Normaleiweiße hab ich :
RS auf PA4
RW auf PA2
EN auf PA0
Daten geb ich über PD0-7 aus die mit DB0-7 1:1 verbunden werden.
CS und Res vom Display hängen auf festen Pegeln.
Sebastian
Ja genau PortA existiert beim Atmega8 ja nicht, weshalb ich das auch alles bereits anpassen musste. Aber die Art des Problems weist doch auf ein Fehler der von dir genannten Pins hin, oder? Denn ich habe lediglich eine abweichende Beschaltung bei der Stromversorgung des eigentlichen LCD.
Marcel
Ich hatte selber mal ähnliche Probleme, da waren Datenleitungen verdreht.
D.h. wenn du mal im Thread weiter vorne liest hatte ich auch einmal RS und RW getauscht, sowas passiert schnell.
Vor allem kann man das mit Multimeter nur schwer finden.
Ich war schon drauf und dran mir einen Logic-Analyzer zu leihen.
Und wenn die Reihenfolge der Leitungen zu passen scheint würd ich mal die Pins zählen.
Weil ich lag auch schon mal 1 Pin daneben.
Ich denke Software Probleme kann ich ausschließen.
(Nach Murphys Law recht sich diese Aussage noch.)
Sebastian
Wo du grade Murphy erwähnst...Ich habe grade alle Leitungen sowohl auf Brücken als auch auf falsche Verdrahtung geachtet. Nichts... Ich habe vom IC-Sockel bis zum (!!) LC7981 Chip gemessen um selbst das auszuschließen. ich bin echt am Verzweifeln. Ich häng mal anbei ein Bild meiner Anzeige an.
Ich verwende die 8x8 font.
Bild hier
Edit: AHHH wie geil^^ Murphy hatte recht: Es ist dein Code. Du rufst in der main.c die Funktion lcd_plot_text(5,5,"Hello",16,16,font_8x8) auf. Aber richtig muss es heißen: lcd_plot_text(5,5,"Hello",8,8,font_8x8). Klar, dass er bei falscher Bitmapgröße was anderes ausm Ärmel zaubert.
Ich hoffe ich konnte helfen.
Moin Moin ...
Ne ich bau zwar viel Murks, aber da geht wohl auf deine Kappe.
Meine main.c :
Du hast wahrscheinlich den Font getauscht, ohne die Größe anzupassen. ;-)Code:lcd_plot_text(5,5,"Hello",16,16,font_12x16);
lcd_plot_pgmtext(50,22,PSTR("World"),16,16,font_12x16);
Das das nicht get ist klar.
Siehe Doku
Sebastian
Ja okay entschuldigung, ich wollte dich nicht diskreditieren. Aber in der ersten Version, die du hochgeladen hattest wurde "Hello" mit dem 8x8 Font genauso aufgerufen. Das habe ich schlichtweg so übernommen, da ich es bisher auch nicht verstanden habe, wieso beim 12x16 Font die Größe 16x16 sein sollte^^.
Andere Frage am Rande: Funktioniert bei dir die Funktion lcd_plot_bitmap mit convertierten bitmapbildern? Bei mir entstehen dabei immer drei Teile wovon die beiden äußeren gespiegelt werden.
Vielen Dank für deine Arbeit *daumen hoch*
MfG Marcel