ich sammle Daten ueber die von Euch verwendeten Logger, und zwar ueber die in diesen verwendeten Flash Speicher. Ich weiss nur, wie man die Informationen ueber die BT747 Software bekommt. Bei anderen Programmen als Logger-Front-End kann ich nicht sagen, ob, und wenn ja, wie man diese Infos bekommt.
Mit der Software BT747 findet man die benoetigten Angaben auf der ersten Seite unter Flash Info. Mich interessiert der Hexcode, nicht, was dahinter steht! (Der Hexcode kommt direkt vom Speicher, das dahinter ist schon eine Uebersetzung von BT747)
Bei mir wird z.B. als Flash Info angegeben: 1C20161C (EON, 4MB). Ich brauche den Code (JEDEC ID), hier 1C20161C.
Genauer ist die JEDEC ID nur 1C2016 (1C = Hersteller → EON; 2016 = Speichermodell → EN25P32). BT747 wiederholt diese Angabe von vorne, um auf 4 Byte zu kommen… Sind erstes und letztes Byte der 4-Byte-Sequenz allerdings voneinander verschieden, so interessert mich das besonders (nach meinem aktuellen Kenntnisstand sollte es das nicht geben… oder doch?)
Es kann also sein, das andere Software nur drei Bytes anzeigt.
Ich wuerde mich ueber viele Rueckmeldungen sehr freuen und bedanke mich schon mal im Voraus! :-)))))
Zum einen moechte gerne ich wissen, ob die durch das Logger-API definierte logische Einteilung des Speichers der physikalischen Einteilung des Speichers entspricht, und zum anderen moechte ich wissen, ob mein aktuelles Verstaendnis der ID korrekt ist. Ersteres wuerde z.B. die verwendeten Speichermodelle einschraenken. Beides sollte sich anhand der Rueckmeldungen ueberpruefen lassen.
Ich verwende den Wintec WBT 201, leider lässt sich über die Software “TimeMaschineX” nichts dergleichen auslesen und andere Quellen die das hergeben hab ich bisher nicht endeckt.
Georg
Das MTK-API teilt den Speicher logisch in Sektoren der Groesse 64K-Byte – zumindest soweit mir bekannt ist. Jetzt waere die Frage, ob das auch fuer den i-blue 747A+ gilt… Wenn ja, hat die Groesse der logischen und physischen Sektoren nichts miteinander gemein.
Andererseits kann das MTK-API die kaputten Sektoren verwalten und hat dazu 32 Byte = 256 Bits zur Verfuegung. Damit koennen aber nur 256 Sektoren verwaltet werden. Laut Dokumentation bis zu 16M-Byte. Die Dokumentation geht also auch hier von 64K-Byte grossen Sektoren aus. Das passt irgendwie nicht zu den 1024 physischen Sektoren des 1C3116…
Vielleicht ist fuer das MTK-API aber auch ein logischer Sektor ein Block. Beide Speichermodelle haben naemlich Blockgroessen von 64K-Byte… Kann mir das vielleicht jemand erklaeren?
Der Speicher ist in 512 physischen Sektoren a 4K-Byte bzw. 32 Blocks a 64K-Byte organisiert. (Er hat also eine Groesse von 2M-Byte.) Auch hier entspricht die Blockgroesse der Groesse des logischen Sektors des MTK-API – nicht die Groesse des physischen Sektors,
