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.
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.
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.
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.
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"!
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.
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.
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
constbyteCS=4;
4
5
voidsetup()
6
{
7
SPI.begin(CS);
8
SPI.setClockDivider(CS,84);
9
}
10
11
12
voidloop()
13
{
14
byteA=0b01010101;// Das Bitmuster möchte ich an MOSI schicken
15
byteB=0b00110010;// Im Anschluss soll das Bitmuster direkt losgeschickt werden
16
17
SPI.transfer(CS,A,SPI_CONTINUE);// Sende nun die ersten 8 Bit
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.
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.
