24c512 nombre d'octets

[invitefd277a6e]

salut a tous , voici une petite question a propos de l'eeprom 24c512.

si j'ai bien compris le datasheet , elle a 512 Kbit soit 64 Ko
pour moi un octet c'est 0xa2 ou 21 ou un nombre jusque 0xFF , c'est bien ca ?

64 Ko ça nous fait 65535 cases.
pour mon programme je garde 200 a 500 cases,il me reste en gros 65000 cases .

je veut enregistrer des donnee de temperature a la raison de 1 par heure
donc 65000 / 24h = 2708 jours
2708 / 31j = 87 mois
87 / 12m = 7 ans

dites moi que je me trompe !! sur cette memoire je peut enregistrer jusque 7 ans de donnée a raison de 1 donnee par heure ?

merci pour vos infos et calculs.
-----

[invite5637435c]

si j'ai bien compris le datasheet , elle a 512 Kbit soit 64 Ko
pour moi un octet c'est 0xa2 ou 21 ou un nombre jusque 0xFF , c'est bien ca ?

Oui c'est bien ça.
Un octet c'est 8 bits, 8 bits permettent de coder 256 valeurs (0 à 255)

64 Ko ça nous fait 65535 cases.
pour mon programme je garde 200 a 500 cases,il me reste en gros 65000 cases .

non ça fait 64ko soit 64k*[8bits] soit 64k de cases de 8 bits.

je veut enregistrer des donnee de temperature a la raison de 1 par heure
donc 65000 / 24h = 2708 jours
2708 / 31j = 87 mois
87 / 12m = 7 ans

dites moi que je me trompe !! sur cette memoire je peut enregistrer jusque 7 ans de donnée a raison de 1 donnee par heure ?

merci pour vos infos et calculs.

Oui tu te trompe même si le résultat est proche
pour stocker sur 7 ans il te faudra:
24*31*12*7=62496 octets

La mémoire sera remplie avec:

64k-62496=1504

1504/24=62j soit 7 ans et 2 mois.

@+

[jiherve]

Bonsoir,
24C512 = 524288 bits = 65536 octets .
JR

[invite5637435c]

Le fameux débat ko...

http://physics.nist.gov./cuu/Units/binary.html

Il n'y a que les informaticiens pour se faire des noeuds au cerveau comme ça

[A voir en vidéo sur Futura]

[abracadabra75]

salut a tous , voici une petite question a propos de l'eeprom 24c512.
.....64 Ko ça nous fait 65535 cases.

Bonjour.
Non, ça fait 65536 cases.
65535 est l'adresse de la dernière case, celle de la première étant 0.
A+

[jiherve]

bonjour,
il n'y a pas de débat lorsque l'on cause de composants mémoire physiques , l'adressage c'est un certains nombre de fils d'adresses et donc la capacité est toujours une puissance de 2, en fait sur les grosses mémoires la capacité réelle est supérieure à cette puissance brute car il y a l’équivalent d'une MMU qui permet la réparation des zones défectueuses (FLASH et moins connu DDR)mais c'est transparent pour l'utilisateur.
JR

[invite5637435c]

Si si il y a débat.

Le problème n'est pas tant la capacité physique, là tout le monde est bien d'accord que 2^10=1024 MAIS tout dépend ensuite du système d'exploitation qui va gérer les datas stockées.

Par exemple windows utilisent le ko, Mo, etc donc ça a des conséquences puisque pour eux 1ko=1000 octets.

Il est normal qu'un kilo fasse 1000.

[invite5637435c]

Je ne te dis pas que j'ai raison juste que ça a suffisamment semé le trouble cette histoire d'écriture.
Honnêtement aujourd'hui je ne sais même pas où ça en est.

Si quelqu'un a des infos ça m'intéresse.

[invite0bbe92c0]

Si si il y a débat.

Le problème n'est pas tant la capacité physique, là tout le monde est bien d'accord que 2^10=1024 MAIS tout dépend ensuite du système d'exploitation qui va gérer les datas stockées.

Et bien, sur on aurait créé des systèmes qui introduiraient des paddings non alignés pour compliquer tout sans aucun bénéfice ?

Par exemple windows utilisent le ko, Mo, etc donc ça a des conséquences puisque pour eux 1ko=1000 octets.

Et pourquoi une telle complication, empêchant l'alignement aux frontières physiques aurait elle été introduite ?
Tu as une source à l'appui de ton affirmation ?

[invite5637435c]

Le bénéfice n'a rien à voir là dedans.

En général quand je dis quelque chose ce n'est pas dans le vent.

lis ça par exemple:
http://physics.nist.gov./cuu/Units/binary.html
http://www.maje.biz/ko-ou-kio-go-ou-gio/

Parler de "kilo" équivalent à 1024 est une connerie, c'est introduire une confusion entre système décimal et binaire, il fallait donc changer ça.

[jiherve]

re
ben moi, lorsque dans ma vie antérieure, je concevais un contrôleur DDR il adressait bien la totalité de la mémoire et donc même si l'on écrivait à tord(si l'on tient compte des recommandations du NIST) que la mémoire faisait 1GO on accédait bien à 1073741824 octets et le client n'avait aucun doute. Pour les disques durs mécaniques c'est en effet différent car il n'y a pas de correspondance stricte entre le medium et un adressage binaire, pour un SSD il ne devrait pas y avoir non plus confusion puisque le support est un ensemble de mémoires Flash sauf bien sur si le constructeur se met sous le coude quelques MO pour assurer la longévité de son produit en permettant le remapage des zones défectueuses.
En fait cette confusion est plutôt à rechercher coté marketing, pour les professionnels de la profession il n'y a jamais eu de soucis
JR

[invite5637435c]

Je suis d'accord avec toi.

C'est plus un soucis de norme d'écriture.

Si on reprend l'exemple du posteur d'origine:

64 Ko ça nous fait 65535 cases.

Est faux (au sens de la norme et à 1 case près)

Il aurait fallu écrire:

64kio nous font 65536 cases.

Du coup cela donne un stockage possible de

65536/(24*31*12)=7.34 années soit 7 ans 4 mois et 2h

Sauf erreur de ma part.

[invitefd277a6e]

merci a tous pour vos lumières et l'intensité du débat que j'ai provoqué,

oui c'est bien l'adresse de la dernière case que j'ai donné et pas le nombre en effet.
Au départ c’était juste pour me rendre compte qu'en fait pour mon application cette mémoire est largement suffisante pour enregistrer mes données,

je voulais enregistrer donc ces températures sur une semaine , je me suis dit que ça ne tiendrai pas , mais quand je me suis engagé dans ces calculs et que je suis arrivé a 7 ans j'ai douté un peu.


en tout cas merci a tous.

[invite0bbe92c0]

je voulais enregistrer donc ces températures sur une semaine , je me suis dit que ça ne tiendrai pas , mais quand je me suis engagé dans ces calculs et que je suis arrivé a 7 ans j'ai douté un peu.

Le problème que je vois avec votre stockage séquentiel non horodaté explicitement c'est que en cas de panne, arrêt, etc .... vous ne pouvez plus horodater vos données; partant de là économiser quelques ko me semble un choix curieux.

Donc comme vous êtes large, rajoutez un horodatage.

[abracadabra75]

je voulais enregistrer donc ces températures sur une semaine , je me suis dit que ça ne tiendrai pas , mais quand je me suis engagé dans ces calculs et que je suis arrivé a 7 ans j'ai douté un peu.

Ceci est vrai à condition que ta donnée tienne sur 1 octet.
Si tu dois y rajouter antre chose, telle une date, le calcul est à refaire.