Da ich immer wieder auf einen grafikfähigen LCD Controller für
controllerlose 320x240 Displays angesprochen werde, habe ich meinen
alten auf der 640x480 Version
(Beitrag "LCD Controller für 640x480 LCD mit mega8515") basierten Controller
etwas aufgepeppt und mit neuen Features versehen:
- Einfache Schaltung aus nur wenigen Standardbauteilen
- Grafikmodus mit 4 Graustufen
- Textmodus mit 8x12 Zeichensatz, der Text in Grafik umwandelt
- Funktionen für Pixel, Linien, Rechtecke, Bilder usw
- Ansteuerung über UART (Standard: 19200 Baud), daher ideal als Display
in einer µC Schaltung verwendbar. Die Grafikfunktionen entlasten dabei
den anderen µC.
- Die LCD Routinen sind in Assembler geschrieben (für beste Ausnutzung
der Rechenleistung), Ansteuerung und Kommunikation dagegen in C, daher
leicht ist das ganze leicht erweiterbar.
Ich hatte schon die ganze zeit vor deinen großen Controller auf die
displays umzumünzen, bin aber noch nicht dazu gekommen, naja jetzt hast
du das ja gemacht, prima :D
@Benedikt,
ich konnte in deiner Schnittstellenbeschreibung die Schnittstelle zum
Kreise zeichnen nicht finden.
Eine Frage dabei zur Umsetzung, bietet sie nur gefüllte Kreise, wie im
Bild, oder ist es möglich die Randdicke zu Variieren?
Gruß,
Dennis
Dennis S. wrote:
> ich konnte in deiner Schnittstellenbeschreibung die Schnittstelle zum> Kreise zeichnen nicht finden.
Gibt es auch nicht. Ich hatte zwar erst dran gedacht, aber dann doch
sein lassen, da Kreis im Vergleich zu Rechtecken doch eher selten
vorkommen. Bei der nächsten Version ist das aber drin.
Wo wir schon dabei sind: Kennt jemand eine Füllfunktion die auch auf dem
AVR einigermaßen schnell läuft ? Floodfill scheitert schon alleine am
Stack.
in inrgend einer lib wurde das so gelöst:
man errechnet zwei auf gleicher höhe liegende Kreiskoordinaten und
zeichnet von der einen koordinate zur anderen eine linie, das macht man
für alle punkte, fertig ist der gefüllte kreis.
Oder du machst es so: vom mittelpunkt ausgehen gehst du in y richtung
nach oben bis du auf ein gleichfarbiges Pixel (rand) triffst, das gleich
einmal nach unten.
Dann erhöhsat du x um eine und wiederholst das solange bis du in x
richtung auf ein gleichfarbiges pixel triffst.
dann nochmal vom mittelpunkt aus nach links und fertig
Problem ist nru wenn andere objekte "im Weg" sind wird nicht der ganze
kreis gefüllt. Man könnte natürlich auch einfach die koordinaten des
Kreisrandes speichern oder das beim zeichnen miterledigen volgendermaßen
vieleicht:
Ich geh jezt mal davon aus das du immer Viertelkreise zeichnest.
1
mx=mittelpunktX
2
my=mittelpunktY
3
4
x=mx
5
oldx=x-1
6
y=my+radius
7
while(x<mx+radius){
8
9
drawPixel(x,y)//rand zeichnen
10
if(x!=oldx){//x != alter postion, sonst haben wir schon gemalt!
11
oldy=y//y sichern
12
while(y>my){//sind wir schon am mittelpunkt?
13
y--;//nach unten gehen
14
drawPixel(x,y)//pixel zeichnen
15
}
16
y=oldy//y wieder herstellen
17
}
18
oldx=x//altes x speichern um "doppelmalen" zu verhindern falls
19
//sich x in dieser iteration nicht ändert
20
x=newXKoord(x)//neue X berechnen
21
y=newYKoord(y)//neue Y berechnen
22
}
Jezt natürlich ungetestet aber das könnte so gehen, es werden halt immer
streifen vom Rand runter bis zum mittelpunkt gezeichnet.
Muß man jezt halt nocheinmal spiegeln für die 4 Quadranten.
Mir ist jetzt noch nicht ganz klar welcher RAM
verwendet wird. Alle anderen Bausteine sind ja bezeichnet ;-).
Gibt es da einen Standard Reichelt Typ ?
Gruß Sven
Als SRAM findet irgendein schneller 32k x 8 SRAM mit 10-35ns Verwendung.
Sowas hat Reichelt nicht.
Daher kann man in der lcd.c den RAM Zugriff ausbremsen. Dann kann man
auch langsamere mit bis zu 90ns verwenden. Das wäre dann z.B. 62256-80
von Reichelt.
Ich hätte da mal eine Frage aus reinem Interesse:
Warum die etwas unorthodoxe Einblendung des externen Speichers in den
Adressraum des AVR (A0 vom externen Interface wird nicht verwendet)?
Hat das Vorteile beim Auslesen des RAM für den LCD-Datenstrom?
Sven wrote:
> Ok, danke. Dann würde dieser hier passen :
Ja, der sollte funktionieren.
Stefan Ernst wrote:
> Ich hätte da mal eine Frage aus reinem Interesse:> Warum die etwas unorthodoxe Einblendung des externen Speichers in den> Adressraum des AVR (A0 vom externen Interface wird nicht verwendet)?> Hat das Vorteile beim Auslesen des RAM für den LCD-Datenstrom?
Ja. Damit das ganze schneller geht, teile ich den 16bit Adresspointer in
256 Zeilen und 256 Spalten auf, genau passend für das LCD.
Ich lese für das LCD 80 Bytes aus. Da das LCD nur 4bit hat, reicht ein
Speicherbyte für 2 Datenpakete zum LCD, daher der Multiplexer und daher
ist A0 nicht beschaltet.
Benedikt K. wrote:
> Ich lese für das LCD 80 Bytes aus. Da das LCD nur 4bit hat, reicht ein> Speicherbyte für 2 Datenpakete zum LCD, daher der Multiplexer und daher> ist A0 nicht beschaltet.
Ah, ich hatte übersehen, dass der Multiplexer am Ausgang durch das
RD-Signal getoggelt wird. ;-)
Danke!
@Benedikt K.
noch mal zu Deiner Schaltung:
von IC1/PD4 kommt FLM/ AC
von IC6A/Pin5 kommt M/Frame.
sonst war FLM=Frame
und M=AC
Frame wird ja wohl gebraucht, welcher Pin wäre denn richtig?
Wigbert
Du hast recht, da habe ich wohl beim Verschieben der Pins nur ein Teil
der Bezeichnung mitverschoben.
Hier iste die Beschreibung mit dem korrigierten Schaltplan.
Hi Benedikt,
hab ein kleines Ausgabeproblem.
Anbei mal Dein "Titelbild"
Sieht so aus , als wenn der Text nicht aus der richtigen "Ablage"
"gemalt" wird.
Hab die Verdrahtung noch mal geprüft, laut DBL soll der mega 8515 nur
12 bis 22pF am Quarz haben, hab ich 15 statt deiner 27 drin.
Reset hat noch 10K an 5V+
Auf Befehle über RXD gehorcht die Schaltung Bedingungslos bei
19K2 .
als Speicher hab ich ein W24M257AK-15 ( hab ein paar ausprobiert) drin.
Fusebits des mega8515: CKOPT programmed(>8Mhz) rest unprogrammed.
habe beide Code (mit und ohne Kreis) ausprobiert.
Dank Dir mal schon.
Wigbert
Hast du die Verdrahtung genauso wie im Schaltplan, oder hast du bei den
Datenleitungen etwas verändert ?
Wenn du Pin 1 vom HC157 an Q statt an Q\ anschließt, dann sollte es
passen.
ich hab den Pin1 vom HC157 an Pin9(Q)des HC74 angeschlossen (geändert)
zw. Pin8 u.Pin12 habe ich die Brücke des HC74 gelassen.
Der Rest ist alles nach Deinem Schaltplan. Nur ISP-Buchse hab ich
zusätzlich drauf.
Wigbert
Hi
Die Schaltung im Beitrag bezieht sich ja auf die Displays von Pollin.
Best.-Nr.: 120 460 und 120 471
Ich habe das von Sharp (120 318). Kann ich das auch verwenden? Nur die
Spannungen für das Display müsste ich da selbst erzeugen. Liege ich da
richtig? Und müsste ich da im Programm etwas verändern?
Ich häng das Datenblatt gleich mit an!
Jens wrote:
> Ich habe das von Sharp (120 318). Kann ich das auch verwenden?
Ja.
> Nur die> Spannungen für das Display müsste ich da selbst erzeugen. Liege ich da> richtig?
Ja, ich mache das so wie bei dem Link den Andreas gepostet hat.
Und müsste ich da im Programm etwas verändern?
Nein.
Nur aufpassen, dass da das Display mit 3,3V läuft. Also den Pegelwandler
nicht vergessen.
> Ich häng das Datenblatt gleich mit an!
Datenblatt würde ich das nicht nennen. Irgendwo hier im Forum fliegt
auch das richtige Datenblatt von Sharp rum, ich habs jetzt gerade nicht
gefunden. Aber da es ein Standard 320x240 TFT ist, ist das Datenblatt
sowiso eher uninteressant (abgesehen von der Pinbelegung).
Wenn's geht - ok. Im Datasheet von dem Teil steht halt 3.0-3,6V drin.
Allerdings mit einem absoluten Maximum von immerhin doch 6V, also wohl
nicht im Sinne des Erfinders, aber vielleicht machbar.
Aber: Bloss weil Pollin das reinschreibt, wird da kein Naturgesetz
draus.
Jens wrote:
> Warum 3,3V für das Display?
Wie Andreas schrieb: Sharp garantiert nur 3,3V. Es mag bei 5V gehen, ist
aber außerhalb der Specs.
> Laut Schaltplan von Pollin betreiben die das LCD mit 5V und nur das FPGA mit
3,3V.
Wichtigste Merkregel bei Pollin: Nie deren Angaben vertrauen, da ist
einiges falsch. Immer das orginal Datenblatt verwenden.
Wo liegt eigentlich der Unterschied zwischen den Displays von Pollin mit
den Nummern 120 460 und 120 471??? Hat nur der Rahmen ne andere Farbe
oder wie?
Hab das zweite noch nicht ausprobiert, aber von der Bezeichnung her
(NANYA hat da ein System drinne) ist das erste hell auf dunklem
Hintergrund, das zweite andersrum. Und das erste geht garnicht ohne
Hintergrundbeleuchtung (transmissive), das zweite kann sowohl mit wie
ohne (transflexive).
ChrisLiebig wrote:
> Wo liegt eigentlich der Unterschied zwischen den Displays von Pollin mit> den Nummern 120 460 und 120 471??? Hat nur der Rahmen ne andere Farbe> oder wie?
120 460 ist das hier:
http://www.mikrocontroller.net/attachment/34396/320240_lcd_4bpp_sch.jpg
und 120 470 ist das:
http://www.mikrocontroller.net/attachment/36571/GLCD.JPG
Das erste hat meiner Meinung nach einen leicht besseren Kontrast, dafür
sieht man (wie Andreas schon wieder vor mir schrieb) garnichts ohne
Backlight. Das zweite ist dagegen auch ohne Backlight bei ausreichend
vorhandenem Licht ablesbar.
Wie kann ich die 23V für die Hintergrundbeleuchtung erzeugen? Bin grade
auf der Suche nach der IC-Lösung möglichst ohne viel äußere Beschaltung.
Wieviel Strom benötigt denn das Backlight?
Und wenn du nicht nur 5V, sondern auch irgendwas ab 6-7V zur Verfügung
hast, darf ungeregelt sein, dann wird es etwas einfacher:
Beitrag "Re: Grafik-LCD Controller mit AVR und VRAM". Die Drossel darin
gibt's übrigens netterweise auch bei Pollin.
Ob der Optokoppler zur Schaltung der Spannung wirklich nötig ist weiss
ich nicht. Laut Datasheet soll die Spannung erst später eingeschaltet
werden, zusammen mit DISP_OFF, also ist es sicherer so. Aber wenn
DISP_OFF die Spannung im LCD sowieso schaltet, wär's ja egal.
In Beitrag "Re: Grafik-LCD Controller mit AVR und VRAM" habe ich den
Wandler mal auf 10mA minimiert und das Kontrastpoti aus dem Wandler
ausgelagert, ist aber so noch nicht getestet. Auch hier gibt's die Spule
bei Pollin.
Strom für Vee ist laut Datasheet von dem Typ mit dunklem Hintergrund
übrigens 3,4mA.
Danke für eure schnellen Antworten.
Leider habe ich nur die 5V zur Verfügung. Ich blicke in dem ganzen
riesen Topic nicht mehr so recht durch, kann mir einer mal die richtige
Schaltung zeigen, wie ich aus den 5V die -22V rauskriege?
Achso nochwas, was fürn SRAM kann ich da nehmen, ich brauche ja was mit
ca. 20ns Zugriffszeit. Hat da jemand nen Beispiel für nen 5V Typ?
ChrisLiebig wrote:
> Leider habe ich nur die 5V zur Verfügung.
Du solltest den CCFL Inverter für die Hintergrundbeleuchtung nicht
ausser Acht lassen. Es sei denn du willst die transflexive Version und
nur bei genug Fremdbeleuchtung verwenden.
Der Inverter von Pollin ist nämlich ein 12V Typ, zu finden als
Kaltlichtkathode für's PC Modding. Daher lag diese Variante der
Spannungserzeugung nahe. Benedikt musste etwas mehr Aufwand treiben, da
man mit dem MC34063A ohne Hilfstransistor aus 5V keine 23V zaubern kann.
> riesen Topic nicht mehr so recht durch, kann mir einer mal die richtige> Schaltung zeigen, wie ich aus den 5V die -22V rauskriege?
Siehe Links oben, such in den Schaltbildern nach dem MC34063A.
> Achso nochwas, was fürn SRAM kann ich da nehmen, ich brauche ja was mit> ca. 20ns Zugriffszeit. Hat da jemand nen Beispiel für nen 5V Typ?
Beispielsweise gesockelte Cache-RAMs aus alten PCs der 486- und der
ersten Pentium-Generation. Gibt's wohl auch bei Segor. Sind aber
ziemliche Schluckspechte, was zu heftigen Transienten auf der
Stromversorgung führen kann. Kondensator nicht vergessen, und kurze
saubere VCC/GND-Führung.
Ok, die Schaltung ist also nur für die Display-Spannung, oder? Ich werde
die jetzt so erzeugen wie in Benedikts Schaltung ganz oben. Und wie wir
die Spannung für die Hintergrungbeleuchtung erzeugt? Verstehe ich das
jetzt richtig, dass der Schaltregler in Benedikts Schaltung nur für die
Displayspannung ist?
ChrisLiebig wrote:
> Wie kann ich die 23V für die Hintergrundbeleuchtung erzeugen?
Die +23V von Pollin sind erstens keine +23V, sondern eher -18V (typisch
Pollin halt: Schnell was zusammengegoogelt, nichts verstanden und falsch
in die Beschreibung gepackt. Das ist genau das was ich hier geschrieben
habe: Beitrag "Re: Grafikfähiger LCD Controller für 320x240 LCD mit 4 Graustufen"), und die sind
nicht für die Beleuchtung sondern für das Display selbst.
> Und wie wir> die Spannung für die Hintergrungbeleuchtung erzeugt? Verstehe ich das> jetzt richtig, dass der Schaltregler in Benedikts Schaltung nur für die> Displayspannung ist?
Ja. Die Hintergrundbeleuchtung benötigt einen CCFL Inverter.
Ja, die -23V sind nur für's Display selbst.
Die Hintergrundbeleuchtung braucht so 400-800V, das baut man sich nicht
selbst sondern kauft fertige sogenannte Inverter. Sind im Umfeld vom
PC-Modding leicht erhältlich, arbeiten aber meist mit 12V.
Benedikt K. wrote:
> Die +23V von Pollin sind erstens keine +23V, sondern eher -18V
Aber arg temperaturabhängig. Bei -20°C sind es laut Datasheet -20V, bei
+50°C -16,5V. Weshalb die Spannungseinstellung im produktiven Einsatz
dem Anwender zugänglich sein sollte. Ein Poti direkt im Wandler ist
dafür u.U. ungeeignet, weil man das da nicht rausoperieren darf. Geht
also wie im Datasheet und meiner 10mA-Version gezeigt beispielsweise mit
separatem Poti+Transistor, oder wie bei dir per PWM (bloss: wie stellt
das dann der Anwender ein, wenn er doch nix sieht?).
Benedikt K. wrote:
> Die +23V von Pollin sind erstens keine +23V,
Wenn man das vom Hersteller vorgesehene Kontrastpoti mit dem Transistor
einrechnet, sind 0,6V weg, und nochmal ~1V wenn man den Kram per
Darlington-Optokoppler schaltet (nicht jeder hat sich rechtzeitig mit
Photo-MOS-Relais eingedeckt ;-). Sind zwar immer noch keine -23V, aber
ganz so dämlich ist der Wert dann auch wieder nicht. Im Datasheet vom
'159 Display sind es übrigens -22V.
@Benedikt
Nochmal zu dem Sharp-LCD (obwohl ich weiß, das das nicht hier her
gehört)
In dem Beitrag sind folgende Signale auf den Stecker geführt:
LP, D0-D3, XCK, M, Yd, DISP, +Versorgung(das ist klar)
Was gehört denn da zusammen, wenn ich diese Schaltung hier verwenden
will. Die Signale sind hier anders benannt und das bringt mich etwas
durcheinander.
Danke für die Hilfe!
hallo,
habe mir den Grafik-controller nachgebaut, allerdings sind solche lücken
wie bei Wigbert zusehen
Pin1 vom HC157 an Pin9 des HC74
als sram habe ich den von reichelt 62256-80
vielleicht könnte mir jemand einen tipp geben
mfg
Mit welcher Bildwiederholfrequenz wird das eigentlich betrieben?
80(320/4) x 244 x 70Hz = 1,36MHZ bei max.16 MIPS = ca. 12 Befehle
zwischen den PixelClocks ???
Oder hab ich da falsch gerechnet?
Die Framerate ist in der param.h einstellbar. Momentan ist 85Hz
eingestellt. Pro 4 Pixel werden etwa 3 Takte benötig, daher bleibt noch
etwas Rechenleistung für andere Aufgaben übrig.
hallo,
hier nochmal ein foto ,von der ausgabe
jedes ic hat ein 100nf abblock kondensator
alle lötpunkte sind verlötet
vielleicht hat einer noch ein tipp
mfg
kay
Sieht nach einem Kurzschluss gegen Masse auf einer Datenleitung oder
einer unterbrochenen Datenleitung aus. Da der Abstand 8 Pixel beträgt,
muss der Fehler irgendwo im Bereich AVR, SRAM, Eingang Multiplexer
liegen.
hallo,
so es war eine kalte lötstelle am multiplexer,
danke für die hilfe.
nur der uart macht noch einpaar sorgenm der mc restet sich ab und zu und
die cts led blinkt manchmal auf
mfg
kay wrote:
> nur der uart macht noch einpaar sorgenm der mc restet sich ab und zu und> die cts led blinkt manchmal auf
Du sendest vermutlich zu schnell die Daten. Sobald der Empfangspuffer
überläuft kommt einiges durcheinander. Eigentlich sollten zwar die
meisten Fehler abgefangen werden, aber es kann dennoch sein, dass
irgendwo was durchkommt und dann Mist macht.
hallo,
wenn ich ein rechteck zeichnen will
dann bekomme ich nur wirre zeuchen angezeigt baudrate ist 19200
zb.
29;für rechteck
50;x1
50;y1
139;x2
139;y2
0; füllfarbe
255; rahmenfarbe
ist das denn so richtig
mfg
kay
wäre es so richtig,
29;für rechteck
50;
25;
139;
89;
0; füllfarbe
255; rahmenfarbe
oder wäre es möglich ein kleines beispiel wies richtig gemacht wird
zb ein rechteck
mfg
kay
Ich hab die Schaltung von Benedikt K. noch nicht nachgebaut, hätte aber
jetzt schon eine Frage:
Wieso gibt es zwei unterschiedliche Schaltplanvarianten (1mal nach
Benedikt und 1 mal nach Wigbert ). Damit meine ich die Pins 9 Q und 8/Q
des Flipflops die auf zwei Arten an den Multiplexer angeschlossen
werden. Hängt doch sicherlich vom verwendeten Display ab, stimmts?
Eventuell kann man das kurz und knapp erklären und in die .ZIP Datei
aufnehmen?
Gruß Alex
hallo,
>Ich hab die Schaltung von Benedikt K. noch nicht nachgebaut, hätte aber>jetzt schon eine Frage:>>Wieso gibt es zwei unterschiedliche Schaltplanvarianten (1mal nach>Benedikt und 1 mal nach Wigbert ). Damit meine ich die Pins 9 Q und 8/Q>des Flipflops die auf zwei Arten an den Multiplexer angeschlossen>werden.
Pin1 vom HC157 an Pin9 des HC74
am hc74 pin8 und pin12 verbinden
so funktionierts
hatte Wigbert ja auch so geschrieben da sonst pixelfehler auftreten
>Hängt doch sicherlich vom verwendeten Display ab, stimmts?>Eventuell kann man das kurz und knapp erklären und in die .ZIP Datei>aufnehmen?
NEIN
ich habs mir auch mehrfach nachgebaut und funktioniert
mfg
kay
hallo,
um ein bild zuladen gibs ja den befehl 16
aber wie wird das korrekt eingegeben
16
0xAA
X=10
Y=50
XS
YS
255
mein bild liegt in einer tabelle,
für eine kurze erläuterung wäre ich sehr dankbar
mfg
kay
16
0xAA
0
0
7
10
0
Bilddaten (70 Bytes)
Damit wird ein 56x10 Pixel großes Bild mit 1bpp an Position 0,0 geladen
16
0xAA
0
0
13
10
1
Bilddaten (130 Bytes)
Damit wird ein 52x10 Pixel großes Bild mit 2bpp an Position 0,0 geladen
Je nachdem in welchem Modus man die Bilder läd, müssen die X Werte
entweder durch 8 oder durch 4 geteilt angegeben werden.
hallo,
so habs mal probiert aber das display wird nur mit wirren zeichen
gefüllt,
die bilddaten habe ich mal im anhang,auch das tool womit ich die
bilddaten umwandle,
das bild hat 60x60
16
0xaa
0
0
60
60
1
bild:
vielleicht hat ja einer von euch mal ein beispiel
Du lädst da doch nicht etwa eine gif Datei ins Display? Du musst die
Bildaten unkomprimiert mit 1bpp bzw. 2bpp senden. 1 Byte enthält also 8
bzw. 4 Pixel.
Benedikt K. wrote:
> Du lädst da doch nicht etwa eine gif Datei ins Display?
nein
das .gif bild wandle ich um mit diesem tool,das ergibt den
zb, diese tabelle wo das bild drin ist,
bild:
.db0x47,0x49,0x46,0x38,0x39,0x61,0xF0,0x00;
.db0x40,0x01,0x80,0x00,0x00,0xFF,0xFF,0xFF;
.db0x00...................
das lade ich in den controller der das dann ans display schickt
oder habe ich das ganze verkehrt verstanden
mfg
kay
hallo,
habe das gif bild mit paint gespeichert und zwar monochrom ,auflösung
60x60pixel,542Bytes,dann das gif bild umgewandelt mit winbin (hat
jetzt3.04Kb)damit ichs im avr(mega128) speichern kann der es dann zum
lcd überträgt.
hab die beiden bild daten im anhang.
wenn ichs zum lcd schicke dann entsehen nur wahllose pixel.
vielleicht könnte mir einer von euch ein wenig weiterhelfen,
oder ein beispiel zum testen.
mfg
kay
hallo,
guten nabend
die funktion ein bmp anzuzeigen funktioniert nicht,zumindest bei mir
nicht,es werden immer nur wirre zeichen dargestellt vielleicht wäre es
möglich mir ein kleines stück weiter zuhelfen
mfg kay
Hi!
Erstmal großes Lob für Deine Arbeit, Benedikt. Ich habe damit allerdings
ein kleines Problem (naja, noch nicht ;)).
Ich will für ein Projekt deine Schaltung verwenden, muss aber mehr
Informationen auf dem Display unterbringen als mit 40 x 20 Zeichen
möglich ist (es geht dabei vor allem um die Zeichen pro Zeile, die
Anzahl der Zeilen ist absolut ausreichend).
Gibt es eine einfache Möglichkeit, die Größe der Zeichen von 8 x 12 auf
z.B. die bei anderen Display-Controllern (z.B. Epson) üblichen 5 x 7 zu
reduzieren? Die entsprechenden Definitionen der Zeichen könnte ich
Ändern, womit ich mehr ein Problem habe, ist das Auslesen durch die
Assembler-Routine und die Positionierung auf "ganzen Zeichen", die du ja
scheinbar vor dem Aufruf der lcd_writebyte-Routine vornimmst..
Ich vermute mal die 8 x 12 sind der "glatten" Ausrichtung an einer
Byte-Grenze geschuldet? Dann wäre es vermutlich nicht so leicht das
ganze hinzukriegen..
Gibts da eine einfache Methode das zu ändern bzw. irgendwo als Konstante
festzulegen?
Danke für deine Mühe,
- Tobi
Hallo Benedikt, hallo liebe Community.
Ich habe eben mal das Projekt "trocken", ohne es testen zu können, unter
der aktuellen Winavr Version (20080610) mit einem Atmega128 als Ziel
erfolgreich compiliert, da ich leider keinen Atmega8515 zur Verfügung
habe.
Sollte gehn, oder?
Testen kann ichs im Moment leider noch nicht...
Würde mich über ein ja, jain, nein von euch freuen ;-)
Danke Rudi
> Gibt es eine einfache Möglichkeit, die Größe der Zeichen von 8 x 12 auf> z.B. die bei anderen Display-Controllern (z.B. Epson) üblichen 5 x 7 zu> reduzieren?
Ja, das sollte kein Problem sein, da die gesamte Software im Grafikmodus
läuft. Die Textzeichen werden daher als Bild in den Bildspeicher
geschrieben.
> Ich vermute mal die 8 x 12 sind der "glatten" Ausrichtung an einer> Byte-Grenze geschuldet?
Ja, da kann man ein ganzes Bytes einfach in den Speicher kopieren. Das
geht am schnellsten, erlaubt aber auch nur das Positionieren eines
Zeichens in 8 Pixel Schritten.
Da man für andere Textgrößen sowieso aus dem Bytraster fällt, kommt man
um das Pixelweise setzen und löschen nicht herum. Mit
lcd_setpixel(x,y,color) sollte eine Erweiterung auch ohne Eingriffe in
den Assembler Code kein Problem sein.
Sowas in der Richtung sollte funktionieren (ich habs jetzt aber nicht
ausprobiert):
rudi wrote:
> Sollte gehn, oder?
Leider nicht.
Die Schaltung verwendet einen Adressbereich von 256x240Bytes=60kBytes,
der mega128 erlaubt aber nur 59,75kByte für das externe RAM. Daher muss
erstens das #define DDRAM 1024 auf 4096 erhöht werden, und zweitens
werden die erste und die letze Zeile des Displays vermutlich dasselbe
anzeigen, da eben zu wenig externer Speicher adressiert werden kann.
Hi Benedikt!
Ich hatte mir den ASM-Quelltext gestern abend nochmal angeguckt. Das
Konzept der Bitmuster im Array kann man ja beibehalten, muss dann nur
gucken das man jeweils nur die ersten 6 Bit des Musters benutzt.
Natürlich muss das ganze dann bitweise adressiert werden, und mit einer
entsprechenden Maske gearbeitet werden.
Meine Ideen bis jetzt:
- Zeichen laden (entsprechende Pixel-Zeile)
- Maske erzeugen (gleiche Breite wie das Zeichen und an selber Stelle)
- Bit-Offset laden (zum Zeichenanfang)
- Speicherstelle berechnen
So lange Bit-Offset > 0:
Maske verschieben (links oder rechts..?)
Zeichen auch verschieben (genau wie Maske)
- Maske XOR 255
- Byte b aus dem Display-RAM laden
- b = b & Maske
- b = b | Zeichen
- Byte b in Display-RAM schreiben
- Externe RAM-Speicherstelle + 1
- Zeichen laden (entsprechende Pixel-Zeile)
- Maske erzeugen (gleiche Breite wie das Zeichen und an selber Stelle)
- Bit-Offset laden (zum Zeichenanfang)
- Neues Bit-Offset = 8 - Altes Offset
- Speicherstelle berechnen
So lange Bit-Offset > 0:
Maske verschieben (rechts oder links, andersrum wie beim ersten
Schritt)
Zeichen auch verschieben (genau wie Maske)
- Maske XOR 255
- Byte b aus dem Display-RAM laden
- b = b & Maske
- b = b | Zeichen
- Byte b in Display-RAM schreiben
- Externe RAM-Speicherstelle - 1 (damit ist der Zustand wie vorher und
kann wie in deiner ASM-Routine fortgesetzt werden)
Das ist mal ganz schnell formuliert der Pseudocode (ASM-nah) den ich
dafür umsetzen würde. Ich habe allerdings mit Assembler bis jetzt nicht
viel gemacht (okay, bis auf ein paar Änderungen in fremdem Code) und
weiß nicht genau ob ich dafür beliebige Register benutzen kann, da der
C-Code da ja noch mit zusammen arbeiten muss. Eigentlich dürfte es kein
Problem geben wenn ich mit push & pop die entsprechenden Register
sichere, oder?
Dieser Code dürfte (sofern ich jetzt keinen Denkfehler drin habe) auch
schneller arbeiten als jedes Bit per "setpixel" zu setzen..
Danke vielmals ;)
- Tobi
P.S: Mir fällt gerade auf, das es wenn ich aus dem externen RAM auch
lese eventuell zu Fehlern kommen könnte.. Spielt das eine Rolle? Ich
meine.. die Daten werden ja eigentlich beim Lesen auch ans Display
übertragen. So ganz hab ich das aber noch nicht durchschaut was in der
Schaltung abläuft ;)
Welch ein Zufall dass genau dieses Display bei mir liegt und ich Montag
Platinen fertigen lasse. Ich werde mal eine SMD-Platine
zusammenstoepseln und das ganze aufbauen, vielen Dank Benedikt!
Tobias Hagemeier wrote:
Das ist mal ganz schnell formuliert der Pseudocode (ASM-nah) den ich
> dafür umsetzen würde.
Sollte soweit funktionieren. Dürfte auch auf jedenfall schneller sein
als die einzelnen Pixel zu setzen, vor allem da man mit einer Maske ja
direkt alle 8 Zeilen untereinander schreiben kann.
> weiß nicht genau ob ich dafür beliebige Register benutzen kann, da der> C-Code da ja noch mit zusammen arbeiten muss.http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_reg_usage> P.S: Mir fällt gerade auf, das es wenn ich aus dem externen RAM auch> lese eventuell zu Fehlern kommen könnte.. Spielt das eine Rolle?
Dafür habe ich extra das Signal an PD3 eingeführt. Damit wird das
Display quasi vom Datenbus getrennt, wenn keine Daten ausgegeben werden.
Nur im Interrupt wird dieses Signal aktiviert, eine Zeile ans Display
übertragen und anschließend das Signal wieder deaktiviert.
Hallo,
ich hab auch mal ein 320x240 Display angeschlossen, jedoch treten bei
mir senkrechte Schlieren/Linien auf.
Ich hoffe auf dem Bild kann man erkennen, was ich meine.
Könnte es daran liegen, dass ich das Display mit Lackdraht an die
Platine angeschlossen habe und die Drähte jetzt wie Sender/Empfänger
arbeiten und Influenzen in den benachbarten Drähten verursachen? Komisch
ist aber, dass es neben der Schrift " 320x240 LCD Controller By
Benedikt" keine Schlieren auftauchen.
Als Sram benutzte ich eins mit 15ns Zugriffszeit.
Die Platine ist gelayoutet und besitzt eine Massefläche.
Gruß Alex
PS: Hier mal ein kleies Video, auf dem ich die Kontrastspannung runter
und wieder hoch regele. Durch die Kontrastspannung kann ich den effekt
zwar abschwächen, bekomme ihn aber nicht weg.
http://mitglied.lycos.de/onrop/Alex/Elektronik/Fotos%20&%20Videos/Kontrast.ASF
(die Hintergrundgeräusche stammen von meinem Radio.... diese treten
jedoch nur dann auf, wenn das LCD im Betrieb ist. Dabei ist das Radio 2
m vom LCD entfernt.)
Alexander Sewergin wrote:
> ich hab auch mal ein 320x240 Display angeschlossen, jedoch treten bei> mir senkrechte Schlieren/Linien auf.
Dieser Effekt nennt sich Übersprechen. Er tritt vor allem an großen
senkrechten oder waagrechten Linien auf, was hier der Fall ist.
Daran kann man leider recht wenig machen, das liegt am LCD. Vor allem
blau-weiße sind davon stark betroffen, da diese einen Knick in der
optischen Kennlinie haben: Zwischen blau und weiß kommt schwarz, was man
auch schön im Video sehen kann.
Das ist der Grund, wieso ich keine blau weißen LCDs verwende, obwohl
blau-weiß eigentlich gut lesbar ist.
Kann man denn gegen das Übersprechen nichts machen?
Wieso tritt dieser Effekt eigentlich nur in der vertikalen Richtung auf?
Ich werde mal ein bischen mit den Frames per Seconde rumspielen oder
halt auf Linienzeichnungen verzichten.
Gruß Alex
Man könnte die Ansteuerung etwas anpassen, eventuell mit passendem
n-line usw. aber das ist alles nicht so einfach und es verursacht andere
Störerscheinungen.
Das Phänomen tritt hauptsächlich vertikal auf, da die Einschaltdauer
einer Zeile konstant ist (nämlich 1/240). Die Einschaltdauer einer
Spalte dagegen variiert je nachdem wie viele Pixel in dieser Spalte
aktiv sind (nämlich 0 bis maximal 240). Insgesamt spielen da sehr viele
Faktoren eine Rolle (Widerstände der Leiterbahnen, Kapazitäten im LCD
usw.), hier ist das ganze einigermaßen beschrieben:
http://www.solomon-systech.com/pdf/Crosstalk%20Improvements%20for%20STN%20LCD.pdf
Es scheint wirklich am LCD zu liegen. Ich habe das s/w LC-Display von
Pollin angeschlossen und man erkennt keine vertikalen Linien mehr.
So langsam verstehe ich auch, wieso viele passive Displays auf dem Markt
für wenig Geld verkauft werden. Die Bildqualität ist wohl nur mit viel
Mühe gut einstellbar.
Gruß Alex
Ich bekomme immer eine Fehlermeldung (AVRStudio4 + WinAVR20081118rc2)
wenn ich das Programm neu compilieren möchte. Eventuell liegt es einfach
an meinem Unvermögen mit dem GCC Compiler umzugehen. Auf dem Bild könnt
ihr sehen, welche Headers ich eingefügt habe. Was muss ich mit lcd.c und
uart.c machen? Die sind derzeit in dem selben Ordner, wo auch die main.c
ist. Muss ich diese c. Files irgendwo einbinden?
Gruß Alex
Ich habe hier ein sp14q002 Display (Datenblatt im Anhang).
So wie ich das hier sehe kann ich dieses Display mit diesem
Selbstbaucontroller verwenden, nur wollte ich nochmal sicher gehen,
bevor ich alle Teile bestelle, die ich brauche, und daraus wird dann
doch nichts...
Ok, vielen Dank!
Nun habe ich noch eine Frage, den Optomosfet kann ich ja, so wie ich das
sehe rauslassen, oder?
Wenn ja, dann muss ich doch VLCD einfach mit an die Anode von D1 und
ONOFF an PE0 (INT2) am Controller oder?
Im Schaltplan ist ONOFF nicht als invertiert beschriftet, in meinem
Datenblatt ist das DISP.OFF(Low-Aktiv). Dann muss ich doch noch das
Signal (am einfachsten mit einem Transistor, oder?) inververtieren??
Nils wrote:
> Nun habe ich noch eine Frage, den Optomosfet kann ich ja, so wie ich das> sehe rauslassen, oder?
Ja.
> Wenn ja, dann muss ich doch VLCD einfach mit an die Anode von D1 und> ONOFF an PE0 (INT2) am Controller oder?
Ja.
> Im Schaltplan ist ONOFF nicht als invertiert beschriftet, in meinem> Datenblatt ist das DISP.OFF(Low-Aktiv). Dann muss ich doch noch das> Signal (am einfachsten mit einem Transistor, oder?) inververtieren??
Nein.
Onoff: High = On, Low = Off
DispOff\ ist Low aktiv, Low deaktiviert also das Display.
Direkt verbinden und das Display sollte funktionieren.
Kay B. wrote:
>> vielleicht wäre es möglich mal drüber zuschauen> was ich verkehrt mache> bild0:> lpm ; Erstes Byte nach R0 lesen> tst R0 ; R0 auf 0 testen> breq _end ; wenn 0 verzw. zu _end
Da dein erstes Datenbyte schon 0 ist, wird die Schleife direkt
abgebrochen und gar nichts gesendet.
Besser ist es mit einem Zähler eine feste Anzahl an Bytes zu senden, da
man nie weiß welche Bytes in den Bilddaten enthalten sind.
könnte mann das so machen
ldi r18,7 ;zähler für daten = 8
bild0:
lpm ; Erstes Byte nach R0 lesen
dec r18 ;zähler für daten
rcall senden ; UP "ausgeben auf uart
brne bild0 ;alle 8bytes durch?
adiw zl, 1 ; Adresse des Z-Pointers um 1 erhöhen
ldi r18,7 ;zähler für daten = 8
rjmp bild0 ; wieder zum Anfang
mfg kay
hallo,
so müsste es doch gehen
wenn der der befehl lpm alle 8byte gelesen hat dann wird der z-pointer
um eins erhöt oder bin ich da auf den holzweg?`
ldi r18,7 ;zähler für daten = 8
bild0:
lpm r17,z+ ; Erstes Byte lesen
rcall senden ; UP "ausgeben auf uart
dec r18
brne bild0
adiw zl, 1 ; Adresse des Z-Pointers um 1 erhöhen
rjmp bild0 ; wieder zum Anfang
senden:
sbis UCSR0A,UDRE0 ; Warten bis UDR für das Byte bereit ist
rjmp senden
OUT UDR0, r17
ret
_end:
Kay B. wrote:
> hallo,> so müsste es doch gehen> wenn der der befehl lpm alle 8byte gelesen hat dann wird der z-pointer> um eins erhöt oder bin ich da auf den holzweg?`
Ja, du machst das komplett falsch. Der z-pointer muss nach jedem Byte
erhöht werden.
Hier mal ein Ausschnitt mit dem ich Daten aus dem Flash in der RAM
kopiere. Er zeigt aber zumindest das Prinzip.
hallo,
so habe die leseschleife etwas umgeändert,es werden nur wirre pixel
dargestellt.
ich weiss aber nicht ob die tabelle mit den bilddaten so überhaupt
richtig ist,das bild hab ich mal im anhang.
mfg kay
ldi r18,7 ;zähler für daten = 8bytes pro tabellen zeile
bild0:
lpm r17,z+ ; Erstes Byte lesen
rcall senden ; UP "ausgeben auf uart
adiw zl, 1 ;Adresse des Z-Pointers um 1 erhöhen
;nächste zeile lesen
dec r18 ;zähler für daten
brne bild0 ;alle 8bytes durch?
Kay B. wrote:
> ldi r18,7 ;zähler für daten = 8bytes pro tabellen zeile
Wieso 8 Bytes? Das Bild ist 60x60 Pixel = 3600Bits = 450Bytes groß.
Das adiw ist auch überflüssig, da dies lpm z+ schon erledigt.
hallo Benedikt,
habe mir mal den beitrag"LCD Controller für 640x480 LCD mit mega8515"
angesehen und das logo was du da verwendest mal probiert und das
funktioniert,
also ist meine bild-tabelle nicht inordnung
aber wie wandelst du denn die bmp`s um?
vieleicht könntest du mir ein wenig weiterhelfen
mfg kay
Ich speichere das Bild als BMP in Schwarzweis mit 1bit pro Pixel. Dann
entferne ich die ersten 62Bytes der Datei, der Rest sind die reinen
Bilddaten.
Einfacher geht es z.B. mit solchen Tools (davon gibt es etliche, das war
jetzt das nächstbeste das ich gefunden habe):
http://en.radzio.dxp.pl/bitmap_converter/
hallo,
so habe jetzt mal das programm probiert
egal welche auflösung das bild hat aber ich bekomme nur zeichensalat
raus,habe die datei im anhang,das bild hat eine auflösung von 132x176
Pixel
vielleicht könntest du mir nochmal weiterhelfen
mfg
kay
habs grad mal ausproniert das haut sogar hin,aber warum haut das bei mir
nicht hin,132x176 = 23232byte´s/8 = 2904byte bei meinen convertierungen
komme ich nie ganz auf die byte`s
mfg
kay
Die Datei habe ich mit dem Programm erstellt, Einstellung: horizontal
Dann nur noch das C Array passend für den Assembler angepasst (jeweils
ein .db am Anfang von jeder Zeile)
Soo jetzt kamen meine Teile von Reichelt erst, doch statt einem Latch
war ein FlipFlop drin...
Ich habe hier noch den Bustreiber 74LS245 liegen.
http://www.ralfzimmermann.de/ttl_ic/0e34.html
In die Schaltung soll ein 74HC245.
http://www.ralfzimmermann.de/ttl_ic/0e39.html
Nun habe ich mir das angesehen und wenn ich DIR von 245er auf H lege und
dann G\ nochmal invertiere und dann an PE1 (ALE) von uC gehe, müsste das
doch eigentlich klappen?
Theorethisch, aber dann ist ja noch die Geschwindigkeitsfrage, muss es
unbedingt ein HC sein oder reicht der LS auch (wenn das überhaupt so
nutzbar ist.) ?
Nils wrote:
> Nun habe ich mir das angesehen und wenn ich DIR von 245er auf H lege und> dann G\ nochmal invertiere und dann an PE1 (ALE) von uC gehe, müsste das> doch eigentlich klappen?
Nein, der 245er ist ein Bustreiber, du brauchst aber ein Latch. Mit
einem 574 würde es eventuell auch noch gehen, aber mit einem 245 auf
keinen Fall.
Hallo,
ich habe mal eine Platine im Eagle zu dem Thema gemacht.
Die IC´s sind alles DIL Bausteine es kommen nur ein paar wenige SMD
Kondensatoren und Widerstände zum Einsatz. Habe die Bauform 1206 gewählt
weil sie sich von Hand noch sehr gut löten lassen.
Auf dem Bord ist eine 5V Spannungsversorgung und die -22V für das
Display enthalten.
Habe mich an das Orginal von Benedikt K. gehalten.
Für den Anschluss des Displays habe ich eine Stiftleiste vorgesehen
(Raster 2,5mm)
Die Belegung ist
1 -> Frame
2 -> LOAD
3 -> CP
4 -> VDD (5V)
5 -> GND
6 -> VSS (-22V) Diese müsste mit dem NAN YA LTBE9T372G1K überein stimen
7 -> D0 Nur bei M AC hab ich keine Angabe gefunden was es ist!
8 -> D1
9 -> D2
10 -> D3
11 -> Display Off
12 -> M AC
Eventuell besteht ja Interesse und man könnte eine Sammelbestellung von
Platinen loslassen.
Hallo,
Habe heute die Größe des Boards auf 100mm x 80mm geschrumpft.
hab mal die Preise bei Bilex im Kalkulator berechnen lassen und er sagt
mir das eine Leiterplatte, 2-lagig, mit Lötstoplack und Verzinnung ca.
7,5€ kostet.
Finde das einen guten Preis.
Die Berechnung gilt für 12 Eurokarten also 24 einzelne Leiterplatten.
Alle die Interesse haben einfach melden dann würde ich eine Bestellung
abschicken.
Können auch gern einen anderen LP Hersteller nehmen, war nur so die
erste Adresse wo ich geschaut habe.
Eventuell schaut auch einer nochmal über die Platine quer, um eventuell
Fehler die sich eingeschlichen haben noch zu ändern.
@Blitzlampe: Warum sind die meisten Leiterbahnen auf den TOP Layer ( Rot
), das heisst du müsstest jede Fassung oder IC von oben festlöten, wäre
sehr umständlich. Da am besten man den Buttom (Blau ) Layer zum löten
verwendet wird entsprechend den Layer wechseln.
Sind die Platinen Durchkontaktiert und mal getestet worden ?
Avr Nix wrote:
> @Blitzlampe: Warum sind die meisten Leiterbahnen auf den TOP Layer ( Rot> ), das heisst du müsstest jede Fassung oder IC von oben festlöten, wäre> sehr umständlich. Da am besten man den Buttom (Blau ) Layer zum löten> verwendet wird entsprechend den Layer wechseln.
???
Jede Bohrung ist gleichzeitig eine Durchkontaktierung und kann somit von
beiden Seiten gelötet werden.
>Jede Bohrung ist gleichzeitig eine Durchkontaktierung und kann somit von>beiden Seiten gelötet werden.
na, ja für Profis sei das Löten wohl kein Problem, ich hatte meine
Platine so geändert, das nur noch jede 2. Fassung von beiden Seiten
gelötet werden braucht. Oder anders gesagt, genügend Platz für den
Lötkolben da ist.
Wigbert
Natürlich sind die Platinen Durchkontaktiert,
Die meisten Leiterbahnen sind übriegens auf der Seite der Leiterplatte
wo nicht die IC´s sitzen. Es gehen nur wenige Leiterzüge unter den IC´s
lang (BOTTOM Layer)
Habe im Anhang noch mal das Layout gespiegelt wer damit besser
zurechtkommt ist aber die selbe Platine.
Wollte nicht deine Platine nieder machen, aber wenn es eng wird und du
keine Präzisionfassung benutzt wird man mit dem löten Schwierigkeiten
haben, da man nicht von oben Löten kann bzw kaum dran kommt.
Wenn man auf top Layer Leitungen weg gehen und auf den Bottom layer
gelötet wird hast du keine Verbindung.
....aber wenn alle Durchkontaktiert (hülse) sind sollte das nicht
passieren
Ich nehmen auch mal eine Platine.
Wird der Spannungsregler nicht zu warm ?
Kritik ist immer gern willkommen solange sie hilfreich ist.
Kenne das Problem auch, wenn man Platinen bügelt muss man schon drauf
achten wie und wo man die Via´s setzt weil es schnell passiert das man
nicht mehr rankommt zum löten. Aber bei einer "richtigen" Platine sind
alle Bohrungen durchkontaktiert und somit reicht es wenn man eine Seite
verlötet.
Die Platine lässt sich ohne Akrobatik löten und bestücken, das Bild im
Anhang zeigt wo alles gelötet werden muss. Jeder grüne Punkt ist eine
Lötstelle + die SMD Bauteile.
Es muss nur diese Seite gelötet werden!
Das Bild zeigt übrigens die Unterseite und die IC's Sitzen auf der
anderen Seite.
Der 7805 wird bei 12V Eigangsspannung und einem Laststrom von 0,1A ca.
46°C + Umgebungstemp warm.
Wenn jemand, der die Schaltung schon aufgebaut hat, mal den Strom messen
könnte wäre das super. Somit könnte man abschätzen wie hitzig es wird
und ggf. noch gegensteuern.
>Kritik ist immer gern willkommen solange sie hilfreich ist.
Stimmt.
Ich hatte damals die Sockelpins fürs Durchkontaktieren genutzt,
um Einzelstücke selbst fertigen zu können.
Industriell hergestellte Platinen haben natürlich Durchkontaktierungen.
Wenn es zu einer Sammelbestellung kommt, vielleicht kannst Du die
Stecker fürs Pollindisplay(wenn Bedarf) zulegen. Die gibt es nun mal
für ein paar Cent (zB.Farnell).
Wigbert
Ich habe mal die Schaltung und das Layout kontrolliert, passt alles
soweit, bis auf eine Kleinigkeit, die allerdings mein Fehler ist:
Der CLK Eingang des FlipFlops das M/AC erzeugt, muss an Frame/FLM und
nicht an LP/Load. Für die beiden Pollin LCDs ist das aber egal, denn die
erzeugen dieses Signal intern selbst. Daher ist es mir bisher nicht
aufgefallen, dass dies falsch war. Nur andere LCDs (wie z.B. Hitachi
SP14Q001 oder das Sharp LCD das es noch bei Pollin gibt), benötigen
dieses Signal.
Den korrigierten Schaltplan habe ich mal angehängt.
Ich würde den TXD Pin auch noch mit rausführen. Er wird zwar momentan
nicht benötigt, aber falls man doch mal irgendetwas erweitert, (z.B.
Zurücklesen der Daten), dann kann man ihn verwenden.
Das Optorelais ist leider bei Pollin nichtmehr erhältlich und daher nur
noch teuer/schwer zu bekommen. Das Pollin LCD besitzt einen ON/OFF Pin,
daher ist ein Schalten der VLCD nicht unbedingt notwendig. Ein
(Löt)Jumper um diesen zu überbrücken, wäre daher vielleicht sinnvoll.
So habe den CLK auf FLM FRAME gelegt und einen Jumper zum überbrücken
für das Optorelais hinzugefügt.
Die UART Schnittstelle habe ich jetzt neu gemacht. Jetzt ist eine 4
polige, 2,5mm Raster Stiftleiste vorgesehen, mit folgender Belegung.
Pin 1 -> RxD
Pin 2 -> TxD
Pin 3 -> GND
Pin 4 -> RTS (BUSY)
Habe die Displayschnittstelle jetzt auch mit 2,5mm Stiftleiste versehen,
da die andere schwierig zu bekommen ist. Desweiteren sind die Signale
jetzt beschriftet.
@ Picht
Die Displayschnittstelle habe ich extra mit der Stiftleiste gemacht,
damit ist die Platine universell für viele Display´s und man kann
Flachbandkabel direkt einlöten. Wer will kann sich immer noch eine
kleine Adapterplatte mit einer passenden Buchse machen und diese auf die
Stiftleiste Löten oder stecken.
Wegen den RAM nicht alle sind sp breit es gibt auch die schmalen die wie
ein ATMega 8 aussehen. könntest du noch eine Leiste Paralle zu einer
Seite einbauen , sodas man beide Breiten einbauen kann, das wäre sehr
Universell.
Oder sonst müsste man extra eine Adapterplatine basteln, so könnte man
den schmalen 28poligen Fassung oder den Breiten 28poligen Fassung
nehmen.
Avr Nix wrote:
> Wegen den RAM nicht alle sind sp breit es gibt auch die schmalen die wie> ein ATMega 8 aussehen. könntest du noch eine Leiste Paralle zu einer> Seite einbauen , sodas man beide Breiten einbauen kann, das wäre sehr> Universell.
Ja, das wäre sinnvoll. Die schnellen SRAMs sind nämlich alle nur in der
schmalen Ausführung erhältlich. Für die langsamen RAMs muss die Software
angepasst werden (lcd.c, Waitstates aktivieren).
So war heut nochmal bei Bilex und hab jetzt einen Preis von 8€ für
folgende Platine
1
12 x LEITERPLATTEN (ergibt 24 einzelne Platinen)
2
2-Lagig Durchkontaktiert
3
100x160 mm
4
Materialstärke: FR4 1.55mm;
5
Oberfläche: Chemisch Gold(RoHs konform)
6
Cu Außenlagen Enddicke: 70 µm;
7
Lötstop: doppelseitig grun
8
Positionsdruck: ohne
9
10
Netto: 147.39 €
11
MwSt: 29.48 €
12
Brutto: 176.87 €
13
Versand 14.00 €
Verzinnt oder vergoldet macht im Preis kein unterschied genauso wie die
Kupferstärke.
Also hab ich mich für Gold entschieden, das lässt sich auch noch nach
langer Zeit super löten.
Also melder wer eine will, bin erst bei 6 Eurokarten.
Ok, es haben sich verschiedene Leute gemeldet und ihr Interesse
angemeldet.
Vielen dank erstmal!
Ich würde dann am WE, eventuell kommen bis dahin noch ein paar
Bestellungen hinzu, Platinen ordern.
Wenn es bei den 12 Platten bleibt wären es 8€ + Porto zu euch. Würde das
mit der Post im gepolsterten Umschlag verschicken. Versandkosten fallen
nur die von mir zu euch an.
Würde mich mal bis zum WE schlau machen (wegen Porto) und euch dann am
WE die Bankdaten und den Preis mailen. Will diese nicht unbedingt im
Netz veröffentlichen nicht das mir die anderen 6*10^9 Leute auf der Erde
auch noch Geld überweisen ;-) man weiß ja nie.
Ich bestelle drei Platinen (falls jetzt noch möglich).
Es wäre jedoch zu überlegen, ob man auf dem Board noch eine Schaltung
zur Erzeugung der HV Wechselspannung für die Hintergrundbeleuchtung
vorsieht (sicher, dann sollte man einen Berührschutz haben, z.B. Einbau
in ein Gehäuse). Und wer diese Schaltung nicht braucht, muss die
Bauteile ja nicht einlöten. Ich habe folgende Schaltung getestet:
http://www.elektronik-kompendium.de/forum/forum_entry.php?id=13083&page=1&category=all&order=time
Sie zieht etwa 300 mA bei 5 V Versorgungsspannung und bei
angeschlossenem Display (nicht 12 V wie auf dem Bild). Ich habe die
Schaltung etwas modifiziet: Widerstände 1K, Transistoren 2N3055, mehr
"Rückkopplungswindungen", Kondensator überflüssig (ich verstehe
prinzipiell den Zweck des Kondensators, aber bei meinen Tests ergab sich
dadurch kein besserer Wirkungsgrad). Vielleicht könnte man den
Wirkungsgrad aber noch mit einer ZVS Schaltung verbessern, die ich
jedoch noch nicht getestet habe:
http://img236.imageshack.us/img236/5286/flybackdriverandrineriji7.jpg
Sie scheint zwar für einen Zeilentrafo konzipiert zu sein, dürfte sich
aber auch für ca. 500 V Ausgangsspannung anpassen lassen (geeigneter
Ferrtikerntrafo).
Noch eine Frage: Hat jemand eine Ahnung, wie stark sich die
Bildwiederholungsrate verringert, wenn man die 70 ns SRAMs von Reichelt
benutzt und das Programm entsprechend anpasst ?
Einen CCFL Inverter würde ich nicht auf die Platine machen.
1. Bekommt man diese günstiger gekauft, als man es selber bauen kann.
2. Es schwierig ist einen Trafo zu bekommen bzw selber zu wickeln.
3. Er die Verlustleistung am 7805 extrem in die Höhe treibt.
4. Weil der gekaufte Inverter oder ein ausgebauter sicher funktionieren.
5. Es nicht abzuschätzen ist ob die Störung des Wandlers die Funktion
der Schaltung beeinflussen.
6. Kein Platz mehr ist.
Florian K. wrote:
> Noch eine Frage: Hat jemand eine Ahnung, wie stark sich die> Bildwiederholungsrate verringert, wenn man die 70 ns SRAMs von Reichelt> benutzt und das Programm entsprechend anpasst ?
An sich garnicht, da sich der LCD Controller soviel Zeit nimmt wie er
braucht. Allerdings benötigt ein Speicherzugriff dann 3 statt 2 Takte,
was die CPU Auslastung auf >80% erhöht. Die Grafikbefehle werden dann
entsprechend langsamer ausgeführt.
Der CCFL Inverter braucht für das Display braucht nicht umbedingt 12V,
ich habe ein Inverter der für 12V ist für die Hindegrundbeleuchtung auf
7..8V laufen. Das sollte man ausprobieren.
Hallo,
habe soeben die Bestellung abgeschickt.
Habe allen eine Mail geschrieben.
Sollte ich einen vergessen haben einfach mir noch ne Mail schreiben.
Laut Bilex sollen die Platten bis zum 20. gefertigt werden und dann
müssten sie 3-4 Tage später bei mir eintreffen.
Werde Sie dann umgehend an euch weiter leiten.
!!!! Habe auch noch ein paar Platten über also wer noch eine will kann
sich immer noch melden!!!!!
Hallo,
gestern sind die Platinen an euch raus. Hoffe das ihr sie bald bekommt.
Habe eine mal fix aufgebaut um zu schauen ob alles soweit passt.
Es sind noch 2 Stück über also wer noch eine oder beide will kann sich
melden.
Im Anhang ist der Funktionstest zu sehen.
Hallo zusammen,
auf dem Display ist nur auf der rechten Seite ein Streifen Muster drauf.
Woran kann das liegen, ich habe alle Lötstellen 3x neu verlötet?
Was könnte das Problkem sein das nur die linke Hälfte OK Angezeigt wird
und rechts streifen auftauchen?
Danke
Avr Nix wrote:
> Was könnte das Problkem sein das nur die linke Hälfte OK Angezeigt wird> und rechts streifen auftauchen?
Ich habe ehrlich gesagt nicht die geringste Vermutung woran das liegen
könnte.
Der Text sieht OK aus, auch auf der rechten Seite.
Da es weder Software noch Hardware mäßig irgendwelche Unterschiede
zwischen beiden Seiten gibt, ist das ganze sehr seltsam.
Dazu kommt noch, dass jeder 2. Pixel anscheinend betroffen ist, aber die
Pixel liegen ja gemeinsam zusammen mit den funktionierenden Pixel in
einem Byte.
Fängt die Störung bei einer Zweierpotenz (Bits/Bytes in der Zeile) an
und wiederholt sich alle 8 Bits? Dann könnte eine irgendwie geartete
Kopplung zwischen einem Adress- und einem Datenpin vom RAM bestehen.
Adress/Datenpins untereinander und gegeneinander durchklingeln.
Speichertestprogramm basteln. Korrekte Funktion vom Adresslatch testen.
RAM und Adresslatch tauschen.
Stützkondensatoren sind ja wohl überall drin? Wie sieht der Aufbau aus?
Also ich habe die Platine von Blitzlampe und mehre RAM wie den
W24M257AK-15 und dem Em51M256A-15P getestet alles das gleiche Ergebnis.
Jetzt darf ich mal das Datenblatt suchen und schauen ob die überhaupt
passen, was ich gedacht habe.
Ich habe hier noch ein HM62256ALP-70G der passt doch ?
Ich meine mich erinneren zu können das die von der PINs her stimmig
sind.
Der SRAM sollte eigentlich funktionieren.
Aktivier mal testweise in der lcd.c in der void lcd_init(void) die
Waitstates um ein Timingproblem auszuschließen.
Hallo,
Verändert sich die Störung, wenn du mit dem Finger an den Rahmen des
Displays fast oder diesen mit Masse verbindest?
Ich frage deshalb, weil bei mir ein Inverter wo solche Störungen auf der
Spannungsversorgung erzeugt hatte, das ich auch Streifen im Display
gesehen habe. Diese haben sich aber verändert wenn ich den Finger an den
Rahmen gehalten oder mit Masse verbunden habe.
Hallo Benedikt,
Noch eine andere Frage welche Zahl ist bei dir Grau und Hellgrau?
Und könntest du mal ein Beispiel in deiner PDF aufnehmen wie man ein
Rechteck und Kreis in den 4 Graustufen etc. zeichnet?
Und -
Wo soll ich Waitstates erhöhen? bzw. könntest du nicht eine passende HEX
posten? Da ich nicht mit C arbeite, Danke
void lcd_init(void)
{ cli();
wdt_disable();
MCUCR=(1<<SRE)|(0<<SRW10); // Enable XMEM !!! Die Null vor
dem SRW Bit durch eine 1 ersetzen, !!!
// !!! wenn der verwendete SRAM mehr
als 35ns hat !!!
OCR1A=10;
OCR1B=128;
TCCR1A=(1<<COM1B1)|(1<<COM1B0)|(1<<WGM10); // Enable PWM (Kontrast)
TCCR1B=1; // 8bit PWM
OCR0=RELOAD;
TCCR0=(1<<WGM01)|2; // 2MHz Timer Takt, CTC
TIMSK=(1<<OCIE0);
sei();
lcd_clear();
lcd_block(50,10,269,79,0,255);
lcd_block(60,20,109,69,64,255);
lcd_block(150,15,189,45,64,64);
lcd_block(180,40,219,75,128,128);
lcd_block(200,20,239,50,255,255);
lcd_string(10,120,PSTR("320x240 LCD Controller"),255,0);
lcd_string(15,140,PSTR("\xB8"" by Benedikt"),255,0);
wdt_enable(WDTO_250MS);
ENABLE_VLCD=1;
}
Avr Nix wrote:
> Noch eine andere Frage welche Zahl ist bei dir Grau und Hellgrau?
Die Farben sind 8bit Werte, man kann jeden Wert senden, es werden aber
nur die 2 MSB verwendet:
0, 64, 128, 192 sind also eine Möglichkeit für die 4 Graustufen.
> könntest du nicht eine passende HEX posten?
Ist im Anhang.
Avr Nix wrote:
> Und könntest du mal ein Beispiel in deiner PDF aufnehmen wie man ein> Rechteck und Kreis in den 4 Graustufen etc. zeichnet?
Hab ein paar Beispiele eingebaut.
Danke benedikt,
aber hat nicht genutzt mit der Erweitung der Waitstate. und habe alle
Lötreste beseitigt, bei Blitzlampe tat es doch auch die Platine.
der HM62256ALP-70G würde auch mit deiner neuen HEX Funktionieren?
Danke
Momentan habe ich dazu leider keine Zeit. Und ehrlich gesagt habe ich da
auch wenig Bedarf daran, da das Display doch ziemlich groß ist.
Die Software war eigentlich auch mehr als Basis für eigene Erweiterungen
gedacht, so dass jeder selbst eigene Befehle implementieren kann. Dazu
gibt es die ganzen Schnittstellen Funktionen wie lcd_setpixel(). Damit
sollte sich eine eigene Schriftart schnell einbauen lassen.
Hallo,
bin heute auch dazu gekommen den Controller in Betrieb zu nehmen.
An dieser Stelle nochmal vielen Dank an Benedikt für Schaltung und
Software sowie Blitzlampe für die Platinen-Aktion.
Hallo!
Hat evtl. jemand noch so eine Platine für mich übrig?
Ich habe nämlich das Gefühl, dass ich das mangels Schaltplanlesekünsten
nicht so schnell auf Lochraster realisieren könnte... ;)
Ich würde sie sowohl neu, als auch fertig bestückt nehmen, natürlich
gegen entsprechende Bezahlung!
Reciht eigentlich ein alter Inverter aus einem Notebook oder brauche ich
da nochwas neues?
Und ausserdem frage ich mich ob es eine komplette Bauteilliste gibt??
MfG
Platine zum Abgeben hab ich leider keine mehr über. Auf Lochraster würd
ich das ganze nicht Aufbauen wollen wäre mir zuviel Drahtverhau.
Der Inverter aus dem Notebook sollte das Display zum leuchten bringen.
1
Bauteil Wert Device Package Description
2
C1 100n C-EUC1206 C1206 CAPACITOR, European symbol
3
C2 100n C-EUC1206 C1206 CAPACITOR, European symbol
4
C3 100n C-EUC1206 C1206 CAPACITOR, European symbol
5
C4 100n C-EUC1206 C1206 CAPACITOR, European symbol
6
C5 100n C-EUC1206 C1206 CAPACITOR, European symbol
7
C6 100n C-EUC1206 C1206 CAPACITOR, European symbol
8
C7 100n C-EUC1206 C1206 CAPACITOR, European symbol
9
C8 27p C-EUC1206 C1206 CAPACITOR, European symbol
10
C9 27p C-EUC1206 C1206 CAPACITOR, European symbol
11
C10 100n C-EUC1206 C1206 CAPACITOR, European symbol
12
C11 100µ CPOL-EUE5-5 E5-5 POLARIZED CAPACITOR, European symbol
13
C12 47µ CPOL-EUE5-5 E5-5 POLARIZED CAPACITOR, European symbol
14
C13 100µ CPOL-EUE5-5 E5-5 POLARIZED CAPACITOR, European symbol
15
C14 1n C-EUC1206 C1206 CAPACITOR, European symbol
16
C15 10µ CPOL-EUE5-5 E5-5 POLARIZED CAPACITOR, European symbol
17
C16 CPOL-EUE5-5 E5-5 POLARIZED CAPACITOR, European symbol
18
D1 1N4148 1N4148 DO35-10 DIODE
19
D2 1N4148 1N4148 DO35-10 DIODE
20
D3 1N4148 1N4148 DO35-10 DIODE
21
IC1 MEGA8515-P MEGA8515-P DIL40 MICROCONTROLLER
22
IC2 74AC02N 74AC02N DIL14 Quad 2-input NOR gate
23
IC3 74HC74N 74HC74N DIL14 Dual D type positive edge triggered FLIP FLOP, preset and clear
24
IC4 74HC157N 74HC157N DIL16 Quadruple 2-line to 1-line data SELECTOR/MULTIPLEXER
25
IC5 74AC573N 74AC573N DIL20 8-bit D latch BUS DRIVER
26
IC6 62256P DIL28-6 MEMORY
27
IC7 78XXS 78XXS VOLTAGE REGULATOR
28
IC8 MC34063AP MC34063AP DIL08
29
JP1 JP1E JP1 JUMPER
30
JP2 PINHD-1X4 1X04 PIN HEADER
31
JP3 PINHD-1X12 1X12 PIN HEADER
32
K1 AQV21SMD AQV21SMD DIL06SMD PhotoMOS Relay NAiS
33
L1 470µ L-EU0204/7 0204/7 INDUCTOR, European symbol
34
LED1 LEDCHIPLED_1206 CHIPLED_1206 LED
35
Q1 CRYSTALHC49U-V HC49U-V CRYSTAL
36
Q2 BC327 BC327 TO92 PNP Transistor
37
R1 2,2k R-EU_M1206 M1206 RESISTOR, European symbol
38
R2 47k R-EU_M1206 M1206 RESISTOR, European symbol
39
R3 1 R-EU_M1206 M1206 RESISTOR, European symbol
40
R4 47k R-EU_M1206 M1206 RESISTOR, European symbol
41
R5 3,3k R-EU_M1206 M1206 RESISTOR, European symbol
42
R6 330 R-EU_M1206 M1206 RESISTOR, European symbol
43
R7 330 R-EU_M1206 M1206 RESISTOR, European symbol
44
R8 100 R-EU_M1206 M1206 RESISTOR, European symbol
45
R9 0 R-EU_0207/10 0207/10 RESISTOR, European symbol
46
R10 0 R-EU_0207/10 0207/10 RESISTOR, European symbol
47
R11 560 R-EU_M1206 M1206 RESISTOR, European symbol
Hallo!
Schonmal vielen Dank für die Bauteilliste! Hat es was zu bedeuten, dass
manchmal der Wert fehlt?
Vielleicht findet sich ja noch jemand, der mir eine Platine schicken
kann.
Leider wäre eine einzelne oer 2 viel zu teuer...
MfG
Naja der Kondi C16 ist irgendwas zwischen 10µ und 47µ ich hab 22µ
genommen.
Der Speicher( IC6 ) muss Pinkompatibel zum Layout sein, ich hab den von
Reichelt genommen. (steht weiter oben welcher das ist)
Der IC7 ist ein 7805 im TO220.
Q1 ist ein 16MHz Quarz.
Led jenachdem was für eine Farbe man will. Ich hab sie gar nicht erst
bestückt, weil sieht man nach dem Einbau sowieso nicht.
JP1...JP3 sind Lötpads, die haben keinen Wert. Die Anbschlussklemme X2
auch nicht.
http://www.platinenbelichter.de/ macht dir die Platte zum guten Preis
allerdings ohne Lötstopp und keine Durchkontaktierung. Ist halt bissel
mehr gelöte nötig dürfte aber gehen.
Hallo!
Wo bekommt man dieses AQV21?
Ich versuche gerade alle Bauteile bei Pollin + Reichelt zusammen zu
suchen, aber ein AQV21 gibt es dort nicht?
Gruß,
Kain
Hallo nochmal,
Wenn ich es ersetze fallen K1 und R8 weg oder? (Ich beziehe mich auf den
Schaltplan im angehängten PDF)
Was ist R6? 1 Ohm? Wenn ja wieso?
Reichen überall 1/4 Watt Widerstände und 16V Kondensatoren?
Danke für eure Hilfe,
Kain
Vul Kain wrote:
> Wenn ich es ersetze fallen K1 und R8 weg oder?
Ja.
> Was ist R6? 1 Ohm?
Ja.
> Wenn ja wieso?
Strombegrenzung für den 34063
> Reichen überall 1/4 Watt Widerstände und 16V Kondensatoren?
Ja, solange nicht anders angegeben.
Wollte mir den Controller jetzt auch mal nachbauen. Hab aber noch ne
Frage zum Zuschalten von der Displayspannung.
Irgendwo hieß es mal, man könne bei manchen Displays auf den OptoMosFet
(bzw. aufs schalten überhaupt) verzichten.
Muss ich jetzt bei diesen beiden Displays
Pollin 120471
Pollin 120460
einen Schalter einbauen, oder kann ich ihn weglassen, weil die Displays
ja einen DISPOFF eingang haben?
Gruß, Sebastian
Jetzt hab ich doch noch ein Problem:
Hab die Schaltung nach deinem Plan aufgebaut und auch alles nochmal
überprüft, aber wenn ich einschalte ist bei mir das ganze Display nur
gelb. Hab jetzt das weiß-auf-schwarz Display von Pollin.
Das einzige was ich bisher festgestellt hab ist, dass die
Kontrastspannung von -17V im Leerlauf auf -11 bei angeschlossenem
Display zusammenbricht. Ist das normal? Hab die Schaltung für die
Kontrastspannung so wie im ersten Plan aufgebaut. Nur halt den Mosfet
hab ich nicht drin.
Sebastian
Hallo nochmal,
ich komm jetzt zwar auf -17 bis -18 Volt Kontrastspannung (auf Masse
bezogen), aber das Display ist immernoch einfach nur gelb. Im Datenblatt
steht doch -22V bezogen auf die 5V Versorgungsspannung, also -17 Volt
bezogen auf Ground.
Sind gute 200mA auf der 5V-Versorgung für die gesamte Schaltung +
Display normal?
Für alle die's interessiert: Ich hatte die Versorgungsspannung am
Spannungswandler nicht ausreichend gepuffert und zusätzlich auf meinen
Versorgungsleitungen so viel Spannungsabfall, dass die ganze Schaltung
nur noch mit gut 4 Volt lief.
Sebastian
Sebastian wrote:
> aber das Display ist immernoch einfach nur gelb.
Prüf mal nach ob die Signale vom AVR zum LCD wirklich richtig verdrahtet
sind oder ob da irgendwo was vertauscht ist, oder ein Kurzschluss ist.
> Sind gute 200mA auf der 5V-Versorgung für die gesamte Schaltung +> Display normal?
Kommt auf den Stromverbrauch vom Speicher, den Wirkungsgrad des
Spannungswandler usw. an. Ich komme auf 100-150mA, grob passt es also.
Hab jetzt nochmal nachgemessen. Konnte aber weder Vertauschungen noch
Kurzschlüsse finden. Mich irritiert auch das satte Gelb des Displays.
Woher könnte das kommen?
Sebastian
Sebastian wrote:
> Woher könnte das kommen?
Das kommt daher, dass das Display nicht richtig angesteuert wird und
daher dauerhaft die volle Spannung sieht, anstelle von 1/240tel der
Zeit.
Werde die schaltung morgen mit zu meinen Eltern nehmen, da hab ich ein
Oszi. Ich denke damit komm ich schneller auf den Fehler.
Danke schonmal soweit.
Sebastian
Oszi ist leider kaputt :-( Hab das Display aber trotzdem zum laufen
gebraucht. Hatte nach dem alten Plan gelötet in dem zwei Signalnamen
verdreht waren.
Vielen Dank an Benedikt für dieses Tolle Projekt.
Sebastian
Hallo,
da ich von AVR keine Ahnung habe, diesen nicht programmieren kann etc
(ich mache nur noch ARM7), wäre es möglich eine Platine mit fertig
programmiertem AVR zu bekommen, so dass ich diese als Black Box mit der
Uart meines ARM7 System verbinden kann?
Gruss,
Christian
>wäre es möglich das glcd über akkus zuversorgen.
wieso nicht? Wo siehst du das Problem? Du brauchst 5 Volt für die
Schaltung und etwas 150mA wenn du die Kontrastspannung aus dem Akku
erzeugst. Hintergrundbeleuchtung nicht mitgerechnet. Sollte halt nicht
grade ne Knopfzellen-reihenschaltung sein. Aber im Prinzip seh ich
nichts, was dagegen spricht.
Sebastian
Hallo,
ich werde diese Leiterplatten nachmachen lassen in blau. Natürlich
mehrere, damit der Preis stimmt.
Er wird 10€/Platte + 1€ Versand liegen für ca 20 Stück. Billiger wirds
erst wieder ab 100.
auf den Cent genau weiss ich das noch nicht, habe nur grob für 10
kalkukiert (1,0mm FR4, doppelseitig, durchkontaktiert, blau beidseitig,
geschnitten, 5 AT) incl. Ritzen des Nutzens. Lieferzeit ca 10 Tage ab
Bestellung.
Falls jemand welche haben will möge er bitte eine e-mail an
admin@der-scirocco.de senden die NUR folgenden Inhalt hat:
Name
Anschrift
Telefon
Anzahl !
Ich antworte mit meinen Kontodaten + Anschrift. Versand per Brief 1€.
Nur Vorkasse.
PS: Ich habe schon vor einem Jahr mal eine Sammelbestellung (HF Booster)
gemacht, diejenigen (zB Benedikt) wissen, dass die Ware auch ankommt.
Einsendeschluss ist der 1.5., dann geht die Bestellung raus, ich werde
trotzdem ein paar mehr machen lassen als Reserve. Grafikdisplay wollen
sicherlich viele haben zumal es einfach bedienbar ist. Vielleicht findet
sich ja auch noch jemand, der die "wesentlichen" Bauteile (zb ICs,
Quartz, Stecker) als Sammelpacks bestellt, damit nicht jeder sich die
zusammensuchen muss.
Benedikt.... kann bis dahin vielleicht die Software noch etwas
verfeinert werden? zb "Zeichne Koordinatensystem" Funktion (Achsen,
Teilstriche), Scrolling um eine Zeile für fortlaufenden Text?
Gruss,
Christian
Hallo,
ich werde die Platine noch um einen FPC Stecker erweitern für die Pollin
Displays. Kann mir jemand sagen welcher der Eagle 5.0 Lib da passt
(genauer Name und welcher Pitch)? Ich habe das Display nicht hier.
Benedikt, stimmt die Reihenfolge der Pins für das Pollin? Nicht dass die
nachher genau seitenverkehrt sind oder überkreuzt....
Christian J. wrote:
> ich werde die Platine noch um einen FPC Stecker erweitern für die Pollin> Displays. Kann mir jemand sagen welcher der Eagle 5.0 Lib da passt> (genauer Name und welcher Pitch)? Ich habe das Display nicht hier.
In Eagle 4.x gibt es zumindest keinen passenden Stecker, keine Ahnung ob
das mittlerweile drin ist.
Ich habe mal ein Foto von dem Display angehängt.
Die Kabel gehen auf der linken Seite vom Display raus, Pin 1 vom
Anschlusskabel ist oben. Die Kontakte von dem Folienkabel liegen auf der
Seite, auf der die Beschriftung auf dem Folienkabel ist (wenn man das
Kabel also ausklappt nach links, dann auf der Vorderseite). Das Kabel
hat ein Pitch von 1mm.
Hier gibt es das Datenblatt von einem sehr ähnlichen Display:
http://www.mark-products.com/pdf/g320x240/159/159%20spec.pdf
Die Belegung passt, die Spannungen passen, nur scheint da ein Stecker
anstelle des Folienkabels drauf zu sein.
Ich würde auf die Platine noch einen ISP Anschluss für den mega8515
machen. Dann kann man leicht die Software an eigene Bedürfnisse
anpassen. Die ganzen Schnittstellenfunktionen zum LCD Controller sind im
Programm ja enthalten.
Hallo Benedikt,
leider versthe ich Deinen Text nicht ganz. Um ganz sicher zu gehen
zeichne vielleicht die Belegung auf einem Foto des Kabels ein. Ich habe
das Display grad hier in der Firma. Auf der platine sieht man eine
kleine 2 neben dem Lötfeld. Bitte für Dumme mal erklären, ich möchte
keine Fehler machen. Eagle 5 hat hunderte dieser Stecker mit dabei. Ein
ISP Stecker würde den Rahmen sprengen, die Platte ist ja schon sehr
dicht. Ich möchte die Größe nicht wesentlich verändern. Da ich keine
Ahnung vopm Avr habe würde ich auch nicht wissen wo anschliessen.
Bisher 3 Bestellungen.
Christian J. wrote:
> Auf der platine sieht man eine kleine 2 neben dem Lötfeld.
Das ist der Rest der teilweise verdeckten 12. Oben ist Pin 1, unten Pin
12. Es stimmt also mit dem Datenblatt überein.
@Christian J. (elektroniker68)
ich hab noch mal wegen der LIB nachgeschaut, habe das nur mit der
Hand geroutet, eine LIB ist aber schnell gemacht
ISP sollte schon rauf, muss ja nicht , so wie bei mir, eine
Pfostenbuchse
sein
@Benedikt
wie schnell müssen die S-Rams nun wirklich sein , um den AVR nicht
auszubremsen
Wigbert
Wigbert Picht-dl1atw wrote:
> wie schnell müssen die S-Rams nun wirklich sein , um den AVR nicht> auszubremsen
Das hängt hauptsächlich von der "OE\ Access Time" des SRAMs ab:
Im Datenblatt vom mega8515, Seite 202, Tabelle 98, Punkt 10:
Read Low to Data valid: max 1.0*tclcl-50ns. Bei 16MHz ist tclcl=62,5ns.
Das SRAM darf daher maximal 12,5ns brauchen zwischen dem Anlegen des RD
Impulses bis die Daten stabil sein müssen.
Das von mir gerne verwendete IS61C256 Cache SRAM hat in der langsamsten
25ns Ausführung hier nur 9ns. Es ist also ausreichend schnell.
Bei der Low Power Variante IS62C256 dagegen, hat selbst die 45ns
Variante hier 25ns. Dies kann funktionieren, da die Werte jeweils die
garantierten Maximalwerte sind, muss aber nicht.
Es gibt Aussagen hier im Forum, dass selbst 70ns SRAMs ohne waitstates
funktionieren. Ausprobiert habe ich bis 35ns (nur Cache SRAMs).
Zusätzlich ist natürlich noch die Zugriffszeit wichtig:
Das wäre Punkt 5 im Datenblatt: Address valid to RD Low: 1.0*tctc-10ns.
Insgesamt ergibt sich dadurch eine Zeit von 2.0*tctc-20ns, also 105ns
zwischen Adresse gültig bis Daten stabil, was eigentlich alle SRAMs die
obige Bedingung erfüllen, auch erfüllen.
Das Latch ist da meiner Meinung nach absolut unkritisch, da die
Zugriffszeit ja im vergleich zu der OE Zeit des Speichers extrem groß
ist. Ich verstehe bis heute nicht, warum Atmel da ein AHC573 empfiehlt.
Hallo Wigbert,
12 Pins mit Pitch 1,0 reichen mir schon, die Lib gibt es. Senkrechter
Stecker wohl am besten.
Das ISP..... wer würde die Platine übernehmen, wenn ich das FPC drin
habe? Müsste nochmal aufgerippelt werden dann. 4 Befestigungsösen wären
schon sehr schön, dann kann man sie auf ein Demobrett schrauben. Oder
sag mir einfach mal einer an welche Pins das ISP kommt und in welcher
Reihenfolge. Ein paar Pfostenstecker dürften reichen. Dann wäre eine smd
Variante für den Avr ja auch wohl besser denke ich.
Also Tabelle:
Pin xyz ---- ISP Pin 1
Pin ....
usw.
(Status: 4 Bestellungen)
Stimmt schon was du aufgeschrieben hast.
Der Standard ISP Stecker ist ein 10 poliger Wannenstecker mit folgender
Belegung.
Wannenstecker ISP Signal
Pin 1 MOSI
Pin 2 VCC
Pin 3 NC
Pin 4, 6, 8 ,10 Gnd
Pin 5 Reset
Pin 7 SCK
Pin 9 MISO
Ach was ich noch sagen wollte, warum macht ihr keinen Bootloader auf den
Atmega dann könnte man das Teil in der Platte neu bespielen und man
könnte gleich die RX und TX Leitung der seriellen Schnittstelle nutzen.
Wäre doch die einfachste Lösung oder?
Nein, dann müsste noch ein Pegelwandler mit rein. Ich möchte da nicht
zuviel rumdoktorn.
Ich mache eine Pfostenleiste, Wannenstecker ist schon wieder zun gross
und ich denke mal die meisten haben diese Programmierdapater auch selbst
gebaut mit diesen kleinen Steckern.
Hi,
also ich könnte so auf die Schnelle mit S-Rams
IS61C256AL-12 oder
AS7C256A-12
aufwarten
@Benedikt
wären die schnell genug, bin mir mit dem DBL nicht so sicher
Wigbert
Wigbert,
ist leider nicht dabei und ich habe keinen Nerv den zu zeichnen, weil
ich ewig nicht mehr mit dem Eagle Designs gemacht habe. Hast Du da eine
Lib zu.?
Ich wollte auch einen stehenden verwenden, habe Hirose in der Lib aber
die gibts leider nicht bei Farnell mit dem Footprint.
Bei Digikey sind keine Bilder dabei. Es gibt hunderte davon. Leider
ebenso in der Eagle Lib.
Du, ich habe das letzte Mal vor 4 Jahren mit Eagle gearbeitet V3.xx.
V5.xx habe ich aber da ist zu viel Neues drin. Am Routen würde ich 3
Tage sitzen. Kann ich Dir das Board schicken und Du änderst das ab? Ich
kann mir keine Fehler leisten.
Zu ändern wären:
- Alle ICs durch smd Bauteile ersetzen, spart viel Platz. Schnelles Ram
gibts wohl auch nur als SO Gehäuseform, die DIPs sind aus der Mode.
(den AVR gibts als PLCC glaube ich)
- ISP Interface einfügen
- FPC Stecker
- smd LED vielleicht durch 3mm ersetzen, die hat jeder rumliegen.
So,
ich habe die Änderungen drin, also ISP und FPC Stecker. Alles andere
bleibt so. Bitte an blitzlampe er möge sich mal melden, da sind ein paar
Sachen im Board die wohl versionsbedingt nicht "fassbar" sind. Ausserdem
bin ich eine Null im Routen.
Die Sache steht und fällt allerdings mit der Beschaffbarkeit des obigen
FPC Steckers.
(5 Bestellungen)
Hallo Christian,
@ Christian J.
> Warten wir erstmal ab wie viele Bestellungen kommen. Die 10 müssen schon> voll werden.
Von mir wird auch noch ne Bestellung kommen, und ich hab ein paar Leute,
die sich auch dafür interessieren. Ich hab aber noch nicht von allen
eine Antwort bekommen. Momentan sind 4 Platinen sicher, es könnten aber
noch 4 weitere hinzu kommen. Sobald ich die genaue Anzahl habe, schicke
ich Dir ne Mail mit der offiziellen Bestellung und Anzahl.
Im übrigen würde ich es bevorzugen, die ICs auf der Platine im DIL zu
lassen. Denn das macht doch gerade den Charme der Platine aus. Die
meisten dürften noch nen 8515 in der Bastelkiste haben, und ein altes
Cache RAM findet sich auch ganz leicht. Also kann man die Schaltung mit
minimalem Kostenaufwand aufbauen. In SMD würde für mich bedeuten, dass
ich alles bestellen müsste, obwohl die meisten Teile schon da sind. Ich
wär froh, wenn ich die mal verbrauchen könnte. Ausserdem lassen sich DIL
ICs sockeln, was bei Modifikationen und weiteren Verbastelungen einfach
viel mehr Spaß macht.
Die ISP Signale noch rauszuführen wäre Spitzenklasse. Dabei würde es mir
reichen, wenn einfach die Pins 1-8, Reset, Vcc und GND direkt neben dem
DIL40 1:1 auf ein einreihiges Pfostenfeld gehen. Das braucht kaum Platz
im Layout.
Gruß und schonmal Danke für Deine Mühe
Kai
Hallo,
ich habe alles auf DIL gelassen, nur kam neben dem Pfostenstecker noch
ein FPC hinzu und eben der ISP. Bzgl Routen warte ich noch auf eine
Rückmeldung vonn blitzlampe, weil das jemand machen soll der mehr
Erfahrung hat als ich, es ist viele Jahre her bei mir.
Einer generellen smd Lösung stehe ich aber offen gegenüber, vor allem
wegen des Platzes, die Platine ist doch recht gross. Mal schauen,
vielleicht gibts ja auch zwei Varianten.
Ich halte das aber noch für ausbaufähig, da ich selbst mit Avr nichts am
Hut habe und dafür auch keinerlei Werkzeuge habe müssten das aber andere
machen. Die Doku ist noch verbesserungsfähig, vor allem das Laden von
Grafiken sollte verbildlicht werden, vielleicht mit Beispiel dazu. Was
mir noch nicht klar ist, wie das Uart Protokoll Befehlsende erkennt,
wenn zB die Daten abreissen oder aus dem Takt kommen.
Christian J. wrote:
> Was> mir noch nicht klar ist, wie das Uart Protokoll Befehlsende erkennt,> wenn zB die Daten abreissen oder aus dem Takt kommen.
Garnicht. Die Software erwartet exakt xs*ys Bytes an Bilddaten.
Das ganze war eigentlich als Embedded LCD Controller gedacht, der
parallel zur eigentlichen Software auf dem selben AVR läuft.
Die UART Ansteuerung war mehr ein Beispiel um von extern Grafik auf das
Display zu bekommen, daher ist das Protokoll sehr einfach gehalten.
Meinste, Du kriegst da noch einen Timeout hin? Wenn das Host System zB
resettet wird muss der Grafikcopntroller da ja irgendwie mitkriegen. Was
ganz einfaches halt, zb wenn 100ms kein Byte zur Uart kam wird
rückgesetzt.
Das halte ich für keine gute Lösung, denn dann muss man andauernd
sinnlose Daten schicken.
Ich würde dann eher die Resetleitung an den Master klemmen und so den
LCD Controller neustarten wenn der Master neustartet.
Hi,
Ich hätte folgenden Vorschlag:
ich könnte bis Ende der nächsten Woche eine Digikey Bestellung
rauszögern. Dann würden die FFC-Stecker Versandkostenfrei nach DL
kommen. Das Beste wäre wohl, alle nach Christian J. zu schicken,
und Christian legt sie bei Bedarf den Platinen bei.
Ahnlich könnte man es, bei Bedarf mit S-Rams machen.
Wigbert
So, hab mir das mal angeschaut, kannst du eventuell mir mal das Bord
zuschicken?
Wenn du Bilder vom Layout hochlädst würde ich den TStop und BStop Layer
ausblenden.
Das AQV21 könnte man ja mal gegen einen Typ ersetzen welchen man noch
bekommt bei Reichelt oder Conrad. Viele hatten mich nach Quellen für das
Teil gefragt.
Die Bohrung bei der Spule L1 ist von mir etwas ungünstig gesetzt wurden.
bedingt duch das Gehäuse läst sich dort nur schwer ne schraube
durchquetschen.
Die Bohrung für die Alternativen Spulen Pads sind auch etwas klein
ausgefallen.
Hallo Lampe,
ich sende Dir heute abend das Design zu wenn ich wieder zu Hause bin.
Schaus Dir bitte nochmal an und route es. Eine Resetmöglichkeit muss
aber unbedingt vorhanden sein als Synchronisationsmarke. Vielleicht
lässt sich in der Software ja doch was machen, vielleicht mit dem Busy
Pin, wenn der zB ab und zu mal als Eingang geschaltet wird. Dann kann
der Host einen Reset mit Low Pegel erzwingen, ich denke nicht dass der
Pin Schaden nimmt, wenn er ein paar Mikosekunden "gegen gepolt" ist.
Ich würde allerdings nur ungern als Bauteillieferant agieren, da das
dann ein Durcheinander gibt, oder aber der Stecker wird per se auf den
Platinenpreis aufgeschlagen, die 1,90 sind ja nicht die Welt und ohne
den ist es eine Frickelei. Ich denke aber, dass diese Projekt das
Potential hat als kompletter Bausatz angeboten zu werden, das ist mit
Abstand die günstigste Grafikdisplay Variante die ich je gesehen habe
und wenn keine Kinderkrankheiten mehr auftauchen kann das ein
Dauerbrenner werden. smd wäre natürlich noch schöner :-)
Wenn der Link stimmt sind so ein Stecker ca o,54 Euro Netto
soll wegen den paar Kröten jeder noch eine Briefmarke von mir bezahlen?
Aber macht wie Ihr denkt, wie gesagt, mein Angebot steht ....
Ein Bausatz zusammenzustellen ist vom Gesamtwert und der Menge wenig
attraktiv.
Wigbert
Hallo,
da ich leider ein 3 tage altes Backup zurückspielen musste und
idiotischweise vergessen haben die Outlook Datendatei zu sichern, bitte
ich alle, die sich gemeldet hatten für Platinen ihre Mail nochmal
abzusenden.
Tut mir leid, war aber nicht beabsichtigt.
(Layout ist fertig zum Review!)
Bitte um Rückmeldung, die Platine ist fertig !!! Wer kann ein Review
machen ???
Bitte dringende Bitte an jene, die noch welche haben wollen ihre Mail
nochmal zu senden, ich verschicke die Platine am Montag aber solange
keine 10 voll sind lohnt sich das nicht.
Hi,
Ich hab grad Eagle installiert, und schau mir das Layout mal an. Bei mir
ist es allerdings auch schon ein paar Jahre her, seit ich das letzte mal
was mit Eagle gemacht habe. Deshalb möchte ich erst mal nicht zu viel
versprechen.
Eine Sache ist mir aber auf den ersten Blick schon aufgefallen. Auf den
Top-Layer und auf dem Bottom Layer befindet sich eine gestricheltes
Rechteck, das einmal rund um die Platine läuft und teilweise mit
Leiterbahnen in Berührung kommt.
Da ich alle Lagen, die nichts mit Kupfer zu tun haben, ausgeschaltet
habe, fürchte ich dass das auch auf der Platine so sein wird. Diese
Strichellinie müsste man noch löschen, weil sie an manchen Stellen
Beinahe-Kürzschlüsse provoziert.
Gruß
Kai
Soo,
Jetzt habe ich mich auch daran erinnert, wozu die gestrichelte Linie
war. Vergesst das letzte Posting, war Blödsinn. Wie gesagt Eagle ist
schon etwas länger her. Das sind natürlich die Masseflächen.
Ich hab mich nun ein wenig mit dem Layout beschäftigt und noch ein
bischen Kosmetik betrieben. Folgendes ist mir aufgefallen bzw. habe ich
geändert.
- Der Beschriftungsdruck von SV3 war vertauscht.
- Verschieben einiger Leiterbahnen, um ein paar Unterbrechungen der
Masse-Flächen zu beseitigen.
- Einfügen einer 8-Poligen Pfostenleiste an den Pins 1-8. Dann sind
diese ungenutzten Pins für Basteleien zugänglich. Wers nicht braucht,
muss es nicht einlöten.
Die Änderungen habe ich diesem Posting angehängt. Wär nicht schlecht,
wenn sich noch wer anders findet und nochmal drüber schaut.
Gruß
Kai
Hallo,
muss Dich leider enttäuschen, die DRC Schablone von Bilex findet da 26
Fehler (1 Kurzschluss), was Distanzen etc angeht. Ich habe die
Platinenumrand absichtlich etwas erweitert, da muss Luft sein zum Rand
zum Ritzen und Schneiden. Lade Dir bitte die .dru Datei von Bilex
herunter oder nimm diese im Anhang und lass den DRC drüber laufen. Bilex
nimmt nur fehlerfreie Platinen an.
Lade dann Dein Board nochmal hoch.
Hallo,
wir haben fast 20 Platinen zusammen...... bitte alle nmochmal melden,
die mir in den ersten beiden Tagen geschrieben haben und nicht auf der
Liste stehen.
Bisherige Besteller:
O.Hagendorf (2)
k. Hingst (8P + 10 Buchsen)
M. Prader (1)
L. Jentsch (1)
W.Friedl-Grimm (1)
zu jeder Platine kommt die FPC Buchse hinzu.
Bitte die FPC Buchsen dann mal bestellen, mich kontaktieren wegen der
Rechnung und mir diese dann bitte zusenden.
>Bestell den mal, wenn er nicht passt geht das auf meine Kappe
und dann?
ob mal jemand, der die brd.Datei geladen hat, den Stecker mit dem
gerouteten Stecker vergleichen kann.
stimmen sollte das schon.
Wigbert
@ Christian J.
Mein DRC hatte keine Fehler gezeigt. Danke für den Tipp. Aber kein
Problem, die meisten Fehler sind schon raus. Knifflig wirds mit den
Abständen an den Platinenrändern.
@ Hauke Radtki
Ratsnest habe ich dann auch entdeckt. Musste mich erst wieder an das
Eagle Look&Feel gewöhnen. Aber langsam kommt das verstaubte Wissen
wieder ans Tageslicht.
Mir ist aufgefallen, dass die Elkos alle 5mm Raster haben. Die Elkos die
ich hier von Reichelt rumliegen habe, sind meistens im 2,5-er Raster.
Bei den nicht allzu großen Werten auch verständlich. Ich versuch mal
noch den Elkos ein zweites Rastermaß als Alternativbestückung
beizubringen.
Was haltet ihr davon der Schaltung noch einen Reset Taster zu verpassen?
Könnte derweil schonmal jemand den Stecker mit dem gerouteten Stecker
vergleichen?
Ich schick nachher nochmal einen aktualisierten Stand.
Gruß
Kai
Hi,
wie versprochen hier nun der aktuelle Stand.
Ich hab jetzt noch nen Reset Taster dazu gefummelt, und an den Elkos
sowie der Spule zusätzliche Pads für ein alternatives Rastermaß
eingefügt. Der DRC lief bei eben Fehlerfrei.
Da ich sicher auch Fehler mache, wers nett, wenn jetzt nochmal jemand
drüber schauen könnte.
Gruß
Kai
Hallo,
nimm bei der Drossel bitte auch 5mm Abstand. Ich habe hunderte davon
hier und kann die beilegen, meine haben einen sehr kleinen
Innenwiderstand, sind auf Ferrit gewickelt. Elkos ruhig alle auf 2,5mm,
notfalls nimmt man eben Tantals. 5mm würde ich weglassen.
Bitte das Layout dann heute noch schicken. Reset Taste braucht es wohl
eher nicht, der Platz wird langsam eng.
Kann eigentlih einer erklären, warum sich auf dieser Platine in der
Freeware Version von Eagle manche Bauteile nicht verschieben lassen.
Eagle hat mir jetzt ziemlich oft eine Meldung gegeben, dass diese
Operation mit der Freeware-Version nicht möglich sei. Setzt man das
Bauteil dann woanders hin, dann geht es. Die Platine ist doch nur 80x100
groß, dann müsste doch alles gehen?
Ich war wohl einen Tick schneller.
- Reset Taster ist drin.
- Raster 2,5 bei Elkos auch.
- Raster 5mm bei Drossel auch.
Schau mal bitte ob es so passt, mir laufen grad die Augen über.
Aktueller Stand ist als DIP3.zip im obigen Posting.
Die Raster 2,5 und 5 mm könnten evtl. nicht ganz exakt stimmen, weil ich
die Lötaugen von Hand platziert habe, und die Bauteile sich alle an
einem unterschiedlichen Raster orientieren. Das war wohl nicht von
Anfang an richtig eingestellt, oder ist geändert worden. 0,1mm hin oder
her dürften aber bei den bedrahteten Bauelementen kein Problem sein.
Gruß
Kai
Hallo,
der Reset Taster ist zwar wegen der Äthetik nicht mein Fall aber man
muss ihn ja nicht einbauen, Ich würde sagen wir lassen es jetzt so, wenn
die Steckerfrage geklärt ist. Gefällt mir gut.
PS: Vielleicht mal eine Eagle 5.x Vollversion besorgen :-) Ich habe bis
heute noch nicht kapiert wie man Innenlagen routet, geschweige denn wie
man das einstellt.
Mit der Freeware-Version gehen soweit ich weiss Innenlagen gar nicht.
Die Vollversion ist sicher nicht schlecht, aber für die wenigen Layouts
zu denen ich privat noch Zeit finde, lohnt sich die Anschaffung nicht.
Ich wollte mir eigentlich mal KiCAD genauer ansehen. Das ist OpenSource
und somit ohne Einschränkungen und Eagle sehr ähnlich. Denn manchmal
will man auch ne grössere Platine machen, auch wenn die Schaltung
einfach ist. z.B. um Befestigungslöcher zu irgendwas passend zu setzen.
Das wäre auch bei dieser Platine interessant gewesen. Dann hätte man die
Platine so dimensionieren können, dass sie genau auf die Langlöcher des
Displays passt.
Bzgl. dem Taster: Ich hab halt den genommen, den ich schon da hab.
Ausserdem ist er bei Pollin und Reichelt billig und leicht zu
beschaffen. Ich werd ihn wahrscheinlich auch erst dann drauflöten, wenn
ich vor habe an der Software rum zu stricken.
Gruß
Kai
Hallo,
ich weiss nicht, ob mein ARM7 stark genug ist um den reset Pull Up
herunter zu ziehen, der Arm kann nur ~0,8mA pro Pin. Es wäre auf jeden
Fall noch wichtig eine Synchronisation zu schaffen, damit das Protokoll
nicht durcheinander kommt. Sowas hat jede gute Statemachine drin.
Kann da jemand was per Software bauen? Ggf. ziehe ich dann statt dem
Reset Pin einen anderen Pin zur Uart leiste, der intern zurücksetzt,
wenn er low gezogen wird. Oder zB resettet die Uart wenn sie 100 Mal
0x00 bekommt oder irgendetwas anderes. Evtl ist ja noch ein Timer frei,
der ~50ms nach dem letzten zeichen die Statemachine zurücksetzt.
Warum? es muss vermieden werden, dass sich der Avr in einem
undefinierten Zustand befindet, wenn nicht alle Zeichen kommen. Das ist
zb immer der Fall, wenn jemand am Host System auf Reset drückt. Es gibt
dann keine Chance mehr den Avr dazu zuu bewegen, dass er wieder auf
Befehle wartet.
Wie gesagt, das MUSS ein richtiges System drin haben, das gehört zu
Statemachines dazu.
1. Timer überwacht Uart, kommt x ms kein zeichen mehr leert er Puffer
etc und setzt zurück. Hat ARM automatisch, komt 3 Perioden kein Zeichen
wird ein Flag gesetzt.
2. Ein Pin wird abgefragt, ist sehr zeitsparend.
3. Eine Befehlsfolge wird vereinbart, zB ein Kommando 0xff wird oft
gesendet bis AVR mit 0xnn antwortet. Da wäre aber nicht so gut, weil ein
TX Pin für den Host ausreichen soll, ein Display antwortet normalerweise
gar nicht, bzw muss es nicht.
meine bevorzugte Lösung: 1
Wenn eben möglich sollte uart auf 56700 hochgedreht werden.
Wie wärs einfach den Tx-Pin mit rauszuführen? Dann kann man je nach
bedürfnissen beliebig komplexe Bestätigungen zurücksenden bzw. über
diesen Pin synchronisieren.
Weils oben mal angesprochen wurde: Ich hab den Reichelt-Ram den Benedikt
ziemlich am anfang mal genannt hat (hat glaub ich 70ns). Der läuft bei
mir problemlos ohne Waitstates. Wie das bei einem anderen Exemplar ist
kann ich natürlich nicht sagen.
Sebastian
Hallo,
es gibt auch Leute die keinen Avr haben (zB ich :-) und es soll ja bei
mir als ARM, PIC user auch laufen. Ein biriktionales Protokoll ist immer
aufwendig, das mit der Busy leitung ist schon super, ein Tx, ein GND
und eine Busyabfrage. Über die Busyabfrage könnte auch was laufen, wenn
sie zB 10us auf Input geschaltet und gesampled wird, damit der Host dort
resetten kann.
Ich hoffe nur jemand kann das für mich irgendwann machen, da ich uzwar
jemanden habe, der Avr bespielen kann aber mehr auch nicht.
Wenn der reichelt läuft ist es doch gut.
PS: Ich habe inzwischen auch eine smd Version (AVR als TQFP) fast
fertig, die ist nur halb so gross. Nur die schwer zu beschaffenden
Bauteile als bedrahtet belassen bzw nur dann smd wenn Platz gespart
wird.
Hallo,
ich bitte alle Besteller eine Mail an admin@der-scirocco.de zu senden,
die NUR folgende Angaben enthält:
Betreff: Grafikcontroller
Name; Vorname
Lieferadresse
Telnr (für Komplikationen)
Anzahl Platinen.
Ich bestelle erst wenn ich alle Daten habe und schicke die Kontodaten
dann per Sammelmail raus. Die FPC Stecker sind fester Berstandteil der
Lieferung, kosten 70c glaube ich. Gratis gibts die Spule mit dabei.
Ich kann mit e-mails über kryptische Accounts ohne Name, ohne Adresse
wirklich nichts anfangen.
Gruss,
Christian
O.Hagendorf (2)
k. Hingst (8P + 10 Buchsen)
M. Prader (1)
L. Jentsch (1)
W.Friedl-Grimm (1)
T.Kalbe (2)
Bitte 32 FPC Stecker bestellen. Sonst geht es mit den Platinen nicht
auf. Ich hab Christian gebeten bei meiner Bestellung noch zwei mehr dazu
zu legen.
Kai
Hallo,
funzt der Inverter von Pollin an deren Displays? Die haben derzeit nur
einen einzigen im Angebot für 4,95€ mit Lampe.
Wird ja mal Zeit zu bestellen, nech? ;-)
Ja, der Inverter sollte gehen. Eventuell muss man die Betriebsspannung
etwas reduzieren, da der Inverter für längere Röhren (=mehr Spannung)
ausgelegt ist.
Ich betreibe die Displays immer mit der niedrigst möglichen Spannung, ab
der die CCFL sauber zündet.
Benedikt,
danke für die Info. Schwingst Du Dich nochmal an den Code Deines
Erfolgsprojektes wegen der notwendigen Synchronisation? Busy Pin etc?
Bei mir gehts leider nicht, weil ohne Arme keine Kekse, AVR ist für mich
kein Thema.
Christian J. schrieb:
> Schwingst Du Dich nochmal an den Code Deines> Erfolgsprojektes wegen der notwendigen Synchronisation? Busy Pin etc?
Wenn du mir genau sagst was ich machen soll, kann ich es versuchen.
Hi,
irgendeine Möglichkeit, den Controller in den Idle State zu kriegen,
d.h. wenn nach dem x.ten Byte der Strom abreisst aber y Bytes erwartet
werden muss er raus wieder in den Empfang. Der Busy Pin liesse sich doch
10us auf Input schalten und auswerten, der kurze Kurzschluss macht es ja
auch nicht.
Wie weiter oben erwähnt: Etwas besseres als den Reset Pin rauszuführen
fällt mir nicht ein.
Eine weitere Möglichkeit wäre zwischen Daten und Befehlen zu
unterscheiden (z.B. über ein bestimmtes Byte das vor einem Befehl
gesendet wird. Allerdings muss man dieses dann, falls es zufällig ein
Datenbyte ist, auch wieder extra kennzeichnen, was die Ansteuerung
wiederum aufwendiger macht.)
Bzw. eine Möglichkeit gibt es momentan schon: Worst case erwartet der
Controller 255x255=65025 Bytes.
Der Befehl 0 ist nop. Wenn man also 65025x 0 sendet, dann sollte der
Controller wieder bereit sein für neue Befehle.
Ich könnte das ganze noch auf 80x240=19200Byte begrenzen, dauert bei
57600Baud aber trotzdem noch 3,3s.
Hi,
mal für Dumme, war da nicht schon ein Busy Pin vorhanden,
der den Datenfluss stoppt und was soll synchronisiert werden?
Ok es gibt wohl keine Check Rückantwort,
das alles richtig angekommen ist, wäre bei Einsatz eines Abgesetzten
Displays vielleicht notwendig.
Wigbert
Wigbert Picht-dl1atw schrieb:
> mal für Dumme, war da nicht schon ein Busy Pin vorhanden,> der den Datenfluss stoppt und was soll synchronisiert werden?
Ja, den gibt es. Der stoppt die Datenübertragung wenn der Empfangspuffer
überläuft.
Leute,
nicht so schwerfällig. Jedes Protokoll MUSS eine Möglichkeit bieten,
dass es aus einemm fernen State zurück in den Idle State kommt. Die
ganze Sache ist ja nichts anderws als eine Statemachine.
Meinetwegen kann man das auch mit dem WDT machen, dass er aus einer
Empfangsschleife rausgeht, wenn keine neuen Bytes mehr kommen, jedoch
müssen natürlich die Inhalte des Sram unverändert bleiben.
Timeout ca 100ms. Derzeit hängt der Avr unrettbar fest, wenn das
Protokoll unterbrochen wird oder man sendet dermassen viel Müll rüber,
dass selbst die Bitmap Funktion überläuft.
Christian J. schrieb:
> Meinetwegen kann man das auch mit dem WDT machen, dass er aus einer> Empfangsschleife rausgeht, wenn keine neuen Bytes mehr kommen, jedoch> müssen natürlich die Inhalte des Sram unverändert bleiben.
Kann ich gerne einbauen, ist eine Sache von ein paar Sekunden. Aber wie
gesagt: Ich finde die Lösung nicht gut, denn dann resettet der AVR
ununterbrochen wenn keine Daten gesendet werden.
> Derzeit hängt der Avr unrettbar fest, wenn das> Protokoll unterbrochen wird oder man sendet dermassen viel Müll rüber,> dass selbst die Bitmap Funktion überläuft.
Das stimmt nicht: Wie oben geschrieben: Man muss einfach nur Daten
senden, damit die Funktion die erwartete Anzahl bekommt. Wenn man nicht
weiß wieviele, dann einfach 0en senden, denn die werden als Befehl
ignoriert.
Das geht in die oben erwähnte Richtung, dass es feste Werte gibt die
einen neuen Befehl ankündigen, ähnlich STX/ETX.
Soll ich das ganze auf solch ein Protokoll umbauen (ähnlich dem das ich
bei meinem 640x480 Controller verwendet habe)? Also alle Daten die
ankommen sind Bild oder Textdaten, erst wenn ein bestimmtes Zeichen
erkannt wird (z.B. der Escape Code 27), dann wird der darauffolgende
Wert als Befehl interpretiert.
Um den Datenwert 27 zu senden ist dieser 2x hintereinander zu
übertragen.
Das ganze hat dann den Nachteil, dass man nicht dumm die Bilddaten
übertragen kann, sondern alle Bytes auf den Wert 27 prüfen muss, und
diesen dann doppelt einfügen muss. Dies empfand ich als ziemlich nervig.
>Christian J. schrieb:>> Meinetwegen kann man das auch mit dem WDT machen, dass er aus einer>> Empfangsschleife rausgeht, wenn keine neuen Bytes mehr kommen, jedoch>> müssen natürlich die Inhalte des Sram unverändert bleiben.
Benedikt K. schrieb:
>Kann ich gerne einbauen, ist eine Sache von ein paar Sekunden. Aber wie>gesagt: Ich finde die Lösung nicht gut, denn dann resettet der AVR>ununterbrochen wenn keine Daten gesendet werden.
Ohne jetzt die Sourcen bzw. das Protokoll genau zu kennen, aber was
spricht dagegen den WDT erst dann zu aktivieren, nachdem das erste Byte
empfangen wurde und wieder zu deaktivieren, wenn alle Kommandos
abgearbeitet wurden?
Dann is ein einfacher Neueinstieg möglich, sollte ein Kommando
abgebrochen werden und der ständige Reset wird vermieden, wenn der Host
gerade keine Kommandos sendet.
Ohne jetzt die Sourcen bzw. das Protokoll genau zu kennen, aber was
spricht dagegen den WDT erst dann zu aktivieren, nachdem das erste Byte
empfangen wurde und wieder zu deaktivieren, wenn alle Kommandos
abgearbeitet wurden?
---
Wenn der Avr einen solchen WDT hat, der sich abschalten lässt wäre das
eine gute Lösung. Das Protokoll sollte einfach bleiben, so dass jeder
damit umgehen kann.
Ich habe mal den besagten Timeout eingebaut. Allerdings nicht global
über den WDT, sondern nur lokal in der Schleife die die Bilddaten
empfängt.
Bei allen anderen Befehlen hängt das ganze also weiterhin, was meiner
Meinung nach nicht schlimm ist, denn für die restlichen Befehle reichen
worst case 8 nops. Notfalls kann ich das aber noch einfügen, es macht
den Code halt etwas unleserlich und bläht diesen etwas auf.
Im LCD Interrupt wird eine Variable runtergezählt, und sobald diese 0
erreicht wird die Empfangsschleife für Bilddaten verlassen und mit den
normalen Befehlen/Daten weitergemacht. Dies hat den Vorteil, dass sich
auf dem Display nichts verändert, da der Controller ja weiterläuft und
nicht neu startet.
Das Timeout ist momentan auf 1s eingestellt, kann aber zwischen etwa
1/100 bis 3s verändert werden.
Die nächste Frage wäre dann noch die Baudrate:
57600 bei 16MHz ist grenzwertig (2,1% Fehler). Im 2x Modus reduziert
sich der Fehler auf 0,8%, allerdings gefällt mir der 2x Modus aufgrund
der 1x Abtastung nicht sonderlich, da hierdurch alles fehleranfälliger
wird.
Hier gibt es nun mehrere Alternativen:
- andere (höhere?) Baudrate, wie 62,5kBaud, 125kBaud, 250kBaud, 500kBaud
usw.
- 18,432MHz Quarz für etwas mehr Rechenleistung und alle
Standardbaudraten, dafür aber etwas außerhalb der Specs.
- 2x Modus nehmen und fertig.
Hallo,
lass mal die Baudrate so, die anderen kann ich nicht einstellen.
Mist, habe mein LPC2368 Board grad geschossen, der Proz ging in einer
Rauchwolke auf ;-(((((((( Wird wohl dauern ein neues aus China zu
kriegen.
Zwischenstand:
Das Geld ist von allen bis auf einen eingetroffen. Leider habe ich
bisher kein Feedback von Bilex-lp.com erhalten, auch auf Nachfrage
nicht. Die Firma habe ich mir empfehlen lassen aber ich denke, dass es
manchmal besser ist ein paar Euro mehr zu bezahlen und in Deutschland
fertigen zu lassen statt in Rumänien. Die haben nicht mal eine
Telefonnummer. Ok, das Geld habe Sie natürlich auch noch nicht. Erst
Ware dann Kohle.
Ich habe denen Frist gesetzt, danach werde ich woanders fertigen lassen.
Ob es bei den 11,50€ dann bleibt weiss ich jedoch nicht.
Es fehlen noch die Überweisungen von
Michael Prader
Wolfgang Friedl-Grimm
Bitte nachholen.
Bilex hat sich gemeldet, Platinen werden morgen eingestielt. Es werden
10 Stück Überhang werden, sind also noch welche zu haben.
Wie steht es mit den Steckern?
Benedikt, wärest Du vielleicht so nett und würdest mit einen
programmierten AVR senden mit der neuen Software? Ich überweise Dir die
Kosten dann sofort.
Christian J. schrieb:
> Benedikt, wärest Du vielleicht so nett und würdest mit einen> programmierten AVR senden mit der neuen Software?
Kann ich machen, sag mir mal die genauen Parameter für Baudrate usw. die
du haben möchtest.
Vermutlich wäre es aber besser wenn du dir einen einfachen Programmer
baust (die einfachen bestehen im Prinzip nur aus nem Stecker für den
LPT), da ich davon ausgehe, dass es doch mal noch die ein oder andere
Softwareänderung geben wird.
Hi,
ich hab 33 Stecker bei Digikey bestellt, da sie auch schon bezahlt
sind, kann ich die Stückzahl nicht mehr erhöhen.
Müsste Anfang der Woche in DL eintreffen.
Wigbert
Benedikt,
bauen wollte ich gar nichts, fertig kaufen ist besser. Gibt es sowas wie
Flashmagic + Programmierstecker fertig zu kaufen, also ohne grossen
Aufwand die Dinger bespielen?
Hallo,
leider gibt es mit Bilex Probleme. Die verlangen Vorkasse und dazu bin
ich nicht bereit, da diese Firma nicht in Deutschland ist und das auch
sehr unüblich ist. Bezahlung erst wenn Ware geprüft wurde, das ist meine
Vorstellung aus dem Geschäftsleben. Sollte ich mit denen nicht
übereinkommen werde ich einen anderen Hersteller suchen, etwas
beta-layout weil ich mit denen schon vor 15 Jahre gute Erfahrungen
gemacht habe.
Update: Mit Bilex nach Rümänien telefoniert und den Deal klar gemacht.
Kohle ist überwiesen.
Ja, es sind noch 10 Stück übrig. Bitte so verfahren, wie oben
beschrieben.
@Christian
> Sollte ich mit denen nicht übereinkommen werde ich einen anderen> Hersteller suchen, etwas beta-layout weil ich mit denen schon vor 15 Jahre >
gute Erfahrungen gemacht habe.
Hallo Christian,
Solltest Du den Hersteller wechseln, dann möchte ich die Gelegenheit
nutzen und noch ne kleine Layout-Änderung einbringen. Mein Kollege, der
Layouter ist, meinte: Es könnte evtl. mit den 10mil-Abständen Probleme
geben. Um ungewollte Brücken zu vermeiden habe ich deshalb die
Design-Rules mal auf 15mil verschärft, und die sich daraus ergebenden
Fehler beseitigt.
Die geänderten DRC-Rules habe auch beigelegt. Vor dem Ausführen der
Ratsnest Funktion sollten diese geladen werden.
Hier der neue Platinenstand. DRC ist jetzt wieder fehlerfrei.
Gruß
Habe sie hingeschickt aber keine Ahnung, ob das noch geht. Ist ein
bisschen spät und ob das jetzt den Unterschied macht? Die Platine wäre
ok sagten die.
8 Platinen sind noch übrig, zwei weitere Besteller kamen hinzu.
Christian J. schrieb:
> bauen wollte ich gar nichts, fertig kaufen ist besser. Gibt es sowas wie> Flashmagic + Programmierstecker fertig zu kaufen, also ohne grossen> Aufwand die Dinger bespielen?
Es gibt so ziemlich alles zwischen schnell und selbstgebaut bis hin zur
teuren, industrietauglichen Lösung:
http://www.mikrocontroller.net/articles/AVR_In_System_Programmer
Ob 10mil oder 15mil sollte eigentlich egal sein.
Wenn die mit 10mil Probleme haben, dann wäre der Laden schon lange
pleite. 8mil sollte heutzutage jeder Platinenhersteller können.
Kannst Du mir einen Link zu einer Fertigplatine geben die ich bestellen
kann, RS232 oder so? Software gleich dabei. Klingt doof aber icb will
mich damit nicht befassen, aufbauen etc, es nur benutzen für diesen
einen Zweck.
Christian J. schrieb:
> Kannst Du mir einen Link zu einer Fertigplatine geben die ich bestellen> kann, RS232 oder so? Software gleich dabei. Klingt doof aber icb will> mich damit nicht befassen, aufbauen etc, es nur benutzen für diesen> einen Zweck.
Hier mal ein Link, ist genau für das 320x240.
http://www.bue.de/produkte-und-dienstleistungen/mt-gr.html
Das MT/GR S Board
Bernd
Hallo Bernd,
die kenne ich, die gibts auch von Electronic Assembly, kosten so runde
180€ und beliefern auch keine Privatleute. Es gibt ohnehin nichts, was
es nicht gibt, wenn man bereit ist das zu bezahlen. Ob es das Hobby wert
ist sei dahingestellt. Das von Benedikt ist schon korrekt und vor allem
Open Source.
Ich meinte nur den Programmer für den AVR.
@Christian J. (elektroniker1968)
>Die Stecker sind leider auch noch nicht hier
kein Problem, Proformarechnung hast Du, nach Zahlungseingang
verschicke ich die Ware
Wigbert
> Mit Ausnahme eines Nichtbezahlers haben alle bezahlt,> Der Nichtbezahler hat dann leider Pech gehabt.
Das Geld ging letzte Woche Mittwoch raus. Also gib mal den Banken noch
etwas Zeit, es eilt ja nicht da du offensichtlich auch noch keine Ware
bekommen hast.
Bitte den Namen oben editieren und unkenntlich machen.
Da der Beitrag nicht mehr editiert werden kann, habe ich diesen mal
gelöscht, hier ist der Inhalt mit dem Namen unkenntlich gemacht:
Christian J. schrieb:
> Update:>> Mit Ausnahme eines xxx haben alle bezahlt, xxx hat dann leider> Pech gehabt.>> Die Platinen sind leider noch nicht da, finde ich schon etwas heftig, da> die 5 AT garantieren. Die Stecker sind leider auch noch nicht hier> angekommen, Adresse hatte ich aber geschickt.
Hallo,
hab dem Code ne Erweiterung zum entprellen einer Tastenmatrix
hinzugefügt.
Ich denke zum Debuggen ist das dann super. Display und Taster mal
schnell an ein Projekt unkompliziert über die UART anschließen - dürfte
einiges vereinfachen.
Ist für eine 2*4 Matrix, also 8 Taster. Der entprellte Zustand wird bei
jedem Wechsel über UART ausgegeben. 2*4 Tasten, weil ich die anderen 2
Pins wahrscheinlich noch brauch, 8 Taster für mich reichen und der
Aufwand für eine neunte Taste bei 3*3 unverhältnismäßig hoch gewesen
wäre. Außerdem müsste man sich bei mehr als 8 Tastern schon wieder
gedanken über das Interface machen.
Ich würde das gerne hier online stellen. Hatte aber etwas probleme
Benedikts Sourcen im AVR Studio (mit gcc) als Projekt zu öffnen.
Dementsprechend schaut das ganze momentan sehr wild aus.
Wenn mir jemand erklärt, wie das zueg sauber öffnen kann stell ich meine
Sourcen gerne hier rein.
Sebastian
Ich musste gerade feststellen, dass die neueren Versionen von WinAVR
12Bytes mehr Stack verschlingen als die 2007er Versionen. Somit lag der
komplette worst case SRAM Verbrauch bei 518 Bytes was in ungünstigen
Situationen (der Timer Interrupt tritt auf, während eine Box gezeichnet
wird und er befindet sich gerade in der Set Pixel Routine) zu Problemen
führt.
Daher habe ich int main(void) __attribute__((OS_main)); dem Code
hinzugefügt, um das Sichern der Register vor dem Aufruf von main zu
unterdrücken. Damit werden 15 Bytes eingespart, so dass nun wieder ein
klein wenig mehr Platz im SRAM ist.
Die älteren Versionen von WinAVR können damit nichts anfangen, daher
wird dieses Attribut mit einer Warning ignoriert. Dies macht aber
nichts, denn bei denen reicht der RAM auch so.
Im Zweifelsfall kann man den Stack hiermit prüfen:
Beitrag "StackViewer (RAM Rechner) für WinAVR"
Damit sollte mit der 20090313 Version ein Wert von 503 Bytes rauskommen.
/** Size of the circular receive buffer, must be power of 2 */
#define UART_RX_BUFFER_SIZE 250
Passt doch nicht ganz zam, oder? Power of 2 heißt doch 2-er Potenz,
demnach wäre 128 und 256 möglich. Nachdem 256 zu groß ist also 128. Oder
sind hier tatsächlich vielfache von 2 gemeint?
Die Kommentare passen nicht mehr ganz. Das ganze war mal die UART Lib
von Peter Fleury, mittlerweile ist allerdings nicht mehr viel von dem
eigentlichen Grundgerüst davon übrig geblieben, da ich alles etwas an
meine Bedürfnisse angepasst habe (so wie z.B. das Hardware Handshaking
wenn der Puffer voll wird). Jetzt sind damit auch beliebige UART
Puffergrößen möglich.
Das war eine Version die ich wieder gelöscht habe, da mir kurz darauf
eingefallen ist, dass ich diesen Trick mit den Registern vor main machen
kann, und so nicht den UART Empfangspuffer zu verkleinern brauche.
In der aktuellen Version (die von heute) steht genau an der Stelle ein
Puffer von 250 Byte. Aber Benedikt hat das ja schon geklärt.
Aber nochwas: Wenn ich die aktuelle Version durch StackView schicke
bekomm ich immer 483 Byte Ramverbrauch. Sowohl mit der Comilierten
version von Benedikt als auch wenn ich es selbst mit Version 20090313
compiliere.
Sebastian
Was für eine Optimierung hast du eingestellt?
-0: geht nicht, da zu wenig Flash
-1: 513
-2: 503
-3: 484
-S: 469
Der Stackverbrauch alleine schwankt also zwischen 75 und 119 Bytes. Das
finde ich schon recht heftig.
Ich verwende meinst -2 da die -S ab und zu dazu tendiert anstelle von
Inline lieber eine Bibliotheksfunktion aufzurufen, auch wenn dies sehr
viel langsamer ist.
Zeigt das Programm zufällig irgendwelche Errors oder Warnings an?
Falls nein, poste mal bitte die erzeugte calltree.txt.
Eigentlich müsste nämlich das selbe rauskommen.
Ich habe mal die verschiedenen Optimierungsstufen verglichen:
-0 ist eindeutig das schlechteste, ist klar.
-1 ist etwas besser aber auch noch suboptimal.
-s, -2 und -3 sind geschwindigkeitsmäßig ähnlich. Die lcd_init (die auch
das Begrüßungsbild erzeugt) benötigt bei allen Varianten 207,8 +/-0,1ms.
Dies dürfte vor allem daran liegen, dass die häufig verwendeten
Funktionen in Assembler geschrieben sind, und daher bei allen Varianten
identisch sind.
Der Geschwindigkeitsvorteil der -2 Version wird ziemlich durch das
vermehrte sichern der Register kompensiert, so dass die -s Version
aufgrund des geringeren Stack Verbrauchs die beste sein dürfte.
Ich denke es hat sich erledigt. Ich hatte die version mit 250 Byte UART
Fifo runtergeladen. Hab mir die Zip also genau zum falschen Zeitpunkt
gezogen. Dass du das zip nochmal aktualisiert hast ist mir erst jetzt
aufgefallen. Kann jetzt nicht sagen, was ich mit der neuen Version an
Ram-Verbrauch bekomme, weil ich hier kein Studio/gcc hab, aber ich denke
mal es sollte dann passen.
Sebastian
Fehlermeldungen gibts keine. Hab jetzt mal das Projekt wie ichs im
Studio compiliert hab angehängt. Ist die version mit 250 Byte UART FIFO.
Im Zip sind außerdem die Calltree und die StackView-version mit der ich
das erzeugt habe, damit man auch alles nachvollziehen kann.
Ich denke aber, das register-sichern vor der Main zu unterdrücken
schadet keinesfalls. Erst recht wenn jemand erweiterungen schreiben will
und nicht wirklich über den Ram nachdenkt.
Was mir grad noch auffällt: Kann es sein, dass du deine Version vom
StackViewer noch nicht online gestellt hast? Bekomme nämlich auch bei
der aktuellen LCD-Version mit 256Byte UART FIFO nur 475 Byte
Ram-Verbrauch.
Sebastian
Könnte mal jemand die letzte Version der Software online stellen? Ich
weiss immer noch nicht wie ich einen programmierten Chip kriege :-(
Ach ja: Die Platinen sind seit dem 13.5. unterwegs nach Auskunft von
Bilex. Kann sich ja nur noch um Tage handeln, bis die eintrudeln.
Erfreulichweise sind auch alle Zahlungen da.
Es sind noch 4 Platinen übrig.
Die Software ist hier:
http://www.mikrocontroller.net/attachment/51086/lcd_con_320x240.zip
Den Chip schicke ich heute weg, ich musste erstmal passende
Luftpolsterumschläge besorgen, da ich mit normalen Briefumschlägen bei
so dicke Sachen schlechte Erfahrungen gemacht habe.
Hi,
dann sende mir auch Deine Kontodaten per e-mail. Die Stecker sind heute
schon angekommen, danke für den schnellen versand. Leider passen sie
nicht auf das Kabel...... :-(
Quark.... Die Schuhe passen wie angegossen :-)
Versand geht los, sobald ich die Platinchen endlich habe.
Es wächst und gedeiht, leider noch nicht alle Bauteile zusammen....
Der Elko rechts verdeckt leider etwas das Bohr-Loch, denke ich werde die
Platinen nochmal einstampfen und neue machen lassen, sowas geht ja gar
nicht ;-)
PS: Es sind noch 3 Platinen zu haben, jedoch ohne FCP Stecker. Die
sind alle.
Das war nur fürs Foto. Inbetriebnahme natürlich wie immer ohne ICs,
durchmessen der Spannungen und dann erst die ICs rein.
Für welche RAM Zeit sind die Delays denn eingestllt? Ich habe nur noch
uralte SRAM hier, vermutlich so 8 Jahre alt. Keine Ahnung ob die
funktionieren.
Ach ja, es gibt noch einige Punkte:
- R8 hat 1 Ohm?
- Ein Kondensator in der Liste hat keinen Wert
- Kann der Ladekondesator der Spg.pumpe 100uF sein? Grössere passen
leider nicht rein.
- Kann ich auch eine 180uH Spule nehmen? 470uH scheint mir etwas viel zu
sein. Von den 180uH habe ich hunderte, die kann ich beilegen.
- Kann der 100 Ohm Widerstand am BC327 auch 150 Ohm sein? Warum sind die
Werte an der Basis so klein? Bei mir liegen die immer im Kiloohm
Bereich.
Glaube der ist auch überflüssig, bei den kleinen Strömen hätte man den
internen Transistor nehmen können.
Mich wundert nur, dass kein Poti frü Kontrast da ist, lässt der sich
einstellen?
Christian J. schrieb:
> Für welche RAM Zeit sind die Delays denn eingestllt? Ich habe nur noch> uralte SRAM hier, vermutlich so 8 Jahre alt. Keine Ahnung ob die> funktionieren.
Die Delays sind für die schnellen RAMs, die ich auch empfehlen würde.
Dein RAM scheint 120ns zu haben, das dürfte etwas zu langsam sein.
Abgesehen vom Bildinhalt sollte die Schaltung aber dennoch
funktionieren.
> - R8 hat 1 Ohm?> - Ein Kondensator in der Liste hat keinen Wert> - Kann der Ladekondesator der Spg.pumpe 100uF sein? Grössere passen> leider nicht rein.
Auf welchen Schaltplan bezieht sich das?
> - Kann ich auch eine 180uH Spule nehmen? 470uH scheint mir etwas viel zu> sein. Von den 180uH habe ich hunderte, die kann ich beilegen.
Ja, sollte gehen.
> - Kann der 100 Ohm Widerstand am BC327 auch 150 Ohm sein?
Ja. Die Werte sind alle eher unkritisch. Nur der Spannungsteiler der die
Ausgangsspannung des 34063 einstellt sollte in etwa das gleiche
Verhältnis haben wie die angegebenen Werte.
> Warum sind die> Werte an der Basis so klein? Bei mir liegen die immer im Kiloohm> Bereich.
Weil der Transistor schnell schalten soll um einen hohen Wirkungsgrad zu
erzielen. Desweiteren fließen bei 330 Ohm gerade mal etwa 13mA
Basisstrom.
Bei ein paar 100mA Spitzenstrom sind die auch notwendig.
> Glaube der ist auch überflüssig, bei den kleinen Strömen hätte man den> internen Transistor nehmen können.
Der interne Transistor ist ein NPN Darlington. Der hat also >1V
Spannungsabfall. Das sind alleine >20% bei 5V die hier verloren gehen.
Der externe PNP hat dagegen wenige 100mV Spannungsabfall.
> Mich wundert nur, dass kein Poti frü Kontrast da ist, lässt der sich> einstellen?
Per Software (Befehl 15).
Hallo,
danke. Es gibt aber ein problem: Der DC/DC Wandler arbeitet nicht. Ich
habe alle ICs draussen und nur den Wandler Chip Drin. Ausgang: 0V.
Feedback Eingang auch 0V. Transistor hat an der Basis 5V.
Muss der AVR drin sein, damit der arbeitet?
Christian J. schrieb:
> danke. Es gibt aber ein problem: Der DC/DC Wandler arbeitet nicht. Ich> habe alle ICs draussen und nur den Wandler Chip Drin. Ausgang: 0V.> Feedback Eingang auch 0V. Transistor hat an der Basis 5V.
Mess mal die Spannung an Pin 4 vom 34063.
Der Ausgangselko dient wenn er leer ist als Brücke zu GND um den 34063
zu Starten. Wenn der Elko zu klein ist (<10µF) dann startet der 34063
nicht.
> Muss der AVR drin sein, damit der arbeitet?
Ja. Ohne den ist der Feedback Eingang offen und die Spannung schießt
nach oben. Testweise kann man C7 in diesem Schaltplan kurzschließen um
das zu umgehen.
http://www.mikrocontroller.net/attachment/44475/lcd_320x240.gif
Pin 4 ist -1.25V gegen Eingangs-Masse. Der Elko hat 100uF
C7 habe ich entfernt, da ich den für überflüssig hielt, hatte nicht
gesehen, dass der nicht parallel zu amdern war. Da scheint auch der
Fehler zu liegen. Tja, nicht so gut. Hoffentlich verlange die Leute
jetzt nicht ihr Geld zurück, denn der muss nun per Hand eingefügt
werden. Kann aber direkt auf zwei smd Pads gesetzt werden, mechanisch
sehr einfach.
Also, hier das Bild, wo der 10uF hinmuss. Direkt auf die smd
Widerstandspads löten, zwischen dem 47k und +5V.
Starten tut er leider immer noch nicht. Mist!
Christian J. schrieb:
> Pin 4 ist -1.25V gegen Eingangs-Masse. Der Elko hat 100uF
Wenn -1,25V anliegen, dann läuft die Schaltung doch.
Das hier ist die richtige Version, oder?
http://www.mikrocontroller.net/attachment/50561/DIP4.zip
Prüf mal R5. Wenn der fehlt, dann kommen nur -1,25V raus.
> C7 habe ich entfernt, da ich den für überflüssig hielt, hatte nicht> gesehen, dass der nicht parallel zu amdern war. Da scheint auch der> Fehler zu liegen.
Der ist nur für die PWM notwendig: Der glättet das PWM Signal mit R1 und
erzeugt so eine Spannung mit etwa 0-5V (bzw. etwas darunter). Um diesen
Wert lässt sich die Ausgangsspannung verschieben.
Hallo,
ich habe DIP3 machen lassen, da DIP4 zu spät nachgereicht worden ist.
Der hat nur 15mil statt 10mil Abstände. Macht aber nichts.
So, wir haben jetzt ein problem und Du kannst verstehen, dass ich nervös
werde, da die Leute funktionierende Platinen erwarten. Der Chip läuft,
den brauche ich nur in meine Lochraster zu stecken, wo er herkam aber da
ist er ein Aufwätswandler.
Widerstände etc sind drin, alle auch richtige Werte. Transistor
testweise getauscht. Den 10uF habe ich nachgefügt, war kein Thema.
Und er läuft eben nicht. Es stehen -1.25V an statt der -20 o.ä.. Da ich
mich blind auf eine richtige Schaltung verlassen habe stelle ich die
hier nochmal ein, damit jeder nachschauen kann, ob da was nicht richtig
ist ausser dem 10uF. Die Platinen sind einwandfrei.
Und hier von gegenüber.... mit dem 10uF auf den beiden Pads.
Ich finde da kein Problem. Auf dem Oszi ist auch deutlich zu sehen, dass
der Schaltet, ebensoo die Spulenschwingung, der Duty Cycle ist sehr
klein.
Christian J. schrieb:
> Und er läuft eben nicht. Da ich mich blind auf eine richtige Schaltung> verlassen habe stelle ich die hier nochmal ein, damit jeder nachschauen> kann, ob da was nicht richtig ist ausser dem 10uF. Die Platinen sind> einwandfrei.
Es sollte eigentlich funktionieren, und es tut es ja auch teilweise.
Wenn 0V oder irgendwas positives an Pin 4 anliegen würde, würde die
Schaltung nicht gehen, aber du hast ja -1,25V gemessen.
Wenn an Pin 4 -1,25V anliegen, müssen an Pin 5 0V anliegen: Der 34063
regelt auf +1,25V an FB gegen seinen Massepin.
Wenn das alles passt, dann muss es an R5 liegen:
Liegen an R4 0V oder +5V an, dann bildet dieser einen Spannungsteiler
mit R5, so dass die Spannung an Pin 5 kleiner wird und der 34063 daher
die Spannung hochdreht, also negativer macht.
Hallo,
also, meine Platine war nicht mehr zu retten, ich habe den Masseschluss
nicht gefunden und die Leiterbahn N$48 Stück für Stück aufgeschnitten.
Er war dann am IC Fuss aber nicht zu sehen und ich habe eine Stereolupe
hier. Ich werde das morgen mit Fädeldraht verdrahten, heute keine Lust
mehr.
Ich habe die anderen Platinen auch untersucht, sie haben alle keinen
Masseschluss dort. Jedoch sollte jeder seine genau unter der Lupe
anschauen oder auch durchpiepsen. Das geht sehr schnell. Diese grosse
Masseflächen haben auch ihre Nachteile.
Ich rede nochmal mit Bilex, ob die mit 10min nicht überfordert waren. Er
hat das Layout ja, da kann er notfalls auch 15 Mil einstellen, Eahle
wird er wohl haben.
Nachwort:
Ich habe alle Platten nochmal durchgepiepst an dieser Stelle und eine
weitere mit Kurzschluss gefunden. Ich habe durch Zufall ausgerechnet
eine der beiden erwischt. Optisch nicht zu sehen, freikratzen half auch
nicht. Es ist absolut unmöglich zu sagen, ob weitere zur Masse hin
existieren. Ich möchte auch das Risiko nicht eingehen, dass mir die
Platten wieder zugeschickt werden und das Geld verständlicherweise
eingefordert wird.
Es ist sehr schwer so etwas später zu finden, besonders wenn sie
bestückt sind. Perfekte Lösungen sind leider nicht möglich, ich bin
keine Firma, die sowas vorher ausführlich testen kann.
Ich habe daher Bilex gebeten auf deren Kosten neue Platten zu machen mit
15mil Abstand und wenn sie das nicht hinkriegen ohne Masseflächen. Da
sie im Ausland sitzen kann man eh nichts machen von hier aus.
Ich hätte lieber 20€ bei Beta zahlen sollen und eine elektrische Prüfung
mit dazu, diese Billiglohnländer haben immer ihre Tücken.
Sollte Bilex das ablehnen kann ich nur hoffen und bitte jeden, die
Platten vorher Punkt für Punkt gegen Masse durchzupiepsen. Ich habe noch
2 Überhangplatten extra. Bis auf den Elko, der wie oben gezeigt
eingelötet wird sind sie soweit ok.
Mir tut das sehr leid aber das konnte ich nicht vorher wissen.
mfg
Christian
So, habs jetzt selbst hinbekommen, die Sourcen halbwegs sauber als
Projekt zu öffnen, daher jetzt auch die versprochene Version mit
Tastenmatrix.
Ich verwende das ganze als Ein-Ausgabe-einheit für ein Gerät, könnte mir
das aber auch zum debuggen recht praktisch vorstellen.
Der Code ist für eine 2*4 Tastenmatrix. 3*3 bräuchte zwar nicht mehr
pins, der Aufwand in Software wäre aber deutlich größer. Die anderen
zwei Pins die noch frei sind werde ich wohl auch noch brauchen, daher
nur 2*4.
Die 4 Spalten müssen an PB0-PB3, die 2 Zeilen kommen an PB4 und PB5.
Pullups sind nicht nötig, da die internen aktiviert sind. Gleichzeitig
kann man 2 Tasten drücken. Wer mehr will muss noch Dioden in die Matrix
einfügen.
Der Debuggte Tastenzustand wird bei jeder Änderung über die UART
gesendet. Also z.B. Taste 0 Drücken --> 0x01 über UART, Taste 0 wieder
loslassen --> 0x00 über UART
Der komplette von mir zugefügte Code ist über define herausnehmbar. Wenn
er drin ist, braucht er 3 Byte im Ram. Sollte also noch reinpassen.
Sebastian
Hier mal eine neue Version mit einer modifizierten Graustufenerzeugung
(abschaltbar in der param.h).
In dieser Version wird das Flimmern von großen Graustufenflächen stark
reduziert. Dafür wird der Kontrast der Graustufen ein wenig schlechter.
Durch das geringere Flimmern kann man die Framerate auf 70-75Hz
reduzieren was mehr Rechenleistung für die Grafikfunktionen zur
Verfügung stellt.
Sag mal Benedikt, magst du mich nicht? Wenn du die neue Version ne halbe
Stunde ehr veröffentlicht hättest, hätt ichs mir sparen können, meine
Sourcen nochmal zu kopieren.
Naja, hab jetzt meine Tastenmatrix in die neueste Version eingebaut.
Also sowohl der GrayMod als auch Tastenmatrix, beides natürlich in der
param.h abschaltbar.
Zum USBProg: Ich verwend ihn schon die ganze Zeit und bin soweit ganz
zufrieden. Gibt aber teilweise schon Probleme, bis das ding mal läuft.
Da du ja sowieso nicht viel mit AVRs machen willst, sondern nur dieses
Projekt flashen willst (oder?) ist der USBProg wohl übertrieben. Ich
würd einen Programmer für den Parallelport empfehlen. Kommt mit einem
Bustreiber aus und war zumindest bei mir problemlos inbetrieb zu nehmen.
Und die Kosten sind auch vernachlässigbar.
Sebastian
Nee, Avr ist nicht meine Welt, nur hex File oder elf brennen was ihr
bastelt und gut ist es :-)
Fügt sich aber harmonisch in die Landschaft ein, Benedikts kleines
Kunstwerk :-)
Um hin und wieder ein fertiges Projekt zu flashen reicht ein
Parallelprogrammer allemal. Brauchst halt einen Parallelport dafür, den
hat ja heute auch nicht mehr jeder.
Schau dir mal das hier an:
http://www.mikrocontroller.net/articles/STK200
Sebastian
Benedikt?
Was muss in die Uart rein, damit ich einen String ausgeben kann? Deine
Doku ist da etwas unklar?
Also "Hallo Welt ausgeben"? geht das buchstabenweise oder gibt es einen
Befehl für den ganzen String?
Das verstehe ich nicht ganz in der Doku:
30 Ziel
Wert
Zeichen aus erweitertem Zeichensatz schreiben.
Ziel = 0: Benutzerdefiniertes Zeichen 0-15 schreiben
Ziel > 0: ASCII Zeichen 0-255 schreiben
32-255 Buchstaben an Cursorposition zeichnen, Cursor erhöhen
Wie schnell zieht die Busy Leitung rauf oder runter? Kann ich die sofort
nach dem Sendebefehl abfragen? Ach ja, geht die auf Low oder High?
Der 30 Befehl wird eigentlich nur benötigt um Sonderzeichen mit einem
ASCII Code <32 zu schreiben. Normalen Text kann man ganz normal senden,
denn alles >=32 wird als Text betrachtet.
Busy wird bei jedem empfangenen Byte neu ausgewertet. Wenn Busy aktiv
wird sind noch 32 Bytes im Puffer. Busy ist high aktiv. Solange es Low
ist kann man also gefahrlos mindestens 32 Bytes schreiben.
Dies dient dazu, dass man z.B. nur einmal vor jedem Befehl prüfen muss.
hallo,
schau doch einmal etwas weiter oben da ist doch alles zielich genau
beschrieben
zb. einen string ausgeben
befehl ist "17" Textcursor auf (x,y) setzen
X zählt in 8 Pixel Schritten, Y in Zeilenschritten
17 X0 Y0 ;zeile 0 , spalte 0
einfach eine tabelle anlegen zb.
zeile_1: .db"hallo welt",0
diese tabelle auslesen (wie man eine tabelle ausliest weist du
hoffentlicht) vorher natürlich 17 senden dann 0 dann nochmal 0
um diesen text oben links anzeigen zulassen
die befehle sind gut in der doku beschrieben
ich mache die nur mit Makros
Hallo,
ich stelle grad fest, dass sich die Rectangles gegenseitig
überschreiben, auch wenn die Füllfarbe 0 ist. Gibt es eine "transparent"
Farbe, so dass sich gegenseitig schneidende Rectangles machbar sind?
Hallo,
habe es jedenfalls ausführlich mit dem Arm7 System getestet und werde
heute abend mal anfangen eine TextScoll Funtion zu programmieren, wie
auf einem Terminal. Dann Koordinatensysteme, wobei ich noch nicht weiss,
wie ich da eine Art Smooth Scroll realisieren soll. Jedenfalls sind die
Möglichkeiten schier unbegrenzt. Klasse Sache Benedikt! Du solltest das
mit in den Shop nehmen als Bausatz.
Hi,
könntest Du diesen Befehl vielleicht mit etwas erklärendem Leben füllen?
Ich rätsel da immer noch herum.
Ich habe ein s/w Bild (1bpp) mit einer Auflösung von 211x144 Pixeln.
Abgelegt in 8Bit Datenbytes in einem Array mit der Grösse 3798 Bytes
(211x144 / 8 = 3798)
16 0xAA = Befehlswort
X,Y = Startkoordinaten Bildecke oben links?
XS,YS = da verliessen sie mich. 211x144?
Textzitat:
X
Y
XS
YS
Modus
Daten…
Bild an Position (x,y) mit Auflösung (xs,ys) laden. Auf diesen Befehl
folgen xs*ys (*2) Bytes mit Bilddaten. x und xs zählen Bytes (Nibbels).
x hat daher den Bereich 0-79 (0-159), xs den Bereich 1-80 (1-160). y und
ys zählen Zeilen. y hat daher den Bereich 0-239, ys den Bereich 1-240.
Modus schaltet zwischen 1bpp (0) und 2bpp (1) um.
0xAA dient nur als Sicherheitsbyte, damit nicht versehentlich dieser
Befehl (z.B.
aufgrund eines Übertragungsfehlers) ausgeführt wird.
Christian J. schrieb:
> Ich habe ein s/w Bild mit einer Auflösung von 211x144 Pixeln. Abgelegt> in 8Bit Datenbytes in einem Array mit der Grösse 3798 Bytes (211x144 / 8> = 3798)
Nicht ganz. Da in X Richtung immer ganze Bytes übertragen werden, ist
dein Bild 27x144 Bytes = 3888 Bytes groß.
> D.h. ein Bild kann nicht grösser sein als 255 Pixel?
Doch, du überträgst Byte Anzahlen. Maximal könnte ein Bild 255*255 Byte,
also 2040x255 Pixel groß sein.
> 16 0xAA = Befehlswort> X,Y = Startkoordinaten Bildecke oben links?
Ja, wenn das Bild z.B. an 0,0 soll dann 0,0.
Wenn es an 16,20 soll, dann 2,20 (da Bytes=8Pixel) in x Richtung.
> XS,YS = da verliessen sie mich. 211x144?
27, 144 da 27 Bytes pro Zeile und 144 Zeilen.
Das Vielfache von 8 Pixeln in x Richtung ist eine Einschränkung aber mit
der kann man leben, denke ich.
Im 4 Farbmodus sind es immer 4 statt 8 Pixel.
Ich habe das ganze bewusst etwas "merkwürdig" gewählt, aber das hat den
Vorteil dass die xs und ys Werte direkt die Anzahl an Bytes
repräsentieren. Somit kann man weniger beim Umrechnen falsch machen.
Hmmm..... mein VW Käfer sieht noch etwas abgeschnitten aus. So ganz
einfach ist das nicht. Habe auf 208x144 verkleinert. Scheint alles
richtig und doch ist er verschoben.
Die Datenbytezahl ist übrigens vom sizeof Befehl, sie war oben richtig.
Soviel Bytes waren im Array drin für 211x144.
Was mir seltsam vorkommt ist, dass der Versatz mitten im Bild anfängt.
Das sieht so aus, als wenn da irgendwie ein paar Bytes verloren gehen,
warum auch immer.
Verloren geht da nichts, ich frage Busy ab und benutze einen ausreichend
grossen Fifo Puffer für die Uart.
Die erwarteten Bytes stimmen aber exakt, danach geht er in die
Hauptschleife, der nächste Befehl der Text ausgeben soll wird sofort
erkannt.
Ich arbeite dran......
Ok, Entwarnung..... der Arm7 war beim Aufstarten wohl etwas schnell
dabei und hat dem Display keine Zeit gelassen zu initialisieren. Passt
jetzt alles, ohne Füllbytes.
Hi,
Ich seh grad, dass auf den Platinen der Bestückungsdruck auf der
Unterseite fehlt, und auf der Oberseite nur die Bauteilwerte, aber nicht
die Referenzierungsnummer, enthält. Um bei der Bestückung, insbesondere
der SMD-Bauteile, die Identifizierung der Bauteile zu erleichtern, habe
ich nochmal zwei zusätzliche Ansichten aus Eagle exportiert. Darin ist
die Referenzierungsnummer der Bauteile in rot gehalten.
Hier die erste Datei ...
Gruß
Kai H. schrieb:
> Hi,>> Ich seh grad, dass auf den Platinen der Bestückungsdruck auf der> Unterseite fehlt, und auf der Oberseite nur die Bauteilwerte, aber nicht
Aus Kostengründen, das Kleinzeugs war es nicht wert.
> die Referenzierungsnummer, enthält. Um bei der Bestückung, insbesondere
Weil Eagle bei 2 Platinen auf einer Seite neue Namen vergibt, die
fortlaufend gezählt werden.
In dem Schaltplan fehlt auch der 10uF Elko am DC/DC Wandler, den ich
verschludert habe, er aber unbedingt rein muss.
Habe schon die nächste Generation fertig, ganz ohne smd und eine nur smd
:-) Letztere ist noch wesentlich kleiner, fast die Hälfte. Ok, BF 0602
habe ich mal ausgelassen, die kriege ich nicht mal mehr mit einer
Pinzette zu fassen.
Benedikt?
habe Deinen neuen Code mit 56700 baud gebrannt und stelle fest, dass die
Grafik verzerrt wird. Um das zu beheben muss ich ein 150us delay
einbauen. Die Abfrage des Busy funktioniert technisch aber wirkt hier
irgendwie nicht. Ich glaube 56700 sind doch etwas überdreht ;-) Das
Flimmern ist aber schön weg.
Probier mal diese Version aus.
Wenn die funktioniert, dann wars die Pause beim Einschalten.
Falls nicht, dann baue mal vor dem Senden des Bildes eine Pause von z.B.
100ms ein. Falls es immer noch nicht geht, ist der Fehler bei 57600 Baud
doch zu hoch (58824Baud -> 2,1%).
Ich habe schon Bilder mit 250kBaud ohne Busycheck gesendet, da sollte
der Controller also 57600Baud spielend schaffen.
Hallo,
ich habe da noch andere Probleme geefunden bei der Textausgabe, die auch
"abgeschnitten" wurden, chaotische Zeichen usw (Fehler?). Es fehlten
auch einfach Zeichen zwischendrin. Seit ich den 28800er Chip wieder drin
habe läuft alles wieder.
Kannste vielleicht die Doku mal erweitern? Da fehlt auch noch der Kreis.
Ach ja, bei meiner Version lassen sich Rechtecke nicht ausfüllen, die
bleiben immer weiss innen und überschreiben andere Pixel auch nicht,
egal welche Farben ich einstelle.
Flashen ist derzwei schwierig, mein Arbeitskollege hat den Brenner
unterm Schreibtisch versteckt :-)
Christian J. schrieb:
> Kannste vielleicht die Doku mal erweitern? Da fehlt auch noch der Kreis.
Ist schon lange drin:
http://www.mikrocontroller.net/attachment/35222/320x240_Grafik.pdf> Ach ja, bei meiner Version lassen sich Rechtecke nicht ausfüllen, die> bleiben immer weiss innen und überschreiben andere Pixel auch nicht,> egal welche Farben ich einstelle.
Kann nicht sein, denn auf dem Startbild funktioniert es auch und das
sind die selben Funktionen.
Hallo Benedikt,
ich verfolge den Thread schon eine ganze Weile und bin begeistert, was
Du da auf die Beine gestellt hast. Da ich jetzt Verwendung dafür hätte,
habe ich mir ein Display besorgt. Der Aufbau erfolgte ohne Probleme.
Allerdings habe ich nur einen SRAM mit 128x8 (25nS) von Samsung im DIP
Gehäuse.
Jetzt das Problem. Nach einem Neustart wird alles normal dargestellt.
Nach ca. 15-20 Sekunden gibt es dann mehr und mehr Pixelfehler. Die
Adressen 15 und 16 habe ich unbeschaltet gelassen. (Ich war mir auch
nicht sicher ob ich sie auf GND oder Vcc legen soll) Weiterhin habe ich
noch einen nicht negierten Chip Enable, den ich auf Vcc gelegt habe. Was
könnte die Ursache sein ?
Benedikt,
wenn ich das richtig sehe ist noch viel Platz im Ram. Wäre es möglich
dieses in Codepages zu unterteilen, so dass eine neue Grafik im
Hintergrund aufgebaut und dann übergeblendet wird? Ich stelle mir so
einen Befehl Codepage-Select(1..n) vor.
Theoretisch ja. Ein Bild benötigt 9600Byte. Zur Vereinfachung der
Software verwende ich aber 16kByte für ein Bild. Durch die Graustufen
verdoppelt sich dieser Wert und füllt somit das ganze SRAM.
Wenn man also die Graustufen rausnehmen würde, würde es reichen.
Hi, tja, Graustufen geht bei mir leider nicht :-( Die Rechtecke bleiben
weiss. Der Rahmen lässt sich aber in der Farbe einstellen.
Bastle grad an einem Scolling des Textpuffers, weiss nur nicht ob das
ruckelfrei abgeht, wenn ich 800 Zeichen neu schreibe und das Scrolling
in einem internen Puffer vornehme. meine Write Befehle greifen auf
diesen zu und ich sende immer nur das veränderte Bild an das Display,
wenn sich die Quersumme einer zeile geänder hat.
Aufruf:
GDisplay_Draw_Filled_Rectangle(10,10,GD_X_MAX-10,GD_Y_MAX-10,100,255);
Routine
Hallo Christian,
hab auch schon über so eine erweiterung nachgedacht. Ich hatte mir
überlegt, einen größeren Ram zu nehmen und Adressleitungen der höchsten
Adressen dann über GPIO-Pins des Displaycontrollers zu steuern. Man
hätte dann einen Befehl mit dem man den Teil festlegt, in den
geschrieben wird, und einen, mit dem man sagt, wo gelesen wird.
Genau dafür hab ich auch die 2 Pins bei meiner Tastenmatrix
freigehalten. Dadurch, dass ich das 4-fache an Speicher verbauen würde,
könnten sogar auch die davon profitieren, die jetzt schon ne fertige
Platine haben: Mit Chip-Stacking werden zwei 32k-Rams gestapelt und die
CS-leitungen kommen (über Freiluftverdrahtung) an die Portpins. Man
hätte dann zwar nur 2 Bilder, aber immerhin.
Um die Vorfreude jetzt wieder etwas zu dämpfen: Ich brauch die
erweiterung momentan nicht. Ich weiß auch nicht, ob ich sie überhaupt
brauche oder ob mir die Performance so reicht. Bis ich das brauche ist
es sicher noch ein paar Wochen oder Monate hin. Wenn vorher was draus
wird war's reiner ehrgeiz. Momentan hab ich noch nichtmal den Ram.
Sebastian
Die Idee mit den mehreren Speicherseiten hatte ich vor kurzem auch mal,
hatte diese aber nicht weiter verfolgt. Da aber anscheinend Bedarf daran
besteht, wieso also nicht.
Hier mal eine erweiterte Version:
Man kann in der param.h zwischen 4 Graustufen und 2 Farben, also SW
umschalten.
Weiterhin kann nun nahezu der gesamte Speicher genutzt werden
(128x240Bytes=30kByte). Bei Graustufen bringt das nicht allzu viel, da
steht dann eine virtuelle Bildgröße von 512x240 zur Verfügung.
Bei 2 Farben dagegen, kann ein Bild mit bis zu 1024x240 Pixel
dargestellt werden (angezeigt wird natürlich nur ein 320x240 Ausschnitt
davon).
Wofür man das verwenden kann, keine Ahnung, seit kreativ...
Da in 1024 Pixel allerdings 3x das komplette Bild reinpasst, kann man im
Hintergrund ein Bild an eine Stelle außerhalb des sichtbaren Bereiches
laden und danach auf diesen Bereich umschalten.
Zum Einstellen der Position in 8 Pixel Schritten dient der Befehl 28.
Genauere Infos dazu stehen in der Anleitung.
Getestet habe ich diese Version nur mal schnell rund um das Laden von
Bildern rund um Befehl 28, also keine Garantie dass alles fehlerfrei
läuft.
Hallo,
also das mit den grauen Bitmaps haut irgendwie nicht hin. Ich habe beim
Grafikconverter alle Einstellungen ausprobiert, es wird nur Murks
dargestellt.
Wir haben:
Nulltransform
Floyd Steinberg
Graustufen Verfahren
Schwellwert Verfahren.
Und unten die Einstellungen für die Anzahl Farben, da habe ich 4 stehen
und habe Schwellwertverfahren ausgewählt. Die Datei ist doppelt so gross
wie die s/w Datei, d..h. es werden auch doppelt so viele Bytes
übertragen. Aber da läuft er aus dem Ruder.
Idee?
Oder hat mal jemand eine Graubild Datei mit Pixelgrößenangabe zum
testen?
Probier das mal aus:
Das ist das komplette Bild, inklusive aller Befehle. Du musst also nur
das komplette Array an das LCD senden.
Auflösung: 240x240, 2bpp
@ Benedikt K. (benedikt) (Moderator)
mal so zwischendurch als Ponyprog Fan:
im letzen Code(Fusebits) wird -Boden ; -Bodlevel programmed
wäre dann der AVR nicht < 4V inaktiv. Warum stellest Du dann 4V noch
mal extra ein? (geht bei Ponyprog wohl nicht)
Schönen Feiertag noch
Wigbert
Wigbert Picht-dl1atw schrieb:
> im letzen Code(Fusebits) wird -Boden ; -Bodlevel programmed> wäre dann der AVR nicht < 4V inaktiv.
Ja.
> Warum stellest Du dann 4V noch> mal extra ein? (geht bei Ponyprog wohl nicht)
Das was darunter steht sind die Klartextbedeutungen der oben
eingestellten Bits. Die am häufigsten benötigten Einstellungen habe ich
in meinen Programmer einprogrammiert, so dass ich nicht immer die Bits
zusammenklicken muss, sondern ich wähle z.B. int 8MHz und BOD auf 4V
aus, er setzt die passenden Bits, und die schreibe ich dann in den AVR.
@Benedikt K. (benedikt) (Moderator)
Dank Dir,
interessanter Programmer(vorprogrammiert?) Wo finde ich sowas?
Ach,ja wäre es möglich, die Hex mit aktivierter
Grayscale(4 Graustufen)von Dein "Lcd_con_320x240 Mod.zip"
reinzustellen.
Sorry, mach ja sonst nur was in Bas...
Danke....
Wigbert
Wigbert Picht-dl1atw schrieb:
> interessanter Programmer(vorprogrammiert?) Wo finde ich sowas?
Ist Marke Eigenbau, eine Weiterentwicklung von einem AT89Sxxxx ISP
Programmer, da es damals nichts billiges an ISP Fertiggeräten gab.
AvrStudio sollte aber eine ähnliche Funktion bieten um die Fusebits
einzustellen.
> Ach,ja wäre es möglich, die Hex mit aktivierter> Grayscale(4 Graustufen)von Dein "Lcd_con_320x240 Mod.zip"> reinzustellen.> Sorry, mach ja sonst nur was in Bas...
Welche Baudrate soll ich einstellen?
38400 ist die, die bei mir im dauerfeuer funzt ohne dass es zu Verlusten
führt. 56700 klappte nicht, der Busy Pin reagiert einfach nicht, ich
frage den immer vor jedem Byte ab was ich sende.
Naja, vielleicht bin ich auch nur zu blöde. So jetzt aber raus nach
draussen, Spitzenwetter.
@ Benedikt
>Welche Baudrate soll ich einstellen?
56K7 wäre wohl in der mainc. definiert.
Ich dachte wir bleiben dabei ?
muss aber wirklich nicht sofort sein und gebe Christian recht:
>So jetzt aber raus nach draussen, Spitzenwetter.
Wigbert
Christian J. schrieb:
> 38400 ist die, die bei mir im dauerfeuer funzt ohne dass es zu Verlusten> führt. 56700 klappte nicht, der Busy Pin reagiert einfach nicht, ich> frage den immer vor jedem Byte ab was ich sende.
Deine Probleme mit 57600Baud gehen mir nicht aus dem Kopf.
Momentan streame ich gerade ein Video mit 500kBaud auf das Display. Das
sind im Graustufenmodus leider nur 2fps, aber egal.
Jedenfalls schafft der Controller die Verarbeitung von so vielen
Graustufendaten nicht und aktiviert Busy, was mit CTS vom UART des PCs
verbunden ist. So wird der Datentransfer ausgebremst (auf ca 310kBit/s).
Das funktioniert wunderbar, ich habe zumindest schon >50MByte ans
Display gesendet, ohne Probleme.
Die einzigen Probleme die ich mir vorstellen kann, sind eine nicht ganz
exakte Baudrate von deinem ARM:
Bei mir sind 57600 Baud in Wirklichkeit 58823 Baud. Das sind 2,1% zu
viel.
Das sollte aber kein Problem sein, denn erst ab >4% treten Probleme auf.
Außer deine Baudrate ist auch nicht genau und weicht in die
entgegengesetzte Richtung ab. Schau mal nach ob das vielleicht zutreffen
kann.
Ansonsten kannst du auch einen 18,432MHz Quarz einbauen, dieses minimale
Übertakten schafft der mega8515 meist problemlos. Damit sollten die
ganzen Standardbaudraten ohne Fehler möglich sein.
Die maximale Baudrate die möglich ist, ist übrigens 500kBaud. Alles
darüber (was nur 666kBaud, 1MBaud und 2MBaud wären), schafft der
Controller nicht weil der UART Hardwarepuffer überläuft, da der
Interrupt zur Datenausgabe ans LCD zu lange braucht.
Oder probier mal diese Version aus:
Ich habe die UART Routinen nun erweitert, dass automatisch ab einem
Fehler von >1,5% in den 2X Modus umgeschaltet wird. Dadurch reduziert
sich der Fehler auf 0,7%.
Die Version ist auf 2bpp, 57600Baud eingestellt.
Hallo Benedikt,
ich hätte mal rein interessehalber eine Frage (der Aufwand würde sich
wohl nicht lohnen):
Ziel der Überlegung ist es, einen höheren Pixeltakt zu erreichen ohne
die Prozessorlast zu vergrößern bzw. eben den AVR zu entlasten.
Man hängt zwischen Pin5 des 74HC02 (Das Gatter von der CP-erzeugung) und
das RD-Signal einen Flankendifferenzierer. Also bei jedem Flankenwechsel
von RD gibts einen kurzen Puls auf CP. Auf diese Weise könnte man mit
jedem ld Befehl des AVR ein ganzes Byte zum Display schicken, da das
Display mit steigender und mit fallender Flanke von RD Daten übernimmt.
Der Multiplexer ist ja über das Flipflop auch von CP gesteuert. Bzw.
wäre zu überlegen, ob man A\/B dann nicht direkt an RD hängen könnte.
Der Flankendifferenzierer müsste etwa 100ns lange Pulse rausgeben, damit
es zum Display passt. Zwischen die I/O des SRAM und den Multiplexer
müsste wohl noch ein Latch, da ja das zweite Nibble erst ans Display
gelegt wird, wenn RD wieder High geht. Dann sind aber auch die I/Os auf
High-Impedance. Also einen Latch der die Daten bei einer steigenden
Flanke von RD latcht.
Wie gesagt, man müsste dann mit einem ld-Befehl pro Byte statt einem pro
nibble auskommen und hätte fast die Hälfte der Prozessorlast gespart.
Dann sollten auch höhere Frameraten beim Video streamen möglich sein,
oder?
An sich müsste es dann doch sogar gehen, 8 Graustufen darzustellen,
oder? Macht das Display (zb. die hier zuerst genannten von Pollin) das
mit? Der SRAM reicht ja für 3 Monochrombilder aus, also auch für ein
3-Bit-Bild.
Würde mich mal interessieren, was der Experte zu diesen Überlegungen
sagt.
Gruß, Sebastian
Sebastian schrieb:
> Man hängt zwischen Pin5 des 74HC02 (Das Gatter von der CP-erzeugung) und> das RD-Signal einen Flankendifferenzierer. Also bei jedem Flankenwechsel> von RD gibts einen kurzen Puls auf CP. Auf diese Weise könnte man mit> jedem ld Befehl des AVR ein ganzes Byte zum Display schicken, da das> Display mit steigender und mit fallender Flanke von RD Daten übernimmt.
So eine ähnliche Schaltung gab es mal in der Elektor für einen
Displaycontroller für einen 8051. Da dieser langsamer ist, bleibt mehr
Zeit, so dass dies richtig sinn macht. Da wurde das ganze mittels
Monoflop gelöst.
> Der Flankendifferenzierer müsste etwa 100ns lange Pulse rausgeben, damit> es zum Display passt.
Das Problem ist, dass der RD Impuls gerade mal etwa 62ns lang ist.
Streng genommen bin ich momentan sogar außerhalb der Specs, denn das
Pollin Display verlangt mindestens 65ns high Zeit. Und das ist ein recht
modernes Display, ältere sind da noch langsamer. Bei dem Pollin Display
ist der maximale Takt mit etwa 6,5MHz spezifiziert. Da ein Zugriff auf
das SRAM 3 takt dauert, sind so theoretisch 5,33MHz möglich. Eine
Verdopplung ist daher nicht möglich, außer man baut Waitstates ein.
Wirklich viel ist also nicht zu gewinnen.
> Zwischen die I/O des SRAM und den Multiplexer> müsste wohl noch ein Latch, da ja das zweite Nibble erst ans Display> gelegt wird, wenn RD wieder High geht. Dann sind aber auch die I/Os auf> High-Impedance. Also einen Latch der die Daten bei einer steigenden> Flanke von RD latcht.
Jain. Ein Latch braucht man, aber aus einem anderen Grund: Momentan gebe
ich die Daten mit der steigenden Flanke von RD\ aus, und verletze damit
eigentlich auch die Hold Zeit des Displays.
Bei der fallenden Flanke von RD\ liegen die Daten noch nicht an, erst
nach einer gewissen Zeit. Man müsste also den ersten Impuls verzögern.
> Wie gesagt, man müsste dann mit einem ld-Befehl pro Byte statt einem pro> nibble auskommen und hätte fast die Hälfte der Prozessorlast gespart.> Dann sollten auch höhere Frameraten beim Video streamen möglich sein,> oder?
Es würde minimal etwas bringen, aber den Hardwareaufwand enorm erhöhen:
Man müsste die Daten bei der steigenden Flanke von RD\
zwischenspeichern, könnte die ersten Daten direkt mit übertragen. Dann
müsste man entweder mittels eines Zählers aus dem Prozessortakt oder
mittels Monoflops einen weiteren kompletten Takt (also >65ns high, >65ns
low, >65ns high und nochmal >65ns low erzeugen.
Wenn man die 16MHz Prozessortakt verwendet um die Takte zu erzeugen,
dann bräuchte man etwa 5 Takte für ein Byte (momentan sind es 6 +
0,75Takte).
Ich hatte mir diese Lösung anfangs auch überlegt, habe diese dann aber
verworfen, da die Lösung möglichst leicht nachzubauen sein sollte.
An der Software könnte man etwas auf kosten des Programmspeichers
optimieren:
Momentan gebe ich in einer Schleife 4 Takte aus, danach kommt der
Schleifenzähler + Rücksprung. Also für 12 Takte kommt ein Overhead von 3
Takten dazu. Diese Schleife könnte man entrollen, so dass der Overhead
weg fällt. Das würde etwa 15% mehr Geschwindigkeit bringen.
Ah, Dankeschön. Wie gesagt, ich wollte einfach nur wissen, obs möglich
wäre. Ich hätte aber doch einen größeren Nutzen erwartet. Aber so würde
es sich ja garnicht lohnen.
Die Schleife zu entrollen hatte ich auch schon überlegt. Habs aber
erstmal auf später verschoben.
Gruß, Sebastian
Im Anhang eine neue Version mit einer etwas auf Geschwindigkeit
optimierten Datenausgabe und einem optimierten UART (ein paar Details
beim X2 Mode korrigiert, etwas optimiert).
Bisherige Version bei 16MHz, 75Hz: 40% CPU Load.
Neue Version: 1/3, also 33,3% CPU Load
Dauer des Interrupts: 18,5µs
Die benötigte "Rechenleistung" liegt damit bei etwa 5,35MIPs.
Da der UART Hardware Puffer 2 Bytes umfasst, darf die Baudate damit bei
maximal etwa 850kBaud liegen. Der nächst niedrigere, mögliche Wert liegt
bei 666,6kBaud (16MHz/8/3). Das ist somit die maximale Baudrate bei
16MHz.
Die damit erreichbare Datenrate bei Graustufendaten sind etwas unter
200kPixel/s, bei SW sind es >400kPixel/s.
Wenn die Graustufen komplett deaktiviert werden, sind irgendwas
>500kPixel/s möglich. Das sind rund 7fps Vollbilder.
Eine weitere "Optimierung" wäre das Übertakten auf 18,432 oder 20MHz.
Die meisten mega8515 machen das mit. Damit liegt die Auslastung bei rund
27%. Und man trifft eventuell eine bestimmte Baudrate besser.
Hier mal noch ein paar Messungen:
Rot ist die Dauer des kompletten Interrupts, grün die XSCL Impulse zum
LCD.
Man sieht einen deutlichen Overhead der vor allem durch das Sichern der
Register im Interrupt und das berechnen der Adressen und Graustufen
drumherum entsteht.
Und die XSCL Impulse vergrößert.
Die Frequenz beträgt exakt 5,33MHz, und die high Zeit exakt 62ns, also
1/16MHz. Die Lowzeit beträgt 125ns, also 2x 1/16MHz, exakt wie erwartet.
Verstehe ich nicht ganz. Die Baudrate ist doch 57600 auf der Uart, oder?
Damit kann man aber nicht soviele Bilder pro Sekunde übertragen. Mein
Arm nach macht maximal 115kbaud mit.
Ist es ok, wenn ich vor jedem Byte an die Uart den Busy Pin auf Low
(=Busy) abfrage?
Graue Rechtecke sind bei mir übrigens immer noch nicht möglich. Sehr
seltsam, der Farbwerte wird ignoriert.
Christian
Christian J. schrieb:
> Verstehe ich nicht ganz. Die Baudrate ist doch 57600 auf der Uart, oder?> Damit kann man aber nicht soviele Bilder pro Sekunde übertragen. Mein> Arm nach macht maximal 115kbaud mit.
Die Werte waren bei 666,6kBaud, also dem maximalen was geht.
Durch das Busy werden die Daten aber auf bis zu 400kBit/s ausgebremst.
> Ist es ok, wenn ich vor jedem Byte an die Uart den Busy Pin auf Low> (=Busy) abfrage?
Ja. Theoretisch würde sogar jedes 64. Byte ausreichen, denn Busy/CTS
wird auf high gesetzt, sobald der Puffer zu 75% (=192 von 256 Bytes)
voll ist.
Hallo,
ich habe es endlich geschafft meine Platine ist funktionsfähig. Nur habe
ich jetzt ein Problem mit den Fusebit. Nachdem ich mit Ponyprog diese
auf "CKOPT, Boden und Bodlevel" ausgewählt habe kann ich den Prozessor
nicht mehr ansprechen. Welche Einstellungen sind richtig?
Viele Grüße
Gerhard
Hier noch das letze Bild der Messung:
Setup und Hold Zeiten.
rot ist der XSCL Impuls, grün eine Datenleitung die gerade den Pegel
wechselt.
Die Setupzeit dürfte irgendwo bei um die 55ns liegen, also gerade noch
innerhalb der Specs. Die Holdzeit liegt irgendwo bei um die 9ns. Laut
Datenblatt sollten es 40ns sein.
Da das LCD aber auch für 3,3V spezifiziert ist, kann man bei 5V diesen
Wert wohl großzügig unterschreiten.
@Gerhard
Schau mal in die pdf die bei der Software dabei ist. Da ist seit ein
paar Versionen ein Bild zu den Fusebits drin.
Benedikt, du bist einfach Spitze! Nicht nur das tolle Projekt, sondern
auch die Dokumentation dazu. Und jetzt die Updates sowieso. Einfach
klasse!
Sebastian
Hallo Bernhard,
zunächst einmal viele Dank für dein interessantes Projekt. Ich habe
bereits eine 640x480-Displaysteuerung von dir im Einsatz. Diese und auch
die aktuelle Variante funktionieren einwandfrei.
Da ich ein vertikal angeordnetes Display benötige habe ich deine
Software vom 10.05.2008 etwas bearbeitet (spätere Aktualisierungen sind
somit nicht berücksichtigt) und möchte diesen Programmcode hier zur
Verfügung stellen. Da ich C nicht mag ist die Version als avr-Studio
compatibles Assemblerprogramm angehängt, wobei nicht alle von C
produzierten Einzelheiten geändert sind.
Die Befehle sind etwas modifiziert, aber hoffentlich gut dokumentiert.
Die Übertragung von Bildern und benutzerdefinierten Zeichen erfordert
eine vertikale Bildabtastung. Ich werde mal mit dem vor kurzem hier
veröffentlichten Bild experimentieren. Bisher habe ich diesen Befehl nur
mit selbst hergestellten Bilddaten getestet.
Ich hoffe, dass ich keine Anpassungen übersehen habe.
Viel Spaß beim ausprobieren.
Horst-Dieter
Hallo,
die letzt gepostete Version läuft bei mir nur im Textmode, Grafik wird
verhackstückelt, die Koordinaten stimmen nicht, ein Rechteck um den
ganzen Bildschirm wird in der Mitte abgeschnitten, quasi nach links
verschoben. Busy geht auch nicht, 56700 sendet der Arm7 sauber raus, der
PC versteht es einwandfrei, trotzdem werden Zeichen verschluckt, fehlen
einfach. Busy rührt sich gar nicht.
Habe daher wieder auf vorherige Version umgesattelt.
Könnte mal jemand anders die letze Version ausprobieren und die
Ergebnisse von Christian J. bestätigen? Ansonsten schiebe ich die Schuld
mal auf den ARM bzw. die Baudrate von diesem, bei mir läuft die nämlich
wunderbar und die Baudrate sollte jetzt auch sehr gut passen. Zumindest
kann ich problemlos Bilder laden und Text anzeigen.
Also, am Arm liegt es sicher nicht, der tuts ja auch mit einem PC
zusammen. Habe testweise ein delay nach jedem Byte eingefügt, bis 100us.
Gleiches Resultat. Wie gesagt, Text einwandfrei, nur bei den beiden
Rechtecken um den Bildschirm hapert es, die sind einfach 50% nach links
verschoben aus dem Bild raus.
Schlimm ist es nicht, die eine Version läuft ja und reicht mir auch.
Durch die Kapselung der Basis-Funktionen in meinen eigenen Code lässt
sich de facto alles machen, was nur denkbar ist solange es keine
bewegten Grafiken werden sollen.
Liesse sich diese Platine für dieses Display umstricken:
Beitrag "Re: LCD Controller für 640x480 LCD mit mega8515"
Davon habe ich etliche hier. Wenn man das genauso komfortabel machen
kann (ohne S1D...) würde ich glatt noch Platinen machen.
Christian J. schrieb:
> Also, am Arm liegt es sicher nicht, der tuts ja auch mit einem PC> zusammen. Habe testweise ein delay nach jedem Byte eingefügt, bis 100us.> Gleiches Resultat. Wie gesagt, Text einwandfrei, nur bei den beiden> Rechtecken um den Bildschirm hapert es, die sind einfach 50% nach links> verschoben aus dem Bild raus.
Läuft die andere Version denn mit 57600 Baud? Ich dachte bisher
funktionieren nur 28800 Baud.
> Liesse sich diese Platine für dieses Display umstricken:>> Beitrag "Re: LCD Controller für 640x480 LCD mit mega8515"
Theoretisch ja:
Man benötigt einen zweiten SRAM. Zwischen beiden wird über die noch
freie Adressleitung umgeschaltet. Dann muss der Umschalter raus, so dass
man einen 8bit Bus hat.
Die andere läuft bis 38400 baud, darüber werden Zeichen verloren. Grafik
aber ok.
Da ich den Brenner nicht hier habe kann ich das leider nicht besser
testen.
Das klingt mir fast danach, als wenn irgendwie Busy bei dir nicht
funktionieren würde.
Busy funktioniert aber, habe ich extra probiert. Sende einfach mal >1000
lange (etwas schräge) Linien Befehle, oder auch Blöcke oder Kreise
direkt hintereinander und schau was passiert (natürlich inkl. des Busy
Checks).
Wenn Busy funktioniert, müsste der Busy Pin dann auf high gehen und
deinen ARM ausbremsen.
Wenn nicht, dann wird Müll auf dem Display ankommen.
So, ich bin jetzt endlich mal dazu gekommen auf die aktuelle Firmware
upzudaten.
Bei mir läuft sie einwandfrei. Text geht, Grafik geht. Alles bei
500kBaud und 4 Graustufen. Den Busy-Pin hab ich jetzt nicht angeschaut,
aber nehme mal an, dass der sich rühren sollte. Mein Sende-AVR fragt ihn
jedenfalls ab. Sende ein 160*200 Graustufenbild und 4 40*40-Rechtecke.
Das kommt alles wunderbar an.
Sebastian
Servus,
ich hab wollte mal fragen, ob hier Interesse an einer
8-Graustufen-Version besteht. Hab die Software etwas aufgebohrt, sodass
jetzt auch 3-bit Bilder angezeigt werden. Text- und Grafikfunktionen
sollten auch auf 8 Graustufen laufen, hab sie aber noch nicht gänzlich
getestet. Mir kam's mehr auf die Darstellung von Bildern an.
Wenn interesse besteht dokumentier ich mal meine erweiterungen und stell
sie hier rein.
Das Bild im Anhang ist von einem Normally Black display (das von
Pollin). Angesteuert mit 3 bit. Links werden nur 2 bit genutzt, rechts
3.
@Benedikt:
An deinem Graustufen-Mod (der gegens Flackern) versteh ich eine Sache
nicht ganz: Reicht es nicht, am Ende eines Bildes GrayCntMod um eins zu
erhöhen und wieder abzuspeicher? 240 ist ja durch 3 Teilbar, daher hat
GrayCntMod am Ende eines Bildes ja erstmal den gleichen Wert wie am
Anfang. Also um eins erhöhen, und das nächste Bild wird angezeigt. Man
würde sich dadurch halt 1 Byte und etwas Rechenzeit im Interrupt sparen.
Oder hab ich da was übersehen?
Gruß, Sebastian
Sebastian schrieb:
> An deinem Graustufen-Mod (der gegens Flackern) versteh ich eine Sache> nicht ganz: Reicht es nicht, am Ende eines Bildes GrayCntMod um eins zu> erhöhen und wieder abzuspeicher? 240 ist ja durch 3 Teilbar, daher hat> GrayCntMod am Ende eines Bildes ja erstmal den gleichen Wert wie am> Anfang. Also um eins erhöhen, und das nächste Bild wird angezeigt. Man> würde sich dadurch halt 1 Byte und etwas Rechenzeit im Interrupt sparen.> Oder hab ich da was übersehen?
Das ist genau der Trick an der Sache:
Ohne diese Modifikation läuft das ganze genau so.
Allerdings kann es dann sein, dass bei einer dunklen Graustufe die viele
Pixel beinhaltet, die gesamte Fläche z.B. nur jedes 3. Bild aufleuchtet,
die restlichen 2 Bilder aus ist.
Um das zu vermeiden, werden die eingeschalteten Pixel über die 3 Frames
verteilt indem zusätzlich GrayCntMod in jeder Zeile erhöht wird.
Am Ende des Bildes muss zusätzlich nochmal erhöht werden, damit sich in
jedem Bild der Wert ändert, also jede Zeile mal jeden Wert sieht.
PS: Schöne Erweiterung. Ich hätte nicht gedacht, dass 8 Graustufen so
gut aussehen.
Danke, bin auch total begeistert :-)
Geht aber nur mit dem normally Black so schön. Auf dem normally White
bringts zwar auch was, aber der Kontrast reicht für 8 Graustufen nicht
wirklich ganz aus.
Das wegen GrayCnMod hab ich wohl etwas ungünstig vormuliert: Ich würde
weiterhin GrayCntMod in jeder Zeile eins hochzählen. Am Ende des Bildes
dann aber nicht GrayCnt hochzähen und nach GrayCntMod kopieren, sondern
einfach GrayCntMod nochmal um eins erhöhen. Auf die Weise startet man
auch bei jedem Frame mit einem anderen Wert und wechselt trotzdem bei
jeder Zeilen durch.
Die Einsparungen sind minimal, ich weiß. Ich wunder mich nur halt, warum
du es nicht so gemacht hast.
Sebastian
Da die Bildgröße an sich einstellbar ist, funktioniert das nur bei
320x240 so gut. Um auch andere Displaygrößen zu unterstützen (z.B.
320x200 oder auch manche Displays die 241 Zeilen benötigen), habe ich
halt die eine Zusatzzeile mit eingebaut. Geschwindigkeitsmäßig ist der
Einfluss ja minimal.
PS: Wenn man die Bezeichnung des LCDs (LTBE9T372G1K) aufschlüsselt,
erhält man folgendes:
LT Bezeichnung
B CCFL Backlight
T Transparent
G Normally Black
1K Hoher Kontrast, Version 1
Dieser vergleichsweise hohen Kontrast, den sieht man auch deutlich.
Ok, die Software allgemein zu halten ist ein guter Grund. Wobei man das
aber auch über den Präprozessor erledigen könnte. So in der Art halt:
#define YSIZE 240
#if(lines%3==0)
GrayCntMod++;
#endif
Dann würde man sich immernoch ein Byte, und eine Hand voll Takte sparen.
Aber das ist nun wirklich erbsenzählerei. Mit 4 Graustufen reicht die
Rechenleistung ja sowieso. Nur bei 8 ist man halt um jeden Takt froh.
Andererseits läuft mein AVR jetzt eh auf 20Mhz, da gehts auch wieder
recht flott. Das ganze übrigens mit dem 80ns SRAM vom Reichelt.
Natürlich weit jenseits der Specs, aber es solange es läuft...
Hab mal noch nen Bild vom Normally White mit 8 Graustufen angehängt. Da
sieht man schön, dass der Kontrast einfach nicht reicht.
Sebastian
Mit welchem Verfahren rechnest du den die Graustufen um? 4 Grauwerte
gibt bei mir eigentlich schon ein schickes Bild, 8 Grauwerte sind
natürlich echt Luxus!
Ich hoffe ja das ich irgenwann mal mein 640x480 Display ans laufen
kriege, aber irgenwie kommt immer was dazwischen :)
Besonders das Layouten des SRAMs ist immer ne schreckliche Sache :)
Hmmm, SRAM routet sich doch normalerweise recht einfach. Du kannst ja
Adress- und Datenleitungen beliebig verdrehen. Ok, hier gehts nicht ganz
beliebig wegen dem Display, aber prinzipiell kann man da schon den
Schaltplan etwas anpassen.
Die Bilder erzeuge ich mit "Grafik Converter". Ist ein kleines
Javaprogramm hier aus dem Forum, das dir aus farbigen Bildern welche in
Grau erzeugt. Kannst dann auswählen, ob sie als Bild, oder als
include-datei für C oder ASM gespeichert werden sollen.
Das Bild was ich oben gepostet habe wurde mit Floyd-Steinberg
umgerechnet. Mit einfachen Schwellenwerten bilden sich bei Farbverläufen
immer so doofe Bögen zwischen zwei Grauwerten.
Sebastian
Ja das stimmt wohl hab nur leider 32K Cache SRAMs und daher brauch ich
min 3 Stück für 640x480... bin schon fast soweit die einfach
übereinander zu stapeln ^^
Das Programm ist übrigens von mir, ggf erreichst du ein besseres
Ergebnis wenn du die Farbraumangleichung deaktivierst und die Graustufen
etwas justierst.
ich wollte nur wissen was ich bei der Ausgabe Optionen einstellen
muss,bei Farbtabelle habe ich 2Farben eingestellt,
vielleicht könnte mir da nochmal jemand helfen
kay
3*32KByte für 640*480? Das stimmt aber nur für Graustufen. Und da wär
ich mir nicht sicher, ob das noch vernünftig aus nem AVR zu holen ist.
Lass mich aber auch gerne vom gegenteil überzeugen.
Wieso nicht stapeln? Wenn's etwas professioneller aussehen soll kannst
du ja jeden Ram auf ein kleines Stückchen Platine löten und die Platinen
übereinander anordnen. Lässt sich dann auch schön einfach
durchverbinden. Bin mir bloß nicht sicher, ob die Signalqualität davon
so begeistert ist ;-)
An sonsten würde ich halt durch die Pins durchrouten. Bei drei
hintereinander sollte man sogar auf nem einlagigen Board noch an die
CS-leitungen rankommen.
Was macht eigentlich die Farbraumangleichung? Ist das nur, damit ich die
Farbtabelle besser auf das jeweilige Bild einstellen kann? Mein Display
hat am Ende ja eh nur Graustufen...
@kay
So schwer ist's eigentlich nicht mit den Bildern. Du machst erst alle
Einstellungen (Größe, Farbtabelle, Zoom,...). Dann suchst du dir aus obs
Floyd-Steinberg oder Schwellenwert Verfahren werden soll.
Dann speichern: Die Einstellungen da sollten für Benedikts
Displaycontroller schon passen. Also Horizontal, MSB First und
Bytegrenzen bewahren. Dann noch auswählen, ob du es als Bild, header für
.asm oder für .c haben willst. Bild (also .bmp,...) macht hier aber
eigentlich keinen sinn, also .asm oder .c
Dem Controller sendest du dann der Reihe nach:
-15 (Startwert)
-0xAA (Kontrollbyte)
-X (Startposition X, für den ersten Versuch am besten 0)
-Y (Startposition Y, auch am besten 0)
-xs (breite des Bildes in Byte. xs=1 heißt 8 Pixel, bei 40Pixel wäre
xs 5)
-ys (Höhe in Pixeln)
-1 (Modus, bei 1 bit ist das "eins")
- und jetzt die Daten.
Viel Erfolg
Sebastian
Sebastian schrieb:
> 3*32KByte für 640*480? Das stimmt aber nur für Graustufen. Und da wär> ich mir nicht sicher, ob das noch vernünftig aus nem AVR zu holen ist.> Lass mich aber auch gerne vom gegenteil überzeugen.
Müsste man halt irgendwie in Bänke unterteilen. 640x480 benötigen 38400
Byte. Das ist ein dummer Wert, man müsste vermutlich irgendwo mitten in
einem Bild umschalten.
Benedikt K. schrieb:
> Sebastian schrieb:>> 3*32KByte für 640*480? Das stimmt aber nur für Graustufen. Und da wär>> ich mir nicht sicher, ob das noch vernünftig aus nem AVR zu holen ist.>> Lass mich aber auch gerne vom gegenteil überzeugen.>> Müsste man halt irgendwie in Bänke unterteilen. 640x480 benötigen 38400> Byte. Das ist ein dummer Wert, man müsste vermutlich irgendwo mitten in> einem Bild umschalten.
Naja ich dachte halt dies wäre der "Nachfolger" der 640x480er Schaltung
oder funktioniert das nur fpr 320x...?
Ich würde dann einfach 4x32k stapeln damit man kein "Loch" im
Addressraum hat.
Geht anstelle des HC753 eigentlich auch ein HCT373? Scheinen mir beides
nicht invertierende "transparente" Latches zu sein.
>Was macht eigentlich die Farbraumangleichung? Ist das nur, damit ich die>Farbtabelle besser auf das jeweilige Bild einstellen kann? Mein Display>hat am Ende ja eh nur Graustufen...
Ist vieleicht ein etwas blöder Begriff was besseres viel mir aber nicht
ein. Die Farbraumangleichung ist nur für Grauwertbilder sinnvoll und
bewirkt eigentlich nur das der volle Wertebereich genuzt wird.
Es wird einmal der Minimale Grauwert und einmal der Maximale Grauwert
bestimmt, und dann alle Werte dementsprechen skaliert das sie im Bereich
0...255 liegen.
Läubi .. schrieb:
> Naja ich dachte halt dies wäre der "Nachfolger" der 640x480er Schaltung> oder funktioniert das nur fpr 320x...?
Mit 640x480 funktioniert das auch, das Problem ist halt eben nur der
ungünstige Speicherverbrauch.
Bei der 320x240 Version ist der Speicher streng genommen als
256x256x4bit organisiert (da der Speicher aber 8bit breit ist, sind
gerade und ungerade Adressen identisch).
Das LCD benötigt 80x4bit x 240. Reserviert sind 128x4bit x 240 für ein
Bild, das gleich nochmal für das andere Teilbild der Graustufe. Ich
denke mal Sebastian hat einfach noch einen weiteren Speicher hinzugefügt
und so 2 weitere Teilbilder eingebaut. War bestimmt einiges an Arbeit,
vor allem das umrechnen 2 bzw. 3bpp -> 2/4 Teilbilder.
> Ich würde dann einfach 4x32k stapeln damit man kein "Loch" im> Addressraum hat.
Oder gleich einen 128kx8 SRAM verwenden.
> Geht anstelle des HC753 eigentlich auch ein HCT373? Scheinen mir beides> nicht invertierende "transparente" Latches zu sein.
Ja, sollte egal sein, bei 0V/5V Pegeln sind beide geeignet.
Ich hab halt ne altes Lapto SW Display was ich da gerne dranhängen würde
hatte erst die "alte" 640x480 Version geplant aber Graustufen sind ja
auch nicht schlecht daher wollt ich jetzt die "Modernere" Variante
wählen.
Bei dem Display wir allerdings 8 bit auf einmal übertragen von daher
wollte ich die "alte" Schaltung mit der "neue" Software aufbauen oder
gibt es da Inkompatibilitäten?
>Oder gleich einen 128kx8 SRAM verwenden
ja okay... aber die Rams hab ich jezt hier und schnelle SRAMs kriegt man
ja auch nicht an jeder Straßenecke...
Läubi .. schrieb:
> Bei dem Display wir allerdings 8 bit auf einmal übertragen von daher> wollte ich die "alte" Schaltung mit der "neue" Software aufbauen oder> gibt es da Inkompatibilitäten?
Die SRAM Adressieren ist etwas anders. Bei der neuen habe ich den oben
beschriebenen, etwas unkonventionellen Ansatz verwendet, A0 vom mega8515
frei zu lassen. Es kann sein, dass ich auch ein paar Pins gedreht habe.
Ansonsten sollte das ganze nahezu gleich sein.
Du kannst das SRAM (also 2x 32kB) so verdrahten wie bei der 640x480
Version, und für die neue Software A0 vom mega8515 trennen und auf Masse
legen.
Aber brauche ich nicht (640*480*2)/8 = 76800 bytes?
Das wären dann ja mind 3x32kb nötig.
Und verliert man nicht die Hälfte an Speicherplatz nochmal dadurch das
A0 fest auf Masse liegt? Das verwirrt mich gerade etwas ;)
Läubi .. schrieb:
> Und verliert man nicht die Hälfte an Speicherplatz nochmal dadurch das> A0 fest auf Masse liegt? Das verwirrt mich gerade etwas ;)
Ach ich seh gerade das du das manuell ansteuerst!
Die erste Frage bleibt aber ;)
Läubi .. schrieb:
> Aber brauche ich nicht (640*480*2)/8 = 76800 bytes?
Für Graustufen, ja. Aber ob es die Version jemals geben wird, bezweifle
ich noch.
> Und verliert man nicht die Hälfte an Speicherplatz nochmal dadurch das> A0 fest auf Masse liegt? Das verwirrt mich gerade etwas ;)
Ja, aber das ist für die neue 320x240 Version notwendig, die mit 32kByte
Speicher auskommt. Diese habe ich bewusst auf möglichst wenige Bauteile
optimiert, damit man die leicht nachbauen kann.
Benedikt K. schrieb:
> Läubi .. schrieb:>> Aber brauche ich nicht (640*480*2)/8 = 76800 bytes?>> Für Graustufen, ja. Aber ob es die Version jemals geben wird, bezweifle> ich noch.
Mist ich dachte die gäbe es schon g
Wodran scheitert es denn?
Ich werd erstmal die 32kb Version aufbauen (Allerdings ohne die Sache
zur Erzeugung des Frame Signales) dann sollte ja erstmal nix kaputtgehen
und im zweifel hab ich halt nur SW :)
>Ich denke mal Sebastian hat einfach noch einen weiteren Speicher>hinzugefügt und so 2 weitere Teilbilder eingebaut. War bestimmt einiges an>Arbeit, vor allem das umrechnen 2 bzw. 3bpp -> 2/4 Teilbilder.
Nein, das ist ja grade das schöne. In den 32k-RAM passen ja 3 Teilbilder
(hast du ja mit einführen der Virtuellen Bildgröße bewiesen). Bei mir
liegen die 3 Teilbilder einfach nebeneinader im Ram, so wie bei dir
schon die 2 bei 2bpp. Fenster verschieben geht dann natürlich nicht
mehr, bringt aber (meiner Meinung nach) eh nur dann wirklich was, wenn
man mindestens 2 Vollbilder im Speicher hat. Sobald man also Graustufen
will, ist's eh egal. Aber die Hardware ist föllig unberührt. Quarz hab
ich auf 20MHz getauscht, läuft aber auch mit 16 noch.
Ich häng das ganze jetzt doch mal an. Bringt ja nichts nur drüber zu
reden...
Sebastian
So jetzt also:
8 Graustufen, hier im Anhang!
Die Hex im Anhang ist für 16MHz und 500000 Baud-Rate und natürlich 8
Graustufen kompiliert.
Was ist neu:
#define GRAY8 aktiviert den 3-bit Modus, aber nur wenn GRAYSCALE auch
aktiv ist.
Eine 3-bit-Grafik wird erstmal genauso gesendet, wie die anderen auch.
X und xs wird 8-Pixel-weise angegeben (also z.B. xs=5 bei 40 Pixel
Bildbreite).
Y und Ys wird in Zeilen angegeben
Modus ist 2 für 3bpp
Die Daten muss MSB-First sein und ein kontinuierlicher Bitstream, also
nicht Byte-aligned. Hab das so gewählt, um die zu übertragenden Daten
klein zu halten. Bei Byte-aligned hätte man 2bit pro Byte umsonst
gesendet.
1- und 2bit Grafiken werden gesendet wie bisher. Zur Farbraumerweiterung
wird einfach das letzte Bit kopiert:
0->000 1->111
00->000 01->011 10->100 11->111
So krigt man immernoch schönes Schwarz und Weiß hin. Würde man das LSB
einfach Null setzen wäre das ja nicht mehr gegeben.
Die Grafik und Textfunktionen sollten alle laufen wie Gewohnt. Für die
Farben (auch Text- und Hintergrundfarbe) sind jetzt aber die obersten
DREI bit relevant, sodass man auch hier 8 Graustufen nutzen kann.
Die Befehle für den virtuellen Bildbereich und das setzen des
Textanfangs werden ignoriert. Da man das Bild nur um ein paar Pixel
verschieben könnte hab ich das für 8 Graustufen deaktiviert. Vielleicht
mach ich irgendwann mal ne Bankumschaltung draus, dann bräuchte man aber
einen größeren RAM.
Performance hab ich bisher noch nicht gemessen, aber es liegt absolut im
Bereich des Zumutbaren. Für ein Vollbild 3-bit Grafik grob geschätzt
eine Sekunde.
Gruß, Sebastian
Sorry für tripple-post. Wollte die Software extra haben und hab jetzt
erst bemerkt, dass ich weiter oben Mist geschrieben hab.
@kay:
Modus muss für Schwarz-Weiß auf 0 gestellt werden. 1 wären 4Graustufen.
Sebastian
@ Sebastian
Ich habe mir die Software gerade angesehen und muss sagen: Respekt! Ich
hätte es nicht besser gekonnt.
Hast du was dagegen wenn ich deine Erweiterung übernehme und diese
Software als aktuellen Stand übernehme, darin also spätere Erweiterungen
einbaue? Dann würde ich das ganze auch mal testen und die neuen
Funktionen der Beschreibung hinzufügen.
Vielen vielen Dank. So ein Lob von dir zu hören ist schon was
besonderes!
Zumal das das erste LCD ist, das ich je zum ansteuern in der Hand hatte!
Nichtmal irgendein HD... kompatibles :-)
Würde mich sogar freuen, wenn du das übernimmst. Allein schon, weil ich
dann auch weiterhin von änderungen profitieren kann, die du einfügst,
ohne jedes mal wieder rumbasteln zu müssen.
Gruß, Sebastian
So jezt nochmal das ich alles richtig habe weil es ja 2
Schaltplanversionen gibt...
AVR --> Display
13 --> XCLK = CP2
14 --> FLM = S
15 --> LP = CP1
31 --> OnOff = DISP (Optopkopler kann wegfallen)
Zur Negativen Spannungserzeugung:
29 --> PWM Ausgang
Muß es ein BC327 sein? Ich hätte nen BC557 oder BSS84P hier.
In welchem Bereich kann die Spule liegen? Ich hätte hier 330µH einmal
las L-PIS2408 und einmal SMCC (die Widerstandsvariante) und einmal ne
MISC 100µH
Diode würde ich ne 1N914 nutzen.
Ich habe mal alle Funktionen der 8 Graustufenversion von Sebastian
geprüft: Laufen wunderbar.
Das einzige was mich stört ist die hohe Framerate die notwendig ist, um
das ganze flimmerfrei anzuzeigen. Daher habe ich die Option GRAYMOD
erweitert. Mit dem Wert dahinter kann man nun die Graustufenerzeugung
etwas beeinflussen. Somit erreicht man bereits bei 100Hz recht gute
Ergebnisse.
Da das ganze auch stark vom verwendeten LCD abhängt, kann man mit diesem
Wert und der Framerate etwas spielen, bis das Ergebnis zufriedenstellend
ist.
Eine weitere Neuerung ist nun, dass das LCD Zeilentiming nun
hardwaremäßig erzeugt werden kann:
Durch den UART Interrupt wird der LCD Timer Interrupt ab und zu für eine
kurze Zeit ausgebremst. Dadurch sind manche Zeilen länger, andere kürzer
an. Das sieht man dann als Streifen im Bild. Mit steigender Framerate
wird der relative Einfluss zunehmend größer. Nun wird der Latchpuls per
Timer erzeugt und wird nun nicht mehr durch andere Interrupts
beeinflusst. Da der Timer aber schon von der PWM belegt war, musste
dieser etwas angepasst werden. Die PWM Frequenz ist nun gleich der
Zeilenfrequenz des LCDs.
Läubi .. schrieb:
> So jezt nochmal das ich alles richtig habe weil es ja 2> Schaltplanversionen gibt...
Welche Schaltung meinst du jetzt? Die neue 320x240 Version oder die alte
640x480? Ich habe bei der neuen 320x240 Version bewusst den ganzen
Ballast der alten Schaltung weg geworfen und alles neu entworfen, daher
sind beide nicht 100%ig kompatibel.
> Muß es ein BC327 sein? Ich hätte nen BC557 oder BSS84P hier.
Ich sag mal ja. Es kann mit einem BC557 funktionieren, aber der dürfte
am Rande der Specs betrieben werden. Der BSS84 ist viel zu hochohmig.
> In welchem Bereich kann die Spule liegen? Ich hätte hier 330µH einmal> las L-PIS2408 und einmal SMCC (die Widerstandsvariante) und einmal ne> MISC 100µH
Sollten eigentliche alle gehen (eventuell bis auf die MISC). Ich
verwende meist die in Widerstandsbauform. Der Widerstand der Spule
sollte etwa 5-10 Ohm allerdings nicht überschreiten.
> Diode würde ich ne 1N914 nutzen.
Da dies ein Vergleichstyp der 1N4148 ist, ist die ok.
Benedikt K. schrieb:
> Welche Schaltung meinst du jetzt? Die neue 320x240 Version oder die alte> 640x480? Ich habe bei der neuen 320x240 Version bewusst den ganzen> Ballast der alten Schaltung weg geworfen und alles neu entworfen, daher> sind beide nicht 100%ig kompatibel.
Ich bau jezt einfach mal die neue 320x240 Version auf. Allerdings ohne
die 4bit Unterteilung.
> Ich sag mal ja. Es kann mit einem BC557 funktionieren, aber der dürfte> am Rande der Specs betrieben werden. Der BSS84 ist viel zu hochohmig.
Okay dann muß ich mal sehen wo ich einen herbekomme.
> Sollten eigentliche alle gehen (eventuell bis auf die MISC). Ich> verwende meist die in Widerstandsbauform. Der Widerstand der Spule> sollte etwa 5-10 Ohm allerdings nicht überschreiten.
Kann ich das einfach mit dem MM messen oder bezieht sich der Wert auf
eine bestimmte Freuenz?
Zu deiner neuen "Demo": Sieht SUPER aus! Wenn ich doch nur schon
soweit wäre :D
Läubi .. schrieb:
>> Benedikt K. schrieb:>> Sollten eigentliche alle gehen (eventuell bis auf die MISC). Ich>> verwende meist die in Widerstandsbauform. Der Widerstand der Spule>> sollte etwa 5-10 Ohm allerdings nicht überschreiten.>Kann ich das einfach mit dem MM messen oder bezieht sich der Wert auf>eine bestimmte Freuenz?
Einfach messen. Da der Spitzenstrom irgendwo im Bereich von >100mA
liegt, sollten sich die Verluste im Drahtwiderstand in Grenzen halten:
Bei 100mA und 10 Ohm gehen 1V verloren. Das sind bei 5V Betriebsspannung
schon 20%. Es funktioniert zwar vermutlich auch, nur ist der
Wirkungsgrad schnell bei <50%. Daher auch der externe PNP Transistor:
Der interne NPN Darlington funktioniert auch (mehr oder weniger), da an
diesem aber >1V verloren gehen, reduziert sich der Wirkungsgrad noch
weiter.
Wäre es den vom Vorteil den MC34063 mit einer Höheren Spannung zu
betreiben? Für den Inverter fürs CCFL brauch ich eh 12V.
Ist den meine Verbindung uC--> LCD ansonsten korrekt?
Ja, 12V würden Vorteile bringen, aber auch Gefahren:
Der MC34063 kann maximal 40V. Bei 12V und -20V sind das bereits 32V.
Sehr viel höher darf man da also nicht gehen, etwa 16V würde ich als
Maximum der Eingangsspannung betrachten.
Die Verdrahtung sollte so passen. Der Schaltplan in der PDF in dem Paket
sollte passen.
hallo,
ich würde das gerne mal in den 8Graustufen probieren,
nun hab ich noch ein paar Fragen
ich hab ein bild 96x62Pixel
1.was muss ich den bei dem oben genanten Programm von Läubi bei der
Farbtabelle einstellen ich hab 2Farben
und beim abspeichern hab ich 16Bytes eingestellt
2.15,0xAA,0,0,12,62,2 =744byte an bilddaten,
aber die abgespeicherte datei hat aber knapp 5KB an daten?
vielleicht könnte mir nochmal kurz jemand helfen,
speziell bei der 3bpp,muss ich 96:8 oder 96:24 rechnen
mfg
kay
DIe Daten in der asm Datei liegen im ASCII / AVRStudio format vor, also
keine Banege, du must wenn ich das richtig verstanden habe einfach nur
die Daten aus diesem Feld senden. (Du kannst die Datei einfach mit
notepad öffnen dann siehst du die entsprechenden Hexzahlen)
Versuchst du das ganze vom PC aus oder von nem uC?
hallo,
ich wollte die asm datei von einem atmega128 übertragen,
ich weis jetzt aber nicht ob ich den befehl 15 so richtig gerechnet
habe,weil bei 1bpp muss ich ja 96:8=12 in X und 62 in Y
das macht 12x62=744 Byte an bilddaten aber,
wie ist das jetzt in der 3bpp variante??
kay
Es ist Befehl 16. Ansonsten passt deine Rechnung: Da 8Pixel gezählt
werden, musst du 12x62 als Bildgröße senden. Da 8 Pixel 3 Bytes
entsprechen, musst du 3x12 x 62 Bytes senden.
Du solltest mal nochmal deine Einstellungen beim Grafik Converter
überprüfen, das passt glaub ich noch nicht ganz:
Das schwarz-weiß-bild im Anhabng wurde mit sicherheit über die "NULL
Transformation" oder über "Graustufen Verfahren" erzeugt. Genau die
beiden wandeln aber nur nach grau, ohne den Farbraum zu begrenzen.
Die ASM-Datei müsste auch größer sein. Du hast ja auch geschreiben, dass
die Farbtabelle nur 2 Einträge hat. Danach schaut auch die .asm aus.
Ich hab mal zwei Screenshots gemacht. Wenn du die Einstellungen machst
wie dort, sollte es auf jeden Fall funktionieren:
Die Farbtabelle muss 8 Farben enthalten, die Größe die angegeben wird
musst du entsprechend dem Display senden und zum convertieren musst du
entweder Floyd-Steinberg oder Schwellenwert-Verfahren auswählen.
Beim Speichern ist Horizontal und MSB-First wichtig und dass der Hacken
bei "Bytegrenzen Bewahren" wegkommt.
Hoffe das hilft
Sebastian
hallo Sebastian,
habe es mal so gemacht wie du es empholen hast,so mein Beispielbild
ist 74x50Pixel,
so wenn ich jetzt rechne 74x50=3700Byte
aber die tatzächliche Bilddaten grösse ist 1388Byte,
wie muss ich den das nun mit dem befehl 16 das übertragen,
16,0,0,?,50,2
muss ich 74:8=9.25*50=462,5 ,x zählt ja nur in 8Pixel,
oder irre ich mich da.
vielleicht könnte mir da nochmal jemand weiterhelfen.
mfg kay
Kay schrieb:
> habe es mal so gemacht wie du es empholen hast,so mein Beispielbild> ist 74x50Pixel,> so wenn ich jetzt rechne 74x50=3700Byte> aber die tatzächliche Bilddaten grösse ist 1388Byte,> wie muss ich den das nun mit dem befehl 16 das übertragen,> 16,0,0,?,50,2
Wie weiter oben schon geschrieben: Es werden 8 Pixel Schritte gezählt:
74/8=9,25 -> geht nicht.
Du musst also entweder 72 oder 80 Pixel senden.
Das wäre dann ein Wert von 9 oder 10.
Da pro Wert 3 Bytes gesendet werden müssen, macht das 3 x 9 x 50 bzw.
3 x 10 x 50. Insgesamt wären das 1200 oder 1500 Bytes.
In deiner Beschreibung steht drinn das der MUX auch gleichzeitig als
Buffer dient. Da ich den ja jezt weggelassen habe brauch ich dann auch
einen Buffer (z.B. HC244).
Wenn das Kabel zum LCD nicht allzu lange ist, dann sollte es keine
Probleme geben. Ein zusätzlicher Puffer ist nie verkehrt, denn er
entkoppelt die Ausgangsleitungen von dem Adress/Datenbus, aber es
funktioniert normalerweise auch ohne diesen Puffer.
Ein kritisches Timing ist das Adresslatch, das wie man im Anhang sieht
in der Praxis sehr viel unkritischer ist als im Datenblatt (grün: ALE,
rot: ADx Signal). Die fallende Flanke von ALE ist interessant, und rum
um diese sind die Daten für >+/-20ns stabil (das Datenblatt garantiert
z.B. nur 5ns Hold Time). Also mehr als ausreichend, selbst bei einer
zusätzlichen Belastung.
Das Timing vom LCD ist da meist sogar noch etwas kritischer, aber auch
hier ist das Timing in der Praxis sehr viel unkritischer als im
Datenblatt:
Beitrag "Re: Grafikfähiger LCD Controller für 320x240 LCD mit 4 Graustufen"
Benedikt, du schreibst doch immer, dass du auf deinen Bildschirmen Filme
vom PC aus anschaust. Was ist das denn für ein Programm, das du da immer
nimmst?
Sebastian
hallo,
so habe es eben mal versucht ein bild zu laden,aber es hat nicht
funktioniert schade es wird nur müll angezeigt,
abgespeichert habe ich es als asm-datei und 16Bytes pro zeile.
hier ist meine routine zum senden:
;320X240Pixel
:320:8=40
locateGrafik320x240picture 0xAA,0,0,40,240,2
ldi ZL, low(2*bild_1)
ldi ZH, high(2*bild_1)
ldi WH, 240
YsLoop:;
ldi XL, 40
XsLoop:
lpm WL, Z+;;
call USART_TX0 ;Zeichen senden
dec XL
brne XsLoop
dec WH
brne YsLoop
vielleicht könnte mir jemand weiterhelfen was ich da falsch mache
die bolddaten habe ich im anhang
mfg
kay
Lass mich raten: Das Display zeigt unter anderem Jede Menge Buchstaben
an, aber nichts was irgendwie nach einem Bild ausschaut?
Du musst die Befehle (also 0xAA,0,0,40,240,2) schon auch zum Display
schicken, damit dieses auch weiß, dass jetzt ein Bild kommt.
Ansonsten passen jetzt eigentlich alle werte. Wenn du das richtig
sendest und dein Bild richtig umgewandelt ist müsstest du was sehen.
Wenns dann immernoch nicht geht meld dich mal nochmal. Dann such ich mal
meinen LKW mit Startwerten raus. Damit MUSS es dann gehn.
Sebastian
hallo Sebastian ,
das ist ein Macro,hatte ich vergessen zuerwähnen
locateGrafik320x240picture 0xAA,0,0,40,240,2
.macro locateGrafik320x240picture
push wl ;Register sichern
LDI WL,16
call USART_TX0
LDI WL,@0
call USART_TX0 ;an LCD
LDI WL,@1
call USART_TX0 ;an LCD
LDI WL,@2
call USART_TX0 ;an LCD
LDI WL,@3
call USART_TX0 ;an LCD
LDI WL,@4
call USART_TX0 ;an LCD
LDI WL,@5
call USART_TX0 ;an LCD als Befehl ausgeben
pop wl ;Register wiederherstellen
.endmacro
das bild ist 320x240
320x240=76800byte
320:8=40
3x40x240=28800byte an bilddaten
da benedikt sagt Da pro Wert 3 Bytes gesendet werden müssen,denke ich
mal ich hab da irgendwo einen fehler in meinen aufruf,ich weiss nich wie
ich 3x40 in meinen aufruf schreiben soll, da denke ich liegt der fehler.
;320X240Pixel
:320:8=40
locateGrafik320x240picture 0xAA,0,0,40,240,2
ldi ZL, low(2*bild_1)
ldi ZH, high(2*bild_1)
ldi WH, 240
YsLoop:;
ldi XL, 40
XsLoop:
lpm WL, Z+;;
call USART_TX0 ;Zeichen senden
dec XL
brne XsLoop
dec WH
brne YsLoop
mfg
kay
das bild ausgeben aber am display wirds nur zu 1/4 mit wirren pixel
gefüllt.
die anderen funktionen laufen prima.
Sebastian schrieb:
> Benedikt, du schreibst doch immer, dass du auf deinen Bildschirmen Filme> vom PC aus anschaust. Was ist das denn für ein Programm, das du da immer> nimmst?
Irgendwo habe ich mal den Sourcecode von einem AVI Player aus dem Netz
gezogen. Der liefert die einzelnen Frames als Bilder. Die schicke ich
dann weiter ans Display, nachdem ich diese passend zurechtschneide und
in das passende Format bringe.
Kay schrieb:
> da benedikt sagt Da pro Wert 3 Bytes gesendet werden müssen,denke ich> mal ich hab da irgendwo einen fehler in meinen aufruf,ich weiss nich wie> ich 3x40 in meinen aufruf schreiben soll, da denke ich liegt der fehler.>> ;320X240Pixel> :320:8=40> locateGrafik320x240picture 0xAA,0,0,40,240,2
Das sieht eigentlich alles richtig aus.
> ldi WH, 240> YsLoop:;> ldi XL, 40> XsLoop:
Pro x Wert musst du 3 Bytes senden, dass wären dann 3*40 und nicht nur
40 Bytes pro Zeile.
Hallo Benedikt
irgendwie hab ich ein Bedienfehler
Rechteckübergabe
29;5;0;5;250;0;30;255;0
wenn ich die 250 durch 315 (Rechteck bis fast rechts) ist das Rechteck
weg.
Linie
18;0;0;230;255;0;230;255
die Linie soll unten horizontal durchgehen
wenn ich die mittlere 255 vergrössere, kommen schräge Linien raus.
Warum hat x eigentlich low und high
Wigbert
Hi,
noch mal zur Bildübertragung:
Ich will ein Bild 1Bpp 64x64 Pixel übertragen
bei Pixel x = 80 ; y = 80 aufs Display.
Ich übertrage dann : 16 0xAA 10 80 8 64 0 und dann die Daten....
stimmt das soweit?
Ich hab hier convert.exe und LCD.Assistent.exe. Oder was kann ich
nehmen?
Wie war das mit den 3 Byte ?
Vielleicht könnte jemand mal die Datei einsehen.
Anbei Testbild + Datei h
Dank Euch mal schon
Wigbert
Wigbert Picht-dl1atw schrieb:
> Ich übertrage dann : 16 0xAA 10 80 8 64 0 und dann die Daten....
Nicht ganz: Erst kommt die X/Y Position, dann die Größe:
16 0xAA 8 64 10 80 0
Das Bild in der .h sieht komisch aus: 455Bytes für 16384 Pixel passt
nicht ganz zu dem 80x80 Bild.
schon der erste Konflikt
mal anders fragen...
Befehl:
16 0AA X Y XS YS Modus Daten...
16 ; 0AA; OK
Displaypixel 80 -> 80 :8 = 10 -> X = 10 ?
Displaypixel 80 -> 80 -> Y = 80 ?
Das Bild wird in 64 x 64 Pixel gesendet (rechts abschneiden)
das wären doch 64 : 8 = 8 x 3 = 24 Byte x 64 = 1536 Byte Testbild.
bis hier richtig gerechnet ?
Wigbert
Äh Mist, deine Zeile oben war richtig. Ich hatte nur das x=80, y=80
gelesen, ich bin heute nicht ganz ausgeschlafen...
Du überträgst die Daten im 1bit Modus, ein Bild ist also 64/8*64=512Byte
groß. Dein angehängtes Bild ist aber 128 Pixel breit. Beschneide das
mal, bevor du das durch die Software schickst.
Es sind zumindest 512 Bytes, könnte also passen. Die Daten musst du
einfach nach dem Befehl senden, einfach alle Bytes so wie sie in der
Tabelle stehen hinereinander, nicht 3x.
falls jemand Lust auf Bascom hat,
der Codeauszug
Sub Bild
Local Count As Word
Local B As Byte
Printbin 16 ; 170 ; 29 ; 70 ; 8 ; 64 ; 0 ' Bildplatz
If Wahl = 0 Then Restore Hase :
'if Wahl = 1 then Restore Testbild:
For Count = 1 To 512 ' Byte müssen stimmen
Read B
Printbin B
Next Count
End Sub
Hase: 'von oben
Data ......
Wigbert
Würde mich auch interressieren ob das hier noch aktuel ist?
wie sieht es mit der 8 graustufen version aus?gibts da ne ZIB mit
Beispielen???
würde mich auch freuen wenn es noch eine platine geben würde
lg
chrissi
Hallo Benedikt,
Wie schon oft bemerkt, tolles Projekt und vielen Dank auch fuer die
Betreuung der Seite.
Meine Frage, bringt ein Mega162 Vorteile? - mehr s-ram, neuerer Chip,
Architektur?
die Displayansteuerung ist ja wirklich ein Spezialgebiet. Mit avrs und
Elektronik kenne ich mich ja etwas aus,
doch programmiere ich fast nur in gcc- c, und habe mich bisher nicht so
sehr fuer die Speicherverwaltung
interessiert.
Was muesste man aendern, wo konkret Adressen umschreiben, - bringt das
was?
vielen Dank philipp
Wirklich viel bringt der Controller nicht, nur mehr Flash (z.B. für
zusätzliche Schriftarten) und mehr SRAM (für einen größeren UART
Empfangspuffer).
Geändert werden muss dazu nur die Zeile #define DDRAM 1024.
Diese muss auf den Ende des internen und Beginn des externen RAMs also
auf 0x500 = 1280 gesetzt werden.
Danke Benedikt für Deine schnelle und kompetente Antwort.
So ungefähr, hatte ich gehofft, konnte auch nur die #define... finden,
und mit den Wert hast Du mir auch geholfen.
War mir aber unsicher, ob sich in dem asm Code noch Adressen ergeben.
Da ich das Teil einlöten wollte, wäre es etwas nervig, es dann tauschen
zu müssen. Den mega162 gibt es auch mal günstiger.
Nochmal Danke, Danke.
philipp
Vielleicht noch zu beachten: Der interne Adressraum darf nicht größer
als 2k sein (2k SRAM ist schon zu viel) wenn man 8 Graustufen nutzen
will. Bei 4/2 Graustufen kann man mit mehr internem SRAM halt nicht mehr
den gesamten virtuellen Bildbereich verwenden.
Aber der Mega162 hat ja nur 1kB
Sebastian
Sebastian ... schrieb:
> Vielleicht noch zu beachten: Der interne Adressraum darf nicht größer> als 2k sein
Nicht ganz: Die theoretische Grenze liegt bei 4kByte, denn es werden
240x256 Bytes benötigt, also 61440 Bytes. Da allerdings der Wert 65536
nicht mehr in in den 16bit Adresszähler passt, funktionieren in der
Praxis nur max 3840 Bytes ohne Anpassungen am Code.
Mit den Graustufen sollte das wenig zu tun haben, denn die liegen alle
in einer Zeile.
Du hast natürlich recht. Hab mich mit High- und Low- Byte und der ganzen
Speicheraufteilung verhaun. Ist doch zu lang her, dass ich im Code
rumgemacht hab. Im Endeffekt kann man dann halt Controller mit 2k SRAM
noch nehmen, solche mit 4k nicht.
Hallo.
Ich habe das Projekt nachgebaut, und nun das Problem, dass meine
negative Spannung von etwa -21,8V auf -6,8V zusammenbricht, wenn ich das
Display anschließe.
Ferner habe ich den RAM "W24257AK-15" verwendet. Ansonsten ist es die
von Benedikt angegebene Schaltung.
Auf dem Display erscheint in der Mitte ein senkrecht unterbrochener
"Block" (weiss) mit mehr oder weniger starker Pigmentierung. Kann dies
ein Fehler der zu niedrigen Spannung sein?
Den AVR (MEGA8515-16PU) habe ich mit AVR DUDE geflasht; hierbei habe ich
die Fuses : hFuse: DF ; lFuse: FF gesetzt. Sind diese korrekt?
Gibt es ein Funktionierendes *.hex, mit einem Beispielbild, um das Board
ohne PC oder serielle Schnittstelle testen zu können?
MfG Denis
Hatte auch Probleme mit der Stabilität der Kontrastspannung. Bei mir
hats geholfen die Versorgungsspannung des Schaltreglers mit 100n direkt
am Chip zu puffern.
Gegen Masse gemessen sollte die Kontrastspannung im Betrieb bei ca. -17
Volt liegen.
Die Software zeigt immer einen Startbildschirm an. Wenn du also nichts
über die UART sendest solltest du was sehn (Ein paar Quadrate und ein
kurzer Text).
Gleich vorsorglich noch: Die erste Zip enthält einen fehlerhaften
Schaltplan. Nimm am besten immer die aktuelle Version. Auch bei der
Software.
@Benedikt:
Wollte mal mit der aktuellen Version im 4-Farb-Modus den virtuellen
Bildbereich ausprobieren. Irgendwie hats nicht funktioniert. Auch wenn
ich direkt im Controller die ensprechende Funkion aufgerufen hab hat
sich nichts getan. Muss aber zugeben, dass ich das Problem nicht weiter
untersucht habe, weils reine Neugier war.
Gruß,
Sebastian
WIeviel "Power" hat den der uC etwa noch frei?
Könnte man noch eine Auswertung eines Touch und ein paar Tastern
zusätzlich einbauen oder ist der Controller mit Bildausgaben vollauf
beschäftigt?
Weiter oben hat Benedikt mal genaue Messungen und Berechnungen gepostet.
Aber ich glaub, da gabs die 3-bit Version noch nicht.
Grob überschlagen liegt die CPU-Last bei 50%. Von daher ist noch einiges
drin. Das größere Problem dürften die anderen Ressourcen sein. Ram ist
ziemlich voll. Flash weiß ich nicht. Timer müsste in der aktuellen
Version einer frei sein, anfangs waren alle belegt.
Wenn du signifikant CPU-Last hinzufügst musst du auch beachten, dass
weniger Zeit für die Grafikberechnungen zur Verfügung steht. Bilder
Laden, Rechtecke malen,... wird dann länger dauern.
Eine Version mit 2*4 Tastenmatrix hab ich weiter oben mal gepostet.
Funktioniert bei mir einwandfrei.
Sebastian
Ich würde dann vieleicht auf den Mega162 umsteigen.
Meine Idee ist das ich ein "Bedienpanel baue mit:
- LCD320x240 + Touchpad
- Drehencoder
- 4 Tasten
- RGB Status LED
Alle Daten werden Zyklisch erfasst und ein weiterer AVR kann dann diese
Daten abrufen und ggf. Sachen an das LCD zur Anzeige senden, die 3bit
Variante wäre da schon nett :)
Wigbert Picht-dl1atw schrieb:
> Cool,Touchpad und dann noch Tasten...
Jupp, die Bedeutung der Tasten kann man erlernen und dann auch im
Blindflug treffen, das Ganze soll ein AVR basiertes Navi/Mp3 Player
sein, und wenn man während der Fahrt einfach ein Lied weiterschalten
will soll man nicht erst auf dem Display die richtige Postion suchen
müssen und dann irgenwo rauf-touchen.
> Besser wäre es wohl, den GLCD-AVR in Ruhe zu lassen, und einen 2.AVR> für den Rest zu nehmen.
Klar, aber dann muß ich schon mit mind. 2 AVRs kommunizieren, beide
brauchen Ihre layouts und Außenbeschaltung ect...
>Jupp, die Bedeutung der Tasten kann man erlernen und dann auch im>Blindflug treffen
na gut, mein Auto hat zusätzlich(vom Hersteller) auch zig Tasten am
Lenkrad.
>Klar, aber dann muß ich schon mit mind. 2 AVRs kommunizieren, beide>brauchen Ihre layouts und Außenbeschaltung ect...
auch richtig,
es gibt ja noch andere (leistungsstärkere usw.) Mikrocontroller.
Viel Spass.
Wigbert
Wie willst du das Touchpad auslesen? 8515 und 162 haben so weit ich das
gesehen hab beide keinen ADC.
Ich bin mitlerweile auch auf einen zweiten AVR ausgewichen, weil mein
Display-AVR die Pins für Ram-Paging braucht. Ist zwar noch nicht
implementiert, aber ich freu mich schon drauf auch bei 8 Graustufen
keine Ladezeiten zu sehen.
Moin.
Nachdem ich dann die Pins am hc74 von 8 auf 9 geändert habe hat das
Signal am LCD anschluss schon besser ausgesehn. Nocheinmal die
Verkabelung zum Display geprüft... siehe da... LOAD und CP vertauscht...
. Jetzt klappt es. Die negative Spannung habe ich mit einer EF20.1
(516597 - 62) vom großen C ,für ca. 2,30€, in den Griff bekommen. Wen's
interresiert, ca. 20 bis 25 Windungen 0,2mm Kupferlackdraht aufgetragen,
die Ferritte eingesteckt und angelötet.
Nun habe ich noch 2 Fragen;
- Das Display hat horizontales Flimmern. Es sieht wie ein
"Lauflicht" nach unten aus. Was kann das sein?
- Die selbstgewickelte Spule Brummt sehr laut, hat damit jemand
Erfahrung und würde mir bitte sagen, wie ich das etwas eindämmen
kann?
Versucht habe ich es schon mit etwas Abstand zwichen den Ferritten,
leider ohne Erfolg.
MfG und vielen Dank schonmal für die Hilfe
Das Flimmern kommt durch die Graustufenerzeugung. Spiel mal mit dem Wert
GRAYMOD etwas rum. Erlaubter Wertebereich steht im pdf aus der zip.
Außerdem hab ich gemerkt, dass das Flimmern mit mehr abstand und
geringerer Hintergrundbeleuchtung schwächer wird. Kenne deine Anwendung
nicht, aber vielleicht ist es dadurch dann nicht mehr relevant.
Wenn du keine großen gleichfarbigen Flächen hast wirst du das Flimmern
auch nicht mehr merken.
Wenn garnichts hilft kannst du auch die Framerate erhöhen, aber dann
erhöht sich die Rechenlast des AVR und es dauert Länger bis Bilder und
Grafiken angezeigt werden.
Zu den Spulen hab ich mal gehort, man solle Sekundenkleber zwischen die
Wicklungen ziehen lassen. Hab aber keine Ahnung, ob das hilft. Habs
selbst nie probiert.
Gruß, Sebastian
Mit GRAYMOD werd ich mal versuchen.
Der TIP mit dem Kleber, erstklassig... ich habe die Wicklungen und die
Zwichenräume des Ferritkerns mit 2 Komponenten Kleber (hatte keinen
Sekundenkleber) "behandelt"; kein Brummen, Pfeiffen oder Zischen mehr.
DANKE
bernd schrieb:
> Hallo Benedikt,>> Warum hast du CP2 mit dem /OE-Pin des RAMs und dem PD3-Pin des uCs mit> einem NOR-Gate verbunden?
Das Frage ich mich auch gerade hat das eine Bewandtnis?
Die Funktion des MUX umschaltens ist mir auch etwas unklar:
Das invertierte LOAD Signal setzt das FF auf 0, und mit CLK setzt du es
auf 1? Oder wird zwischendurch das FF auch mittels CLK getoggelt?
Hab es glaub rausgefunden:
wenn der /OE-Pin auf low gezogen wird und anschliessend wieder auf high
geht, wird am CP Pin der inverse Signalverlauf sein. Wenn das Byte vom
Ram gelesen ist, wird ein Puls erzeugt. Da das Display auf die fallende
Flanke die Daten einshiftet, funktioniert das gerade prima. ver-"nor"-t
wird das mit einem portpin. Mit diesem Portpin kann man nun festlegen,
ob ein Shift-clock erzeugt werden soll oder nicht. Wenn man das Display
akutalisieren möchte (also in der Interrupt-routine) muss man diesen
Portpin auf low legen. Wenn man einfach wahlweise Daten vom Ram lesen
möchte, bleibt der Pin aber auf high, sodass keine Shift Clocks
ausgelöst werden.
Der MUX wird einfach bei jedem Shift Clock getoggelt, und falls er mal
falsch initialisiert worden wäre, wird spätestens nach der ersten Zeile
das FF geresetted, sodass er wieder mit den korrekten Daten beginnt.
Halbwegs verständlich?
gruss,
bernd
Hallo,
ich möchte an dieser Schaltung das Glcd F-51154NF-FW-AA von Pollin
anschließen. Es hat die Größe 480x240 Pixel.
Anschlüsse:
4=Vdd (+5V)
5=D3
6=D2
7=D1
8=D0
9=Vss (GND)
10=Vee (-25V)
11=Display off (invertiert, also mit nem Pullup auf Vdd ziehen)
13=CP
14=LOAD
15=FRAME
Problem 1: Text und Grafik erscheinen doppelt.Einmal in der oberen
Hälfte des Display, und gleichzeitig in der unteren Hälfte.
Problem 2:Über UART kann ich nur Text anzeigen lassen. Das mit den
Steuerzeichen funktioniert bei mir nicht.In welchem Format werden die
Steuerzeichen gesendet.Sender ist ein Atmega 32.
Atmega 32 Atmega 8515
RDX--------------TDX
TDX--------------RDX
GND--------------GND
Hat jemand einen Tip für mich?
MfG
Karl
Welche Software-version verwendest du denn? Mit welchen Parametern?
Poste am besten mal deine param.h und wenn du hast auch ein Datenblatt
des Displays.
Dein Display wird ohne ändern der Parameter nicht (sauber) laufen. Auch
musst du auf 8 Graustufen verzichten, sonst reicht der Speicher nicht.
Außerdem musst du mit einer deutlich höheren Prozessorauslastung wegen
der größeren Auflösung rechnen. Das Rendern der Grafik dauert dann
einfach länger.
Du musst das RTS(BUSY)-Signal (PD2) noch zu deinem Master controller
führen und dort Abfragen. Die TXD-leitung des Mega8515 kannst du dir
dafür sparen (also die, auf der der Mega32 zuhört).
Gruß, Sebastian
Hallo Sebastian
>Welche Software-version verwendest du denn? Mit welchen Parametern?>Poste am besten mal deine param.h und wenn du hast auch ein Datenblatt>des Displays.
LCD Controller für 320x240
LCD mit UART Version 1.11
>und wenn du hast auch ein Datenblatt
Datenblatt habe ich leider nicht gefunden nur dass hier aus Tread
Pollin Display Optrex F51154NF-FW-AA
>Autor: Benedikt K. (benedikt) (Moderator)>Datum: 19.08.2009 11:55>Die sichtbare Fläche beträgt übrigens etwa 160x69mm, also das Display>ist recht groß.>Hier gibts weitere Infos:>http://www.goldmine-elec-products.com/prodinfo.asp...>http://pccar.ru/showthread.php?t=9191>Den 6x3 Treiber ICs nach (je 80 Ausgänge), hat das Display wie von mir>vermutet entweder 480x200 oder 480x240 Pixel.>Die Touchscreenmatrix müsste 12x8 Felder haben, wenn ich das richtig>sehe.>Da scheint wohl irgendwo ein Lager ausgeräumt worden zu sein, die Dinger>gibts überall.>Autor: Eike J. (Gast)>Datum: 30.11.2009 19:06>nachdem ich mich nun lange genug mit der Ansteuerung des Displays>gequält habe, wollte ich es hier einmal kurz erläutern:>Wie Norbert schon geschrieben hat, sind die Anschlüsse:>4=Vdd (+5V)>5=X3>6=X2>7=X1>8=X0>9=Vss (GND)>10=Vee (-25V)>11=Display off (invertiert, also mit nem Pullup auf Vdd ziehen)>13=CP>14=LOAD>15=FRAME>Nun zur Ansteuerung mit einem Mikrocontroller.>1. die 4 Bit ausgeben (CP low, LOAD low, FRAME high)>2. CP high (die 4 Bit bleiben natürlich, LOAD low, FRAME high)>3. die nächsten 4 Bit ausgeben (CP low, LOAD low, FRAME high)>4. CP high (die 4 Bit bleiben natürlich, LOAD low, FRAME high)>das solange bis die zeile voll ist, also 120 mal, da es 480 Pixel sind.>Wenn die Zeile voll ist, wird nach den letzten 4 Bit CP auf high gezogen>und danach auch noch LOAD auf high (CP low, FRAME high). Dadurch springt>der "Cursor" in die nächste Zeile und ihr könnte die wieder>vollschreiben.>wenn alle 240 zeilen voll sind, muss wieder in die erste zeile>gesprungen werden, dazu wird FRAME auf low (rest auch auf low) gezogen.>ich hab bevor ich den frame auf low ziehe auch noch einen zeilenumbruch>gemacht, ob das nötig ist, weiß ich nicht, aber es stört auch nicht.>jetzt geht der spaß wieder von vorne los.>und zwischen jedem "schaltvorgang" hab ich 1 microsec delay zwischen,>ist aber nur ausprobiert, damit gehts aber auf jeden fall..>ich hoffe mit dieser anleitung gehts bei euch etwas schneller als bei>mir..^^>Gruß Eike
Habe die Schaltung auf Lochrasterplatte aufgebaut, funktioniert bis auf
die Auflösung(480X240Pixel werden angezeigt, aber die obere und untere
Hälfte werden gleichzeitig beschrieben) und eben die Sache mit den
Steuerzeichen. Ich habe bei meinen Schaltungen bis jetzt nur mit RXD und
TXD gearbeitet.
>Du musst das RTS(BUSY)-Signal (PD2) noch zu deinem Master controller>führen und dort Abfragen.
Ich schalte also RTS auf TXD vom Master?
Hast du für die Busy Abfrage einen Code-Schnipsel vieleicht mit ner
kleinen Erklärug?
Gruss
Karl
Ganz kurz:
Du musst mindestens Version 1.2 nehmen, nimm aber am besten die
aktuelle. 8-Grastufen musst du dann halt in der param.h deaktivieren. So
beim Überfliegen ist mir sonst nichts aufgefallen.
Sebastian
So, jetzt hab ich wieder mehr zeit.
RTS vom 8515 legst du auf einen beliebigen (als Eingang konfigurierten)
Pin des Masters. Rx vom 8515 kommt auf Tx vom Master. Tx vom 8515 bleibt
offen.
Die Funktion von RTS ist im pdf aus der zip ganz gut erklärt:
Hinweise zur Ansteuerung:
Aufgrund der teilweise ziemlich rechenintensiven Grafikbefehle sollte
der RTS/Busy Ausgang vor dem Senden eines Befehls abgefragt werden. Der
Controller verfügt zwar über einen 256 Byte Befehlspuffer, aber auch
dieser ist irgendwann voll, wenn mehrere aufwendige Befehle ohne Pause
gesendet werden! Solange der RTS/Busy Pin Low ist, kann man gefahrlos
mindestens 64 Bytes senden, da RTS/Busy aktiviert wird, wenn der Puffer
zu ¾ gefüllt ist. Man braucht also nicht vor jedem Byte RTS/Busy zu
prüfen, sondern es reicht einmal vor jedem Befehl (falls dieser kürzer
als 64 Bytes ist.)
Dein Display hat so weit ich das mitbekommen hab aber nur 200 Zeilen,
also eine Auflösung von 200*480.
Wenn ich nicht wieder nen Denkfehler drin hab ist deine Softwareversion
wie gesagt zu alt. Du musst dann eine nehmen, die einen virtuellen
Bildbereich unterstützt. In jedem Fall wird es nicht schaden, die
aktuelle Version zu verwenden. #define GRAY8 musst du dann halt
auskommentieren.
Und schreib bitte, obs dann funktioniert. Am Besten mit Bild. Bin am
Überlegen, ob das Display was für mich wäre.
Gruß, Sebastian
>In jedem Fall wird es nicht schaden, die aktuelle Version zu verwenden.
habe es mit der Vers. 1.2 und 1.3 versucht.Das Ergebnis ist das
Gleiche.Dann bin ich beim Prüfen mit VSS an D0 gekommen.Das hat mich den
BC327 und vermutlich das Display gekostet.Habe ein Neues bestellt.
Servus,
nachdem mir das Bilder laden immer zu langsam ging, hab ich mal die
Software noch ein wenig aufgebohrt. Ich muss zugeben, dass das ganze ein
wenig aus dem Ruder gelaufen ist, denn die Timings sind jetzt schon sehr
hart, aber ich wollte dann einfach sehn, was möglich ist.
Mit der Angehängten Version kommt man bei 3 bit/Pixel Vollbildern auf
sagenhafte 5 Frames pro Sekunde!
Baudrate ist dabei 2MBaud.
Die BSY-leitung verhält sich jetzt anders:
Für jede fallenden Flanke von BSY muss man ein Byte senden. Das Byte
muss nicht sofort kommen (sollte es aber), aber man darf auf keinen Fall
eine Flanke übersehen.
Zwischen zwei Flanken liegen mindestens 1,5µs, also 24 Takte bei 16MHz.
Das kann man auch nicht wirklich durch den Master ausbremsen. Lediglich
die Framerate sinkt, wenn man langsamer sendet. Im Mittel werden die
Flanken auch seltener, aber mehr als 1,5µs kann man nicht garantieren.
Außerdem muss man nach einem Bild mit 3 bit immer 2 Dummy-Bytes senden.
Ich empfehle 0x0, dann auch gerne ein paar mehr Bytes (falls unterwegs
was passiert sein sollte).
Die Parameter der angehängten Version sollte man möglichst nicht ändern,
insbesondere die Baudrate sollte wohl mindestens auf 1MBaud stehen. Zwar
werden viele einstellungen funktioniere, ich hab mir aber keine Gedanken
über andere Parameter gemacht, kann also nichts mit sicherheit sagen.
Wie das ganze funktioniert?
Der Software-Fifo ist ausgebaut worden. Statt dessen verlasse ich mich
auf den Hardware-Puffer der USART.
Im Normalen Betrieb wird immer ein Byte im Puffer vorgehalten. Ruft das
Programm ein neues Byte aus dem Puffer ab, so wird direkt das nächste
durch fallende Flanke auf BSY bestellt.
Wenn der Controller zum Anzeigen eines 3-bit Bildes kommt, werden zuerst
durch 2 fallende Flanken zwei weitere Bytes bestellt. Eines davon landet
im zweiten Byte des Hardware-FIFO, das zweite bleibt im Shift-register.
Durch die 3 Byte Puffer ist es möglich, die Zeit während dem
Display-intterupt zum senden von 2-3 Byte zu nutzen. Zwischen 2
Interrupts werden dann nochmal 3-4 Bytes übertragen und 6 Bytes
verarbeitet. Ungefähr - im Mittel.
Wenn das Bild fertig übertragen ist muss noch der Puffer geleert werden.
Man könnte natürlich "einfach" beim verarbeiten der letzten beiden Bytes
keine Flanke erzeugen. Ich habs mir hier aber leicht gemacht und lese
zwei Dummy-Bytes aus. Der inhalt ist egal, aber der Sender muss halt
zwei zusätzliche Bytes senden.
Viel Spass damit. Vielleicht kanns ja jemand gebrauchen.
@Benedikt:
Wenn du mir eine große Freude machen willst: Lass doch mal mit 5fps 3bit
Farbe ne Filmsequenz über das Display laufen :-)
Viele Grüße, Sebastian (der von den Graustufen :-)
Vielleicht noch als Hinweis für alle, die's mal ausprobieren wollen:
Ich hab auf meinem Master einen Interrupt der auf fallende Flanke von
BSY triggert. Das ist auch der einzige Interrupt am Master, sonst würden
wohl die Latenzen zu groß. Bei jedem Auslösen zählt eine Variable um
eins hoch, sie zählt also, wie viele Bytes zu senden sind.
In der Main-loop schau ich dann, ob diese Variable Null ist. Wenn nicht,
wird, sobald UDR leer ist, ein byte gesendet und die Interrupt-Variable
wieder um eins verringert.
Sonst passiert auf meinem Master auch nichts. Viel rechenzeit dürfte
auch nicht mehr übrig sein ;-)
Gruß, Sebastian (der sich auf Kommentare freut :-)
Ist ja ein super Projekt. Vielen Dank!
Hat jemand noch Interesse an Leerplatinen (DIP4-Version)? Werde in Kürze
welche in Auftrag geben. Preis dürfte so bei ca. 8 Euro pro Stück liegen
+ Versand.
Schöne Grüsse
@Günter S. (varda)
war die Platine hier schon mal ausgestellt?
Brauche 2 Stück, allerdings sollte der S-Ram in SOJ 28 drauf.
Also, wenn Du noch routest, steuere ich die S-Rams sogar bei.
IS61C256AL 12ns.
Wigbert
@Wigbert
Die Platine wurde hier noch nicht ausgestellt. An der Platine selbst
möchte ich selbst keine Änderungen vornehmen. (Möchte mich nicht extra
in Eagle einarbeiten - mache alles in KICAD)
Sollte sich jemand aber finden, der die Änderungen vornimmt wäre es auch
ok! (hätte auch noch eine Änderung .... der 12 pol. Flexprintanschluss
zusätzlich als Stiftleiste rausführen)
Günter
Mist,
Günter, ich dachte Du nimmst mir die Arbeit ab.
Also meine Platine wäre 100x80 hätte zusätzlich eine Adapterplatine
Stiftleiste-Flexprintstecker für NANYA. Allerdings muss ich den S-Ram
noch routen. Könnte dann bei Interesse die S-Rams für 1 Euro zulegen.
Um ein ordentlichen Preis zu erhalten sollten ca.20 Platinen
zusammenkommen.
Das ganze sähe dann etwa so aus, aber mit Lötstopplack
Beitrag "Re: Grafikfähiger LCD Controller für 320x240 LCD mit 4 Graustufen"
Wigbert
Hallo,
Günter war zuerst da. Also steht ihm auch die Sammelbestellung zu.
Ich wollte nur helfen, nicht wegnehmen.
Mit dem Spannungsregler ist Ansichtssache. Hatte ich doch neulich
ein Pollin GLCD mit 320x240 Pixel mit positiver Kontrastspannung.
Da wäre es Sinnvoller die Kontrastspannung extern zu erzeugen.
Raufpassen tut die Spannungsversorgung noch auf dem Board.
Wäre kein Thema.
Genauso das Adapterboard, das lässt sich dann an das GLCD anpassen.
So, jetzt hat aber Günter erstmal das Wort.
Wigbert
Ich sage mal so ...
Änderungen am Layout bzw. Schaltung würden bestimmt einige Zeit in
Anspruch nehmen. Jeder hat bestimmt so seine Änderungswünsche. Sind
event. nicht leicht auf einen Nenner zu bringen.
Ich denke mal, mit dem Layout und der Schaltung aus DIP4.zip dürften
doch mehr oder minder alle zufinden sein.
Hallo @ alle mal!
Ich wuerde mir unheimlich gern diese Ansteuerung fuer das NANYA Display
bauen. Es waere ideal wenn es dann im Endeffekt ueber Funk ansprechbar
waere. Kann mir da jemand bitte helfen?
1) Welches Board Layout stimmt jetzt und ist bereit zum aetzen? (EAGLE
4.x)
2) Was benoetige ich alles fuer Bauteile? In den Beitraegen wurde die
oefters ausgebessert...
3) Also kann man die CCFV Schaltung als Spannungsversorgung nehmen?
4) Ist es unabhaengig welchen SRAM man nimmt? Bei dem Layout kann man
ja nur eine beschraenkte Anzahl an SRAMs nehemen oder?
5) Brauche ich sonst noch was?
Ich bitte drum, kann mir wer bitte helfen? Oder bitte verweise auf die
dateien oder so?
Ich danke echt im Voraus!
Hey, genau den hab ich auch gefunden. Leider bin ich mit der
Leiterplatte noch nicht so weit. Aber wenn der UM61256CK-20 gehen sollte
wäre das echt prima. Habe da jetzt 10Stück rumliegen.
Gerne auch ein paar zum Abgeben!
Hallo,
ich hab ein kleines Problem mit dem Code, wenn ich ihn im AVR Studio
öffne und compilieren will scheinen die Funktionen welche die Ausgabe
auf das Display steuern zu fehlen welche laut dem aller ersten Post in
Assembler geschrieben sind, ich konnte jedoch auch keine Datei in dem
Archiv finden welche Assebler-Kommandos (inline-Asselbler o.ä.) enthält.
Muss ich diese Datei extra wo runterladen? oder handelt es sich bei der
.bin evtl. um eine Precompiled Variante?
Danke, Thomas
Hast du auch die letzte offizielle Version von hier
Beitrag "Re: Grafikfähiger LCD Controller für 320x240 LCD mit 4 Graustufen"
genommen? Da gibts ne .aps. Wenn du die im Studio öffnest sollte es
eigentlich funktionieren.
Die Software aus dem ersten Post ist mittlerweile veraltet und lässt
sich nicht so schön einfach im Studio öffnen und compilieren.
Sebastian
Habe das Projekt in Kicad umgesetzt.
Die Platinen sind zwischenzeitlich auch schon gekommen. Gestern gleich
aufgebaut - Mit LCD von Pollin 480x200; geht wunderbar.
Benedikt - einfach ein tolles Projekt von Dir ! Super
Ich finde das toll, was du da ihr da auf die Beine gestellt habt
(besonders Benedikt)!
Eine Frage: Funktioniert die Schaltung auch mit dem Display WINTEK
WD-H3224V von Pollin (Best. Nr. 120 506)? Das hat doch eine positive
Kontrastspannung, wie muss ich den Teil mit dem Schaltregler abändern,
dass es funktioniert?
Hallo Wigbert,
schöne Platine. Wegen RAM - Habe auf meiner Platine normale RAM mit 70
ns. Laufen auf ohne Waitstates. Sogar bis 20 MHz, wenn ich den AVR mit
20 MHz Quarz betreibe.
Hallo Günter
Deine Platine muss sich aber auch nicht verstecken.
Mein Board hätte vielleicht kleiner werden können.
Wobei, in der Höhe stimmen die Befestigungslöcher mit dem Display.
Bei S-Rams kann sicher etwas Glück hilfreich sein. Meine
S-Rams sind so nun mal vorrätig.
Die Platine lief sofort, und seltsamerweise stimmte sogar der
Kontrast sofort mit meiner Widerstandsauswahl.
Wigbert
Hallo,
Ich wollte immer noch den mega162, statt dem mega8515 verwenden, da ich
auch noch zufällig welche davon rumliegen habe (mal mit mega168 beim
Bestellen verwechselt). Mit den zusätzlichen PWM Channels, wollte ich
z.B. die LED Hintergrundbeleuchtung dimmen. Da ich SMDs verwende kann
ich sie jedoch nicht einfach wechseln.
Meine Frage: Wie kommt der Wert "DDRAM 1024" zustande?
mega8515:
"To the Application software, the external 32 KB memory will appear as
one linear 32 KB address space from 0x0260 to 0x825F. This is
illustrated in Figure 17."
mega162:
"To the Application software, the external 32 KB memory will appear as
one linear 32 KB address space from 0x0460 to 0x845F."
Zum Wechsel zwischen m8515/m162 hatte Benedikt geschrieben:
"Geändert werden muss dazu nur die Zeile #define DDRAM 1024.
Diese muss auf den Ende des internen und Beginn des externen RAMs also
auf 0x500 = 1280 gesetzt werden."
Also meine zweite Platine der Schaltung (bei Bilex machen lassen) ist
fertig aufgebaut, und ich glaube auch nicht, dass durch einen falschen
DDRAM -Wert die Hardware kaputt geht, aber ich trau mich nicht sie
anzuschliessen, da ich auf der ersten auch einen mega162 aufgeloetet
hatte, der wahrscheinlich schon defekt war.
[ Habe schon so drei Dutzend mega8/48/32 "verarbeitet", doch dieser war
mein erster kaputter, und das Smdteil wieder rauszukriegen macht die
Platine nicht schöner.]
Ich bezweifel ja auch nicht Benedikts Angabe, der 1024er Wert
funktioniert ja bei mir mit dem sicherheitshalber eingesetzten
mega8515 ja sehr gut - wie bei allen Anderen. DANKE für das tolle
Projekt, doch verstehen tue ich auch den schon nicht, daher schon gar
nicht den 1280er Wert. Kann mir da geholfen werden?? Ich programmiere ja
nur in C, nicht Assembler, und Speicherverwaltung sollte man schon etwas
kennen, konnte mich aber bisher davor drücken, und hatte auch nie
Probleme bemerkt.
Vielen Dank für eure Hilfe, tolles Forum,
Philipp
Hallo,
ich habe den Controller nachgebaut, leider sieht man auf dem
angeschlossen Display garnichts. (Hitachi SP14Q006-T)
Mit dem Oszi sieht man z.B. auf den SRAM-Leitungen Rechtecksignale, d.h.
der Controller tut irgendwas. Ich erwarte eigentlich dieses Testbild,
oder muss ich dem Display erst Daten senden?
Außerdem bin ich mit bei der Verkabelung der Anschlüsse V0 und VEE nicht
ganz sicher. Ich habe an VEE die -21 Volt angeschlossen, V0 ist über ein
Poti als Spannungsteiler bei -17 V.
Was muss ich mit der AC-Leitung des Controllers machen?
Gruß,
Alex
Im Datenblatt des SP14Q006-T habe ich eine VDD-V0 von +21V gelesen,
allerdings ist weiter hinten eine Beispielschaltung mit einem Poti
zwischen +5V und -22V (Mittelabgriff am V0). Hmm
AC müßte eigentlich an FLM vom Display gehen.
Hallo
Hab da mal ne Frage:
Ist es auch möglich statt der UART-Schnittstelle eine parallele
Schnittstelle zu integrieren?
PortB ist ja rein theoretisch noch frei. Bin in C leider nicht wirklich
involviert. Sonst hätt ich es schon geändert.
Der Uart bremst die Anzeige meiner Meinung nach ganz schön aus. Ich
benutze momentan die neuste Version (8-Graustufen) mit 666666Baud.
LG Steffen
Sollte gehen. Du müsstest halt den UART-Fifo umbaun, so dass er sich die
Daten vom Port holt. Statt dem UART-interrupt nutzt man dann den INT0
(wo momentan BSY drauf hängt. BSY müsste man halt auf PD0 oder PD1
verlegen. Im Interrupt muss du dann das Daten-senden auf jeden Fall
gesperrt sein, sonst gehen daten verloren. Auch muss dein Master dann
unverzüglich auf BSY reagieren, eben weil sonst daten im Interrupt
verloren gehen.
Was für eine Performance erwartest du denn? Und welche Version
verwendest du genau? Die letzte von Benedikt? Die letzte von mir läuft
auch mit 2MBaud. Mit 666666 Baud bist du über die UART ja schon auf 2.3
fps beschränkt. Mit meiner letzten schafft man ca. 5fps. Wenn dir das
nicht reicht oder das Timing für den Master zu hart ist kann ich dir
noch ne Version mit bis zu 7fps anbieten. Das ist dann das theoretische
Maximum der UART. Allerdings hab ich die Anpassungen hier etwas
inkonsequent vorgenommen. Was ich brauch funktioniert, für den rest kann
ich nicht garantieren.
Bei mir bremst mitlerweile auch der Master. 7fps schaff ich in der
Praxis nicht. Vielleicht ginge mehr, wenn man einfach auf einen Port
schreiben könnte, aber drauf zählen würde ich nicht, weil du dann wieder
auf dein Display hören musst.
Sebastian
Hi Sebastian
Danke für die schnelle Antwort. Ich werd es mal versuchen, doch wie
gesagt, meine C-Kentnisse sind sehr rarr. Hab gesehen dass der
Grafikcontroller für die 640x480 LCD´s ja auch anfangs mit einer
parallelen Schnittstelle versehen war.
Wenn ich nicht weiter komme meld ich mich wieder..
LG Steffen
Ach ja, ich brauch ja eigentlich auch nur den Textmodus (möglichst in 8
Graustufen) und den Befehl 16 (Bild laden) in S/W. Vielleicht kann man
ja die restlichen Funktionen entfernen..
Steffen
Der Textmodus wird aber doch nicht zu langsam sein, oder? Bei 666666Baud
sind das immerhein 83 Displayseiten pro sekunde.
Bzw. wenn das nicht erreichbar ist dann bringt auch ein paralleles
interface nichts, weil einfach das Verarbeiten der Daten so lange
dauert.
Auch bei S/W-bildern kann man sich ausrechnen, dass rein von der UART
her bei 666666Baud fast 7fps drin sein müssten. Die schafft man auch
nicht, weil nämlich die datenverarbeitung zu langsam ist.
Zumindest bei den Bildern könnte man die Verarbeitung verbessern. Das
sind dann aber tiefgreifendere Änderungen.
Jedenfalls wird dir das parallele Interface (wenn ich mich nicht
verrechnet hab) nichts bringen solange du nicht teile der
Datenverarbeitung grundlegend änderst.
Sebastian
Ja, es ging mir hauptsächlich um den Grafikaufbau. Text ist kein
Problem. Ich teste jetzt gerade mit einem Master mit 666666Baud. Das
Resultat ist doch sehr gut. Nur mein später anvisierter Master läuft mit
10Mhz und da ist eine max. Baudrate von 250kBaud drin. Deswegen hatte
ich den Parallelbetrieb angepeilt.
Es soll übrigens mal ein 2-Kanal-DSO mit 2xADS831 werden. Mit dem
AVR-eigenen ADC´s funktioniert es schon recht gut. Nur sind die nicht
brauchbar für höhere Frequenzen.
LG Steffen
Ich bin endlich auch einmal dazugekommen, die Schaltung nachzubauen. Ich
verwende das Wintek-Display von Pollin (laut DB hat das eine positive
Kontrastspannung, kann das sein?). Gibt es ein kleines Testprogramm für
den Mega8515 (also den LCD-Controller selbst), mit dem ich die Funktion
überprüfen kann?
grüssse
w.
Wegen der Kontrastspannung schau mal hier
Beitrag "Einfacher Low Cost LCD Controller für 320x240 LCD im Textmodus"
da haben einige das Wintek display verbaut. Da hat sicher auch jemand
über die Kontrastspannung geschhrieben.
Die Firmware zeigt standartmäßig automatisch ein Startbild an. Wenn
alles läuft sieht man also auch was, ohne dem Controller daten zu
schicken.
Dein Fehler könnte allerdings in der Schaltung an sich liegen. Die erste
Zipdatai die hier hochgeladen ist enthält einen Fehler im Schaltplan.
Nimm immer die letzte von Benedikt hochgeladene Version. Das ist im
allgemeinen die mit den wenigsten Fehlern.
Viele Grüße,
Sebastian
Hallo nochmal. Ich bin nun wieder am Arbeiten an diesem Projekt... Die
Textausgabe auf dem Display ist wirklich gut. Dennoch habe mit 3
Terminal Programmen versucht auf dem Display die im Beispiel genannten
"Codes" probiert, leider ohne erfolg. -Bzw. je nach Daten sende Art auch
mit Kryptischen Zeichen. Wie sind denn die Fusebits als Hex? Einen
MEGA8515 habe ich schon verfust... Mit was sendet ihr die Daten auf den
Controller? Gibt es eine Beispielschaltung, o.ä.? Mein Adapter besteht
aus Serielle Schnittstelle -> MAX232 -> MEGA8515.
Wenn ich das Display mit Zeichen fülle, ändert sich der Hintergrund.
Sprich viele "O" und das Display wird dunkler, viele "i" oder "l" und
das Display wird heller. Was kann ich dagegen tun?
MfG Denis
Was genau funktioniert nicht? Kommt immer was falsches am Display an,
oder nur, wenn du versuchst, die Grafik-funktionen zu nutzen?
Allgemein macht mir dein Beitrag einen sehr kaotischen eindruck. Wenn
das Testbild angezeigt wird passen die Fuses erstmal bzw. sind zumindest
nicht vollkommen falsch. Wenn Text so angezeigt wird, wie du ihn sendest
funktioniert auch die UART-kommunikation, dann liegt der Fehler daran,
dass du die Kommandos falsch eingibts.
Die Fuses sind eigentlich relativ unkritisch. Der AVR muss halt mit
16MHz laufen. Brown out kann man anschalten, wenn mans nicht tut läuft
der Controller aber trotzdem, muss also nicht sein. So weit ich mich
erinner wars das auch schon. Glaube aber, hier im Thread wurde schonmal
über die Fuses geschrieben.
Und die UART läuft halt mit 1 Startbit, 8 Datenbits, ohne Paritätsbit
und ein oder zwei Stopbits - letzteres ist egal, da der AVR das zweite
Stopbit einfach ignoriert. Mit den Einstellungen sollten eigenltich
Daten am AVR ankommen. Wenn nicht schau mal in die Artikelsammlung. Da
gibts so weit ich weiß ne Anleitung zum UART debuggen.
Ich sende meine Daten von einem zweiten AVR aus zum Display.
Funktioniert bei mir wunderbar.
Sebastian
Hallo.
Wenn ich Text eingebe, kommt der an, aber das Testbild verschwindet
nicht. Dazu nutze ich HTERM. Ich sende die Daten in ASCII. Wie sende ich
die befehle? Kommen irgendwelche Anführungszeichen oder Vorzeichen vor
die Kommandos?? Gibt es für den Mega8 oder Konsorten ein kleines
Beispielprogramm?
MfG Denis
Na dann funktioniert doch alles. Fuses und UART einstellungen müssen
zumindest halbwegs passen, sonst würde der Text doch nicht ankommen. Die
Kommandos musst du als Zahlenwerte schicken. Ich kenne HTERM nicht, aber
da kann man sicher irgendwo einstellen, dass es Dezimal/Hex/Binärwerte
schicken soll. Und dann gibst du halt einfach die Zahlenwerte aus der
Dokumentation ein.
Dass der Startbilschirm nicht verschwindet ist normal. Der wird nur
überschrieben. Wenn er komplett gelöscht werden soll musst du das über
den passenden Befehl anweisen.
Hallo Sebastian, ich hoffe Du schaust hier hin und wieder nochmal rein!
Nach meiner Kalenderuhr (die übrigends in der Zwischenzeit ein Gehäuse
bekommen hat und immer noch super läuft) versuche ich dieses Projekt zu
verstehen und nachzubauen. Allerdings wie Du ja weißt, in Assembler.
Wäre schön, wenn Du mir auch diesmal helfen könntest.
Ich habe die Schaltung wie von Benedikt vorgegeben, nachgebaut (meine
ich jedenfalls). Statt eines 8515 habe ich allerdings einen ATMega162
verbaut.
Um mich der Sache langsam zu nähern, habe ich Benedikts Programm
gnadenlos zusammengestrichen und nur das unbedigt Nötige behalten.
Geändert habe ich natürlich YMin, da der interne Speicher des 162 bis
0x4FF geht. Angezeigt werden soll nur ein kleines Rechteck mit einem
einzigen Farbton.
Leider zeigt das Bild aber etwas anderes als erwartet und vor allem
läuft es durch (siehe Bild).
Hast Du dafür eine Erklärung??
@Spätkommender: Leider nicht. Hatte nie ne geätzte
@Bruno
>Ich habe die Schaltung wie von Benedikt vorgegeben, nachgebaut
Gleich mal vorsorglich: Das im ersten Beitrag angehängte zip hat einen
Fehler im Schaltplan. In der letzten Offiziellen Version gibts übrigens
(neben einem korrekten Schaltplan) auch 8 Graustufen falls du das noch
nicht gesehen hast.
Heut ists bischen spät um mir das genauer anzuschaun (morgen dann), aber
warum nutzt du nicht das Projekt einfach wie es ist als Grafikkarte und
steuerst die über einen weiteren AVR per UART an? Das funktioniert sehr
gut und du brauchst an diesem Projekt nichts mehr zu ändern.
Alternativ wäre es doch eine gute Gelegenheit endlich mal C zu lernen.
Früher oder später brauchst du es sowieso.
Viele Grüße,
Sebastian
Hallo Sebastian,
super, daß du dich so schnell gemeldet hast!!
Das mit dem Fehler im ersten Schaltplan hatte ich schon registriert.
Da es mir in erster Linie darum geht, die Schaltung und das Programm
richtig zu verstehen, hilft mir die Übernahme des kompletten Projektes
wenig.
Auch deine Version mit den 8 Graustufen habe ich gesehen, aber das wäre
dann der nächste Schritt.
Dein Hinweis auf C ist natürlich völlig richtig und mir wird
wahrscheinlich gar nichts anderes übrig bleiben, wenn ich das gesamte
Projekt verstehen will. Im Moment bin ich aber noch bei der LCD Routine
(die ja sowieso in ASM geschrieben ist) und der trickreichen Ankopplung
des externen RAM.
Zu meinem Problem selbst noch der Hinweis, daß ich in der Zwischenzeit
noch weitere XL und XH Werte getestet habe. Dabei sieht es so aus, als
würde XL von der rechten Seite gezählt und nicht von der linken??? Wenn
die Höhe des Rechtecks unter 10 Pixel liegt, dann sieht man einzelne
Balken.
Ich hoffe du kannst daraus irgendwelche Schlüsse ziehen.
Schon im Voraus herzlichen Dank für die Mühe!
Gruß
Bruno
Hallo Sebastian,
ich meine ich kann dir die Fehlersuche im Code ersparen. Ich habe jetzt
meinen gesamten Programmteil weggelassen und nur aus der Routine von
Benedikt heraus ein Pixel unmittelbar vor der Ausgabe auf 1 gesetzt. Da
auch dann das Bild durchläuft, kann es meiner Meinung nach nur noch an
der Hardware liegen. Ich werde jetzt mal alle ICs tauschen.
Gruß
Bruno
Ich glaube nicht, dass das ICs tauschen was hilft. Wenn du einen
Hardware-fehler hast, dann wahrscheinlich in der Verdrahtung.
Um das zu prüfen wird es aber geschickter sein, die Sourcen von Benedikt
nur auf den anderen Controller anzupassen. Dann hat man eine ganze Menge
mögliche Fehlerquellen weniger.
Zu deinem Vorhaben den Code zu verstehen: Das aufregende ist sowieso
alles in Assembler geschrieben. Die Ausgaberoutine hast du ja schon
gesehen. Dann gibts noch ein paar Routinen um Daten in den RAM zu
schreiben, die auch quasi alle in Assembler geschrieben sind.
Was dann in C passiert sind höhere Aufgaben, wie z.B. der
Bresenham-Algorithmus um linien zu zeichnen. Oder die
UART-kommunikation. Aber das ist eigentlich alles nicht mehr so
aufregend.
=> Lass die sourcen wie sie sind (abgesehen von der Anpassung auf den
anderen Controller), versuch den ASM-teil zu verstehen, schau dir an was
im C-Teil gemacht wird und überleg dann, welche Anpassungen du machen
musst.
Gruß, Sebastian
Hallo Sebastian,
wie du schon angekündigt hast, hat das tauschen der LCs nichts gebracht.
Auch die Verdrahtung habe ich gründlich geprüft und nichts feststellen
können.
Auch in meinem ASM Code konnte ich bis jetzt keinen Fehler entdecken.
So versuche ich deiner Empfehlung zu folgen, das Original C-Programm zum
Laufen zu bringen. Für einen C Anfänger ist dieses komplexe Programm
natürlich eine gewaltige Herausforderung. Da werde ich sicherlich
kleiner anfangen müssen.
Es ging schon damit los, daß ich die main.elf Datei zwar öffnen konnte,
aber nicht bearbeiten (alle Dateien wurden als "read only" angezeigt).
Das konnte ich durch Anlegen eines neuen Projektes und Einbinden der
Orginaldateien lösen. Auch das Anpassen des Speichers durch eine
Änderung des Parameters DDRAM bekam ich noch hin. (Wenn ich es richtig
interpretiere hätte ich wahrscheinlich auch mit dem Ursprungswert leben
können!).
Beim Build and Run meckert er aber nun, daß RXCIE und RXEN nicht
definiert sind. Wahrscheinlich hängt es damit zusammen, daß der AT162
zwei USARTs hat und der AT8515 nur einen.
Wie und wo ich aber das ändern kann, habe ich wirklich keine Ahnung.
Ich hoffe du kannst mir mit einem einfachen Hinweis weiterhelfen. Ich
weiß natürlich auch nicht, ob der Debugger im weiteren Verlauf nicht
noch neue Probleme findet.
Schon mal herzlichen Dank für deine Hilfe!
Gruß
Bruno
Das includefile (m8515def.inc) hast du durch das für deinen Controller
getauscht?
Wenn 162er wirklich 2 uarts hat haben die UART-bits jeweiles noch ein
0bzw. 1 im namen. Aber eigentlich sollte die UART-lib das schon selbst
abhandeln, wenn du das includefile getauscht hast. Wenn nicht (benedikt
hat recht viel an der lib rumgebastelt), dann musst du halt die Bitnamen
ändern. Der Compiler sagt dir ja eigentlich, wo es hakt.
Hallo Sebastian,
mit jeweils einer 0 dahinter und einigen anderen Anpassungen habe ich
tatsächlich eine hex Datei bekommen.
So weit so gut. Jetzt weiß ich zumindest, daß es offensichtlich an der
Hardware liegt. Nur leider finde ich nichts. Kann es daran liegen, daß
ich als FlipFlop keinen HC Typ habe, sondern einen F?
Oder kannst du aus dem Bild etwas anderes ableiten?
Gruß Bruno
@Bruno
>> Geändert werden muss dazu nur die Zeile #define DDRAM 1024.>> Diese muss auf den Ende des internen und Beginn des externen RAMs also>> auf 0x500 = 1280 gesetzt werden.
Hast du das berücksichtigt ?
Ich benutze auch einen M162 und es funktioniert mit Benedikt's code
einwandfrei.
Hallo Helfender,
herzlichen Dank für den Tip, aber das habe ich schon berücksichtigt. Ich
habe sogar 0x600 genommen, da Benedikt auch etwas Luft gelassen hat. Der
8515 Speicher geht ja nur bis 0x260.
Gut zu wissen ist aber, daß der 162 sonst keiner weiteren Einstellungen
bedarf.
Sorry, ich habe mir nicht den ganzen Thread durchgelesen.
Das FF als "F" kann laut Datenblatt 90MHz, dürfte also auf jeden Fall
schnell genug sein.
Aber irgendwie sieht es aus als ob dein Takt nicht stimmt.
>> Pin1 vom HC157 an Pin9 des HC74>> am hc74 pin8 und pin12 verbinden
Diese Änderung hast du auch berücksichtigt ?
@ Helfender
Ja, die Änderung habe ich berücksichtigt. Allerdings brauche ich keinen
AC Anschluß und daher habe ich das erste FF mit entsprechend geänderten
PinNr. benutzt. Pin5 (FF) an Pin1 (HC157) und Pin2 (FF) an Pin6 (FF).
@ kay
Die 0x500 ergeben sich aus dem Datenblatt des AT162. Der interne
Speicher bei normaler Konfiguration (d.h. nicht im AT161er Modus) geht
bis 0x4FF. Der externe Speicher kann also erst bei 0x500 beginnen.
hallo Bruno,
Der externe Speicher kann also erst bei 0x500 beginnen. ja das ist mir
klar ,nur ich meinte wie kommt ihr auf 1280 sind ja 0x500 bloss wie
kommt mann auf die 1280 das ist mir nicht ganz klar
mfg
Hallo kay,
>> wie kommt ihr auf 1280 sind ja 0x500
das 0x vor 500 sagt, daß es sich um einen hexadezimalen Wert handelt. Du
nimmst dir also einen Rechner, der hexadezimal rechnen kann, gibst 500
ein und wandelst es in dezimal um, dann bekommst du 1280.
Hallo Helfender,
leider hat auch deine Datei keine Änderung gebracht. Es liegt also
eindeutig an der Hardware. Ich weiß nur nicht, wo ich noch suchen
könnte. Die Verdrahtung habe ich schon mindestens 5 mal geprüft. Auch
die Signale habe ich schon mit dem Oszi getestet. FRM, LP und CLK zeigen
den erwarteten Verlauf.
Eigentlich müßte ja das Bild eindeutige Hinweise liefern, aber ich kann
es leider nicht deuten.
Fällt dir noch was ein?
Ist das Bild statisch, oder läuft das durch?
Und welches LCD verwendest du? Datenblatt? Wie hast du es angeschlossen?
Wenn deine Schaltung nach Plan stimmt kann es eigentlich nur am
Anschluss des LCD liegen (oder eben doch an der Software, aber ich denke
mal, dass das hexfile von Helfender passen sollte).
Wie schnell taktet dein AVR eigentlich?
Sebastian
@Bruno
ich habe bei mir mal zum Test einen MC74F74 eingesetzt und der
funktioniert ebenfalls tadellos. Kannst du also 100% ausschliessen.
Danach habe ich mal meinen LA an CP,LOAD,FRAME und eine Datenleitung
geklemmt. Ablauf siehe Screenshoot.
Load kommt ca. alle 41µs. Frame ist ca.26µs lang. In welchem Abstand
kann ich nicht sagen, dafür ist der Samplespeicher zu begrenzt.
Hallo,
ich hab vor, nochmals ein paar Platinen anfertigen zu lassen und
in einen Shop zu hinterlegen.
Neu ist der V-Regler und die Bereitschaftsanzeige. Die Platine
hat in Betrieb ca 85mA so das der V-Regler weitere Platinen
versorgen kann. 5V kann an 3 Stellen abgenommen werden.
Preisvostellungen:
GLCD_32K Platine: 10 Euro.
S-Ram + sämtliche SMD-Bauteile + Speicherspule: 1,50 Euro
NANYA-Adapterplatine: 0,5 Euro
FFC Buchse: 1,80 Euro
Für eine Erstbestellung hätte ich gerne den Bedarf gewusst.
Wer interesse hat, bitte eine Mail schicken.
Wigbert
Hi,
anbei mal die Platinen.
Es wird sicher jeder verstehen, das ich die Position S-Ram+ SMD + Spule
nur im Zusammenhang mit der GLCD Platine abgeben kann.
Bestücken:
Als erstes den S-Ram, dann die SMD-Bauteile, dann den Rest.
Sämtliche ICs sind in der gleichen Richtung ausgerichtet.
Wird der V-Regler nicht verwendet, die Anschlussbuchse rechts
neben den V-Reg. Platz einlöten.
Man kommt mit 8mm Abstandshülsen zw. dem NANYA-Adapter aus, wenn
man Buchsenleiste +Stiftleiste (2,54mm) verwendet.
Sinn des Adapters ist die Benutzung anderer controllerlosen GLCD's.
Die Platine ist grosszügig aufgebaut, wobei die senkrechten
Befestigungslöcher an das NANYA-Display angeglichen sind.
Eine Rechnung mit ausgewiesener MwSt gibts dazu.
Wigbert
Hallo Sebastian, hallo Helfender,
Nach längerer Pause bin ich wieder dran.
Vorab herzlichen Dank für eure Kommentare.
@ Sebastian
>>Ist das Bild statisch, oder läuft das durch?
das Bild sieht zuerst statisch aus, wird dann aber auf der gesamten
Fläche sehr unruhig und läuft -so weit ich es erkennen kann- durch.
>>Und welches LCD verwendest du? Datenblatt?
das übliche NANJA s/w Display.
>>Wie hast du es angeschlossen?
das Flachbandkabel am Ende aufgedröselt und in eine Steckerleiste
gelötet.
In der Zwischenzeit habe ich das LCD in einer anderen Schaltung getestet
und es funktioniert einwandfrei.
>>Wie schnell taktet dein AVR eigentlich?
16MHz
@ Helfender
LA besitze ich nicht, daher kein direkter Vergleich möglich.
LP Frequenz ca. 24,4 kHz, das sind genau deine 41µs.
FRAME Frequenz ca 100 Hz.
PCLK zeigt Blocks von ca. 80 Takten und danach eine Pause. Die Takte
haben allerdings nach oben und unten ziemliche Spitzen.
Aus den Datensignalen kann ich nichts Eindeutiges ableiten.
Gruß
Bruno
Hallo Bruno,
ich habe mal kurz dein asm Programm geflasht.
Der Frameimpuls kommt wahrscheinlich exakt am LCD an, da keine Bauteile
dazwischen sind. Also vermute ich, dass es an der Datenausgabe liegt.
So wie es aussieht, kommen deine Daten zu spät. Aber gemessen am
Frameimpuls immer an der gleichen Stelle.
Wird dir nicht viel helfen, aber ich habe auch keine Idee mehr.
Hast du vielleicht irgendwo nen Kurzschluss in deinen Adressleitungen
zum RAM? Mir kommt das komisch vor, dass auf dem ganzen LCD immer die
gleichen 12 (oder so) zeilen angezeigt werden. Und das einzige was mir
dazu einfällt ist, dass irgendwas an deinen Adressleitungen nicht passt.
Hallo Helfender, hallo Sebastian
daß bei mir der senkrechte Balken rechts und das Rechteck bei dir links
ist, hat nichts zu sagen. Ich hatte das LCD anfangs nur verkehrt rum
aufgestellt.
Eine letzte Frage an Helfender zur Vollständigkeit:
Wie hast du die Fuses gesetzt?
Ansonsten nochmals herzlichen Dank an euch beide für die Geduld. Sollte
ich den Fehler noch finden, lasse ich es euch wissen.
Hallo Sebastian, hallo Helfender,
ich hab's geschafft!!!
Die Lösung war natürlich ganz simpel. Ich habe versuchsweise einmal das
WAITSTATE Bit gesetzt, obwohl ich eigentlich schnelle RAMs habe(15ns
bzw. 25ns). Das Problem ist wahrscheinlich mein großzügiger
Schaltungsaufbau auf einer Lochrasterplatine.
Gruß
Bruno
Mit Waitstate hats nicht funktioniert, ohne funktionierts? Dann wars
aber nicht das Layout. Da wärs ehr andersrum gelaufen ;)
Wahrscheinlicher ist, dass die Framerate zu hoch war. Mit Waitstate
braucht der Interrupt deutlich länger. Du hast die 8-Graustufen-version
in der eh schon mehr Zeit im Interrupt verbracht wird. Mit Waitstate
hats dann halt nicht mehr gereicht.
Aber glückwunsch dass es jetzt läuft.
Sebastian
Dein Kommentar hat mich etwas verwirrt.
Wenn ich in param.h die (normalerweise nicht gewählte) Option Waitstate
aktiviere, dann nehme ich in lcd.c doch die Version mit (1<<SRW10 im
MCUCR). Damit schalte ich den Waitstate doch ein und nicht aus! Oder
habe ich da etwas falsch verstanden?
Bruno
Hallo Bruno,
>>Kann ich mit HTerm die Befehle und Daten in einem Textfile übertragen>>und wenn ja, wie?
Textfile geht nicht. Mit einem Hex Editor ein Binärfile erstellen.
In HTerm SendFile anklicken und den Binärfile auswählen.
Alternativ kannst du auch Befehle mit ASend verschicken. (dazu Bin
markieren)
Ich bin es schon wieder! Ich habe mich zu früh gefreut!
Wenn ich Bilder übertrage, dann werden diese immer irgendwie geteilt,
u.z. unabhängig davon ob ich mit HTerm oder mit einem Controller
übertrage. Es ist auch egal, ob ich den Code von Benedikt mit 4
Graustufen, oder den erweiterten von Sebastian nehme. Der Unterschied
scheint nur zu sein, daß im Benedikt Code das Bild in der Mitte geteilt
ist (siehe Anlage) und beim Sebastian Code links ca. 2/3 des Bildes
erscheinen. Das ist aber mit Vorsicht zu betrachten, da sich das hin und
wieder auch ändert.
Hat jemand eine Idee?
Bruno
Hallo Helfender,
dein Bild hat mir zwar nichts Neues gebracht, aber trotzdem bin ich
dadurch auf die richtige Spur gekommen. Ich hatte bei meinen Bildern
immer einen Clear-Befehl (12) an den Anfang gesetzt und das verträgt der
Code offensichtlich nicht.
Dank und Gruß
Bruno
Hallo Helfender,
ich brauche nochmals Rat. Dein Beispiel war zwar nur mit 2 Farben, ich
gehe aber davon aus, daß du dich auch mit der 4 und 8 Graustufen Version
beschäftigt hast.
Ich habe Probleme mit dem xs Wert. Wenn ich ein Bild 320x240 übertrage,
dann
habe ich im s/w Modus 320/8=40.
Im 4Grau Modus sind das dann 2*320/8, also 80 und im 8Grau Modus müßten
es doch 3*320/8, also 120 sein. Das ergäbe 120*240=28800 Bytes für das
gesamte Bild. Mein Problem ist, daß ich bei der Erzeugung eines 8Grau
Bildes mit dem GrafikConverter hier aus dem Forum aber 38399 Bytes
bekomme. Rein rechnerisch müßte ich dann ja 38399/240 ~ 160 Bytes mit xs
übertragen. Ganz egal wie ich es aber anstelle, es kommt nur Müll.
Liegt es nun an der Einstellung des GrafikConverters oder an meiner
Berechnung des xs.
Die 4Grau funktioniert übrigends problemlos.
Bruno
Hallo Bruno,
ich dir mal etwas im Anhang,
da sind die Bilddaten320x240 in 8Graustufen und eine Schleife die die
Bilddaten ausgibt.
kannst ja mal probieren obs klappt,
wäre gut wenn du dich dann nochmal mit nen foto meldest
mfg
Hallo Bruno,
na klar habe ich auch 8 Graustufen probiert.
>>Im 4Grau Modus sind das dann 2*320/8, also 80 und im 8Grau Modus müßten>>es doch 3*320/8, also 120 sein. Das ergäbe 120*240=28800 Bytes für das>>gesamte Bild.
Das ist richtig.
Header = 16,170,0,0,40,240,2 -> für 3bpp 8 Graustufen
1 -> für 2bpp 4 Graustufen
0 -> für 1bpp 2 Graustufen
Also liegt es am GrafikConverter, den du benutzt.
Dazu kann ich aber nichts sagen, da ich ein anderes Programm benutzt
habe.
Welches kann ich nicht mehr sagen. Irgendeinen Grafik LCD Konverter.
Hallo gasst und Helfender,
ich danke für die prompte Antwort.
Der Rambo ist angekommen (siehe Anlage). Ich habe ihn allerdings mit
HTerm übertragen.
Wie ich aus euren Antworten entnehme, sind die 3bpp nur bei der Anzahl
der Bytes zu berücksichtigen, Ich war bisher davon ausgegangen, daß im
Befehl das xs auf 40, 80 bzw. 120 gesetzt werden muß. Da es bei mir aber
mit der 4Grau trotzdem geklappt hat, muß mein GrafikConverter die Daten
anders aufbereiten.
Könnt ihr mir euren Converter verraten?
Bruno
Ich habe noch etwas rumgespielt und dabei folgendes festgestellt:
Wenn ich 4grau haben will, muß ich den xs Wert tatsächlich verdoppeln.
Nur die Anzahl Bytes des Bildes funktioniert nicht. Man sieht dann immer
nur das halbe Bild durchlaufen. Wenn ich 8grau haben will, darf ich den
xs Wert hingegen nicht erhöhen.
Jetzt würde mich natürlich schon interessieren, ob es am GrafikConverter
liegt, oder am Code.
Angenommen das Bild ist 320x240 Pixel.
Es werden horizontal jeweils 8 Bit (Pixel) übertragen. (xs = 320 / 8)
Bei 2 Grauwerten reichen diese 8 Bit (jeweils 0 oder 1).
Also xs=40, ys=240, 1bpp = 9600 Byte.
Bei 4 Grauwerten reichen diese 8 Bit nicht mehr. Also braucht man 2bpp.
Also xs=40, ys=240, 2bpp = 19200 Byte.
Bei 8 Grauwerten braucht man 3bpp.
Also xs=40, ys=240, 3bpp = 28800 Byte.
Hallo Helfender,
genau so hatte ich dich verstanden! Aber das scheint nicht zu stimmen.
Für die 2grau und 8grau passt es, aber für die 4grau muß ich xs=80,
ys=240 eingeben. Alles andere funktioniert nicht. Offensichtlich war das
von Benedikt auch so vorgesehen, da er am 1.6.2009 die anliegende Datei
ins Forum gestellt hat. Die Befehlszeile ist darin 0x10, 0xAA, 0x00,
0x00, 0x3C, 0xF0, 0x01, d.h. er hat für ein 30 Byte breites Bild xs=60
eingegeben.
Hallo Bruno,
>>Die Befehlszeile ist darin 0x10, 0xAA, 0x00,>>0x00, 0x3C, 0xF0, 0x01, d.h. er hat für ein 30 Byte breites Bild xs=60>>eingegeben.
So genau habe ich mir das damals nicht angesehen.
Wenn ich das richtig verstanden habe, gibt der letzte Wert die Bit pro
Pixel an. Dann wäre das obige Beispiel eigendlich 1bpp ???
xs=60, ys=240, 1bpp = 14400 Byte
Ist im Endeffekt das gleiche wie ich dachte.
(240 / 8) xs=30, ys=240, 2bpp = 14400 Byte
Aber warum xs 60 ist kann ich dir auch nicht beantworten.
Ist mir auch nie aufgefallen, da ich mit 4 Graustufen nie probiert habe.
> Ich hatte bei meinen Bildern> immer einen Clear-Befehl (12) an den Anfang gesetzt und das verträgt der> Code offensichtlich nicht.
Der sollte eigentlich keine Probleme machen. Wenn du allerding den
Busy-pin nicht abfragst kann das leicht probleme machen. Clear brauch
relativ lang zum ausführen. Wenn du jetzt blind daten sendest wird
erstmal der Puffer vollgeschrieben. Danach gehn die Daten verloren bis
Clear fertig ist. Könnte durchaus sein, dass das in etwas eine halbe
Bildzeile ist. Als Resultat ist dann das gesamte Bild ein Stück nach
links verschoben und das was links rausgeschoben wurde wird rechts
angezeigt.
Zu deinem xs-problem kann ich dir nicht wirklich helfen. Was ich nach
kurzem Überfliegen aus dem code gelesen habe ist, dass für 1bbp und 3bbp
der maximalwert für xs 40 ist und für 2bbp 80. Sicher bin ich mir aber
auch nicht. Erscheint irgendwie unlogisch. Ich weiß nur noch, dass mir
der xs-wert auch ständig probleme gemacht hat als ich die 3ppb
programmiert habe.
Sebastian
Herzlichen Dank für eure Antworten!
Ich habe das mit dem Busy Pin zwar schon gelesen, aber ich weiß nicht
wie ich das realisieren kann. Eigentlich wäre es doch sinnvoll die
Abfrage in den Übertragungscode einzubauen (bei mir scheitert das aber
noch immer am C++), oder welche Möglichkeiten gibt es sonst noch? In der
Zwischenzeit hatte ich selbst festgestellt, daß es funktioniert, wenn
ich nach dem "Clear" ca 500 Leerbytes einfüge.
Das mit dem xs ist kein Problem mehr, da ich ja nun weiß was ich tun
muß.
Gruß Bruno
Nachtrag:
Beim Übertragungscode meinte ich eigentlich Empfängercode. Wenn ich die
Daten per µC sende läßt es sich sicher relativ einfach realisieren, da
ich aber immer mit HTerm sprich vom PC sende, kenne ich keine Lösung.
Bruno
Herzlichen Dank für den Tip!
HTerm hat ja tatsächlich ein CTS Kästchen zum Ankreuzen (Flow control),
nur leider scheint es nicht zu funktionieren. Bei mir bleibt die
Übertragung jedenfalls schon am Anfang hängen.
Trotzdem habe ich aber kein wirkliches Problem, da es ja einige
Alternativen gibt.
Bruno
Du musst dann natürlich auch Physikalisch CTS der RS232 und Busy vom
Controller verbinden. Ich weiß auch nicht, ob die beiden Signale von der
Polarität zusammenpassen. Und bevor du sie einfach zusammenlötest denk
auch mal über die Pegel nach, die drauf liegen.
http://de.wikipedia.org/wiki/EIA-232
Sebastian
Da du mir dieses Thema schon so nahe bringst, bleibt mir ja gar nichts
anderes übrig, als mich etwas näher damit zu befassen.
Ich habe also angefangen mich mit der RS232 und dem busy pin zu
beschäftigen und stoße natürlich wieder auf Fragen.
Als erstes habe ich die Spannung am PIN D2 gemessen und festgestellt,
daß er auf high steht. Nach der Erklärung von Benedikt, müßte ihn aber
doch das Programm hochziehen, wenn der Puffer zu 3/4 gefüllt ist.
Schaue ich nun in den Ursprungscode von Benedikt, dann hat er in der
"int main" PORTD=3 und DDRD=254 gesetzt. Danach wäre der Pin D2 ein
Ausgang mit 0 Level. Dann dürfte er also nicht auf high stehen.
Schaue ich aber nun in die von Benedikt modifizierte, oder auch in deine
8grau Version, dann wird PORTD=7 gesetzt. Damit ist D2 immer high. Wie
paßt das zusammen???
Bruno
Mit HTerm geht es mir ähnlich.
Laut Beschreibung sollte die Übertragung gestoppt werden, wenn CTS high
geht.
Die Spannung am CTS Pin ist auch normal 0. Nur funktioniert dann die
Übertragung nicht. Wenn ich CTS high setze wird zwar übertragen, aber am
Display kommt nur Datenmüll an?????
Hast du mit HTerm Erfahrung?
Bruno
Ne, leider überhaupt keine Erfahrung mit HTerm. Und auch allgmein so gut
wie nichts an der PC-RS232 gemacht. Kann also kaum helfen. Bzw. halt nur
dokumentattion lesen, aber das kannst du ja auch selbst machen. Der
Busy-pin des Displaycontrollers verhält sich bei mir so wies in dem
beigelegten pdf steht (also das aus der .zip). Gib nicht zu viel auf den
wert, auf den Busy initialisiert wird. Es zählt nur, wie das ganze in
der UART-lib behandelt wird.
Pass bei RS232 mit high/low auf. Ich hab irgendwas im Kopf, dass da
logisch 1 = physikalisch low ist. Aber sicher bin ich mir da auch nicht.
Hallo,
hat jemand schon mal bei einem Mega162 mehr als einen Zeichensatz
eingebaut ? Der Speicher sollte das ja zulassen, oder ? Da die beiden ja
Pin-kompatibel sind, könnte man ja den 8515 schön damit ersetzen.
Das wäre für mich ne ziemliche Erleichterung, da ich (noch) nicht so
viel Erfahrung mit C habe. Ich programmiere zwar schon ein paar Jahre,
aber meist eben mit Bascom oder Delphi und nicht in C. (Ich arbeite
grade dran :-) )
Gruß
Markus
Hi !
hat überhaupt schon jemand den ATMega 162 bei dem Projekt eingesetzt ?
Der 8515 ist im Moment leider nicht zu bekommen und ich müsste eins
meiner Boards ersetzen ..
Gruß Markus
Hi,
hast du noch Platinen übrig? Würde evtl. was abkaufen. Ich habe noch ein
320x240 Display von Nanya rumfliegen und würde gerne die Schaltung
aufbauen.
Gruß
Alex
Hallo,
ich bin neu bei diesem Projekt. Ich habe fast den ganzen Tag damit
verbracht, den Thread mit den vielen Links zu lesen und halbwegs zu
verstehen. Ein wirklich tolles Projekt.
Nun würde ich ebenfalls gerne loslegen - doch Pollin hat all die schönen
Displays mit CCFL Hintergrundbeleuchtung bis auf eine Ausnahme (Best.Nr.
120 486) ausverkauft. Und dummerweise fehlt hier das Datenblatt.
Wer von euch hat besagtes Display vielleicht schon einmal eingesetzt
oder kennt die Anschlussbelegung ?
Oder eine andere Bezugsquelle als Pollin für solche Displays mit CCFL?
Vielen Dank schon mal!
Gruß
Josef
Hi,
die GLCD_32K Platinen und auch die NANYA Adapterplatinen
sind jetzt vorrätig. Vielleicht gerade richtig zur kalten
Jahreszeit. Ich hab mal schnell von der Serie eine aufgebaut,
lief promt auf Anhieb. Einige Verbestellungen schreibe ich noch
mal an, ansonsten bitte eine Mail.
Wigbert
Hi @ all,
ich (bzw. mein Vater und ich) haben uns von Wigbert 2 Platinen besorgt.
Meine funktioniert auch schon wunderbar (mein Vater ist noch am
Bestücken), VIELEN DANK AN WIGBERT UND BENEDIKT!
Aber ich komme mit der Grafik konvertierung und dem Bild Befehl nicht
klar.
Wie das mit 1bpp läuft ist mir in der Theorie klar. Aber wie läuft das
mit 2bpp (4 Graustufen) und 3bpp (8 Graustufen)?
Ich verstehe die (leider ziemlich knappe) Erklärung in dem .pdf nicht so
wirklich.
Werden bei 2bpp immer 2 aufeinanderfolgende Bits zusammengefasst und
stehen dann sozusagen 4 Pixel in einem Byte? Wie soll des bei 3bpp
funktionieren? stehen dann 2,67 Pixel in einem Byte???????????
Wie konvertiere ich das Bild im Anhang (ist momentan mit 8bpp Farbtiefe
aufgelöst) nach 2 oder 3bpp? 1bpp müsste ja Schwarz Weiß entsprechen
(macht ja Paint).
Wie bekomme ich dann die Tabelle aus der Grafikdatei?
Ich selbt benutze Bascom AVR zum Programmieren.
Ich hoffe es kann mir jemand weiterhelfen, wie ich das (oder ein
beliebiges Bild) auf das Display bringe.
Mfg Bimbo385
Total Geil!
Alles funktioniert wie es soll.
Danke dir Sebastian! und euch Allen!!!
@ Wigbert:
Ich möchte allen vorsichtshalber mitteilen, dass es bei FFC-Buchsen
welche gibt, bei denen die Kontakte des Folienleiter zur Platine zeigen
müssen (beim Reinstecken) (solche hat Wigbert) und, dass es FFC-Buchsen
gibt, bei denen die Kontakte des Folienleiters nach oben (also von der
Platine weg)
zeigen müssen (solche habe nämlich ich).
Somit hängt es von der verwendeten FFC-Buchse ab, wierum die kleine
NANYA Adapterplatine (von Wigbert) auf die Hauptplatine von Wigbert
gelötet werden muss.
Bie mir muss man, im Gegensatz zu Wigberts Fotos, die FFC-Buchse von
oben sehen können.
Auf jeden Fall muss sich am Ende Die blaue Beschriftung des
Folienleiters auf der Bestückungsseite der Hauptplatine befinden.
Außerdem möchte ich die Frage nach dem Inverter für die
Hintergrundbeleuchtung nochmal aufwerfen. Ich habe noch so einen
Schwarzen Kasten für 2x 30cm CCFL's (Casemodding). Kann ich den einfach
verwenden?
Hat das schon mal jemand gemacht?
Mfg Bimbo385
PS: Die HEX-Datei im Anhang kann man mit HTerm senden und enthält den
Befehl für die Bildausgabe!
@Bimbo 385 (bimbo385)
Danke für den Hinweis. Auf der Platine ist ein Pin, auf der die
Adapterplatine aufgesteckt wird, sicherheitshalber mit 1
gekennzeichnet.
Also schön aufpassen! Ich erweitere mal meinen beigelegten
Merkzettel, wenn meine FFC Buchsen nicht verwendet werden.
Die Adapterplatinen lassen sich ja problemlos drehen.
Wigbert
hallo,
ich habe mir den lcd Controller auch aufgebaut läuft supi,
ich habe mir ein bild erstellt(184x74Pixel) in 8 Graustufen mit den
GrafikConverter weiter oben,diese Bilddaten sende ich von einem extra
Controller zum display das funktioniert herrvoragend.
nun meine frage , als Controller des Lcds verwende ich einen
atmega162,ich wollte gern diese Bilddaten im flash speichern und dann am
lcd ausgeben im 1bpp funktionierts aber im 3bpp läufts nicht.
kann mir denn da jemand weiter helfen
mfg
Hallo zusammen!
Habe gerade ein Wintek H3224V von Pollin an den Controller, basierend
auf Wigbert's Platine, angeschlossen und genieße meine Triumpf: Es
erscheint das Testbild und es nimmt brav Befehle entgegen. Hier schonmal
ein riesen Dankeschön an Euch alle!
Nur läuft es noch nicht ganz rund:
Ich habe flackernde senkrechte Streifen die wohl immer dort entstehen,
wo etwas angezeigt wird. Ein Rechteck mitten im Bild z.B. wird somit ab
und zu zu einem kompletten senkrechten Streifen von oben bis unten. Hat
jemand eine Idee?
Zweites Problem wäre der Anschluss "M" des Displays, wo gehört der denn
hin? auf wigbert's Schaltplan ist ein Pin dafür vorgesehen, auf der
Platine finde ich aber irgendwie nichts. An diesen Pin habe ich gerade
einfach nur ein Kabel hinkrokodilt und lasse es in der Luft hängen. Ohne
dieses verblasst das Bild binnen einiger Sekunden.
MfG,
Der fast ganz Glückliche
Schau mal links von IC4 dort ist M als Lötpad herausgeführt.
Rechts von R7 auf meiner Platine. Ist auf der Top Platinenansicht
mit M bezeichnet
Wigbert
Oh Gott bin ich blind... Bin eh schon Kurzsichtig und seh sowas net.
Vielen Dank Wigbert! Funktioniert jetz alles wunderbar. Aber um etwas
für den Lerneffekt zu tun: Für was ist das Signal gut?
@neuer:
Ich hab mir deinen Code jetzt nicht genau angeschaut, aber dein Problem
könnte schlicht darin liegen, dass du die Falsche Funktion aufrufst.
Für 8-Graustufen-bilder darfst du nicht mit lcd_writebyte schreiben
sondern musst lcd_writebyteg8 nehmen. Beachte, dass lcd_writebyteg8 mehr
Parameter verlangt.
Wenn du Die 8-Grastufen-daten mit der lcd_writebyte schreibst kommt
jedenfalls nur müll im Speicher an ;)
Sebastian
hallo Sebastian
ich schreibe ja mit der Funktion lcd_writebyteg8 es wird ja auch von den
abmessungen richtig dargestellt also breite und höhe.
nur siehts halt verschwommen aus.in den 4Graustufen passt alles.
vielleicht wäre es möglich mir da ein bischen weiterzuhelfen
mfg
Nachdem ich nur mutmaßen kann wo der Fehler ursprünglich ist erklär ichs
mal bissl ausführlicher - sollst ja auch wissen, was du da tust ;)
Es gibt prinzipiell mal zwei Stellen, wo man die Graustufenzahl
einstellen kann. Das erste ist bei den Parametern - hier stellt man ein,
mit wie vielen Graustufen der Controller arbeitet. Dabei ändert sich
primär die Organisation des RAMs. Stellt man hier 2 ein kann der
Controller einfach nichts mit 4 oder 8 Graustufen anfangen. Umgekehrt
kann aber ein 8-Graustufen-build natürlich auch 2 Graustufen anzeigen.
Die andere Ecke ist dann die Datenverarbeitung selbst. Also das, wo man
am UART-interface zu den Bilddaten noch den Modus mitschicken muss. Über
den Modus wählt man dann aus, ob die lcd_writebyte, die lcd_writebyteg
oder die lcd_writebyteg8 verwendet werden soll. Die Routinen erwarten
dann aber auch entsprechend Daten mit 2,4 bzw 8 Graustufen. Die Art, wie
die Daten im RAM abgelegt werden regeln die Routinen dann intern. Du
kannst also per Config auf 8 Graustufen flashen und mit der
lcd_writebyteg ein 4-Graustufen-bild zeichnen.
Bei dir liegt der Fehler genau bei der Verwendung von lcd_writebyte*. Du
musst -unabhängig davon was in den Parametern steht- für
2-Graustufenbilder die lcd_writebyte, für 4-Graustufen die
lcd_writebyteg und für 8-Graustufen die lcd_writebyteg8 nehmen. Die
lcd_writebyteg8 erwartet dann aber auch 3 aufeinanderfolgende Datenbytes
(und natürlich auch eine Vorlage mit 8 Graustufen) und nicht wie bei dir
dreimal das selbe Byte.
Sebastian
hallo Sebastian
erstmal vielen dank für deine Antwort,
>> (und natürlich auch eine Vorlage mit 8 Graustufen)
<Das bild mit 8Graustufen liegt im Flash vom Controller
> und nicht wie bei dir> dreimal das selbe Byte.> lcd_writebyteg8 erwartet dann aber auch 3 aufeinanderfolgende Datenbytes
<ja daran harperts bei mir weil ich nun nicht so viel Ahnung von C
habe,um mir eine Routine zu schreiben die die richtigen Bytes ausliest.
deshalb meine frage,ob mir da jemand weiterhelfen könnte.
mfg
Muss es zwingend möglich sein, beliebige Bildbreiten darzustellen (wenn
ich deinen Algorithmus richtig interpretiere versuchst du das ja)?
Dann müsstest du nämlich an einem Rand Füll-pixel einfügen um in der
Breite auf vielfache von 8 pixeln zu kommen. Das geht aber leichter,
wenn du die Füllpixel gleich im Bild vorsiehst.
Wenn du mit der beschränkung leben kannst, dass die Bildbreite vielfache
Werte von 8 hat, dann kannst du quasi den Algorithmus aus der main.c
nehmen und einfach uart_getchar() durch pgm_read_byte(...) ersetzen. Das
sollte eigentlich recht problemlos laufen.
Wenn du wirklich auf beliebige Breite ohne Füllpixel bestehst muss ich
dich leider allein lassen. Das erfordert tiefere Eingriffe in die
lcd_writebyteg8 für dich ich leider keine Zeit habe.
Sebastian
@Glücklicher Displaybesitzer:
Nochmal für den Lerneffekt: Das Signal M sorgt für die nötige,
gleichspannungsfreie Ansteuerung des Displays, indem es in regelmäßigen
Abständen invertiert wird. Es gibt Displays, die dieses Signal intern
erzeugen und nicht herausführen, anderen muß man es liefern.
Das Display lief jetzt so schön, nun zeigt es nur noch senkrechte
Streifen mit verschiedenen Stärken an. Auch musste ich feststellen, dass
der RAM warm wird. Ich habe schon sämtliche 74hctxx und den 8515
gewechselt, keine verbesserung. Da dürfte wohl der RAM gehimmelt sein,
oder?
Hallo Leute
Wer könnte mir denn den Code soweit minimieren das ich den
Displaycontroller nur noch im s/w Modus betreiben kann ohne jeglichen
Schnick Schnack???
Ich möchte die Daten auch am liebsten parallel (8bit) in den Controller
schaufeln um so schnell wie möglich ein Bild aufzubauen.
Ich sende momentan nur reine Bilddaten mit 666666 baud. Schriftarten
werden bei mir in einem anderen Controller erzeugt.
Momentan hängt es bei mir an der Geschwindigkeit der Bildübertragung.
Die scheint hier einige ms in Anspruch zu nehmen. Ich müsste das Bild
(320x240) allerdings in weniger als 0,004 s aufgebaut haben.
Ist das Möglich?
Eigentlich bräuchte ich den Grafik-Controller nur als Bildspeicher der
autark das Timing des Displays übernimmt..
Ich hab nicht soviel (sehr wenig Programiererfahrung) in "C". Ich hoffe,
mir kann jenand helfen.
Grüße
Steffen
Hallo
@Benedikt
Vieleicht kann mir aber auch der Benedikt nochmal kurz beschreiben wie
der Ablauf/Timing vom AVR zum Display abläuft. Dann versuch ich es mal
selber in ASM zu programmieren.
Grüße
Steffen
Die minimal-version kann man sich sehr leicht selbst zusammenstellen
indem man in den parametern nur die s/w-version auswählt. Die ganzen
grafikfunktionen verlangsamen das programm wirklich nur unwesentlich.
Wenn man Text sendet ists vollkommen irrelevant. Und bei den
Grafikfunktionen ist die Render-Zeit der Grafik deutlich relevanter als
das, was man sparen würde, wenn man ein Paar der Funktionen
rausschmeißt.
Über die 4ms solltest du nochmal gut nachdenken. Wie groß ist denn die
Reaktionszeit deines Panels? Die NANYA-displays, die hier massenhaft
verwendet werden haben, glaub ich, gute 100ms. In dem Fall wären die 4ms
vollkommen lächerlich.
Zumal das Display -wenn ich mich recht erinner- auch im sw-Modus mit
wenigstens 70Hz betrieben wird. Du hast also eh schon bis zu 14ms Latenz
bis die neuen daten überhaupt angezeigt werden.
Du kannst auch überlegen, das Bild erst zu puffern und dann den
Bildbereich umzuschalten. In der SW-Version kann man ja bis zu 3
Vollbilder im Speicher vorhalten. Die Latenz wird dadurch zwar nicht
kleiner, aber man muss dem Bild nicht beim aufbau zuschaun.
Wenn das alles nichts hilf: Ich hab daheim ne Version, die Bilder mit
2MBaud entgegen nimmt, ohne den Master dabei zu bremsen. In dem Fall ist
dann sowohl die CPU als die UART voll ausgelastet (= ca.7fps) - ich weiß
nicht, wie noch mehr gehn soll. Ist aber nur für 3bpp-bilder
implementiert und nicht gut dokumentiert. Wenn du willst, kann ich das
mal hier anhängen, aber anpassen auf SW kann ichs nicht: Leider zu wenig
Zeit und gerade auch keine Hardware hier ums zu testen.
Parallele Datenübertragung hilft nur, wenn die CPU momentan unterfordert
ist. Das ist sie aber -soweit ich mich erinner- in der Originalversion
bei 666kbaud nicht. Nachteil an paralleler Datenübertragung ist, dass
man entweder Bandbreite verliert, weil der Hardware-Buffer der UART
während dem Anzeige-Interrupt nicht mehr genutz werden kann, oder einen
Handshake braucht, den man in Software bedienen muss => CPU-zeit.
=> Parallele Datenübertragung bringt wenn überhaupt nur was, wenn man
den Anzeigeinterrupt kräftig umbaut und wirklich nur SW anzeigen will.
Aber auch da wär ich mir nicht sicher. Für 3bpp-bilder dürfte nicht mehr
als ca. 7fps machbar sein.
Die Ansteuerung des Displays selbst kann man eigentlich ganz gut aus dem
Datenblatte des Displays (Timingdiagramm) und der Interrupt-Routine des
Controllers verstehen. Nachdem aber eh nur die High-level-Routinen in C
geschrieben ist (Der Interrupt ist also in ASM) könntest du auch einfach
Benedikts Interrupt übernehemen und nur den rest neu implementieren -
wenn du das denn unbedingt willst.
Viele Grüße,
Sebastian
Hallo Sebastian
>Über die 4ms solltest du nochmal gut nachdenken. Wie groß ist denn die>Reaktionszeit deines Panels? Die NANYA-displays, die hier massenhaft>verwendet werden haben, glaub ich, gute 100ms. In dem Fall wären die 4ms>vollkommen lächerlich.
Ich hab gestern nochmal drüber nachgedacht und du hast völlig Recht! Das
ist nur Wunschdenken. Außerdem, falls irgendein Display jemals so
schnell sein sollte, könnte das Menschliche Auge es sowiso nicht einzeln
folgen..
>Wenn das alles nichts hilf: Ich hab daheim ne Version, die Bilder mit>2MBaud entgegen nimmt, ohne den Master dabei zu bremsen. In dem Fall ist>dann sowohl die CPU als die UART voll ausgelastet (= ca.7fps) - ich weiß>nicht, wie noch mehr gehn soll.
Die Version hattest du mir schon mal vorgeschlagen. Damals wusste ich
noch nicht so genau wo mein Vorhaben mich hin führt. Wenn ich mit dem
Display 10fps erreiche wär ich jedoch trotzdem froh. Soll auch alles NUR
S/W werden. Und ich nutze wirklich nur Bilddaten. Ich hab sozusagen das
komplette Bild schon im anderen Controller gespeichert und muss es nur
noch so schnell wie möglich zum Display-Controller schreiben.
>Nachteil an paralleler Datenübertragung ist, dass>man entweder Bandbreite verliert, weil der Hardware-Buffer der UART>während dem Anzeige-Interrupt nicht mehr genutz werden kann, oder einen>Handshake braucht, den man in Software bedienen muss => CPU-zeit.
Also wird hier der Hardwarebuffer der UART genutzt um mehr Zeit für den
Anzeige-Interrupt zu haben? Ist denn das Timing zum Display so knapp
bemessen?
>Du kannst auch überlegen, das Bild erst zu puffern und dann den>Bildbereich umzuschalten. In der SW-Version kann man ja bis zu 3>Vollbilder im Speicher vorhalten. Die Latenz wird dadurch zwar nicht>kleiner, aber man muss dem Bild nicht beim aufbau zuschaun.
An genau so etwas hab ich auch gedacht. Zwei Bildspeicher die man nach
jedem neu empfangenen Bild umschaltet. Soll heißen:
>Bildbereich1: Wird verwendet zum Refresh des Displays durch den Controller>Bildbereich2: Wird verwendet zum Speichern der neuen Bilddaten
Wurden die neuen Bilddaten übermittelt dan wird umgeschaltet.
>Bildbereich2: Wird verwendet zum Refresh des Displays durch den Controller>Bildbereich1: Wird verwendet zum Speichern der neuen Bilddaten
Also immer schön im Wechsel.
Ist dies möglich? Ist da mein Ansatz so schon ganz gut?
>Die Ansteuerung des Displays selbst kann man eigentlich ganz gut aus dem>Datenblatte des Displays (Timingdiagramm) und der Interrupt-Routine des>Controllers verstehen. Nachdem aber eh nur die High-level-Routinen in C>geschrieben ist (Der Interrupt ist also in ASM) könntest du auch einfach>Benedikts Interrupt übernehemen und nur den rest neu implementieren ->wenn du das denn unbedingt willst.
Ich hab da schon mal durch den Code gesehen. Aber ich kam da wegen dem
UART nicht mehr weiter. Denn der ist in C geschrieben. Den UART-FIFO hab
ich da auch nicht mehr nachvollziehen können. Dann noch die ganzen
Auswahlmöglichkeiten.. Da ist man schnell am Ende wenn man nicht
wirklich C kann. Na dann werd ich mir am WE wohl mal den ASM Code
anschauen.
Danke aber trotzdem für deine Hinweise und Hilfe Sebastian.
Grüße
Steffen
> Wenn ich mit dem> Display 10fps erreiche wär ich jedoch trotzdem froh. Soll auch alles NUR> S/W werden.
Dann sollten mit 2 Mbaud 20,8fps möglich sein, wenn man den
Display-Interrupt aufteilt. In SW könnten dann mit parallelem Interface
sogar noch mehr gehen, aber das wird auf jeden fall aufwändiges gebastel
und du bräuchtest auch erstmal ein Display, das unter 50ms schaltzeit
hat.
> Also wird hier der Hardwarebuffer der UART genutzt um mehr Zeit für den> Anzeige-Interrupt zu haben? Ist denn das Timing zum Display so knapp> bemessen?
Ja genau. Während dem Displayinterrupt landen die UART-daten erstmal im
Hardwarepuffer. Der hat 2 oder 3 byte (weiß ich nicht mehr sicher). Ist
er voll muss der Interrupt fertig sein, sonst gehen daten verloren.
Darüber bestimmt sich auch die maximale Baudrate. Will man mehr Baudrate
muss der Interrupt kürzer werden.
> An genau so etwas hab ich auch gedacht. Zwei Bildspeicher die man nach> jedem neu empfangenen Bild umschaltet. Soll heißen:>>Bildbereich1: Wird verwendet zum Refresh des Displays durch den Controller>>Bildbereich2: Wird verwendet zum Speichern der neuen Bilddaten> Wurden die neuen Bilddaten übermittelt dan wird umgeschaltet.>>Bildbereich2: Wird verwendet zum Refresh des Displays durch den Controller>>Bildbereich1: Wird verwendet zum Speichern der neuen Bilddaten> Also immer schön im Wechsel.> Ist dies möglich? Ist da mein Ansatz so schon ganz gut?
Genau so wars gemeint. In der aktuellen Version gibts auch schon die
passenden befehle dafür. Man hat ein Virtuelles Bild das gut dreimal so
breit ist, wie das was angezeigt werden kann. Mit einem Befehl kann man
jetzt festlegen ab welcher Spalte angezeigt werden soll, mit einem
anderen ab welcher Spalte geschrieben werden soll.
> Ich hab da schon mal durch den Code gesehen. Aber ich kam da wegen dem> UART nicht mehr weiter. Denn der ist in C geschrieben. Den UART-FIFO hab> ich da auch nicht mehr nachvollziehen können. Dann noch die ganzen> Auswahlmöglichkeiten.. Da ist man schnell am Ende wenn man nicht> wirklich C kann. Na dann werd ich mir am WE wohl mal den ASM Code> anschauen.
Den UART-Code brauchst du nicht anschaun. Das ist eine fertige Library
(von Peter Fleury glaub ich) die Benedikt recht rabiat umgebaut hat. Für
so extremen Datendurchsatz (20fps SW) musst du den Software-FIFO sowieso
rausschmeißen. der braucht zu viel Rechenleistung. Sorge lieber dafür,
dass beim Bilder übertragen die Daten wenigstens so schnell verarbeitet
werden, wie sie über die UART kommen. Dann kann der Master einfach so
schnell senden wie's die Schnittstelle hergibt.
Wichtig ist aber, den Displayinterrupt zu verstehen und verstehen, wie
die Daten im Speicher hinterlegt sind.
Viele Grüße,
Sebastian
Hallo Sebastian
So, ich hab mich mal rangewagt und so ziemlich viel Code
rausgeschmissen. Die Übertragung bleibt seriell. Mit 1Mbaud funktioniert
das ganze noch. Mit 2Mbaud kommen nur noch wilde Streifen, sieht eher
aus wie rauschen.
Da ich ja sowieso nur reine Bilddaten zum DSP-Controller sende, hab ich
auch die ganzen anderen Commands rausgeschmissen.
Ich sende jetzt nur noch 0x16, 0xAA, Data_0, Data_1,..,Data_9599. Also
genau ein Bild der Größe 320x240 pixel.
In der asm routine wird FLM/Frame gesteuert. Der OCR1A (PD5) steuert
LP/Load und ich denke mal RD steuert XSCL/CP und den 4aus8 MUX und wird
aktiviert durch einen lesenden Zugriff auf den externen Speicher durch
ld Rd, X+.
Richtig so?
>>Was ich überhaupt nicht verstehe:
Wo wird CKDIS gesteuert? Hab ja die ganzen Routinen rausgeschmissen wo
dies passierte..
Hast du in deiner 2Mbaud Version den UART umgebaut?
Im Anhang mal meine extrem geschrumpfte Version. Aber sie funktioniert!
Grüße Steffen
Hallo zusammen,
nach längerer Suche nach einem ATMega8515-16PU habe ich noch eine Quelle
gefunden.
Bei http://www.kessler-electronic.de gibt es noch ein paar...
lg,
Loki
> So, ich hab mich mal rangewagt und so ziemlich viel Code> rausgeschmissen. Die Übertragung bleibt seriell. Mit 1Mbaud funktioniert> das ganze noch. Mit 2Mbaud kommen nur noch wilde Streifen, sieht eher> aus wie rauschen.
Wenn du mal die Takte des Displayinterrupt zählst und überlegst, wie
lang ein Byte mit UART braucht - dann noch den Hardwarepuffer bedenken -
dann sollte klar werden warum ;) Eventuell musst du noch die Latenz des
UART-interrupt bedenken.
Wenn du mehr willst als 1Mbaud wirst du den Displayinterrupt aufteilen
müssen. Aber wahrscheinlich nutzt du die 1Mbaud momentan noch nicht mal
voll. Der Software-FIFO braucht massig Rechenzeit und bremst die UART
aus.
An deiner Stelle würde ich den Datenempfang per Polling in der
ASM-Routine erledigen. Aus der brauchst du auch eigentlich garnicht mehr
rausspringen. Die kann man zur Main-Loop befördern. Muss aber nicht
sein. Auf die Weise solltest du dann auch Netto 1Mbaud/10fps schaffen.
Wenn du den Displayinterrupt noch halbierst sollten auch 2Mbaud/20fps
drin sein.
> In der asm routine wird FLM/Frame gesteuert. Der OCR1A (PD5) steuert> LP/Load und ich denke mal RD steuert XSCL/CP und den 4aus8 MUX und wird> aktiviert durch einen lesenden Zugriff auf den externen Speicher durch> ld Rd, X+.> Richtig so?
Sollte stimmen.
>>>Was ich überhaupt nicht verstehe:> Wo wird CKDIS gesteuert? Hab ja die ganzen Routinen rausgeschmissen wo> dies passierte..
Was ist CKDIS?
> Hast du in deiner 2Mbaud Version den UART umgebaut?
Ja, der Software-Fifo bremst enorm. Mit dem sind 2Mbaud Netto nicht
drin. Um 2Mbaud Brutto erstmal zu erreichen muss man aber den
Displayinterrupt verkürzen.
Viele Grüße,
Sebastian
Danke für deine Hilfe Sebastian
Doch da tun sich gleich wieder Fragen auf:
>Ja, der Software-Fifo bremst enorm. Mit dem sind 2Mbaud Netto nicht>drin.
Kannst du bitte mal deine 2Mbaud Version anhängen damit ich mal schauen
kann wie du das gelöst hast?
>Um 2Mbaud Brutto erstmal zu erreichen muss man aber den>Displayinterrupt verkürzen.
Welcher ist denn der Displayinterrupt?
1
.section.bss
2
XStart:.ds.b1
3
YCnt:.ds.b1
4
#define XSIZEV XVSIZESW
5
.section.text
6
.globalTIMER1_OVF_vect
7
TIMER1_OVF_vect:
8
pushr16
9
inr16,_SFR_IO_ADDR(SREG)
10
pushr16
11
pushXL
12
pushXH
13
pushr18
14
ldsXL,viewstart
15
ldsXH,YCnt// Zeilenadresse laden
16
incXH
17
cbi_SFR_IO_ADDR(PORTD),FLM
18
ldr16,X+// 320 bits ausgeben
19
ldr16,X+
20
ldr16,X+
21
ldr16,X+
22
ldr16,X+
23
...
Etwa der hier?
Was genau bedeutet diese Schreibweise hier?
1
.globalTIMER1_OVF_vect
>Was ist CKDIS?
Das hier:
1
// PortD
2
#define CKDIS 3 //?????
3
#define FLM 4
4
#define LP 5
5
#define WR 6
6
#define RD 7
7
8
// PortE
9
#define EnLCD 0
10
#define ALE 1
11
#define PWM1 2
>An deiner Stelle würde ich den Datenempfang per Polling in der>ASM-Routine erledigen.
Wenn die ASM-Routine die selbe ist wie die oben erwähnte mit .global
TIMER1_OVF_vect, dann wird die doch durch den Timer1 angesprungen,
oder??
Also immer nur in einer bestimmten Zeit! Ich konnt das nicht simulieren,
da der Simulator dort irgendwie überhaupt nicht reinspringen will. Hab
versucht mir dort in der Simulation einen Brakepoint zu setzen. Das ging
irgendwie nicht. Wie gesagt, zu "C" muss ich noch viel lernen..
Sonst hätt ich das alles schon komplett in ASM umgeschrieben. Kann man
meiner Meinung nach viel besser simulieren!
>Wenn du mal die Takte des Displayinterrupt zählst..
Das bekomm ich hin ;-)
>und überlegst, wie>lang ein Byte mit UART braucht - dann noch den Hardwarepuffer bedenken -
Ist in "C" geschrieben.. = Bahnhof ganz groß für mich :(
Aber den Empfang bekomm ich auch in ASM hin. Ich sehe nur nicht, dank
meiner magelnden C-Kentnisse, wo und wie der UART die ankommenden Daten
speichert. Da ist ja immer noch der Empfangs-FIFO drin. => kein Plan
hab!
Wäre echt nett mal deine Version kennen zu lernen.
Grüße Steffen
>>Um 2Mbaud Brutto erstmal zu erreichen muss man aber den>>Displayinterrupt verkürzen.> Welcher ist denn der Displayinterrupt?> Etwa der hier?
ja, genau, den meinte ich. Teile ihn in zwei teile und ruf ihn doppelt
so oft auf. Verkürzen (über Codeoptimierung) wirst du nicht viel können.
> Was genau bedeutet diese Schreibweise hier?>
1
>.globalTIMER1_OVF_vect
2
>
Ist die Sprungmarke für den Timer1 Overflow. Ist ne eigenheit von
C/ASM-Mischprojekten, dass man diese Formulierung auch noch hinschreiben
muss.
>>Was ist CKDIS?> Das hier:
Sicher bin ich mir nicht, aber glaube das ist, um Daten aus dem RAM
zurücklesen zu können, ohne, dass sie auf dem Display angezeigt werden.
Am anfang der main wird der Pin initialisiert. Solange du das drinlässt
kann dir der Pin eigentlich egal sein.
>>An deiner Stelle würde ich den Datenempfang per Polling in der>>ASM-Routine erledigen.> Wenn die ASM-Routine die selbe ist wie die oben erwähnte mit .global> TIMER1_OVF_vect, dann wird die doch durch den Timer1 angesprungen,> oder??
Nein, ich meinte die lcd_writebyte
> Ich sehe nur nicht, dank> meiner magelnden C-Kentnisse, wo und wie der UART die ankommenden Daten> speichert. Da ist ja immer noch der Empfangs-FIFO drin. => kein Plan> hab!
einfach die ganze library (alle dateien, die irgendwie UART heißen)
rausschmeißen. Und dann die uart_getchar() selbst implementieren (mit
polling) oder gleich den gesamten UART-empfang in den ASM-teil
verfrachten.
> Wäre echt nett mal deine Version kennen zu lernen.
Hab ich angehängt. Hoffe, du verstehst den code halbwegs. Ist für 8
Grastufen und es ist noch ne Bankumschaltung mit dabei - hab etwas mehr
RAM an meinem Controller.
Sebastian
Danke dir Sebastian für deine Hilfe. Den Code werde ich morgen mal
durchforsten.
>Verkürzen (über Codeoptimierung) wirst du nicht viel können.
Ja, da hast du recht.. Das ist schon sehr kutz und knackig gehalten.
>ich meinte die lcd_writebyte
Was genau wird da eigentlich gemacht? Ist die zum speichern der
empfangenen Daten da?
In der mainloop steht die ja drin. Aber WANN genau wird die aufgerufen?
..und noch was:
Wozu ist eigentlich der COMAND_TIMEOUT gut?
1
#define DOTIMEOUT() ctimeout=COMMAND_TIMEOUT; while (!uart_data()) if (!ctimeout) goto mainloop
Hallo an alle,
Betr.: Display Wintek WD-H3224V von Pollin
Nachdem ich nun das Display im Textmodus mit der Schaltung von Benedikt
zum laufen gebracht habe und den Touchscreen mit Bascom wunderbar
abfrage habe ich mich an die Grafikvariante von Benedikt getraut aber
hier gibt es nun bei mir ein Problem.
Wenn ich die Software von Benedikt in den Atmega 8515 lade erhalte ich
ein sauberes Bild aber keine Graustufen (siehe Foto), lade ich die
Software von Sebastian in den Atmega erhalte ich zwar 8 Graustufen aber
das Bild wird im 1. Drittel noch mal dargestellt (siehe Foto). Eine
Veränderung in den jeweiligen Programmen (Waistate, Framerate usw.)
bringt keine Verbesserung, kann mir jemand weiterhelfen ???
mfg
Walter10
Auszug aus dem Datenblatt:
Address Bus Breite 15Bit
Anzahl Bits per Word 8Bit
Anzahl I/O Lines 8Bit
Anzahl Ports 1
Anzahl Worte 32K
Data Rate Architecture SDR
Density 256KBit
Maximum Betriebsstorm 50mA
Maximum Betriebstemperatur 70°C
Maximum Random Access Time 70ns
Minimum Operating Temperatur 0°C
Mounting Durchsteckmontage
Pin Count 28
Product Height 4.95
Product Length 37.59
Product Width 13.97
Supplier Package MDIP
Timing Typ Asynchron
Typische Versorgungsspannung 5V
Ich würde jetzt mal einen Brücke zwischen irgendwelchen Adressleitungen
tippen.
Warum?:
Die s/w Variante braucht nicht soviel Speicher wie die 4Bit oder 8Bit
Variante. Deswegen scheint ja auch s/w zu funktionieren.
Gruß Steffen
Ja diesen Fehler hatte ich schon vorher, bei meinem Layout war eine
Verbindung zwischen einer Adressleitung und dem Masse-Polygon was dazu
geführt hat das die Anzeige unvollständig war also nur Bruchstücke
angezeigt wurden und versetzt dargestellt wurde. Daraufhin hab ich alle
Adressleitungen noch mal durch gemessen und überprüft, aber keinen
Fehler mehr gefunden. Ich werde mir wohl noch mal einen neuen Atmel und
Speicher besorgen vielleicht haben die etwas abbekommen, oder es gibt
jemanden der diesen Fehler auch schon mal hatte und eine Lösung kennt.
mfg
walter10
@Walter Hammes
ich lehne mich mal ganz weit aus dem Fenster und behaupte bit 6 oder 7
der Adressleitungen liegt fest auf einem Pegel :D
Ne, ernsthaft. Der Tip mit den Adressleitungen klingt plausibel, schau
die mal an.
Aber was anderes: Verwende doch bitte die Version, die Benedikt im
Beitrag "Re: Grafikfähiger LCD Controller für 320x240 LCD mit 4 Graustufen" gepostet hat. Das ist
die letzte offizielle version und enthält auch 8 Graustufen. Die älteren
Versionen von Benedikt haben teilweise auch noch ein paar Bugs, die da
nicht mehr enthalten sein sollten. Wenn du weniger Farbe willst
konfiguriere es über die param.h.
Alles was ich danach noch gepostet hab ist mehr oder weniger
experimentell. Bei mir läufts/lief es, mehr kann ich aber auch nicht
garantieren.
@Steffen
Auch wenn du es mitlerweile selbst rausgefunden haben dürftest:
Die lcd_writebyte schreibt die Daten, die an sie übergeben werden, als
Bilddaten in den RAM. Die Funktion ist also nicht sonderlich
intelligent. In meiner letzten Version übernimmt die lcd_writebyteg8
auch noch den Datenempfang selbst. Damit spart man sich das verlassen
und wieder aufrufen der Funktion, was doch jedes mal einige Takte sind.
COMAND_TIMEOUT ist als Timeout beim Bilder übertragen gedacht. Wenn auf
dem Weg ein Byte verloren geht würde der Displaycontroller ja erstmal
ewig auf dieses Byte warten. Die Bild-routine würde erst beendet werden,
wenn wieder ein neues Byte kommt. Wenn dieses neue Byte zu einen Befehl
auslösen sollte funktioniert das nicht, weil es ja noch als letzte
Bild-Byte angesehen wird.
Man kann aber auch einfach eine Hand voll Nullen nach jedem Bild senden,
dann kann man auf den Timeout verzichten ;)
Sebastian
@Sebastian
@Steffen
Vielen Vielen Dank,
ich habe heute morgen einfach noch mal die kompletten Adressleitungen
vom Ram auf meinem Layout frei gekratzt und siehe da es funktioniert
tadellos. Das nenne ich absoluten Fachverstand. Vielen Dank. Werde in
Zukunft größeren Abstand zum Massepolygon lassen. Nun werde ich mal
versuchen ein paar Kreise und Bilder auf dem Display anzuzeigen.
mfg
walter10
Eine Frage an die Profis.
Ich habe hier ein LCD TLX-1241 (480x128 4_Datenbits). Dieses würde ich
gerne mit meinem kleinen Computer Z86 clone (UB8830 8MHz) bedienen. Wäre
das möglich? Gibt es eventuell fertige routinen für den Prozessor?
Hallo zusammen,
ich möchte das Projekt auch gerne realisieren, ich warte noch auf die
Teile, von daher probiere ich schon mal alles zu verstehen.
Was ich nicht verstehe ist warum ad0 vom controller zwar am latch hängt,
aber nicht weitergeführt wird, an den Speicher?
64K können adressiert werden wir haben aber nur 32K Speicher, da brauch
man auch keine 16 adressleitungen.
Jedoch ist nicht gerade diese eigentlich notwendig? Ist es nicht das bit
das angibt ob eine adresse gerade oder ungerade ist?
Oder war es vielleicht doch anders rum und bit0 gibt an ob wie die
ersten 32K oder die nächsten 32K anschauen?
Jedenfalls ist es in anderen Beispielschaltungen anders die ich gesehen
habe... Und auf eines von beiden kann man doch nicht verzichten...?
Z.B. Hier:
http://www.mikrocontroller.net/articles/Speicher#Anschluss_an_den_Mikrocontroller
Vielen dank für eure Antworten.
Grüße
Felix
@Peter:
willst du dein Display mit dem Z86 Clone ansteuern? Dann bist du im
falschen thread. Wenn du das Display mit dem Controller hier aus dem
Thread ansteuern willst, und diesen Controller dann mit deinem Z86
Clone, dann passt der Thread. Fertige routinen dürfte es dazu kaum
geben. Ich hab hier jedenfalls noch keine gesehen. Dein Display müsste
sich prinzipiell mit Benedikts Controller ansteuern lassen, aber ich
glaube, du müsstest den Code etwas anpassen.
@Felix:
Auch wenns mit sicherheit schonmal hier im Thread erklärt wurde: Das
Display will die Daten 4-bit weise. Um die Speicher voll auszunutzen
speichert Benedikt die daten aber 8-bit weise im Speicher. Um möglichst
einfach nacheinander an die oberen und unteren 4 bit einer
Speicheradresse zu kommen wird ad0 nicht zum speicher geführt. Dadurch
zeigen immer 2 controller-interne Adressen auf die gleiche physikalische
Speicherstelle. Bei jedem Lesevorgang wird dann noch der Multiplexer
umgeschaltet und so zwischen den oberen und unteren vier bit ausgewählt.
Warum AD0 jetzt noch gelatcht wird, wird wohl Benedikts geheimnis
bleiben. Für die Funktion der Schaltung ists egal. Man sollte allerdings
den Eingang des Latches auf einen definierten pegel legen. Je nach
layout kanns da durchaus das einfachste sein, ihn mit AD0 zu verbinden.
Viele Grüße, Sebastian
Hallo Thread.
Mal zwei schnelle Fragen:
- welches ist die aktuellste Version der Firmware ? Ich hatte gelesen,
dass es etliche neuere Fassungen sowie einige Variationen gegeben hat.
Kann mir jemand eine Empfehlung geben, welche Version am universellsten
einzusetzen ist ?
- Benedikt hat ja sowohl Schaltung als auch Firmware für den Betrieb mit
16 MHz ausgelegt, spricht irgendwas dagegen, das Ganze mit einem 12MHz
Quarz (und entsprechender Änderung in der Firmware) umzusetzen ?
Gruss und schöne Pfingsten,
der Nachbauer
Hi bezüglich der Software kann ich dir auch nicht wirklich helfen das
ist hier mittlerweile etwas durcheinander geraten.
Ich denke die Letzte von Benedikt sollte die sein die mit dem
ursprünglichen Projekt am ehesten läuft. Wobei die anderen Softwaren
sicher auch funktionieren sollten.
Bezüglich des Quarzes:
Es hat seine Gründe weshalb ein 16Mhz Quarz eingesetzt wurde. Da der
Display Controller ja in Software geschrieben ist benötigt die ganze
Schaltung erst einmal einen höheren Takt und das Display Timing
brauchbar zu erzeugen. Ansonsten ist die gGfahr dass das Display stark
flimmert relativ hoch.
ich hoffe dir soweit schon mal geholfen zu haben.
MfG
Kai
Hey Kai.
Na, das ist aber weder ein Ja noch ein Nein.
Dass auch Du keine konkrete Aussage wegen der Firmware machen kannst,
bestätigt ja nur meinen Eindruck, dass es mittlerweile zu viele
Varianten davon gibt. Ich werde so wohl zunächst einmal die Version aus
dem Kopf dieses Threads verwenden.
Mit der Frequenz hingegen konntest Du mich so noch nicht überzeugen - an
anderer Stelle las ich, dass auch die Verwendung langsamer SRAMs ohne
nennenswerte Probleme funktionieren soll [finde den Beitrag gerade
nicht, erinnere aber, dass Benedikt dies im Thread zu der text-only
Fassung der Firmware irgendwo schrieb:
Beitrag "Einfacher Low Cost LCD Controller für 320x240 LCD im Textmodus" ]
Flimmern sollte das Display so oder so auch bei einem geringeren Takt am
µC nicht - der Bildschirminhalt wird doch aus dem SRAM abgerufen. Da
dürfte es relativ unbedeutend sein, wie schnell dieser Inhalt in den
SRAM geschrieben wird.
Hi,
das ist hier im Forum die wohl die aktuellste SW.
In der param.h lässt sich alles einstellen.
Die PDF sagt auch was über das Timing (und damit den Takt) des AVRs
aus.
Beitrag "Re: Grafikfähiger LCD Controller für 320x240 LCD mit 4 Graustufen"
Langzeiterfahrung habe ich sogar mit der Version 1.0
Man müsste den Beitrag wirklich mal etwas sortieren.
Wigbert
Schöne Feiertage.
Hey Wigbert.
Danke für Deinen Hinweis.
Ich habe jetzt die Firmware aus dem Link geladen, für die Verwendung mit
einem 12MHz Quarz geändert
[ #define XTAL_CPU 12000000UL ]
und mal in den ersten Testbetrieb genommen.
Jetzt zeigt mir das angeschlossene Display [das Wintek wd-h3224v] nur
ein schwarzes Bild an, jedoch kann ich kurz nach dem Einschalten
Benedikts Testscreen einmal aufblitzen sehen, danach wird das Display
komplett schwarz.
Jemand eine Idee, woran das liegen könnte ?
[ Die Kontrastspannung, die ich von einem MC34063 beziehe, beträgt +26V,
kann's vielleicht daran liegen ? ]
Gruss,
Martin
Hallo Martin,
die +26V scheinen etwas zu hoch zu sein, sind bei meinen Display's
zwischen 21,5 und 22V.
Versuch mal zu reduzieren.
Viel Erfolg
Ralf-Peter
Grelli,
erneut meinen Dank - nachdem ich die Kontrastspannung auf ca. 22V
gedrosselt habe, ist jetzt ein Bildinhalt zu erkennen.
Leider ist dieser noch ein wenig zerschreddert ( nur bestimmte Teile -
v.a. die Schrift und Teile des Rahmens in Benedikts Testbild, die
Gradientenlinie wie auch einige der Quadrate sind o.k. ), aber durch
Deinen Hinweis bin ich schon einen guten Schritt weiter gekommen.
Danke Dir !
Nachtrag:
Ich habe noch ein bisschen herumprobiert - dabei unter anderem auch mal
die brown out detection [BODEN und BODLEVEL] des Mega8515 angeschaltet.
Siehe da - schon blieb das Display leer.
Also habe ich ein stärkeres Netzteil (1.5A max, anstelle des 350mA)
ausprobiert - ohne Erfolg.
Kann es überdies sein, dass der "gestörte" Bildinhalt, wie ich ihn im
vorherigen Post beschrieb, auch damit zusammen hängt ?
Hat jemand eine Idee ?
Die aktuellste offizielle Version ist die, die Benedikt zuletzt gepostet
hat. Der Link von Wigbert zeigt genau auf den richtigen Post.
Es gibt noch einige andere mehr oder weniger experimentelle Versionen
für mehr Datendurchsatz oder um das Display hochkant zu verwenden. Die
würde ich aber nur nehmen, wenn ich sicher weiß, dass meine Hardware
läuft.
Zum Prozessortakt: Der ist aus sehr gutem Grund auf 16MHz. Der
Controller muss zwar die Daten nicht erst aus dem RAM zurücklesen um die
auf dem Display anzuzeigen, aber er gibt den Takt vor, mit dem die Daten
vom RAM ins Display kommen. Da das in Software gemacht wird, braucht es
auch einiges an Rechenzeit.
Deine Probleme KÖNNTEN vom zu geringen Takt kommen. Stell mal die
Anzeigefrequenz auf 3/4 des aktuellen Wertes. Oder deaktiviere die 8
Graustufen funktion. Oder beides. Oder steck versuchsweise einen 16MHz
Quarz rein.
Wenn es läuft kannst du die Anzeigefrequenz auch wieder hochdrehen.
Darunter leidet allerdings die Geschwindigkeit, mit der die Bilder
aufgebaut werden. Also nicht höher stellen als nötig.
Viele Grüße,
Sebastian
Hallo Martin,
wie sieht eigentlich deine 5Volt Versorgung aus?
Hast du hier einen 5V Festspannungsregler mit entsprechenden
Kondensatoren?
Der Prozessor sollte seinen obligatorischen 100nF direkt am VCC Pin
haben.
Da gibts kein wenn und aber. Ich hatte hier bei nem Versuch auch gedacht
die brauch ich zu testen nicht aber falsch gedacht!
Eventuell noch einen Pullup an Reset schaden tuts nicht. Verbessert auf
jeden fall das EMV Verhalten.
MfG Kai
Hey Kai.
Die Spannungsquelle ist ein 7805.
Ja, so mehr ich hier lese, desto eher glaube ich, dass ich meinem Board
noch ein paar Folienkondensatoren und eine Prise Pullups spendieren
sollte.
Danke für den Hinweis !
Gruss,
Martin
Kleines Update:
An der Frequenz liegt's nicht - ich habe jetzt den 12MHz Quarz durch
einen 16er ersetzt und auch die entsprechende Firmware [direkt das
unveränderte "Original"] auf den µC übertragen - das zerschredderte Bild
bleibt dennoch.
[Zur Erinnerung: Auf dem LCD wird im oberen Drittel der entsprechende
Teil von Benedikts Testbild verzerrt dargestellt. In den beiden unteren
Dritteln der Anzeige wiederholt sich dieser Teil.]
Ich habe mir auch nochmal die Musse gegönnt und die Spannungen an den
VCC der verwendeten ICs nachgemessen [jeweils gegen den entsprechenden
Massepin] - alle ICs liegen bei ca. 4.2 ~ 4.6 V, was laut den
Datenblättern kein Problem darstellen dürfte.
[ Vielleicht mit Ausnahme des SRAMs ? Wie kann ich die Spannung dort auf
einem höheren Level stabil halten ? Der 7805, welchen ich zur
Spannungsversorgung verwende, spuckt ca. 4.8 V aus. ]
Hat noch jemand eine gute Idee, an welcher Ecke ich mit der Fehlersuche
weiter machen könnte ?
Gruss,
Martin (a.k.a. der Nachbauer)
Schieß doch mal ein Foto vom Display. Das was angezeigt wird ist klar
und (halbwegs) kontrastark zu erkennen?
Ist dein RAM groß genug? Hast du irgendwo Adressleitungen vertauscht
und/oder miteinander verbunden? Gleiches für Datenleitungen? Welche
Version des Schaltplans hast du verwendet? Die im ersten Posting des
Threads enthält einen Fehler.
Ich muss aber zugeben, dass ich hier ziemlich im dunklen stocher ;)
Viele Grüße,
Sebastian
Hey Sebastian.
Der SRAM dürfte eine 50ns Variante sein.
Die Schaltpläne habe ich mir auch noch einmal genau angesehen und die
Leitungen nochmals alle durchgemessen.
So weit kann ich keinen Fehler entdecken.
Anbei eine Aufnahme des angezeigten Bildinhaltes.
Ich hoffe, dass dieser Aufschluss über die mögliche Fehlerursache geben
kann.
Gruss,
Martin
@Martin:
Da stimmt was an deiner Schaltung nicht ;)
Bei den Leitungen vom HC157 zum Display dürfte eine leitung keinen
Kontakt haben oder Fest auf Ground gezogen sein (Brücke zur
Nachbarleitung?)
Die Horizontalen Widerholungen sind etwas komisch, aber normal kommt
sowas von Fehlern in den Adressleitungen.
Einfach nochmal alles durchschaun und nachmessen ;)
Sebastian
Hallo Wigbert,
hey Sebastian.
Lieben Dank für Eure Hinweise und den Schaltplan.
Ich habe heute Abend alle Kontakte erneut durchgemessen und noch
fehlende Abblockkondensatoren [je 100nF] vor alle ICs gesetzt.
[Sebastian: ich habe genau darauf geachtet, es ist (leider) keine
Datenleitung auf Masse gezogen]
Leider stellte sich keine Veränderung am Ergebnis ein.
Vielleicht spielt es eine Rolle: Ich verwende das Wintek WD-H3224V
Display von Pollin -- mittlerweile das zweite, um ggf. vorhandene
Probleme auf Seiten des Displays auszuschliessen.
Ich werde Morgen erneut alle Verbindungen durchmessen, um ganz sicher zu
gehen.
Gruss,
Martin
Heute habe ich mir die Zeit genommen, noch einmal in Ruhe alle Leitungen
durchzumessen - es ist alles so, wie es sein sollte.
Darüber hinaus konnte ich jedoch eine interessante Beobachtung machen:
Bei einem probeweisen Einschalten der Schaltung gab es mit einem Mal
erstmals ein einwandfreies Bild.
Natürlich habe ich diesen Zustand auf Reproduzierbarkeit testen wollen,
jedoch zeigte sich schon beim erneuten Neu-Einschalten wieder die o.g.
Störung.
Vielleicht könnt Ihr mit dieser Information etwas anfangen.
Gruss,
Martin
Hallo Leute
Ich brauche unbedingt ein EEPROM an dem Mega8515 um ein Bild
(Startbildschirm) gleich nach der Initialisierung anzuzeigen. Ich habe
mir dafür ein ATMEL25256A SPI EEPROM ausgesucht. Die Anschlüsse dafür
wären ja noch frei.
Hab mir auch schon die Application-Note AVR107 (Interfacing AVR serial
memories) herunter geladen.
Anschlussbelegung:
EEPROM SCK -> SCK Mega8515
EEPROM SI -> MOSI Mega8515
EEPROM DO -> MISO Mega8515
EEPROM /CS -> /SS Mega8515 -> /CS noch über einen 4k7 Widerstand gegen
5V
Funktion:
Wenn der Display-Controller initialisiert wurde soll der Startbildschirm
aus dem EEPROM geladen und sofort angezeigt werden. Danach wird der Uart
frei gegeben.
Ich hab die Controllerversion auch schonmal so weit abgespeckt (fast
alle Funktionen entfernt) da ich nur jeweils ein s/w Bild laden muss.
>>Hat schonmal jemand sowas gemacht?>>Brauche da mal eure HILFE!!!
Ich komm mit "C" einfach nicht klar
Wo definier ich zum Beispiel die Ports für den SPI?
Hab mal die SPI-Treiber und meine Abgespeckte Version mit angehangen
Schau dir mal die lcd.c genauer an. Da wird (wenn ichs richtig im kopf
hab) alles initialisiert. Da hängst du dann auch die SPI-Init rein.
In der lcd.c wird auch das aktuelle Startbild erzeugt. Diesen Code
müsstest du dann einfach durch deinen eigenen ersetzen (also daten aus
SPI laden und über die im pdf dokumentierten subroutinen ins RAM
schreiben).
Du kannst auch überlegen, ob du dein Bild algorithmisch erzeugen kannst
(also über rechtecke, kreise, linien, text,...). Dann könntest du dir
eventuell das externe EEPROM sparen.
EDIT
Ich bin mir nicht sicher, welche Version du runtergeladen hast, aber von
den experimentellen, die ich noch gepostet habe kann ich nur abraten,
wenns mit den Programmierkenntnissen nicht sooo gut steht. Die bei dir
eingestellten 2MBaud machen mich jedenfalls hellhörig. Mit der letzten
offiziellen Version von Benedikt wird das nicht funktionieren und mit
meinen experimentellen Versionen könnte sw probleme machen.
Nimm doch bitte diese Version. Die Sollte auf jeden Fall funktionieren:
Beitrag "Re: Grafikfähiger LCD Controller für 320x240 LCD mit 4 Graustufen"
Viele Grüße,
Sebastian
Hallo Sebastian
Endlich eine Antwort. Huhu..
Meine Baudrate ist momentan bei 1Mbaud. Das funktioniert auch alles
supi. Ich hab mich heute schon soweit durchgewurschtelt und all die
SPI-Routinen zum Laufen gebracht.
Jetzt steh ich natürlich wieder auf dem Schlauch, was die Einbindung zum
RAM angeht.
Hier mal ein kurzer Auszug aus der Funktion zum EEPROM lesen.
Funktion:
Ich würde das auch gern in der lcd.c einbinden. Und zwar da wo der RAM
gelöscht wird.
1
voidlcd_clear(void)
2
{unsignedshorti;
3
for(i=0;i<(65536-DDRAM);i++)
4
mem[i]=0;
5
}
Wie kann ich jetzt den Pointer auf das Array von den SPI-Daten gleich in
den Display-RAM schreiben???
Ich glaub ich bin schon so na.. Aber ich bekomms einfach nicht hin!
Kanst du mir da noch helfen?
LG Steffen
"Einfach so" in den RAM schreiben funktioniert nicht, weil die Daten
nicht linear im RAM abgelegt sind. Nimm die vorhandenen Subroutinen. Für
dich also die lcd_writebyte. Der Aufruf davon ist im pdf aus dem
projekt-zip dokumentiert.
In die lcd_clear würde ich das nicht hängen. Ist einfach unsauber.
Schreib dir eine eigene Funktion, die die Daten aus dem EEPROM ausliest
und dann mit lcd_writebyte in den RAM schreibt. Die rufst du dann da
auf, wo auch aktuell das Startbild erzeugt wird.
Wenn du Benedikts Version verwendest läuft 1MBaud aber nur sauber, wenn
du mit dem Master nicht so schnell senden kannst, wie es der Slave
zulässt. Eigentlich ist nämlich der Displayinterrupt zu lang, sodass du
Bytes verlieren würdest.
Noch ne andere Idee: Du steuerst das Display ja eh von außerhalb an.
Wieso nicht einfach von dort das Startbild reinschieben? Dann sparst dus
dir an einem fremden System zu basteln. Das aktuelle Startbild kann man
ja rauskommentieren. Dann bleibt das Display schwarz, bis was an der
UART kommt.
Sebastian
HAllo Sebastian
>"Einfach so" in den RAM schreiben funktioniert nicht, weil die Daten>nicht linear im RAM abgelegt sind.
Das hab ich gestern auch noch gemerkt. :(
>Schreib dir eine eigene Funktion, die die Daten aus dem EEPROM ausliest>und dann mit lcd_writebyte in den RAM schreibt. Die rufst du dann da>auf, wo auch aktuell das Startbild erzeugt wird.
So hab ich es jetzt erst mal gelöst. Ich verwende nun die
"lcd_writebyte(x,y,c)". Und es funktioniert erst mal soweit wie es
aussieht. Allerdings etwas unschön. Ich hol mir jetzt momentan jedes
einzelne Byte vom EEPROM und sende es gleich danach weiter über die
"lcd_writebyte". Das heißt für jeden EEPROM Zugriff habe ich jetzt einen
Head von 4 Byte für ein Nutz-Byte. Das ist eher subotimal. Wenn ich den
EEPROM mit dem Bild gefüllt habe häng ich mal ein Bild an. (PonyProg
funktioniert dafür leider doch nicht)
>Wenn du Benedikts Version verwendest läuft 1MBaud aber nur sauber, wenn>du mit dem Master nicht so schnell senden kannst, wie es der Slave>zulässt. Eigentlich ist nämlich der Displayinterrupt zu lang, sodass du>Bytes verlieren würdest.
Ich weiß. Ich muss natürlich das Busy beim Senden abfragen. Und schon
sind es effektiv keine 1Mbaud mehr. Aber es reicht mir so.
>Das aktuelle Startbild kann man ja rauskommentieren. Dann bleibt das >Display
schwarz, bis was an der UART kommt.
Das hab ich schon gemacht. Ich habe ja bis jetzt keinen Startbildschirm
mehr.
>Noch ne andere Idee: Du steuerst das Display ja eh von außerhalb an.>Wieso nicht einfach von dort das Startbild reinschieben?
Das wär die einfachste Lösung. Aber der andere Controller hat einen
Bootloader drauf der nach den Reset/Einschalten erstmal ca 5sec wartet
bis er die Application startet. Deswegen möchte ich ja auch in dieser
Zeit ein Startbild im Display anzeigen und kein schwarzen Bildschirm.
Hallo zusammen,
ich hab mal eine Frage an die Bild Spezialisten.
Mein Touchscreen von Pollin im 8 Graustufen Modus funktioniert
wunderbar, ich kann Rechtecke, Kreise und Linien darstellen und das
Touchpad abfragen nur würde ich gerne mal ein Bild anzeigen ,aber hier
komme ich zu keinem Erfolg, ich Programmiere in Bascom und steuere den
8515 mit einem Atmega32 an. Die Anleitung in Bascom hier im Forum zur
Anzeige des Hasen funktioniert einfach nicht bei mir. Wäre es möglich
eventuell eine kleine Anleitung zu geben ? (z.B Bild mit Grafikkonverter
umwandeln, welche Einstellung, Erzeugte Daten in Bascom einbinden und an
8515 übergeben mit Hinwies zu den Graustufen und Pointervarialblen zu
den Datenbanken)
Vielen Dank
walter10
Hallo Walter,
hast du dir den Thread (ab da, wo es die 8Graustufen-Version gibt)
durchgelesen? Mit den Bildern hatten schon einige Probleme. Vielleicht
findest du da was. Im Doku-pdf ist glaube ich ein kleiner Fehler drin
beim Senden von 3bit Bildern. Um dir zu helfen wäre es hilfreich, wenn
du mal postest, was du überhaupt an den Controller sendest, und was das
Display dann macht. Ich kann dir aber nicht versprechen zu antworten.
Bin grade im Urlaub.
Viele Grüße,
Sebastian
Hallo zusammen,
also ich hab jetzt soweit alles mögliche versucht und habe immer das
Problem das die Bilder nach ca 3 mm von oben verschoben sind, egal wo
ich sie auf dem Display hinsetzte. Ich hab mal ein Bild aus dem
Grafikkonverter auf 208x144 Pixel verkleinert und im Floyd-Steinberg
Verfahren umgewandelt und entsprechend für Bascom nachbereitet ergibt
dann 3744 Bytes wie in der Anleitung und sende diese Daten zum Display.
Auch wenn ich den Hasen aus dem Forum nehme und die Daten ausgebe sind
die Füße von dem Hasen nach rechts verschoben, kann da eventuell ein
Hardwarefehler vorliegen. Zur Kontrolle hab ich auch mal das
Basicprogramm mit eingestellt.
mfg
walter10
Könnte gut am gewählten Quarz und der Baudrate liegen.
10,24MHz sind sehr ungewöhnlich.
10,24MHz und 57,6kBaud hat ne Fehlerrate von rund 1% da kann es sehr gut
sein das der Empfänger hin und wieder mist empfängt und das bild dann so
aussieht.
Versuch mal einen anderen Quarz am besten einen Baudraten Quarz wie z.B.
14.7456 MHz oder auch 12MHz.
Tritt der Effekt immer an der selben Stelle oder immer an
unterschiedlichen Stellen auf?
Also hab mir einen 14.7456 MHz Quarz besorgt und neu Compiliert aber der
Fehler bleibt ca. die ersten paar Zeilen sind korrekt und dann macht das
Bild einen Sprung und wird verschoben und der rechte Teil wird links
angelegt und das Gesamtbild wird nach rechts verschoben. Das Problem
tritt immer auf egal wo ich das Bild auf dem Display platziere. PS. der
10,24MHz Quarz war noch ungenutzt, den 14,7456 Mhz hab ich aus meinem
AVR-Server mit Kamera ausbauen müssen.
mfg
walter10
mal die ganze Sub für mein "Karnickel"
Sub Bild
Local Count As Word
Local B As Byte
If Bild_bit = 1 Then 'Flag, woher auch immer
Printbin 16 ; 170 ; 30 ; 63 ; 8 ; 64 ; 0 ' Bildplatz
If Wahl = 0 Then Restore Hase : 'Bildauswahl
If Wahl = 1 Then Restore Schildkroete :
If Wahl = 2 Then Restore Taste :
For Count = 1 To 512 'hole Byte
Read B
Printbin B
Next Count
Bild_bit = 0 'Flag auf 0 setzen
End If
End Sub
Ich hatte das mit Bitmap_Converter in C ausgegeben und für Bascom
umgeschrieben.
Vielleicht ist was Hilfreich.
Wigbert
Es funktioniert:
Aber ich mußte mir nochmal fast das ganze Forum durchlesen um den Fehler
zu finden, es liegt nicht am Quarz. Und zwar der Beitrag von Bruno M hat
mich auf die Lösung gebracht. Es ist ganz alleine der Clear
Befehl(Printbin 12) wenn der vorher gesendet wird, dann klappt es nicht
mit den Bildern. Weiß jetzt nicht ob das nur an Bascom liegt aber
irgendwie werd ich das jetzt hinbekommen, und mich nun mal mit den
Graustufen beschäftigen.
Vielen Dank
walter10
Hallo Walter,
du handlest das Busy-signal nicht richtig. Wenn du das richtig machst,
ists auch egal, welcher Befehl vorher kommt.
Sobald das Busy-signal anliegt darfst du nur noch eine Hand voll Bytes
an den Displaycontroller schicken. Wie viele das sind sollte im Doku-pdf
stehen. Wenn du das in den Sourcen anders konfiguriert hast musst du
dich natürlich an deine Konfig halten.
Bei dir passiert momentan folgendes: Du Lässt das Display löschen und
sendest gleich die ersten Bilddaten. Die kommen dann erstmal in den
Puffer des Displaycontrollers. Der ist aber voll, bevor der lösch-befehl
abgearbeitet ist - genau hier gehen dir Daten verloren. Dadurch entsteht
der Versatz.
Viele Grüße,
Sebastian
Hallo,
Ich mir mal so überlegt, ob man mit einem ATmega1284P-PU (gibt es bei
Pollin) nicht sogar den LCD-8Graustufen_Grafikcontroller implementieren
könnte.
Der ATmega1284P-PU hat intern 16kByte RAM !!!
Damit könnte einiges an Hardware des LCD-8Graustufen_Grafikcontroller
wegfallen und der Aufbau sich ähnlich einfach gestalten wie hier dieser
LCD-Text_Controller.
Was meint ihr??
Um es kurz zu machen: Nein. ;)
Die 16kByte würden erstmal eh nur für S/W reichen. 4 Graustufen brauchen
18,75kByte und 8 Graustufen brauchen 28,125kByte für je ein Vollbild.
Wenn man sich auf S/W beschränkt könnte es hinhaun, hab ich aber nicht
durchgerechnet. Aber sobald du Graustufen willst wirds mindestens knapp,
wenn nicht unmöglich (abgesehen vom Speichermangel). Benedikts Schaltung
ist so gebaut, dass für einen Displayrefresh die Daten direkt vom RAM
ins Display geladen werden. Der Controller gibt nur den Takt vor.
Würdest du die Daten im internen RAM vorhalten, müsste die CPU erst den
RAM auslesen und die Daten dann auf einem Port dem Display zur Verfügung
stellen. Die Steuersignale des Displays kämen dann auch noch dazu. Das
dauert definitiv länger, auch wenn die Zugriffszeit im internen Ram
etwas kürzer ist. Du kaufst dir den geringeren Schaltungsaufwand also
durch mehr CPU-Last, was die Framerate deutlich drücken dürfte.
Aber schau dir doch mal den LCD-Controller im Textmodus (da hast du ja
unerhörterweise genau das gleiche gepostet) genauer an. Vielleicht
kannst du den mit Hilfe des Mega1284 soweit aufbohren, dass er
grafikfähig wird. Ich kenne die Software des Textcontrollers nicht
genau, aber eigentlich müsste es (mit genug RAM) möglich sein, dem
Grafik beizubringen.
Oder was viel Sinnvoller wäre: Nimm einen der vielen Displaycontroller
die es gibt. Zum Beispiel von Epson. Das verringert den
Schaltungsaufwand auch enorm und dürfte sogar eine deutlich höhere
Leistung bringen als die Lösung hier.
Sebastian
Sebastian ... schrieb:> Die 16kByte würden erstmal eh nur für S/W reichen. 4 Graustufen brauchen> 18,75kByte und 8 Graustufen brauchen 28,125kByte für je ein Vollbild.
Ja, das hab ich wirklich nicht bedacht. Da hast du wohl recht Sebastian.
Dann lohnt es sich wirklich nicht mit dem ATmega1284 rum zu
experimentieren. Der kostet ja auch immerhin min. 7 Euronen.
Naja, war halt nur mal so eine Überlegung..
LG Steffen
Hallo zusammen,
Hab bei mir im schrank noch nen sp14q002 gefunden und würde den
controller gerne nachbauen. Hat noch wer ne unbestückte platine zum
verkauf?
Hi,
mal was neues von der GLCD-Front.
Ein SP14Q002 an Benedikts Graphikkarte. Zusätzlich muss nur
ein Poti die Spannung V0 einstellen.
Es ist etwas grösser wie das NANYA. Blauer Hintergrund.
Preis des Displays etwa 9 Euro+Versand.
Eine Adapterplatine ist auch schon geroutet.
Ich mach noch ein paar SW Tests und könnte mir dann eine
Sammelbestellung vorstellen.
Vielleicht noch was für Weihnachten.
Wigbert
Hallo,
ich habe heute noch mal die Display-Platine an die RS232 Schnittstelle
gehangen.
Mal zur Ansicht, ein halb invertiertes Display bei Spannungswerte
VEE, V0 laut DBL. Man kann mit dem Display sicher keine Wunder
erwarten, aber ein kostengünstiges Spielzeug.
@Martin Schröer
ich hatte an ein Bausatz mit folgendem Umfang gedacht:
Graphikkartenplatine; Adapterplatine für GLCD; FFC Buchse;
S-Ram;alle SMD; Speicherspule; und das GLCD.
Schönes Wochenende.
Wigbert
Hallo Wigbert
Wenn man sich schon so konsequent mit den GLCD's wie du beschäftigst,
warum integrierst du nicht auch gleich den Inverter für die
Hintergrundbeleuchtung mit in das Layout?
@Steffen H.
na ja, sooo viel mach ich auch wieder nicht.
Ein Inverter nachbauen lohnt sich wohl preislich kaum.
Ich wollte Benedikts GRAKA nicht sterben lassen, nur weil es
keine NAN-YAs mehr gibt und such immer nach Ersatzdisplays.
Wobei, für Hinweise bin ich immer offen. Ich hatte schon mal
in Erwägung gezogen ein Inverter aufzustecken. Die
Spannungsversorgung(5V) ist ja schon auf dem Board vorgesehen.
Wigbert
Hier mal ein Vorschlag für einen Inverter. Diese Schaltung funktioniert
so bei meinen Displays schon seit Langem.
Den CCFL Trafo bekommt man leider nur bei DigiKey, Mouser oder auch
Farnell.
Gruß Steffen
>Den CCFL Trafo bekommt man leider nur bei DigiKey, Mouser oder auch>Farnell.
Eigentlich kommt wohl nur Digikey in Frage. Ca 4-5 Euro
für den Trafo.
Steffen hast Du mal auch Langzeittests gemacht? Bei zu
hohen Strom leiden sicher die CCFL-Röhren.
Wigbert
Diese Schaltung wurde schon ausgiebig getestet und wird in medtec
Produkten so verbaut.
Bei mir selber läuft das ganze schon länger als 2Jahre ohne die CCFL
Röhre zerstört zu haben.
Hi,
der Adapter-Prototyp des SP14Q002 läuft anstandslos auf mein Board.
Ich denke, anfang des neuen Jahres werde ich einige machen lassen.
Ansonsten: Siehe Testbild
Wigbert
Moin allerseits,
Ich habe mal wieder ein tolles e-Bucht Angebot genutzt und mir 2 Epson
EG-4801-ER gekauft...
Nun zu meiner Frage, das Display hat eine Auflösung von 512*128 Pixel,
bekomme ich den Controller soweit "aufgebohrt"?
Das Datenblatt ist übrigens hier:
http://www.knjn.com/files/512%20x%20128%20Graphic%20LCD%20Display%20-%20EG4801.pdf
MfG
Sollte recht problemlos gehen.
Die Ansteuerung des Displays scheint auf den ersten blick sehr ähnlich
zu den hier verwendeten zu sein, also wenig oder keine anpassungen an
der Hardware nötig. Die Software muss natürlich an die neue Auflösung
angepasst werden. Wenn die S/W reicht geht das relativ einfach. Bei 4
Graustufen bin ich mir jetzt ohne nachschaun nicht sicher, aber sollte
auch ohne weiteres machbar sein. 8 Graustufen sind an sich auch kein
Problem, allerdings musst du dann die Daten im RAM anders anordnen. Das
sollte prinzipiell ganz gut machbar sein, aber man muss sich halt schon
etwas tiefer in die Software einarbeiten und muss auch alle low-level
Schreib-Routinen anpassen.
Grund dafür ist, dass die 512 Pixel bei 3bpp nicht mehr "nebeneinander"
in den RAM passen. Momentan liegt eine Displayzeile immer so, dass sich
die höchsten 8 Adressbits innerhalb der Zeile nicht ändern. Das wäre mit
512 Pixeln in einer Zeile nicht mehr gegeben.
Viele Grüße,
Sebastian
Hallo.
Das klingt gut. Mir würden im Prinzip auch schon 2 Graustufen genügen.
Dann werde ich mal eine Platine Fräsen und etwas ausprobieren. Könnte
mir jemand mit der Softwareänderung helfen? Meine Kentnisse beschränken
sich leider nur auf BASCOM. Was die Anpassung für mich etwas kompliziert
macht. Jedoch habe ich den AVR-GCC Installiert und sollte in der lage
sein änderungen vorzunehmen...
MfG und Danke
Klar, wenn du Fragen hast dann stell sie einfach. Für den Anfang
solltest du halt den vorhanden Code zumindest halbwegs verstehen, sonst
wirds reine Glückssache.
Der wichtigste teil für dich dürfte der Display-interrupt sein. Der ist
in Assembler geschrieben. Ist aber auch kein größeres problem. Die
Befehle sind alle in der Hilfe vom Studio erklärt. Darin müsstest du in
Jeder zeile einige Pixel mehr ausgeben als das jetzt der fall ist und
dafür nur 128 Zeilen durchlaufen lassen bevor das Bild beendet wird.
In der param.h gibts auch parameter, die die Displaygröße angeben. Die
solltest du auch ändern, weil sie für einige berechnungen hergenommen
werden.
Wenn ich mich nicht irre musst du die Schreibroutinen nicht weiter
anpassen. Für den Gültigen Bereich sollten die auf die Displaygröße aus
der param.h zurückgreifen. Sicher bin ich mir aber nicht. müsste auch
erst wieder in den code schaun.
Viel Erfolg bei deinem Vorhaben!
Sebastian
Hallo.
Ich habe gerade angefangen mein Layout an die Gegebenheiten anzupassen,
da fiel mir auf, dass das Display mehr Anschlüsse hat, als der
Graphikcontroller...
Ich habe bis jetzt
Contr.-- Display
D3 --- D3
. .
. .
D1 --- D1
XSCL --- XSCL
LP --- LP
ON/OFF--- YDIS
Übrig ist bis jetzt am Controller : "M_AC" und "FLM_Frame"
Am Display ist noch : "FR" , "YSCL" und "DIN" frei.
Wie ist dies anzuschließen, bzw. der Controller anzupassen?
MfG
Hallo zusammen,
kann mir jemand sagen für welche Spalten - u. Zeilen - Treiber die
Software geschrieben wurde.
Könnte das Display "Grafikdisplay 320x256" bei Pollin füe 5,-95€ passen.
halo,
h habe habe in paar Problm einBitmap bild zum glcd Conrole un üertragen
mein Sourccode ist im Anhang.
das bild ist 240x240 pixel gross,die Abmessung auf dem Display stimmen
aber der Inhalt sind nur wirre pixel erkenbar.
Wenn ich das ganze in Assembler schreibe geht es,
aber in C gehts überhaupt nicht.
vielleicht kann mir einer von ihnen weiterhelfen
was ich Falsch mache
mfg
Erstmal sorry, dass ich mir so lange Zeit gelassen habe. War viel zu
tun...
@Denis
Hat sich das Problem mitlerweile gelöst, oder soll ich mir das nochmal
anschaun? Aus dem Stand weiß ich jetzt auch nicht, was mit den übrigen
leitungen anzufangen ist.
@Ronny
Prinzipiell sollte das Display gehen. Problem ist aber, dass du kein
Datenblatt dazu hast. Dir fehlt also die Anschlussbelegung. Auch die
höhe der Kontrastspannung kannst du so eigentlich nur raten.
Schau dir doch mal das Wintek hier an:
http://www.pollin.de/shop/dt/Mzk0OTc4OTk-/Bauelemente_Bauteile/Aktive_Bauelemente/Displays/LCD_Modul_WINTEK_WD_H3224V.html
Dazu gibts auch ne Anschlussbelegung und in Benedikts anderem
320*240-GLCD-Thread gibts auch genug erfahrungen mit dem Display sowie
eine Umbauanleitung auf weiße Hintergrundbeleuchtung.
@Heinz
Wenn sich das Problem noch nicht gelöst hat, dann schieß doch mal ein
Bild deines Displays. Oft erkennt man daran schon ungefähr, was schief
läuft. Dann muss ich mich nicht erst durch deine Quellen arbeiten ;)
Viele Grüße,
Sebastian
Aber nur, wenn du mich duzt ;)
Das schaut stark danach aus, dass du den Befehl zum Bild anzeigen nicht
sendest. Ein kurzer Blick in den Code scheint das zu bestätigen.
Sollte ich die entsprechenden Befehle im Code übersehen haben, dann
prüfe bitte nochmal, ob du das Kommando wirklich richtig ans LCD
schickst. Wie's geht weißt du ja, sonst würds ja in ASM nicht laufen.
Wenn es dann immernoch nicht geht hängt das Display vermutlich noch in
einem anderen Befehl. Dann geht entweder im Displaycontroller beim
starten was schief, oder du hast vor dem Bild-senden ein Kommando in
deinem Code, dem du nicht alle Parameter mitgibst. Als work-around hilft
in beiden Fällen, vor dem Bild-Kommando einige nullen (zehn oder so) zu
Senden. Das ist aber keine endgültige Lösung!
Viele Grüße,
Sebastian
Ah, jetzt hab ich auch die stelle gefunden, wo du den Befehl sendest.
uart_putc(16 );
uart_putc(0xAA);
uart_putc(0 );
uart_putc(0 );
uart_putc(0 );
uart_putc(30 );
uart_putc(240 );
uart_putc(0 );
da ist eine null zu viel zwischen 0xAA und 30. Richtig gehts so
uart_putc(16 );
uart_putc(0xAA);
uart_putc(0 );
uart_putc(0 );
uart_putc(30 );
uart_putc(240 );
uart_putc(0 );
In deiner version wird die Breite des bildes als 0 interpretiert. => Der
Bildbefehl beendet sich gleich wieder und die restlichen Bilddaten
werden als Text interpretiert.
Sebastian
Funktioniert denn normales text schreiben richtig, oder kommt da auch
schon nur mist an?
Wenn nicht: Läuft der Controller wirklich auf dem vorgesehenen Takt? Ist
die Taktfrequenz im Code/im Projekt richtig angegeben? Am besten prüfen
indem man mit warteschleife pins toggelt. Ist die Baudrate richtig
angeben? Sendet er auch wirklich mit der baudrate? Am besten mit
Oszi/Logicanalyzer nachmessen.
Ansonsten würd ich die LoadBitmap_P mal hardcoded aufbauen. Also die
Parameter ignorieren und die Schleifengrenzen fest in den code
schreiben. Keine Sonderfälle mehr behandeln. Einfach nur stur auf
speziell dieses eine Bild trimmen. Schließt schonmal wieder ein paar
mögliche Fehlerquellen aus.
Sebastian ... schrieb:>> Ansonsten würd ich die LoadBitmap_P mal hardcoded aufbauen. Also die> Parameter ignorieren und die Schleifengrenzen fest in den code> schreiben. Keine Sonderfälle mehr behandeln. Einfach nur stur auf> speziell dieses eine Bild trimmen. Schließt schonmal wieder ein paar> mögliche Fehlerquellen aus.
hallo Sebastian,
Das Wars:) Läuft jetzt alles supi auch im Modus2
viellen Dank nochmal .
Manchmal ist das doch soeinfach wenn man draufkommt
mfg
Hallo Sebastian
danke für Deine Antwort.
Grund meiner Frage nach dem Display bei Pollin war, dass ich noch
einige Grafikdisplay (Anzahl > 30, 160 x 128 Pixel) mit den
Spalten-/Reihen- Treibern Hitachi HD61104/HD61105 habe.
Das Display habe ich versucht wie weiter unten beschrieben zu betreiben.
Pin 1 GND
V0
VCC
VEE
CL1 LP
CL2 CP
DI FRM
M M
D0 D0
D1 D1
D2 D2
Pin 14 D3 D3
Funktioniert aber nicht.
Die Displays habe ich schon einmal mit einem Hitachi H8 angesteurt,
sie funktionieren aber die Framerate war leider zu gering, hat zu
stark geflimmert.
Wäre schön wenn die Controller-Software hier passen würde und ich damit
meine Displays Hitachi LMG6490 (natürlich gibts dazu auch keine Daten-
blätter mehr) betreiben könnte.
Das schaut erstmal nicht falsch aus. Hab mal etwas in die Datenblätter
reingeschaut. An sich sollten die Treiber sich mit dem Controller hier
vertragen und die Verbindungen schaun auch passend aus.
Dispoff ist auf dem panel verdrahtet? Das müsste sonst halt auch noch
versorgt werden.
GND, VCC sollten ja klar sein. Die Spannung an VEE passt? Was ist V0?
Wenn dein Display aber wirklich nur 160*128 Pixel hat, musst du auf
jeden Fall die Software umbauen! Ich bin mir jetzt auch nicht sicher, ob
es reicht, in der param.h die auflösung anzupassen. Glaube du musst auch
im code selbst (anzeigeinterrupt) änderungen machen.
Viele Grüße,
Sebastian
Dann kann ich, mit den vorhandenen Informationen, leider auch nicht
helfen.
Wenn du hilfe willst wäre der angepasste Quellcode hilfreich. Außerdem
eine genauere Beschreibung was genau das Display macht oder nicht macht.
Auch die Haredware könnte duraus noch fehlerhaft sein. Hier gabs schon
einige, die schon 3 mal alles kontrolliert hatten. Am Ende lags dann
doch an der Hardware. Zur Sicherheit hier gleich noch der Hinweis: Der
Schaltplan aus den ersten ein oder zwei Versionen ist fehlerhaft.
Viele Grüße,
Sebastian
Hallo.
Nein, mein Problem hat sich noch nicht gelöst. Ich habe auch die letzte
Woche keine Zeit zum recherchieren gehabt, meine Arbeit hat mich doch
sehr gefordert...
ich bin am Überlegen, ob ich XSCL und YSCL miteinander verbinden
soll/kann.
Für Hilfe mit diesem Display wäre ich froh.
MfG Denis
Hallo Denis,
sorry, dass ich zur Zeit immer so lange brauche. Ist halt grad
Prüfungszeit....
Hab mir das Datenblatt deines Displays grade etwas genauer angeschaut
und gemerkt, dass das Ding als 1024*64 organisiert ist. Ist erstmal kein
problem, aber die Software muss man entsprechend anpassen. Das werden
schon tiefere Eingriffe...
Zu den Verbindungen:
FR (Display) muss an M/AC (Controller)
XECL (Display) müsste man noch extra erzeugen. Das muss alle 64 Pixel
einmal kurz high geschaltet werden. Sollte ganz gut in Software machbar
sein, aber muss man halt machen.
DIN (Display) müsste an FLM_Frame (Controller) gehören.
YSCL kann man eventuell mit an LP hängen, aber sicher bin ich mir da
nicht.
Unterm Strich scheint mir das display deutlich nerviger zu sein, als ich
erst dachte ;)
Sebastian
Hallo,
ich beobachte diesen Thread schon seit langem, und genauso lange wollte
ich diesen bzw. einen seiner "Geschwister-Controller" hier im Forum
nachbauen.
Da ich wohl nicht dazu kommen werde verkauf ich nun meine LC-Displays
mit Touchpanel. Vielleicht kann sie ja jemand von euch ehernvoll in
Betrieb nehmen.
Hab sie im Markt eingestellt
(Beitrag "Verschenke/Verkaufe Touch LC-Displays, Textoolsockel, div. USB und Audio IC´s").
Philipp
@Moderator: ich hoffe diese "Werbung" ist erlaubt, sonst bitte löschen.
Hallo zusammen,
gibts eine Zusammenfassung vom Projekt? ist doch sehr unübersichtlich.
Eine Wiki Seite konnte ich nicht finden. Oder sind die Sourcen aus dem
Eröffnungspost gar noch aktuell?
Gruß
Die Sourcen aus dem eröffnungspost sind definitiv nicht mehr aktuell.
Das findet man aber schon nach einer Hand voll Beiträge raus. ;)
Die aktuelle Version gibts hier
Beitrag "Re: Grafikfähiger LCD Controller für 320x240 LCD mit 4 Graustufen"
Die hat dann auch 8 Graustufen und einen leicht korrigierten Schaltplan.
Später im Thread kommen noch ein paar andere Versionen, aber die sind
als experimentell anzusehen und sind nur in ausnahmen empfehlenswert.
Eine Zusammenfassung gibts leider nicht. Jedenfalls kenne ich keine.
Sebastian
Ich finde es eigentlich auch schade, das ein gewisser
Überblick fehlt. Die Grafikkarten werden nach wie vor
gerne genommen. Auch hätte ich einige Adapterboarde
schon in der Schublade.
Leider fehlt mir im Moment die Zeit, eine aktuelle
Zusammenfassung zu erstellen.
Wigbert
Ja, mir gehts da ähnlich. Keine Zeit. Ein Wiki-Artikel wäre echt schön.
Zumindest gibts ja das pdf-file in den zip-ordnern. Das fasst ja das
wichtigste schon zusammen.
Habe in der letzten Version von Benedikt ja auch noch einige Änderungen
vorgenommen, die ich ja auch schon veröffentlicht habe. Aber das ist
halt so inkonsequent, dass mans nicht empfehlen kann. Das wollte ich
eigentlich auch noch alles vernünftig implementieren. Aber halt wie
immer zu wenig zeit.
Mal schaun, vielleicht schaffen wir ja mit vereinten kräften zumindest
einen wiki-artikel ;)
Sebastian
Ich hab jetzt mal im Wiki einen Artikel zu dem Controller angefangen.
Aktuell besteht er nur aus einer Kurzbeschreibung sowie einer
Linksammlung zu den verschiedenen Versionen mit Changelog. Zu einer
ausführlichen Beschreibung hatte ich bisher noch keine Lust. Vielleicht
findet sich ja dafür auch noch jemand ;)
Was vielleicht auch noch sinn macht: Alle bekannten Pinbelegungen
(Display <-> Controller) dokumentieren.
Fürs erste gibts hier mal den Link zum Artikel
http://www.mikrocontroller.net/articles/Grafikf%C3%A4higer_LCD_Controller_f%C3%BCr_320x240_LCD_mit_8_Graustufen
Vielleicht könnte ja ein Mod den Artikel im ersten Beitrag hier im
Thread verlinken? Benedikt ist hier leider nicht mehr aktiv (hab ihn
jedenfalls lang nicht mehr gesehen), kann das also nicht selbst machen.
Sebastian
Vielen Dank!
werde natürlich auch meinen betrag dazu leisten wenn ich die Geschichte
mal aufbaue. Das kann natürlich auch noch ein wenig dauern. Aber ein
Anfang ist ja schonmal da :-) Da kann man auf jeden Fall mit arbeiten!
Gruß
Du meinst in dem Wiki-artikel? Na klar! Ich kenne mich ohnehin besser
mit dem Softwareteil aus. Werde also auch im Artikel vor allem was zur
Software schreiben. Aber auch alle, die was zur Software zu sagen haben
sind immer gerne gesehen. Ich wollte mit der aktuellen Form nur mal
einen Anfang schaffen.
Sebastian
Achso! Hab ich gemacht.
Neue Inhaltspunkte kannst du setzen, indem du, wenn der Artikel offen
ist, links im Bereich "Dieser Artikel" auf "Bearbeiten" gehst. Dann hast
du den ganzen Artikel im Editor und kannst auch neue Überschriften
erstellen.
Sebastian
Achja,
Danke!
Noch eine Frage: Wir gehen teilweise mit fremden Eigentum um.
Ich denke, ich sollte Benedikt informieren, was wir vor haben.
Wenn er nicht schon mitliest.
Wigbert
Ja, über das Thema hab ich auch schon nachgedacht. Wäre wohl sinnvoll,
Benedikt zumindest noch als Urheber auf der Wiki-Seite zu nennen.
Ich denke aber, solange der Artikel nur eine Zusammenfassung des
Threads/Linksammlung auf Beiträge darstellt ist das (rechtlich)
unkritisch. Der Artikel darf halt nicht so ausschaun, als hätten wir den
Controller entwickelt.
Wenn du Kontakt zu ihm hast wäre es sicher nicht verkehrt, ihn darauf
aufmerksam zu machen. Ich hab leider seit 2 Jahren nichts mehr von ihm
gelesen.
Sebastian
Ich habe die Schaltung nachgebaut, beim Display aber ein Problem: es
sind Streifen drauf! (siehe Anhang)
Display ist das Wintek WD-H3224V, als SRAM ist nen Cypress CY7C199D
verbaut.
Durchgemessen hab ich schon alles, konnte aber noch nichts finden, was
den Fehler begründen könnte. Verbindungen kommen alle am Display an.
Hat wer ne Idee, woran das liegen könnte und wie man das Problem lösen
könnte?
Die Ansteuerung scheint soweit eigentlich zu passen, sonst wäre das
eigentliche Bild nicht so ungestört. Nur beim M/AC signal könnte ich mir
vorstellen, dass was schief läuft. Hoffe du hast den Schaltplan nicht
aus dem Eröffnungspost genommen, da ist nämlich genau in der Ecke ein
Fehler drin.
Ändern sich die schlieren, wenn sich der Bildinhalt ändert?
@Wigbert
Den link zum Artikel in jedem Beitrag mitzuposten ist sicher nicht
schlecht. Auf Dauer wärs aber geschickter, wenn ein Moderator oder
Benedikt selbst den Link im Eröffnungspost reineditiert.
Sebastian
http://www.mikrocontroller.net/articles/Grafikf%C3%A4higer_LCD_Controller_f%C3%BCr_320x240_LCD_mit_8_Graustufen
Sebastian ... schrieb:> Die Ansteuerung scheint soweit eigentlich zu passen, sonst wäre das> eigentliche Bild nicht so ungestört. Nur beim M/AC signal könnte ich mir> vorstellen, dass was schief läuft. Hoffe du hast den Schaltplan nicht> aus dem Eröffnungspost genommen, da ist nämlich genau in der Ecke ein> Fehler drin.
Dochdoch, genau den hab ich verwendet. Sehe ich das richtig, dass der
Fehler cder ist, dass der eine FF statt auf LP Load auf FLM Frame liegt?
> Ändern sich die schlieren, wenn sich der Bildinhalt ändert?
Hab ich noch nicht getestet, erst mal wollte ich die Schaltung zum
laufen bringen, bevor ich anfange, da was drauf zu schreiben.
Es sind drei Fehler:
M/AC und FLM/FRAME sind falsch benannt (heißen in der falschen Version
FLM/AC und M/FRAME), könnte also sein, dass du die falsch angeschlossen
hast.
Der 74HC157 muss an den Ausgang Q des einen 74HC74 Gatters, nicht an
Q_nicht, wie im ersten plan gezeichnet.
Außerdem wird das andere Gatter des 74HC74 nicht von LP/Load gespeist
sondern von FLM/FRAME.
Wenn ich mir das so anschau, kannst du eigentlich nicht nach dem ersten
Schaltplan gebaut haben, sonst wäre noch mehr verkehrt. Entweder hast du
also doch einen neueren Plan genommen, oder beim nachbaun einen "fehler"
gemacht.
Prüf die ecke auf Jeden Fall nochmal durch. Denke dass der Fehler da
irgendwo liegt.
Die Frage, ob die Fehler sich mit dem Bildinhalt ändern hab ich gestellt
weil, wenns sich ändert, ists wahrscheinlich deine Hardware. Wenns sich
nicht ändert ist ehr das Display hinüber.
Sebastian
http://www.mikrocontroller.net/articles/Grafikf%C3%A4higer_LCD_Controller_f%C3%BCr_320x240_LCD_mit_8_Graustufen
Sebastian ... schrieb:> M/AC und FLM/FRAME sind falsch benannt (heißen in der falschen Version> FLM/AC und M/FRAME), könnte also sein, dass du die falsch angeschlossen> hast.
In unserem Schaltplan heißen die wirklich FLM AC und M FRAME - da das
Datenblatt des Displays die Pins aber nur als FLM und M angibt, wird das
wohl keinen Einfluss gehabt haben.
> Der 74HC157 muss an den Ausgang Q des einen 74HC74 Gatters, nicht an> Q_nicht, wie im ersten plan gezeichnet.
Faszinierenderweise ist bei uns im Schaltplan der $A$/B-Pin auch an Q
und nicht an Qnicht angeschlossen. Also schon richtig angeschlossen.
> Außerdem wird das andere Gatter des 74HC74 nicht von LP/Load gespeist> sondern von FLM/FRAME.
Genau das war der Fehler. Nach dem Auftrennen der Leiterbahn auf der LP
und einbringen eines Drahtes auf FLM ist das Display streifenfrei.
> Wenn ich mir das so anschau, kannst du eigentlich nicht nach dem ersten> Schaltplan gebaut haben, sonst wäre noch mehr verkehrt. Entweder hast du> also doch einen neueren Plan genommen, oder beim nachbaun einen "fehler"> gemacht.
Welchen Plan ich da genau genommen haben, kann ich da jetzt auch nimmer
sagen. Aber wird wahrscheinlich wirklich der erste gewesen sein und ich
habe aus versehen den einen FF "falsch" - und somit richtig -
angeschlossen.
> Prüf die ecke auf Jeden Fall nochmal durch. Denke dass der Fehler da> irgendwo liegt.
Jetzt läufts ja zum Glück. Auch wenn die Graustufen nicht ganz so
intensiv rüberkommen, ists immerhin nutzbar.
Nur die Kontrastregelung ist unter den Tisch gefallen - ich brauche für
das Display nämlich +24V und hab entsprechend einen einfachen
Stepup-Wandler eingebracht, der arbeitet wunderbar, so lange ich über
nen Poti einen Teil der Kontrastspannung auf den CINV-Pin führe, aber
wenn ich wie im Schaltplan beschrieben das PWM-Signal mit reinmixe, geht
das ding auf 5V runter. aber das ist ja denk ich mal nicht so wichtig.
hallo,
ich versuche schon seit tagen eine andere Schriftart 12x16 einzubinden
aber leider werden mir die zeichen nicht richtig dargestellt.
Die Schriftarten habe ich von hier
Beitrag "LCD Schriftarten ( Fonts in veschiedenen Größen )"
vielleicht kann mir einer weiterhelfen.
mfg
Es sollte eigentlich angezeigt werden;
57600 Kbs Baud
8 colour mode by Sebastian
Anbei noch 2 fotos
Schriften bis 8x14 werden korrekt angezeigt aber alles was Grösser ist
kommt nur Pixelsalat raus.
mfg
Ehrlich gesagt hab ich immernoch nicht genau in deinen Code geschaut
(einfach keine Zeit...), aber kanns sein, dass du den Code, der den Text
zeichnet, nicht angepasst hast? Das müssten eigentlich größere
Code-änderungen sein. Jedenfalls, wenn man Text mit einer Breite
ungleich 8 pixel anzeigen will. Würde jedenfalls zu deinem Fehlerbild
passen.
Sebastian
Hi,
bin ebenfalls daran diesen Controller nachzubauen. Leider bekomme ich
noch nicht einmal ein Bild aufs Display. Nutze die LP von Wigbert und
ein GLCD Wintek wd-h3224.
Nun bin ich mir nicht sicher, ob meine Fuse vom ATmega stimmen (siehe
Anhang mit PonyProg). Weiter bin ich mir nicht sicher, ob das Datenblatt
von pollin zu dem Display stimmt.
Könnte mir jemand dabei mal helfen....
Danke & Gruß MAT
@MAT
die Fuses schauen eigentlich gut aus. Hast du das Display richtig
angeschlossen? Keine Kurzschlüsse am Displayanschluss? Liegen alle
Spannungen richtig an? Kontrastspannung?
@Julian
Soweit ich das gesehen habe, hast du wirklich nichts am Code geändert.
So kann das nicht funktionieren. Ehrlich gesagt wurnderts mich gerade,
dass es überhaupt mit anderen Fonts läuft.
Das Problem ist, dass der Code ziemlich auf 8 Pixel breite Buchstaben
ausgelegt ist. Da sind tiefgreifendere Änderungen nötig, wenn du einen
breiteren Font verwenden willst. Am einfachsten wäre wohl noch ein 16
Pixel breiter, aber auch hier sind definitiv Anpassungen am Code nötig.
Das ist alles machbar und von der Rechenleistung her kein Problem (auch
andere Größen als 16Px), aber man muss eben den Code (lcd_writechar in
der lcdcon.S) entsprechend ändern.
Viele Grüße,
Sebastian
Nein, dafür reicht die Rechenleistung des AVR nicht mehr aus. Die
nötigen Datenraten sind für Farbe einfach viel zu hoch. Nimm einen
displaycontroller der dafür gemacht wurde. Epson stellt sowas zum
beispiel her. Einige ARMs haben sowas auch integriert. Und selbst mit
extra displaycontroller wäre zu fragen, ob der AVR wirklich genug
leistung hat, die Bildinhalte in vernünftiger Zeit zu generieren. Aber
da kommts dann einfach auf die Anwendung an.
Gruß,
Sebastian
Reines bauchgefühl, nicht durchgerechnet: Mit nem Pic24 / Pic33 könnte
man das display auch zum laufen bringen.
Aber sowohl der Pic als auch der Propeller sind wenig sinnvoll, wenn du
eigentlich auf AVRs unterwegs bist. Ein fertiger Displaycontroller
dürfte kaum mehr kosten, der Aufwand, den du treiben musst ist aber
deutlich geringer.
Sebastian
Das ist echt ne super Anleitung, will mir auch sonen Controller
nachbauen!
Ich Frage mich ob es von der Leistung her einen großen Unterschied
macht, diesen Controller hier (mit AVR) zu nehmen oder so einen SED oder
S1D oder wie auch immer. Bei dem SED/S1D steht im Datenblatt was von 3
Layer usw...
Also wie sieht es bei dem selbstbau hier aus? Schafft der noch was an
Grafikfunktionen oder ist der mit Textausgabe schon ausgelastet?
Zu meinem Vorhaben: Es sollen auf einem 320x240 LCD (wintek bei Pollin
4,95€) alle möglichen Messwerte eines Motors angezeigt werden. Soweit
kein Problem, jedoch wollte ich schon ein paar grafische effekte drinne
haben, zB habe ich für ein 128x64 mit KS0108 eine Funktion geschrieben,
die ein neues Bild (Menü zB) von der Seite ins Display "reinschiebt",
also wie ein slide effekt auf touchscreen handys.
Ist sowas mit dem eigenbau controller möglich? Oder überhaupt mit dem
SED(1335?)?
MfG Waldemar
Das hängt stark von den effekten ab. Ich denke als worst case kannst du
die leistung beim bloßen bilder anzeigen sehen. Die müsstest du halt
gegebenenfalls vorberechnen. Mit vollbildern schafft die letzte version
von Benedikt (wenn ich mich recht erinnere) etwa 3fps. Bei kleineren
Bildern entsprechend mehr.
Wenn du die Grafikfunktionen nutzt kanns deutlich schneller gehen, aber
auch langsamer. Das hängt stark von den effekten ab und davon, wie
geschickt du es programmierst.
Gerade wenn es nur darum geht, grafikelemente im Bild zu verschieben,
wäre es sicher hilfreich, den vorhandenen Code um BitBlt-funktionen zu
erweitern. Also zum beispiel, die möglichkeit, bildbereiche zu kopieren.
Das könnte dann durchaus relativ performant laufen.
Zu den Epson-controllern kann ich nicht so viel sagen, weil ich nie
einen selbst angesteuert habe. Allerdings würde es mich stark wundern,
wenn die nicht schneller wären, als der hier vorgestellte AVR. Außerdem
kriegt man den sicher auch mit einer 2-layer platine zum laufen (3 layer
gibts garnicht, wenn dann 4). Bei single-layer platinen könnte es schwer
fallen, das ganze zu entflechten.
Sebastian
http://www.mikrocontroller.net/articles/Grafikf%C3%A4higer_LCD_Controller_f%C3%BCr_320x240_LCD_mit_8_Graustufen
Mit den Layern meinte ich eigentlich "Bild-layer", ich glaube damit ist
dann gemeint dass mehrere Bilder gleichzeitig im Ram sind aber nur eines
davon angezeigt wird, bzw man dann unter denen verschiedene Funktionen
ausführen kann.
Ich habe mir auch schon gedacht dass ein "richtiger" LCD Controller
leistungsfähiger ist, aber mich interessiert halt wie leistungsfähig und
ob es sich für mich lohnt eine smd platine zu "entwickeln" oder ob ich
mir das auch sparen kann.
Ich denke ich probiere es erstmal mit dem Bausatz hier, ist ja
eigentlich ne schnelle und günstige geschichte und wenn mir das zu
langsam ist versuch ich mich am Epson Controller.
Habe ich eigentlich einen großen Nutzen wenn ich einen größeren SRAM
dranhänge? Mal davon abgesehen dass ich mehr Adressleitungen brauche,
könnte man doch zB Menüs und Untermenüs schon vorher in den RAM laden
und bräuchte nur noch "umzuschalten" anstatt den ganzen Bildinhalt erst
in den RAM zu laden. Da ich eh nur S/W nutzen wollte wären das bei 32Kx8
ja schon 3 Vollbilder und wenn ich bei Reichelt gucke, dann gibts da
auch 512Kx8 dann wären das schon 16 Bilder, damit könnte man dann auch
einiges anstellen und viel schnellere Effekte erzeugen denke ich...
MfG Waldemar
Hi,
wie damals die ersten Pollin-LCDs aufgekommen sind,
dachten wir ein AVR einzusetzten der über Uart Daten empfängt
und übersichtliche Einstellungen beinhaltet.
Es ist als kostengünstiges Gerät gedacht um irgendwelche
Visualisierungen (Grafik) darstellen zu können.
Beitrag "Re: Grafikfähiger LCD Controller für 320x240 LCD mit 4 Graustufen"
Wer mehr will muss sicher auch mehr für tun.
Ich habe ein Board zu laufen mit ein 128x8K S-Ram, allerding 15ns.
Dort kann ich natürlich mehrere Bilder ablegen, und kopieren.
Da wäre sogar S-Ram und Platine vorrätig.
Das sollte eigentlich der Nachfolger werden, aber wir haben
was Besseres als Bausatz in Vorbereitung.
Nun ist ehrlich das Wintek mit rosa Hintergrund einer der wenigen
GLCDs die mich NICHT interessieren.
Wenn du nur kleine Bildchen bei Deinem Projekt mit einfliessen
lassen willst, ist der Bausatz GLCD-32K durchaus richtig.
Sollen da Bilder laufen lernen wohl kaum.
Wigbert
Was habt ihr denn noch besseres als Bausatz in Planung ? bzw wie lange
wird es dauern bis der Bausatz fertig ist (bzw man erste
Veröffentlichungen sehen darf)?
Wie benutzt du denn 128kx8 als Sram, ich habe vorhin in die Datenblätter
geguckt und gesehen dass bei 64k externem sram ende ist, oder machst du
das dann in software ?
MfG Waldemar
Die SW ist bei 128K schon weiterentwickelt, da werden dann weitere
Pins zugeschaltet. Kopierfunktion, im Hintergrund Bild schreiben
und dann irgendwann aufs GLCD kopieren.
Solche SW kann man dann natürlich nicht
mehr ins Netz posaunen.
Ich hatte auch schon ein 512K Bausatz
in Vorbereitung, aber wir wollten dann
doch was Moderneres versuchen.
Das GLCD 32K wird, da grösstenteils in Dip, bleiben,
dazu kommt dann, wenn alles klappt im Herbst was Leistungsfähiges.
Wigbert
Aufgrund des Hardware-aufbaus lässt sich in diesem Projekt sogar nur
32kByte SRAM direkt ansteuern. Das lässt sich auch nicht ändern, ohne
das projekt komplett neu aufzurollen. Für mehr muss man dann mit GPIOs
die restlichen Adressleitungen in Software ansteuern.
Sebastian
Sebastian ... schrieb:> @Julian>> Soweit ich das gesehen habe, hast du wirklich nichts am Code geändert.> So kann das nicht funktionieren. Ehrlich gesagt wurnderts mich gerade,> dass es überhaupt mit anderen Fonts läuft.> Das Problem ist, dass der Code ziemlich auf 8 Pixel breite Buchstaben> ausgelegt ist. Da sind tiefgreifendere Änderungen nötig, wenn du einen> breiteren Font verwenden willst. Am einfachsten wäre wohl noch ein 16> Pixel breiter, aber auch hier sind definitiv Anpassungen am Code nötig.> Das ist alles machbar und von der Rechenleistung her kein Problem (auch> andere Größen als 16Px), aber man muss eben den Code (lcd_writechar in> der lcdcon.S) entsprechend ändern.
Hallo Sebastian,
Vielen Dank für ihre Antwort,
leider reichen meine Kenntnisse nicht aus um in der lcdcon.S das soweit
zu ändern für eine andere Schriftart deshalb war meine frage ob mir den
jemand weiterhelfen kann
mfg
erstmal danke für deine Antwort,
ich habe mal ein paar Werte in der Lcdcon.s bei lcd_writechar geändert
aber leider ohne erfolg.
Getest hab ichs mit der 16x24 Schriftart versucht.
mfg
Hi Sebastian,
ich habe deinen Rat mal versucht umzusetzen aber leider ohne erfolg
bekomme die die schriftart leider nicht zum laufen.
vielleicht könntest du mir nochmal kurz einen Tipp geben was ich in der
routine änder muss.
Es wird doch durch,
ldi r21, 52 //für 16x26
lsl r24
mov XH, r22
subi XH, (-(YMin))
mov r25, r16
and r25, r18 // Bits die auf jedenfall gesetzt werden
or r18, r16 // Bits die auf nie gesetzt werden
wchar:
lpm r20, Z+
mov r22, r20
mov XL, r24
sbrc r16, 7 // Wenn Hintergrund an: Bits invertieren (eventuell
ldi r21, 52 bestimmt wieviele zeichen in der tabelle pro zeile sind
{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0
x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x0
0,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}, // 0x00
lpm r20, Z+ holt dann byte für byte aus der tabelle bis die schleife
zuende ist.
ich bin kein profi in der sache
daher meine frage wie ich das umändern muss damit die zeichen korrekt
angezeigt werden.
mfg
lcd_writechar: // Y: r22
cpi r24, (XSIZEV/8) // C: r20
brsh exitchar // TC: r18
cpi r22, lo8(YSIZE) // BC: r16
brsh exitchar
mov ZL, r20
ldi ZH, 52 //für 16x26
mul ZL, ZH //Offset addieren
movw ZL, r0
subi ZL, lo8(-(font))
sbci ZH, hi8(-(font))
ldi r21, 52 //für 16x26
lsl r24
mov XH, r22
subi XH, (-(YMin))
mov r25, r16
and r25, r18 // Bits die auf jedenfall gesetzt werden
or r18, r16 // Bits die auf nie gesetzt werden
wchar:
lpm r20, Z+
mov r22, r20
mov XL, r24
sbrc r16, 7 // Wenn Hintergrund an: Bits invertieren (eventuell
Hallo julian,
> ldi r21, 52 bestimmt wieviele zeichen in der tabelle pro zeile sind
nein, dort kommt die Fonthöhe rein
Versuche es mal mit der angehängten lcd_writechar.txt
Ist ungetestet, sollte aber für 16x26 Font funktionieren.
Weiterhin musst du die lcd_string Routine ändern.
wie meinst du das halber Buchstabe ?
Eventuell ist dein Font anders aufgebaut.
Die Routine schreibt von oben nach unten jeweils 2 Byte nebeneinander.
z.B. das "+" Zeichen
(Bit7-0) (Bit7-0)
1.Byte 00000000 00000000
3.Byte 0000000* *0000000
5.Byte 0000000* *0000000
7.Byte 000***** *****000
9.Byte 000***** *****000
11.Byte 0000000* *0000000
13.Byte 0000000* *0000000
...
Sieh dir mal deinen Font an, wie der aufgebaut ist.
Lucky schrieb:> wie meinst du das halber Buchstabe ?
es wird immer nur die erste hälfte vom Buchstaben geschrieben
> Eventuell ist dein Font anders aufgebaut.
Der Font ist der gleiche wie der 8x12 nur halt grösser.
>> Die Routine schreibt von oben nach unten jeweils 2 Byte nebeneinander.> z.B. das "+" Zeichen> (Bit7-0) (Bit7-0)> 1.Byte 00000000 00000000> 3.Byte 0000000* *0000000> 5.Byte 0000000* *0000000> 7.Byte 000***** *****000> 9.Byte 000***** *****000> 11.Byte 0000000* *0000000> 13.Byte 0000000* *0000000> ...> Sieh dir mal deinen Font an, wie der aufgebaut ist.
Verstehe ich nicht ganz.
> Der Font ist der gleiche wie der 8x12 nur halt grösser.
Kann ja nicht der gleiche sein.
Der 8x12 hat 12 Byte pro Zeichen und der 16x26 hat 52 Byte pro Zeichen.
Beim 8x12 werden in die erste Zeile 8 Pixel (1Byte) gesetzt.
Darunter das 2.Byte, darunter das 3.Byte ... bis zum 12.Byte.
Also 12 Byte zu je 8 Pixel(Bit) Breite.
>> Sieh dir mal deinen Font an, wie der aufgebaut ist.> Verstehe ich nicht ganz.
Beim 16x26 werden in die erste Zeile 16 Pixel (2Byte) gesetzt.
Darunter das 3.Byte + 4.Byte, darunter das 5.Byte ... bis zum 52.Byte.
Also 26 Byte zu je 16 Pixel(Bit) Breite.
Wegen der jeweils 2 Byte nebeneinander passt ja auch die originale
Routine nicht.
Hallo Sebastian, hallo Wigbert,
wie ich sehe seid Ihr noch immer aktiv in diesem Thema.
Ich habe jetzt nach längerer Abstinenz auch wieder meine alten
Schaltungen ausgegraben um etwas zu realisieren. Mangels anderer LCDs,
aber auch aus Interesse versuche ich dazu das LCD von Pollin, das es
auch heute noch gibt
http://www.pollin.de/shop/dt/MzE1OTc4OTk-/Bauelemente_Bauteile/Aktive_Bauelemente/Displays/Grafikdisplay_320x256.html
mit Graustufen zu betreiben. Mit 4Grau und einem ASM Code ist es mir
auch schon gelungen (siehe Bild), aber jetzt möchte ich den 8Grau Code
mal so nutzen wie er vorliegt. Das Problem dabei ist die Hardware, da
ich einen eigenen M - Takt benötige, der an LP hängt und nicht an Frame.
Ich dachte mit einem Zählerbaustein (74LS163) und einem 3-input AND Gate
zwischen LP und dem 74HC74 könnte ich das realisieren, aber irgendwie
funktioniert das nicht.
Hat jemand Interesse ins Detail zu gehen?
Beste Grüße
Bruno
Ich verstehe noch nicht genau was dein Display braucht und was du
gemacht hast.
Was ich meine zu verstehen: Du hast die hardware leicht modifiziert um
das Display anzusteuern. Mit 4 Graustufen läuft das auch alles, mit 8
nicht.
Ist seltsam. Eigentlich wird die Hardware mit 8 Graustufen nicht anders
bedient als mit 4. Hast du vielleicht sonst noch was geändert? Framerate
hochgestellt? Vielleicht packt dein Display die Framerate dann nicht
mehr.
Was genau geht denn nicht wenn du 8 Graustufen nutzen willst?
Gruß, Sebastian
Hallo Sebastian,
schön daß du dich meldest!
Sebastian ... schrieb:
> Was ich meine zu verstehen: Du hast die hardware leicht modifiziert um> das Display anzusteuern. Mit 4 Graustufen läuft das auch alles, mit 8> nicht.
Nicht ganz. Für die 4Grau habe ich nicht die Hardware verändert, sondern
die Software. Ich habe mit einem ASM Code einfach die 4 Rechtecke
dargestellt und mit einem freien Pin des Controllers den richtigen M -
Takt eingestellt, der wie oben schon gesagt nicht an Frame sondern an LP
hängen muß.
> Was genau geht denn nicht wenn du 8 Graustufen nutzen willst?
Wenn ich nun den Originalcode von 8 Grau einsetze, muß ich den M - Takt
aber durch die Hardware erzeugen. Im Ursprungsschaltplan erfolgt das
durch Frame und einem 74HC74. Ähnlich möchte ich das jetzt auch
realisieren, aber mit einem Zählerbaustein (74LS163) und einem 3-Input
AND Gate zwischen LP und dem 74HC74. Im Moment scheitert das aber daran,
daß bei Verbindung von LP und Clock des Zählers, LP verändert wird.
Genau gesagt, LP bekommt eine Grundspannung von ca. 2-3V und darüber
liegen dann die Spitzen. Damit bekomme ich natürlich kein Bild mehr.
Warum das so ist, konnte ich noch nicht herausfinden.
Ich hoffe, die Schilderung des Problems ist einigermaßen klar.
Bruno
Nachtrag:
Ich meine, ich habe den Fehler gefunden. Der Zähler 74LS163 den ich
nutze hat negativ aktiv Eingänge. Wenn ich das richtig interpretiere (so
zeigt es auch die Messung) ist CLK damit standardmäßig high, was
natürlich bei LP Probleme verursacht.
Sehe ich das so richtig?
Bruno M. schrieb:
>Sehe ich das so richtig?
ich vermute, dass sie da richjtig liegen. An ihrer stelle würde ich
einfach mal nen inverter (z.b. 74*04) dazwischenhängen und gucken ob 8
Graustufen korrekt darstellbar sind.
MfG,
Hakon Hennig
Laut Datenblatt ist bei deinem Zähler Clear und Load active low, der
rest active high. Beim Takt musst du dir die Flanken anschauen. Dein IC
zählt immer bei steigender Flanke weiter.
Ansonsten hatte ich noch keine zeit, deine Pläne nachzuvollziehen.
Schreib doch, obs jetzt funktioniert.
Gruß, Sebastian
Hakon Hennig schrieb:
>> ich vermute, dass sie da richjtig liegen. An ihrer stelle würde ich> einfach mal nen inverter (z.b. 74*04) dazwischenhängen und gucken ob 8> Graustufen korrekt darstellbar sind.>
Der Tip war natürlich richtig und das LP Problem ist damit gelöst!
Trotzdem habe ich noch viele Versuche gebraucht um das Bild wirklich
darstellen zu können.
Aus mir unerfindlichen Gründen klappte es mit dem bereits auf dem Board
befindlichen Flip-Flop (2. Seite) überhaupt nicht. Auch das Auswechseln
brachte nichts. Dann habe ich ein zweites außen drangehängt und
plötzlich bekam ich ein klares Bild obwohl auch hier das Signal nicht
einwandfrei ist.
Wie auf den Bildern zu sehen ist der Takt vom Timer relativ gut. Im
Flip-Flop wird dann aber immer noch ein Zwischentakt eingefügt.
Hat jemand eine Erklärung dafür????
Hallo Bruno,
offensichtlich hast du die Belegung des 320x256-Displays schon
herausgefunden. Könntest du diese Daten - und weitere, wie
Betriebsspannungen - hier veröffentlichen?
Harald
Harald P. schrieb:
> offensichtlich hast du die Belegung des 320x256-Displays schon> herausgefunden. Könntest du diese Daten - und weitere, wie> Betriebsspannungen - hier veröffentlichen?
Siehe hier:
Beitrag "Pollin LCD ohne Datenblatt"
> Aus mir unerfindlichen Gründen klappte es mit dem bereits auf dem Board> befindlichen Flip-Flop (2. Seite) überhaupt nicht. Auch das Auswechseln> brachte nichts. Dann habe ich ein zweites außen drangehängt und> plötzlich bekam ich ein klares Bild obwohl auch hier das Signal nicht> einwandfrei ist.> Wie auf den Bildern zu sehen ist der Takt vom Timer relativ gut. Im> Flip-Flop wird dann aber immer noch ein Zwischentakt eingefügt.
Ich habe das Problem gelöst!
Ich mußte nur das bisher benutzte 74F74 gegen ein normales 7474
austauschen und schon hatte ich einen super M Takt.
Das 74F74 ist offensichtlich zu schnell und damit zu empfindlich
(zumindest für meinen Schaltungsaufbau auf Lochstreifenplatine).
Hallo Bruno,
ich habe jetzt auf dem Nachfolger dieses Grafikcontrollers nun
auch das Display testweise eingerichtet. Ich würde gerne etwas mit
Dir spielen (testen)
Kurzum: Der neue Grafikcontroller auf einen Pic basierend wird
über USB oder RS232 von einer Software aus eingestellt. Die
Lieblings GLCDs sind schon voreingestellt.
Schon mit integriert sind mehrehre Schriftgrössen, einige Seiten
und und und......
Mehr wird erstmal in der Testphase nicht verraten.
Wigbert
Hallo Wigbert,
Wigbert Picht-dl1atw schrieb:
> Kurzum: Der neue Grafikcontroller auf einen Pic basierend wird> über USB oder RS232 von einer Software aus eingestellt. Die> Lieblings GLCDs sind schon voreingestellt.> Schon mit integriert sind mehrehre Schriftgrössen, einige Seiten> und und und......>
Das klingt natürlich super, aber warum bist Du zum PIC Fan mutiert? Das
wäre doch sicherlich auch mit einem ATMega zu machen.
Beste Grüße Bruno
Hallo Sebastian,
Ich versuche z.Zt. das Programm für einen anderen Controller anzupassen.
Dabei bin ich über die Timereinstellungen gestolpert und komme trotz
intensivem Studium nicht ganz klar was da abläuft. Bis 4Grau war noch
alles in Ordnung, aber beim HWLP Modus habe ich Verständnisprobleme.
OCR1AL=10; // Output Compare Wert für 1A
OCR1BL=RELOAD/2; // OCW für 1B = 625/2 = 312
ICR1=RELOAD-1; // Input Compare Register = 625-1 = 624
TCCR1A=(1<<COM1A1)|(1<<COM1B1)|(1<<COM1B0)|(1<<WGM11); //)COM1n1:0
bestimmt Output Compare Modus normal oder invertiert
TCCR1B=1<<WGM12)|1<<WGM13)|1; //)Fast PWM (WGM11-13 = 111) | 1=kein
prescaling
TIMSK|=(1<<TOIE1); // Interrupt
Willst Du mir auf die Sprünge helfen?
Bruno
Hallo Wigbert,
16 Graustufen klingt sehr intressant.
Ich bin derzeit dabei meinen Controller auch weiter zu entwickeln,
geplannt hatte ich zwar erst mal nur auf 8 Graustufen zu gehen aber 16
wär vom speicher und der verfügbaren Rechenleistung her auch möglich.
Es wird aber nur RS232 als schnittstelle geben.
Falls du Interesse hast würde ich gerne das Kommunikations Protokoll mit
dir abgleichen.
Gruß Alexej
Du fragst sachen...
mal das datenblatt rauskramen...
also, der Timer zählt immer hoch, bis RELOAD-1 und fängt dann wieder bei
0 an.
Wird RELOAD-1 erreicht, dann wird der overflow-interrupt (das müsste der
sein, der die Daten aufs display schreibt) ausgelöst.
OC1A wird gelöscht, wenn der Counter den Wert 10 erreicht und gesetzt,
wenn der Timer überläuft. Wenn ich mich recht erinnere, erzeugt das den
Frame-impuls fürs Display.
OC1B wird gesetzt, wenn der Counter den Wert RELOAD/2 erreicht und
gelöscht, wenn der Timer überläuft. Wenn ich micht recht erinnere, war
das für die Kontrasterzeugung.
Hoffe, das stimmt alles. War jetzt nur Datenblatt+erinnerung. Den
schaltplan hab ich nicht mehr angeschaut.
Gruß, Sebastian
Danke für die Info. Das meiste hatte ich auch so aus dem Datenblatt
gelesen. Mein Hauptproblem war, daß der Timer im Studio4 falsch
angezeigt wird. Dort zählt er von Top wieder runter, statt auf 0 zu
springen. Auch der obere Wert stimmt nicht.
Sebastian ... schrieb:
> also, der Timer zählt immer hoch, bis RELOAD-1 und fängt dann wieder bei> 0 an.> Wird RELOAD-1 erreicht, dann wird der overflow-interrupt (das müsste der> sein, der die Daten aufs display schreibt) ausgelöst.
Von den WGM Bits wird vorgegeben, daß der Top-Wert durch ICR1 bestimmt
wird und der Zähler dann wieder bei 0 beginnt.
> OC1A wird gelöscht, wenn der Counter den Wert 10 erreicht und gesetzt,> wenn der Timer überläuft. Wenn ich mich recht erinnere, erzeugt das den> Frame-impuls fürs Display.
Ich meine das ist nicht Frame, sondern LP.
Gruß Bruno
Sowas in der Art?
Platinen habe ich noch liegen. Bei Interesse, einfach eine PN.
Hier mal im Inversmodus, da mir das GLCD etwas flau vorkommt.
Schönen Sonntag.
Wigbert
Wigbert Picht schrieb:> Bei Interesse, einfach eine PN.
Hallo,
habe Dir eine Pn gesendet.
Schönen Sonntag und einen schönen 2. Advent an alle.
Gruß Ronny
Hab vor einiger Zeit eine von Wigbert bekommen.
Hab aber noch paar Displays hier, deswegen würde ich vielleicht neu
bestellen ;)
Das hier erscheint mir sehr günstig.
10x10cm FR4 Doppelseitig und davon 10 Stück für insgesamt 21,60$ also
17.46€ inclusive Versand.
http://www.elecrow.com/2-layer-10cm-10cm-max-pcb-510pcs-color-free-p-328.html
Wäre am Rand sogar noch Platz für kleine Breakout Boards, Logger oder
sowas halt ;)
Oder aber eben für den eigentlichen uC. Soweit ich mich Erinnere war ja
Benedikts Firmware fix und die Controller Platine wird mit seriellen
Signalen angesteuert.
Also ich sag mal bei nichtmal 2€ pro Platine kann man nix falsch machen.
Dann würde ich sagen, dass ich das am Wochenende bestelle. Ich würde
erstmal zwei behalten, dann sind noch drei zu vergeben :) .
Design gehe ich jetzt mal vom DIP4 aus, richtig?
Porto weiß ich gar nicht. Was kostet das heutzutage? Noch 45c pro Brief
oder haben die das schon wieder angehoben ^^ ?
Sehe grade -->
https://www.deutschepost.de/de/b/brief_postkarte.html
Also doch 1,45€. China meint 50Gramm pro Platine. Der 90c Brief geht nur
bis 50Gramm. Also wäre der günstigste der Kompaktbrief. Wenn ich das
jetzt richtig gedeutet habe.
Im Design, der Displayanschluß (Die kleineren diagonalversetzten
Durchkontaktierungen). Waren die so gewünscht? Sonst würde ich das gegen
eine normale Buchse austauschen.
Hallo,
also von mir aus kannst das auch alles etwas anpassen falls Du noch
einen Spannungsregler für 3,3 / 300 bis 500 mA mit rauf bekommst könnte
ich gut gebrauchen.
Gruß Ronny
Das wäre die Schaltung meiner Platine. Ich hatte auch was mit einem
grösseren S-Ram schon in der Schublade, aber das reichte nicht.
So entstand ein PIC basierender Grafikcontroller, der eine Menge mehr
kann. Aber die Zeit.....
Ich würde auf jeden Fall auch eine positive Spannungserzeugung bis ca.
25V vorsehen.
Schönen 3. Advent.
MfG
Wigbert
Sind die Platinen denn jetzt smd oder bedrahtet? smd habe ich nix hier,
könnte nur bedrahtet verarbeiten. UNd vor allem der Source Code für den
AVR muss da sein. Ich habe leider nichts mehr durch den Daten Unfall.
Und auch nix für AVRs, außer die Arduino IDE und einen AVR Brenner.
2 Platinen habe ich auch noch irgendwo von der Sammelbestellung damals
aber bloss wo..... tja?
Wo kriegt mann denn noch Displays her? Sind das die von Pollin?
Könnte mir ggf. jemand den Source für 9600 baud und 57600 kompilieren?
Guten Abend,
also eigentlich handelt es sich um THT Prozessoer DIP40.
Ben wolte es noch etwas anpassen und dann die PCBs bestellen.
So war meine letzte Info dazu, habe 5 Stück bei Ben davon bestellt.
Der Preis soll um 2 Euro für ein PCB plus Versand betragen.
Das mit dem Source Code wūrde mich auch noch interessieren wo man die
Aktuellste Version davon findet oder wer das noch alles gesichert hat
und es bereit stellen kõnnte.
Gruß Ronny
Christian J. schrieb:> [Dummy Mail für Threaad beobachten]
Das geht auch einfach indem man auf "Thread beobachten" direkt über
"Antwort schreiben" klickt...
Ich hab jetzt doch nochmal Wigbert ne Nachricht geschrieben, ob er mir
die *.brd Datei zukommen lässt. Finde sein Design irgendwie besser. Auch
mit der Buchse für ISP.
Falls er sie nicht rausgeben kann, bin ich weiterhin selber am routen.
Kann nicht mehr lange dauern bis zur Bestellung ;)
Christian J. schrieb:> Wo kriegt mann denn noch Displays her? Sind das die von Pollin?
Ich habe diese hier:
http://www.pollin.de/shop/dt/NDgyOTc4OTk-/Bauelemente_Bauteile/Aktive_Bauelemente/Displays/LCD_Modul_LCM_5430_E.html
Ist aber schon fast zu groß. Hätte auch Interesse an links für
kompatible kleinere Displays.
> Könnte mir ggf. jemand den Source für 9600 baud und 57600 kompilieren?
Im Anhang ist die, die ich benutze. Fertig kompiliert für Baudrate 19K2.
Fusebits siehe PDF. Mehr hab ich leider auch nicht. Falls jemand ne
*.hex für 57K6 hat würde ich die auch nehmen ;)
Schlechter Zeitpunkt vor den Feiertagen.
Ich habe mal ein Prototyp mit einem S-Ram AS7C1025 gebaut.
Also eine 128K Platine. Damit würde das LCM5430 sich gut ansteuern
lassen.
Irgendwo habe ich sicher diese Rams.
Ich schau mal nach , was ich finde.
MfG
Wigbert
Hallo,
ansonsten schau mal in der Bucht nach SP14Q002 gibt es auch als
blau/weiß.
Aber ob Du mit <5 hin kommst weiß ich nicht sind aber gute Displays.
Hatte für meine s/w 20 Euro gezahlt vor ca. 1 Jahr.
Gruß Ronny
S-Rams sind vorhanden. Ich muss mal meine Boarddatei auf Richtigkeit
prüfen
und schicke B.R. was ich finde. Bei Interesse kann B.R. auch
die S-Rams verteilen.
Anbei ein SP14Q002 aus aktuellen Anlass.
MfG
Wigbert
Wigbert Picht schrieb:> Anbei ein SP14Q002 aus aktuellen Anlass.
Sieht gut aus und der Controller auch mit dem Adapter dazu auch.
@ Ben,
ich werde mal nach den Feiertagen schauen habe glaube noch eins über.
Machen wir dann aber über PN.
Gruß Ronny
Ja, der Weihnachtsbaum scheint gelungen zu sein...
Egal, ob die 32K oder die 128K Platinen, Adapter passen.
Ich hatte auch für einige GLCD Varianten was geroutet.
MfG
Wigbert
Wigbert Picht schrieb:> Ich hatte auch für einige GLCD Varianten was geroutet.
Hallo,
das ist Interessant leider fehlt mir dafür die Zeit wo kann man Bilder
oder Infos finden.
Hast auch was für Dual Scan und auch mit Farbe ? Sowas suche ich auch
noch so lange es in THT ist.
Gruß Ronny
Wigbert Picht schrieb:> S-Rams sind vorhanden. Ich muss mal meine Boarddatei auf Richtigkeit> prüfen> und schicke B.R. was ich finde. Bei Interesse kann B.R. auch> die S-Rams verteilen.
Hab grad zum Heißluftstation testen nen alten Drucker
auseinandergenommen.
Unter anderem waren da 10 Stück 8x32k Speicher drin.
Die hier-->
http://pdf1.alldatasheet.com/datasheet-pdf/view/47640/WINBOND/W24257AJ-12.html
Im Displaybetrieb hab ich einen von Wigbert, den hier -->
http://www.issi.com/WW/pdf/61C256AL.pdf
Auf den ersten Blick stimmen Zugriffszeit und Pinout überein. Überseh
ich irgendwas oder soll ichs mal probieren obs mit denen aus dem Drucker
auch funktioniert?
@Wigbert
Hast du schon die *.brd gefunden :) ?
Und wieder hoch damit!
Lebt dieser Benedikt eigentlich noch? Ich brauche die Unterlagen und
Dokus, da ich meine beiden restlichen Platinen noch bestücken möchte,
die ich von der Sammelbestellung 2009 habe. Alles weg seit dem
Datencrash 2013 :-(
@Hobel --> Hab doch weiter oben einiges gepostet. Das sollte mit dem
Schaltplan und der *.brd zum bestücken reichen. Ne Anleitung als PDF ist
auch dabei.
Von Wigbert hab ich leider noch nichts gehört.
Hat jemand ne unbestückte Platine mit seinem Design und kann Vorderseite
und Rückseite einscannen? Dann route ich das nach.
Hallo Christian,
ich verstehe dein Problem nicht ganz. Was Benedikt damals alles erstellt
hat steht doch nach wie vor im Thread zur verfügung. Also auch
Schaltpläne. Bestückungspläne für die Platine von Wigbert hatte Benedikt
vermutlich auch nicht. Dafür sollten auch die irgendwo im Thread zu
finden sein.
Von Benedikt weiß ich leider auch nichts. Irgendwann hat er einfach
nicht mehr gepostet. Es gab dann noch einen Benedikt-Such-Thread. Soweit
ich mich erinner war der aber auch erfolglos.
Viele Grüße,
Sebastian
Hab leider keine Rückmeldung von Wigbert bekommen. Sorry, dass es so
lange dauert mit der Neubestellung der Platinen.
Deswegen nochmal die Frage ;) --->
B. R. schrieb:> Hat jemand ne unbestückte Platine mit Wigberts Design und kann Vorderseite> und Rückseite einscannen? Dann route ich das nach.
So, hab jetzt das Design nochmal nach und umgerouted ;).
Morgen geht die Bestellung raus.
Mal schauen wie lange sie brauchen bis die Platinen in Deutschland sind.
Thomas K. schrieb:> Hallo> @B.R. verkaufst Du auch eine oder zwei von den Platinen, hätte> Interesse.> Gruss> Thomas
Hey Thomas,
falls noch Interesse besteht, würde ich welche nachordern. Hab fünf
Displays rumliegen, für die es noch kein Projekt gibt, aber die Platinen
schonmal hier zu haben kann ja nicht schaden ;). Würde die übrigen fünf
wieder zum Einkaufspreis (Elecrow, Itead, mal sehen was grade günstiger
ist) rausschicken + halt das Brief bzw. Umschlagporto.
Grüße
Habe noch 3 Platinen von der ursprünglichen Bestellung von 2008. Habe
damals sehr viele machen lassen und verschickt.
2 wären noch da, pro Stück nen 10er. Nur ob die Bestückungspläne usw.
noch alles hier ist weiss ich nicht.
>>Von Benedikt weiß ich leider auch nichts.
Erinnert mich an einen anderen Fall ... der Mod war schlichtweg
verunfallt und verstorben, merkt natürlich im Netz keiner, man kennt
sich ja njct.
Thomas K. schrieb:> Hallo Christian> Eine Platine würde ich nehmen. Wie gehen wir vor? Geld Adresse usw.>> Grüße Thomas
Hallo,
es ist eine Platine aus der Version 3. Du musst sie kontrollieren ob es
Masseschlüsse zwischen der großen Fläche und Leiterbahnen gibt. Einige
hatten das, weil der Abstand sehr klein war. Natürlich funktionierten
die, habe das Display mit einem Cortex-4 selbst noch in Gebrauch,
schöner großer Bildschirm, gut für Fliesstext.
Ich gehe mal in den Keller und hole die rauf heute, muss erst danach
suchen. Dann melde ich mich.
Hallo Christian
die Platine ist aber doch für den Atmega8515 oder?
Das mit dem Masseschluss bekomme ich hin Multimeter und Oszi sind
vorhanden.
Eine Anleitung währe natürlich super.
Gruß Thomas
Christian J. schrieb:> habe das Display mit einem Cortex-4 selbst noch in Gebrauch
Gabs da wohl noch ein neues Layout? Kannst du da mal n Foto machen :) ?
Thomas K. schrieb:> die Platine ist aber doch für den Atmega8515 oder?
Also das Layout, dass ich noch von Wigbert hatte, war mit dem 8515.
Leider hat er sich auch bei mir trotz mehrfacher Versuche laaaange nicht
mehr gemeldet. Bin ihm leider noch einen kleinen Betrag schuldig, aber
wie gesagt, bekomme keine Antwort.
Thomas K. schrieb:> Hallo Christian> die Platine ist aber doch für den Atmega8515 oder?> Das mit dem Masseschluss bekomme ich hin Multimeter und Oszi sind> vorhanden.> Eine Anleitung währe natürlich super.> Gruß Thomas
Hallo,
ja, ist sie. Guck mal in dem Thread am Anfang, da sind einige .rar
Pakete wo noch alles drin sein müsste. Auch das Lapout für Eagle. Die
"Bedienung" such ich auch noch, die ist bei mir derzeit nur im Source
Code vorhanden. Ob nach meiner Zeit noch Platinen gemacht wurden weiss
ich nicht. Benedikt hatte mir damals den Atmega zugeschickt da ich keine
eigenen Chips flashen konnte.
Ich guck mal....
Hier sind die Brocken, die ich damals habe machen lassen bei Bilex. Und
auch die Kommandos fanden sich wieder hier.
Ich habe leider keinen lizensierten Eagle mehr und eine Crack Version
möchte ich nicht erzeugen, schon wegen der Viren mit denen diese Cracks
und Seriennummer Generatoren verseucht sind.
Muss gleich mal runter in den Keller, das alles von dem LPC2368 Board
abschrauben, was ich sowieso nie wieder verwende, weil der LPC2368 schon
lange überholt ist, obwohl es ein echt cooler Controller war.
Hier gibt es das aber noch, genau das gleiche Board was ich vor 7 Jahren
gekauft habe, seltsam...
http://www.micro4you.com/store/lpc2368-development-board.html
So.... abstaub.... da sind sie :-) Funzt alles noch, nur die RTC Backup
Batterie ist leer nach 5 Jahren im Keller.
2 kann ich abgeben, die 3.te werde ich mir selbst aufbauen. Ist ja alle
bedrahtet bis auf den FPC Stecker, den habe ich aber auch nicht mehr in
Reserve.
Hallo,
Die "Uhr" sieht sehr interessant aus. Können Sie vll. den source Code
zur Verfügung stellen?
Habe den Treiber als lochraster und draht verhau und hätte gern eine
sinnvolle Aufgabe dafür.
Grüße
Denis K. schrieb:> Die "Uhr" sieht sehr interessant aus. Können Sie vll. den source Code> zur Verfügung stellen?
Ähm... ja, aber das funktioniert auch nur mit genau diesem Board und dem
LPC2368, entwickelt mit Rowley Crossworks. Wofür denn genau den Source
Code, das sind über 15 einzelne Module, teilweise sehr hardwarenah.
Wobei gd_user auf gdriver aufbaut usw.
Hui, das ging fix. Danke schonmal. Ich versuche es mir mal anzusehen und
zu verstehen ;). Vll kann ich es für einen avr portieren, wenn nicht,
habe ich etwas nettes zu lesen gehabt.
Grüße
Hallo,
ich habe dieser Tage mal wieder angefangen mit den Grafik/Text Einheiten
zu Experimentieren. Leider finde ich keine Datenblätter mehr von meinen
Displays. Könnte mir von euch da jemand mit dem Pinout helfen? Es
handelt sich um zwei Displays von WIN-TEK WM-G3224V-1WFWa.
Danke schon mal
Grüße Denis
Thomas K. schrieb:> Hallo> ich suche noch drei Platinen. Hat noch jemand welche zu Verkaufen?> Würd mich sehr freuen......
Alle verkauft, sorry. Du hast doch schon welche, 2 Stück.
Hi
jau, hab aber von der Arbeit drei 640x240 LCD mit 4 Bit bekommen und
wollte noch den großen Controller(640x480) von Benedikt bauen. Hatte
gesehen das die Schaltpläne fast gleich sind, und mit ein wenig
Änderungen das ganze auch mit Deinen Platinen gehen sollte. Ich bekomme
immer wieder mal Displays. Deswegen hätte ich gerne noch eine paar
Platinen gehabt. Wenn nicht....schade.
Thomas