Arduino Uno - SPI Rückkopplung zwischen SCLK und MISO

[Wing (Gast)]

Moin,

ich versuche aktuell ein einfaches SPI-Protokoll auf einem Arduino Uno 
zum laufen zu bekommen... Dafür habe ich eben einen kurzen Beispielcode 
geschrieben, der mein Problem recht schnell verdeutlichen sollte... Wenn 
ich Daten über die SPI-Schnittstelle aussende, kommt es zu einer 
Kopplung zwischen SCLK und MISO und ich verstehe nicht, weswegen diese 
Zustande kommt... vielleicht hat von euch ja einer eine schlaue Idee. 
(s. Bild)
Ich verwende als Oszilloskop eine Analog Discovery 2.

#include <SoftwareSerial.h>
#include <SPI.h>


const int  TEST  = 0x08;
int x = 0;

void setup() {
  Serial.begin(9600);

  digitalWrite(SS, HIGH);
  pinMode(SS, OUTPUT);


  SPI.begin();
  SPI.beginTransaction(SPISettings(4000000, MSBFIRST, SPI_MODE1));
}

void loop() {
  while (x == 0)
  {
    digitalWrite(SS, LOW);
    SPI.transfer(TEST);
    digitalWrite(SS, HIGH);
  }
}

Vielen Dank im voraus und beste Grüße

[Jens M. (schuchkleisser)]

Liegt der MISO-Pin offen, ohne Pullup/down?

[Wing (Gast)]

Ja...
Also einfach bspw. 10kOhm zwischen MISO und GND und alles sollte 
funktionieren? Auch das Daten empfangen?

[Jens M. (schuchkleisser)]

Daten Empfangen tust du ja nicht in dieser Software.
Wenn kein Slave aktiv ist (also alle CS inaktiv) so liegt MISO ja 
"offen".
Da gehört dann ein Pulldown dran, damit sich da ein stabiler Pegel 
einstellt.
Alternativ kann der interne Pullup des Controllers aktiviert werden, 
keine Ahnung ob die Library das macht, und der könnte zu schwach sein. 
Grundsätzlich helfen sollte er allerdings schon.

Der Pull* darf natürlich nicht zu niederohmig sein, aber er stört die 
Datenübertragung nicht. Bloß aufpassen das nicht in der Software der 
Pullup aktiviert wird und extern ein Pulldown läuft, das gibt schräge 
Pegel an den Pins.

Wenn kein Pull* aktiv ist ist der Eingang auf jeden Fall hochohmig, da 
reicht ankucken und er wechselt den Pegel.
Warum das mit deinem Scope auch noch geht, weiß ich nicht, das hat 
normalerweise min. 1MOhm und sollte daher für einigermaßen definierte 
Pegel sorgen, aber versuch doch einfach mal 10k nach GND, kann nur 
besser werden.

[Einer K. (Gast)]

Eigentlich ist es doch völlig egal, was Miso tut, wenn kein Slave daran 
angeschlossen, bzw aktiv, ist. Dann kann doch nur Mist kommen...
Irgendwelche gültige Daten sind nicht zu erwarten.

[Wing (Gast)]

Ich habe den internen Pullup mal aktiviert.
Jetzt kopiert MISO zwar nicht mehr SCLK, dafür aber MOSI?
Mit einem externen Pulldown von 10k wurde es übrigens nicht besser.

Wie auch immer, wenn mein Datenprotokoll vorsieht, dass ich erst zwei 
Bytes sende und dann zwei Bytes als Antwort erwarte vom Slave. Dann 
sollte es ja eigentlich keinen großen Einfluss auf den Slave haben, wenn 
beim schicken der "Befehle" MISO MOSI kopiert, oder?
Allerdings habe ich Angst, dass wenn ich eine Antwort erwarte, MISO MOSI 
weiterhin kopiert und quasi die eigentliche Antwort mit 0x00 
überschreibt.

Beispielsweise:

SCLK: 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
MOSI: 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
MISO: 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 eigentliche Antwort

[Einer K. (Gast)]

Wing schrieb:
> sollte es ja eigentlich keinen großen Einfluss auf den Slave haben,
Du bist verwirrt!

