Hallo, ich programmiere gerade den MCP3008 und habe eine Anleitung, in der auch der Zusammenhang über das Datenblatt hergestellt wurde. (siehe Bild) Ich verstehe nun aber nicht wie er von seinem Text (welchen ich verstehe) auf den Befehl spi.xfer([0x01, 0x80,0x00]) kommt. Was der Befehl macht verstehe ich, wie er auf die Hexzahlen kommt jedoch nicht. Und im Programm selbst benutzt er plötzlich :antwort = spi.xfer([1,128,0]) Wie kommen denn diese Zahlen zustande? Hoffe jemand kann mir von meinem Schlauch runterhelfen Grüße Chris
Chris schrieb: > spi.xfer([0x01, 0x80,0x00]) Chris schrieb: > spi.xfer([1,128,0]) Ich habe mir jetzt nicht die Bits angeschaut und was die machen, aber vielleicht hilft dir: Dezimal = Hexadezimal 1 = 0x01 128 = 0x80 0 = 0x00 d.h.: die beiden Zeilen sind funtionell identisch, benutzen nur eine andere Zahlendarstellung. Die HEX-Darstellung hat den Vorteil, dass man die einzelnen Bits besser sehen kann.
Danke! Das habe ich eben auch herausgefunden und ist nun klar, aber wie kommt er nun von den Bits auf die Hex-Zahlen? Das ist noch der springende Punkt der nicht in den Schädel will.
Chris schrieb: > Danke! > Das habe ich eben auch herausgefunden und ist nun klar, > > aber wie kommt er nun von den Bits auf die Hex-Zahlen? Das ist noch der > springende Punkt der nicht in den Schädel will. Hier stehts: https://de.wikipedia.org/wiki/Stellenwertsystem
Hallo,
> Wie kommen denn diese Zahlen zustande?
Ich verstehe es so:
Schritt 1.Startbit senden -> 1
Schritt 2.1 single-ended- oder differential-Bit senden -> 1
Schritt 2.2 Kanal wählen -> 000
Schritt 2.3 Byte mit "don´t care"-Bits, hier 0000 auffüllen
Schritt 3.Dummybyte senden -> 0
Das ergibt die Bitfolge:
für Schritt 1: 0b1 = 1(dez) = 0x1
für Schritt 2.1 bis 2.3: 0b10000000 = 128(dez) = 0x80
für Schritt 3: 0b0 = 0(dez) = 0x0
rhf
Super das hat mir enorm geholfen! Danke! Ich habe jetzt noch einen ADC hier rumfliegen mit dem angehängten Datenblatt. Dann wäre zum Auslesen von Channel 0 folgender Befehl richtig? Schritt 1: Auto -1 Programm -> 0b1000 Schritt 2: Kanäle wählen -> Ch0 : 0b0000 0000 0000 0001 Schritt 3: Dummybyte senden -> 0 Bitfolge: Variante 1: für Schritt 1: 0b1000 = 8(dez) für Schritt 2 : 0b0000 0000 0000 0001 = 1(dez) für Schritt 3: 0b0 = 0(dez) oder muss man die 2 Bytes aufteilen? Variante 2: Für Schritt 1: 0b1000 = 8(dez) Für Schritt 2: 0b0000 0000 = 0(dez) Für Schritt 2(f.): 0b0000 0001 = 1(dez) Für Schritt 3: 0b0000 = 0(dez) Ist der Dummybyte überhaupt notwendig? Im Datenblatt steht es wäre mit 2 Frames erledigt. Der Befehl für Variante 1 wäre dann spi.xfer([8,1,0]) oder wie im Datenblatt mit nur 2 Frames beschrieben einfach spi.xfer([8,1)]? Habe ich das so richtig verstanden?
Hallo, Chris schrieb: > Dann wäre zum Auslesen von Channel 0 folgender Befehl richtig?... Keine Ahnung, ich kenne den Baustein nicht, was ich geschrieben habe basiert auf deinen Angaben, probier es einfach aus. rhf
Ich verstehe das so, dass das zweite (unbekannte) Device zwei 16Bit-Werte haben möchte. Frame 1: 0x8nmm Frame 2: 0xyyzz Startbit und Dummybyte sind wohl notwendig, damit die Funktion spi.xfer das Richtige macht. Da muss man in der Dokumentation nachschauen, welche Parameter notwendig und zulässig sind. Es könnte also sein: 1. es geht gar nicht mit spi.xfer, weil sie nur ein Byte senden kann, dein Device aber 16-Bit-Frames haben möchte. 2. spi.xfer kann auch mit 16-Bit-Worten umgehen, dann dürfte es so aussehen: a) spi.xfer(1, 0x8nmm, 0) und b) spi.xfer(1, 0xyyzz, 0), also zwei Aufrufe. 3. spi.xfer kann mehrere 8-Bit Datenbytes verarbeiten: spi.xfer (1, 0x8n, 0xmm, 0xyy, 0xzz, 0) 4. vielleicht auch mehrere 16-Bit Worte, dann ev. so: spi.xfer (1, 0x8nmm, 0xyyzz, 0). Wie gesagt, das sollte aus der Dokumentation von spi.xfer hervorgehen.
Danke für eure Mithilfe! SpiDev kann wie ich jetzt wohl gelesen habe beliebig viele einzelne Bytes schicken. Die Methode wartet auf eine Liste. Von einer Beschränkung habe ich nirgends was gelesen. @Hilde wie kommst du denn auf 0x8nmm und 0xyyzz? Sollen das Platzhalter sein? Sorry für die Newbiefrage aber Bits sind Neuland für mich
Chris schrieb: > Sollen das Platzhalter sein? Sorry für die Newbiefrage aber Bits sind > Neuland für mich 1. HildeK! 2. Ja, das sind Platzhalter. Ich kann dir ja keine festen Werte geben, wenn die von deinen mir unbekannte Wünschen abhängig sind. Ich habe für jedes Byte eigene Buchstaben genommen. Die 0x8 waren ja gegeben für Frame 1 und der Rest davon ist beliebig. In Frame 2 erfolgt dann die Auswahl der verwendeten Kanäle. Welcher geheime IC ist den das? Ob die 0 am Ende und/oder die 1 am Anfang von spi.xfer immer notwendig ist oder nur beim MPC3008 weiß ich allerdings nicht. Es könnte sein, dass damit das CS gesteuert wird. Deshalb muss meine Aufzählung nicht unbedingt richtig sein. Wie gesagt: Doku zu spi.xfer sollte es wissen. Ich kenne sie nicht. Chris schrieb: > SpiDev kann wie ich jetzt wohl gelesen habe beliebig viele einzelne > Bytes schicken. Also, alle Infos in Bytes aufteilen, klären ob die 1 am Anfang und die 0 am Ende erforderlich sind und dann die Liste von Bytes schicken. Für die Selektion von Ch1 also spi.xfer ([1, 0x80, 0x00, 0x00, 0x01, 0]) oder ohne Anfang und Ende spi.xfer ([0x80, 0x00, 0x00, 0x01]) Wenn man die Frames getrennt schicken muss, dann halt zwei Befehle draus machen: spi.xfer ([?, 0x80, 0x00, ?]) bzw. spi.xfer ([0x80, 0x00]) spi.xfer ([?, 0x00, 0x01, ?]) bzw. spi.xfer ([0x00, 0x01])
Vielen Dank für deine Hilfe HildeK :-) Der IC ist der ADS7961SDBT von TI. Nichts geheimes. Ich werde es morgen Abend mal testen und werde berichten.
Kurzes Feedback. Der ADC läuft. Muss nur noch die Werte in Spannungen umrechnen. Da die beiden ersten Bits des Antwortbytes sich erhöhen, wenn ich den angeschlossenen TempSensor anföhne, sollte das Ding ja funktionieren :) Vielen Dank für die Hilfe!
Bitte 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.