Forum TI-Planet.org

Code: Tout sélectionner

(gdb) x/32xb 0x90000000
0x90000000:   0xa9   0x03   0x00   0x20   0x00   0x00   0x10   0x00
0x90000008:   0x00   0x00   0x10   0x00   0x88   0x30   0x00   0x00
0x90000010:   0x00   0x00   0x10   0x00   0x21   0xbb   0xbb   0x20
0x90000018:   0xa3   0x13   0x81   0x12   0x00   0x00   0x00   0x00


Lionel Debroux a écrit:Lors de mon stage de fin d'études en binôme, il y a 10 ans maintenant, on avait implémenté (c'était une partie dont j'étais davantage en charge que mon binôme, mais je pense qu'on avait au moins discuté ensemble des couches du design) un framework + driver simple de gestion de mémoire Flash pour une carte Analog Devices basée sur un processeur/DSP Blackfin. On programmait en C++, en tirant partie seulement de l'héritage et de la composition. A l'époque, c'était mon premier vrai projet de C++, dans lequel je faisais autre chose que modifier le contenu de méthodes existantes.
J'avais aussi rédigé une documentation un peu générale sur la gestion d'une mémoire Flash (à l'époque, je crois que je n'étais pas conscient de la différence entre une Flash NOR, telle que celles de ces cartes Blackfin et celles des TI-68k que je connaissais, et une Flash NAND) et le design du framework; une des questions de la soutenance, posée par un des profs que nous avions invités, qui nous a malheureusement quittés quelques années plus tard, avait porté sur le design et la flexibilité - ciblage d'autres chips de Flash - de ce framework.

Bref - il y avait 3 couches permettant potentiellement le ciblage de plusieurs chips de Flash:
* la couche de plus bas niveau, qui s'occupait de réaliser les opérations unitaires spécifiques à ce chip de Flash, telles que décrites dans la datasheet. Il devait y avoir 2 ou 3 méthodes dans cette classe parce qu'on n'avait pas besoin de plus: essentiellement get status, single write, single block erase. Je ne sais plus si j'avais implémenté les queries CFI et les fast writes (ni si des commandes de ce type étaient gérées);
* la couche intermédiaire, qui implémentait notamment des opérations de block write en utilisant le single write en boucle (ou les fast writes s'ils étaient gérés), et de multiple block erase en utilisant le single block erase;
* la couche supérieure, qui fournissait des fonctions de plus haut niveau comme l'enregistrement d'un firmware, probablement une paire uint8_t * data + uint32_t length, dans le slot A ou le slot B qu'on avait définis en mémoire Flash, pour pouvoir garder le firmware de production et un firmware de backup.

D'une manière générale, la réalisation des opérations unitaires du chip consiste à envoyer, d'une façon ou d'une autre, des suites de commandes précises. Dans ce projet de stage de fin d'études, la Flash était directement mappée en mémoire (et ça serait pareil sur la NumWorks, sinon aucun intérêt de mettre de la Flash NOR), et il fallait envoyer des commandes à des adresses précises comme 0x554/0x555 ou 0x5554/0x5555, 0xAAA ou 0xAAAA, avant de cibler l'adresse qu'on veut écrire dans le cas du single write / effacer dans le cas du block erase. Les suites de commandes de ce chip sont d'autant plus longues et plus complexes qu'elles sont destructives, ce que j'avais attribué à la volonté de minimiser la probabilité que des commandes dangereuses soient déclenchées par hasard (crash de la machine).

Je n'ai jamais soudé du matériel au pas de 1.27mm, mais au-delà de ce que j'ai soudé en cours de techno comme la plupart des élèves, j'ai utilisé de nouveau des fers à souder lors du stage de fin d'études et dans mon précédent emploi; dans ce dernier, j'ai vu que les élèves qui ont soudé des choses au pas de 1.27mm étaient plus des informaticiens que des électroniciens.