Morgen an alle Hatte ja bereits gefragt ob ein OLED mit I2C an einem Attiny 841 (Slave) geht. Kam ja die eindeutige Meinung dazu, das es nicht geht. Fragen wir mal anders. Welches Display geht an einen Attiny 841? Dabei müssen die I2C Pins frei bleiben und so wenig wie möglich Pins verbraucht werden? Sicher wird jetzt SPI kommen. Das Problem dabei ist, von SPI habe ich keine Ahnung, noch nie mit gearbeitet. Hat jemand eine Idee dazu?
Helmut schrieb: > Das Problem dabei ist, von SPI habe ich keine Ahnung So geht es uns allen beim ersten Mal. Helmut schrieb: > Hat jemand eine Idee dazu? Das wäre das ideale Projekt im sich einzuarbeiten. Helmut schrieb: > Kam ja die eindeutige Meinung dazu, das es nicht geht. Rein Interesse halber. Was waren die Gründe? Speicher? Bei so einer Aussage hätte ich einen Link erwartet.
:
Bearbeitet durch User
Helmut schrieb: > Dabei > müssen die I2C Pins frei bleiben und so wenig wie möglich Pins > verbraucht werden? Warum sollen diese Pins frei bleiben, wenn Du ein I2C Display dort anschließen möchtest? Wenn Du die USI Pins meinst, die für I2C vorgesehen sind, dann kannst doch auch auf andere Pins ausweichen. Per Software I2C. Helmut schrieb: > Sicher wird jetzt SPI kommen. SPI braucht keine Pins?
Helmut schrieb: > Hatte ja bereits gefragt ob ein OLED mit I2C an einem Attiny 841 (Slave) > geht. Kam ja die eindeutige Meinung dazu, das es nicht geht. Jeder kennt hier sämtliche Posts, weiß also genau, welchen Thread Du meinst. Echt jetzt? Bei Fortsetzungen verlinkt man gefälligst den alten Thread. Warum soll denn ein I2C-OLED an einem beliebigen MC nicht gehen? I2C-Master geht auch prima mit Bitwackeln.
Der 841 hat I2C nur als Slave implementiert. Ein per I2C anzusprechendes Display ist bei ausgerechnet diesem µC also etwas ungünstig. Dafür geht dann nur Software-I2C. Dabei ist ein Oszi oder Logikanalysator - egal wie primitiv - aber hilfreich, wenn man den Code nicht einfach anderswo abschreibt.
:
Bearbeitet durch User
Helmut schrieb: > Morgen an alle > Hatte ja bereits gefragt ob ein OLED mit I2C an einem Attiny 841 (Slave) > geht. Kam ja die eindeutige Meinung dazu, das es nicht geht. > Fragen wir mal anders. Welches Display geht an einen Attiny 841? Eben ein OLED mit SPI. Die meisten haben beides und können umgeschaltet werden. Und wenn es unbedingt I2C sein muss, implementiere es in SW. Hab ich ca. mit 12 Jahren auf einem PIC auch gemacht. Ist echt sau schwer.... Brauchte fast ne Stunde dazu. Ohne Oszi und LA. Wenn ich damals nur gewusst hätte, das man besser in ein Forum geht und Unsinn fragt. Und das löst dann alle Probleme. Wenn man nur genug darüber quatscht. Und anderen erzählt wie wenig man kann. Aber mit 12 ist man halt so blöd und weiß das nicht. Wer keine Probleme hat, macht sich welche.
:
Bearbeitet durch User
Cyblord -. schrieb: > Hab ich ca. mit 12 Jahren auf einem PIC auch gemacht. Als Anfänger? Denk dran, dass er sich nicht einmal SPI zutraut.
:
Bearbeitet durch User
Beitrag "OLED Display mit I2C Bus am Slave betreiben" Meine diesen. Das OLED hat auch einen I2C Bus Anschluss. Das mit dem Peter D. schrieb: > Warum soll denn ein I2C-OLED an einem beliebigen MC nicht gehen? > I2C-Master geht auch prima mit Bitwackeln. Da muss ich leider total passen, noch nie gemacht. Habe gerade meinen Displays durchgesehen und das DOG M163B-A gefunden. Nach DB kann man ja damit SPI bei 5V machen und hat den ST7036. Nach dem ersten Blick könnte es funktionieren. Gibt es bestimmte Pins des Attiny 841 die man für SPI nehmen sollte, ausser I2C Bus?
(prx) A. K. schrieb: >> Hab ich ca. mit 12 Jahren auf einem PIC auch gemacht. > > Als Anfänger? Denk dran, dass er sich nicht einmal SPI zutraut. Nein, mit 12 war ich bereits Vollprofi, promoviert und hatte den Nobelpreis in seriellen Bussystemen in der Tasche. NATÜRLICH als Anfänger! Sich hinstellen und sagen "kann ich nicht" bringt einen nicht weiter. Einfach mal machen. Selber denken. Wissen aneignen. Scheinen für manche völlig fremde Konzepte zu sein.
:
Bearbeitet durch User
Cyblord -. schrieb: > Nein, mit 12 war ich bereits Vollprofi, promoviert und hatte den > Nobelpreis in seriellen Bussystemen in der Tasche. Ja, den Eindruck erweckst du sonst auch gerne. ;-) Ich hatte das allerdings irrtümlich falsch gelesen, als "vor 12 Jahren".
:
Bearbeitet durch User
HackenBeek schrieb: > Helmut schrieb: >> Sicher wird jetzt SPI kommen. > > SPI braucht keine Pins? Natürlich braucht SPI auch Pins. Bei dem genannten Display gibt es ja auch 4 Bit und 8 Bit und die brauchen ja noch mehr.
(prx) A. K. schrieb: > Cyblord -. schrieb: >> Nein, mit 12 war ich bereits Vollprofi, promoviert und hatte den >> Nobelpreis in seriellen Bussystemen in der Tasche. > > Ja, den Eindruck erweckst du sonst auch gerne. ;-) > Ich hatte das allerdings irrtümlich falsch gelesen, als "vor 12 Jahren". Übrigens, genau auf einem ATTINY841 lese ich einen Sensor über I2C (SW) aus. In einem Kleinserienprojekt. Seit Jahren ohne Probleme.
Cyblord -. schrieb: > Scheinen für manche völlig fremde Konzepte zu sein. Es gab Zeiten, da konnte man nicht so ohne Weiteres fragen. Heute kann man, also tut man. Andere Zeiten. "Man nenne es nicht Sittlichkeit weil Mangel an Gelegenheit."
(prx) A. K. schrieb: > Es gab Zeiten, da konnte man nicht so ohne Weiteres fragen. Heute kann > man, also tut man. Andere Zeiten. "Man nenne es nicht Sittlichkeit weil > Mangel an Gelegenheit." Nur was bringt die Fragerei? Die löst kein Problem. Läuft sein Display denn jetzt? Nach den ganzen Fragen? NeiN! WENN ich I2C nicht implementieren kann, google ich nach Code dazu. Kann ich das auch nicht, kann ich eigentlich gar nichts.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Cyblord -. schrieb: >> google ich nach Code dazu > > Macht er ja quasi, nur halt hier. Bitte zeige mir die Stelle wo er nach Code fragt. Aber wonach fragt er dann eigentlich? Ich weiß es nicht. Nach einer "Idee". So kommt niemand weiter. Und selbst WENN er Code hätte, glaubst du wirklich es würde ihm helfen? Ehrlich, Hand aufs Herz usw?
:
Bearbeitet durch User
Cyblord -. schrieb: > Und wenn es unbedingt I2C sein muss, implementiere es in SW. Hab ich ca. > mit 12 Jahren auf einem PIC auch gemacht. Ist echt sau schwer.... 1995 hab ich mal nen I2C-EEPROM in Keil C51 an nen 89C51 gepappt. Den Code kann man problemlos auf anderen MCs und für andere Slaves (OLED) weiter verwenden. Man muß das SW-I2C also nur einmal schreiben. Die OLED-Lib ruft dann nur noch die I2C-Lib auf. Alles schön modular halten und nicht als riesen Spaghetticodemonster.
Peter D. schrieb: > Den Code kann man problemlos auf anderen MCs und für andere Slaves (OLED) > weiter verwenden. Aber Ports der 51er haben Pins, die von Haus aus direkt I2C-tauglich sind. Nicht alles, was spezifisch für 51er geschrieben wurde, lässt sich direkt übernehmen. Bei anderen Controller-Typen muss man deutlich mehr über ebendieses Thema nachdenken. Ist an sich kein Problem, aber wenn man sieht, was Leute bei den 1-Wires für Fehler machen, muss man schon drauf hinweisen.
:
Bearbeitet durch User
Helmut schrieb: > Peter D. schrieb: >> Warum soll denn ein I2C-OLED an einem beliebigen MC nicht gehen? >> I2C-Master geht auch prima mit Bitwackeln. > > Da muss ich leider total passen, noch nie gemacht. Auch wenn es schon öfter gesagt wurde, wo ist das Problem? Irgendwann ist immer das erste Mal, und dazu finden sich einige Software-I2C-Implemetierungen für AVRs im Netz. Die musst du zwar noch an den 841 anpassen. aber wenn du das nicht hinbekommst, wäre doch ein Hobbywechsel auf Gärtnern o.ä. angebracht. Oliver
(prx) A. K. schrieb: > Nicht alles, was spezifisch für 51er geschrieben wurde, lässt sich > direkt übernehmen. Minimalste Codeanpassungen sind zumutbar. Beim 8051 schreibe ich auf das PORT-Bit, beim AVR eben auf das DIR-Bit, um zwischen Input und Output_Low zu wählen. Und zum Einlesen PORT-Bit (8051) bzw. PIN-Bit (AVR). Sowas kann man bequem per #define kapseln.
Es wäre schön, wenn der TE mal sagen könnte, was das eigentlich soll. Immerhin ist ein I2C Display ja schon selber ein Slave und kann direkt am Bus hängen. Ein zusätzlicher Tiny841 wäre dazu nicht nötig. Und wenn man den Tiny noch aus anderen Gründen am Bus hängen hat, gibt man ihm eine andere I2C Adresse als dem Display und kann beide vom Master ansprechen. Für jeden AVR bietet übrigens die I2C Library von P. Fleury eine bewährte Lösung.
:
Bearbeitet durch User
Matthias S. schrieb: > Ein zusätzlicher Tiny841 wäre dazu nicht nötig. Ein MC kann schon den Traffic auf einem allgemeinem I2C-Bus erheblich reduzieren, wenn er die Daten für das GLCD aufbereitet.
Nur zur "Einordnung /Klärung" - O-Ton von Helmut im anderen Thread: "c-hater schrieb: > Was er allerdings nicht kann, ist Multimaster. Und genau deswegen ist es > nötig, das der TO sich erstmal mit sich selbst auf ein Konzept einigt, > was überhaupt laufen soll... Multitasking meine ich, nicht Multimaster und das läuft auf dem Master. Heiner schrieb: > Hast Du überhaupt schon mal per I2C Daten zwischen einem Master und > einem Slave ausgetauscht; ich meine nicht nur ein paar Bits sondern eine > richtige sinnvolle Kommunikation aufgezogen? Das habe ich bereits gemacht. Du hast selber entsprechende Seiten genannt wo einzelne Tuts und Programme veröffentlich wurden. Teilweise habe ich bis 6 Slave am Master dran. Beispiel dazu: PCF8574, PCF8591, MCP23008, MCP23017, OLED, E-Paper, INA221, Farb TFT Display von EA mit bis zu 3,2 Zoll. Teilweise habe ich 2 Displays gleichzeitig am Bus betrieben. Auch der Austausch von Atmega zum Attiny 841 und zurück per Bus klappt ohne Probleme. Kann dir gern ein Beispiel dazu bringen. Ein richtiger sinnvolle Kommunikation ist für mich die graphische Anwendung auf einem TFT Display mit verschiedenen Schriftarten oder Darstellung von Geraden, Mehrecken oder einer Laufschrift mit dem (mehreren) HT16K33 und 5 (und mehr) x Matrix 8x8. Das sind nach meiner Rechnung über 300 LEDs. Die Beispiel dazu stehn im Netz, musst nur richtig suchen. Ein Beispiel was funktioniert:
1 | void Graphik_Gerade(int8_t x1, int8_t y1, int8_t x2, int8_t y2) |
2 | {
|
3 | uint8_t bcc; |
4 | bcc = 0x11 + 0x07 + 0x1b + 'G' + 'D' + x1 + y1 + x2 + y2; |
5 | i2c_start(slave_adresse_1); |
6 | i2c_write(DC1); // DC1 |
7 | i2c_write(0x07); // len 07 |
8 | i2c_write(ESC); // ESC |
9 | i2c_write('G'); // G |
10 | i2c_write('D'); // D |
11 | i2c_write(x1); |
12 | i2c_write(y1); |
13 | i2c_write(x2); |
14 | i2c_write(y2); |
15 | i2c_write(bcc); |
16 | i2c_start(slave_adresse_2); |
17 | e = i2c_readAck(); |
18 | i2c_stop(); |
19 | _delay_us(10); |
20 | }
|
Bei dieser Anwendung ist es relativ egal. Das Graphik Display nutze ich zur eigentlichen Anzeige und das OLED nur zur Anzeige der Prüfsumme. Das Display funktioniert nur wenn die Prüfsumme korrekt berechnet wird und der Wert zurückgelesen wird. Die Prüfsumme muss vorher berechnet werden, zum Display übertragen werden und wird vom Display nochmal berechnet. Wenn beide Werte übereinstimmen erfolgt die Anzeige. Der Wert muss auch ausgelesen werden, sonst keine Anzeige. Das Display ist so schnell das eine Pause eingefügt werden muss, sonst kann es zu einer fehlerhaften Anzeige kommen. Je nach Typ kann die Anzeige auch 320 x 164 haben. Dann muss noch eine Berechnung efolgen wo die Anzeige liegt. Komisch, es ist hier so still, keiner meckert das ich keine Ahnung habe oder überhaupt schon mal eine Übertagung per Bus gemacht habe. Komisch ???!!!!"
Peter D. schrieb: >> Und wenn es unbedingt I2C sein muss, implementiere es in SW. Hab ich ca. >> mit 12 Jahren auf einem PIC auch gemacht. Ist echt sau schwer.... > > 1995 hab ich mal nen I2C-EEPROM in Keil C51 an nen 89C51 gepappt. Den > Code kann man problemlos auf anderen MCs und für andere Slaves (OLED) > weiter verwenden. Man muß das SW-I2C also nur einmal schreiben. > > Die OLED-Lib ruft dann nur noch die I2C-Lib auf. Alles schön modular > halten und nicht als riesen Spaghetticodemonster. Du erkennst Ironie?
Helmut schrieb: > Hat jemand eine Idee dazu? Lernen, wie's geht ? Es gibt genügend seriell anschliessbare Displays (und viele uC mit mehr Pins, die es in der Summe vielleicht billiger machen).
Helmut schrieb: > Sicher wird jetzt SPI kommen. Das Problem dabei ist, von SPI habe ich > keine Ahnung, noch nie mit gearbeitet. > Hat jemand eine Idee dazu? Ganz einfach: wirf eine Münze und je nach dem, ob Kopf oder Zahl zu sehen sind, entscheidest Du Dich für IIC oder SPI. Das ziehst Du dann durch und fertig!
Nachbarthread vom gleichen Poster zum gleichen Thema: Beitrag "OLED Display mit I2C Bus am Slave betreiben"
Helmut schrieb: > Welches Display geht an einen Attiny 841? Jedes Display mit I²C Schnittstelle kann an jedem Mikrcocontroller betrieben werden. Den I²C Master kann man (wie mehrfach gesagt wurde) leicht in Software mittels Bit-Banging implementieren. Cyblord -. schrieb: > Hab ich ca. mit 12 Jahren auf einem PIC auch gemacht. > Brauchte fast ne Stunde dazu. Ohne Oszi und LA. > Ist echt sau schwer.... Das "sau schwer" war ironisch gemeint, oder? Cyblord -. schrieb: > Und selbst WENN er Code hätte, glaubst du wirklich es würde ihm helfen? Ich habe ihm ja schon Quelltext (mit Soft-I²C) für genau dieses Display gegeben. Damit konnte er nichts anfangen.
Leute Helmut hat sich doch schon nach den ersten Posts ausgeklinkt. Jeder weiterer Post (auch meiner - sic!) ist zwecklos.
>Helmut hat sich doch schon nach den ersten Posts ausgeklinkt. >Jeder weiterer Post (auch meiner - sic!) ist zwecklos. Richtig >Gibt es bestimmte Pins des Attiny 841 die man für SPI nehmen sollte, >ausser I2C Bus? Helmut ist nicht mal auf die 2. Seite des Datenblatts seines Wunsch uCs gekommen: https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-8495-8-bit-AVR-Microcontrollers-ATtiny441-ATtiny841_Datasheet-Summary.pdf
drm schrieb: > Helmut ist nicht mal auf die 2. Seite des Datenblatts seines Wunsch uCs > gekommen: > https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-8495-8-bit-AVR-Microcontrollers-ATtiny441-ATtiny841_Datasheet-Summary.pdf Helmut muss sein Tutorial weiterschreiben - er hat dafür keine Zeit. https://playground.boxtec.ch/lib/exe/fetch.php/tutorials/ati-841_avr_studio.pdf
Hugo H. schrieb: > drm schrieb: >> Helmut ist nicht mal auf die 2. Seite des Datenblatts seines Wunsch uCs >> gekommen: >> > https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-8495-8-bit-AVR-Microcontrollers-ATtiny441-ATtiny841_Datasheet-Summary.pdf > > Helmut muss sein Tutorial weiterschreiben - er hat dafür keine Zeit. > > https://playground.boxtec.ch/lib/exe/fetch.php/tutorials/ati-841_avr_studio.pdf 100 Punkte 👍😉😂
@Helmut Alias Achim Seeger Warum stellst Du Deine Fragen nicht auch im Forum: https://forum.boxtec.ch/index.php/topic,2622.0.html Da bist Du doch sogar Moderator! SCNR
(prx) A. K. schrieb: > Als Anfänger? Denk dran, dass er sich nicht einmal SPI zutraut. So what? Dann muss er es halt lernen. Vorlagen und Doku gibt es doch genug für beides, er hat also eigentlich die freie Wahl, was er lernen möchte. Ich wette: nichts von beidem. Der will einfach nur fertigen Code, nix anderes.
Ist erstaunlich was so einige Leute vermuten. Ich bin hier, lese alles und melde mich auch dazu. Matthias S. schrieb: > Es wäre schön, wenn der TE mal sagen könnte, was das eigentlich soll. > Immerhin ist ein I2C Display ja schon selber ein Slave und kann direkt > am Bus hängen. > Ein zusätzlicher Tiny841 wäre dazu nicht nötig. Und wenn man den Tiny > noch aus anderen Gründen am Bus hängen hat, gibt man ihm eine andere I2C > Adresse als dem Display und kann beide vom Master ansprechen. > Für jeden AVR bietet übrigens die I2C Library von P. Fleury eine > bewährte Lösung. Leider passt die Lösung von Peter zum I2C Bus nicht zum Attiny 841. Der hat ganz was anderes. Da der Attiny 841 als Slave gebaut (laut DB) ist kann er kein anderen Slave ansteuern. In wieweit der Master als Software gemacht werden kann, kann ich nicht sagen. c-hater schrieb: > Ich wette: nichts von beidem. Der will einfach nur fertigen Code, nix > anderes. Du willst wetten? Dann geht es los. Habe weiter oben einen Code von mir reingestellt. Der stammt ganz allein von mir oder findest du eine Quelle dazu? Ein fertiger Code ist eine Lösung, ich will aber wissen wie es geht. Da der 841 sich in einigen Teile unterscheidet ist es nicht so leicht. Einige werden wieder schreiben, ist doch super einfach oder so. Andere werden wieder sagen, nimm dein C-Buch und lerne erst mal die Grundlagen. Wenn ihr den Anfang lest werdet ihr feststellen das ich nicht nach Code gefragt habe sondern nach einem Typ und den Pins dazu. Heiner schrieb: > Helmut ist nicht mal auf die 2. Seite des Datenblatts seines Wunsch uCs >>> gekommen: Auf dieser Seite war ich und den ganzen Rest so ziemlich auch. Wo wüsste ich sonst her welche Pins für Bus oder Quarz sind. Bleibt bitte bei der Wahrheit und versucht nicht mir etwas zu unterstellen. So das wars, mach zu.
Helmut schrieb: > Da der Attiny 841 als Slave gebaut (laut DB) ist kann er kein anderen > Slave ansteuern. Doch, selbst das geht (ist aber tricky, da die Hardware des Tiny841 tatsächlich eigentlich nicht dafür gedacht ist). > In wieweit der Master als Software gemacht werden kann, > kann ich nicht sagen. Dir wurde bereits gesagt, dass das natürlich geht. Nur halt nicht am gleichen Bus, an dem der Tiny841 bereits als Slave (mit der vorhandenen Hardware) hängt. Wenn das der Fall ist (du hast die explizite Frage nach dem Gesamtkonzept bisher nicht beantwortet), dann hilft nur eins: Software-Bitbanging, das aber dann GARANTIERT. Kostet halt zwei Pins und macht darüber einen weiteren I2C-Bus auf, das ist aber auch schon alles. > Du willst wetten? Dann geht es los. Habe weiter oben einen Code von mir > reingestellt. Wo genau? Ich kann keinen Code sehen. Code ist Text.
Helmut schrieb: > Leider passt die Lösung von Peter zum I2C Bus nicht zum Attiny 841. Der > hat ganz was anderes. Doch. Ich schrieb 'für jeden AVR' und das gilt auch so. Bei der Lib von Fleury hast du die Wahl zwischen Hardware TWI, die beim ATTiny841 nicht funktionieren muss und einer Software Lösung, die auf jedem AVR läuft, der 2 freie GPIO hat. Helmut schrieb: > In wieweit der Master als Software gemacht werden kann, > kann ich nicht sagen. Aha.
:
Bearbeitet durch User
Hallo Helmut Gemäß den Posts kannst Du den Attiny841 - als I2C Slave betreiben (Datenaustausch mit I2C Master, z.B Atmega128) - per Bit-Bang einen Software I2C implementieren und damit Dein Display betreiben. Eine SW TWI Implementation gibt es von P. Fleury und im anderen Post einen link von Stefan S. Also Kollege was hindert Dich am Programmieren?
Helmut Damit es keine Missverständnisse gibt - Du kannst beides zusammen mit dem Attiny841 machen, den SW I2C UND den HW I2C
Helmut Klimper was zusammen bezüglich Bit-Bang I2C, stelle es hier rein damit man sieht, Du bist tätig. Wenn es funktioniert- prima. Wenn nicht, kann man ja helfen. Aber werde TAETIG!!! 😉👍
Schau mal hier, wurde von Hugo übernommen: 06.04.2022 10:28 Heiner schrieb: > Wenn es funktioniert- prima. > Wenn nicht, kann man ja helfen. > Aber werde TAETIG!!! Das kling sehr gut. Leider ziehen es andere vor mich zu beschimpfen und nieder zu machen. Dabei soll ich noch Vertrauen in das Forum haben? So wie scheint geht es einigen nur darum Stimmung zu machen. Ich werde es mir auf jeden Fall ansehen, mal sehen ob es klappt. c-hater schrieb: > Da der Attiny 841 als Slave gebaut (laut DB) ist kann er kein anderen >> Slave ansteuern. > > Doch, selbst das geht (ist aber tricky, da die Hardware des Tiny841 > tatsächlich eigentlich nicht dafür gedacht ist). > >> In wieweit der Master als Software gemacht werden kann, >> kann ich nicht sagen. > > Dir wurde bereits gesagt, dass das natürlich geht. Nur halt nicht am > gleichen Bus, an dem der Tiny841 bereits als Slave (mit der vorhandenen > Hardware) hängt. Wie kommt es dann eigentlich zu den grossen Unterschieden zwischen Slave z.B. MCP23008 und Slave Attiny 841. Ist ein Prozessor, klar. Beim Betrieb des Attiny 841 als Slave am Bus sieht die SW ganz anders aus. c-hater schrieb: > Wenn das der Fall ist (du hast die explizite Frage nach dem > Gesamtkonzept bisher nicht beantwortet), dann hilft nur eins: > Software-Bitbanging, das aber dann GARANTIERT. Kostet halt zwei Pins > und macht darüber einen weiteren I2C-Bus auf, das ist aber auch schon > alles. Gesamtkonzept sieht halt so aus, das ich das ganze als Hobby betreibe und gern wissen möchte wie man was macht. Die zwei Pins stören nicht. Heiner schrieb: > Aber werde TAETIG!!! Das bin ich, schreibe allerdings nicht jeden Tag rein was ich gerade mache. Können wir uns darauf einigen bei einer technischen Runde zu bleiben und persönlich Probleme und Äusserungen zu unterlassen?
OLED und SPI geht ganz gut. Ich habe auf einem xmega einen Clip-Player programmiert. Bei 48 MHz schaufelt der 6 MB pro Sekunde ans Display. Bei den gängigen OLEDs (mehr als 160x128 scheints nicht zu geben) reichts für 50 fps :D
Helmut schrieb: > Gesamtkonzept sieht halt so aus, das ich das ganze als Hobby betreibe > und gern wissen möchte wie man was macht. Du hast bereits mit P. Fleurys I2CMaster etc. "gearbeitet". Beitrag "LCD am I2C Bus" Mehr schreibe ich nicht mehr dazu.
Helmut schrieb: > Das kling sehr gut. Leider ziehen es andere vor mich zu beschimpfen und > nieder zu machen. ich habe dich nie beschimpft, aber du beantwortest auch keine Fragen! Beitrag "Re: OLED Display mit I2C Bus am Slave betreiben" welche OLED Displays berechnen Prüfsummen? Ich denke ich habe den Faden verloren oder der Helmut! außerdem ist es sehr unglücklich, dass du 2 parallele Threads aufgemacht hast! vielleicht bittest du einen Moderator diese zusammenzuführen?
:
Bearbeitet durch User
Helmut schrieb: > Wie kommt es dann eigentlich zu den grossen Unterschieden zwischen Slave > z.B. MCP23008 und Slave Attiny 841. Ich verstehe die Frage nicht. Der eine Chip ist ein nicht programmierbarer Port-Expander, der andere ein programmierbarer Mikrocontroller. Der Unterschied ist in etwa wie ein Anhänger vs. Traktor.
Hugo H. schrieb: > Helmut schrieb: >> Gesamtkonzept sieht halt so aus, das ich das ganze als Hobby betreibe >> und gern wissen möchte wie man was macht. > > Du hast bereits mit P. Fleurys I2CMaster etc. "gearbeitet". > > Beitrag "LCD am I2C Bus" > > Mehr schreibe ich nicht mehr dazu. Achim S. Alias Helmut hat ALLE nötigen Informationen, um loszulegen, außerdem kann er ja in seinen Tuts nachsehen 😉
z.B. Display EA DOG X160, EDIP TFT 32, EDIP 128. Die Prüfsumme ist eine Vorgabe des Herstellers. Zur Entwicklung des Programmws muss die Prüfsumme korrekt sein egal welche Eingabe z.B. Beim Startpunkt oder Zielpunkt. Beim normalen Programm brauchst du kein zweites Display. Wenn du die Prüfsumme auf dem zweiten Display lesen kannst erleichtert es einen sehr das schreiben. Bei normalen Betrieb muss es aber ausgelesen werden und kann man dann vergessen. Nicht vergessen, das Display ist mit 6uS sehr schnell. Stefan ⛄ F. schrieb: > Der Unterschied ist in etwa wie ein Anhänger vs. Traktor. Da gebe ich dir Recht, jeder Vergleich hingt. Nehmen wir dann mal USI am Attiny2313. Ist auch wieder unterschiedlich. Sonst kann ich dir keinen Unterschied sagen, da der 841 der erste IC mit Slave als Prozessor ist. Heiner schrieb: > Helmut hat ALLE nötigen Informationen, um loszulegen, > außerdem kann er ja in seinen Tuts nachsehen Leider stimmt das nicht so ganz. Ich frage nach Themen die ich bisher nicht behandelt oder verstanden habe. Ansonsten versuche ich die Tuts so zu schreiben, das es auch ein Anfänger versteht, als so einfach wie möglich und so Kompliziert wie nötig. Joachim B. schrieb: > außerdem ist es sehr unglücklich, dass du 2 parallele Threads aufgemacht > hast! Ja das stimmt, habe zwei aufgemacht. Einen habe ich beerdigt und geh nicht weiter drauf ein. Bleibe bei diesem. Joachim B. schrieb: > welche OLED Displays berechnen Prüfsummen? OLED nicht, meine die TFTs von EA. Mit diesen Teilen arbeite ich sehr gern, habe eine gute Doku und man kann sogar beim Hersteller fragen. Wenn jemand Lust hat kann er ja sich das EDIP TFT 32 ansehen. Habe die Version mit Touchdown auf dem Display. Da kann man das Display berühren und Auswählen. So was Ähnliche habe ich bereits mit QTouch am I2C Bus gemacht. Nenne es Tastensatz ohne Tasten, einfach wählen durch auflegen des Fingers.
Helmut schrieb: > Ansonsten versuche ich die Tuts so zu schreiben, das es > auch ein Anfänger versteht, als so einfach wie möglich > und so Kompliziert wie nötig. Genau kann ein Anfänger besser als ein Erfahrener, denke ich.
Helmut schrieb: > z.B. Display EA DOG X160, EDIP TFT 32, EDIP 128. so ein Unsinn, diese Displays haben keine I2C! und auch keine Prüfsummenberechnung! Das Einzige was sich dazu im Netz finden lässt sind diese Displays die an einen µC hängen und wenn dieser Prüfsummen verlangt sind das nicht die Displays! https://playground.boxtec.ch/lib/exe/fetch.php/tutorials/atb_i2c_ea_dog_xl160_32_hardware.pdf somit ist beweiesen das es keine I2C Displays gibt die Prüfsummen verlangen!
Hat irgendwer mit gutem Gefühl verstanden, was der Helmut mit seinen Prüfsummen anstellen will? Also ich verstehe da ehrlich gesagt nur Bahnhof.
Stefan ⛄ F. schrieb: > Hat irgendwer mit gutem Gefühl verstanden, was der Helmut mit seinen > Prüfsummen anstellen will? > > Also ich verstehe da ehrlich gesagt nur Bahnhof. Das ist bei Dir oft der Fall. Wichtig ist vor Allem: Antworten. Schreiben. Zeilen mit Müll erzeugen. Nur keinen Leerlauf, wenn der Tag sonst schon so leer ist. Arme Sau.
Firma Dunning & Kruger schrieb: > Das ist bei Dir oft der Fall. Wichtig ist vor Allem: Antworten. > Schreiben. Zeilen mit Müll erzeugen. Nur keinen Leerlauf, wenn der Tag > sonst schon so leer ist. > Arme Sau. Danke für diesen wertvollen hochwertigen Beitrag von dir. Selber Arme Sau!
Stefan ⛄ F. schrieb: > Hat irgendwer mit gutem Gefühl verstanden, was der Helmut mit seinen > Prüfsummen anstellen will? Sieh dir das Tut an und besonders die Auszüge aus dem DB des Herstellers. Ist ziemlich eindeutig. Joachim B. schrieb: > somit ist beweiesen das es keine I2C Displays gibt die Prüfsummen > verlangen! Schau dir bitte die DB des Herstellers zu den Typen an. Da steht eindeutig welche Betriebsarten möglich ist. Leider hast du auf der Seite zu wenig gesucht, steht alles drin und beschrieben. Es sind genug SW Beispiel dabei. Das Schema mit der Berechnung stammt aus dem DB des Herstellers mit genauer Angabe was passieren muss. Es ist nicht Ziel sich hier zu belegen. Ich möchte einen technischen Beitrag leisten und erwarte auch von anderen einen sachliche anständigen Ton.
Beitrag #7027842 wurde von einem Moderator gelöscht.
Helmut schrieb: > Sieh dir das Tut an und besonders die Auszüge aus dem DB des > Herstellers. Ist ziemlich eindeutig. OK jetzt habe ich es geschnallt. Das ist aber ungewöhnlich. Das Display will also jedes Kommando in ein Paket mit Prüfsumme verpackt haben. Aber was meinst du dann damit: > Wenn du die Prüfsumme auf dem zweiten Display lesen > kannst erleichtert es einen sehr das schreiben. > Bei normalen Betrieb muss es aber ausgelesen werden > und kann man dann vergessen. ? geht es dir um Debugging mit Hilfe von Textausgaben? Das würde ich normalerweise seriell machen und auf dem PC mit einem Terminalprogramm anzeigen. Ein zweites Display passt da irgendwie nicht in Weltbild.
Helmut schrieb: > Schau dir bitte die DB des Herstellers nun schlägts 13! erst kommst du mit: Helmut schrieb: > z.B. Display EA DOG X160 schaut man dort hin kommt man auf: https://www.lcd-module.de/produkte/dog.html die haben kein I2C solche habe ich schon selber verbaut, willst du uns verkackeiern? oder bist du so sparsam im Kopf ausgestattet das du LCD und mit µC aus anderen Quellen nicht auseinander halten kannst, nun schiebst du ein anderes Beispiel nach, das nennt man trollen.
@Joachim Kollege, da muss ich den Achim / Helmut doch in Schutz nehmen; leider drückt er sich (immer) etwas unklar aus (weiß nicht warum). Er will Dich / uns bestimmt nicht verkackeiern, und die Sache mit den Displays ist letztendlich nur eine Nebensache, hat mit seinem jetzigen Problem (Anbindung eines Displays an den ATiny841) nicht direkt was zu tun. Also komm' runter
@Achim / Helmut Hast Du die eDIP128.* libs wirklich (!) alleine ohne Hilfe geschrieben?
Habe beim Hersteller angefragt und den Hinweis bekommen das einige Sachen dazu in den Beispielen stehem. Leider kaum was anzufangen. Habe mich dann dabei gemacht das zu verstehen wie es laut DB gemeint ist. Habe dann die Prüfsumme "entschlüsselt" mit Anzeige der Prüfsumme auf einem 2. Display und habe dann ca. 35 Befehle aus dem DB in C übertragen. Auch die für TFT32, TFT050, E-Paper und andere Display von EA. Habe keine Hinweise oder Anleitung dazu im Netz gefunden. Ja, das habe ich alles allein gemacht.
Joachim B. schrieb: > willst du uns > verkackeiern? Nein das will ich auf keinen Fall machen, bin auch kein Troll. Mein Ziel war ein Display an den Attiny 841 zu bekommen. So wie es jetzt aussieht werde ich SPI nehmen. Display ist vorhanden, der Attiny auch und noch ein bischen "Hühnerfutter" dazu. Ist eine gute Ergänzung zu den Attiny Sachen. Habe noch andere Sachen mit den Displays gemacht, z.B. ein Spiel, natürlich mit Joystick, I2C Bus, ACD und TFT.
Helmut schrieb: > So wie es jetzt aussieht werde ich SPI nehmen. Display ist vorhanden, > der Attiny auch und noch ein bischen "Hühnerfutter" dazu. Ist eine gute > Ergänzung zu den Attiny Sachen. Also wohl letztlich mit dem Konzept "zusätzlicher I2C-Bus + Bitbanging nach Wichsvorlage" arrangiert. Immerhin, nach einem Thread mit gefühlt 1000 Postings zu einer Entscheidung zu kommen, die jeder Normaldenkende sofort gewählt hätte ohne lange darüber nachdenken zu müssen. Hut ab...
c-hater schrieb: > Immerhin, nach einem Thread mit gefühlt 1000 Postings zu einer > Entscheidung zu kommen, die jeder Normaldenkende sofort gewählt hätte > ohne lange darüber nachdenken zu müssen. Hut ab... Jeder normal Denkende würde Dir nach solchen Sprüchen im realen Leben die Fresse einschlagen. Womit? Mit wachsender Begeisterung.
Realitäts-Anerkenner schrieb: > Jeder normal Denkende würde Dir ... die Fresse einschlagen. Da bin ich froh, nicht normal zu denken.
Realitäts-Anerkenner schrieb: > c-hater schrieb: >> Immerhin, nach einem Thread mit gefühlt 1000 Postings zu einer >> Entscheidung zu kommen, die jeder Normaldenkende sofort gewählt hätte >> ohne lange darüber nachdenken zu müssen. Hut ab... > > Jeder normal Denkende würde Dir nach solchen Sprüchen im realen Leben > die Fresse einschlagen. Womit? Mit wachsender Begeisterung. Ist Dein Leben so armselig, dass Du sowas schreiben musst, zudem auch noch anonym? Bei diesem Hass ist wohl der Besuch bei einem Psychiater nötig. Armer Wicht
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.