Ich habe ein Register mit der Adresse 0x89, dies ist das einzige Register mit dieser Adresse. Der Bereich des Registers befindet sich bei Bit 0 bis Bit 5. Nun meine frage, kann es zu problemen führen wenn ich das Register fälschlicher weise mit 0xFF, anstelle von 0x3F, beschreibe? Wenn ja, was kann passieren?
Das steht normalerweise im Datenblatt. Oft wird es ignoriert, manchmal kann es aber auch schaden.
Tja hätte er statt oder zusätzliche zu diesem Bildchen das Datenblatt verlinkt, dann hätte er auch schon eine konkretere Antwort.
Ich habe nichts im Datenblatt gefunden, meine frage ist aber eher allegmein gemeint, was kann kaputt gehen und wieso? Datenblatt APDS-9500: https://docs.broadcom.com/doc/AV02-4584EN
Wenn im Datenblatt überhaupt nichts dazu steht, werden die Bits üblicherweise ignoriert. Allerdings fällt den Entwicklern manchmal ein, bei einer späteren Version dort noch weitere Bits zu belegen. Wenn Deine Software da unkontroliert reinschreibt, ist sie evtl. nicht kompatibel zu neueren Versionen der Hardware. Es ist daher Best Practice, Null reinzuschreiben (nichts reinschreiben geht ja nicht). Probewiese kannst du das Register ja mal lesen und schauen, was von den oberen Bits zurückkommt. Wenn es das ist, was du reingschrieben hast, ist zumindest ein Flop dahinter. Dann solltest du auf jeden Fall Null reinschreiben.
Ich finde die Memory Map von dem Ding irgendwie.... Nutzlos. Ich mein, ja, die Adressen stehen dort, aber 0 Aussagen darüber, was welche Werte bedeuten. Sehr merkwürdig.
Ich habe es ausprobiert und er gibt 0x3F zurück obschon ich 0xFF geschriben habe. Heisst das nun das der Sensor besser Konstruiehrt ist? @ Sebastian R. : Finde ich auch, stichwort: Selbst Herusfinden....
IIC S. schrieb: > Nun meine frage, kann es zu problemen führen wenn ich > das Register fälschlicher weise mit 0xFF, anstelle von 0x3F, beschreibe? > Wenn ja, was kann passieren? IIC S. schrieb: > Ich habe es ausprobiert und er gibt 0x3F zurück obschon ich 0xFF > geschriben habe Warum wollst du ueberhaupt 0xFF da schreiben wenn das nicht im Datasheet genennt wird ? Es kann sein das es jetzt funktioniert aber bei neue version der Sensor nicht mehr....
Wird ja über I2C angesprochen und meines Wissens sind das immer Bytes, die geschrieben oder gelesen werden. Das neunte ist ACK bzw. NACK. Viele ICs haben Register, die nicht vollständig belegt sind. Die nicht genutzten laufen intern einfach ins Leere. Vancouver schrieb: > Es ist daher Best Practice, Null > reinzuschreiben (nichts reinschreiben geht ja nicht). Ja. > Probewiese kannst du das Register ja mal lesen und schauen, was von den > oberen Bits zurückkommt. Wenn es das ist, was du reingschrieben hast, > ist zumindest ein Flop dahinter. Dann solltest du auf jeden Fall Null > reinschreiben. Selbst wenn keines da wäre: Es hindert den Hersteller nicht daran, in einer 'verbesserten' Revision ein 'Flop' einzubauen.
Ich schreibe meine Software schon so das ich nicht definierte Bits mit 0 beschreibe. Es nimmt mich nur wunder was im schlimmsten fall passieren kann wenn Bits beschriben werden die im Datenblatt nicht angegeben sind, bei diesem Sensor gibt es ja keine probleme, kennt jemand ein IC das anfällig auf solche sachen ist?
IIC S. schrieb: > kennt jemand ein IC das anfällig auf solche sachen ist? Ich hatte vor einiger Zeit ein Datenblatt von einem IC, in dem das Probleme geben konnte. Ich weiß aber nicht mehr, ob das nur ganze Register oder auch einzelne Bits in einem sonst nutzbaren Register war. Ich weiß auch absolut nicht mehr, welcher IC das war. IIC S. schrieb: > Es nimmt mich nur wunder was im schlimmsten fall passieren kann wenn > Bits beschriben werden die im Datenblatt nicht angegeben sind In meinem Fall war es, wenn ich mich richtig erinnere, irgendwas mit einem undokumentierten Testmodus. Wenn man das falsche reinschreibt, schaltet man den IC (auch nach Abschalten der Versorgungsspannung) in einen Testmodus, in dem er anders funtkioniert als normal. Da das nicht dokumentiert ist, kommt man da auch nicht mehr so leicht raus. Da ich aber nichts genaueres mehr weiß, bin ich nicht mehr sicher. Irgendwas in der Richtung war es.
IIC S. schrieb: > kennt jemand ein IC das > anfällig auf solche sachen ist? Wenn ich mich nicht irre NRF24L01+. Das ist eine neue version der NRF24L01. Software-kompatibel aber mit die (vorher nicht beschrieben 0-bits) kann die neue funktionalitaet aktiviert werden. Patrick aus die Niederlande
Beitrag #7054929 wurde von einem Moderator gelöscht.
Beschreib Register immer nur mit exakt den Werten die im Datenblatt angegeben sind! Ich hatte mal einen Controller, bei dem ich zu Debugzwecken einen GPIO-Port einfach hab hochzählen lassen. Bei bestimmten Werten hat sich der Controller dann einfach aufgehängt. Nach einer kurzen Unterhaltung mit dem Support des Herstellers hat sich rausgestellt, dass die auf die unbenutzten Pins in diesem Register irgendwelche Speicher-Enables gemappt haben. Ich hab dem Controller quasi seinen Speicher abgeschaltet. War natürlich nicht öffentlich so dokumentiert. Im Datenblatt steht nur, dass das Bit reserviert ist und immer mit 0 beschrieben werden soll. Also halt dich besser generell an die Vorgaben, du weißt nie welche Effekte du sonst auslöst.
Wenn du nicht sicherstellen kannst nur die offiziellen Bits zu ändern, dann maskiere den Schreibvorgang ins Register.
Vielen dank für die ausführlichen Erfahrungsberichte!
Hermann K. schrieb: > Nach > einer kurzen Unterhaltung mit dem Support des Herstellers hat sich > rausgestellt, dass die auf die unbenutzten Pins in diesem Register > irgendwelche Speicher-Enables gemappt haben. Ich hab dem Controller > quasi seinen Speicher abgeschaltet. War natürlich nicht öffentlich so > dokumentiert. Das sind mir die Liebsten... Ich arbeite selbst in der Ecke und natürlich sind in der Registerbank diverser Chips irgendwo "Eastereggs" versteckt für Testfunktionen oder ähnliches. Aber bei uns gilt der Grundsatz, dass ein "zu erwartendes" Verhalten implementiert werden muss bzw. sollte. Sprich: Ein GPIO Register wird nicht überbelegt mit irgendwelchem internen Testkrams. Keiner rechnet damit. Da kommt schön ein eigenes Register in den Adressraum, das dann eben nicht dokumentiert ist... Die paar Gatter im Adressdekoder bringen auch keinen um... Es kann natürlich immer sein, dass ein Feature im Silizium trotz Verifikation einfach nur kaputt ist und dann die entsprechenden Bits aus der Doku gelöscht werden. Aber per Design baut man keine Testfunktionen in ein Register, das einen ganz anderen Kontext hat. So einen Mist hatte ich auch schonmal auf dem Tisch. Da hat der Hersteller in irgendwelchen Registern seinen ATPG (automatic pattern generator) versteckt. Wenn man da rumgeschrieben hat, hat der dann angefangen die Scan-Ketten in der Logik zu aktivieren und schön automatisiert die Logik getoggelt. Das schöne daran war, das ging bis zum RAM Block durch, der dann durch das Pseudo-Random toggling immer an gewissen Adressen kaputtgeschrieben war.
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.