Kann es sein das man beim MCP3008 keine Standard 8 Bit zur Übertragung
nutzen kann?
sowohl mit Variante 1 als auch 2 klappt es nicht.
1.
1
CS:=0;
2
var3:=0;
3
SPI1_Write(%11000000);
4
lo(var3) := SPI1_Read(8);
5
CS:=1;
Klar, weil bei Variante ein werden nur 8 Bit ins Register
hineingeschoben(bzw 16 Takte), also bekomme ich auch nur wieder 8
heraus, das erscheint mir recht klar.
Bei Variante 2 wird es etwas komplizierter, da es nun 32 Takte sind,
wird das Signal einmal normal und einmal gespiegelt ausgegeben?!
In keinem Fall bekomme ich so ein brauchbares Ergebnis.
Wie müsste es richtig aussehen?
2.
Versuche mit 16 bit zu experimentieren. Vielleicht klappt das irgendwie
doch. Eventuel wir beim einschiften der Rest ignoriert. Ausschiften ist
ja klar, du musst die extra bits ignorieren.
Sonst kann man mit Bitbang SPI losgehen. Ist zwar nicht so elegant, aber
dennoch recht flexiebel.
Eventuel auch gemixt, Bitbang für den einschiften, und 2*8bit lesen
durch den Peripherie lib oder SPI Treiber was du jetzt hast.
127 = 00000000 01111111
128 = 00000000 10000000
32896 = 10000000 10000000
shifte ich dann nach links und dann rechts..geht er bis 255 und springt
dann bei 256 auf 16384
127 = 00000000 01111111
128 = 00000000 10000000
32896 = 10000000 10000000
255 = 00000000 11111111
16384 = 01000000 00000000
bzw wozu gibt es eigentlich eine Hardware SPI Schnittstelle aber ständig
nutzt ein Hersteller doch wieder was spezielles so das die HArdware gar
nicht genutzt werden kann und doch alles zu Fuss erledigt werden muss?
Welchen Sinn hat das?
Einfach mal im Datenblatt runter scrollen bis Fig.6.1!
Ist eine simple SPI-Übertragung von 3 Byte (a 8 Bit), kein Bitbanging
etc.
1. Byte 0x01 senden (Startbit) ----- Wert im Empfangsregister verwerfen
2. Byte mit SGL/DIFF, D2, D1, D0 im oberen Nibble senden ---- Wert im
Empfangsregister enthält B9+B8 vom Ergebniss.
3. Byte 0x00 (oder sonst was) senden ---- Wert im Empfangsregister
enthält B7...B0 vom Ergebniss.
Und genau da verstehe ich offensichtlich was grundlegendes nicht.
Im Datenblatt ist immer von 3 Bytes die Rede..
Wenn ich doch aber mit SPI REad auslese, verschiebt er das Register doch
auch?!
Also
000000001 Senden = 8 Takte
110000000 Senden = 8 Takte
SPI_Read
unteres Byte = 8 Takte
oberes Byte = 8 takte
Damit habe ich doch schon 8 Takte mehr als im Datenblattbeispiel
angegeben?!
Und dabei habe ich nicht mal das dritte unbedeutende Byte gesendet?!
Wo ist hier mein Denkfehler?
Ich finde Chris B. (dekatz) hat es dir um 09:12 sehr gut erklärt.
Mir scheint du hast nicht verstanden dass zu jedem SPI Write
auch ein empfangenes Datum gehört. Du brauchst eine Funktion
die dir nach dem Schreiben auch das empfangene Byte (das immer
mit daherkommt, im SPI Leseregister) liefert.
Ich versuch es nochmal auf meine Art wie man das macht:
// 1. Schreib-/Lesevorgang, Ergebnis ignorieren
ergebnis = SPI Write (dein Kommando);
// 2. Schreib-/Lesevorgang, Ergebnis: 2 Bit Nutzdaten
ergebnis = SPI Write (dummy Wert);
// 3. Schreib-/Lesevorgang, Ergebnis: 8 Bit Nutzdaten
ergebnis = SPI Write (dummy Wert);
Kein Ahnung welchen Controller du verwendest und was deine SPI1_Write
und SPI1_Read machen.
Beim PIC mache ich es direkt über den SPI-Buffer:
SSP1BUF = 0b00000001; //1.Byte mit Startbit senden
while( !SSP1STATbits.BF ); //warte bis "receive complete"
dummy = SSP1BUF;
SSP1BUF = 0b11000000; //2.Byte mit Konfiguration senden
while( !SSP1STATbits.BF ); //warte bis "receive complete"
HighByte = SSP1BUF;
SSP1BUF = 0; //3.Byte ist ohne Bedeutung
while( !SSP1STATbits.BF ); //warte bis "receive complete"
LowByte = SSP1BUF;
nein eigentlich ist es viel eifnacher..ich habe die Lösung gerade
gefunden:-)
Ich hatte das mit dem Buffer nicht verstanden und du offenbar meinen
Beispielcode nicht;-)
CS:=0;
var3:=0;
SPI1_Write(%00000001); //Startbye senden
Highbyte := SPI1_Read(128); Highbyte lesen Eingang 1 daher
%10000000=128
Lowbyte := SPI1_Read(0); Lobyte lesen, egal welche Zahl im Buffer
steht
CS:=1;
Das ist des Rätzels Lösung.
ich hatte nicht verstanden das die Zahl inden Klammer gestendet wird,
wenn man mit SPI_read liest
@ Chris B. (dekatz)
danke, das haben wir jetzt zeitgleich geschrieben:-)
Aber ja, DU hast mein Problem verstanden und hättest es gelöst, danke
nochmals:-)
So ... jetzt hat er es mindestens dreimal erklärt bekommen,
jetzt sollte es doch klappen.
Wenn nicht, dann ist Hopfen und Malz verloren, wie der Bayer
(in diesem Fall ich) zu sagen pflegt ....
Panter Schmidt schrieb:> Ich hatte das mit dem Buffer nicht verstanden und du offenbar meinen> Beispielcode nicht;-)Panter Schmidt schrieb:> Lowbyte := SPI1_Read(0); Lobyte lesen, egal welche Zahl im Buffer> steht
Das kann man beim besten Willen nicht verstehen, weil du von einem
Buffer schreibst den keiner kennt.
Panter Schmidt schrieb:> ich hatte nicht verstanden das die Zahl inden Klammer gestendet wird,> wenn man mit SPI_read liest
Ja, das sind aber absolute Grundlagen, für die man schon mal aufs
Datenblatt des verwendeten Busses verweisen darf: ein SPI-Bus besteht
aus gekoppelten Schieberegistern. Für jedes Bit, das "gesendet" wird,
wird auch eines "empfangen".
Insofern ist ein SPI_Write() genauso unsinnig wie ein SPI_Read(). Denn
das, was da auf dem Bus passiert, ist immer ein SPI_WriteAndRead()
oder besser ein SPI_Transfer().
Panter Schmidt schrieb:> Und genau da verstehe ich offensichtlich was grundlegendes nicht.
Und genau dagegen haben Hersteller Datenblätter, Spezifikationen und
AppNotes geschrieben.
udn wenn man es als Anfänger nicht versteht hilft auch das Datenblatt
nicht...sonst würde hier nicht so oft gefragt.
Aber da du das anders siehst kann das Forum ja auch geschlossen werden,
steht ja schließlich alles in Datenblättern und den Rest kann man
ergooggeln..
Schräge Logik haben einige hier....
Peter Pander schrieb:> udn wenn man es als Anfänger nicht versteht hilft auch das Datenblatt> nicht...sonst würde hier nicht so oft gefragt.> Aber da du das anders siehst kann das Forum ja auch geschlossen werden,> steht ja schließlich alles in Datenblättern und den Rest kann man> ergooggeln..
Nicht so frustriert. Ich bin auch noch recht neu im Forum, habe aber
schon bemerkt, dass die Leute oft aneinander vorbeireden. Klar für die
alten Hasen sind bestimmte Begriffe so klar, dass die gar nicht auf die
Idee kommen, dass jemand die nicht genau so (richti) verstehen kann.
Aber auch ich erlebe immer wieder, dass die Fragenden oft das Datenblatt
entweder nicht richtig gelesen oder nicht verstanden haben.
Ich schreibe in solchen Fällen zum Beipiel auch schon mal: Im Datenblatt
steht unter "absolute Maximum....". Das heißt nur, dass dann das Bauteil
(noch) nicht gleich kaputt geht. Es sind aber nicht Betriebsbedingungen.
Die Spannung / der Strom für den normalen Betrieb steht ...... und muss
so verstanden werden, dass ..... Meist kommt dann noch etwas wie: Es
dürfen aber nicht alle Ausgänge gleichzeitig ..... , da sonst der
maximal zulässige Strom ..... überchritten wird. So versuche ich
zumindest einmal den Fall zu klären und gleichzeitig für künftige
Anwendungen aufzuzeigen, wie die Datenblattwerte zu interpretieren sind.
Das ist manchmal recht mühsam und klappt auch nicht immer. Aber ein
Forum kann nicht mehr leisten, da die "Berater" ja keine ausgebildeten
Pädagogen sind, sondern mehr oder minder einfache Leute, die das nötige
Wissen für die Beantwortung der Frage haben und sich bemühen, dieses
weiterzugeben.
Ich kenne inzwischen einige Foren. Dieses ist auf jeden Fall eines,
welche auf keinen Fall geschlossen werden sollte. Mehr Kompetenz,
Hilfsbereitschaft und manchmal auch Geduld habe ich woanders nicht
gefunden. (Auch wenn manchmal auch Leute dumme Sprüche machen, die auch
mich stören. Aber die kann man ja getrost ignorieren.)
Thread beobachten
Seitenaufteilung abschalten