SOMMAIRE

 

1) GENERALITES 
1.1) Principe du projet
1.2) Caractéristiques
1.3) Ma vision du projet

2) HARDWARE
2.1) Carte de développement
2.2) Verilog, schéma global
2.3) Verilog, coeur CPU
2.4) Verilog, Vidéo VGA
2.5) Verilog, périphériques

3) OUTILS DEVELOPPEMENT SOFTWARE
3.1) Généralités
3.2) Langage A2Z Basic
3.3) Compilateur
3.4) Assembleur
3.5) Autres outils
3.6) Emulateur sur PC

4) LES LOGICIELS A2Z
4.1) Le Boot
4.2) Système fichier & OS
4.3) Editeur texte
4.4) Image viewer & map viewer
4.5) Le jeu : Micromachines

Blog (hackaday.io)

4.1) Le Boot

Le bootloader est présent dans une ROM interne au FPGA de 2ko. 2ko, c’est tout juste suffisant pour faire rentrer tout ça.
Le code est directement exécuté depuis cette Boot-ROM.
Ce bootloader peut au choix :

  • Charger du contenu via le port série vers la SRAM et l’exécuter. C’est utile quand on développe des programmes (fraichement compilés sur le PC), pour les exécuter directement sans passer par la Flash. C’était aussi indispensable tant que je n’avais pas codé l’interface Flash et l’OS.Le port série doit être configuré à 57600 bauds, sans aucun handshake/flow-control, et si possible avec 2 bits de stops au lieu d’1. Attention, les fichiers envoyés via le port série doivent être envoyés bruts, en format binaire, surtout pas en ASCII.Sous Windows, j’utilise le logiciel de terminal TeraTerm.
  • Charger l’OS depuis la mémoire Flash vers la SRAM et l’exécuter. C’est l’utilisation « normale » de ce boot. L’OS est un exécutable de 64ko, placé à un emplacement connu de la Flash.  

Remarque : le bootloader n’est pas émulé dans l’émulateur. L’équivalent du bootloader côté émulateur est directement codé en C, et prend les mêmes fichiers que ceux envoyés par le port série.

Le protocole de bootloader :
Le protocole de téléchargement depuis le PC vers A2Z, via le port série, est le même pour le bootloader, et pour l’OS. Le protocole est très simple et mono-directionnel. Je n’ai même pas câblé ou codé la partie TX du port série de A2Z !
Il n’y a pas d’acquittement, pas de demande de répétition, ou de contrôle de flux de la part du récepteur (A2Z). 


Ce protocole ne permet que 2 choses :

  • Télécharger un bloc de données vers une plage RAM spécifiée. De base, j’utilise des blocs de 256 octets.
  • Faire un goto : modifier le program counter pour reprendre l’exécution à partir du programme qui vient d’être chargé.

Il y a un mécanisme de « checksum » dans les 2 cas, pour vérifier l’absence de corruption de données.
Les fichiers produits par « bin generator » (.bina ou .bine) contiennent directement ces instructions bootloader, et pas seulement les données à télécharger. Il suffit alors de les envoyer directement en brut (format binaire) via le port série.
Attention, les fichiers .bine / .bina / .binc ne sont donc pas des fichiers binaires bruts.


F4HDK| Janvier 2017
f4hdk_arob_free.fr