SCA3000 unter BASCOM über SPI ansprechen

[S. G. (goeck)]

Hallo,

ich arbeite seit einiger Zeit mit dem SCA300-E05 und dem E04, habe ein
Programm in Bascom geschrieben, dass den Sensor abfragt und die Werte
über UART übermittelt. Jetzt sehe ich nicht hinten 3 Nullen, sondern 3 
Nullen + eine Stelle (springt zw. 0 und 1).
Weiterhin habe ich einen Bug, dass meine 13 Bit, die ich bekommen sollte 
an sich nur 12 Bit sind, denn das erste Bit fehlt einfach. Das habe ich 
ein paar mal überprüft.

Also meine ich, meine Bytes sind um eins nach links versetzt. Kann das
an einer Latenz bei der SPI Kommunikation liegen?

Ich bin für jede Eingebung dankbar, kann mir so langsam nicht merh
erklären, was ich noch anders machen könnt.
Achja, ich nutze SoftSPI, da ich mit HardSPI das Programm nicht 
kompilieren kann!!!

Grüße und vielen Dank

[Gast (Gast)]

Und wo liegt jetzt genau das Problem?
Statt der Beschreibung wäre es auch viel Zielführender ein Oszibild 
aufzunehmen und hier zu posten.

[S. G. (goeck)]

Ja interessante und vor allen Dingen ZIELFÜHRENDE Antwort..Danke

Das habe ich nunmal nicht vorliegen und wäre auch nicht weiter spannend, 
weil man eben dort einfach nur sieht, dass keine Kommunikation vor dem 
Chip Select (active low) stattfindet...
Fakt ist, dass mein erstes Bit verloren geht, oder gar nicht erst 
gesendet wird?!
Deswegen hatte ich ja die Vermutung in den Raum gestellt, dass durch die 
SOft SPI Implementation in BASCOM eine Latenz zustande kommt, die mein 
erstes Bit verloren gehen lässt. Also ungefähr so, als wenn der Sensor 
zu schnell anfängt zu senden, nachdem er die beiden Anforderungsbytes 
bekommt.

Grüße

[Gast (Gast)]

Also hast du jetzt ein Problem damit dass BASCOM das erste Bit 
(verschluckt) oder sind diese Bits schon auf der Datenleitung vom Sensor 
nicht vorhanden?

[S. G. (goeck)]

OK, gute Frage. Ich sehe vor dem "Chip Select auf GND Ziehen" kein Bit, 
allerdings wird CS auf GND gezogen, dann folgen zwei Byte an den Sensor, 
dann schickt der insgesamt vier zurück. Ich denke ich muss mir das 
Montag mal ausdrucken und mal inRuhe drüber schauen. Das hab ich bis 
jetzt ein paar wenige mal eher flüchtig mir angeschaut. Dann werde ich 
das auch hier gerne mal posten. Denn mir kommt grade in den Sinn:
wenn wirklich das erste Bit des ersten Bytes dieser 4 zurückgeschickten 
Bytes verschluckt wird, und zwei Bytes jeweils zu einem Short 
zusammengefasst werden, dann könnte ja dieses ominöse letzte Byte, was 
ja irgendwie zuviel ist und springt genau das erste Bit des 
nachlaufenden Bytes sein. Ich hab nämlich mal beobachtet, dass ich das 
beeinflussen kann..aber nicht wirklich deterministisch..naja alles 
komisch...Ich werde erst mal ein Oszibildchen besorgen, dann können wir 
aufhören zu spekulieren.

Merci!

[S. G. (goeck)]

Hi,

ich habe heute nochmal reingeschaut in die Abläufe. Also mir scheint es 
schleierhaft, was dort passiert. Bin ein wenig konfus.
IM oberen Abschnitt sieht man das Chip Select Signal (CSB) und MOSI (ein 
Byte wird gesendet [Lese Register Nummer x1]), dann bleibt der Takt 
anliegend und der Sensor shiftet 4 Bytes raus. X_highbyte,X_lowbyte, 
Z_highbyte,Z_lowbyte, dann folgen zwei einzelne Abfragen (ein byte 
senden, eins bekommen 1.y_highbyte 2. y_lowbyte).
Im mittleren Abschnitt sieht man CSB und MISO, also die Antowert vom 
Sensor.
Im unteren Abschnitt sieht man eine "Großaufnahme" von Miso und Mosi 
direkt bei dem allerersten gesendeten Byte von Mosi.

Ich kann mir die unsynchronen Zeitversätze nicht ganz erklären. 
Vielleicht liegt es daran.

Grüße
Göck