Der Miso Pegel wird vom Slave bestimmt!
IMMER!
(Wenn ein solcher vorhanden und aktiv ist)

Wing schrieb:
> Mit einem externen Pulldown von 10k wurde es übrigens nicht besser.

Dann ist an der Miso Linie doch noch irgendwas dran!
Denn 10k sollten reichen um  Zufallseinstreuungen zu unterbinden.

[Jens M. (schuchkleisser)]

SPI hat die dumme Eigenschaft, das immer gleichzeitg geschrieben und 
gelesen wird.
D.h. du musst erst deine Befehle senden (und liest dabei nichtssagende 
Bits ein, die verworfen werden müssen) und könntest danach eine evtl. 
Antwort sofern erforderlich einlesen (wobei dann Dummybits gesendet 
werden müssen, das kann der nächste Befehl sein, oder auch z.B. 
00000000, was immer der Slave als NOP interpretiert).
Wenn du keinen MISO hast, weil der Slave nur empfängt, ist völlig egal 
was am MISO passiert. Jedwede ankommende Information ist hinfällig und 
muss verworfen werden, ob das jetzt 0,1 oder 255 ist völlig egal.
Was im Endeffekt bedeutet: Sollte ein Empfangsinterrupt kommen, löscht 
man ihn einfach, fertig.

[Wing (Gast)]

Danke!
Dann ist ja alles okay, war sehr verwirrt.

[Wing (Gast)]

Zwei kurze Fragen noch...

Ist es möglich mit einem Arduino Uno 24 Bit hintereinander 
wegzuschicken?
Beim Due gibt es sowas wie "SPI.continue", aber das funktioniert ja 
nicht beim Uno.
Wenn ich jetzt beispielsweise SPI.transfer(), SPI.transfer(); und 
SPI.transfer(); mache, gibt es zeitliche Lücken zwischen den Bytes... 
die würde ich gerne verhindern, sodass quasi kontinuierlich übertragen 
wird.

Wenn ich den CS auf low setze, dann möchte ich gleichzeitig dazu einen 
Synchronisierungspuls über die Leitung ausgeben, gibt es da eine 
Möglichkeit das einzustellen?

[Chicken Wing (Gast)]

Wing schrieb:
> Wenn ich den CS auf low setze, dann möchte ich gleichzeitig dazu einen
> Synchronisierungspuls über die Leitung ausgeben,

Das möchtest du nicht da der CS selbst ja bereits ein
Synchronisierung-Signal ist.

Wing schrieb:
> Ist es möglich mit einem Arduino Uno 24 Bit hintereinander
> wegzuschicken?

Ja.

Wing schrieb:
> die würde ich gerne verhindern,

Erstens geht's nicht da das neue Byte erst geschrieben werden
muss, zweitens stört es niemanden ausser dir. In der
Geschwindigkeit wirst du es auch nicht bemerken.

Wenn du es schneller haben willst dann musst du ohne Arduino
programmieren.

[Einer K. (Gast)]

Wing schrieb:
> Wenn ich jetzt beispielsweise SPI.transfer(), SPI.transfer(); und
> SPI.transfer(); mache, gibt es zeitliche Lücken zwischen den Bytes...
> die würde ich gerne verhindern, sodass quasi kontinuierlich übertragen
> wird.

Wieso interessieren dich die Lücken?!?
Das ist dem SPI "Standard" doch sowas von egal.

Wing schrieb:
> Wenn ich den CS auf low setze, dann möchte ich gleichzeitig dazu einen
> Synchronisierungspuls über die Leitung ausgeben, gibt es da eine
> Möglichkeit das einzustellen?
/CS und dein SPI Takt ist die Synchronisation.
Mehr kann SPI nicht leisten.

[Wing (Gast)]

Mich stören die Lücken, weil beispielsweise mein DAC 16Bit geschlossen 
braucht, um alle Informationen zu erhalten und damit arbeiten muss, 
ansonsten reagiert der nicht.

Bei einem anderen Beispiel kann ich die SPI von einem anderem Programm 
mir über ein Oszilloskop angucken und dort sind auch keine "Lücken", mit 
meinem SPI Protokoll mit "Lücken" funktioniert die Kommunikation 
nicht... (Bei einem ADC)...

