EADOGM mit weiteren Slaves am selben SPI-Bus (Hardware)?

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Aufgrund technischer Veränderungen ist der Mailverkehr innerhalb des Forums (Private Nachrichten) nur noch eingeschränkt möglich. Die Einschränkung ist notwendig, um zusätzliche Betriebskosten für das Forum zu vermeiden. Näheres zu den Hintergründen im Thread "Aktuelles zum Forum".Wir bitten um Verständnis.

    Hinweis kann nach Kenntnisnahme deaktiviert werden!

    • EADOGM mit weiteren Slaves am selben SPI-Bus (Hardware)?

      Hallo!

      Nach etlichen Stunden Frusterlebnisse:

      ATmega1284 hat an seinem Hardware-SPI vier Slaves hängen:
      1: Erstes EADOGM128x64 soll gemischt ca. 70-90% Testbasierend genutzt werden.
      2: Zweites EADOGM128x64 soll später 100% Grafik (xy-Charts) anzeigen.
      3: Ein RFM69HW FFSK-Modem
      4: Eine SDHC-Karte für ein kleines AVR-DOS als Datenlogger

      Wie es sich gehört haben alle SPI-Slaves eigene /CS und der SDHC-Chacht zusätzlich noch parallel vom /CS gesteuerten Bus-Schalter (PI3C3125-W14) welcher die SDCH komplett vom SPI-Bus trennt solange /CS der SDHC high bleibt.

      Mit der Inbetriebnahme des ersten LCD's kamen aber die ersten Probleme:

      BASCOM-Quellcode

      1. $Regfile="m1284def.dat"
      2. $Crystal=11059200
      3. $hwstack=400
      4. $swstack=200
      5. $framesize=320
      6. $Baud=115200
      7. $Baud1=38400
      8. $LIB "I2C_TWI.LBX"
      9. $LIB "glcdEADOGM128x6.lbx"
      10. 'Eingangsdefinitionen:
      11. PR alias Pina.0 'RFM-Signal Payload Ready
      12. PS alias Pina.2 'RFM-Signal Packet Sent
      13. SDwp alias pinb.3 'SD-Meldung Schreibschutz aktiviert
      14. SDcd alias Pinb.4 'SD-Meldung Karte eingesteckt!
      15. S1 alias pind.4 'Taste S1
      16. S2 alias pind.5 'Taste S2
      17. S3 alias pind.6 'Taste S3
      18. S4 alias pind.7 'Taste S4
      19. 'Ausgangsdefinitionen:
      20. LCD1ss alias porta.4
      21. LCD2ss alias porta.5
      22. LCDa0 alias Porta.6
      23. LCDrst alias Porta.7
      24. RFMrst alias portb.0 'Reset-Signal RFM69HW
      25. RFMss alias portb.1 'Slave-Select RFM69HW
      26. SDss alias portb.2 'Slave-Select SDHC-Card
      27. WC10 alias portc.2 'Schreibschutz IC10
      28. WC11 alias portc.3 'Schreibschutz IC11
      29. LSP alias portc.4 'Pizo-Signalgeber
      30. Licht alias portc.5 'LCD-Beleichtung
      31. LCDrst = 1
      32. LCDa0 = 1
      33. LCD1ss = 1
      34. LCD2ss = 1
      35. RFMrst = 0
      36. RFMss = 1
      37. SDss = 1
      38. WC10 = 1
      39. WC11 = 1
      40. LSP = 0
      41. Licht = 1
      42. config SPI = HARD, INTERRUPT=OFF, DATA_ORDER=MSB , MASTER=Yes , POLARITY=Low , PHASE = 0 , CLOCKRATE=4 , NOSS=1
      43. SPIINIT
      44. Config GRAPHLCD = 128 * 64eadogm , Cs1 = Porta.4 , A0 = Porta.6 , SI = Portb.5 , SCLK = Portb.7 , Rst = Porta.7
      Alles anzeigen

      Führte dazu das dass LCD nicht funktionierte.

      Setze ich die Config SPI (Zeile 47) unter die Config GRAPHLCD initialisiert endlich das LCD, jedoch mit konfiguration des dann folgenden Config SPI friert ds LCD ein und nimmt meine neuen Befehle mehr an.

      Offenbar kollidiert die glcdEADOGM128x6.lbx mit der Config SPI, weil sie selber bereits die Hardware-SPI-Pins definiert.

      Gibt es einen Trick die glcdEADOGM128x6.lib dennoch mit anderen SPI-Slaves am Hardwarebus zu stricken?

      Alternativ: Wenn ich die zwei LCD's ganz ohne Lib direkt via SPI befeuere, wie bekomme ich dann die Textfonts ins obere LCD?

      Jürgen
    • Ich kenn mich ja nicht aus, aber vielleicht hängt dein Problem mit dem ss-pin zusammen. In der Hilfe zu spi steht
      When using NOSS=1 : In order to use the Hardware SPI in master mode, you need to set the SS pin to output. In input mode, this pin can be used to set the SPI bus into slave mode. You only need to set the pin to output when you use the NOSS=1 option. With NOSS=0, the compiler will set the SS pin to output and makes SS pin logic 1.
      When NOSS=1 is used, the SS pin is only made an output pin in MASTER mode. No logic level is set when NOSS=1.

      Ich finde das alles bisschen verwirrend, aber vielleicht hilft das weiter.
      avrhelp.mcselec.com/config_spi.htm
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Hallo tschoeatsch!

      tschoeatsch schrieb:

      Ich kenn mich ja nicht aus, aber vielleicht hängt dein Problem mit dem ss-pin zusammen. In der Hilfe zu spi steht
      When using NOSS=1 : In order to use the Hardware SPI in master mode, you need to set the SS pin to output.

      Ja, ist verwirrend, stimmt.
      Nach meinem Verständniss ist damit für meine bisherigen Anwendungsfälle (µC als Master) nichts weiter gemeint als:
      Hast du mehrere Slaves und somit mehrere /SS-Pins, sollte man mit NOSS=1 den einzelnen Standard-/SS abwürgen und die /SS selber steuern.
      Hat man hingegen nur einen einzelnen Slave am Bus, kann man NOSS=1 wechlassen und braucht den /SS dann auch nicht selber immer Low und High schalten. Denn das geht dann automatisch bei SPI-Kommunikation.
      Bei mehr als einem Slave ist das aber kontraproduktiv.

      Mein Problem von oben basiert schlicht darauf das Config SPI mit Config GRAPHLCD in Verbindung mit glcdEADOGM128x6.lbx kollidiert. Denn ganz offensichtlich nutzt die glcdEADOGM128x6.lbx nicht einen bereits eingerichteten SPI, sondern definiert wohl einen eigenen Soft-SPI - dummer weise aber auf den Pins die bereits als Hardware-SPI genutzt werden.

      Eben so dumm: Bascom gibt nicht mal eine Fehlermeldung aus beim kompilieren.

      Und so macht der µC die Funktion halt Abhängig von der jeweiligen Konfigurationsfolge:


      Richte ich erst einen Config SPI = Hard ein, funktioniert das solange, bis Config GRAPHLCD da einen eigenen Soft-SPI auf die Pins legt. SPI-Bus tot, aber LCD funktioniert.


      Umgekehrt: Richte ich zuerst Config GRAPHLCD ein und geben eine Einschaltmeldung auf's LCD, funktioniert das.

      Kommt dann der Config SPI, ist ab diesem Punkt das LCD eingefrohren, kein Zugriff mehr.


      Allerdings: Wo ein Wille, da auch ein Gebüsch:

      Anfangs war ja eh geplant eines der beiden 128*64 EADOGM auf Pixelebene grafisch an zu steuern.

      Nachdem ich mich eingelesen habe wie das exakt funktioniert, kann ich mir auch einen abgespeckten Font für das erste LCD selber basteln.

      Somit versuche ich nun ohne Config GRAPHLCD und der glcdEADOGM128x6.lbx die Displays komplett manuell als normale SPI-Slaves zu befeuern.


      Nur wie schon häufiger zweifel ich langsam daran ob der gewählte ATmega1284 noch ausreicht. Alleine für die bisherigen LCD-Versuche kratzte ich schon an die 6% Flash-Belegung. Naja - Augen zu und durch - hat bisher immer irgendwie gepasst.


      Grüße


      Jürgen
    • Ich hab' jetzt mein Zitat auch noch mal ganz langsam gelesen und glaube, es jetzt verstanden zu haben.
      Wenn du noss=1 vorgibst, dann wird dieser pin nicht als ss verwendet und du musst dir selber einen/mehrere pin einrichten, aber wenn du den spi im master-Betrieb verwenden willst, dann muss trotzdem dieser pin auf output geschaltet werden. Input wäre spi-slave.
      In input mode, this pin can be used to set the SPI bus into slave mode.
      Es ist so, aus meiner Sicht, schon nötig, den ss als output zu konfigurieren, weil ja per default der sonst ein input wäre und ein low den slave auswählt. Was passiert, wenn du mit der aktuellen Einstellungen den ss auf high legst , läuft dann dein display?

      Das kopieren der Tabelle hat nicht geklappt, aber betrachte mal:

      TABLE 2. Overview of SS pin.
      in der Hilfe
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von tschoeatsch ()

    • Das display scheint ja was anzuzeigen. Den ss auf high wäre eine Möglichkeit, zumindest meine ich das aus der Hilfe herauszulesen. Alternativ einfach das noss weg lassen, es gibt ja sowieso ss-pins für die einzelnen slaves, die manuell gesetzt werden müssen. Und ob der hardware-ss jetzt rum zappelt, ist ja dann auch wurscht. Wenn man noss=1 setzt und ss auf output, dann kann man den hardware-ss für beliebigen output verwenden, da sehe ich den einzigen Vorteil der ganzen Sache mit dem noss.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Hallo!

      tschoeatsch schrieb:

      Es ist so, aus meiner Sicht, schon nötig, den ss als output zu konfigurieren, weil ja per default der sonst ein input wäre und ein low den slave auswählt. Was passiert, wenn du mit der aktuellen Einstellungen den ss auf high legst , läuft dann dein display?

      Das kopieren der Tabelle hat nicht geklappt, aber betrachte mal:

      TABLE 2. Overview of SS pin.
      in der Hilfe

      Hmm, kann man anhand der etwas verwirrenden Hilfe durchaus so verstehen.
      Halte diese Intepretation aber etwas fragwürdig: Die Firmware sollte definieren ob die Pins ein Master oder ein Slave sein sollen. Es wäre theoretisch noch eine dritte definition sinvoll die beides umfasst (Multi-Master).
      Aber via Hardware den /SS (PortB.4) als Master/Slave-Bestimmer, wenn die Firmware das gar nicht berücksichtigt?

      Gut, ganz so falsch scheine ich mit meiner Interpretation gar nicht falsch zu liegen...gerade getestet:
      Der Hardware-/SS PortB.4 ist bei mir als Input beschaltet und hängt am CD-Pin des SD-Schachtes.
      Bislang war dieser PB4 immer High, weil dort der interne PullUp aktiviert ist und der CD-Kontakt bislang immer geöffnet.
      Also gerade mal ne SDHC eingeschoben, PB4 also Low. SPI-Verkehr z.B. zum LCD ist dennoch weiter möglich.
      Das bestätigt meine Annahme das der PB4 bei Verwendung von NOSS als gewöhnlicher IO beliebig verwendbar ist.

      Was ich aber vermute, worauf die Verwirrung beruht bei der SPI-Hilfe von Bascom:
      m.E. hätte der Author zwei sauber getrennte Kapiten machen sollen für SPI-Master und komplett getrennt davon der Sonderfall SPI-Slave.
      Das SPI-Kapitel pendelt derart häufig zwischen Normalfall (µC als Master) und Spezialfall (µC als Slave) das die Hilfe dort mehr verwirrt als hilft.
      Was mir damals den Einstieg auch onnötig schwierig machte war die SCK-Polarität.
      Jeder Hersteller verwendet andere Umschreibungen, manche mit CPOL, CHP, Mode usw, manche Hersteller benennen es gar nicht und seigen nur ein Timingchart vo man erkennen kann das z.B. MOSI als gültig übernommen werden bei aufsteigender SCK-Flanke.
      In der Bascom Hilfe steht da was zu, der Configurationsbefehl arbeitet aber wieder anders.
      Wie war das damals? Mode=X geht nur bei Soft-SPI und nicht bei Hard-SPI?

      Schraubbaer schrieb:

      ähm,
      Der syntax ist doch falsch, konfiguriert wird der 128x64eadogm, der benutzte syntax ist aber vom eadog128m

      Hmm...die Syntax...

      Ich verwende:

      BASCOM-Quellcode

      1. Config GRAPHLCD = 128 * 64eadogm , Cs1 = Porta.4 , A0 = Porta.6 , SI = Portb.5 , SCLK = Portb.7 , Rst = Porta.7

      Im zu Bascom gehörenden Sample EADOGM128.BAS wird verwendet:

      BASCOM-Quellcode

      1. Config Graphlcd = 128 * 64eadogm , Cs1 = Portd.4 , A0 = Portd.7 , Si = Portb.3 , Sclk = Portb.5 , Rst = Portd.5

      Abgesehen von den angepassten Ports sehe ich da keine Unterschiede - oder welche Syntax meinst du?

      Grüße

      Jürgen
    • tschoeatsch schrieb:

      aber wenn du den spi im master-Betrieb verwenden willst, dann muss trotzdem dieser pin auf output geschaltet werden.
      Ich will das hier nochmal extra hervorheben, weil das ist ein wichtiger Satz. Die AVR Familie muss für den Hardware-Master-Betrieb diesen Pin auf Output haben. Das liegt nicht an Bascom, das ist ein AVR-Problem. Dass es in der Hilfe steht, zeigt, wie umsichtig der Hilfe-Schreiber war.

      DG7GJ schrieb:

      Was ich aber vermute, worauf die Verwirrung beruht bei der SPI-Hilfe von Bascom: m.E. hätte der Author zwei sauber getrennte Kapiten machen sollen für SPI-Master und komplett getrennt davon der Sonderfall SPI-Slave. Das SPI-Kapitel pendelt derart häufig zwischen Normalfall (µC als Master) und Spezialfall (µC als Slave) das die Hilfe dort mehr verwirrt als hilft.
      Wo ist dein Problem? Die Welt ist nunmal kompliziert. Wenn du SPI verstanden hast, dann wird dir die Verwirrung schon klar werden.
    • Hallo!

      Michael schrieb:

      tschoeatsch schrieb:

      aber wenn du den spi im master-Betrieb verwenden willst, dann muss trotzdem dieser pin auf output geschaltet werden.
      Ich will das hier nochmal extra hervorheben, weil das ist ein wichtiger Satz.Die AVR Familie muss für den Hardware-Master-Betrieb diesen Pin auf Output haben.
      Das liegt nicht an Bascom, das ist ein AVR-Problem.
      Dass es in der Hilfe steht, zeigt, wie umsichtig der Hilfe-Schreiber war.
      Nunja, neben der Bascom Hilfe gibt es im Internet mehrere HowDo's zum Thema SPI die deutlich klarer getrennt sind zwischen den grundlegenden Anwendungsarten Master, Slave, Multi-Master.
      Abgesehen davon was alles möglich ist, ging es mir bislang nur um reine Master-Topologien und bislang nur grobe Überlegungen vielleicht mal etwas mit mehreren ATMega's als Slave an einem zentralen Master zu machen.
      Liegt aber noch in relativ weiter ferne.

      Michael schrieb:

      Wo ist dein Problem?Die Welt ist nunmal kompliziert.Wenn du SPI verstanden hast, dann wird dir die Verwirrung schon klar werden.

      Das dass Leben häufig komplizierter ist als es sein müsste ist glaube ich allgemeiner Konsens.
      Gerade aktuell wieder so ein Dingen bei der Versuchung das EADOGM128x64 zufuß (ohne LIB) an zu steuern.
      Pixeladressen...:

      Start Line = 1 Byte Wertbereich h40-h7F, simpel.
      Page Adress = 1 Byte Wertbereich hB0-hB8, auch profan.
      Column Adress = 2 Byte völlig wirsch und nicht nachvollziehbar gestrickt:
      Da wird ein 7Bit-Wert (128 Pixelspalten) aufgeteilt in MSB-Nibble im LSB des ersten Adressbytes und dem LSB im LSB des zweiten Adressbytes:

      Quellcode

      1. Spalte 0 : 00010000 + 00000000 = h10 + h00
      2. Spalte 1 : 00010000 + 00000001 = h10 + h01
      3. Spalte 2 : 00010000 + 00000010 = h10 + h02
      4. Spalte 3 : 00010000 + 00000011 = h10 + h03
      5. Spalte 4 : 00010000 + 00000100 = h10 + h04
      6. Spalte 5 : 00010000 + 00000101 = h10 + h05
      7. Spalte 6 : 00010000 + 00000110 = h10 + h06
      8. Spalte 7 : 00010000 + 00000111 = h10 + h07
      9. Spalte 8 : 00010000 + 00001000 = h10 + h08
      10. Spalte 9 : 00010000 + 00001001 = h10 + h09
      11. Spalte 10 : 00010000 + 00001010 = h10 + h0A
      12. Spalte 11 : 00010000 + 00001011 = h10 + h0B
      13. Spalte 12 : 00010000 + 00001100 = h10 + h0C
      14. Spalte 13 : 00010000 + 00001101 = h10 + h0D
      15. Spalte 14 : 00010000 + 00001110 = h10 + h0E
      16. Spalte 15 : 00010000 + 00001111 = h10 + h0F
      17. Spalte 16 : 00010001 + 00000000 = h11 + h00
      18. Spalte 17 : 00010001 + 00000001 = h11 + h01
      19. Spalte 18 : 00010001 + 00000010 = h11 + h02
      20. Spalte 19 : 00010001 + 00000011 = h11 + h03
      21. Spalte 20 : 00010001 + 00000100 = h11 + h04
      22. Spalte 21 : 00010001 + 00000101 = h11 + h05
      23. Spalte 22 : 00010001 + 00000110 = h11 + h06
      24. Spalte 23 : 00010001 + 00000111 = h11 + h07
      25. Spalte 24 : 00010001 + 00001000 = h11 + h08
      26. Spalte 25 : 00010001 + 00001001 = h11 + h09
      27. Spalte 26 : 00010001 + 00001010 = h11 + h0A
      28. Spalte 27 : 00010001 + 00001011 = h11 + h0B
      29. Spalte 28 : 00010001 + 00001100 = h11 + h0C
      30. Spalte 29 : 00010001 + 00001101 = h11 + h0D
      31. Spalte 30 : 00010001 + 00001110 = h11 + h0E
      32. Spalte 31 : 00010001 + 00001111 = h11 + h0F
      33. Spalte 32 : 00010010 + 00000000 = h12 + h00
      Alles anzeigen

      Zurück zum Thema.../SS-Funktionalität PortB.4 beim µC:
      Aufgrund deiner Hervorhebung habe ich nochmal das Datenblatt des ATmega1284 überflogen, und dort den Hinweis unter Punkt 17.3.2 gefunden.

      Zusammengefasst vom Sinn her:
      Als SPI-Master darf der /SS belibig als Input oder Output konfiguriert werden.
      Wird der /SS-Pin jedoch (als Input) extern auf Low gezogen, dann soll der µC das MSTR Bit im SPCR-Register löschen - der Master wird somit angeblich zum Slave.

      Tja, jetzt hänge ich da:
      Mein PortB.4 (Hardware-/SS) ist fest konfiguriert als Input mit aktiviertem PullUp.
      Da hängt der CD-Schaltkontakt eines SD-Sockels dran, welcher PB4 auf Low zieht sobald eine SD-Card im Sockel steckt.
      Diesen Eingang frage ich noch nicht ab in meinem Programm, aber ich kann messen das an PB4 High 3,3V auf Low wechselt sobald eine SD-Karte im Sockel steckt.
      Am SPI, den ich bislang nur sendeseitig am EADOGM betreibe, merke ich bislang keine Auswirkungen.
      Egal ob die SD-Karte steckt oder nicht, also auch wenn der /SS auf Low gezogen ist, kann ich problemlos Daten über den Hardware-SPI an das EADOGM senden.

      Ändern oder nicht?
      Theoretisch käme ich da noch ran, weil die Platine erst Teilbestückt ist.
      Sobald das zweite EADOGM aufgelötet ist, verschwindet der µC da drunter.
      Wenn ändern...tja...PA2 wäre der aller letzte noch unbenutze Port... a_67_e210de67

      Grüße

      Jürgen
    • Hallo!

      Pluto25 schrieb:

      Es sieht so aus als das das Programm sein Zustand bei jedem Schreibauftrag wieder herstellt. Aber sicherheitshalber würde ich ihn gegen einen CS austauschen. wenn er Ausgang ist sollte es nicht schiefgehen. Damit bliebe A2 auch frei.
      Ja, habe mich durchgerungen vor der Endbestückung der Platine den /CD von PB4 auf PA2 zu patchen.
      Leider nicht die erste Änderung dieser Art:
      Nu kommt da also noch ein dritter Draht dran a_51_b30e0498

      Sowas passiert halt wenn man Hardware einbindet, die man noch nicht perfekt kennt.
      Der linke Patch an Pin 40 (PB0) geht auf den RESET-Pin der RFM69HW, der vorher mit an µC-/Reset lag, weil die Erkentniss zu spät kam das der RFM69HW High-Activ resettet.

      Der rechte Patch an Pin 36 (PA1) geht an Ausgang D4 der RFM69HW.
      Auch hier kam die Erkentniss zu spät, das es Sinn macht das Hardwaresignal "Packet Send" mit an den µC zu legen.

      Der dritte Patch nun halt demnächst, weil ich den PB4 nie zuvor als Input nutzte *grumel*

















      So sieht das Gesamtprojekt bislang in der Teilbestückung aus:




































      Grüße

      Jürgen
    • Der hardware ss-pin geht ja nicht verloren. Bei noss=1 zappelt der ja nicht bei jedem spi-Zugriff, die Logik ist mit der Option damit abgetrennt. Aber man kann ihn ja als händischen ss/cs für die restliche hardware verwenden.
      Noch ein Drähtchen mehr <X .
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------