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
Und wo liegt jetzt genau das Problem? Statt der Beschreibung wäre es auch viel Zielführender ein Oszibild aufzunehmen und hier zu posten.
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
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?
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!
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
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.