Also dachte ich, dass das vielleicht die Lösung meiner Probleme wäre.

[Wing (Gast)]

Beispielsweise so, das eine Bild zeigt lückenlos 24 Bit bei der Clock, 
das andere nicht und ich würde gerne ersteres mit einem Arduino 
hinbekommen, scheine dafür aber zu unfähig zu sein...

[Wing (Gast)]

Ein weiteres Beispiel... das möchte ich beispielsweise auch erreichen, 
nur, dass ich einen ADS1299 verwende.

[Chicken Wing (Gast)]

Wing schrieb:
> weil beispielsweise mein DAC 16Bit geschlossen
> braucht, um alle Informationen zu erhalten und damit arbeiten muss,
> ansonsten reagiert der nicht.

Käse.

Zeige mir welchen DAC du hast der damit nicht funktioniert.
Der Fehler sitzt vor Bildschirm und Tastatur, nicht im Protokoll.

Wing schrieb:
> mit
> meinem SPI Protokoll mit "Lücken" funktioniert die Kommunikation
> nicht... (Bei einem ADC)...

Käse.

Zeige mir welchen ADC du hast der damit nicht funktioniert.
Der Fehler sitzt vor Bildschirm und Tastatur, nicht im Protokoll.

[spess53 (Gast)]

Hi

>Beispielsweise so, das eine Bild zeigt lückenlos 24 Bit bei der Clock,
>das andere nicht und ich würde gerne ersteres mit einem Arduino
>hinbekommen, scheine dafür aber zu unfähig zu sein...

Da nimmt man einen AVR mit USART im SPI-Mode. Die besitzt eine 
Transmit-Puffer und sendet ununterbrochen solange da etwas drin ist.

Allerdings bin ich der gleichen Meinung wie Hühnerflügel.

MfG Spess

[Wolfgang (Gast)]

Wing schrieb:
> Mich stören die Lücken, weil beispielsweise mein DAC 16Bit geschlossen
> braucht.

Welcher Aussage zum Timing deines DAC aus dem Datenblatt entnimmst du 
diese Anforderung?

Wenn du dir hier qualifizierte Hilfe erhoffst, nenne Fakten, z.B. die 
Typenbezeichnung von deinem DAC und streue nicht irgendwelches 
merkwürdiges Zeugs wie: "Rückkopplung zwischen SCLK und MISO".
Bei einem offenen Eingang hast du einfaches Übersprechen

Wing schrieb:
> Mit einem externen Pulldown von 10k wurde es übrigens nicht besser.
> ...
> Wie auch immer, wenn mein Datenprotokoll vorsieht, dass ich erst zwei
> Bytes sende und dann zwei Bytes als Antwort erwarte vom Slave. Dann
> sollte es ja eigentlich keinen großen Einfluss auf den Slave haben, wenn
> beim schicken der "Befehle" MISO MOSI kopiert, oder?

SPI ist immer ein Datenaustausch. Aus Sicht des Masters werden bei einem 
Transfer immer über MOSI Daten rausgeschickt und gleichzeitig über MISO 
Daten eingelesen. Was damit dann weiter passiert, ist ein anderes Thema. 
Und was der Slave dabei für Daten auf MISO schickt, hängt von deinem 
Slave ab. Solange MISO an einem gerade aktiven Slave hängt, wäre es 
schlimm, wenn ein Pulldown daran etwas ändern würde.

[Einer K. (Gast)]

Mich erinnert diese Art der Lösungssuche an einen alten Witz:

> Der Betrunkene, der unter der Laterne seinen Schlüssel sucht.
> Nach einer Weile kommt ein hilfreicher Passant und sucht mit.
> Eine zweite Weile später, fragt der Passant:
> "Bist du dir sicher, dass du den Schlüssel hier verloren hast?"
> Der Betrunkene:
> "Nee, dahinten, aber hier ist mehr Licht!"

[Wing (Gast)]

Na gut, ihr habt mich überzeugt, dass mein Ansatz totaler Müll ist.