Liebe Leute, anbei eine Frage, die ich bis dato selbst nicht klären
konnte.
Ich möchte über meine SPI Schnittstelle vom DUE ein bestimmtes Byte
rausschicken (MOSI), z.B. 10101010.
Bevor ich irgendein SLAVE anschließe, möchte ich jedoch erst mal
schauen, ob das Bitmuster auch wirklich so rausgegeben wird.
Also messe ich einfach nur an meine MOSI-Leitung gegen Masse und stelle
da fest, dass wir entweder nur HIGH oder LOW haben, nichts
alternierendes.
Mache ich da ein Messfehler oder habe ich ein logischen Fehler?
Ich poste euch den kurzen Code mal dazu:
======================================================
#include <SPI.h>
SPISettings settingsA(1000000, MSBFIRST, SPI_MODE1);
void setup() {
// put your setup code here, to run once:
pinMode (4, OUTPUT);
SPI.begin();
}
void loop() {
// put your main code here, to run repeatedly:
byte A=0b01010101; // Das Bitmuster möchte ich an MOSI schicken
byte B=0b00110010; // Im Anschluss soll das Bitmuster direkt
losgeschickt werden
SPI.beginTransaction(settingsA);
digitalWrite(4,LOW); // Ziehe SlaveSelect auf LOW
SPI.transfer(A); // Sende nun die ersten 8 Bit
SPI.transfer(B); // Sende nun die zweiten 8 Bit
digitalWrite(4,HIGH); // Setze SS auf HIGH
SPI.endTransaction();
delay(1000);
}
======================================================
Über Anregungen, Tipps, etc. wäre ich euch sehr dankbar.
@ Benjamin Nels (Gast) >Also messe ich einfach nur an meine MOSI-Leitung gegen Masse und stelle >da fest, dass wir entweder nur HIGH oder LOW haben, nichts >alternierendes. Oszi richtig benutzt? Trigger auf Normal eingestellt? Richtiger Kanal als Triggerquelle, Triggerlevel? >Über Anregungen, Tipps, etc. wäre ich euch sehr dankbar. Da du so oder so ein Chip Select Signal brauchst, solltest du auch das in deinem Arduino ansteuern und mit einem 2. Kanal anzeigen. Das kann man dann auch wunderbar als Triggerquelle für die Messung nutzen.
https://www.arduino.cc/en/Reference/SPI nachlesen ! besonders hier https://www.arduino.cc/en/Reference/DueExtendedSPI Der DUE ist eben ein ARM und der funktioniert etwas anders ;).
:
Bearbeitet durch User
Marco H. schrieb: > https://www.arduino.cc/en/Reference/SPI nachlesen ! Das solltest vielleicht du tun bevor du hier deinen Mist postest. Ich habe es mal schnell ausprobiert. Der vom TO gezeigte Code funktioniert so wie er soll. Siehe auch Screenshot vom Oszilloskop.
Angehängte Dateien:
-
Tds_220.png
2,9 KB
Due Mitläufer schrieb: > Siehe auch Screenshot vom Oszilloskop.
Falk B. schrieb: > Da du so oder so ein Chip Select Signal brauchst, solltest du auch das > in deinem Arduino ansteuern und mit einem 2. Kanal anzeigen. ... oder als Hilfestellung mal das delay(1000); auf 1ms reduzieren damit die Wiederholrate gross genug ist. Dann sieht man (leichter) auch auf einem analogen Oszilloskop die Daten- bzw Clock-Pakete.
Dann lege mal den CS auf und dann schau mal wo der ist ? Das meinte ich mit Nachlesen. Dann mit einen Device funktionierte dies vermutlich dann nicht mehr bei größeren Clock.
:
Bearbeitet durch User
Marco H. schrieb: > Dann lege mal den CS auf und dann schau mal wo der bei 10MHZ ist ? Das > meinte ich mit Nachlesen. Dann mit einen Device funktionierte dies > vermutlich dann nicht mehr. Bevor du hier weiteren unverständlichen Mist schreibst solltest du vielleicht erst mal öffentlich einsehen dass dein erster Beitrag hier im Thread schon Mist ist.
Nicht verständlich geschriebenen das der DUE einige Besonderheiten mit sich bringt. Genau das steht da nämlich drin.. Das Verhalten kam vermutlich vom falschen Trigger. Trotzdem wird es nicht funktionieren, der CS sollte von der Hardware betätigt werden. Selbst bei 1MHZ kann das mit dem Arduino schon nicht mehr funktionieren da das Pin Umschalten erheblich viel Code anschiebt wie man das auf Register Ebene erledigen würde. Leg doch mal den CS auf ? Schraube den Clock von 1MHZ auf 10MHZ und schaue wie der im Signal liegt. digitalWrite() dürft nicht warten bis der Pin den zustand erreicht hat.
:
Bearbeitet durch User
Marco H. schrieb: > Trotzdem wird es nicht funktionieren, > der CS sollte von der Hardware betätigt werden. Du hast die Funktion von CS nicht verstanden, für Benjamins Aufbau ohne Slavebaustein am SPI ist der irrelevant. Akzeptiere die Kritik von "Due Mitläufer"!
Angehängte Dateien:
-
Tds_220_cs.png
2,7 KB
Marco H. schrieb: > Trotzdem wird es nicht funktionieren, > der CS sollte von der Hardware betätigt werden. Höre endlich auf deinen geistigen Dünnschiss hier abzulassen. Ich benutze den Soft-CS seit ewigen Zeiten und er funktioniert einwandfrei, auch im Code-Beispiel des TOs. Siehe auch Screenshot. Ich wollte hier deine einzelnen Dünnschisse widerlegen aber das ist mir zu mühsam diesem offensichtlichen Mist zu widersprechen.
Na dann wenn nichts dran hängt dann braucht er den SPI Port ja auch nicht. Scherz beiseite, da kommt aber etwas rann. Schau dir von SPI Devices die Spezifikation an. Dann kommen wir auf den CS zurück... Das Problem ist beim Soft CS das die Daten schon ausgebenden werden obwohl der CS nicht unten ist. Das Datensignal wird zum Anfang verschluckt. Weil das Umschalten des Pins zu lange dauert. Bei 1MHZ funktioniert das ewt. noch, bei 10MHZ nicht mehr. Jetzt könnte man ein delay zwischen packen das ginge, ist aber unschön und mindert die Framerate. Der Frust warum nichts brauchbares zurück kommt ist ihm sicher. Über den Rest kann man streiten, es schadet nie ins Manual zu schauen.
Marco H. schrieb: > es schadet nie ins Manual zu schauen. Es schadet nie die Fresse zu halten wenn man keine Ahnung hat.
Na dann macht mal... mit euren Soft CS schau mal bei 10MHZ oder 25MHZ und ziehe dir die Spezifikation einen SPI Devices zu rate. Aus Erfahrung kann ich der sagen das beim SAM21D ab 5MHZ mit einen Soft CS nichts mehr funktioniert. Tja mit ASM braucht man deutlich weniger Takte. Das ist eben der Dünnschiß aus der Praxis. Und warum das eben so schön funktioniert hat steht auch da drin. "NB : once SPI.begin() is called, the declared pin will not be available as a general purpose I/O pin" Dein digitalWrite() ist wirkungslos weil der MUX schon auf dem Hardware SS geschaltet wurde. Ehrlich zugegeben das ist mir auch gerade eingefallen, weil das Signal so sauber aussah ;). Benutze mal einen anderen PIN und dann schau nochmal nach auch bei höheren Clock.
:
Bearbeitet durch User
Danke für eure Antworten liebe Leute, aber streitet doch bitte nicht. Falk B. schrieb: > Oszi richtig benutzt? Trigger auf Normal eingestellt? Richtiger Kanal > als Triggerquelle, Triggerlevel? Wozu eine Triggerquelle? Ich sende das Bitmuster doch eig. in der Loop-schleife, d.h. das Bitmuster wird immer wieder neu ausgegeben, dadurch reicht mir doch eine normale Messung am Oszi ohne irgendwelche Trigger. Marco H. schrieb: > https://www.arduino.cc/en/Reference/SPI nachlesen ! > > besonders hier https://www.arduino.cc/en/Reference/DueExtendedSPI > > Der DUE ist eben ein ARM und der funktioniert etwas anders ;). Was will man mir hiermit sagen? Entweder hilfreiche Antworten oder lass es einfach. Die beiden Seiten kenne ich. Due Mitläufer schrieb: > delay(1000); > > auf 1ms reduzieren damit die Wiederholrate gross genug ist. > Dann sieht man (leichter) auch auf einem analogen Oszilloskop > die Daten- bzw Clock-Pakete. Das werde ich mal probieren. Aber wie gesagt, meiner Meinung nach muss ich doch keine bestimmten OSZI-Einstellungen treffen, oder? Der Normal-Modus sollte doch ausreichen, oder muss ich triggern? Triggern müsste ich doch nur, wenn das Bitmuster nur ein einziges mal ausgegeben wird. Da ich jedoch in der void loop() Funktion den Code eingefügt habe, wiederholt er sich doch die ganze Zeit, ähnlich einer for-schleife. Von daher sollte das Bitmuster doch immer wieder neu gesendet werden nach einem Takt. Daher reicht meiner Meinung nach nur ein Normal-Modus. Vielen Dank für eure Antworten.
Benjamin Nels schrieb: > Vielen Dank für eure Antworten. Mit deiner Reaktionszeit wird es vielen schwerfallen weiter auf dich einzugehen. Benjamin Nels schrieb: > Triggern müsste ich doch nur, wenn > das Bitmuster nur ein einziges mal ausgegeben wird. Müssen tut man nur sterben. Aber es ist wesentlich leichter mit einer Triggerschwelle zu arbeiten. Dass du deinen Trigger- Pegel auf das eingespeiste Signal selbst richten kannst hast du noch gar nicht verstanden. Also: - Trigger auf intern schalten. - Trigger Quelle auf den Kanal den du betrachten willst - Trigger Level auf 1/2 Logikpegel also ca 1.6V
Benjamin Nels schrieb: > Was will man mir hiermit sagen? Entweder hilfreiche Antworten oder lass > es einfach. Die beiden Seiten kenne ich. Na, na na... Nicht so schnell... Lesen und Verstehen, sind oftmals 2 paar Schuhe. Wenn du den Default SS verwendest, gibts keine Extrawurst zu backen. Aber hier will Pin 4 als CS genutzt werden. Und dann ist der Artikel doch schon interessant! Merksatz: PinMode und DigitalWrite sind Gift für den DUE SPI Dieses funktioniert mit Pin 4 als CS:
1 | #include <SPI.h> |
2 | |
3 | const byte CS = 4; |
4 | |
5 | void setup() |
6 | {
|
7 | SPI.begin(CS); |
8 | SPI.setClockDivider(CS,84); |
9 | }
|
10 | |
11 | |
12 | void loop() |
13 | {
|
14 | byte A=0b01010101; // Das Bitmuster möchte ich an MOSI schicken |
15 | byte B=0b00110010; // Im Anschluss soll das Bitmuster direkt losgeschickt werden |
16 | |
17 | SPI.transfer(CS,A,SPI_CONTINUE); // Sende nun die ersten 8 Bit |
18 | SPI.transfer(CS,B); // Sende nun die zweiten 8 Bit |
19 | }
|
Marco H. schrieb: > Selbst bei 1MHZ kann das mit dem Arduino schon nicht mehr funktionieren > da das Pin Umschalten erheblich viel Code anschiebt wie man das auf > Register Ebene erledigen würde. Auch beim Arduino Due steht es jedem frei, einen Pin direkt über die Register zu steuern, so wie es ihn am besten deucht.
Benjamin Nels schrieb: > Der Normal-Modus sollte doch ausreichen, oder muss ich triggern? Wie willst du den Normal-Modus ohne Trigger benutzen? Ob du direkt über das Eingangssignal, einen weiteren Eingangskanal oder einen externen Trigger triggerst, steht dir frei.
Beitrag #5294870 wurde von einem Moderator gelöscht.
Arduino F. schrieb: > Merksatz: > PinMode und DigitalWrite sind Gift für den DUE SPI Deswegen schaut mein Test auch so nichtfunktional aus. Ich bin voll verweifelt. Due Mitläufer schrieb: > Siehe auch Screenshot.
Du kannst machen, was du für richtig hältst! Aber jammere bitte nicht rum, wenn dir die Brocken auf die Füße fallen. Kann auch gut sein, dass dich das nicht interessiert, dass da noch ein anderer CS Pin (der Default SS Pin) völlig sinnbefreit rum zappelt... Alles gut. Das musst du noch nicht einmal ignorieren.
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.