Hallo.
Ich möchte an einen STM32F7 einen AD9826 anbinden. Der AD9826 verfügt
über ein serielles Interface für die Ansteuerung seiner Register.
Der AD9826 hat einen SDATA-Pin, der sowohl Ausgang(Read) als auch
Eingang(Write) sein kann. Zur Auswahl, ob gelesen oder geschrieben wird,
erwartet der AD9826 zuerst einen "4Bit-Header" mit der Info Read/Write
und der Registernummer. Danach schaltet der AD9826 offensichtlich seinen
SDATA entsprechend dieses Headers auf Input oder Output.
Ich hab jetzt schon einiges mit SPI gemacht. Aber dies kam mir noch
nicht unter. Kann man sowas per SPI im STM32 lösen oder muss ich dies
rein per Firmware lösen?
Vielen Dank schon mal.
Pepe.
Pepe schrieb:> Zur Auswahl, ob gelesen oder geschrieben wird,> erwartet der AD9826 zuerst einen "4Bit-Header" mit der Info Read/Write> und der Registernummer.
Mit 4 Bit wird er nicht zufrieden sein. Denn ich sehe im
Protokoll 8 (in Worten acht) Bits die gesendet werden.
Davon werden dann 4 Bits ausgewertet. Wenn du ihm nur 4 Bits
sendest steht seine Zustandsmaschine, solange nicht weitere
4 Bits kommen oder der CS inaktiv wird.
Die restlichen 3 Bits hab ich unterschlagen. (Wenn ich richtig gezählt
habe, sind es übrigens 7 Low-High-Flanken.)
Mir geht's aber auch um was anderes:
Je nach "Header" schaltet der AD9826 ja sein SDATA auf Output oder
Input. Somit muss ich den STM32 ja auch entsprechend konfigurieren. Z.B.
den MOSI deaktivieren beim Lesen der Register, damit ich mir den Ausgang
nicht brate.
Mich würde interessieren, ob man dies "automatisieren" kann oder nicht.
Oder vielleicht ist dies ja auch gar kein SPI, sondern WasAuchImmer...
Pepe schrieb:> Die restlichen 3 Bits hab ich unterschlagen. (Wenn ich richtig gezählt> habe, sind es übrigens 7 Low-High-Flanken.)
Das wäre die dümmste Implementierung ich ich je gesehen habe.
Das traue ich weder Analog Devices noch irgendeinem anderen
Chip Hersteller zu.
Zähle nochmals sorgfältig!
Vor allem will das Teil dann noch 9 Datenbits.
Echt nen komisches Protokoll, da bleibt wohl nurnoch Bitbanging als
Lösung.
Insgesamt sins aber wieder 16 Taktflanken, vllt gibts doch nen Trick?
Der SPI im STM32 kann übrigens:
"Simplex synchronous transfers on two lines with or without a
bidirectional data line"
Das wäre dann SPI mit einem bidirektionalen "SDATA", aber eben nur in
8Bit Blöcken umschaltbar.
Dazu angucken was die BIDIMODE und BIDIOE Bits machen.
Mw E. schrieb:> Vor allem will das Teil dann noch 9 Datenbits.> Echt nen komisches Protokoll, da bleibt wohl nurnoch Bitbanging als> Lösung.
Nö, das kann jede normale SPI Einheit als 2 Byte transferrieren. Muss
man beim Lesen dann hinterher halt zusammen fummeln oder beim Schreiben
vorher zurecht schieben.
Bei Schreiben seh' ich auch kein Thema. Die 16Bit raus und gut.
Nur beim Lesen bedeutet dies ja, dass ich zuerst 4 Bits (=Header) zur
Auswahl des Registers rausschicken muss, dann hab ich die 3 Bits Zeit,
um den STM32 auf "Read" umzustellen und dann kann ich die 9 Bits
einlesen.
Oder: Der STM32 hat ja noch einen 2. SPI. Dann könnte ich ja einen nur
zum Schreiben einsetzen und den anderen rein zum Lesen. Ich muss nur
sicherstellen, dass der "Schreibende" beim setzen der Registeradresse
nur die ersten 4 Bit schickt. Der Takt des schreibenden SPI wird dann
als Takt für den Lesenden verwendet.
Pepe schrieb:> Oder: Der STM32 hat ja noch einen 2. SPI. Dann könnte ich ja einen nur> zum Schreiben einsetzen und den anderen rein zum Lesen. Ich muss nur> sicherstellen, dass der "Schreibende" beim setzen der Registeradresse> nur die ersten 4 Bit schickt. Der Takt des schreibenden SPI wird dann> als Takt für den Lesenden verwendet.
Man kann sich auch einen Knopf ans Knie nageln oder schrauben ...
Viel Spaß dabei ;-)
A. B. schrieb:> Man kann sich auch einen Knopf ans Knie nageln oder schrauben ...> Viel Spaß dabei ;-)
Wahrscheinlich aber trotzdem einfacher, als das Ganze per Firmware
aufzubauen. Noch dazu möchte ich ja während der Kommunikation noch was
anderes tun...
Was haben die Leute nur früher gemacht als es noch keine SPI Einheiten
gab. Nimm 2 normale I/O Pins und 2 Schleifen Put und Get. Oder ist das
zu einfach ?
Stephan schrieb:> UART Funktionen
Würde sicherlich auch gehen. Aber mein Problem sind nicht die 9 Bits,
sondern der Header mit 4 Bits. Die ersten 4 Bits muss der STM32 immer
schreiben und dann Lesen oder Weiterschreiben.
Und beim Header kann ich im Datenblatt nicht raus finden, ab welchem
Clock die Datenleitung von Input auf Output umgeschalten wird. Um auf
Nummer Sicher zu gehen, würde ich meinen MOSI direkt nach dem 4 Bit
"rausnehmen" (wie ich dies auch immer lösen werde...)
Pepe schrieb:> Würde sicherlich auch gehen. Aber mein Problem sind nicht die 9 Bits,> sondern der Header mit 4 Bits. Die ersten 4 Bits muss der STM32 immer> schreiben und dann Lesen oder Weiterschreiben.
Irgendwie die Funktionsweise vom SPI nicht verstanden.
Auch zum Lesen "schiebt" man gleichzeitig Bits heraus.
> Und beim Header kann ich im Datenblatt nicht raus finden, ab welchem> Clock die Datenleitung von Input auf Output umgeschalten wird. Um auf
Irgendwo zwischen dem 4-ten und dem 7-tem. Wo genau, ist egal.
> Nummer Sicher zu gehen, würde ich meinen MOSI direkt nach dem 4 Bit> "rausnehmen" (wie ich dies auch immer lösen werde...)
So ein Unfug! Mal abgesehen davon, dass eine eventuelle Fehlfunktion der
Firmware, Glitch auf der Versorgung ...
Wie schon geschrieben, Widerstand zwischen MOSI und SDATA, MISO direkt
an SDATA, dann geht das Lesen und Schreiben mit Einstellung 16 Bit
problemlos.
Wenn der AD SDATA auf Ausgang schaltet, arbeiten dann zwar SDATA und
MOSI u. U. gegeneinander, aber der Widerstand begrenzt den Strom auf
sicheren Wert, und da MISO direkt am SDATA hängt, gewinnt der Pegel an
SDATA.
Und wenn das immer noch zu hoch sein sollte: So paar kümmerliche Bits
bekommt man wohl auch ohne irgendsoein Trallala per Bitbanging hin. Der
Widerstand zwischen SDATA und dem GPIO Pin ist aber auch dann eine
sinnvolle Sicherheitsmaßnahme.
