Forum: Mikrocontroller und Digitale Elektronik Register mit mehr Bits beschreiben als im Datenblatt angegeben

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.

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.

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.

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.

Wenn du nicht sicherstellen kannst nur die offiziellen Bits zu ändern, 
dann maskiere den Schreibvorgang ins Register.

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.