« SE4Binome2025-6 » : différence entre les versions
| (45 versions intermédiaires par 2 utilisateurs non affichées) | |||
| Ligne 71 : | Ligne 71 : | ||
La deuxième carte à réaliser est la carte mère avec une spécificité cependant, à savoir une puce STM32F410R8T6 en tant que microprocesseur. | La deuxième carte à réaliser est la carte mère avec une spécificité cependant, à savoir une puce STM32F410R8T6 en tant que microprocesseur. | ||
Remarque : M. Redon a également fait une carte mère mais | Remarque : M. Redon a également fait une carte mère mais basée sur un ATSAMD21G8A-A. Celle-ci pourra nous être utile si on rencontre des soucis pour le code avec notre stm32. | ||
=== Hardware === | === Hardware === | ||
| Ligne 220 : | Ligne 220 : | ||
# ordonnanceur.c : uniquement pour l'ordonnanceur, le main.c gère le reste, les différents fichiers et variables à inclure | # ordonnanceur.c : uniquement pour l'ordonnanceur, le main.c gère le reste, les différents fichiers et variables à inclure | ||
# ordonnanceur.h | # ordonnanceur.h | ||
# un makefile : pour compiler notre projet et les fichiers du firmware. On rajoute les chemins d'accès nécéssaires à la compilation du main.h qui a besoin du fichier stm32f410rx.h. On a également besoin du fichier core_cm4.h, d'où le second chemin : INCLUDES = -Istm32cubef4-v1-28-3/STM32Cube_FW_F4_V1.28.0/Drivers/CMSIS/Device/ST/STM32F4xx/Include \ -Istm32cubef4-v1-28-3/STM32Cube_FW_F4_V1.28.0/Drivers/CMSIS/Include | # un makefile : pour compiler notre projet et les fichiers du firmware. On compile avec arm-none-eabi-gcc. On rajoute les chemins d'accès nécéssaires à la compilation du main.h qui a besoin du fichier stm32f410rx.h. On a également besoin du fichier core_cm4.h, d'où le second chemin : INCLUDES = -Istm32cubef4-v1-28-3/STM32Cube_FW_F4_V1.28.0/Drivers/CMSIS/Device/ST/STM32F4xx/Include \ -Istm32cubef4-v1-28-3/STM32Cube_FW_F4_V1.28.0/Drivers/CMSIS/Include | ||
# un fichier nommé linker.ld : à la différence des atmega, notre microcontrôleur a une organisation mémoire plus complexe donc ce fichier nous permet de choisir où placer chaque type de données (cf les sections elf) dans la mémoire du microcontrôleur | # un fichier nommé linker.ld : à la différence des atmega, notre microcontrôleur a une organisation mémoire plus complexe donc ce fichier nous permet de choisir où placer chaque type de données (cf les sections elf) dans la mémoire du microcontrôleur. On y précise la taille de la flash : 128ko et la taille de la RAM : 32 ko ainsi que leurs adresses trouvées page 40/763 de la datasheet. On y initialise également les sections .text (le code), .data (variables initialisées) et .bss (variables non initialisées). | ||
# un fichier startup_stm32f410rx.s : un fichier assembleur qui gère les interruptions, les resets, l'initialisation des données que l'on copie colle depuis /stm32/stm32cubef4-v1-28-3/STM32Cube_FW_F4_V1.28.0/Drivers/CMSIS/Device/ST/STM32F4xx/Source/Templates/gcc | # un fichier startup_stm32f410rx.s : un fichier assembleur qui gère les interruptions, les resets, l'initialisation des données que l'on copie colle depuis /stm32/stm32cubef4-v1-28-3/STM32Cube_FW_F4_V1.28.0/Drivers/CMSIS/Device/ST/STM32F4xx/Source/Templates/gcc. Remarque sur ce qu'est thumb : sur notre stm32, on utilise ARM et thumb 2 dont le rôle est d'avoir un code plus compact en mélangeant des instructions à la fois de 16 et 32 bits. | ||
<p style="clear: both;" /><p style="clear: both;" />Remarque : commande à taper quand la carte "fail to connect" : <syntaxhighlight lang="c"> | |||
st-flash --connect-under-reset erase | |||
</syntaxhighlight> | |||
====== Ordonnanceur ====== | ====== Ordonnanceur ====== | ||
Il faut également faire l'ordonnanceur que l'on doit maintenant adapter non plus au shield et aux avr mais à la carte mère et aux arm. | Il faut également faire l'ordonnanceur que l'on doit maintenant adapter non plus au shield et aux avr mais à la carte mère et aux arm. | ||
* ordonnanceur.h : | |||
On y ajoute les librairies et la liste des fonctions implémentées dans ordonnanceur.c | |||
* ordonnanceur.c : | |||
On y implémente des fonctions pour les leds, le minuteur, la communication série. | |||
[ | # leds : fonctions pour allumer, éteindre et faire clignoter (exemple de tâche). | ||
# minuteur : pour pouvoir effectuer une tâche pendant un certain temps. | |||
# communication série (deuxième exemple de tâche). Commande minicom à taper dans le terminal (-o permet d'éviter que mincom envoie des commandes d'initialisation) : | |||
<syntaxhighlight lang="c"> | |||
sudo minicom -D /dev/ttyACM0 -b 9600 -o | |||
</syntaxhighlight>[[Fichier:Minicom2.png|center|500px|alt=Minicom_|vignette|Minicom_]] | |||
<p style="clear: both;" /> | |||
== Carte fille Clavier == | == Carte fille Clavier == | ||
=== Boutons utilisés === | |||
Nous voulions implémenter un clavier à touche mécanique. Monsieur Xavier REDON avait des switchs qui convenait donc nous n'avions pas besoin d'en recommander. | |||
Les switchs sont de la marque KAILH : | |||
[[Fichier:Boite Kailh Switch.jpg|centré|vignette|Boite Kailh Switch]] | |||
[[Fichier:Kailh Hot swap socket.png|gauche|vignette|Kailh Hot swap socket]] | |||
[[Fichier:Bouton kailh comparaison hot swap.jpg|vignette|300x300px|Bouton kailh comparaison hot swap socket]] | |||
Petit bémol : les '''sockets hot-swap''' ne correspondaient pas à nos boutons. Comme on peut le voir sur la photo, il existe '''deux types de sockets''' pour nos modules hot-swap. Nous avons donc dû commander les modèles adaptés. | |||
L’intérêt de ces modules est de '''pouvoir insérer ou retirer les boutons à volonté''', sans qu’ils soient soudés directement au PCB — ce sont les sockets qui, eux, sont soudés. Cette solution présente plusieurs avantages : elle '''facilite la réutilisation des boutons''' d’un projet à un autre et '''améliore la réparabilité''' du clavier. | |||
==== Concevons un clavier ! ==== | |||
Notre clavier doit comporter '''62 touches''', conformément au '''format standard ISO 60 %''', et sera capable d’'''assurer l’ensemble des combinaisons de touches attendues pour un clavier moderne en 2025'''. | |||
Afin de customiser notre clavier, on se rend sur le site [https://www.keyboard-layout-editor.com/#/ keyboard-layout-editor] . | |||
=== | Nous pouvons partir d'un modèle de base ou alors d'un preset : | ||
[[Fichier:Site keyboard layout .png|centré|vignette|534x534px|Site keyboard layout preset ISO 60%]] | |||
Nous nous sommes alors inspirés des '''claviers disponibles sur le marché''' afin d’adopter un placement des touches conforme aux dispositions les plus courantes. | |||
[[Fichier:Keyboard-layout.jpg|centré|vignette|575x575px|Keyboard layout]] | |||
<p style="clear: both;" /><p style="clear: both;" />L’utilisation de cet outil présente plusieurs intérêts : elle permet d’'''imaginer et définir la disposition du clavier''', de '''le découper en lignes et colonnes''' afin de concevoir la '''matrice de touches''', et enfin d’'''identifier les bonnes empreintes''' à utiliser sur le futur PCB grâce au '''sommaire illustré ci-dessous'''. | |||
[[Fichier:Summary keyboard layout.png|centré|vignette|399x399px|Summary keyboard layout]] | |||
<p style="clear: both;" /><p style="clear: both;" />Ce sommaire indique la '''taille indicative de chaque type de touche''' ainsi que '''le nombre de touches associées''' à chacune d’elles. Le "coloriage" est utile pour voir visuellement quelle touche correspond à quelle taille.<p style="clear: both;" />On peut également sauvegarder notre configuration en exportant sous format "json". Via ce format on peut utiliser une extension de kicad qui se prénomme "'''Keyboard footprints placer'''" et qui permet de placer automatiquement les boutons si on les intancie dans le bon ordre (exemple : bouton 1 => SW1 , etc...). L'outil est un peu capricieux mais fais gagner un peu de temps précieux sur le routage. | |||
==== Kicad - Schématique Notre carte fille comporte plusieurs éléments : ==== | |||
# Le microcontrôleur ATMega32U4 avec un cristal de 16 MHz, des capacités de découplage et une ferrite (Cf AVR042) ; | |||
# L'USB pour la programmation et l'alimentation pendant la phase programmation du projet ; | |||
# Le connecteur ISP ; | |||
# Les boutons RST et HWB ; | |||
# Le connecteur SPI pour la communication avec la carte mère ; | |||
# La led pour l'alimentation de la carte ; | |||
# La led pour l'état du clavier (rôle ?) ; | |||
# La matrice de touches évidemment ; | |||
# Des mounting holes. | |||
Remarque : Pas de leds RGB, pas assez de pins et nous ne voulions pas nous éparpiller sur trop d'idées (sujet evoquer avec M Boé). | |||
==== | [[Fichier:Clavier schematique.pdf|center|700px|alt=Clavier schematique|vignette|Clavier schematique]] | ||
[ | |||
==== Kicad - Vue 3D ==== | |||
[[Fichier:Keyboard 3D up v2.png|gauche|vignette|652x652px|Keyboard 3D up]] | |||
[[Fichier:Keyboard 3D back v2.png|vignette|649x649px|Keyboard 3D back]] | |||
<p style="clear: both;" /> | |||
== Carte Fille FPGA == | == Carte Fille FPGA == | ||
Une '''carte FPGA''' est actuellement en développement en parallèle. Il s’agit d’un '''défi technique majeur''' visant à faire évoluer le projet de '''pico-ordinateur''' vers une nouvelle étape. | |||
=== | L’objectif, à terme, est de concevoir un '''pico-ordinateur complet''' capable de '''gérer des flux vidéo et audio''', ainsi que différents '''protocoles HID''', notamment en intégrant un '''microcontrôleur''' (comme sur la carte '''Nexys A7''', par exemple). Dans cette optique, le développement de la carte FPGA doit '''progresser au mieux''', mais il est '''possible que le travail se poursuive sur le semestre S8''', comme convenu avec '''M. Boé'''. | ||
=== Kicad - Schématique === | |||
La référence de la puce FPGA à router est celle ci : XC7A15T-1FTG256C. C'est une puce de la famille Artix-7. | |||
Les notes liées à la conception de la schématique se trouve dans ce répertoire : https://gitea.plil.fr/ahouduss/SE4-Pico-B6/src/branch/master/01-Kicad/Recherche%20FGPA . | |||
La schématique comporte elle même toutes les explications, il est donc inutile de revenir sur chacun de ces points ici. | |||
===== Liste et Description des sheets ===== | |||
'''''FPGA_Power :''''' Feuille regroupant l'alimentation critique de notre puce : | |||
# VCCAUX : Auxiliary voltage (tension auxiliaire), alimente circuits internes non critiques en puissance. | |||
# VCCINT : Internal core voltage (tension interne du cœur logique), alimente la logique principale du FPGA (LUTs, Flip-flops). | |||
# VCCADC/BATT : | |||
#* VCCADC : tension pour le module ADC si le FPGA en a un. | |||
#* VBATT : alimenter registres de configuration non volatiles ou horloge temps réel. | |||
# VCCBRAM : Block RAM, alimente les blocs mémoire. Cela permet de séparer l’alimentation de la mémoire afin de réduire le bruit. | |||
'''''FPGA_Banks_14-15''''' et '''''FPGA_Banks_34-35''''' ''':''' Feuille disposant de l'ensemble des entrées et sorties du FPGA n'ayant pas de fonction prédisposé et étant donc libre pour ajouter nos composants. | |||
'''''FPGA_Config :''''' Feuille regroupant les pins de programmation de la puce en fonction du mode choisi au préalable ainsi que la logique data USB-C (2.0 ici) . | |||
'''''Switch&Button :''''' ''Feuille contenant les boutons et les switchs.'' Joue le rôle de la carte matrice de boutons''.'' | |||
'''''LEDs&7seg :''''' ''Feuille contenant les LEDs et le 7 segments.'' | |||
'''''Ethernet :''''' ''Feuille contenant la logique Ethernet de notre carte.'' Joue le rôle de la carte réseau. | |||
'''''VGA :''''' ''Feuille contenant toute la logique du VGA.'' Joue le rôle de la carte écran. | |||
'''''HDMI :''''' ''Feuille abandonné car non supporté par notre puce FPGA.'' | |||
'''''Power :''''' Feuille sur la gestion de l'alimentation avec son séquencage. | |||
'''''Memory :''''' Feuille contenant la mémoire SRAM de notre carte. Joue le rôle de la carte mémoire. | |||
Version actuelle datée du 28 octobre 2025 à 23:57
Cahier des charges
L'objectif pour notre groupe est de réaliser une carte mère.
Lien GIT
Lien du git : https://gitea.plil.fr/ahouduss/SE4-Pico-B6
Carte Shield
La première étape est de réaliser un shield au cas où notre carte mère s'avérerait non fonctionnelle, afin de ne pas bloquer l'avancée des groupes des cartes filles.
Hardware
Composants
Afin de réaliser notre bouclier qui combiné à un arduino uno fera guise de carte mère, nous utilisons les composants suivants :
- Puce ATMega328-A en tant que microprocesseur
- 5 connecteurs 2*4 pour les cartes filles (clavier, écran, réseau, son) et un connecteur 2*4 pour connecter la carte mémoire.
- Des convertisseurs de niveaux logiques 5V vers 3,3V pour l'utilisation de la carte mémoire (même si il aurait été préférable de mettre la partie conversion directement sur la carte mémoire).
Schématique et vue 3D
Carte mémoire
En extension de notre shield ou de notre future carte mère, on ajoute la gestion de la mémoire avec la carte SD sur une carte mémoire distincte.
Brasage
On procède au brasage des cartes shield et mémoire.
Tests
Test leds
On teste les leds et on constate que notre carte shield est fonctionelle.
Test carte SD
On teste ensuite un programme arduino simple au préalable pour voir si la carte SD est détectée. La carte n'étant pas détectée, on regarde alors :
- que la connexion série est bien établie pour voir si le problème ne vient pas de l'IDE Arduino -> ce n'est pas le cas.
- si la carte SD est défaillante en testant le programme avec une autre carte SD. On teste aussi sur un lecteur de carte SD pour voir si elle est détectée sur le pc ce qui est le cas -> le pb ne vient pas de là non plus.
- on s'intéresse maintenant à l'aspect matériel, on vérifie les soudures -> toujours pas de souci particulier.
- schématique et routage de la carte : on s'aperçoit alors que l'on a inversé le sens du 74LVC125 de l'unité U1A pour la conversion de niveau logique du MOSI en appuyant par erreur sur le raccourci clavier x qui inverse en "miroir" le sens du composant. Remarque : on aurait aussi vraiment du mettre le convertisseur de niveau logique sur la carte mémoire pour voir le problème plus vite. Conséquence : le routage n'est pas correct, on rajoute donc des fils pour faire les bonnes connexions et on coupe au cutter les mauvaises.
[INSERER PHOTO]
Software
Programmation carte SD
Maintenant que la carte SD fonctionne, on va s'atteler à essayer de comprendre son fonctionnement en stockant des données dedans à l'aide de code en C.
[CONTINUER LA PROG]
Ordonnanceur
Maintenant que notre shield est fonctionnel, nous pouvons réaliser notre ordonnanceur. A voir ici : https://gitea.plil.fr/ahouduss/SE4-Pico-B6/src/branch/master/03%20-%20Code/Carte%20Shield/ordonnanceur.
[EXPLICATIONS A DETAILLER]
Carte mère
La deuxième carte à réaliser est la carte mère avec une spécificité cependant, à savoir une puce STM32F410R8T6 en tant que microprocesseur.
Remarque : M. Redon a également fait une carte mère mais basée sur un ATSAMD21G8A-A. Celle-ci pourra nous être utile si on rencontre des soucis pour le code avec notre stm32.
Hardware
Microprocesseur
On utilise la puce STM32F410R8T6.
Signification du nom de la puce
Signification (cf p 134 de la short datasheet) :
Arm based 32-bit microcontroller
- F = General-purpose
- R = 64 pins
- 8 = 64 Kbytes of Flash memory
- T = package LQFP
- 6 = Industrial temperature range, - 40 to 85 °C
Datasheets
Datasheet de la puce STM32F410R8T6 :
On peut également retrouver des pages supplémentaires afin de bien dimensionner notre quartz et les capacités aux alentours. Document AN2867- Guidelines for oscillator design on STM8AF/AL/S and STM32 MCUs/MPUs à retrouver sur le lien suivant : https://www.st.com/en/microcontrollers-microprocessors/stm32f410/documentation.html
Schématique
Notre schématique est composée de quatres sous feuilles, respectivement pour l'alimentation, le microcontrôleur, la carte mémoire et les cartes filles.
Alimentation
L'alimentation se fait via du 5V et est ensuite directement convertie en 3,3V par le biais du régulateur afin d'alimenter le microcontrôleur. C'est pourquoi les bus de données USB ne sont pas utilisées car l'USB servira ici uniquement à l'alimentation et pas à la transmission de données. On ajouté également des mounting holes pour fixer la carte.
Carte mémoire
La carte mémoire ou carte fille SD est sensiblement la même que celle pour le shield. On a juste rajouté une capacité de découplage car la carte SD va recevoir et envoyer beaucoup de données rapidement.
Microcontrôleur
Le microcontrôleur est composé de beaucoup de broches dédiées à l'alimentation, aux horloges, aux boots, à la communication, aux cartes filles, aux switchs, aux leds et au JTAG (voir sections suivantes).
Alimentation
Les broches VDD servent à l'alimentation numérique et VDDA à l'alimentation analogique, ici séparée pour filtrer de manière plus précise car plus sensible que le numérique. En effet, pour filtrer les hautes fréquences en numérique, les capacités de découplage suffisent alors qu'en analogique le signal d'entrée nécessite une gestion plus précise avec une ferrite.
Horloges
On utilise ici deux sources d'horloge : on peut soit choisir l'oscillateur RC ou une horloge externe comprise entre 4-26 MHz (p18/142) ou bien la deuxième horloge est une horloge pour temps réels (donc pas une application qu'on vise) (p22/142).
[PRECISER VALEURS ET REFERENCES]
Boot et configuration
Les boot 0 et 1 permettent de choisir la partie ou le bloc mémoire que l'on souhaite réinitialiser. En sélectionnant 0 bit, un bit de l'un ou de l'autre ou les deux, on choisit ce que l'on souhaite réinitialiser. On peut réinitialiser :
- la flash (boot0 à 0) : mémoire non volatile pour le code principal. Adresse : 0x0800 0000 - 0x0801 FFFF d'après le memory mapping (p43/142).
- la ROM - Read Only Memory (boot0 à 1 et boot1 à 0) : mémoire non volatile que l'on change rarement sauf si besoin de changer mode communication par exemple (passage en spi, uart ...). Adresse : 0x1FFF 0000 - 0x1FFF 77FF.
- la SRAM - Static Random Access Memory (boot0 à 1 et boot1 à 1) : mémoire volatile pour le débogage. Adresse : 0x2000 0000 - 0x2000 7FFF.
On a aussi le pin NRST (Not Reset car actif à l'état bas) pour réinitialiser le microcontrôleur.
Switchs
On a 3 switchs qui peuvent servir pour choisir les modes de boot ?. [PRECISER UTILITE]
Communication
On a prévu différents types de communications selon les utilisations : SPI pour les cartes filles mais aussi UART et I2C amélioré si besoin pour une potentielle carte FPGA.
Cartes filles
On a prévu de la place pour 5 cartes filles, sans compter la carte mémoire et la carte FPGA potentielle.
Leds
3 leds supplémentaires ont étés ajoutées pour différents tests, utile pour l'ordonnanceur potentiellement par exemple.
JTAG et SWD
Le bloc JTAG sert pour le débogage de la carte. Ici sur le stm32, c'est combiné à un deuxième mode de débogage spécifique aux stm32 : le SWD, une version simplifiée de JTAG.
JTAG (Joint Test Action Group) :
- TCK : Test Clock, l'horloge du JTAG
- TMS : Test Mode Select
- TDI : Test Data In pour envoyer des données depuis le JTAG au microcontrôleur.
- TDO : Test Data Out pour envoyer des données depuis le microcontrôleur au JTAG.
- RTCK : Return Test Clock
SWD (Serial Wire Debug) :
- SWCLK : comme TCK
- SWDIO : comme TMS
- SWO : comme TDO
Cartes filles
Notre carte mère peut acceuillir 5 cartes filles communicantes en SPI parmi lesquelles :
- carte clavier
- carte écran
- carte réseau
- carte son
- une autre carte
Et en plus de cela, on a aussi la carte "fille" pour la gestion de la mémoire = le boîtier SD (en SPI également) ainsi que la carte fille FPGA ou d'autre cartes qui peuvent communiquer en UART ou I2C amélioré (car SMBA).
Remarque : pour voir les différentes pages de la schématique, cliquer sur le fichier.
Vue 3D
Software
NUCLEO-F410RB
En attendant de recevoir notre carte mère et afin de prendre en main la programmation quelque peu spécifique des arm, on s'entraîne sur la carte NUCLEO-F410RB qui possède le même microcontrôleur STM32F410R8T6 que celui de notre carte mère.
Spécifications
La carte NUCLEO-F410RB est "séparée" en deux parties :
- la partie haute de la carte : c'est le programmateur spécifique à STM32 nommé ST-LINK qui permet de programmer :
- la partie basse de la carte : qui est elle dédiée à l'utilisateur.
STM32CubeIDE
Test led
Pour commencer à comprendre, on utilise dans un premier temps l'IDE STM32CubeIDE dont l'on se passera ensuite afin d'être proche du matériel et de ne pas passer par plein de librairies. Dans notre fichier nucleo.ioc, on a toutes les spécifications de notre carte dont le pinout. Premier programme test : on fait clignoter la led LD2. On voit sur le fichier nucleo.ioc que LD2 est sur le pin PA5 du microcontrôleur. En allant dans l'arborescence à gauche, on va dans Core -> Src -> main.c.
On ouvre le main et dans la boucle while, on va faire clignoter notre led D2 grâce à la librairie HAL (Hardware Abstraction Layer) dont l'on se passera par la suite (c'est juste pour les premiers tests).
while (1)
{
HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_5); //change d'état
HAL_Delay(500); //attend 500ms
}
Sans IDE
Test led
Après avoir testé le code dans l'IDE, on va maintenant coder avec moins de librairies subsidiaires avec juste les fichiers utiles pour la puce STM32F410RB que l'on va chercher sur le site de STMicroelectronics .
On va dans la catégorie Tools et software : https://www.st.com/en/microcontrollers-microprocessors/stm32f410rb.html#tools-software.
On pourrait sélectionner directement l'evaluation tools de la nucleo mais ce n'est pas l'objectif ici puisque la nucleo nous permet juste de s'entraîner sur le microcontrôleur F410 le temps que l'on recoive notre carte. Donc on va plutôt télécharger STM32CubeF4.
Suite à cela, on ajoutera différents fichiers :
- stm32cubef4-v1-28-3 : le firmware de STMicroelectronics
- main.c : code principal
- main.h
- ordonnanceur.c : uniquement pour l'ordonnanceur, le main.c gère le reste, les différents fichiers et variables à inclure
- ordonnanceur.h
- un makefile : pour compiler notre projet et les fichiers du firmware. On compile avec arm-none-eabi-gcc. On rajoute les chemins d'accès nécéssaires à la compilation du main.h qui a besoin du fichier stm32f410rx.h. On a également besoin du fichier core_cm4.h, d'où le second chemin : INCLUDES = -Istm32cubef4-v1-28-3/STM32Cube_FW_F4_V1.28.0/Drivers/CMSIS/Device/ST/STM32F4xx/Include \ -Istm32cubef4-v1-28-3/STM32Cube_FW_F4_V1.28.0/Drivers/CMSIS/Include
- un fichier nommé linker.ld : à la différence des atmega, notre microcontrôleur a une organisation mémoire plus complexe donc ce fichier nous permet de choisir où placer chaque type de données (cf les sections elf) dans la mémoire du microcontrôleur. On y précise la taille de la flash : 128ko et la taille de la RAM : 32 ko ainsi que leurs adresses trouvées page 40/763 de la datasheet. On y initialise également les sections .text (le code), .data (variables initialisées) et .bss (variables non initialisées).
- un fichier startup_stm32f410rx.s : un fichier assembleur qui gère les interruptions, les resets, l'initialisation des données que l'on copie colle depuis /stm32/stm32cubef4-v1-28-3/STM32Cube_FW_F4_V1.28.0/Drivers/CMSIS/Device/ST/STM32F4xx/Source/Templates/gcc. Remarque sur ce qu'est thumb : sur notre stm32, on utilise ARM et thumb 2 dont le rôle est d'avoir un code plus compact en mélangeant des instructions à la fois de 16 et 32 bits.
Remarque : commande à taper quand la carte "fail to connect" :
st-flash --connect-under-reset erase
Ordonnanceur
Il faut également faire l'ordonnanceur que l'on doit maintenant adapter non plus au shield et aux avr mais à la carte mère et aux arm.
- ordonnanceur.h :
On y ajoute les librairies et la liste des fonctions implémentées dans ordonnanceur.c
- ordonnanceur.c :
On y implémente des fonctions pour les leds, le minuteur, la communication série.
- leds : fonctions pour allumer, éteindre et faire clignoter (exemple de tâche).
- minuteur : pour pouvoir effectuer une tâche pendant un certain temps.
- communication série (deuxième exemple de tâche). Commande minicom à taper dans le terminal (-o permet d'éviter que mincom envoie des commandes d'initialisation) :
sudo minicom -D /dev/ttyACM0 -b 9600 -o
Carte fille Clavier
Boutons utilisés
Nous voulions implémenter un clavier à touche mécanique. Monsieur Xavier REDON avait des switchs qui convenait donc nous n'avions pas besoin d'en recommander.
Les switchs sont de la marque KAILH :
Petit bémol : les sockets hot-swap ne correspondaient pas à nos boutons. Comme on peut le voir sur la photo, il existe deux types de sockets pour nos modules hot-swap. Nous avons donc dû commander les modèles adaptés.
L’intérêt de ces modules est de pouvoir insérer ou retirer les boutons à volonté, sans qu’ils soient soudés directement au PCB — ce sont les sockets qui, eux, sont soudés. Cette solution présente plusieurs avantages : elle facilite la réutilisation des boutons d’un projet à un autre et améliore la réparabilité du clavier.
Concevons un clavier !
Notre clavier doit comporter 62 touches, conformément au format standard ISO 60 %, et sera capable d’assurer l’ensemble des combinaisons de touches attendues pour un clavier moderne en 2025.
Afin de customiser notre clavier, on se rend sur le site keyboard-layout-editor .
Nous pouvons partir d'un modèle de base ou alors d'un preset :
Nous nous sommes alors inspirés des claviers disponibles sur le marché afin d’adopter un placement des touches conforme aux dispositions les plus courantes.
L’utilisation de cet outil présente plusieurs intérêts : elle permet d’imaginer et définir la disposition du clavier, de le découper en lignes et colonnes afin de concevoir la matrice de touches, et enfin d’identifier les bonnes empreintes à utiliser sur le futur PCB grâce au sommaire illustré ci-dessous.
Ce sommaire indique la taille indicative de chaque type de touche ainsi que le nombre de touches associées à chacune d’elles. Le "coloriage" est utile pour voir visuellement quelle touche correspond à quelle taille.
On peut également sauvegarder notre configuration en exportant sous format "json". Via ce format on peut utiliser une extension de kicad qui se prénomme "Keyboard footprints placer" et qui permet de placer automatiquement les boutons si on les intancie dans le bon ordre (exemple : bouton 1 => SW1 , etc...). L'outil est un peu capricieux mais fais gagner un peu de temps précieux sur le routage.
Kicad - Schématique Notre carte fille comporte plusieurs éléments :
- Le microcontrôleur ATMega32U4 avec un cristal de 16 MHz, des capacités de découplage et une ferrite (Cf AVR042) ;
- L'USB pour la programmation et l'alimentation pendant la phase programmation du projet ;
- Le connecteur ISP ;
- Les boutons RST et HWB ;
- Le connecteur SPI pour la communication avec la carte mère ;
- La led pour l'alimentation de la carte ;
- La led pour l'état du clavier (rôle ?) ;
- La matrice de touches évidemment ;
- Des mounting holes.
Remarque : Pas de leds RGB, pas assez de pins et nous ne voulions pas nous éparpiller sur trop d'idées (sujet evoquer avec M Boé).
Kicad - Vue 3D
Carte Fille FPGA
Une carte FPGA est actuellement en développement en parallèle. Il s’agit d’un défi technique majeur visant à faire évoluer le projet de pico-ordinateur vers une nouvelle étape.
L’objectif, à terme, est de concevoir un pico-ordinateur complet capable de gérer des flux vidéo et audio, ainsi que différents protocoles HID, notamment en intégrant un microcontrôleur (comme sur la carte Nexys A7, par exemple). Dans cette optique, le développement de la carte FPGA doit progresser au mieux, mais il est possible que le travail se poursuive sur le semestre S8, comme convenu avec M. Boé.
Kicad - Schématique
La référence de la puce FPGA à router est celle ci : XC7A15T-1FTG256C. C'est une puce de la famille Artix-7. Les notes liées à la conception de la schématique se trouve dans ce répertoire : https://gitea.plil.fr/ahouduss/SE4-Pico-B6/src/branch/master/01-Kicad/Recherche%20FGPA .
La schématique comporte elle même toutes les explications, il est donc inutile de revenir sur chacun de ces points ici.
Liste et Description des sheets
FPGA_Power : Feuille regroupant l'alimentation critique de notre puce :
- VCCAUX : Auxiliary voltage (tension auxiliaire), alimente circuits internes non critiques en puissance.
- VCCINT : Internal core voltage (tension interne du cœur logique), alimente la logique principale du FPGA (LUTs, Flip-flops).
- VCCADC/BATT :
- VCCADC : tension pour le module ADC si le FPGA en a un.
- VBATT : alimenter registres de configuration non volatiles ou horloge temps réel.
- VCCBRAM : Block RAM, alimente les blocs mémoire. Cela permet de séparer l’alimentation de la mémoire afin de réduire le bruit.
FPGA_Banks_14-15 et FPGA_Banks_34-35 : Feuille disposant de l'ensemble des entrées et sorties du FPGA n'ayant pas de fonction prédisposé et étant donc libre pour ajouter nos composants.
FPGA_Config : Feuille regroupant les pins de programmation de la puce en fonction du mode choisi au préalable ainsi que la logique data USB-C (2.0 ici) .
Switch&Button : Feuille contenant les boutons et les switchs. Joue le rôle de la carte matrice de boutons.
LEDs&7seg : Feuille contenant les LEDs et le 7 segments.
Ethernet : Feuille contenant la logique Ethernet de notre carte. Joue le rôle de la carte réseau.
VGA : Feuille contenant toute la logique du VGA. Joue le rôle de la carte écran.
HDMI : Feuille abandonné car non supporté par notre puce FPGA.
Power : Feuille sur la gestion de l'alimentation avec son séquencage.
Memory : Feuille contenant la mémoire SRAM de notre carte. Joue le rôle de la carte mémoire.