Hallo Mit einem Attiny 841 möchte ich ein Display DOG M163 mit SPI (5V) betreiben. Mit SPI habe ich bisher nicht gearbeitet und bin dabei totaler Neuling. Dabei verwende ich die folgenden Pins: Attiny 841 Name Display // PA4 --> SCK/SCK --> DOG 29 // PA6 --> Mosi --> DOG 28 // PB1 --> CSB --> DOG 38 // PB2 --> RS --> DOG 39 In einigen anderen Treets habe ich bereits einiges zum Attiny 841 geschrieben, allerdings mit dem I2C Bus. Im Netz habe ich einiges an Erklärung zu SPI gefunden. Leider etwas zu allgemein für mich. Kennt jemand eine gute Seite für mehr Info? Oder einiges an Beispielen zum Thema?
Beitrag #7101886 wurde von einem Moderator gelöscht.
DerEinzigeBernd schrieb im Beitrag #7101886: > Das ist ein ST7036, dessen Datenblatt davon solltest Du Dir > ansehen. Die Seite habe ich mir angesehen. Du sprichst von 4 Möglichen SPI Verfahren. Da brauche ich wohl mehr Grundlagen um das zu verstehen.
Henry schrieb: > Da brauche ich wohl mehr Grundlagen um das zu verstehen. Ja, leider. Atmel hat ist beim Thema SPI auf halber Strecke liegen geblieben. Zum einen haben sie zwar ziemlich schicke Timing-Diagramme geliefert, aber nur zwei, in denen jeweils zwei Modi zusammengefaßt dargestellt werden. Und zum anderen haben sie nirgendwo übersichtlich aufgelistet, welche Kombination aus CPOL und CPHA nun welchem SPI-Mode entspricht. Also irgendwie nix halbes und nix ganzes. Dem Einsteiger hilft es fast garnicht, die Diagramme verwirren ihn eher und der Profi bräuchte das ganze Gesülze nicht, sondern eigentlich nur die kleine Tabelle, die auf einen Blick die nötige Information liefern würde. Die Diagramme wären dann nur noch als Absicherung der Information aus der Tabelle nützlich. Allerdings ist anderen dieser Mißstand schon vor Jahrzehnten aufgefallen, und deswegen gibt es im Netz durchaus viele Quellen, die die kleine Tabelle liefern, die eigentlich Atmel hätte liefern müssen.
Beitrag #7102099 wurde von einem Moderator gelöscht.
DerEinzigeBernd schrieb im Beitrag #7102099:
> Meinst Du, daß das hilft?
Vielleicht hilft es dem TO dabei, auch mal auf die Idee zu kommen,
selbst zu googeln. Damit wäre bei ihm schon viel erreicht.
Henry schrieb: > Da brauche ich wohl mehr Grundlagen um das zu verstehen. Oder einfach ausprobieren. Da hier entweder keiner das Display kennt, oder nicht bereit ist Dir zu helfen ist das vermutlich das schnellste. Stundenlang im Netz suchen und dabei nicht entscheiden können ob dort blödsinn empfohlen wird kann recht frustrierend sein. Da sind zwei Fehlbrände schneller erledigt. PS Nicht vergessen die Stromversorgung dazwischen ab zu schalten. Hat ein Fehlbrand es ins Nirwana geschickt kann es sein das der Richtige es nicht wiederbelebt. (Die 16x2LCD lassen sich so abschießen das nur ein Kaltstart hilft ;-)
Beitrag #7102172 wurde von einem Moderator gelöscht.
Die Kernroutine zum DOGM LCD ist so simpel, das sich die Verwendung der SPI Hardware so gut wie nicht lohnt:
1 | // LCD connections
|
2 | #define LCD_PORT PORTB
|
3 | #define LCD_DIR DDRB
|
4 | #define LCDDATA 1
|
5 | #define LCDCLK 2
|
6 | #define LCDA0 3
|
7 | #define LCDCS 0
|
8 | #define LCD_MASK ((1<<LCDDATA)|(1<<LCDCLK)|(1<<LCDA0)|(1<<LCDCS))
|
9 | |
10 | // LCD routines by bit banging SPI
|
11 | void lcd_out(const uint8_t data) { |
12 | uint8_t n = 8; |
13 | uint8_t shifter = data; |
14 | LCD_PORT &= ~(1<<LCDCS); // select LCD |
15 | while (n>0) { |
16 | LCD_PORT &= ~(1<<LCDCLK); // clk lo |
17 | if (shifter & 0x80) LCD_PORT |= (1<<LCDDATA); |
18 | else LCD_PORT &= ~(1<<LCDDATA); |
19 | shifter <<= 1; |
20 | LCD_PORT |= (1<<LCDCLK); // clk high |
21 | n--; |
22 | }
|
23 | LCD_PORT |= (1<<LCDCS); // deselect LCD |
24 | }
|
Wie man Portpins initialisiert, ist ja sicher bekannt.
Beitrag #7102177 wurde von einem Moderator gelöscht.
c-hater schrieb: > Vielleicht hilft es dem TO dabei, auch mal auf die Idee zu kommen, > selbst zu googeln. Damit wäre bei ihm schon viel erreicht. Leider wusste ich bis dieser Info nicht einmal das so was exestiert. Werde dann mal auf Jagd nach der Tabelle gehen. c-hater schrieb: > Allerdings ist anderen dieser Mißstand schon vor Jahrzehnten > aufgefallen, und deswegen gibt es im Netz durchaus viele Quellen, die > die kleine Tabelle liefern, die eigentlich Atmel hätte liefern müssen. Das ganze verwundert mich sehr.Kann mir noch jemand sagen wie die Tabelle heisst? Oder mehr Info dazu. Matthias S. schrieb: > // LCD connections > #define LCD_PORT PORTB > #define LCD_DIR DDRB > #define LCDDATA 1 > #define LCDCLK 2 > #define LCDA0 3 > #define LCDCS 0 > #define LCD_MASK ((1<<LCDDATA)|(1<<LCDCLK)|(1<<LCDA0)|(1<<LCDCS)) > // LCD routines by bit banging SPI > void lcd_out(const uint8_t data) { > uint8_t n = 8; > uint8_t shifter = data; > LCD_PORT &= ~(1<<LCDCS); // select LCD > while (n>0) { > LCD_PORT &= ~(1<<LCDCLK); // clk lo > if (shifter & 0x80) LCD_PORT |= (1<<LCDDATA); > else LCD_PORT &= ~(1<<LCDDATA); > shifter <<= 1; > LCD_PORT |= (1<<LCDCLK); // clk high > n--; > } > LCD_PORT |= (1<<LCDCS); // deselect LCD > } Das ist schom mal ein Anfang. Matthias S. schrieb: > Die Kernroutine zum DOGM LCD ist so simpel, das sich die Verwendung der > SPI Hardware so gut wie nicht lohnt: Mit dieser Sache bringst du mich schön ins Schwitzen. Wenn die Sache so einfach ist, wozu dann soviel Aufwand. Werde den Code genau ansehen. Selber habe ich sogut wie Code bisher. Vielleicht bis auf Titel und Angabe Frequenz. Da fehlst noch einiges an Grundlagen.
Henry schrieb: > Mit dieser Sache bringst du mich schön ins Schwitzen. Wenn die Sache so > einfach ist, wozu dann soviel Aufwand. Ich frag mich beim SPI Interface, also die Hardware im AVR, oft, wo sie mir Arbeit spart. Die o.a. Routine kann ich simpel an andere Pins anpassen und sie läuft auf jedem AVR, ob mit oder ohne SPI Hardware. Nur eine Sache noch: Für Befehle muss man evtl. noch vor dem Ansprung dieser Routine einen Pin hochziehen (RS bzw. A0) und ihn danach wieder runtersetzen. Läuft jedenfalls ohne Änderung mit DOGM163, DOGM128 und anderen. Die Befehle selber sind je nach LCD Controller unterschiedlich, aber die Ausgaberoutine ist immer die gleiche.
:
Bearbeitet durch User
DerEinzigeBernd schrieb im Beitrag #7102172: > http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-8495-8-bit-AVR-Microcontrollers-ATtiny441-ATtiny841_Datasheet.pdf > > Blickt man ins Datenblatt des Tiny841, erkennt man ...dass der Poster dieses Schwachsinns ganz erheblich gehirnamputiert ist. Auch im von ihm selber verlinkten Datenblatt gibt es nur die ZWEI Atmel-üblichen Diagramme, hier unter den Bezeichnern "Figure17-3" und "Figure17-4". Das die in Wirklichkeit jeweils zwei Modi darstellen, hatte ich natürlich auch gesagt, Zitat: > aber nur zwei, in denen jeweils zwei Modi zusammengefaßt > dargestellt werden.
Beitrag #7102303 wurde von einem Moderator gelöscht.
Matthias S. schrieb: > Ich frag mich beim SPI Interface, also die Hardware im AVR, oft, wo sie > mir Arbeit spart. Speziell bezogen auf Displays: Immer dann, wenn man keine Diashow will, sondern möglichst flüssige/unmerkliche Bildwechsel. Gleichzeitig aber noch was anderes in "Echzeit" wahrnehmen will/muss. So zum Einarbeiten in die Problematik folgendes Hobbyprojekt: implementiere einen Oszi. Wir brauchen nicht darüber zu diskutieren, dass das (selbst bei optimaler Implementierung) ein recht unbrauchbares Gerät sein würde, nicht zu vergleichen mit einem wirklichen Oszi, selbst einem sehr billigen. Aber es wird dir zeigen, warum es sinnvoll ist, vorhandene Hardware zur Beschleunigung zu verwenden, statt in stumpfdoofer Arduino-Manier zu erwarten, dass es an jedem Pin gleich gut funktioniert und die unsäglichen Software-Ersatzlösungen auch nur annähernd brauchbar wären.
DerEinzigeBernd schrieb im Beitrag #7102303: > Der Hassprediger kann offensichtlich nicht lesen. > > DerEinzigeBernd schrieb im Beitrag #7102177: >> Oh, ich muss mich korrigieren. Die von mir vorgefundenen Diagramme >> beschreiben die SPI-Betriebsarten der USART. Das hast du nachweislich mehr als eine Stunde nach meinem ursprünglichen Posting geschrieben, wie jeder leicht nachvollziehen kann, das war nämlich: 19.06.2022 14:13 Beitrag "Re: Attiny 841 mit SPI ein Display ansteuern" Das Posting, in dem du deinen dämlichen Kommentar quasi zurückziehst war: 19.06.2022 15:27 Beitrag "Attiny 841 mit SPI ein Display ansteuern" Also bist du nicht nur dumm, sondern ein bewusster Störer. Du hättest zwar gerne darauf hinweisen können, dass es bessere Diagramme in DB gibt, aber du kannst niemanden anblaffen, wenn der sagt, dass es sie nicht dort gibt, wo sie primär hingehören. Die nette (fehlende) Tabelle gibt's aber übrigens auch dort nicht...
Angehängte Dateien:
-
Tabelle_SPI.jpg
26 KB
Habe im Netz diese Tabelle gefunden. Meint ihr das? Nach den ersten Erklärungen im Netz, arbeiten die meisten mit der Nr3. Vorteile oder Nachteile, wieso gerade diese? Fragen über Fragen, ich weiss. Dann gibt es einige Begriffe die ich nicht so zuordnen kann oder nennen die sich einfach nur anders? SS CS RS ??? Mosi / Miso ???
Henry schrieb: > Habe im Netz diese Tabelle gefunden. Meint ihr das? Genau das. > Nach den ersten Erklärungen im Netz, arbeiten die meisten mit der Nr3. Kommt natürlich darauf an, was der Peer macht. Was ein Wunder...
Beitrag #7102358 wurde von einem Moderator gelöscht.
Bitte bleibt beide höflich. Euer Streit löst mein Problem nicht. Ansonsten können wir ja mal den Vorschlag machen eine neu Rubrik aufzumachen. Dachte dabei an so was wie "Ring". Dort kann man sich dann ausgiebig belegen. Bitte bleibt freundlich.
@Henry Nachdem Du absolut keine Ahnung vom SPI hast, würde ich Dir empfehlen, erst mal mit dem MCP23S17 und dem Attiny 841 zu üben - Schalter einlesen und LEDs ansteuern. Und erst wenn Du die SPI Kommunikation beherrschst, solltest Du Dich dem Display widmen. Es gibt zudem auch Dokumente von Atmel mit Informationen über die SPI Kommunikation
Heiner schrieb: > Es gibt zudem auch Dokumente von Atmel mit Informationen über die SPI > Kommunikation Leider habe ich diese Infos nicht gefunden. Haben jetzt wahrscheinlich alle einen neuen Namen bekommen. Heiner schrieb: > würde ich Dir empfehlen, > erst mal mit dem MCP23S17 und dem Attiny 841 zu üben Das ist eine gute Idee. Diesen IC als SPI habe ich nicht zu liegen. Noch eine Frage dazu. Der Attiny841 verwendet ja die Pins PA4 und PA6 als Ausgang für I2C und SPI. Das bedeutet, es kann nur I2C oder SPI verwendet werden. Beides gleichzeitig geht nicht. Korrekt?
Henry schrieb: > Der Attiny841 verwendet ja die Pins PA4 und PA6 > als Ausgang für I2C und SPI. Das bedeutet, es kann nur I2C oder SPI > verwendet werden. Beides gleichzeitig geht nicht. Korrekt? Nein; die USARTs können ebenfalls für SPI-Betrieb verwendet werden. Und die nutzen andere Pins als die reine SPI-Hardware. Die Pinbeschreibung im Datenblatt ist da leider sehr unübersichtlich, Du bist mit PA4/PA6 für SPI auch drauf reingefallen. (Alle Pinnummern für 14p Gehäuse) Die "reine SPI-Hardware" nutzt MISO (Pin 13 PA0) MOSI (Pin 12 PA1) SS (Pin 11 PA2) SCK (Pin 10 PA3) Die beiden USARTs nutzen im SPI-Mode ihre jeweiligen Pins so: TxD0 - MOSI (Pin 12 oder Pin 6 PA7) RxD0 - MISO (Pin 11 oder Pin 5 PB2) XCK0 - SCK (Pin 10 PA3) TxD1 - MOSI (Pin 8 PA5) RxD1 - MISO (Pin 9 PA4) XCK1 - SCK (Pin 7 PA6) Das Slave-Select-Signal gibt es bei den USARTs nicht, wenn Du das brauchst, musst Du das von Hand mit irgendeinem Portpin nachliefern. Die I2C-Schnittstelle nutzt SCL (Pin 9 PA4) SDA (Pin 7 PA6) Damit kannst Du SPI und I2C gleichzeitig verwenden, bei SPI kannst Du sogar zwischen USART0 und der SPI-Hardware wählen.
Ach ja, sieh Dir im Datenblatt genau die "Alternate Port Functions" ab Seite 63 an, da steht exakt, welcher Port welche andere Funktion haben kann.
Henry schrieb: > Habe im Netz diese Tabelle gefunden. Meint ihr das? SCL ist ein Signal vom I²C. Beim SPI heißt dieses Signal entweder SCK oder SCLK. Insoern ist die Quelle verbesserungsdüfrtig... Ich nehme immer das Bild dort: http://www.lothar-miller.de/s9y/categories/17-SPI Denn sogar Atmel verwendet die Polarität für CPOL und CPHA die Motorola-Definitionen. Ein CPHA=CPOL=1 ergibt also SPI-Mode 3. CPOL = 0 bedeutet, dass der Ruhepegel 0=low ist (also der Pegel, die der SCLK haben muss, wenn SS# auf low geht). Bei CPOL=1 ist der Ruhepegel also high. Und CPHA habe ich mir so gemerkt: die Daten werden mit CPHA=0 an den Odd-Flanken (odd = ungerade, also 1,3,5,7,9...) übernommen. Mit CPHA demzufolge an den anderen (geraden) Taktflanken. Mit diesen 2 Eselsbrücken kann ich mir in kurzer Zeit den SPI herknobeln. Und der Mode ergibt sich dann als Binärwert [CPOL:CPHA].
:
Bearbeitet durch Moderator
Nach gefuehlt zuvielen Fehlschlaegen laesst man die vorgegebenen SPI Modi des Controllers sein und schaut sich das geforderte Timing im Datenblatt des Displays an. Dann bildet man das mit den einzelnen Pins nach.
Im Moment komme ich mit den verschiednen Versionen ganz schön durcheinander. DerEgon schrieb: > Die "reine SPI-Hardware" nutzt > MISO (Pin 13 PA0) > MOSI (Pin 12 PA1) > SS (Pin 11 PA2) > SCK (Pin 10 PA3) Auf der genannten Seite steht hinter jedem Pin (PA0-PA3) den du genannt hast noch "alternative". Bei den anderen steht "default". Bei einigen Hardware Zeichnungen im Netz wird PA4-PA7 verwendet. Welche Version sollte man den jetzt nehmen?
Purzel H. schrieb: > Nach gefuehlt zuvielen Fehlschlaegen laesst man die vorgegebenen SPI > Modi des Controllers sein ... > Dann bildet man das mit den einzelnen Pins nach. Echt jetzt? Bitbanging? So bekommt man jeden MHz-Boliden langsam... > Nach gefuehlt zuvielen Fehlschlaegen laesst man die vorgegebenen SPI > Modi des Controllers sein und schaut sich das geforderte Timing im > Datenblatt des Displays an. Man schaut einfach mit dem Oszi, ob das Timing, das der Controller generiert, zu dem Timing passt, das der Slave im Datenblatt verlangt. Und wenn das passt (sind ja vom Master zum Slave nur 3 Signale), dann läuft der SPI.
Henry schrieb: > Auf der genannten Seite steht hinter jedem Pin (PA0-PA3) den du genannt > hast noch "alternative". Bei den anderen steht "default". Datenblatt, Seite 159, Abschnitt 17.5.4 Register REMAP
Danke für die gute Antwort. Damit ist das Pin Mapping klar.
Morgen Es gibt ja vom gleichen Hersteller den MCP23 S 17 und den MCP 23017. Einer ist für SPI und der andere für I2C Bus. Wenn ich die Pins vergleiche gibt es viele übereinstimmungen. Das bezieht sich ja auch auf die Register. Sehe ich das richtig? Bei der Auswahl der Pins wurde angegeben Belegung nach Register Auswahl und Anschluss am MCP PA 4 - SCK - Pin 12 SCK PA 5 - Miso -Pin 14 Miso PA 6 - Mosi - Pin 13 Mosi PA 7 - SS - CS ? - RS ? - Chip Selekt ? - ist das das gleiche? Was ist Miso und Mosi? Dann gibt es noch A0, A1 und A2. Werden damit die Adressen eingestellt, ähnlich wie beim I2C Bus? Sollte die "Chip Auswahl" nicht mit SS (CS oder Rs) erfolgen?
Hallo Henry MISO ==> MasterInSlaveOut (= Signal vom Slave an den Master) MOSI ==> MasterOutSlaveIn (= Signal vom Master an den Slave) SCK Clocksignal (fuer die Daten) CS = Chip Select (wenn mehrere MCP am SPI hängen wird per CS ausgewählt, wer die Daten empfangen/liefern soll). A0 .. A2 = Adresseinstellung MCP - damit kann man bis zu 8 MCP23S17 mit nur einem CS haben. Die Register sind die gleichen (haste ja schon richtig erkannt).
Egonwalter M. schrieb: > MISO ==> MasterInSlaveOut (= Signal vom Slave an den Master) > MOSI ==> MasterOutSlaveIn (= Signal vom Master an den Slave) Die Unsicherheit mit den Namen kommt von den Bezeichnungen am Prozessor und am IC: MOSI - SI MISO - SO SCLK - SCK CEO - CS (SS) Der Nebel hebt sich. Danke
Sorry, noch was vergessen. Ist zum Betrieb mit einem Prozessor ein Quarz notwendig, so 16MHz oder reicht der interne Oszi? (zu ungenau)?
Ist bei SPI egal, da liefert der µC den Takt. Das ist nur bei der UART als asnynchrone serieller Schnittstelle (z.B. für die Kommunikation it einem PC) wichtig, denn da wird kein Takt mitgelifert.
Braucht er nicht. Es wird nur entsprechend langsamer, funktioniert aber bis runter zu "Kippschalter" ;-) Der Clock bestimmt die Bitübernahme, da ist es egal ob der nächste in 1µs oder 10 Sekunden kommt. Da es sowieso nur wenig Daten sind wird selbst mit Bit-Banging das ganze selbst bei 1Mhz schneller sein als man lesen kann.
A. H. schrieb: > Da es sowieso nur wenig Daten sind wird selbst mit Bit-Banging das ganze > selbst bei 1Mhz schneller sein als man lesen kann. Die DOGM LCD sind mit bis zu 20MHz ansprechbar.
Das wären 50nS und schneller als jedes Insekt (500 Bilder pro Sekunde?) lesen kann. :-) Igendwann kommen die Kristalle auch nicht mehr nach. So ab 20? Zeichen pro Sekunde wird es zum "Buchstabenbrei" Schön das es es kann. Aber ausnutzen braucht man es nicht, vielleicht schnell raushauen damit die Cpu Zeit für wichtigeres hat. Aber wenn sie so in Stress gerät wäre es wieder Zeit über SPI oder Paralell nach zu denken.
Henry schrieb: > Sorry, noch was vergessen. > Ist zum Betrieb mit einem Prozessor ein Quarz notwendig, so 16MHz oder > reicht der interne Oszi? (zu ungenau)? Wenn Du NUR den MCP23S17 am Controller betreiben willst, würde ich sagen, dass der interne Oszi reicht (Du wirst ja eh' nur 1 Byte/Zyklus übertragen werden - 1 Byte LEDs - Ausgabe, 1 Byte Schalter - Eingabe). Willst Du aber mehr Peripherie anschließen (Display + I2C Geräte + nutzen des USART zum Datenausgeben per PC - Stichwort "debuggen"), dann würde ich schon einen externen Quarz anschließen.
A. H. schrieb: > Das wären 50nS und schneller als jedes Insekt (500 Bilder pro Sekunde?) > lesen kann. :-) Wenn man Graphik ausgeben möchte, und kein reines Textdisplay à la HD44780 betreiben will, kann ein hoher Takt durchaus sinnvoll sein. Allerdings, das Display des Threadstarters ist ein reines Textdisplay, mit maximal 48 Zeichen ... Da kann dann ein hoher Takt den Sinn haben, daß man das komplette Display ohne große Warterei in einem Rutsch beschreiben kann und dann bis zur nächsten Komplettbeschreiberei viel Zeit zur Verfügung hat. Ob man's wirklich braucht? Wohl eher nicht so.
Stimmt, ist ein Textdisplay. Soll auch nur Text anzeigen und vielleicht ein paar Sonderzeichen. HD44780 verwende ich auch, sowie verschiedene Graphikdisplays und TFTs. Mir kommt es bei diesem Display und dem MCP 23S17 auf den SPI Bus an. Da ich ihn zum ersten mal verwende möchte ich verstehen wie man ihn nutzt. Daher muss ich soviel fragen und hoffe auf eure Hilfe und Erklärung.
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.