SSI und BiSS-C --> Half-Dubplex SPI Slave Mode?

[Bert S. (kautschuck)]

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

[Achim M. (minifloat)]

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

[MaNi (Gast)]

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.

[Bert (Gast)]

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

[Achim M. (minifloat)]

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

[Leon L. (leonelf)]

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.

[Bert S. (kautschuck)]

Danke, dass mit dem DMA und leading zero detection klingt genau nach der 
Art von Effizienz die ich gesucht habe.

[Achim M. (minifloat)]

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

[Leon L. (leonelf)]

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.