Exportation nostub dans MakePrgm incorrecte - Page 3

Godzil (./47) :
La memoire flahs utilisé dans les TI 68k est de la NOR, il faut compter quelques milliers d'effacement, pas bien plus. Pas des centaines de milliers ça c'est sur.

Mmh, apparemment la puce utilisée (pour les 89 du moins) est soit une LH28F160 soit une LH28F320, et la datasheet dit 100 000 cycles mini.

Par ailleurs j'ai jamais entendu dire que les NOR étaient moins endurantes que les NAND pour le nombre de cycles de réécritures, tu as une source ?

c'est même plutot l'inverse, les NAND c'est 10k cycles et les NOR 100k, je l'ai appris du temps où je suivais les mailing list openmoko.

Non plus, on trouve des NAND qui tapent dans le million de cycles, il y en a dans les clés USB par exemple.

ah. bon, ok.

33-kernel::LibsPtr	(Preos only)

	Input:
		a0.l -> Lib descriptor
		d0.w = Number of the function
	Output:
		a0.l = Pointer to the function or NULL
	Destroy:
		a0

	It gives a pointer to the required function of the library.

Là ya un vrai problème, d0 est détruit... Adress error à cause de ça dans mon programme (corrigé évidemment, mais bon ce fût la surprise ^^)

LibsPtr commence et finit par un movem.l d1-d2,-(sp)/(sp)+. Il est utilisé à deux autres endroits de sld (et dans aucun autre fichier). Chaque fois, d0 est écrasé immédiatement pour tester le résultat (move.l a0,d0). Il n'y a donc pas de problème pour faire un movem.l d0-d2.

ou alors changer la doc et dire que d0 est détruit

Oui, solution de loin la plus simple. Mais la modification du code me ferait gagner largement deux bons octets

Tu as arrété le C++ à ce que je vois ;o

Je peux pas être sur tous les fronts à la fois, et je suis reviendu à fond dans mon assembleur, PedroM, toussa. Ca me manquait trop

Zerosquare (./61) :

Godzil (./47) :
La memoire flahs utilisé dans les TI 68k est de la NOR, il faut compter quelques milliers d'effacement, pas bien plus. Pas des centaines de milliers ça c'est sur.

Mmh, apparemment la puce utilisée (pour les 89 du moins) est soit une LH28F160 soit une LH28F320, et la datasheet dit 100 000 cycles mini.

Par ailleurs j'ai jamais entendu dire que les NOR étaient moins endurantes que les NAND pour le nombre de cycles de réécritures, tu as une source ?

Me suis planté de un 0. c'est ~100 000 pour la NOR en effet, par contre la NAND, je suis pas du tout d'accord, c'est entre 10.000 et 100.000 pour de la NAND SLC, et largement moins de 10.000 pour de la MLC. Et encore, la NAND est moins testé que la NOR, donc seul les premiers secteurs voir que le secteur 0 sont garantit au nombre d'effacement sans apparition d'erreurs sur les bits.

Ce qui "allonge" la durée de vie des clefs USB/Cartes mémoires (SD/MMC) c'est le controlleur intégré gerant le Wear Levelling et les bad blocs qui donne cette impression. (cf : http://fr.wikipedia.org/wiki/Mémoire_flash#Dur.C3.A9e_de_vie pour les durée de vie)

autre différence, tous les chips NOR fonctionnent à 100% mais les chips NAND ont des bad blocks, et la première chose que fait un bootloader basé sur de la NAND est de scanner le chip pour faire une liste des bad blocks et ne plus écrire dedans.

ce qui fait que tous les chips de NAND sont prévus avec plus de blocks que marqué sur l'emballage pour que ça revienne à normal après l'éjection des bad blocks.

et effectivement sans wear leveling on va pas très loin (cf smart media)

J'ai pas de source précise mais y'avait eu des threads la dessus sur les mailing list openmoko.

(ça vous dirait pas de forker pour vos nand ? c'est pas trop l'endroit quoi... ya info/hw pour ça )

C'est fait -> topics/129839-flash-nand-vs-flash-nor-nombre-decritures-maxi.

Écoute, j'utilise les bug trackers ou les formulaires de bug report quand il y en a, mais là, la méthode officielle est apparemment ce forum, étant donné que c'est ici qu'on trouve pas mal de bug reports pour les logiciels de PpHd.

Si ça ne convient pas à PpHd, c'est à lui de le dire, pas à vous!

Je suivrai toute consigne (raisonnable, évidemment – si c'est du genre aller consigner une clé USB en personne à PpHd, ça ne va pas aller évidemment ) indiquée par PpHd pour les bug reports.