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?
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.
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 ;-)
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.
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...
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...
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.
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].
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
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
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.
