SPI-Signal oder Synchron Uart?

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • SPI-Signal oder Synchron Uart?

      Hallo zusammen
      Ich habe hier an einer Logo am Peripherie-Bus gemessen und bekomme folgendes Oszillogramm.
      DS1Z_QuickPrint5.png
      In Gelb das ist der Clock (IDLE = HIGH), und Blau ist die Datenleitung (IDLE = HIGH).
      Ich versuche das Signal nachzubilden. Aber da gibt es Probleme mit dem Pegel, der nach dem letzten Clock High werden muss.
      Bei SPI bleibt das Signal mit dem letzten Bitwert der Daten stehen, bis das nächste Byte übertragen wird. Bedeutet, es ist mal High mal low.
      Es fällt auf, dass die Datenleitung vor der 1. Clock-Flanke schon auf Low geht. Mit der hinteren Clock-Flanke wird gesampelt.
      Das Letzte Datenbit ist Low bei der letzten steigenden Flanke. Data bleibt aber nicht Low, sondern geht wieder auf High.

      Das macht SPI nicht.

      Könnte es sein, dass es sich hierbei um einer synchrone serielle Schnittstelle handelt?
      Aber da müssten doch auch Clock-Pulse beim Start-Bit und beim Stop-Bit kommen.
      Oder liege ich da falsch?

      Was für ein Signal ist das und wie kann ich das nachbilden mit UART oder SPI (ohne Bitbänging!)?
    • Ja das ist D0, wenn man die Bits bei steigender Clock-Flanke sampelt.

      Ich habe das Signal als "reines SPI-Signal" auf die Erweiterungs-Module gegeben, aber die reagieren nicht.
      Ich vermute mal, dass es keine Synchrone Serielle Schnittstelle ist, denn dann müsste doch für das Startbit und das Stop-Bit auch ein Clock ausgegeben werden.
      Liege ich da richtig?

      Ich habe einen Monitor programmiert, der das SPI-Signal einliest und seriell an den PC sendet.
      Da hatte ich das Problem mit dem Synchronisieren der Bits, da ja kein SS-Signal vorhanden ist.
      Kann also sein, dass die Bits immer verschoben sind im Byte bzw. Bits davon zu einem vorherigen Byte gehören.

      Um das synchron zu bekommen, musste ich mir mit Timer und abfallende Clock-Flanke von SCK ein Slot schaffen (Interrupt), den ich dass als SS-Signal verwenden konnte.
      Damit konnte ich das einlesen.

      Das selbe Problem dürften die Erweiterungs-Module der LOGO auch haben.
      Die müssen also irgendwie sicher erkennen, wann ein Byte ankommt.
      Und meine Vermutung ist, dass auf die erste abfallende Flanke von MOSI das SS-Signal auf low geht, und nach Empfang der 8 Datenbits durch den ISP-Empfangsinterrupt wieder High wird. Zwischen den Bytes liegen 250µs, also lange Pausen.

      Wenn ich jetzt von SPI ausgehe, wie kann ich das hinbekommen, dass ich Senderseitig zuerst die Datenleitung (MOSI) auf Low ziehe (1 µs) und dann erst das Byte per SPI sende.
      Und wenn es gesendet ist, nach 1µs das MOSI-Signal wieder High legen. So wie im Oszillogramm?

      Einfach Set pinMOSI und Reset pinMOSI geht nicht.

      Wenn ich die SPI deaktiviere (SPCR.SPE = 0) kann ich die Pegel ändern.
      Aber muss ich dann wieder die ganze SPI Initialisieren, wenn ich etwas senden will? Oder reicht es, SPCR.SPE = 1 zu setzen?
    • Ich habs jetzt mal mit Abschalten der SPI-Schnittstelle und Aktivierung nur für die Übertragung probiert.
      Wenn nichts übertragen wird, werden MOSI und SCK gesetzt.
      So kommt es dem Original schon nahe, aber mit Schönheitsfehler

      Zum Nachvollziehen, wie die SPI konfiguriert und Aktiviert/Deaktiviert wird hier der Code:

      BASCOM Source Code

      1. Dim _SPI_Config as Byte
      2. Macro WaitSPI
      3. !SBIS SPSR,SPIF
      4. !RJMP -1
      5. '!SBI SPSR,SPIF
      6. End Macro
      7. Macro SPI_Enable
      8. Reset pinMOSI
      9. NOP
      10. NOP
      11. NOP
      12. SPCR = _SPI_Config
      13. 'Waitus 2
      14. End Macro
      15. Macro SPI_Disable
      16. Waitus 10
      17. Reset pinMOSI
      18. SPCR = 0
      19. Set pinMOSI
      20. End Macro
      21. ' ------------------------------------
      22. ' SPI auf ca. 1MHz Takt konfiguriert
      23. ' ------------------------------------
      24. Sub SPI_Init()
      25. Config pinSS = Output ' SS auf Ausgang
      26. Config pinMOSI = Output : Set pinMOSI ' Ruhepegel MOSI = HIGH
      27. Config pinSCK = Output : Set pinSCK
      28. Config SPI = Hard , INTERRUPT = OFF , DATA_ORDER = MSB , MASTER = YES , POLARITY = HIGH , PHASE = 1 , CLOCKRATE = 16 , NOSS = 1 , SPIIN = 0
      29. SPIInit
      30. _SPI_Config = SPCR
      31. End Sub
      Display All
      Übertragung von D0 bei der Logo:
      SPI_D0_LOGO.png

      Meine Nachbildung:
      SPI_D0_Sender.png

      Dann noch ein 2. Beispiel mit Wert A5

      Hier die Logo:
      SPI_A5_LOGO.png

      Und hier die Nachbildung:
      SPI_A5_Sender.png

      Bei den Nachgebildeten Signalen merkt man am Anfang und am Ende des Bytes Unterschiede.
      Ob die Daten nun so von der Logo-Erweiterung akzeptiert werden?

      Edit:
      Erweiterung reagiert nicht.

      The post was edited 1 time, last by Mitch64 ().

    • Mitch64 wrote:

      Erweiterung reagiert nicht.
      Was ne Diva X(
      Sprechen die Byteweise? Nie viele Bytes nacheinander ohne das Datenlow vor und nach dem Byte?
      Da ist es fast schon eingfacher/schneller das Byte selber zu versenden als das Spi mit dem nötigen drumrum. Das ss könnte eine Pulldown Diode und ein kleiner Kondensator erledigen?
      Möglicherweise interpretieren die das Low vorn und hinten wie Start Stop beim i2C und wenn die nicht schön genug sind wirds verworfen?
      Versuch mal Zeile 19 Waitus 5
      und Zeile 22 auch Waitus 5
      dann sollte es den Unterschied nicht mehr erkennen?
    • Pluto25 wrote:

      Möglicherweise interpretieren die das Low vorn und hinten wie Start Stop beim i2C und wenn die nicht schön genug sind wirds verworfen?
      Der Gedanke hat sich mir auch schon aufgedrängt.

      Pluto25 wrote:

      Da ist es fast schon eingfacher/schneller das Byte selber zu versenden
      Du meinst per Bitbanging?

      Da schaffst du aber nicht die Bitrate. SCK-Takt ist 1MHz.

      Pluto25 wrote:

      Sprechen die Byteweise? Nie viele Bytes nacheinander ohne das Datenlow vor und nach dem Byte?
      Die Bytes werden einzeln übertragen. Jeweils davor geht das Datensignal ohne Clock auf Low und danach geht es nochmal auf Low oder Bleibt auf Low ohne Clock.
      So wie es im Oszillogramm abgebildet ist (Siehe SPI_xx_LOGO.pgn).
      Zwischen den Bytes vergehen 250µs, wobei MOSI und SCK HIGH (IDLE) ist.

      Ob die nun Byteweise sprechen?
      Es werden Pakete gesendet mit Startbyte, Datenlänge, Daten, Checksumme etc.
      Aber eben die Bytes alle 250µs ein Byte.
      Pakete werden je nach Typ alle 15ms gesendet bzw. alle 50ms.
      Wenn gerade nichts zum Senden ist, wird eine Sequenz A5, D0 gesendet. Aber auch wieder mit Abstand 250µs.

      Beantwortet das deine Fragen?
    • Ja, jedes Byte das selbe prozedre

      Mitch64 wrote:



      Da schaffst du aber nicht die Bitrate. SCK-Takt ist 1MHz.
      Ist das wirklich nötig? Die meißten sychrone gehen bis "Kippschalter" runter. Und Empfangen könnte das HW Spi
      1Mhz= 8? Takte bei einer riesigen Pause zwischen den Bytes. Das sollte möglich sein.
      PS Das Waitus 10 passt nicht zum Bild? War das waitus 1? Oder kam der "lowpix" woanders her?
    • Pluto25 wrote:

      Ist das wirklich nötig?
      Das weiß ich nicht. Frühere Logos sind auch mit 250kHz gelaufen.
      Ich weiß halt nicht, ob die Erweiterungen diese Pausen zwischen den Bytes brauchen, un IO's zu setzen, abzufragen etc. Keine Ahnung was die intern machen.

      Per Bitbanging kann man es ja mal versuchen. Muss man aber erst mal coden.
      Mit etwas Pech funktioniert das dann auch nicht - vielleicht wegen Timing. Das lässt sich dann schlecht feststellen.

      Vielleicht liegt das Problem aber auch wo anders, dass die Module nicht reagieren.

      Im Moment verwende ich einen Spannungsteiler vom Mosi und SCK (Controller 5V) zur Logo (Eingang 3,3V).
      Der ist vielleicht etwas hochohmig mit 1k2 am Controller und 1k2 gegen Masse. Ich vermute da einen Optokoppler im Erweiterungsmodul.

      Da muss ich mal drüber nachdenken.

      Wäre natürlich schon cool, wenn man gekaufte SPS-Komponenten mit dem Controller steuern könnte.
      Und umgekehrt eigene Erweiterungen basteln.
    • Die 10µs passt zum Bild.
      Denn die 10µs werden gerechnet ab dem Zeitpunkt, wo das SPDR beschrieben wird. Es müssen ja dann 8 Datenbits ausgegeben werden.
      Wird die SPI zu früh abgeschaltet, wird die Übertragung mitten im Byte abgebrochen.

      Besser wäre, per Abfrage des SPIF-Flag zu prüfen, ob das Byte raus ist und dann die SPI abzuschalten.
      Das hatte ich auch mal probiert, aber dann wurde nichts mehr ausgegeben.

      Das ist im Moment eine Notlösung.
    • Normal habe ich das Oszi auch an der 3,3V Seite.
      Aber ich hatte die LOGO-Schnittstelle auf dem Board und separat die von meiner Sender-Software.
      Ich habe dann nur das Oszi umgehängt von LOGO zum AVR um die Signale zu vergleichen.
      Zu dem Zeitpunkt ging es ja um das Abfallen der Datenleitung von dem 1. Clock.

      Inzwischen bin ich etwas schlauer.
      Den Pegelwandler habe ich noch ne Ecke niederohmiger gemacht (560 Ohm und 1k Ohm gegen Masse). Das Signal sieht bei 1Mhz sehr akzeptabel aus.
      Vor allem, wenn die 3,3V noch an die LOGO-Schnittstelle aufgelegt werden.

      Aber trotzdem reagierte die Logo nicht. Am Signal kanns eigentlich nicht mehr liegen.
      Allenfalls am Protokoll.

      Also habe ich mal die Logo über das Steckboard mit dem Erweiterungsmodul verbunden. So kann ich nun jede beliebige Leitung (MOSI, MISO, CLK, 3,3V) auftrennen und schauen was passiert.
      Interessanterweise müssen alle Leitungen (Außer 3,3V) miteinander verbunden sein. Wenn nur eine fehlt, geht das Erweiterungsmodul in den Savemode, und signalisiert das durch eine Rote LED. Verbinde ich die Leitung wieder. geht die LED wieder auf grün und das Relay schaltet wieder wie im LOGO-Programm vorgesehen.

      Ich folgere daraus, dass da eine gewisse Rückkopplung ist von dem was das Modul zur PLC schickt und was sie wieder von ihr bekommt. Sonst müsste auch ohne die MISO-Verbindung alles weiter laufen. In welcher Beziehung nun die rück-gekoppelten Daten stehen entzieht sich meiner Kenntnis. Es sind jedenfalls unterschiedliche Pakete, die auf der MOSI und MISO-Leitung laufen.

      Ohne Logik-Analyser ist man da am Ende. So gut mein Oszi auch ist, das kann es nicht.
      Ich habe also keine Chance, das zu entschlüsseln.

      Schade. Wieder eine Erkenntnis reicher !
    • Wenn das nicht viele Daten sind kann das Ozzi es darstellen.
      Ein Avr könnte es abhören um zu erkennen was da gesprochen wird. ss dauerhaft Low oder besser per Diode mit der Datenleitung steuern. ( Es ist ein Krampf die evt Bitverschobenen Daten zu rekonstruieren wenn man nicht weiss was geprochen wurde)
    • Pluto25 wrote:

      Wenn das nicht viele Daten sind kann das Ozzi es darstellen.
      Mit dem Oszi ist das schon ein Gefrickel, weil ja nur alle 0,25ms ein Byte kommt.
      Ein Frame zum Setzen der Ausgänge ist schon 15 byte lang.
      Man sollte also schon mindestens 30 oder mehr Byte von MOSI und MISO aufzeichnen, um zu sehen, wie das Modul reagiert.
      30 Byte sind aber schon 30 x 0,25ms, die mit dem Oszi aufgezeichnet werden müssen. Und dann hineinzoomen, um die einzelnen Bytes zu sehen.
      Einmal zu schnell gedreht und schon ist man mit dem Cursor im nirvana - und fängt wieder an.
      Natürlich muss man dann nebenher alles aufschreiben, damit man da einen Zusammenhang erkennen kann.
      Wie ich schon sagte ein ziemliches Gefrickel.

      Mit nem ATMega328PB hat man 2 SPI-Schnittstellen.
      Mit der einen am MOSI und mit der anderen am MISO lauschen.
      Pro Datenbyte auf dem MISO müssen dann das gelesene Byte von MISO und das von MOSI seriell an den PC gesendet werden.
      Vom Timing her machbar. Ich muss aber noch ein 3. Byte übertragen, damit ist im Log-File dann sehe, welche 2 Bytes gleichzeitig an MISO und MOSI waren.
      Also pro Byte (8 Clock-Pulse) 3 Bytes an den PC senden.

      Das muss noch bissel reifen. Vielleicht probiere ich das mal aus.

      Pluto25 wrote:

      ss dauerhaft Low oder besser per Diode mit der Datenleitung steuern
      SS dauerhaft auf LOW geht nicht. Wenn beim Einschalten Pulse kommen, fängt duie SPI mittendrin an. Der Bit-Versatz bekommt man nicht synchronisiert.
      Ich hatte das oben schon erklärt. Man muss sich ein eigenes SS-Signal generieren, das aus der MOSI oder SCK Leitung gewonnen wird.
      Im einfachsten Fall ein retriggerbares Mono-Flop, das bei neg. Flanke getriggert wird. Die Mono-Zeit etwas über einen Takt der SPI. Also z.B. 1,5µs bis 2µs.
      Das sollte klappen.

      Ich hatte das oben ja mit einem Interrupt und einem Timer gemacht. Siehe Code-Schnipsel Post #4.