Hi, Reicht für SSI/BiSS-C ein SPI im Half-Duplex Slave Mode oder sollte man eher mit einem UART gehen? BiSS-C würde ja auch Full-Duplex unterstützen, für meine Applikation ist das aber egal. Gerade bei BiSS-C werden ja bis zu einem Ack die ersten CLK Pulse verworfen, von daher wie kann man da die Daten Synchronisieren? Grüsse
Bert S. schrieb: > von daher wie kann man da die Daten Synchronisieren? Vorschlag: Du schaltest einen extra Takt z.B. mit einem PWM-Pin ein und lässt den UART asynchron empfangen. Vor Einschalten den Timer Nullen, um Takt-glitches zu vermeiden. Mit Einschalten des Taktes wird der Winkel gesampelt? mfg mf
Gast
#6801415
Synchrone Slaves(SSI/BISS)mit einer asynchronen Schnittstelle im Master (UART) auszulesen, sorry das ist doch Murks! Noch schlechter finde ich nur noch den Vorschlag einen anderen Perepherieteil wie eine PWM dazu zu missbrauchen. Nimm doch einfach eine synchrone Schnittstelle wie eine SPI (geht evtl nicht mit jedem Slave. Manche haben eine blöde Anzahl an Datenbits und nehmen es einem krumm wenn die Anzahl nicht stimmt). Selbst Bit Banding geht bei den meisten Slaves und würde ich noch bevorzugen wenn es mit SPI nicht geht.
Gast
#6801433
Ok, nun ist es aber ja bei BiSS-C etwas komplizierter als bei SSI, da die Daten verzögert werden können und man so irgendwie auf ein Ack warten muss. Nun habe ich mir mal die Implementation von TI angesehen, die scheinen die SPI clock zurückzuspeisen und die Pulse zu zählen und dann einen Interrupt zu generieren sobald der DIN auf High geht. Allgemein scheint BiSS-C sehr CPU lastig zu sein, wenn es nicht auf einem FPGA läuft. Gibt es da keine einfachere Möglichkeit? Am besten wäre eigentlich ein Interface wie SSI, wo eine CRC besitzt und nicht irgendwie auf 25 CLK Zyklen wartet. Z.B 14bit position, 8bit CRC, 1bit Status und 1bit Trash
MaNi schrieb: > Synchrone Slaves(SSI/BISS)mit einer asynchronen Schnittstelle im Master > (UART) auszulesen, sorry das ist doch Murks! Eine unbekannte vielleicht schwankende Anzahl führender Clocks zu ignorieren, ist Murks. Ich weiß jedenfalls nicht, wie schnell der Takt und wie lang die Leitung vom Bert ist. mfg mf
Ich habe bisher BISS-C genutzt, indem der SPI einfach per DMA im Hintergrund eine mindestanzahl an Bits gesamplet hat. Die Startbitdetektion wurde durch Zählen der leading zeros (gibt eine Instruktion) und shiften um so viele Nullen umgesetzt; das war relativ Laufzeiteffizient. Die Samplezeit des Winkels wird ja durch die erste Taktflanke festgelegt; Nacheinem Timeout auf dem Bus setzt sich der Sensor auch zurück, falls noch zu viele Takte kamen und wartet dann wieder auf eine neue Taktflanke.
Danke, dass mit dem DMA und leading zero detection klingt genau nach der Art von Effizienz die ich gesucht habe.
Leon L. schrieb: > Ich habe bisher BISS-C genutzt, indem der SPI einfach per DMA im > Hintergrund eine mindestanzahl an Bits gesamplet hat. Da werden die Bits synchron zum Takt gesampled... Da muss aber gesichert sein, dass die Durchlaufzeit eines Taktes durch den Encoder plus zweimal Verzögerung durch die Leitung (Takt hin, Daten zurück) kleiner als eine halbe Taktperiode sind. Wie bei SPI eben, oder sehe ich das falsch? mfg mf
Solange die "Datenflanke" nicht durch Zufälle genau auf den Punkt des Samplings fällt (durch Verzögerung), sollte diese Kompensation ja auch durch die Leading-Zero-Detection machbar sein. Ansonsten könnte ein USART mit oversampling ja auch "Zufälle" kompensieren.