Ich beziehe mich auf die angehängte Anleitung. (4P018-00_03_G2.....)
Die Initialisierung (Thema: Suche Lösungsvorschlag zur Initialisierung
eines Pervasive Displays ) habe ich jetzt erfolgreich? gemeistert,
sodass es mit dem Abschnitt 5 weiter gehen soll.
Speziell geht es um das 2,7" Papier (S. 23)
Einige Fragen: a) Was ist z.B. mit 1 hoch st, 33 hoch rd und 44 hoch th
gemeint?
b) Wie muss (kann) man
Example:
D(263,y) = Black (B) = 11
D(261,y) = White (W)= 10
D(259,y) = Nothing(N) = 00
D(257,y) = Black (B) = 11
1st Data Byte = 11,10,00,11
in eine Befehlsfolge wandeln?
SPI soll in der Art verwendet werden, wie in "Suche Lösungsvorschlag
zur Initialisierung eines Pervasiven Displays" bereits beschrieben.
Hi >Speziell geht es um das 2,7" Papier (S. 23) >Einige Fragen: a) Was ist z.B. mit 1 hoch st, 33 hoch rd und 44 hoch th >gemeint? > b) Wie muss (kann) man >Example: >D(263,y) = Black (B) = 11 >D(261,y) = White (W)= 10 >D(259,y) = Nothing(N) = 00 >D(257,y) = Black (B) = 11 >1st Data Byte = 11,10,00,11 >in eine Befehlsfolge wandeln? Wo steht das genau im Datenblatt? MfG Spess
spess53 schrieb: > Einige Fragen: a) Was ist z.B. mit 1 hoch st, 33 hoch rd und 44 hoch th >>gemeint? "1st, 33rd, 44th" heißt "first, thirtythird, fortyfourth". Sprich: "erstes, dreiunddreißigstes, vierundvierzigstes" (Byte).
wolle g. schrieb: > Einige Fragen: a) Was ist z.B. mit 1 hoch st, 33 hoch rd und 44 hoch th > gemeint? Das der OP seinen Englisch Grundkurs wiederholen muss. Ohne diese Grundlagen ist das Verständnis eines Datenblatts nicht möglich.
Jim M. schrieb: > Das der OP seinen Englisch Grundkurs wiederholen muss. Sehr dünnes Eis... http://www.das-dass.de/
spess53 schrieb: > Wo steht das genau im Datenblatt? elo schrieb: > Seite 29 peinlich, peinlich. Aber elo hat die richtige Seite gefunden. Jim M. schrieb: > Das der OP seinen Englisch Grundkurs wiederholen muss. Ohne diese > Grundlagen ist das Verständnis eines Datenblatts nicht möglich. und nun? Wie muss man denn mit ausreichenden Englischkenntnissen das Beispiel (example) von S. 29 deuten?
Wahrscheinlich bin ich ein weiterer Exot, der sich mit e-paper beschäftigt. Vielleicht hat jemand einen Hinweis oder ein Programmschnipsel, wie man den Abschnitt 5 (ab Seite 25) als Programm schreiben kann. Wie schon gesagt, Initialisierung funktioniert und der Rahmen lässt sich bei mir jetzt auch schon EIN und AUS schalten.
Hallo, also zu S29 du sendest die ersten 33 Byte, jedes Byte enthält die Information von 4 Pixeln (2Bit pro Pixel), in dem Durchlauf werden nur die Informationen für die ungeraden Pixel übertragen. Dann kommen 44Byte Scandaten 2Bit pro Zeile macht 4 Zeilen pro Byte mal 44 = 176 Zeilen, wofür das genau da ist versteh' ich auch nicht auf Anhieb, würde erst mal 44x 0xFF senden. Im Anschluss kommen noch mal 33Byte für die geraden Pixel der Zeile wie oben Codiert. Damit hast du 2Bit pro Pixel, sind 4 Pixel pro Byte mal 66 Byte ergibt deine 276 Pixel in X-Richtung. Bei den 2Bit für ein Pixel hast du die Auswahl zwischen Pixel AN, Pixel AUS und Pixel im vorherigen Zustand belassen. Du sendest über SPI: 0x0A,0x00, 33 Byte Pixeldaten, 44 Byte Scandaten, 33 Byte Pixeldaten und 0x02,0x07 Das ganze machst du für jede Zeile also 176 Mal. Sascha
Danke, das hilft schon etwas weiter. Z. Zt. kann ich erst einmal schöne senkrechte schwarze Striche "zaubern". Sieht ähnlich aus, wie ein Strichcode.
Dann wird "scan data" wohl angeben, welche Zeilen durch die Pixeldaten geändert werden sollen. 44 x 0xFF ändert alle Zeilen auf einmal, also sehen alle Zeilen gleich aus: Strichcode. 1 x 0xFF + 43 x 0x00 sollte z.B. nur die ersten 4 Zeilen ändern.
Jetzt kann ich das e-Papier entweder komplett schwarz oder weiß beschreiben. a) Das reicht natürlich noch nicht für meine Anwendung. (es soll mal ein EKG geschrieben werden) Vermutlich liegt mein Problem u.a. in der Zeile -scan Byte- (for(s=0;s<44;s++)SPI_8Bit_oCS( 0xff);), welche zwischen den geraden und ungeraden Bildpunkten eingebaut ist. Zunächst: Wie könnte man scan Byte sinnvoll übersetzen? im Anhang mal das Programmschnipsel „E-Papier beschreiben.h“ b) als nächstes habe ich versucht, das Bild „Bild_EAlogo1.h“, welches als zweidimensionales [Feld] (array) aufgebaut ist, zu verarbeiten. Dazu wurde eine Funktion, wie in „mit bild 176x33.c“ angeführt, geschrieben. Nun tritt das Problem auf, dass das Programm, wenn 176 Zeilen verwendet werden, sich aufhängt. Bei einem Bild mit versuchsweise nur 48 Zeilen, hängt sich das Programm nicht auf. Weil ich von Programmierung zu wenig Ahnung, die Frage, wie man das Problem lösen könnte (z.B. Zeiger ??) Verwendet wird ein MSP430F1611.
:
Bearbeitet durch User
wolle g. schrieb: > Jetzt kann ich das e-Papier entweder komplett schwarz oder weiß > beschreiben. > > a) Das reicht natürlich noch nicht für meine Anwendung. (es soll mal ein > EKG geschrieben werden) > Vermutlich liegt mein Problem u.a. in der Zeile -scan Byte- > (for(s=0;s<44;s++)SPI_8Bit_oCS( 0xff);), welche zwischen den geraden und > ungeraden Bildpunkten eingebaut ist. > Zunächst: Wie könnte man scan Byte sinnvoll übersetzen? hast du mal den Vorschlag von Nosnibor getestet? Bei genauerer Betrachtung scheint das sinnvoll damit anzugeben für welche Zeilen die Pixeldaten übernommen werden sollen. > im Anhang mal das Programmschnipsel „E-Papier beschreiben.h“ Scan soll 11 oder 00 sein, ein senden von 0xaa ergibt 10! > b) als nächstes habe ich versucht, das Bild „Bild_EAlogo1.h“, welches > als zweidimensionales [Feld] (array) aufgebaut ist, zu verarbeiten. > Dazu wurde eine Funktion, wie in „mit bild 176x33.c“ angeführt, > geschrieben. Deine Bilddaten haben 1-Bit pro Pixel, das müsstest vor dem senden auf 2-Bit erweitern und dann logischer Weise noch erst alle geraden dann alle ungeraden Pixel auslesen. > Nun tritt das Problem auf, dass das Programm, wenn 176 Zeilen verwendet > werden, sich aufhängt. > Bei einem Bild mit versuchsweise nur 48 Zeilen, hängt sich das Programm > nicht auf. Wie hängt sich auf? Und irgendwie passt das mit dem 0x0A,0x00 vor den Daten und 0x02,0x07 nach den Daten zusammen mit deinem CS nicht so recht. Was sind das für Daten die bei den SPI16 noch gesendet werden? > Weil ich von Programmierung zu wenig Ahnung, die Frage, wie man das > Problem lösen könnte (z.B. Zeiger ??) Da hast du dir ja gleich was großes vorgenommen! Sascha
Sascha W. schrieb: > Was sind das für > Daten die bei den SPI16 noch gesendet werden? Das lässt sich noch leicht beantworten: es wird 0x02, 0x07 gesendet und davor muss jeweils 0x72 (Register) bzw. 0x70 (index) gesetzt werden. >hast du mal den Vorschlag von Nosnibor getestet? Ja, funktioniert bei mir so, dass ich an einer gewünschten Stelle eine Linie (Zeile) schreiben kann. >Deine Bilddaten haben 1-Bit pro Pixel, würde ich nicht so sehen: 1 Daten-Byte enthält 4 Bildpunkte zu je 2 Bit (11 für schwarz, 10 für weiß), wobei man zunächst die ungeraden und nach -scan Byte- die geraden Bildpunkte sendet. (so habe ich es gemacht) > Wie hängt sich auf? Nach dem Übertragen des Programms zum µC tut sich nichts. Z.B. , die LED grün reagiert nicht. und ein TIMER , der alle 2s eine LED blitzen lässt, bleibt aus. Bei dem Versuch mit nur 48 Zeilen wurden aber Bildpunkte gezeichnet und der TIMER lief auch
wolle g. schrieb: > Sascha W. schrieb: >> Was sind das für >> Daten die bei den SPI16 noch gesendet werden? > > Das lässt sich noch leicht beantworten: es wird 0x02, 0x07 gesendet und > davor muss jeweils 0x72 (Register) bzw. 0x70 (index) gesetzt werden. Ok >>hast du mal den Vorschlag von Nosnibor getestet? > Ja, funktioniert bei mir so, dass ich an einer gewünschten Stelle > eine Linie (Zeile) schreiben kann. Ok >>Deine Bilddaten haben 1-Bit pro Pixel, > würde ich nicht so sehen: 1 Daten-Byte enthält 4 Bildpunkte zu je 2 Bit > (11 für schwarz, 10 für weiß), wobei man zunächst die ungeraden und > nach -scan Byte- die geraden Bildpunkte sendet. (so habe ich es gemacht) deine Daten haben 33Byte pro Zeile das langt nur für die Hälfte der horizontalen Pixel, aber egal da du im Moment für die geraden und ungeraden die selben Daten sendest wird das Bild horizontal um den Faktor 2 vergrößert. >> Wie hängt sich auf? > Nach dem Übertragen des Programms zum µC tut sich nichts. Z.B. , die LED > grün reagiert nicht. und ein TIMER , der alle 2s eine LED blitzen lässt, > bleibt aus. > Bei dem Versuch mit nur 48 Zeilen wurden aber Bildpunkte gezeichnet und > der TIMER lief auch Hast du nur die Schleife geändert oder auch die Bilddaten? um noch mal auf die Scandaten zurückzukommen, du musst die 44Byte entsprechend der aktuellen Zeile die du sendest anpassen - also in den 44 Byte dürfen nur die zwei Bit gesetzt sein die zu der Zeile gehören deren Daten du in den 2x33Byte sendest. Sascha
Sascha W. schrieb: > um noch mal auf die Scandaten zurückzukommen, du musst die 44Byte > entsprechend der aktuellen Zeile die du sendest anpassen - also in den > 44 Byte dürfen nur die zwei Bit gesetzt sein die zu der Zeile gehören > deren Daten du in den 2x33Byte sendest. Ich habe noch etwas experimentiert und hoffe, das mit den Scandaten verstanden zu haben. Es ist mir jetzt möglich, in jede beliebige Zeile eine Linie zu zeichnen und denke, evtl. in nächster Zeit auch ein komplettes Bild zeichnen zu können. Unbefriedigend ist aber, dass mit meinem µC und meinem Programm das Bild nur 98 Zeilen haben darf. Wie schon gesagt, mit 176 Zeilen will das Programm nicht laufen. In einem Demoprogramm (epaper_pi_130307.tar.gz) wurden Zeiger verwendet. Könnte dies zu einer Lösung des Problems führen? wenn ja, wie
:
Bearbeitet durch User
wolle g. schrieb: > Ich habe noch etwas experimentiert und hoffe, das mit den Scandaten > verstanden zu haben. Es ist mir jetzt möglich, in jede beliebige Zeile > eine Linie zu zeichnen und denke, evtl. in nächster Zeit auch ein > komplettes Bild zeichnen zu können. das passt doch schon mal > Unbefriedigend ist aber, dass mit meinem µC und meinem Programm das Bild > nur 98 Zeilen haben darf. Wie schon gesagt, mit 176 Zeilen will das > Programm nicht laufen. du hast meine Frage noch nicht beantwortet, hast du nur die Schleife auf 98 gesetzt oder auch weniger Bilddaten in dein Array gelegt? Wenn du nicht noch eine serielle Schnittstelle für Statusausgaben hast dann musst du halt mit ein paar Pins wackeln um zu sehen wo dein Programm hängenbleibt Sascha
Sascha W. schrieb: > du hast meine Frage noch nicht beantwortet, hast du nur die Schleife auf > 98 gesetzt oder auch weniger Bilddaten in dein Array gelegt? Es wurden weniger Bilddaten verwendet. Das Feld wurde von der Größe [176] [33] auf [98][33] verkleinert. Im Anhang mal der Bildschirm, wie er sich zeigt, wenn es Probleme gibt. Irgendetwas mit der Kopierung in einen Speicher (memcpy)läuft wahrscheinlich nicht so, wie es soll.
wolle g. schrieb: > Sascha W. schrieb: >> du hast meine Frage noch nicht beantwortet, hast du nur die Schleife auf >> 98 gesetzt oder auch weniger Bilddaten in dein Array gelegt? > > Es wurden weniger Bilddaten verwendet. > Das Feld wurde von der Größe [176] [33] auf [98][33] verkleinert. > Im Anhang mal der Bildschirm, wie er sich zeigt, wenn es Probleme gibt. > Irgendetwas mit der Kopierung in einen Speicher (memcpy)läuft > wahrscheinlich nicht so, wie es soll. ganz klar, deine Definition der Bildaten als
1 | unsigned char const ImageDataPD[96][16]= ... |
2 | unsigned char PreloadImage[96][16] |
landet komplett im RAM des Controllers, und das wird einfach zu viel sein. macht bei 176x33 = 5.8kB * 2 >10kB und dein MSP hat nur 10kB! Du musst die festen Bilddaten ausschließlich im Flash ablegen. Sascha
Sascha W. schrieb: > landet komplett im RAM des Controllers, und das wird einfach zu viel > sein. macht bei 176x33 = 5.8kB * 2 >10kB und dein MSP hat nur 10kB! > Du musst die festen Bilddaten ausschließlich im Flash ablegen. Die Berechnung verstehe ich noch nicht so richtig. Wenn ich mir zum Beispiel die Datei -Image_EAlogo.h- ansehe, dann ist sie als Feld mit 176 Zeilen zu je 33 Spalten aufgebaut, also 33 Spalten zu 1 Byte x 176 Zeilen = 5,8kB. Auf S.21 wird zwar ein Speicherbedarf von 11,6kB angegeben, aber dies gilt m.E.für 2 Bilder (vorhergehendes/ neues Bild) > Du musst die festen Bilddaten ausschließlich im Flash ablegen. Wie ist das gemeint? Was ist der Flash? Ich kenne z.Zt. den Arbeitspeicher (RAM) und den Programmspeicher. Bei dem MSP430F1611 gibt es noch einen nichtflüchtigen Speicherbereich, wo man Daten ablegen kann. (nur 2kB) Es sollen bei meiner Anwendung keine Bilddaten fest abgelegt werden. Wie oben schon mal gesagt, soll (kontinuierlich) eine EKG-Kurve dargestellt werden. Dazu wird alle 10ms ein Spannungswert (Y-Wert) gemessen. Dass dies nicht ganz unmöglich ist, zeigt ein Beispiel unter https://www.youtube.com/watch?v=enzUbiSWenQ (2,6"), wobei hier allerdings die Abtastzeit bedeutend höher gewählt wurde.
:
Bearbeitet durch User
wolle g. schrieb: > Sascha W. schrieb: >> landet komplett im RAM des Controllers, und das wird einfach zu viel >> sein. macht bei 176x33 = 5.8kB * 2 >10kB und dein MSP hat nur 10kB! >> Du musst die festen Bilddaten ausschließlich im Flash ablegen. > Die Berechnung verstehe ich noch nicht so richtig. > Wenn ich mir zum Beispiel die Datei -Image_EAlogo.h- ansehe, dann ist > sie als Feld mit 176 Zeilen zu je 33 Spalten aufgebaut, also > 33 Spalten zu 1 Byte x 176 Zeilen = 5,8kB. > Auf S.21 wird zwar ein Speicherbedarf von 11,6kB angegeben, aber dies > gilt m.E.für 2 Bilder (vorhergehendes/ neues Bild) Die 11.6 aus dem Datenblatt kommen sicher daher das, wie wir ja inzwischen wissen, 2Bit pro Pixel übertragen werden. In deinem Programm hast du ein Array mit den Daten definiert und ein zweites leeres mit der selben Größe, der Speicherplatz wird dafür im RAM aber trotzdem reserviert. Eigentlich sollte der Compiler auch eine Warnung ausgeben. >> Du musst die festen Bilddaten ausschließlich im Flash ablegen. > Wie ist das gemeint? Was ist der Flash? > Ich kenne z.Zt. den Arbeitspeicher (RAM) und den Programmspeicher. Der Programmspeicher ist der Flash, In C sollte das dann const char progmem heißen, beschäftige dich dazu mal mit C > Bei dem MSP430F1611 gibt es noch einen nichtflüchtigen Speicherbereich, wo > man Daten ablegen kann. (nur 2kB) Das ist dann EEProm > Es sollen bei meiner Anwendung keine Bilddaten fest abgelegt werden. > Wie oben schon mal gesagt, soll (kontinuierlich) eine EKG-Kurve > dargestellt werden. Dazu wird alle 10ms ein Spannungswert (Y-Wert) > gemessen. das ist schon Ok, Aufgrund der verschachtelten Bitzuordnung wirst du die Bilddaten aber sicher im RAM puffern müssen. Sascha
Sascha W. schrieb: > In C sollte das dann const char progmem heißen, beschäftige dich dazu > mal mit C Ich habe den Eindruck, dass --progmem-- etwas AVR-Spezifisches sein könnte. Gibt es noch andere Möglichkeiten?
Jim M. schrieb: > wolle g. schrieb: >> Einige Fragen: a) Was ist z.B. mit 1 hoch st, 33 hoch rd und 44 hoch th >> gemeint? > > Das der OP seinen Englisch Grundkurs wiederholen muss. Ohne diese > Grundlagen ist das Verständnis eines Datenblatts nicht möglich. +1
wolle g. schrieb: > Sascha W. schrieb: >> In C sollte das dann const char progmem heißen, beschäftige dich dazu >> mal mit C > > Ich habe den Eindruck, dass --progmem-- etwas AVR-Spezifisches sein > könnte. dafür kenne ich mich weder mit C noch dem MSP ausreichend aus, aber prinzipiell sollte es sowas eigentlich bei allen Architekturen geben bei denen das Programm aus einem separaten Speicher und nicht aus dem RAM ausgeführt wird. > Gibt es noch andere Möglichkeiten? Nein, aber für deine Anwendung ist das ja erst mal kein Problem wenn du keine vollformatigen statischen Bilddaten ablegen willst. Dein Speicher reicht ja um den kompletten Bildinhalt im RAM vorzuhalten (mit 1Bit pro Pixel), bei der Ausgabe an das Display musst du halt jeden Bildpunkt entsprechend auf die 2Bit umrechnen. Sascha
wolle g. schrieb: > Ich habe den Eindruck, dass --progmem-- etwas AVR-Spezifisches sein > könnte. > Gibt es noch andere Möglichkeiten? Da der MSP430 einen gemeinsamen Adressraum für Programm und Daten hat, sollte const char reichen. Wenn der Compiler nicht vollkommen bescheuert ist, läßt er das Bild dann im Programmspeicher liegen und belegt keinen RAM dafür.
Nosnibor schrieb: > Wenn der Compiler nicht vollkommen > bescheuert ist, läßt er das Bild dann im Programmspeicher liegen und > belegt keinen RAM dafür. Der Compiler ist nicht bescheuert. Jetzt bleibt der µC erst einmal nicht mehr hängen. Am "Rest" kann ich jetzt weiter arbeiten. Danke
Den "Rest" habe ich Angriff genommen, komme aber nicht so richtig weiter. Jetzt hängt es zunächst an der Zeilenauswahl (bzw. Linienauswahl) Ich beschreibe erst einmal, wie ich den im Anhang dargestellten Programmabschnitt dargestellt habe und wie ich das Flussdiagramm gedeutet habe Zunächst wird SPI (0A, 00) gesendet. Dann werden die ersten 33 ungeraden 4-fach Bildpunkte (je 1 Byte) gesendet. Dann folgen insgesamt 44 scan-Byte, wodurch entweder die Zeilen (auch Linien) ein- oder ausschaltbar sind. Danach kommen wieder 33 gerade 4-fach Bildpunkte (je 1 Byte). Das wiederholt sich 44 mal (176 Linien/4 = 44 Zeilen ) Damit ist das e-Papier 176x264 bei mir voll. Was mache ich falsch? Ich will ja jeden einzelnen Bildpunkt darstellen können, d.h. ich muss die 4 Linien, die sich in einer Zeile befinden irgendwie einzeln ansprechen. nächstes Problem: Von dem Feld der Datei: Bild_EAlogo5_44x33.h wird immer nur die 1. Zeile ausgelesen bzw. in den Zeilen dargestellt. Wie könnte man das Problem lösen? bzw. was ist an meinem Gedankengang falsch? Hoffentlich habe ich mich ausreichend verständlich ausgedrückt.
:
Bearbeitet durch User
wolle g. schrieb: > Zunächst wird SPI (0A, 00) gesendet. > Dann werden die ersten 33 ungeraden 4-fach Bildpunkte (je 1 Byte) > gesendet. Ja > Dann folgen insgesamt 44 scan-Byte, wodurch entweder die Zeilen (auch > Linien) ein- oder ausschaltbar sind. Jain, mit den 44Byte wählst du aus in welche Zeilen die 2x 33Byte übernommen werden. Das schein als eine Art Kompression der Übertragung gedacht zu sein du kannst so das komplette Display oder einen beliebigen rechteckigen Bereich in einem Durchlauf löschen. > Danach kommen wieder 33 gerade 4-fach Bildpunkte (je 1 Byte). > Das wiederholt sich 44 mal (176 Linien/4 = 44 Zeilen ) wenn jede Zeile was anderes enthalten soll brauchst du 176 Durchläufe > Damit ist das e-Papier 176x264 bei mir voll. wenn das Display schon nach 44 Durchläufen voll ist hast du die Zeilen nicht einzeln ausgewählt. > Was mache ich falsch? > Ich will ja jeden einzelnen Bildpunkt darstellen können, d.h. ich muss > die 4 Linien, die sich in einer Zeile befinden irgendwie einzeln > ansprechen. abhängig davon in welche der in einem Byte zusammengefassten 4 Zeilen du schreiben willst musst du 0xC0, 0x30, 0x0C oder 0x03 senden > nächstes Problem: Von dem Feld der Datei: Bild_EAlogo5_44x33.h wird > immer nur die 1. Zeile ausgelesen bzw. in den Zeilen dargestellt. d.h. in allen Zeilen dargestellt? Das liegt einfach daran das du mit 44x 0xff dem Display in jedem Durchlauf sagst das es die gerade angelieferten Pixel in alle Zeilen übernehmen soll Prinzipiell könnte man eine Funktion schreiben die ein einzelnes Pixel setzt oder löscht, das wird natürlich sehr ineffizient. **X-Koordinate *Bit 0 entscheidet darüber ob die Daten für das Pixel im ersten oder im zweiten Block übertragen werden (gerade/ungerade) *Bit 2+1 entscheiden über die Position der Pixelbits innerhalb des Bytes *Bit 7-3 entscheiden über das Byte in welches die Daten müssen Die Farbe des Pixels gibt den Zustand der Pixelbits vor **Y-Koordinate *Bit 1+0 entscheiden über die Position der Zeilenbits innerhalb des Bytes *Bit 7-2 entscheiden über das Byte in welches die Bits müssen Wenn du ein Diagramm oder Schrift zeichnen willst wird es effizienter den betroffenen rechteckigen Bereich im RAM mit 1Bit/Pixel zu puffern, dort hineinzuzeichnen und den Bereich dann komplett an das Display auszugeben. Die rechnerei s.o. brauchst du natürlich trotzdem. Sascha
:
Bearbeitet durch User
Sascha W. schrieb: > Prinzipiell könnte man eine Funktion schreiben die ein einzelnes Pixel > setzt oder löscht, das wird natürlich sehr ineffizient. so ähnlich mache ich es ja bei einem "normalen" LCD. Aber da muss man nicht ein ganzes Bild schreiben, sondern das geht hier punktweise. "Neue" Idee (für mich), um einzelne Linien zu berechnen: Rest (Modulo) aus Division berechnen. Z.Zt. nur Idee. Beispiel: 48/4 = 12 Rest 0 --> Zeile 12 Linie 1 50/4 = 12 Rest 2 --> Zeile 12 Linie 3 51/4 = 12 Rest 3 --> Zeile 12 Linie 4 52/4 = 13 Rest 0 --> Zeile 13 Linie 1
:
Bearbeitet durch User
wolle g. schrieb: > Sascha W. schrieb: >> Prinzipiell könnte man eine Funktion schreiben die ein einzelnes Pixel >> setzt oder löscht, das wird natürlich sehr ineffizient. > so ähnlich mache ich es ja bei einem "normalen" LCD. Aber da muss man > nicht ein ganzes Bild schreiben, sondern das geht hier punktweise. das ganze Bild auch nicht, aber eine Zeile, und der Transfer ans Display macht halt 110 Datenbytes. > "Neue" Idee (für mich), um einzelne Linien zu berechnen: > Rest (Modulo) aus Division berechnen. > Z.Zt. nur Idee. Beispiel: > > 48/4 = 12 Rest 0 --> Zeile 12 Linie 1 > 50/4 = 12 Rest 2 --> Zeile 12 Linie 3 > 51/4 = 12 Rest 3 --> Zeile 12 Linie 4 > 52/4 = 13 Rest 0 --> Zeile 13 Linie 1 ja, deine "Zeile" ist dann das Byte (von den 44) und die "Linie" dann die beiden Bits in dem Byte Rest 0 => 0xc0 Rest 1 => 0x30 Rest 2 => 0x0c Rest 3 => 0x03 für die Reihenfolge will ich jetzt mal nicht die Hand ins Feuer legen - hab jetzt nicht noch mal im DB nachgeschaut. Sascha
:
Bearbeitet durch User
Ich kann zwar z. Zt. jede beliebige Zeile oder auch Linie als schwarzen Balken darstellen, aber etwas bildähnliches wird es nicht, da es immer nur bei einem Balken (Zeile) bleibt. Ich habe mal die Anzahl der Zeilen (Variable i, ursprünglich 176 Linien) auf 44 festgelegt, um dadurch nur bei vollständigen Zeilen (0xFF) bleiben zu können. Da i von 0 bis 43 durchläuft, hatte ich gedacht, dass ab Zeile 5 alle Zeilen schwarz werden. Ab Zeile 6 bleibt die Fläche aber weiß. Was könnte falsch sein? Oder hat jemand ein funktionierendes Beispiel? Im Anhang mein Programmschnipsel
wolle g. schrieb: > Ich kann zwar z. Zt. jede beliebige Zeile oder auch Linie als schwarzen > Balken darstellen, aber etwas bildähnliches wird es nicht, da es immer > nur bei einem Balken (Zeile) bleibt. > Ich habe mal die Anzahl der Zeilen (Variable i, ursprünglich 176 Linien) > auf 44 festgelegt, um dadurch nur bei vollständigen Zeilen (0xFF) > bleiben zu können. > Da i von 0 bis 43 durchläuft, hatte ich gedacht, dass ab Zeile 5 alle > Zeilen schwarz werden. > Ab Zeile 6 bleibt die Fläche aber weiß. > Was könnte falsch sein? > Oder hat jemand ein funktionierendes Beispiel? > Im Anhang mein Programmschnipsel in der PDF hab ich mal mit Excel nachgestellt was du an das Display ausgibst. Wie du siehst kann das so nicht funktionieren. Erstens beschreibst du viele Zeilen doppelt und Zweitens ist die Anzahl der gesendeten Bytes für die Zeilen nur 1x 44Byte! versuch das mal so ...
1 | ;Zeile zu Linedata |
2 | int Zeile; |
3 | |
4 | for (i=0;i<(Zeile>>2);i++) SPI_8Bit_oCS(0x00);//volle 4 Zeilen zuvor |
5 | SPI_8Bit_oCS(0x03<<((Zeile & 0x03)<<1)); |
6 | for (i=0;i<43-(Zeile>>2);i++) SPI_8Bit_oCS(0x00);//volle 4 Zeilen danach |
das hier sollt eine schräges Muster aus 4 Linien (10101010) erzeugen
1 | int Zeile,sp,i,cnt; |
2 | cnt=0; |
3 | for(Zeile=0;Zeile<176;Zeile++) { |
4 | //ungerade
|
5 | for(sp=0;sp<33;sp++) { |
6 | if (cnt==sp) { |
7 | SPI_8Bit_oCS(0xff); |
8 | } else { |
9 | SPI_8Bit_oCS(0x00); |
10 | }
|
11 | }
|
12 | for (i=0;i<(Zeile>>2);i++) SPI_8Bit_oCS(0x00); |
13 | SPI_8Bit_oCS(0x03<<((Zeile & 0x03)<<1)); |
14 | for (i=0;i<43-(Zeile>>2);i++) SPI_8Bit_oCS(0x00); |
15 | //gerade
|
16 | for(sp=0;sp<33;sp++) { |
17 | SPI_8Bit_oCS(0x00); |
18 | }
|
19 | cnt++; |
20 | if (cnt>32) cnt=0; |
21 | }
|
Sascha
Mist, da habe ich doch die falsche Datei angehängt. Danke für Deinen Entwurf. Den werde ich natürlich mal testen. Trotzdem im Anhang mal die ursprünglich gedachte Datei, damit man sehen kann, was ich gemeint hatte.
@Sascha, das "schräge Muster aus 4 Linien" habe ich getestet. Leider wird nicht das gewünschte Muster dargestellt. Nach dem -loeschen();- (alles weiß) und dem dann folgenden -schreiben_sw1();- kann man nur rechts unten in Linie 1 ein Muster mit 4 Punkten sehen. Der Abstand zwischen den Punkten beträgt 1 Bildpunkt. 1. Punkt von rechts nach links gesehen, könnte Punkt (1, 264) sein. Alle weiteren Linien und Zeilen bleiben weiß. im Anhang die verwendeten Funktionen mit den zusätzlichen Ergänzungen. Natürlich kann hier auch jede(r) andere mitmischen.
Hallo, innerhalb der Zeilenschleife muss natürlich noch das 0x0a,0x00 am Anfang und 0x02,0x07 am Ende rein. Sascha
Sascha W. schrieb: > innerhalb der Zeilenschleife muss natürlich noch das 0x0a,0x00 am Anfang > und 0x02,0x07 am Ende rein. Beides habe ich doch bereits schon vor dem Test eingefügt. siehe Anhang
wolle g. schrieb: > Sascha W. schrieb: >> innerhalb der Zeilenschleife muss natürlich noch das 0x0a,0x00 am Anfang >> und 0x02,0x07 am Ende rein. > Beides habe ich doch bereits schon vor dem Test eingefügt. > siehe Anhang nö, der Start ist vor der Zeilenschleife und das Ende ist innerhalb, aber auch noch an der falschen Stelle (darf nicht in der if-Abfrage sein). Siehe Flowchart auf Seite 29, der Tranfer beginnt für jede Zeile mit dem CMD 0x0A,0x00 (Displaydaten) und endet für jede Zeile mit dem CMD 0x02,0x07 (Übernahme der gesendeten Daten) Sascha
Sascha W. schrieb: > nö, der Start ist vor der Zeilenschleife und das Ende ist innerhalb, > aber auch noch an der falschen Stelle (darf nicht in der if-Abfrage > sein). Klasse! das schräge Muster ist jetzt zu sehen; nur noch etwas blass Danke! Das Ende war m. E. richtig. Jetzt muss ich mir das Ganze noch einmal in Ruhe ansehen, damit ich mal eines Tages meine EKG-Kurve darstellen kann.
wolle g. schrieb: > Sascha W. schrieb: >> nö, der Start ist vor der Zeilenschleife und das Ende ist innerhalb, >> aber auch noch an der falschen Stelle (darf nicht in der if-Abfrage >> sein). > > Klasse! das schräge Muster ist jetzt zu sehen; nur noch etwas blass > Danke! Na bestens > Das Ende war m. E. richtig. Ja hast recht, die if hat ja gar keinen Codeblock Sascha
So, jetzt bin ich (fast) mit meinem EKG-Gerät bei Verwendung eines Pervasive Display fertig. Kurze Erläuterung: Die EKG-Kurve wird auf einem e-Papier E2271CS021 abgebildet. Dass die Kurve fortlaufend, wie ursprünglich das Ziel war, dargestellt wird, ist mir nicht gelungen. Der EKG-Eingangsverstärker ADS1293 wird alle 7ms abgefragt. Von dem 24BIT Messwert wird nur das mittlere Byte verarbeitet, da es nur 176 Zeilen x 263 Bildpunkte gibt. Es erfolgt eine Nulllageregelung über den gleitenden Mittelwert. Die Bildpunkte werden in einem Feld [33][176] = (33 Spalten je 8Bit und 176 Zeilen) im Arbeitsspeicher abgelegt und danach mit der Funktion „schreiben_zum_E2271“ als gesamtes Bild zum Bildschirm E2271 übertragen. Vorher wird der Bildschirm gelöscht (alles weiß) Im Anhang für evtl. Interessierte das Programm eines Programmierlaien.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.