Soweit bin ich jetzt schon:
Adresse 78 (Rumgehexe mit der 3C schon erledigt.)
Befehle zum Initialisieren der Reihe nach eingegeben:
0x8D, 0x14, 0x20, 0x8D, 0x14, 0xAF
Dann zeigt mir das Display schon einmal Rauschen, bzw. kryptische Zeichen Zeile für Zeile. Das scheint aber unvollständig.
Dem Datenblatt des Controllers SSD1315 kann ich keinen Hinweis entnehmen,
dass schon "Charakters" über ASCII abrufbar sind, wie man es vom HD44780- Standard so gewohnt war.
Also einfache Frage:
Eine "schöne" Initialisierungsroutine scheint das Teil auch nicht zu brauchen. Steht jedenfalls nichts direkt so im Datenblatt.
Andersherum. Man wird nicht umhin kommen, die Libraries ausführlich zu Hilfe zu nehmen.
Mehr wollte ich nicht wissen.
Oder könnt Ihr mir eine supereinfache Initialisierungsroutine verraten.
Wollte nur - wie gehabt - Buchstaben und Ziffern "normal" darstellen lassen.
(Vorerst, nicht gleich mit etwas Komplizierten Graphischem beginnen.)
Dem Datenblatt des Controllers SSD1315 kann ich keinen Hinweis
entnehmen, dass schon "Charakters" über ASCII abrufbar sind,
wie man es vom HD44780- Standard so gewohnt war.
Man darf "Zeichen" sagen. Und nein, sind sie nicht. Das ist einer der wesentlichen Unterschiede zwischen einem Graphik- und einem Textdisplay.
Du musst jeden einzelnen Bildpunkt selbst von Hand setzen. Dafür gibt es natürlich "Libraries", die das übernehmen, mit nachezu beliebigen Zeichensätzen und -Größen.
Warum nennt das Datenblatt auf S.15 dann als Slave Adresse die 0x3C bzw. 0x3d, je nach SA0 Bit?
("...“SA0” bit provides an extension bit for the slave address. Either “0111100” or “0111101”, can be selected as the slave address of SSD1315".)
Da hast du wohl noch das R/W-Bit mit reingemischt und alles um ein Bit verschoben. Elementare Bitoperationen als Hexerei zu bezeichnen, hört sich so an, als ob du die Arbeitsweise des I2C noch nicht ganz verinnerlicht hast.
das ist das größte "Problem" bei verschiedenen LIBs erst Recht wenn man
mischt!
Elementare Bitoperationen als Hexerei zu bezeichnen, hört sich etwas befremdlich an.
Die I2C-Spezifikation spricht bezüglich der Adresse eine klare Sprache und alles, was sich I2C nennt, sollte sich an die dort verwendeten Begrifflichkeiten halten. In Fig.9 (S.13) sind die Signale sogar bildlich dargestellt und die Bits genau bezeichnet.
https://www.nxp.com/docs/en/user-guide/UM10204.pdf
Notfalls hilft ein kleiner Logikanalysator, der einem die Signale auf dem Bus darstellt und dekodiert, so dass man sofort sieht, was dort gesendet wird und ob das Ack vom Slave kommt - ganz unabhängig von möglicherweise irreführenden Interfacebeschreibungen irgendwelcher Libs oder deren Fehlinterpretation.
Man wird nicht umhin kommen, die Libraries ausführlich zu
Hilfe zu nehmen.
So machen es in der Tat die allermeisten Leute. Und wenn du nun noch verraten hättest, welche μC-Plattform du nutzt, hätte dir auch jemand die ebenfalls ungestellte, aber vermutlich vorhandene Frage beantworten können, welche man da am besten nimmt, und wie man sie nutzt.
das ist das größte "Problem" bei verschiedenen LIBs erst Recht wenn man
mischt!
Elementare Bitoperationen als Hexerei zu bezeichnen, hört sich etwas
befremdlich an.
das habe ich nicht geschrieben, und warum zitierst du micht?
Tatsache bleibt, viele Arduinos LIBs zählen I²C bis 127, R/W Bit ausgeblendet und wer sich ans Datenblatt hält der berücksichtigt selber das R/W Bit und kann auf die Nase fallen so wie ich am Anfang, denn in Datenblätter steht nichts von Arduino, oft nicht mal was von extendet I²C
https://rn-wissen.de/wiki/index.php?title=I2C#10-Bit-Adressierung
Tatsache bleibt, viele Arduinos LIBs zählen I²C bis 127,
Nicht eher alle?
Da die meist zu Grunde liegende Wire das eben auch so tut.
Und laut dem NPX Dokument ist die Sichtweise auch voll ok so.
7 Adressbit und ein R/W Bit.
Das R/W Bit liegt im gleichen Byte, aber heißt nicht, dass es ein Adressbit ist.
Arduino macht es richtig, entsprechend der I2C Spezifikation. Verwirrung stiften nur die Leute, die aus der 7 Bit Adresse ein verschobenes Byte machen.
Dass man auf der Schnittstelle die Adresse zusammen dem R/W Flag kombiniert ist klar. Diese Kombo soll man aber niemals Adresse nennen. Du kannst es gerne "erstes Byte" nennen.
das habe ich nicht geschrieben, und warum zitierst du micht?
"Elementare Bitoperationen ..." ist auch kein Zitat von dir, sonst wäre es als Zitat gekennzeichnet gewesen.
Tatsache bleibt, viele Arduinos LIBs zählen I²C bis 127, R/W Bit
ausgeblendet ...
I²C Adresse bis 127 entspricht der I²C-Spezifikation. NXP (damals noch Philips) hat das 1982 mit Einführung des Bus so festgelegt. Da ist kein Bit ausgeblendet. Um 10-Bit Adressen geht es hier gerade nicht. Die sind zwar auch spezifiziert, spielen für den Display Controller des TO aber keine Rolle.
Nix für ungut, aber ich glaube, die Adresse hatte der TE schon, weswegen ihn der Diskussionszweig dazu vermutlich nicht weiterbringt.
„Rumgehexe“ hätte ich im gegebenen Kontext auch eher als mehr oder weniger gelungenes Wortspiel „Dec → Hex“ interpretiert, also auch nicht unbedingt etwas, das noch weiterer Diskussion bedürft hätte.
Da gibt es doch im Web für Arduino Bastler unzählige Beispiele.
Auf die schnelle diesen Link gefunden :
https://wiki.seeedstudio.com/Grove-OLED-Display-0.96-SSD1315/
Ich würde generell bei einen unbekannten Display bzw. I2C Device
mit einen I2C Scanner zuerst die Adresse ermitteln und dann
weitere Versuche unternehmen - so stellst Du auch die Funktionsfähigkeit Deines Aufbaues sicher.
Und noch etwas : ein OLED ist nicht mit einen HD44780 Display
vergleichbar (auch anders herum nicht).
Manche sind damit gescheitert ein angeblich HD44780 kompatibles
OLED plug & play gegen ein LCD Display auszutauschen.
Nix für ungut, aber ich glaube, die Adresse hatte der TE schon, weswegen
ihn der Diskussionszweig dazu vermutlich nicht weiterbringt.
Mir ging es darum, ob bereits ein Charakter ROM vorhanden ist, das einfach mit ASCII angesprochen werde kann. Oder nicht. Neben der pixelweisen Ansteuerung à la "User definded Characters".
Und, ob eine Initialisierungsroutine nötig ist.
Hatte die Werte oben aus einem Youtube Video.
(Das ist aber so unnötig kompliziert aufgebaut, dass einem nach 30 Minuten mühsamem Zuschauens die Lust vergeht.)
Hatte noch festgestellt, dass Anschlüsse für SCL und SDA Pin auf dem Display selbst verdreht sind gegenüber dem PCF8574A-Portadapter.
(Zur Not kann man ja den Stecker testweise umdrehen.)
Dachte am Anfang, könnte einfach das vorhandene Programm ein wenig abändern. (Programm 1 im Anhang.)
Also einfach alles Unnötige rausremmen und dafür:
ldi temp, 0x8D ....etc
twiout...
reinsetzen. (Wie oben bereits gepostet)
OK. Man sieht schon einmal etwas.
Aber jetzt müsste noch mehr an Programmcode kommen.
Bzw. Initialisierung.
Das war noch die nächste Frage.
Und ja, die zahllosen Arduinolibraries hatte ich schon entdeckt.
Wollte es aber lieber ein wenig simpler haben. So, dass ich es nicht nur blind ohne Sinn und Verstand abkopiere, sondern auch ein Lerneffekt entsteht.
Danke schon einmal für Eure zahlreichen Antworten.
nd ja, die zahllosen Arduinolibraries hatte ich schon entdeckt.
Wollte es aber lieber ein wenig simpler haben.
Als Anfänger nimm lieber die Librarys - ein OLED ist komplizierter als
ein Standard HD44780 LCD zum laufen zu bringen.
Das erkennst Du schon an den umfangreicheren DB gegenüber den LCD.
Aber Pixeltexte selber schreiben, etc. das wird umfangreicher.
Ich versuche, mit dem Target Attiny4313 etwas Vernünftiges hinzubekommen.
Die empfohlenen Libraries sind ja auf die ATIMEGAs fixiert. Das wird so nichts mit copy and paste.
Aber für ganz primitive Darstellung müsste es auch mit dem Attiny klappen.
Der SSD1315 braucht nebenbei bemerkt auch Zeitschleifen zwischen den Kommandos.
Die Umschaltung von Kommando auf Daten (hex00 auf hex40) scheint so eine
Sache, die momentan nicht auf Anhieb geklappt hat.
Und Pins SDA und SCL auch sind nicht vertauscht. Das stimmt schon einmal.
Werde weiter berichten.
So, jetzt habe ich mich einmal hingesetzt (und wieder einmal viel zu viel Zeit vertan für Dinge die nicht für mch sind, nur weil ich diesen Thread gelesen habe).
Zum einen bin ich erstaunt: Karl B. ist seit 2008 dabei, hat über 8000 Threads geschrieben und es gibt Probleme mit SSD1315 und I2C und scheinbar Displays allgemein.
Dann hab ich die Postings gelesen und es wird sich über I2C ausgelassen und darüber ob eine 7 Bit Adresse plus r/w Bit korrekt ist, oder ob es eine 8 Bit Adresse gibt. Was grundsätzlich eine Frage des I2C und nicht des Displays ist.
Wie andere hier schon angemerkt haben, fasse ich mal kurz die Infos zusammen, die für Karl dann wichtig sind:
ein Display mit SSD1315 Display ist ein graphisches Display, es hat keinen eingebauten Zeichensatz, der einfach abgerufen werden kann
ein Display mit SSD1306 Controller ist sehr ähnlich und unterscheidet sich relativ wenig vom 1315, der 1315 ist gewissermaßen ein Upgrade auf einen SSD1306. Die Initialisierungssequenz der beiden unterscheidet sich etwas und, nimmt an ein 128x64 Pixel großes Display an, dann läuft ein und der selbe Code auf beiden Displays
ein Standard-Display mit HD44780 Controller ist ein reines Textdisplay welches die Bitmaps der Ascii-Zeichen im HD44780 mit abgelegt hat, weshalb diese einfach so abrufbar sind. Grundsätzlich hat dieses Display entweder eine 4-Bit oder eine 8-Bit parallele Datenkommunikation. Wenn ein solches Display über I2C angesprochen wird, hat es einen I2C I/O Expander (i.a.R einen PCF8574), der diese auf eine parallel Kommunikation umsetzt.
für das OLED-Display muß also zwingend ein Array her, dass die Bitmaps des Fonts, mit dem auf das Display geschrieben werden soll beinhaltet.
will man bspw. den Asciisatz der Zeichen 32 (Leerzeichen) bis 127 min. darstellen können, benötigt es bei einem 8x8 Pixel Font 96 Zeichen zu je 8 Byte = 768 Byte Speicherbedarf. Möchte man das auf einem ATtiny2313 machen, der nur 2048 Byte hat, wird das sehr schnell sehr knapp.
Da Karl B. ursprünglich nicht den Controller genannt hat, den er verwenden möchte, habe ich mal aus meinen Sourcen das extrahiert, was benötigt wird, um auf einem solchen Display einen Text ausgeben zu können.
Damit mein Demo-Programm auf so ziemlich jeder Mikrocontrollerplattform laufen soll, habe ich bewußt auf ein Hardware I2C-Verzichtet und dieses mittels Bitbanging realisiert.
Im Demo kann jetzt unterschieden werden, ob das Programm auf einem AVR-Controller, einem STM8-Controller oder einem anderen laufen soll (Präprozessor Defines). Bei mir habe ich diese Datei temporär so erweitert, dass ich meine Sourcen für Systeminitialisierung und GPIO-Behandlung eingebunden habe (die auf meiner Platte liegen) und so lief ein OLED-Display auch auf einem CH32V003, einem STM32F030 / F103 / F411.
Hier jedoch nur die Datei, bei der AVR und STM8 eingebunden sind. Bei Verwendung für AVR ATmega328 und AVR-GCC als Compiler, hat das erzeugte Kompilat bei mir eine Dateigröße von 1396 Byte. Ram-Bedarf zeigt es mir an 12 Bytes, wobei der tatsächliche Bedarf minimal höher sein dürfte, weil Ram-Belegung innerhalb Funktionen nicht einbezogen werden. Grundsätzlich sollte es hier tatsächlich möglich sein, das OLED tatsächlich an einem ATtiny2313 zu betreiben, wobei dann für das tatsächliche Anwenderprogramm nicht mehr viel übrig bleibt.
Der größte Teil in der Source meines Demos nimmt die Unterscheidung der Controller ein.
Für die, die das tatsächlich auf einem STM8 laufen lassen möchten: der verwendete Compiler ist natürlich SDCC.
Sollte Bedarf daran bestehen, aufzuzeigen wie das an CH32V003 (mit Framework CH32fun) oder mit einem STM32 aussieht (hier dann libopencm3, keine HAL und kein CubeMx), dann kann ich da hier gerne auch posten, allerdings bin ich der Überzeugung, dass man sich mittel Copy and Paste aus diesem Demo schnell etwas lauffähiges zusammenklicken kann.
Viele Grüße,
Ralph
PS: die angehängte Datei stm8s.h ist etwas selbst zusammen getragenes und wurde von mir aus den Datenblätter erstellt und ist unvollständig, sie war für meine Programme ausreichend und wurde, wenn etwas gefehlt hatte das meine Programme benötigt haben, erweitert. Sie ist also nichts offizielles aus irgendeiner wie auch immer gearteten Quelle
... so, aus lauter "Jux und Dollerei" habe ich in meinem Sammelsurium nachgesehen, ob ich richtig liege und es dort noch ein paar ATtiny2313 gibt und tatsächlich habe ich noch eine halbe Stange der Chips gefunden.
Früher waren die mal sehr günstig, deshalb hatte ich damit hantiert (grundsätzlich ist es etwas her dass ich überhaupt etwas mit AVR gemacht habe).
Dann habe ich im Netz nachgesehen, was denn heute ein ATtiny2313 kostet und mir verwundert die Augen gerieben: zwischen 2,00€ und 4,50€ ist da alles dabei und für mich muß ich sagen, dass das für die Leistungsfähigkeit absolut heute nicht mehr zeitgemäß ist und bei neueren Entwicklungen doch der Chip zu wechseln ist, selbst ein mittlerweile STM8 ist hier preislich noch deutlich besser als ATtiny2313. Alternativen in einem 20 pol. Gehäuse wären hier, preislich aufsteigend: CH32V003, STM32F030, STM8S103, ATtiny1604 (AVR-series0)
Wie dem auch sei, der TO hatte hier etwas von einem ATTiny2313 geschrieben und ich wollte sehen, ob das OLED-Display auch an einem 2313er funktioniert... und siehe da, es funktioniert.
Im Anhang findet ihr den Code, ausschließlich für einen ATtiny2313, befreit von der Präprozessorsteuerung eines anderen Controllers und ich habe eine kleine Ausgabefunktion für Integerzahlen hinzugefügt.
Das ganze belegt 1624 Byte Flashspeicher.
Ein Makefile zum Übersetzen und Flashen des Controllers habe ich auch hinzugefügt, der ATtiny hat Fusesettings: LOW: 0xE4, HIGH: 0xDF, EXT.: 0xFF. Dieses entspricht einem Takt von 8 MHz intern, der Chip benötigt also keinen externen Quarz.
schick, nur warum Platz verschwenden?
Ich finde 5x7 charsets (6x8 mit Pixelzwischenraum) sparsamer und nutze
ich gerne beim Nokia Display
Na ja, man kann den Font ja auch ersetzen und das putchar leicht anpassen. Nokia Displays (haben SPI-Interface) sind ja mittlerweile eher rar geworden und sind von der Anzeigefläche größer als das OLED-Display, bei weniger Pixeln.
Was beim Nokiadisplay mit 5x7 Font noch relativ gut zu lesen ist, ist beim OLED Display schon richtig richtig klein. Selbst der 8x8 Font ist noch klein. Da ich hier aber nicht den oft verwendeten Font nehme, sondern einen aus Anno dazumal extrahierten Font der CGA-Grafik eines Amstrad PC1512 ist der dennoch gut zu lesen.
5x7 will ich mir auf OLED nicht antun. Allerdings: tu dir keinen Zwang an!
5x7 will ich mir auf OLED nicht antun. Allerdings: tu dir keinen Zwang
an!
der Vorteil vom Pixeldisplay ist auch das man frei Hochformat oder Querformat wählen kann.
Beim Nokia Charset habe ich mich vor 10 Jahren Byte für Byte durch die Sourcen "gekämpft" aber heute mag ich nicht mehr. Das Alter hinterläßt halt Spuren.
Das hatte ich zuvor sogar so gehabt, aber ohne das do-while funktioniert es eben auch und dann hat mir das optisch nicht so gut gefallen.
Der Compiler generiert für beide Versionen denselben Code.
Ich werde testen, ob es genügt, den Port ein einziges mal auf 0 zu setzen und dann so zu belassen und das Umschalten der Pins nur noch mit DDR zu realisieren.
Grundsätzlich war das hier sehr schnell realisiert.
Ich werde testen, ob es genügt, den Port ein einziges mal auf 0 zu
setzen und dann so zu belassen und das Umschalten der Pins nur noch mit
DDR zu realisieren.
Ich habe vor kurzem eine fremde (chinesische) Bibliothek so geändert, wo direkt Port beschrieben wurde und ACK nur nachgebildet. Einfach "Port" auf "DDR" geändert und invertiert.
do{...}while(0) sind besonders bei verschachtelten #define sinnvoll - wenn man nicht lieber auf inline Funktionen setzt.
Läuft genauso und spart zudem dann 8 Byte an Flashspeicher :-)
(ich bin ja sonst auch geizig mit Flashspeicherverbrauch, aber auf 8 Byte habe ich dann doch nicht geschaut)
Allerdings werde ich mir das so merken und bei Bitbanging Sachen bei denen ein PullUp vorhanden ist, werde ich das - egal auf welcher Controllerfamilie - dann so handhaben.
Vielen Dank für den Tip (man lernt auch nach x-Jahren noch immer etwas dazu, was eigentlich relativ einfach ist. Man macht halt Dinge, die man immer so gemacht hat, und weil sie funktionieren überdenkt man das dann nicht mehr, sondern benutzt es einfach nur noch!
GIGA hat mich wegen TFT verführt. Aber vieles kann man nur mit selbst gebauten Funktionen und #define erreichen (so wie SPI2, 3 und 6). Glücklicherweise stört nichts, HAL und direkte Zugang zu Register auch aus Arduino zu nutzen.
Gerne. Ich experimentiere jetzt mit STM32H723 und mit Arduino GIGA, aber
auch ATMega1284P bleiben in Griff.
:-) das ganze auf einem Blackboard STM32H723VGT6 ?
Das evaluiere ich zur Zeit auch. Für 13 Euro ist das ein gigantisches Teil, allerdings hantiere ich dort mit libopencm3 ... und bin noch am schwer am "kämpfen". Grundsätzlich habe ich noch nicht wirklich eine Anwendung dafür, ein STM32F411 / F407 sind bisher absolut mehr als ausreichend für meine Dinge gewesen.
Mich reizt am H7 vordergründig der imensens Flashspeicher. Zudem, wenn ich das Datenblatt richtig lese, legt er nicht die üblichen Waitstates beim Flashspeicher lesenein (ich kann natürlich auch gründlich täuschen), was das ganze Kind extrem beschleunigen würde gegenüber einem F4.
Im Moment bastle ich auch an meiner Spielekonsole und lege dort im Flash meine Spiele ab, bisher habe ich hier 7 Spiele am laufen, die ich auch tatsächlich spiel (ich muß endlich mal ein PCB in sauber machen).
Auf einem H7 hätte ich Speicher ohne Ende und Grafiken wären extrem schnell berechnet.
Aber wie gesagt: dort bin ich noch sehr am evaluieren und ich bin erst einmal froh, dass ich UART und SPI hinbekomme, so dass ich dort ein SPI-TFT betreiben kann.
Für den TO hier bin ich am Überlegen, ob man nicht aus einem CH32V003 im I2C-Slave Mode betrieben, einen Textdisplayadapter mit einem OLED-Display machen kann.
Dann könnte man mit einem solchen SLAVE die Codes für ein HD44780 interpretieren und das dann an ein OLED schicken. Nach außen würde es dann keinen Unterschied machen, ob ein ein HD44780 Textdisplay über einen I2C-Adapter (mit PCF8574) oder über einen CH32V003 I2C-Slave Adapter mit einem OLED betreibe. Das OLED wäre damit zu einem Textdisplay degradiert.
Ich habe Board selber entworfen. Gerade aus China gekommen - um mit GIGA besser spielen zu können. Alles was ich brauche: MIDI-Buchsen (ich habe viele Musikinstrumente mit MIDI), zwei Poti mit Mitte-Null (z.B. um Tempo und Tonhöhe zu ändern, das wird bequemer als über Menu und Touch), Funkmodul (falls in Giga eingebautes Wifi zu kurzsichtig wird) und noch Kleinigkeiten. Giga wird TFT nach oben angeschlossen und alle Pins gut zugänglich.
Was Geschwindigkeit von Giga betrifft: ich habe Vergleich mit Arduino MEGA2560 und TFT 3,5'' über 8bit Parallelbus gemacht. Ein Zeichen auf dem Bildschirm macht Giga um 70x schneller.
Leider kann SD-Card nicht in 4bit-Modus angeschlossen werden: dafür notwendige Kontakte sind für externe Flash und SRAM verbraucht. Aber vielleicht kann man das tolerieren, da USB-Wechselspeicher möglich ist, anzuschließen. Ähnlich wie bei Arduino Mega2560 kann man USARTs nur als UARTs benutzen, ohne CLK. Dabei ist nur SPI5 auf äußere Pins geführt. Wertvollere (da 32 bit kann, und SPI5 nur 16 bit, kritisch bei NSS-Automatik: z.B. wenn 2x MAX7219 in Serie angeschlossen) SPI1 kann man über Pins in der Mitte haben. Beide sind mit Arduino-Funktionen zugänglich. Über Manipulationen mit Register kann man noch SPI2 und 3 (auf Kosten von DAC) und SPI6 (ohne NSS) bekommen, aber Funktionen muß man dafür selber schreiben.
Ansonsten könnten viele fertigen LIBs viel Zeit sparen.
oha, da hast du eine schöne Platine zum experimentieren. Daumen nach oben,
Du hast also einen orginalen Giga-Arduino und betreibst das auch unter Arduino?
Ich habe nur ein China-Board und war interessiert, wie gut das Ding ist (Spieltrieb halt).
Mit Arduino hantiere ich immer nur allerhöchst sporadisch und das auch niemals für mich selbst. Im Moment etwas mehr, weil ich "Libraries" für den CH32V003 schreibe, da viele Arduino Programme (meistens sind die für AVR) darauf nicht laufen.
Mich würde nur mal kurz interessieren, wie viel Flashverbrauch der Giga für ein einfaches Blinkprogramm benötigt (obschon das fast schon egal ist, weil das Teil sowieso sehr sehr viel davon hat).
Erstmal vielen Dank für die ausführlichen Antworten.
Die Fragen sind also beantwortet.
Kein Charakter-ROM, das mit ASCII Steuerwort angesprochen werden kann.
Das ist jetzt sonnenklar.
Dann Tabellen erstellen, die an "User defined Charakters" erinnern.
Es ging noch um die Frage, ob Verweis auf Tabelle genügt, oder beim "Schreibvorgang" pro Zeichen (Charakter) wirklich jedes Pixel einzeln angesprochen werden muss.
Also Spalte und Zeile. Punkt für Punkt.
Dafür ist mir die Angabe der Befehlsfolge extrem wichtig.
Genau das , was @jjflash schrieb, suchte ich:
oled_cmd(0xae); // display off
oled_cmd(0x20); // set memory addressing mode
oled_cmd(0x00); // horizontal addressing mode
etc...
Und:
Bitmap eines 8x8 Pixel Zeichensatzes
Nochmals danke dafür.
Jetzt geht es weiter.
Und, wie gesagt, wenn es dann über die Grundlagen hinausgeht, man ein Projekt ohne viel Hexerei realisieren möchte, sieht es so aus, dass man um
Installation der Arduino-IDE2.3.8, evtl. Arduino Nano o.ä. nicht herumkommt.
Bis bald,
und nochmals ein großes Dankeschön an alle, die sich die Mühe gemacht hatten, hier ausführlich zu antworten.
Und, wie gesagt, wenn es dann über die Grundlagen hinausgeht, man ein
Projekt ohne viel Hexerei realisieren möchte, sieht es so aus, dass man
um
Installation der Arduino-IDE2.3.8, evtl. Arduino Nano o.ä. nicht
herumkommt.
Natürlich kommt man da drum herum, das ganze was ich dir hier gepostet habe ist ohne Arduino gemacht. Alles mit Makefile, Text mit Texteditor (bspw. Geany o.ä.). Aufgesetzte Toolchain, Geany ruft Makefile auf !
Ging dann um weitere Anwendungen, denn das Target Attiny wird dann doch
wohl zu knapp bezüglich Speicherplatz etc.
Was hättest du denn gerne für ein Target. Grundsätzlich auch: willst du das wirklich in Assembler machen ????
Alleine das Referenzieren der Bitmaptabele der Fonts und die spätere Ausgabe ist nicht wirklich lustig. C / C++ ist da schon sehr hilfreich, Arduino ist es eher weniger, weil der Overhead den Arduino da erzeugt (ich bin da gerade an einem anderen "Projekt" mit CH32V003) ist da schon enorm und frißt gut Speicher.
der Vorteil vom Pixeldisplay ist auch das man frei Hochformat oder
Querformat wählen kann.
Und auch daß man GLEICHZEITIG deutschen ÄÖÜäöüß und kyrillischen
verwenden kann.
oder ein hochgesetztes ° für °C oder -> und <- und up/down Pfeile einsetzen kann, Pixeldisplays sind schon geil und die Methode es platzsparend im Flash statt im Ram unterzubringen ist auch geil, doof nur wenn Flash und RAM ausgehen (ATmega328*) deswegen mag ich den m128p
doof
nur wenn Flash und RAM ausgehen (ATmega328*) deswegen mag ich den m128p
Falls ich nicht zu viele Pins bei AVR brauche, nehme ich immer ATmega1284P. 128 k Flash, 16 k SRAM, JTAG möglich. Auch 0,8 mm Raster ist lötfreundlicher als 0,5 mm Raster von mega2560.
Mich würde nur mal kurz interessieren, wie viel Flashverbrauch der Giga
für ein einfaches Blinkprogramm benötigt (obschon das fast schon egal
ist, weil das Teil sowieso sehr sehr viel davon hat).
Egal was ich mache, mindestens 111k Flash und 47k SRAM gleich weg.
"Sketch uses 111384 bytes (5%) of program storage space. Maximum is 1966080 bytes.
Global variables use 47504 bytes (9%) of dynamic memory, leaving 476120 bytes for local variables. Maximum is 523624 bytes."
Auch bei Arduino mit AVR ist das nicht viel anders: System braucht Init.
Andere Seite wäre interessant zu klären:
Mit AVR ist Arduino-Art, mit Pins zu hantieren, zeitaufwendig, das ist Preis für die Möglichkeit, Pins als Var zu geben. Deshalb wird die Arbeit mit Pins über direkte Port-Anweisungen (z.B. über Makro, Hauptsache alle Berechnungen schon von Compiler gemacht) deutlich schneller.
Ob das so mit Arduino mit STM32 bleibt, ist unklar: STM32 kommt auf Register sowieso über Zeiger, so ist CPU gemacht. Könnte sein, das "digitalWrite" fast genau so schnell gemacht wird wie auch GPIOA->ODR |= (1UL<<5) . Zwar wird bestimmt auch hier atomare Variante über BSRR etwas schneller. Auch habe ich nicht gefunden, wie man mit Arduino-Funktionen die Pins einstimmen kann: push-pull oder open-drain, Alternate function, speed - alles kann man direkt über Register machen.
Auch habe ich nicht gefunden, wie man mit Arduino-Funktionen
die Pins einstimmen kann: push-pull oder open-drain, Alternate function,
speed - alles kann man direkt über Register machen.
So geht das:
1
pinMode(PB1,OUTPUT);// push-pull
2
pinMode(PB1,OUTPUT_OPEN_DRAIN);
Es gibt keine Arduino Funktion, um die Alternate Funktion eines Pins einzustellen. Das ist Aufgabe der jeweiligen Library, in deinem Fall Wire:
Danke für Info!
Z.Z. löte ich die Platine für Giga. Bisher könnte ich nicht so viel mit
Giga machen, da mit TFT zusammen alles schwer zugänglich war. Und ohne
TFT sehe ich in Giga wenig Sinn.
Ich möchte nach Möglichkeit Funktionen von Arduino benutzen. Aber ich
möchte auch versuchen, SPI2, SPI3 und SPI6 zugänglich zu machen. Dafür
muß ich aber Alternate Funktionen umschalten. Aber Hauptgrund für Giga
ist Wunsch, fertige Libs zu nutzen, deshalb zu viel in dieser Richtung
plane ich nicht. Volle Freiheit werde ich auf einer anderen Platine
haben, mit H723, die auch schon bereit zum Löten ist. Dann natürlich
HAL. Und vielleicht auch einige Libs, die ich mit Giga erproben werde.
Auf der Platine mit H723 habe ich externe SRAM und FRAM über Octo-SPI
vorgesegen. Ob es damit wirklich gut klappt, bleibt noch eine Frage.
Mit Giga ist für mich noch interessant, ob ich den zweiten, F4-Kern
irgendwie sinnvoll verwenden kann.
Nimm für die I2C Pull-Up Widerstände besser 2,2 kΩ. Deine geplanten 10
kΩ sind für viele Fälle zu hochohmig. Es soll mindestens 1 mA fließen.
Viele Module haben eigene I2C Pull-Up. Deshalb habe ich auch diese 10k über Lötbrücken angeschlossen. Über I2C4 geht schon sowieso RGB-LED auf der TFT-Platine, so gibt es dort schon diese Widerstände.
Kuck mal bei Mouser, was STM32H747 kostet. Alleine, ohne externe Speicher, ohne WIFI-Modul, ohne Platine... Giga kostet nur 1x Tanken, so ist das heute...
Ich habe bei Ebay H723-Module gekauft. Aber ohne Schaltplan kann ich damit wenig anfangen (Schaltplan habe ich leider nirgendwo gefunden). In jedem Fall ist das nur H723 + Quarz, + Möglichkeit 0,5 Pin-Raster nicht löten zu müssen, wer das nicht kann. Mehr ist das nicht.
Die alten ATmegas sind leistungsmäßg und
finanziell nicht mehr zeitgemäß.
Vor allem bin ich geärgert, daß die Entwickler alles Mögliche getan haben, damit man USART nicht in SPI-Mode benutzen kann. Keiner von vier! Aber das bleibt auch bei Giga so.
.... hm, irgendwie - like ever - driftet irgendwann jeder Thread zu einem anderen Thema ab, auch wenn ich das Thema relativ spannend finde.
Ich finde den Arduino Giga auch sau-teuer (und um ehrlich zu sein wußte ich gar nicht, dass es diesen gibt).
Ich habe ein Board, wo ein STM32H723 drauf ist, vllt. werde ich auch einmal ausprobieren, wie sich dieses unter der Arduino IDE verhält, aber grundsätzlich mag ich das mit der Arduino IDE eigentlich nicht machen.
Interessant wäre hier für mich, wie komplett ist ein offizieller Arduino Core ältumgesetzt.
Mein Spieltrieb kennt hier fast keine Grenzen, bspw. hatte ich mir einen Arduino Uno R4 besorgt (Reneasas Controller), nur um zu sehen, wie der Core sich verhält und um zu sehen, wie gut der ist... und nach 2 Stunden spielen liegt der jetzt in der Ecke und ist uninteressant für mich.
Arduino mache ich meisgtens nicht und als "normales" Controllerboard war hier jedes STM32F4 Board besser...
Aber wie gesagt: irgendwann driftet jeder Thread ab (und ich bin ja nicht ganz unschuldig) und hoffe, dass der TO seine Infos zu seinem Display bekommen hat. Allerdings hat er sich immer noch nicht geäußert gehabt dazu, auf welcher Platform nach einem Attiny2313 er das betreiben will.
:-) grundsätzlich schon ein krasser Unterschied: von einem Tiny2313 zu einem STM32H7 ... die sind ja fast gleich... sozusagen
Arduino mache ich meisgtens nicht und als "normales" Controllerboard war
hier jedes STM32F4 Board besser...
Wirklich etwas kann man erst mit einem eigenen Board machen. Einer braucht mehr ADC, anderem sind USARTs mit CLK lieber, ein Dritter kann ohne PSSI nicht leben... Und alles zusammen kaum möglich, auch wenn LQFP-208...
HAL für STM32 ist auch etwas wie Arduino, nur etwas komplizierter aufgebaut.
Gestern habe ich eine Mega falsch "verfüßt". Wie kann man schnell einen Takt machen? Mit einer Arduino-Nano habe ich das in ein paar Minuten gemacht.
1
voidsetup(){
2
// put your setup code here, to run once:
3
pinMode(9,OUTPUT);
4
}
5
6
voidloop(){
7
// put your main code here, to run repeatedly:
8
while(1){
9
PORTB|=(1<<1);
10
asmvolatile("nop");
11
asmvolatile("nop");
12
asmvolatile("nop");
13
asmvolatile("nop");
14
asmvolatile("nop");
15
asmvolatile("nop");
16
PORTB&=~(1<<1);
17
asmvolatile("nop");
18
asmvolatile("nop");
19
asmvolatile("nop");
20
asmvolatile("nop");
21
}
22
}
Mit 16 MHz Quarz ist das genau 1 MHz.
Für so etwas ist Arduino ideal.
Das kannst du so pauschal nicht sagen. Wenn da fünf Module auf dem Bus hängen, summiert sich das.
Es kommt darauf an, wie viele Module auf dem Bus hängen, wie hoch die kapazitive Last - hauptsächlich durch die Kabel - ist und mit welcher Geschwindigkeit der Bus arbeiten soll.
Die 10kΩ auf vielen Modulen sind ein fauler Kompromiss für DAU-Aufbauten, um das Gejammer über "mein I2C-Bus geht nicht" zu reduzieren. Bei ernsthaften Aufbauten sollte man wissen, was man tut und vielleicht auch einen Blick in I2C-Spezifikation und Application Notes werfen.
und hoffe, dass der TO seine Infos zu seinem
Display bekommen hat. Allerdings hat er sich immer noch nicht geäußert
gehabt dazu, auf welcher Platform nach einem Attiny2313 er das betreiben
will.
Ja, danke für die zahlreichen Infos.
Jetzt ist bei dem Versuch, den Compiler Win AVR-GCC zu Installieren, um mich ein bisschen mehr mit "C" und Derivaten zu befassen, eine Fehlermeldung aufgetaucht und Studio 4 stürzt regelmäßig ab.
Problemereignisame: APPCRASH
Anwendungsname: AVRStudio.exe
Anwendungsversion: 4.19.0.730
Anwendungszeitstempel: 4e569ce0
Fehlermodulname: COMCTL32.dll
Bin erstmal raus hier, bis ich das "neue" Problem gefixt habe.
Mache dann evtl. einen neuen Thread auf.
Aber die Tips, auch mit STM32 zu arbeiten, sind bestimmt hilfreich für denjenigen, der bei der Suche auf diesen Thread hier stößt.
Die Sache ist doch recht komplex, und es gibt viele Leute, die gerne Ihre Erfahrungen mitteilen möchten, aber sich eventuell nicht trauten, direkt bei der Arduino-Forenseite zu fragen. Oder da nicht die passende Antwort fanden.
Nochmals vielen Dank für die zahlreichen Antworten.
Jetzt ist bei dem Versuch, den Compiler Win AVR-GCC zu Installieren, um
mich ein bisschen mehr mit "C" und Derivaten zu befassen, eine
Fehlermeldung aufgetaucht und Studio 4 stürzt regelmäßig ab.
Problemereignisame: APPCRASH
Anwendungsname: AVRStudio.exe
Anwendungsversion: 4.19.0.730
Anwendungszeitstempel: 4e569ce0
Fehlermodulname: COMCTL32.dll
Ich mache es mit AVRStudio 4.19 so:
avr-toolchain-installer-3.4.2.1573-win32.win32.x86.exe installieren (letzte Variante von toolchain mit Installer, setzt auch Ungebungsvariablen selber), danach avr8-gnu-toolchain-installer-3.6.0.1734 per Hand.
Ordner 4.7.2 für 5.4.0 gewechselt
D.h. Files mit gleichen Namen ersetzen, fehlende Ordner kopieren, und was alt ist so lassen.
Somit bekommt man u.a. die Möglichkeit, __Flash statt PROGMEM zu nutzen (das bringt viel höhere Flexibilität). Man kann so wohl auch spätere Toolchaine ausprobieren, ich habe das aber nicht gemacht. Hauptsache, nicht vergessen, bei einem neuen Projekt IMMER -gstrict-dwarf per Hand ergänzen: Project -> Configuration Options -> Custom Compilation Options -> [All files] -> Add. Sonst ist 4.19 bei Debug-Versuch gleich raus.
Um Problem mit USB-Treiber für Win11 zu vermeiden, benutze ich Atmel AVR JTAGICE mkII Debugger (China Clon natürlich) über externe USB/RS232 Converter (mit FT232). Das ist langsamer als über USB direkt, dafür aber sichere Arbeit auch mit Win11 (und nicht nur bis zu erster automatischen Erneuerung von Windows, die nicht abschaltbar ist). Um flexibler zu arbeiten, habe ich eine Adapterplatine gemacht, wo man JTAG über verschiedene Badewannestecker und Stiftleisten bekommt, auch 1117 mit 3,3-5 Volt Umschaltung ist da. Als praktisch hat sich Badewannestecker mit 2 mm Raster gezeigt: viel sparsamer mit Platz auf der Platine als mit 2,54 mm Raster.
Als Bonus von AVRStudio 4, diese Möglichkeit fehlt in späteren Studien: File c:\Program Files (x86)\Atmel4\AVR Tools\AvrStudio4\edit\AvrStudio_c.ini erlaubt selbst definierten Schlüsselworte mit Farbe hervorzuheben. Somit werden kleine Schreibfehler besser sichtbar. Als Beispiel lege ich hier von mir geänderten AvrStudio_c.ini bei. Dazu noch meindef.h, wo man die Wirkung sehen kann.
Jetzt ist bei dem Versuch, den Compiler Win AVR-GCC zu Installieren, um
mich ein bisschen mehr mit "C" und Derivaten zu befassen, eine
Fehlermeldung aufgetaucht und Studio 4 stürzt regelmäßig ab.
Quatsch. Was heißt "zu alt" ? Warum spiele ich Orgel aus dem 1842 und niemand sagt "zu Alt", und ein Programm aus dem 2011 schon "zu alt" ?
Mit vielen AVRs funktioniert das Programm gut, auch besser gemacht als späteren "Studios". Meine lieben ATmega1284 arbeiten mit dem Studio 4 perfekt. Paßt auch für ATMega2560, ATmega328P und vieles andere. Zwar nicht mit AVR128DB64 u.Ä. (die übrigens statt gewöhnlichen 10 000 nur 1000 cycles Flash halten). Wenn das wichtig, dann braucht man Studio 7. Ich habe beides auf dem Computer, auch verschiedene JTAG-Debugger dafür. Wenn möglich, wähle ich immer Studio 4.
Win11. JTAG über USB/RS232 Konverter, und ISP geht wunderschön auch direkt über USB: Waveshare AVR ISP Programmer mit berühmter CH340G aus China. Gerade habe ich damit die Fuse auf "Arduino die nicht gibt" mit ATmega1284P gestellt.
Das wird zwar auch seit einiger Zeit nicht weiterentwickelt, braucht aber noch nicht so viele Besuche im Sanitätshaus, um Inkontinenzeinlagen zu besorgen, wie es die völlig veraltete 4.x-Version nötig hat.
Und wenn man entweder zum richtigen Zeitpunkt gekauft hat oder etwas Aufwand* treibt, dann kann man Mplab Snap als kostengünstiges Programmier- und Debuginterface direkt via USB verwenden, statt mit Gehhilfen und Kompressionsstrümpfen zu hantieren.
*) Neuere Modelle werden mit unpassender Firmware vertrieben, die aber lässt sich durch eine ältere ersetzen:
Beitrag "Re: Ärgernis MPLAB Snap"
Kurzes Update:
Ein Arduiono Nano spricht ein Oled Display richtig an, das andere nicht.
Gleiche Adresse. Aber Zeilen sind zu klein, und Rest unten nur "Rauschen".
Da muss ich mich noch reinarbeiten.(Richtige Bibliothek auswählen).
Dann das obige Programm über einen REV AVR Disassembler laufen lassen und habe festgestellt, dass da "mul" als Befehl auftaucht.
Den hat der Attiny4313 nicht oder muss evtl. durch ein Makro zusammengebastelt werden. Der Speicherplatz für das übungsmäßig ausprobierte Analogwandlerprogramm ist auch schon zu groß für den Attiny.
Also, wer's schnell haben möchte, dann auf zum Arduino. Und zum Fuses verstellen brauche ich einen zweiten, der dann auf den Namen "ArduinoISP" hört.
Wie gesagt, nur als kleines Update. Rest folgt irgendwann.
Bei dem Originaldateinamenerweiterung *.ino wird direkt die Verknüpfung angestoßen. Das wollte ich vermeiden.
Hier noch das Bild vom Aufbau dazu.
Frage Richtige Dateieindung *.ccp, oder was schlagen die Experten vor.
Ohne, dass sich gleich das Programm öffnet. Gehe davon aus, dass nicht allerorten die IDE vorhanden ist.
Ganz einfach das was es ist, ich vermute mal eine *.ino Datei.
Die Leute, die sich fachlich damit auseinandersetzen wollen,
sind nicht so blöd einfach die die Verknüpfung anstossen zu
lassen. Nein, sie machen von vorne herein etwas Sinnvolles
damit. Sie denken sich etwas dabei und starten die für sie
geeignete Applikation, nicht die, die ein bevormundendes
Betriebssystem ihnen vorgibt.
Wenn Du *.ino verwendest, können andere die foreneigene Dateianzeige mit
Syntax-Highlighting verwenden.
Das muss man jemanden sagen der seit dem Jahr 2008 hier
angemeldet ist? Ich kann's nicht glauben ..... da gehört schon
viel Ignoranz und Beratungsresistenz dazu das nicht zu wissen.
Die Arduino-Geschichte ist für mich - muss ich zugeben- Neuland.
Bevor hier wieder Kommentare kommen, dass nicht jeder jede Datei mit jeder x-beliebigen Verknüpfung öffnen kann, war es nur allzu logisch, das Wesentliche eines Programmes in Textform zu konvertieren. Abgesehen davon würde der Text mit Copy&Paste auch im "Sketch" laufen.
Über den Inhalt des Programms wurde nicht diskutiert. Schon einmal eine erfreulichere Situation.
Dann biete sich den Kritikastern eben als Haar in der Suppe an, den Dateinamen zu ändern.
Wie man Programme lesbar hier als Anhänge einfügt, weiß ich spätestens ab 2009. "Nachhilfeunterricht" in der Hinsicht ist zwar nett gemeint aber leider nicht nötig.
Offensichtlich wird jetzt nicht mehr über Arduino hergezogen, was das Zeug hält, nein, sogar die Dateiendung *.ino erregt keinerlei Missfallen mehr. Das war hier schon einmal ganz anders, soweit ich mich erinnern kann.
Aber da Programme in Assembler noch teilweise nicht ganz auf dem Müllplatz der Geschichte gelandet sind, hier noch ein Disassemblat obigen *.ino-Files (auszugsweise).
Was fehlt, sind die erleuchtenden Kommentare und die Trivialnamen der
Register. Die müsste man sich selbst anhand des Dablas des Targets heraussuchen. Übrigens, eventuell eine nette kleine Aufgabe für KI?
Sehr gut. Wenigstens verbal hat der Mann Mumm.
OK. Aber zurück zum Thema, wir wollen ja einen deeskalierenden Eindruck hinterlassen:
KI liefert mir die "Initialisierung" für den Mega328 ohne mit der Wimper zu zucken.
Gerade ausprobiert. Sieht nicht schlecht aus. Könnte eventuell sogar funktionieren.
Aber nur die Initialisierung. Die Pixelansteuerung fehlt noch.
Mittlerweile Programmierkünste gediehen zu Voltmeter für zwei Spannungen.
In INO sieht das so aus. Viel Spaß weiterhin mit dem Arduino.
Ging dann um weitere Anwendungen, denn das Target Attiny wird dann doch
wohl zu knapp bezüglich Speicherplatz etc.
ATtiny ist nicht gleich ATtiny. Die gibt es bezüglich des verfügbaren Flash-Speichers in recht breiter Auswahl, so ca. von 0,5kB..8kB.
Der wichtigste Trick ist aber sicher die weise Beschränkung des Zeichensatzumfangs, sprich: Reduktion auf die tatsächlich in der Anwendung benötigten Zeichen. Diese Maßnahme ist sehr einfach umzusetzen und meist überaus wirksam.
Außerdem können auch Sachen zum Einsatz kommen wie etwa "kompaktierte" oder gar tatsächlich komprimierte Font-Daten. Das ist dann schon ein wenig schwieriger, aber es ermöglicht z.B. den ROM-Font eines HD44780 in den 2k Flash eines ATttiny2313 unterzubringen und dann trotzdem noch einiges an Flash für das Programm über zu haben.
ATtiny ist nicht gleich ATtiny. Die gibt es bezüglich des verfügbaren
Flash-Speichers in recht breiter Auswahl, so ca. von 0,5kB..8kB.
Mir erschließt sich nicht, warum man sich Mitte der 2020er-Jahre für derartige Dinge gerade einen Dinosaurier wie den 2313/4313 aussucht. Es gibt mittlerweile AVRs, die in sämtlichen Kriterien um ein Vielfaches besser ausgestattet und gleichzeitig auch noch wesentlich preisgünstiger sind. Viele davon sogar in DIP erhältlich (wenn man's denn unbedingt braucht). Das scheint sich nur noch nicht überall herumgesprochen zu haben.
Ich hätte mir jetzt eher Kritik am zuletzt geposteten *.ino Programm - oder wie das jetzt heißt "Sketch"- erhofft.
Denn:
Einige gelbe Striche sind zu sehen, die da nicht hingehören. Die tauchen synchron zur Anzeige der folgenden Zeile auf.
Die Positionierung mit "ungeraden" Werten war testweise gewählt worden, um das Display maximal ausnutzen zu können. Offensichtlich ist da der Fehler zu suchen.
Aber zurück zu der Ursprungsfrage. Der Attiny4313 wurde deswegen ins Spiel gebracht, um die "einfache" Initialisierungsroutine und die "einfachste" Pixelansteuerung vom Prinzip her besser zu verstehen.
In Kürze nochmal zusammengefasst, wo es Probleme geben kann:
I2C Adresse sinnigerweise 7-bittig, soll 8-bittig umgemodelt werden.
Also 0x3C ist dann als 0x78 einzugeben.
Dann die USI-Schnittstelle so konfigurieren, dass eine vernünftige Kommunkkation erst ermöglicht wird. Dabei fällt sofort auf, dass die Sequenz I2C-Stop nirgends erscheint. Also da nochmal ansetzen.
Ferner: Die Befehlsfolge für Kommandomodus beim OLED lautet einmal 0x00
oder 0x80. Das eine Tutorial erklärt 0x00 als Umschalten in den Kommandomodus, wobei danach weitere Kommandozeilen folgen können.
Und genau andersherum wird es im anderen Tutorial erklärt:
Die Eingabe 0x80 bedeutete dieser Lesart zufolge, danach können mehrere Befehle bzw. Befehl mit nachfolgendem näher bezeichnendem Argument eingegeben werden.
Also:
ldi temp, 0x00
rcall I2C_out
ldi temp, 0x81
rcall I2C_out
ldi temp, 0xCF
rcall I2C_out
ret
Oder:
ldi temp, 0x00
rcall I2C_out
ldi temp, 0x81
rcall I2C_out
ldi temp, 0x00
rcall I2C_out
ldi temp, 0xCF
rcall I2C_out
ret
Was ist jetzt richtig, nicht ganz falsch oder total falsch.
Dann die Pixelung. Soweit bin ich noch nicht. Das kommt (vielleicht) demnächst einmal in ferner Zukunft.
Da sich aber zunächst Arduino hier dazwischengemogelt hat, wird der solange traktiert, bis überhaupt erst einmal etwas halbwegs Vernünftiges im Zusammenhang mit den mittlerweile nicht nur sondern auch bei "Bastlern" extrem beliebten OLED-Displays dabei herauskommt.
Ausserdem stiften harte Fakten und technische Daten eher
Verwirrung
Es ist ein SSD1315. Das Dabla habe ich schon vor dem Posting hier studiert.
Wo steht der korrekte Befehl nun drin?
Und: Was ist Befehl, was ist Argument.
Einbyte, Zweibyte, Dreibytebefehle?
Und keine Idee oder Kommentar dazu?
Karl B. schrieb:
Einige gelbe Striche sind zu sehen, die da nicht hingehören. Die tauchen
synchron zur Anzeige der folgenden Zeile auf.
doch du hast aussortierte Reste vom Chinaschrott bekommen, die liefern durchaus gute Ware, aber die Reste werden u.U. von findigen Kinesen aus dem Schrott gesammelt und trotzdem an Langnasen verkauft.
Ich habe bei Displaybestellungen schon immer einen gewissen Anteil Schrott dabei gehabet, 5 Displays gut 3 unangeschlossen mit sichtbaren Fehlern.
doch du hast aussortierte Reste vom Chinaschrott bekommen.
Kann sein:
Das andere, etwas größere zeigt nur "Schnee".
Und dann die Sache mit den Pullupwiderständen.
Laut Dabla (1315-er) ca. 300 kOhm. Laut allgemeiner Forenteilnehmerzustimmung im Bereiche zwischen 10 und 5,6 kOhm von SCl sowie SDA nach Vcc (5V bzw. 3,3V).
Das Display im Bild läuft aber so, ohne Extra-Widerstände drauflöten zu müssen.
Sind Kleinigkeiten. Aber keiner sagt: So oder so oder garnicht. Basta.
Nun ja, ich nehme an, die Pixel-Ansteuerung ist noch nicht pefekt. Ausprobieren angesagt.
Die zu optimierenden Zeilen:
// zweite Zeile mit Zähler
display.setCursor(0,15);
Deswegen fragte ich oben ja bereits, ob "ungerade" Werte da überhaupt den Konventionen entsprechen.
Die Positionierung mit "ungeraden" Werten war testweise gewählt worden,
um das Display maximal ausnutzen zu können. Offensichtlich ist da der
Fehler zu suchen.
Oder auch nicht. Wer ist von Euch der Schlaumeierste?
Danke.
du verwürfelst einige Dinge zusammen, aber wenn du auf dem Display schon etwas siehst, kann es so schlimm noch nicht sein.
Erstens hast du einen Datentransfer, hier für dieses Display namentlich I2C. Für diesen Datentransfer gibt es ein Protokoll und hier "streiten" sich die Leute, ob das r/w Bit am Ende einer Adresse zu einer 8-Bit Adresse gehört oder nicht. Wenn nicht, ist die 7-Bit Adresse um eine Bitposition nach links zu schieben und an Bitposition 0 das read/write Bit einzufuegen. Wenn das schon einmal klappt (und das klappt dann, wenn man bspw. schon ein Rauschen auf dem Display sieht), geht es an das Datenblatt des Controllers. Der Einfachheit halber habe ich dir ein reines C-Programm hier gepostet, bei dem das I2C über Bitbanging funktioniert. Wenn man über Bitbanging etwas am Laufen hat, kann man daran gehen, Hardware I2C zu verwenden (aber das scheint bei dir auch schon zu laufen, sonst würdest du am Display nichts sehen).
Zweitens: wenn I2C läuft, geht es an das Protokoll des Displays um dieses mit Steuerbytes und anzuzeigenden Bytes zu beschreiben. Beim Studium meines Codes hätte dir auffallen können:
i2c_write(0x40); // 0x40 = Wert, dass ein Datenbyte folgt
24
i2c_write(data);
25
i2c_stop();
26
}
Hier solltest du überdeutlich sehen (auch ohne Datenblatt), dass ein Steuerkommando wie es bspw. zum Initialisieren des Displays benötigt wird, ganz klar den Wert 0x00 hat. Aus diesem Grund heißt die Funktion hier auch "oled_cmd" weil sie ein Kommandowert schreibt. In "oled_data" wird ein Datum in das Videoram des Displays geschrieben, Daten eben. Hier ist vor der Datenübertragung der Wert 0x40 zu senden, von da an weiß das Display: Aha, ab hier anzuzeigende Daten.!
drittens: Dein "Pixelzeugs". Das Display hat das Videoram derart adressiert, dass immer 8 Pixel gleichzeitig geschrieben werden. Einen einzelnen Punkt kannst du hier nicht setzen / löschen. Aus diesem Grund ist bei diesen Display, wenn man Grafik machen möchte, zwingend ein Framebuffer notwendig. Das ist im Grunde nichts anderes, als ein C-Array, das den Bildinhalt, den das Display haben soll, "spiegelt", D.h. es hat denselben Inhalt wie das Display selbst. Hier mußt du Funktionen schreiben, die ein einzelnes Bit im Byte eines Array setzen bzw. löschen. Wenn du das Bild in diesem Array aufgebaut hast, schickst du dieses über I2C komplett an das Display.
By the way: I2C mit dem USI eines ATtiny ist Hardcore. Viel Spaß dabei (ich hatte keinen) und ich glaube auch nicht, dass das mit dem Overhead eines Arduino zu schaffen ist. Zudem: Ein ATtiny2313 oder auch 4312 hat nicht genügend RAM für einen Framebuffer. Die Größe des Framebuffers beträgt: 128x64 Pixel / 8 = 1024 Byte .
Durch 8 deshalb, weil ein Byte 8 Pixel aufnimmt
Die gelben Striche auf deinem Display könnten auch daher kommen, dass evtl. Der Zeichensatz nicht korrekt ist, oder bei Übertragen des Zeichensatzes irrtümlich eine 1 mit Übertragen wird (die da nicht hingehört). Sicherlich ist dieser Strich kein Fehler in der Initialisierung
Merkt ihr denn nicht wie ihr vom Troll vorgeführt werdet?
sagen wir so, es ist möglich aber auch um µC.net oben zu halten, wird sowieso immer weniger wert hier reinzuschauen, die Wissenden sterben aus, die Trollbeiträge werden gefühlt immer mehr und da wir hier nichts bezahlen gönne ich dem Andreas die Werbeeinnahmen für etwas mehr Action hier.
Ich käme mir sehr blöd vor wenn ich an einen Troll soviel
Text verschwenden würde.
Die tollsten Fachleute haben die engsten Scheuklappen und sie
schaffen es nicht über den Tellerrand hinauszublicken. Oder
sie spielen dieses blöde Spiel der nicht enden wollenden
Diskussion mit, im Sinne von Internet Schrott Traffic fördern.
Oft kommen aber nach einiger Zeit noch durchaus brauchbare "IME"- Antworten. Gerade die oben erwähnte USI-Geschichte beim Attiny2313 war ja einmal heftigster Diskussionsstoff hier. Und das Programm habe ich davon "abgekupfert". Kann also durchaus noch einmal jemand drüberschauen im Sinne einer für den Zweck einer OLED-Display-Ansteuerung praxistauglichen Lösung.
Oft stolpert man über - wie man hinterher beschämt feststellen muss - die trivialsten Dinge.
Beispiel die HD44780-LCD-Initialisierung wollte bei mir vor Jahren überhaupt nicht funktionieren, obwohl ich damals genau das Programm, das hier im mittlerweile nicht mehr vefügbaren Tutorial in AVR asm benutzt hatte.
Der Fehler: Temporärdateien für Argumente vorher nicht gepushed und hinterher gepopt, die für andere "Aufgaben", zum Beispiel Zeitschleifen, dringend gebraucht wurden. Manchmal sogar SREG sicherungsbedürftig, aber auch nicht zu viel Pushen und Popen. Da die richtige Balance zu finden, ist unter Umständen garnicht so allgemeinverständlich.
Freue mich jedenfalls über weitere konstruktive Beiträge!
Der Fehler: Temporärdateien für Argumente vorher nicht gepushed und
hinterher gepopt, die für andere "Aufgaben", zum Beispiel Zeitschleifen,
dringend gebraucht wurden.
Das ist einer der wirklich großen Vorteile von Assembler, daß man sich damit noch viel, viel besser in den eigenen Fuß schießen kann, als mit angeblich "unsicheren" Programmiersprachen wie C.
das hier im mittlerweile nicht mehr vefügbaren Tutorial in AVR asm
Super. Merci villmols.
Jetzt in AVR asm auf OLED umhäkeln. Ich versuch's bei Gelegenheit einmal. Momentan andere Baustellen.
Wenn fertig, dann poste ich hier das Ergebnis. Großes "Indianer-Ehrenwort".
Bis bald
ciao
gustav
BTW: Ähhm poltical correct: American Native-Ehrenword
Der Fehler: Temporärdateien für Argumente vorher nicht gepushed und
hinterher gepopt, die für andere "Aufgaben", zum Beispiel Zeitschleifen,
dringend gebraucht wurden.
Das ist einer der wirklich großen Vorteile von Assembler, daß man sich
damit noch viel, viel besser in den eigenen Fuß schießen kann, als mit
angeblich "unsicheren" Programmiersprachen wie C.
Falsche, weil unlogische Betrachtungsweise. C ist unsicherer als reiner Assembler.
Das liegt daran, dass Inline-Asm Teil der Sprachdefinition von C ist. Damit hat man schon mal die Freiheit, alle in Asm möglichen Fehler auch in C zu machen.
Zusätzlich steht einem aber auch noch der gesamte Fehlerraum zu Verfügung, den C selber aufspannt. Der ist zwar in weiten Teilen kongruent mit den in Asm möglichen Fehlern, aber nicht vollständig. Er bietet durchaus einige Extra-Features...
Das liegt daran, dass Inline-Asm Teil der Sprachdefinition von C ist.
Ist es nicht wirklich:
Unlike in C++, inline assembly is treated as an extension in C.
It is conditionally supported and implementation defined,
meaning that it may not be present and, even when provided
by the implementation, it does not have a fixed meaning.
Unlike in C++, inline assembly is treated as an extension in C.
It is conditionally supported and implementation defined,
So viel zur Theorie. Praktisch gibt es keine einzige C-Implementierung ohne Inline-Asm. Warum wohl? Die Antwort auf diese Frage liefert dann auch gleich die Erklärung, warum es für C++ sogar mandatory geworden ist.
Praktisch gibt es keine einzige C-Implementierung
ohne Inline-Asm.
Auf der verlinkten Seite werden sehr reale Varianten genannt:
MSVC does not support inline assembly on the ARM and x64 processors,
and only support the form introduced by __asm on x86 processors.
Das ist ein sehr weit verbreiteter und oft genutzter Compiler, kein bizarrer Exot, den ich zur Bekräftigung eines Arguments aus irgendeiner Mottenkiste hole.
Man kann auch gut ohne Inline-Assembler auskommen, der ist nur "bequem". Andere schreiben dann halt reine Assemblermodule, wenn sie denn der Ansicht sind, irgendwas in Assembler programmieren zu müssen.
In den jetzt über drei Jahrzehnten, die ich als Embedded-Entwickler meinen Lebensunterhalt verdiene, habe ich nur sehr, sehr wenig in Assembler schreiben müssen. Das war gegen Anfang der 90er mal ein sehr primitiver DOS-Devicetreiber (mit dem ich eine Interprozesskommunikation zwischen Windows 3.0 und einem in der VDM laufendem DOS-Programm hinbekommen habe), und davor etwas 8-Bit-Mikroprozessorzeugs.
Aber sonst? Vielleicht mache ich ja meinem Arbeitgeber nur etwas vor, und der bezahlt mich dafür, daß ich meinen Namen tanze - dann aber tut der das mit beeindruckender Hartnäckigkeit. Und nein, das ist kein ÖD.
Auf der verlinkten Seite werden sehr reale Varianten genannt:
MSVC does not support inline assembly on the ARM and x64 processors,
and only support the form introduced by __asm on x86 processors.
Und du ziehst daraus den Schluß, das es nicht möglich wäre, mit der verfügbaren Form auch 64Bit-Targets zu bespaßen?
Das sagt dann eigentlich bereits alles über deine Asm-Kompetenz. Wie willst du mit diesen Fähigkeiten Fehler im Compiler finden?
Hint: ich warte jetzt eigentlich nur noch auf deine Behauptung, dass es selbige nicht gäbe, dass also alle C-Compiler sozusagen von Natur aus fehlerfrei sind. Dann machen wir aber besser einen neuen Thread auf. Denn das hat dann ganz sicher nichts mehr mit dem Topic des OT zu schaffen...
Hint: ich warte jetzt eigentlich nur noch auf deine Behauptung, dass es
selbige nicht gäbe, dass also alle C-Compiler sozusagen von Natur aus
fehlerfrei sind.
Sowas kommt nicht. Natürlich gibt es Compilerfehler.
Allerdings: Von der Existenz von Compilerfehlern sind erstaunlicherweise besonders oft Programmieranfänger betroffen. Gerade die finden die sehr gerne.
Ich war auch mal felsenfest davon überzeugt, einen ganz dicken Fehler gefunden zu haben. Felsenfest.
Im Gegensatz zu gewissen anderen Personen aber habe ich seitdem dazugelernt.
Sowas war natürlich zu erwarten. Man kennt Dich ja, wobei Du jetzt schon
fast mobyeske Züge annimmst.
Hauptsache ein fest gefügtes Feindbild und niemals dazu lernen. So kennt man dich.
Natürlich gibt es Compilerfehler.
Dann sind wir uns doch zumindest in einem ganz wesentlichen Punkt einig. Nun musst du nur noch darlegen, wie du sowas ohne Asm-Kompetenz finden willst.
Allerdings: Von der Existenz von Compilerfehlern sind erstaunlicherweise
besonders oft Programmieranfänger betroffen.
Natürlich nicht wirklich. Sie glauben das oft nur. Das ist nicht zu bestreiten. Liegt aber durchaus auch daran, dass C nicht gerade einsteigerfreundlich ist, sondern eine Scheiß-Sprache, von der nur behauptet wird, dass sie eine Hochsprache wäre.
Tatsächlich ist es nach wie vor ein maßlos aufgedonnerter Makro-Assembler. Daran hat sich niemals etwas geändert. Die Makros (die man früher(tm) wenigstens noch einfach nachlesen konnte) sind nur größtenteils in den Compiler selber gewandert und man muß sie erst in dessen Quelltexten finden. Das ist eigentlich auch schon fast alles.
Nun musst du nur noch darlegen, wie du sowas ohne Asm-Kompetenz finden
willst.
Wie kommst Du auf die bizarre Idee, ich hätte keine? Nur, weil ich den Scheiß nicht beruflich verwenden muss, heißt das doch nicht, daß ich ihn nicht kennen und verstehen würde.
Hi,
was @JJFlash schrieb
Beitrag "Re: I2C Display einfache Frage"
war nicht das, was mich zum Nachfragen anregte.
Die 0x00 als Kommando
aber auch 0x80 wird als Kommando bezeichnet.
Und zwar einmal, dass mehrere Befehle hintereinander folgen.
(Befehl und Argument bzw. Parameter z.B. Kontrast und dann, welche Kontraststärke etc.)
Und zum anderen, dass nur ein Befehl folgen darf. Sonst immer nochmal die Anweisung "jetzt kommt ein Befehl".
Klingt simpel, aber das ist nun einmal mein Wissensstand.
Und an etwas mehr gehirnschmalzfordernde AVR Asm Progrämmchen hatte ich mich schon mal rangewagt. Beispiel:
Beitrag "MSF60 Dekoder AVR Teil_2"
Ehrlich gesagt, das Grundgerüst stammt von @Scott Falk Huehn, aber ich habe mir die Frechheit herausgenommen, es auf MSF60 umzuschreiben, wobei das Problem mit den DUT "Doppelimpulsen" zu umschiffen war.
Wie man das in C++ hätte ummodeln können, dazu hätte ich absolut keinen Zugang.
Jede Sprache braucht Einarbeitung, jeder fängt einmal ganz unten an.
Ich bin noch im tefsten Keller, was meine C-Kenntnisse anbelangt.
Aber das mit ASM betrachte ich eher als Hobby und eine nette Freizeitbeschäftigung, keine Notwendigkeit beruflicherseits.
Ja, deine Sichtweise scheint mir doch arg .....
Für mich ist das Zauberwort "Portabilität".
In der Arduino Welt habe ich mit mindestens einer Handvoll µC Typen zu tun.
z.B. AVR, ESP in min 3 Varianten, ARM, K210
Da ist die Krake C, oder C++, doch wesentlich angenehmer/praktikabler als die vielen kleinen ASM Inseln.
Die Frage ist leider noch nicht beantwortet:
Also:
Befehlsmodus 0x00 oder 0x80
welche Unterschiede?
Am besten ich probier es einfach 'mal aus.
Dann werde ich vom Fragenden zum Beantwortenden ;-)
Und das MSF60-Programm in ASM bekommt heute noch ein Update:
Änderung: Wochentagkürzel auf Englisch. ;-)
Wärest Du so freundlich und würdest den Link nochmal posten, beim Rückscrollen hier sind eine Menge Links, welchen meinst Du jetzt genau:
Oder auch nur Seitenangabe.
Ich hatte mir folgendes Datenblatt nicht nur heruntergeladen, sondern auch angesehen. Und da keine Antwort auf die Frage gefunden, die so eindeutig ist, dass ich sie auch 1:1 umsetzen kann.
Ich hatte mir folgendes Datenblatt nicht nur heruntergeladen, sondern
auch angesehen. Und da keine Antwort auf die Frage gefunden, die so
eindeutig ist, dass ich sie auch 1:1 umsetzen kann.
Das ist das erste Bild, das Hans hier gepostet hat:
Datenblatt ist einfach zu kompliziert formuliert und ohne praktisches Beispiel. (Und auch wieder in 7-Bit Format.)
KI sagt das:
"...In der Kommunikation mit dem
SSD1315-Display-Controller (oft über den I2C-Bus) hat der Wert 0x80 zwei Hauptbedeutungen, je nachdem, ob er als Steuerbyte oder als Parameterwert innerhalb eines Befehls verwendet wird:
Als I2C-Steuerbyte (Control Byte)
Wenn du Daten per I2C an das Display sendest, erwartet der SSD1315 nach der Geräteadresse (z. B. 0x3C) ein Steuerbyte, das dem Controller mitteilt, was als Nächstes folgt.
0x80: Bedeutet, dass das nächste Byte ein Befehl (Command) ist und dass danach weitere Befehle folgen können.
Technischer Hintergrund: Das Bit 7 (Co-Bit) ist auf 1 gesetzt, was signalisiert, dass weitere Steuerbytes folgen können. Bit 6 (D/C#-Bit) ist auf 0, was den Modus auf "Kommando" festlegt.
Vergleich:
0x00: Nur ein einzelner Befehl (oder eine Kette von Befehlen ohne weitere Steuerbytes).
0x40: Es folgen Bilddaten (Data) für das GDDRAM..."
Und nichts anderes wollte ich wissen.
Trotzdem vielen Dank an die Hinweisgeber auf die Seiten im Datenblatt. Thumbs up!
Datenblatt ist einfach zu kompliziert formuliert und ohne praktisches
Beispiel. (Und auch wieder in 7-Bit Format.)
Das ist jetzt ein sinnloser Nebenkriegsschauplatz. Die Adressierung von Geräten am I2C-Bus erfolgt mit 7-Bit-Adressen. Das steht so in der Spezifikation, und jeder, der mit I2C arbeitet, versteht das -- oder sollte das tun, weil er sonst völlig sinnlos Lebenszeit von sich und anderen verschwendet.
Gebe ich im Dabla per Strg F 0x00 ein, lande ich auf Seite 15, die ein anderes Thema behandelt.
Gebe ich Dabla per Strg F 0x80 ein, lande ich auf eben derselben Seite.
Wäre das so extrem schwer, im Dabla einfach ein klares Statement abzugeben:
b00000000 als Befehl "Command",
b10000000 als Befehl "Command", dem "Argumente" bezüglich vorausgegangener Einstellung folgen können, ohne, dass nochmals unmittelbar pro Einstellungsparameter der Befehl "Command" 0x00 explizit vorausgegangen sein muss.
So sehe ich das.
Die gelben Striche auf deinem Display könnten auch daher kommen, dass
evtl. Der Zeichensatz nicht korrekt ist, oder bei Übertragen des
Zeichensatzes irrtümlich eine 1 mit Übertragen wird (die da nicht
hingehört). Sicherlich ist dieser Strich kein Fehler in der
Initialisierung
Lösung extrem einfach: Die Zeilenanfänge einfach etwas inkrementieren.
display.setCursor(0,16) anstelle von 0,15
display.setCursor(0,31) anstelle von 0,30
display.setCursor(0,46) anstelle von 0,45
Das gilt für das verwendete OLED DST-015-D,
für das DST-013 nicht mehr.
Ich probiere für letzteres OLED-Display einmal die anempfohlene Bibliothek U8g2 aus.
Gebe ich im Dabla per Strg F 0x00 ein, lande ich auf Seite 15, die ein
anderes Thema behandelt.
Gebe ich Dabla per Strg F 0x80 ein, lande ich auf eben derselben Seite.
Trenn Dich doch einfach mal von der Vorstellung, der Wert 0x80 wäre der korrekte.
Der Arduino-Code, den Du da irgendwo aufgetrieben hast, dem Du diese Werte entnommen hast, ist halt nicht die Referenz, sondern das Datenblatt ist die Referenz.
Danke! Das erklärt vieles.
Nun, um etwas über den Fortschritt hier zu erzählen: das eine Display an einem DRM1000 Board ausprobiert. Laut Dabla soll daran jedes Display mit dem SSD1315-Controller laufen.(DST-015-D 0.96')
Tatsächlich es ist austauschbar gegen das vorhandene.
Aber Achtung Vcc und GND sind vertauscht. Das hatte ich beim letzten Test übersehen und damit das erste Display beim Test zerstört. Habe mir ein neues gekauft. Das läuft auf Anhieb beim "verdrehten" Anschluss.
Auch an solche absolut trivialen Dinge sollte man denken. Arghh.
Und das andere Display DST-013 1.3' zeigt zwar etwas an, aber völlig falsch. Die ausprobierten "Workarounds" funktionierten nicht.
Eine explizite Library für den "angeblich" eingebauten Controller zeigt nicht den Erfolg.
//Display
#include <U8g2lib.h>
U8G2_SH1106_128X64_NONAME_F_HW_I2C u8g2(U8G2_R0);
void setup(void){
u8g2.begin();
}
Was ich jetzt mache, ich versuche Schritt für Schritt die einzelnen Initialisierungsschritte durchzugehen.(Evtl. auch noch just for fun in asm mit dem Attiny4313 und STK500 Board, Studio 4)
Was nämlich auffällt: Es scrollt ein Text in "kryptischen" Buchstaben durch. Obwohl kein Scrollen des Textes programmiert war. Eindeutig Fehler in der Init.
Spannend die Sache.
Bleibe dran.
Nochmals Danke an @Kirnbichler für die Tipps.
Da kann ich dir einen "Trick" zeigen, wie man da Unstimmigkeiten erkennen kann.
Wobei folgendes unbedingt zu beachten ist, eben, weil wahr:
Harald K. schrieb im Beitrag #8026236:
Der Arduino-Code, den Du da irgendwo aufgetrieben hast, dem Du diese
Werte entnommen hast, ist halt nicht die Referenz, sondern das
Datenblatt ist die Referenz.
Wenn man weiß, dass der Arduino Code die Initialisierung hin bekommt.
Das Datenblatt schwer verständlich ist.
Die Arduinolib schwer zu durchblicken ist.
Variante 1:
Logikanalyser an den Arduino und die Initsequenz aufzeichnen.
Eine brauchbare LA-Software hat einen I2C Decoder.
Variante 2:
Keine Arduino IDE verfügbar/erwünscht.
Kein LA vorhanden
Kein Arduino Board vorhanden
Dann bietet sich https://wokwi.com/ an.
Neben etlichen Arduino Boards, und vielen Displays hat es auch einen Logikanalyser. Mit diesem kann man die Initsequenz aufzeichnen und z.B. mit sigrok PulseView auswerten.
Die so gewonnen Daten kann man naiv einfach verwenden, oder mit dem Datenblatt vergleichen, um die ein oder andere Erkenntnis zu gewinnen.
Wird im Internet so angeboten.
Habe ich auch erst später gesehen, dass im Archiv-File nur eine Datei drin ist, nicht noch ein Makefile (oh Schreck, oh Graus) oder weitere sonst zu erwartende Files.
Wohlgemeinter Vorschlag:
Google mal direkt nach "oled1.3.ino" und teile hier das Suchergebnis mit.
Gibt aber doch noch eine Besonderheit:
Schließe ich das vorher benutzte 0.96-er an, läuft das Programm auch.
Aber umgekehrt das vorher für das 0.96-er erstellte nicht beim 1.3-er.
Vermutung: Prog. oben ist "abwärtskompatibel". Das andere nicht "aufwärtskompatibel".
Und dass die <wire.h> explizit raus muss, wusste ich nicht.
Schließe ich das vorher benutzte 0.96-er an, läuft das Programm auch.
Aber umgekehrt das vorher für das 0.96-er erstellte nicht beim 1.3-er.
Ja,
andere Library. Dann geht es mit beiden, sowohl mit dem, das zuerst als defekt angesehen wurde als auch mit dem anderen.
Was mir nur noch auffällt: Der Konstruktor soll angepasst werden.
Die I2C-Adresse (Slve) wird nirgends explizit verlangt. Hmmm.
Die I2C-Adresse (Slve) wird nirgends explizit verlangt. Hmmm.
Du könntest Dir ja mal ansehen, was U8GLIB_SSD1306_128X64 macht, und welche Bedeutung U8G_I2C_OPT_NONE hat. Steht im Quelltext der "lib", die Du da verwendest.
Ja, habe gerade KI bemüht.
Wovon auch das obige Beispiel stammt. Respekt!
"...Mit dieser Wahl weiß die Library bereits, welche Hardware-Schnittstelle und welcher Befehlssatz genutzt werden soll, wobei die Standardadresse für diesen Chip-Typ meist direkt mitgeladen wird...Du sparst dir die Angabe nur deshalb, weil die Library die wahrscheinlichste Adresse bereits für dich "errät"..."
Und da geht es echt zur Sache...
https://github.com/olikraus/u8g2/wiki/u8g2setupcpp#ssd1305-128x64_adafruit
Und, wie sieht denn das von Dir favorisierte Programm aus?
Die Frage war doch zuletzt:
Wieso läuft ein Programm auf 0.96-er und 1.3-er OLEDs.
Ein anderes nur auf 0.96-er, auf 1.3-er eben nicht. Obwohl beide den SSD1306 (kompatiblen) Chip haben. (Im Konstruktor ist das auch so angegeben.)
Und das letzte läuft eben auf beiden.
Einmal KI fragen.
Das eine nur auf dem 1.3-er OLED laufende Programm so umschreiben, dass das ursprüngliche "Analogwandlerprogramm" auf beiden OLEDS läuft.
Die Lösung: Die verwendete Library auf die da gültige "Syntax" hin abklopfen.
Und die Unterschiede sind nicht unerheblich.
Nur ein wahllos herausgegriffener Schnipsel:
Die ug8-Library tut es ohne diese Anweisung nicht.
void loop() {
u8g.firstPage();
do {
draw();
} while ( u8g.nextPage() );
Das brauchte das "erste" Analogwandlerprogramm nicht.
Und woher sollte ich das wissen.
Wenn es schon KI gibt, die solche Fragen überhaupt akzeptiert, warum sollte man so ein Angebot einfach ausschlagen?
Es gibt ja zwei Möglichkeiten: Entweder es funktioniert, oder nicht.
Und es funktioniert hier.
Es gibt ja zwei Möglichkeiten: Entweder es funktioniert, oder nicht.
Und es funktioniert hier.
Aber herausgefunden, /warum/, das hast Du nicht. Und so wirst Du beim nächsten auftretenden Problem genauso hilflos bleiben, und beim übernächsten genauso.
Das 1.3-er Display selbst ist die wahrscheinlichste Ursache. Denn, es ist am rechten Rand noch ein weißer Streifen zu sehen, der da nicht hingehört.
Aber das Erfolgserlebins, etwas, was ich vor Wochen vielleicht schon der fachgerechten Entsorgung zugeführt hätte, durch zielgerichtete Fehlersuche wieder zum Leben zu erwecken, lasse ich mir von keinem noch so miesepetrigen Kommentar madig machen.
Dass man von einem 2,95 Euro China-Klon-OLED mit Fehlern rechnen muss, war mir beim Kauf schon klar. Aber einen Versuch war es wert, wie man sieht.
Gib's zu, Du hast von Arduino keinen blassen Schimmer und in dem Falle auch keine punktgenaue Antwort parat gehabt.
Aber da bist Du nicht alleine, denn auf der Arduino-Diskussionsseite geht es zum Teil genauso chaotisch zu wie hier.
Das 1.3-er Display selbst ist die wahrscheinlichste Ursache. Denn, es
ist am rechten Rand noch ein weißer Streifen zu sehen, der da nicht
hingehört.
Moment mal, das kommt mir bekannt vor...
hier:
"Es sind vereinzelt Displays mit SH1106 aufgetaucht, wo das Bild um zwei Pixel verschoben erscheint. Links fehlt etwas und rechts erscheint dafür ein vertikaler Balken mit zufälligem Inhalt. In diesem Fall musst du im Quelltext von OLED::display() eine 0x00 auf 0x02 ändern. Die Stelle ist mit einem Kommentar gekennzeichnet."
hier:
"Es sind vereinzelt Displays mit SH1106 aufgetaucht, wo das Bild um zwei
Pixel verschoben erscheint. Links fehlt etwas und rechts erscheint dafür
ein vertikaler Balken mit zufälligem Inhalt. In diesem Fall musst du im
Quelltext von OLED::display() eine 0x00 auf 0x02 ändern. Die Stelle ist
mit einem Kommentar gekennzeichnet."
Ok, danke für die konstruktiven Hinweise.
Habe beide Displays parallelgeschaltet. (Ich weiß, sollte man lieber nicht machen, vor allem, wenn gleiche Slaveadressen.)
Man sieht deutlich beim linken 1.3-er die weiße Linie, bestehend aus 2 Pixelspalten.
Und ganz deutlich zu sehen, auch ohne Lupe:
Unter U2 hat die 6 bei beiden Displays unten ein paar fehlerhafte Pixel. (Das ist evtl.librarybedingt, oder eher die Syntaxfehler von mir in dem quick and dirty Beispiel. Zeile 14 ug8.drawStr und Zeile 18 ug8.print. Mix von verschiedenen Ausgabekommandos, weiß nicht ob das überhaupt zulässig ist, scheint wohl intern geparst zu werden.)
So, jetzt geht es mit dem im Eingangspost angeschnittenen Thema weiter:
Besonderheit:
Beim Array für die Parametereingabe wird der Befehl 0x00
vorangestellt, um sicher ausgeführt zu werden, sonst hätte ich ihn ins Array mit aufgenommen.(Das Postinkrement Z+ kennt der ATiny2313 noch nicht, daher beide Möglichkeiten angegeben bzw. "geremt".
Also hiermit selbstbeantwortete Frage:
Subsequentielle Kommandoeingabe nicht mit 0x80 (Auch, wenn es hie und da in den Dokus und Beschreibungen so auftaucht.)
0x00 ist richtig
Dann:
bei der Pixel-Definition muss zwingend nochmal der I2C-Setup des Displays erfolgen. (Der benutzte Befehl lautet nicht 0x20 sondern 0x40 für "Dateneingabe".)
Es erscheint zunächst ein dicker Balken, der dann von rechts nach links durch einen schmalen überschrieben wird.
Nachfolgend geht es an die Bilddarstellung, die Organisation, die Ansprache etc. pp.
Jetzt ist der Speicherverbrauch noch überschaubar.
... warum man das so zwingend mit einem 2313 machen möchte erschließt sich mir nicht!
Sagen wir, wir haben 128 Zeichen Font 8x8 ( das ist der für alle gültige Ascii-Code, von 128 bis 255 sind nationale Zeichensätze), dann bedeutet das, dass von den 2 kByte Flash, die ein 2313 hat, alleine 1024 Byte für den Zeichensatz benötigt wird.
Was kann ich da noch für ein Anwenderprogramm schreiben, wenn ich hierfür nur noch 1024 Bytes übrig habe?
Natürlich bekommt man das mit ATtiny2313 hin, aber was macht das für einen Sinn? (und ich bin nicht der Mensch, der normalerweise anderen sagt: nimm etwas anderes).
Aber: Unabhängig davon (auch von seitens des technischen Verstehens) ist deine Hartnäckigkeit bewundernswert!
dann bedeutet das, dass von den 2 kByte Flash, die ein 2313 hat,
alleine 1024 Byte für den Zeichensatz benötigt wird.
32 von 128 der mit ASCII definierten Zeichen sind nicht darstellbar, die entfallen schon mal. Ein weiteres muss man auch nicht codieren, das ist das Leerzeichen.
95 * 8 = 760 Byte
Und dann wird die Anwendung auch ganz sicher nicht alle möglichen der übriggebliebenen 95 Zeichen benötigen. Wenn man einen Überblick darüber hat, welche Texte man tatsächlich anzeigen will, schrumpft das deutlich zusammen.
Gut, man braucht dann noch eine Tabelle zur Abbildung ASCII-Code -> komprimierter Code, aber die muss auch nicht größer als o.g. 95 Zeichen werden.
Allerdings, und das wurde hier schon angesprochen, die Idee, den ganzen Kram in Assembler zu machen, mithin in einer weder wartbaren noch portierbaren Programmiersprache, die entwertet den hier verbratenen Aufwand enorm.
Denn von dem, was hier veranstaltet wird, haben nur Leute etwas, die auch mit AVR-Assembler unterwegs sind. Das schließt alle aus, die andere Microcontroller verwenden, selbst wenn diese Leute auch in Assembler programmieren würden.
Allerdings, und das wurde hier schon angesprochen, die Idee, den ganzen
Kram in Assembler zu machen, mithin in einer weder wartbaren noch
portierbaren Programmiersprache, die entwertet den hier verbratenen
Aufwand enorm.
Bei über 150 Postings zur Beantwortung einer nach Worten des TO "einfachen Frage" geht der Thread sowieso entweder am Thema vorbei oder der TO hat sein Anliegen völlig falsch eingeschätzt.
Oder sollte sich das "einfach" nur auf die Komplexität der Frage beziehen und nicht auf die Beantwortung derselben. ;-)
Es geht prinzipiell um ein einfaches Testprogramm für OLEDs.
Und dann, ob tatsächlich die Prototypen der ersten Generation der Atmel AVRs sowas mit allfällig üblichen Bordmitteln hinbekommen.
Offensichtlich ja.
Für den Test, ob ein Display Pixelfehler hätte, reicht ein "Clear Display" völlig aus.
Für ein simples Avatarpixelbildchen reicht es vielleicht auch noch.
Und, die anderen Aufgaben müsste dann ein "Co-Prozessor", der über den UART oder sonstwie mit dem ATtiny korrespondiert, herhalten.
Ist das verboten Ideen zu haben? Why not?
Dass ich für neue Sachen aufgeschlossen bin, hatte ich ja durch selbst durchgeführte Beispiele mit dem Arduino bereits dokumentiert.
Und auch da gibt es "Macken", mit denen man vorher nicht gerechnet hatte.
Das Problemfeld fächert sich weiter auf. Und so wird der Thread eben immer weiter off topic.
Zumindest eine "einfache", sauber funktionierende und getestete Initialisierungsroutine für OLEDs, um die es hier ging,
in AVR ASM wurde nicht von Euch sondern von mir geliefert.
Und die könnt Ihr jetzt in der Luft zerreissen, wenn Ihr Lust habt.
Die anderen wohlgemeinten ASM-Beispiele berücksichtigen nicht, dass "jeder" seinen eigenen Programmierstil pflegt. Der eine mit Makros, der andere mit Include-Dateien, die nicht vollständig ausfomuliert wurden, die anderen mit C-Derivaten, die erst einer gewissen Beschäftigung damit bedürfen.
Für mich ist der Thread hier zu Ende.
Dank an alle, die sich die Mühe machten, nicht nur herumzumeckern, sondern etwas Konstruktives zu leisten.
Für den Test, ob ein Display Pixelfehler hätte, reicht ein "Clear
Display" völlig aus.
Mit einem "Clear Display" kannst du nicht das richtige Umschalten zwischen zwei Zuständen erkennen. Dir entgehen damit also entweder tote oder immer aktive Pixel. Du musst zwei verschiedene Pixelzustände steuern, um beide Ausfallarten zu erkennen.
In der Adafruit Library kann man auch die ganzen Abfragen [SPI<->I2C] rauswerfen. Die Bibliothek ist nämlich für beide Arten Displays erstellt und die Art der Ansteuerung nicht in Precompilierbare Makros gepackt worden, sondern wird bei jedem Befehl zur Laufzeit ermittelt. UNd wenn man nicht vor hat, SPI-Displays zu verwenden, sondern nur und ausschliesslich I2C, kann man sich das antun und man spart nochmal ne Menge Platz.
Und die lustigen kleinen Sterne aus der Startmeldung kann man auch löschen.
Ich musste mich der Sache tatsächlich auch näher widmen, weil mir der Speicher ausging.
Bei einem anderen Projekt war das Display durch einen 3D gedruckten Rahmen verdeckt, meine "Pixelsicht" war auf 122 x 62 Pixel beschränkt. Geht am Ende aber auch zu machen. Datenblatt eben. Man hat ja das große Glück, die Initialisierung bereits im QuellCode der Bibliothek vorzufinden und kann gut mit dem Datenblatt vergleichen, was wann wie gemacht wird und die Startadressen und den Multiplextakt entsprechend anpassen.
Man nur disziplinert die Bibliothek gesondert speichern und separat halten, sonst ist natürlich beim nächsten Update alles futsch.
Und dann gibt es von Wattenroth(?) noch OLEDs mit 64 x 128 Pixeln. Auch "nice". Quasi hochkant.
Ein kleines 64x32 (weiss ich garnicht mehr genau - siehe Bild), samt genanntem Tiny2313 steckt im Moped als Ersatz für die Ladekontrolleuchte (MZ TS150) und zeigt dort die Bordspannung an. Das Programm passt schon rein da, nicht nur der OLED-Treiber.. Muss man halt n bissl trixen. (ADC fehlt ja auch bei dem Typ AVR).
Probiers aus, dann siehst Du es selbst. Bin auf Dein Ergebnis schon gespannt.
Der ATtiny2313 hat übrigens auch kein SPH.
Hatte ich vergessen auszuremen "für ATiny2313".
Die untenstehende Routine geht 100%ig beim ATtiny2313:
print_0:
lpm ; read table's first byte towards R0
mov temp, r0 ; testing R0 auf 0 bei 0-termination
cpi temp, 0x00 ; "tst" geht auch
breq print_end ; if "0x00", then jump to "print_end"
rcall Ausgabe ; call output routine
adiw ZL:ZH, 1 ; increment Z-pointer
rjmp print_0 ; jump to start to take next byte
; ; from table
Die gabs übrigens schon, bevor man wusste, wie man das Wort KI schreibt.
So um 2008 herum. Die habe ich aus der Mikrocontroller-Artikelsammlung
"abgekupfert".
Momentan bin ich mit der "Page" Adressierung des OLED dran.
Etwas tricky. Nibble-Vertauschen. Irgendwoher kenn ich das doch. Da war doch noch etwas.
ciao
gustav
P.S. mit der 2313def.inc
auf keinen Fall.
Mit der tn2313def.inc, die später herauskam, vielleicht.
32 von 128 der mit ASCII definierten Zeichen sind nicht darstellbar, die
entfallen schon mal. Ein weiteres muss man auch nicht codieren, das ist
das Leerzeichen.
95 * 8 = 760 Byte
eben und wenn man genau schaut bleiben nur 69 über mit ß und Ziffern
Space muß man nicht kodieren, na gut wer es mag -> 70 und nicht als 8 x 8 Matrix sondern als 7 x 5 und kann das Leerpixel auch on the fly hinzufügen.
Probiers aus, dann siehst Du es selbst. Bin auf Dein Ergebnis schon
gespannt.
Das habe ich schon vor Jahrzehnten "ausprobiert". Zu Zeiten, als es noch nicht mal die Nachfolger 2313A/4313 gab.
Der ATtiny2313 hat übrigens auch kein SPH.
Das ist korrekt. Wozu auch? Der hat doch nur 128 (0x80) Byte SRAM, die ab 0x60 beginnen. 0x60 + 0x80 - 1 = 0xdf. Und 0xdf < 0x100. Für die Stackadressierung reicht also SPL.
P.S. mit der 2313def.inc
auf keinen Fall.
Mit der tn2313def.inc, die später herauskam, vielleicht.
Kausalität falsch herum. Primär ist, was das Device tatsächlich kann. Die Aufgabe der *.def.inc ist nur, diese Informationen in einer für den Assembler lesbaren Form bereitzustellen. Tut sie das nicht, ändert das rein garnix daran, was das Device kann oder nicht kann.
dann bedeutet das, dass von den 2 kByte Flash, die ein 2313 hat,
alleine 1024 Byte für den Zeichensatz benötigt wird.
32 von 128 der mit ASCII definierten Zeichen sind nicht darstellbar, die
entfallen schon mal. Ein weiteres muss man auch nicht codieren, das ist
das Leerzeichen.
95 * 8 = 760 Byte
:-) und dann kann man das auch darauf reduzieren, nur Großbuchstaben anzuzeigen, von 33 bis 93 (Defaulbitmap der Zeichen = alle 8 Bytes 0x00), macht dann 60x8 Byte= 480 Byte.
:-) :-) man kann alles amputieren wenn man mag. Ich bin ja auch ein Retro-Fan, allerdings würde ich bspw. nicht auf die Idee kommen, mit einem C64 oder Amstrad CPC464 noch Texte zu erfassen... und so komme ich nicht auf die Idee mit einem 2313 ein graphisches Display zu betreiben.
nicht als 8 x 8 Matrix sondern als 7 x 5 und kann das Leerpixel auch on
the fly hinzufügen.
ergo komme ich auf viel weniger Byte.
Genau so habe ich das gemacht. Bin mit Umlauten auf ca. 550 Bytes für den Zeichensatz gekommen. Wenn man statt fester Breite eine variable Breite nimmt, passen auch noch ein paar Zeichen mehr in die Zeile und es sieht besser aus. Z.B. ist mein "i" deutlich schmaler als das "m". Anstelle eines Längen-Bytes, das zusätzlich Platz gekostet hätte, habe ich einfach einen bestimmten Wert der sonst nirgendwo vorkommt (0x88) als "unsichtbar, wird übersprungen" festgelegt.
Wenn man alle Ausgaben vertikal an 8 oder 16 Pixeln ausrichtet, und keine überlappenden Ausgaben braucht, kann man zudem auf Pufferspeicher verzichten.
Kurzer Zwischenbericht:
Memory adressing mode ausprobiert.
Zunächst stand alles auf dem Kopf.
In der Initsequenz muss dann noch 81hex und C8hex an der passenden Stelle eingefügt werden, dann passt es.
Der Page-Modus klappte bislang nicht. Kommt noch.
ciao
gustav
P.S.:Viele, schöne, bunte Ostereier wünsche ich Euch!
