Wiki Techno-Innov - Contributions [fr]

Products/Module RFSub1G

2023-01-22T19:42:00Z

Nathael : Page créée avec « {{DISPLAYTITLE:Module RF-Sub1GHz}} right == Description == Le module "RF-Sub1GHz" est un module de communication RF (Radio-Fréquence)... »

{{DISPLAYTITLE:Module RF-Sub1GHz}}
[[Image:Module_RFSub1G.jpg|300px|right]]

== Description ==
Le module "RF-Sub1GHz" est un module de communication RF (Radio-Fréquence) qui utilise l'émetteur-récepteur sans-fil CC1101 de Texas Instruments et le microcontrôleur LPC1224 de NXP.<br />
Il est décliné en trois version :
* UEXT
* USB
* Standalone
=== Hardware ===
==== Dimensions ====
==== Connecteurs ====
* Connecteur P1
* Connecteur P2
* Connecteur P3
* Connecteur P4
* Connecteur P5
* Connecteur P6
* Connecteur P7
==== Slot micro-SD ====
* Slot J1
==== Jumpers ====
* Jumper J1
=== Electronique ===
==== Micro-contrôlleur LPC1224 ====
==== RAM interne ====
==== Mémoire Flash interne ====
==== Interfaces de communication ====
==== GPIO ====
==== ADC ====
==== Reset et mode ISP ====
==== Contrôleur RF Sub1GHz CC1101 ====
==== I²C ====
* Adresses I²C
* EEPROM externe
* Capteur de température
==== Boutons et Led utilisateur ====
==== Bridge USB-UART ====
=== Logiciel ===
==== Récupération des sources ====
==== Organisation des sources ====
==== Point d'entrée ====
==== Exemples ====
==== Compilation ====

== Utilisation ==
== TODO List ==
== Documentation Technique et Schémas ==
== Historique ==

Products

2023-01-22T19:29:05Z

Nathael :

{{DISPLAYTITLE:Liste des produits}}
== Projet "Scialys" ==
* [[Products/Module_Scialys|Module Scialys]]
[[Image:Module_Scialys.jpg|100px|left]]
: Le module principal du système Scialys (système d'optimisation de l'auto-consommation).

<div style="clear:both"> </div>

== Extensions miniPC ==
* [[Products/PiSerialPower|Extension "PiSerialPower"]]
[[Image:PiserialPower.jpg|100px|left]]
: Extension d'alimentation (mais pas que) pour cartes RaspberryPi (et modèles concurrents compatibles).

<div style="clear:both"> </div>

== Modules de développement ==
* [[Products/Module_GPIO_Demo|Module GPIO Démo]]
[[Image:Module_GPIO_Demo.jpg|100px|left]]
: Le module GPIO pour le DomoTab et le [[Products/DTPlug|DTPlug]].
: Le module GPIO-Démo est un module de développement pour les modules de communication du projet DomoTab.

<div style="clear:both"> </div>
* [[Products/LPC1224BO|LPC1224 Break-Out]]
[[Image:LPC1224-BO.jpg|100px|left]]
: La carte de développement LPC1224 Break-Out : un module de développement autonome (un port USB suffit) pour le microcontrôleur LPC1224 de NXP (ARM Cortex-M0).

<div style="clear:both"> </div>
* [[Products/LPC1224mbed|LPC1224-mbed]]
[[Image:LPC1224-mbed.jpg|60px|left]]
: La carte de développement LPC1224-mbed : une version "mbed ready du module de développement autonome pour le microcontrôleur LPC1224 de NXP (ARM Cortex-M0).

<div style="clear:both"> </div>
* [[Products/USB_UART|Adaptateur USB-UART]]
[[Image:USBtoUART.jpg|100px|left]]
: Adaptateur USB vers UART, et potentiellement UEXT.

<div style="clear:both"> </div>

== Modules de communication ==
* [[Products/Module_RFSub1G|Module RF Sub-1GHz]]
[[Image:Module_RFSub1G.jpg|100px|left]]
: Le module RF, version Standalone, USB, ou UEXT

<div style="clear:both"> </div>
* [[Products/Module_1Wire|Module 1Wire]]
[[Image:Module_1Wire.jpg|100px|left]]
: Module 1Wire au format UEXT.

<div style="clear:both"> </div>
* [[Products/Module_RS485|Module RS485]]
[[Image:Module_RS485.jpg|100px|left]]
: Module RS485 au format USB, UEXT et Standalone.

<div style="clear:both"> </div>
* [[Products/Module_KNX|Module KNX]]
[[Image:Module_KNX.jpg|100px|left]]
: Module KNX (filaire) au format USB, UEXT et Standalone.

<div style="clear:both"> </div>
* [[Products/Module_DMX|Module DMX]]
[[Image:Module_DMX.jpg|100px|left]]
: Module DMX (filaire) au format USB, UEXT et Standalone.

<div style="clear:both"> </div>
* [[Products/Module_CPL|Module CPL]]
[[Image:Module_CPL.jpg|100px|left]]
: Module CPL (Courant porteur) au format USB, UEXT et Standalone.

<div style="clear:both"> </div>
== Projet "DomoTab" ==
* [[Products/DTPlug|Le DTPlug]]
[[Image:DTPlug.png|100px|left]]
: Passerelle DTPlug : Ethernet ---> 4x UEXT

<div style="clear:both"> </div>
* [[Products/PSMC|Module PSMC : Power Supply Monitor & Control]]
[[Image:PSMC.jpg|100px|left]]
: Module PSMC pour alimentation d'un module de communication, mesure de courant (consommation) et contrôle d'une prise (Nécessite un module de communication pour fonctionner).

<div style="clear:both"> </div>
== Adaptateurs divers ==
* [[Products/Adaptateur_Thermocouple|Adaptateur Thermocouple]]
[[Image:Adaptateur_Thermocouple.jpg|100px|left]]
: Adaptateur Thermocouples pour mesure de température (nécessite un module de communication pour fonctionner).

Products/PiSerialPower

2021-09-22T09:53:14Z

Nathael :

{{DISPLAYTITLE:Extension PiSerialPower}}
[[Image:PiserialPower.jpg|300px|right]]

== Intro ==
La [http://wiki.techno-innov.fr/index.php/Products/PiSerialPower page de l'adaptaeur Pi Serial Power sur le Wiki en Anglais] est à jour. Celle-ci est en attente de traduction.

== Description ==
=== Hardware ===
==== Dimensions ====
==== Connecteurs ====
* Connecteur P1

=== Électronique ===
=== Logiciel ===

== Utilisation ==
== TODO List ==
== Documentation Technique et Schémas ==
* [http://techdata.techno-innov.fr/Adapters/PiSerialPower/PiSerialPower_Hat_v02-02.jpg Image en fonctionnement]
* [http://techdata.techno-innov.fr/Adapters/PiSerialPower/PiSerialPower.pdf Documentation technique] (en anglais seulement)
* [http://techdata.techno-innov.fr/Adapters/PiSerialPower/PiSerialPower_Schematics.pdf Schéma électronique de la carte]
* [http://techdata.techno-innov.fr/Adapters/PiSerialPower/PiSerialPower_Board.pdf Routage de la carte électronique]
* [http://techdata.techno-innov.fr/Adapters/PiSerialPower/PiSerialPower_Schematics.tar.bz2 Sources de la carte électronique au format KiCaD]
* [http://techdata.techno-innov.fr/Adapters/PiSerialPower/eeprom_settings.txt Fichier eeprom_settings.txt]
* [http://techdata.techno-innov.fr/Adapters/PiSerialPower/overlay.dts Fichier overlay.dts]

== Historique ==

Products/PiSerialPower

2021-09-22T08:58:12Z

Nathael : /* Documentation Technique et Schémas */

{{DISPLAYTITLE:Extension PiSerialPower}}
[[Image:PiserialPower.jpg|300px|right]]

== Description ==
=== Hardware ===
==== Dimensions ====
==== Connecteurs ====
* Connecteur P1

=== Électronique ===
=== Logiciel ===

== Utilisation ==
== TODO List ==
== Documentation Technique et Schémas ==
* [http://techdata.techno-innov.fr/Adapters/PiSerialPower/PiSerialPower_Hat_v02-02.jpg Image en fonctionnement]
* [http://techdata.techno-innov.fr/Adapters/PiSerialPower/PiSerialPower.pdf Documentation technique] (en anglais seulement)
* [http://techdata.techno-innov.fr/Adapters/PiSerialPower/PiSerialPower_Schematics.pdf Schéma électronique de la carte]
* [http://techdata.techno-innov.fr/Adapters/PiSerialPower/PiSerialPower_Board.pdf Routage de la carte électronique]
* [http://techdata.techno-innov.fr/Adapters/PiSerialPower/PiSerialPower_Schematics.tar.bz2 Sources de la carte électronique au format KiCaD]
* [http://techdata.techno-innov.fr/Adapters/PiSerialPower/eeprom_settings.txt Fichier eeprom_settings.txt]
* [http://techdata.techno-innov.fr/Adapters/PiSerialPower/overlay.dts Fichier overlay.dts]

== Historique ==

Products/PiSerialPower

2021-09-22T08:57:29Z

Nathael : /* Documentation Technique et Schémas */

{{DISPLAYTITLE:Extension PiSerialPower}}
[[Image:PiserialPower.jpg|300px|right]]

== Description ==
=== Hardware ===
==== Dimensions ====
==== Connecteurs ====
* Connecteur P1

=== Électronique ===
=== Logiciel ===

== Utilisation ==
== TODO List ==
== Documentation Technique et Schémas ==
* [http://techdata.techno-innov.fr/Adapters/PiSerialPower/PiSerialPower_Hat_v02-02.jpg Image en fonctionnement]
* [http://techdata.techno-innov.fr/Adapters/PiSerialPower/PiSerialPower.pdf Documentation technique] (en anglais seulement)
* [http://techdata.techno-innov.fr/Adapters/PiSerialPower/PiSerialPower_Schematics.pdf Schéma électronique de la carte]
* [http://techdata.techno-innov.fr/Adapters/PiSerialPower/PiSerialPower_Board.pdf Routage de la carte électronique]
* [http://techdata.techno-innov.fr/Adapters/PiSerialPower/PiSerialPower_Schematics.tar.bz2 Source de la carte électronique au format KiCaD]
* [http://techdata.techno-innov.fr/Adapters/PiSerialPower/eeprom_settings.txt Fichier eeprom_settings.txt]
* [http://techdata.techno-innov.fr/Adapters/PiSerialPower/overlay.dts Fichier overlay.dts]

== Historique ==

Products/USB UART

2021-03-25T00:56:23Z

Nathael : /* Utilisation */

{{DISPLAYTITLE:Adaptateur USB-UART}}
[[Image:USBtoUART.jpg|300px|right]]

== Description ==
L'adaptateur USB-UART est un adaptateur simple et utile donnant accès à une liaison série (UART 3.3V) à partir d'un port USB, incluant un accès aux alimentations 3.3V et 5.0V pour tous vos besoins de prototypage.

Cet adaptateur utilise le composant FTDI FT230XS et dispose de deux connecteurs USB différents, USB A ou micro-USB (Les deux connecteurs sont montés en même temps, mais un seul peut être utilisé à un moment donné, ne connectez jamais les deux simultanément !)

Ce composant devrait aussi supporter l'I2C, le SPI, et d'autres protocoles/bus de données, et nous avons donc mis un connecteur UEXT, cependant cela nécessitera quelques développements logiciels. Nous vous tiendrons au courant des évolutions.

== Utilisation ==
== Connecteurs ==
=== Connecteur P1 ===
[[Image:USB_UART_V02_P1.png|300px|right]]
P1 est un connecteur standard au pas de 2.54mm (0.1 inch), avec 2 colonnes de 5 pins.
{| class="wikitable"
!colspan="4"|Connecteur P1
|-
| Pin #
| Description
| FT230XS signal
| Note
|-
| 1
| +3.3V from FT230XS
| +3.3V Out
| --
|-
| 2
| GND - Ground
| --
| --
|-
| 3
| UART Tx
| TxD
| FT230XS pin 1
|-
| 4
| UART Rx
| RxD
| FT230XS pin 4
|-
| 5
| I2C SCL
| RTS
| FT230XS pin 2
|-
| 6
| I2C SDA
| CTS
| FT230XS pin 6
|-
| 7
| SPI MISO
| Sleep
| FT230XS pin 16
|-
| 8
| SPI MOSI
| TxDEN
| FT230XS pin 15
|-
| 9
| SPI CLK
| RxLed
| FT230XS pin 14
|-
| 10
| SPI CS
| Tx Led
| FT230XS pin 7
|}

=== Connecteur P2 ===
[[Image:USB_UART_V02_P2.png|300px|right]]
P2 est un connecteur standard au pas de 2.54mm (0.1 inch), avec 1 colonne de 2 pins, qui donne accès au 5V de l'USB.<br />
'''Note''' : Attention ! ne connectez jamais les deux pins de ce connecteur ensemble (comme pour un jumper) car cela cour-circuiterait l'alimentation USB, provoquant la destruction du filtre présent en entrée (FB1).
{| class="wikitable"
!colspan="3"|Connecteur P2
|-
| Pin #
| Description
| Note
|-
| 1
| +5V
| +5V from USB
|-
| 2
| GND
| Ground
|}

=== Connecteur P3 : micro USB debug ===
P3 est un port USB microB.<br />
Consultez la page [http://fr.wikipedia.org/wiki/Universal_Serial_Bus Universal Serial Bus (USB)] sur Wikipedia pour plus d'informations sur le BUS USB et les connecteurs USB.

=== Connecteur P4 : USB type A debug ===
P4 est un port USB type A male.<br />
Consultez la page [http://fr.wikipedia.org/wiki/Universal_Serial_Bus Universal Serial Bus (USB)] sur Wikipedia pour plus d'informations sur le BUS USB et les connecteurs USB.

== TODO List ==
* Documentation technique
* Support des protocoles I2C et SPI via les capacités de "bit-banging" du FTDI (soft PC)
* Support SWD et/ou JTAG
* Version avec RS232
* Version avec alimentation 1.8V (pour l'alimentation de microprocesseurs et le debug SWD/JTAG)

== Documentation Technique et Schémas ==
La documentation technique de ce produit est à rédiger

== Historique ==

MediaWiki:Sidebar

2020-09-03T22:06:24Z

Nathael :

Wiki Techno-Innov FR:Politique de confidentialité

2020-09-03T15:38:53Z

Nathael :

== Licence ==
Le contenu de ce Wiki est accessible à tous, et placé sous licence [http://creativecommons.org/licenses/by-sa/4.0/ Creative Commons attribution partage à l'identique].

== Responsabilités ==
Nous demandons aux auteurs de ne pas se cacher derrière des pseudonymes ou un faux nom. Ce que vous écrivez sur Internet engage votre responsabilité.

Faites attention à ce que vous écrivez, ne publiez pas d'informations sensibles, et en général, n'importunez pas les personnes, qu'il s'agisse d'autres auteurs ou de simples passants.

== Partage ==
Encore une fois, le contenu de ce Wiki est accessible à tous, et placé sous licence [http://creativecommons.org/licenses/by-sa/4.0/ Creative Commons attribution partage à l'identique].<br />
Vous pouvez donc lire son contenu sans limitation, le modifier si vous acceptez cette licence pour vos modifications et publications et que vous en avez la possibilité (contactez nous si vous n'avez pas de compte, voir message en page d'accueil), et même copier tout ou partie de son contenu si vous respectez la licence sous laquelle celui-ci est placé : Vous devez citer vos sources et leur(s) auteur(s), et placer le résultat - '''la totalité du résultat''' - sous la même licence.

Sinon, merci de passer votre chemin, et n'importunez pas les personnes présentes.

== Confidentialité et données personnelles ==
Techno-Innov ne conserve aucune donnée personnelle vous concernant du fait de l'utilisation de ce site.

Seuls les cookies strictement nécessaires au fonctionnement du site sont utilisés. Ils ne contiennent aucune information personnelle et ne permettent pas de vous identifier.

Si cela ne vous convient pas, merci d'aller voir ailleurs.

Wiki Techno-Innov FR:Copyrights

2020-09-03T15:32:39Z

Nathael : Page créée avec « Voir : ici ! »

Voir : [[Wiki_Techno-Innov_FR:Politique_de_confidentialité|ici]] !

Wiki Techno-Innov FR:Avertissements généraux

2020-09-03T15:17:08Z

Nathael : Page créée avec « Le contenu présent sur ce site est fourni tel quel, sans AUCUNE garantie d'aucune sorte. Les mises à jour sont faites occasionnellement, quand nous en avons le temps, e... »

Le contenu présent sur ce site est fourni tel quel, sans AUCUNE garantie d'aucune sorte.

Les mises à jour sont faites occasionnellement, quand nous en avons le temps, et le contenu présent sur ce site peut ne pas être à jour, et être modifié sans préavis (mais c'est un Wiki !)

Bonne lecture !

Accueil

2020-09-03T15:13:44Z

Nathael :

{{DISPLAYTITLE:Bienvenue sur le Wiki de la communauté Techno-Innov}}
<div id="mainpage_topbox">
<div class="mainpage_boxcontents">
Ce wiki est destiné à simplifier et organiser la diffusion d'informations autour de nos projets et produits.

Vous retrouverez ici des pages relatives à chacun des produits de Techno-Innov, des pages plus générales sur certains points techniques, et la série d'articles sur le "Making of" du module GPIO-Démo.
</div>
</div>

{| role="presentation" style="border:0; margin: 0; width: 100%; border-spacing: 10px;"
| style="vertical-align: top;" class="mainpage_hubbox" |
<div class="mainpage_boxcontents">
[[File:Products.png|80px|center|link=Products]]
<div title="Products">
<p><strong class="mainpage_boxcontents_title">
[[Products|Documentation des produits]]
</strong></p>
<ul>
<li>
[[Products/Module_Scialys|Module Scialys et extensions]]
</li>
<li>
Le [[Products/PiSerialPower|"RPi Power and Serial Hat"]]
</li>
<li>
Le [[Products/Module_GPIO_Demo|module GPIO Démo]] (et diverses déclinaisons)
</li>
<li>
Et [[Products|les autres]]
</li>
</ul>
</div>
</div>
| style="vertical-align: top;" class="mainpage_hubbox" |
<div class="mainpage_boxcontents">
[[File:API.png|80px|center|link=Technique]]
<div title="API">
<p><strong class="mainpage_boxcontents_title">
[[Technique/Logiciel|Documentation Soft]]
</strong></p>
<ul>
<li>
[[Technique/Logiciel/API|Utilisation de l'interface logicielle (API)]] de Techno-Innov pour les microcontrôleur ARM Cortex-M*
</li>
<li>
Guide pour [[Technique/Logiciel/API/New_App|créer une nouvelle application avec l'API]]
</li>
<li>
[[Technique/Logiciel/Compilation|Compiler le code des application utilisant l'API "Techno-Innov" sous Linux]]
</li>
</ul>
</div>
</div>
|}

{| role="presentation" style="border:0; margin: 0; width: 100%; border-spacing: 10px;"
| style="vertical-align: top;" class="mainpage_hubbox" |
<div class="mainpage_boxcontents">
[[File:TechData.png|80px|center|link=Technique]]
<div title="Infos Techniques">
<p><strong class="mainpage_boxcontents_title">
[[Technique|Informations techniques]]
</strong></p>
<li>
[[Technique/Logiciel/Embedded|Systèmes embarqués]]
</li>
<li>
[[Technique/Elec/Kicad|Utiliser Kicad]] pour [[Technique/Elec/DIY|créer vos propres cartes électroniques]]
</li>
</ul>
</div>
</div>
| style="vertical-align: top;" class="mainpage_hubbox" |
<div class="mainpage_boxcontents">
[[File:Articles.png|x80px|center|link=Articles]]
<div title="Articles">
<p><strong class="mainpage_boxcontents_title">
[[Articles|Articles des utilisateurs]]
</strong></p>
<ul>
<li>
Le [[Articles/Nathael|"Making of" du module GPIO-Démo]] paru dans [http://www.opensilicium.com/ Open Silicium]
</li>
<li>
[[Articles/Dindinx|Création de jeux pour micro-contrôleurs ARM Cortex-M0]] (avec écran SSD1036)
</li>
</ul>
</div>
</div>
|}

<br />
<br />
'''[[Wiki_Techno-Innov_FR:À_propos_de|À propos de ce site]]''' |
'''[[Wiki_Techno-Innov_FR:Politique_de_confidentialité|Licence et partage]]''' |
'''[[Contributeurs|Contributeurs]]'''

Techno-Innov Community Wiki:Confidentialité

2020-09-03T15:12:59Z

Nathael : Nathael a déplacé la page Techno-Innov Community Wiki:Confidentialité vers Wiki Techno-Innov FR:Politique de confidentialité

#REDIRECTION [[Wiki Techno-Innov FR:Politique de confidentialité]]

Wiki Techno-Innov FR:Politique de confidentialité

2020-09-03T15:12:59Z

Nathael : Nathael a déplacé la page Techno-Innov Community Wiki:Confidentialité vers Wiki Techno-Innov FR:Politique de confidentialité

Le contenu de ce Wiki est accessible à tous, et placé sous licence [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons attribution partage à l'identique].

Nous demandons aux auteurs de ne pas se cacher derrière des pseudonymes ou un faux nom. Ce que vous écrivez sur Internet engage votre responsabilité.

Faites attention à ce que vous écrivez, ne publiez pas d'informations sensibles, et en général, n'importunez pas les personnes, qu'il s'agisse d'autres auteurs ou de simples passants.

Encore une fois, le contenu de ce Wiki est accessible à tous, et placé sous licence [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons attribution partage à l'identique].<br />
Vous pouvez donc lire son contenu sans limitation, le modifier si vous acceptez cette licence pour vos modifications et publications et que vous en avez la possibilité (contactez nous si vous n'avez pas de compte, voir message en page d'accueil), et même copier tout ou partie de son contenu si vous respectez la licence sous laquelle celui-ci est placé : Vous devez citer vos sources et leur(s) auteur(s), et placer le résultat - '''la totalité du résultat''' - sous la même licence.

Sinon, merci de passer votre chemin, et n'importunez pas les personnes présentes.

Techno-Innov Community Wiki:À propos de

2020-09-03T15:09:43Z

Nathael : Nathael a déplacé la page Techno-Innov Community Wiki:À propos de vers Wiki Techno-Innov FR:À propos de

#REDIRECTION [[Wiki Techno-Innov FR:À propos de]]

Wiki Techno-Innov FR:À propos de

2020-09-03T15:09:42Z

Nathael : Nathael a déplacé la page Techno-Innov Community Wiki:À propos de vers Wiki Techno-Innov FR:À propos de

Ce wiki est destiné à simplifier et organiser la diffusion d'informations autour de nos projets et produits.

== Gestion du Wiki ==
=== Obtention des droits de modification ===
Le contenu en est principalement créé et maintenu par les soins de [[Utilisateur:Nathael]]. D'autres personnes auront certainement accès en écriture prochainement, et peut-être tout le monde dans un futur proche, mais toujours sur demande pour limiter les risques de détérioration.

N'hésitez pas à nous contacter par mail pour obtenir un accès en écriture.

Si ce mode de fonctionnement ne vous convient pas, vous pouvez passer votre chemin. De même si le contenu de ce wiki vous dérange ou ne vous intéresse pas.

=== Règles à respecter ===
Lorsque vous ferez partie des auteurs, merci de respecter certaines règles :

* Respectez les internautes (et les personnes en général). Vos affirmations vous engagent.
* Respectez l'organisation du Wiki
* Consultez régulièrement cette page pour voir si de nouvelles consignes ont été ajoutées.

Techno-Innov Community Wiki:À propos

2020-09-03T15:08:08Z

Nathael : Nathael a déplacé la page Techno-Innov Community Wiki:À propos vers Techno-Innov Community Wiki:À propos de

#REDIRECTION [[Techno-Innov Community Wiki:À propos de]]

Wiki Techno-Innov FR:À propos de

2020-09-03T15:08:08Z

Nathael : Nathael a déplacé la page Techno-Innov Community Wiki:À propos vers Techno-Innov Community Wiki:À propos de

Products

2020-09-03T14:09:58Z

Nathael : /* Extensions miniPC */

{{DISPLAYTITLE:Liste des produits}}
== Projet "Scialys" ==
* [[Products/Module_Scialys|Module Scialys]]
[[Image:Module_Scialys.jpg|100px|left]]
: Le module principal du système Scialys : gestion de l'auto-consommation.

<div style="clear:both"> </div>

== Extensions miniPC ==
* [[Products/PiSerialPower|Extension "PiSerialPower"]]
[[Image:PiserialPower.jpg|100px|left]]
: Extension d'alimentation (mais pas que) pour cartes RaspberryPi (et modèles concurrents compatibles).

<div style="clear:both"> </div>

== Modules de développement ==
* [[Products/Module_GPIO_Demo|Module GPIO Démo]]
[[Image:Module_GPIO_Demo.jpg|100px|left]]
: Le module GPIO pour le DomoTab et le [[Products/DTPlug|DTPlug]].
: Le module GPIO-Démo est un module de développement pour les modules de communication du projet DomoTab.

<div style="clear:both"> </div>
* [[Products/LPC1224BO|LPC1224 Break-Out]]
[[Image:LPC1224-BO.jpg|100px|left]]
: La carte de développement LPC1224 Break-Out : un module de développement autonome (un port USB suffit) pour le microcontrôleur LPC1224 de NXP (ARM Cortex-M0).

<div style="clear:both"> </div>
* [[Products/LPC1224mbed|LPC1224-mbed]]
[[Image:LPC1224-mbed.jpg|60px|left]]
: La carte de développement LPC1224-mbed : une version "mbed ready du module de développement autonome pour le microcontrôleur LPC1224 de NXP (ARM Cortex-M0).

<div style="clear:both"> </div>
* [[Products/USB_UART|Adaptateur USB-UART]]
[[Image:USBtoUART.jpg|100px|left]]
: Adaptateur USB vers UART, et potentiellement UEXT.

<div style="clear:both"> </div>

== Modules de communication ==
* [[Products/Module_RFSub1G|Module RF Sub-1GHz]]
[[Image:Module_RFSub1G.jpg|100px|left]]
: Le module RF, version Standalone, USB, ou UEXT

<div style="clear:both"> </div>
* [[Products/Module_1Wire|Module 1Wire]]
[[Image:Module_1Wire.jpg|100px|left]]
: Module 1Wire au format UEXT.

<div style="clear:both"> </div>
* [[Products/Module_RS485|Module RS485]]
[[Image:Module_RS485.jpg|100px|left]]
: Module RS485 au format USB, UEXT et Standalone.

<div style="clear:both"> </div>
* [[Products/Module_KNX|Module KNX]]
[[Image:Module_KNX.jpg|100px|left]]
: Module KNX (filaire) au format USB, UEXT et Standalone.

<div style="clear:both"> </div>
* [[Products/Module_DMX|Module DMX]]
[[Image:Module_DMX.jpg|100px|left]]
: Module DMX (filaire) au format USB, UEXT et Standalone.

<div style="clear:both"> </div>
* [[Products/Module_CPL|Module CPL]]
[[Image:Module_CPL.jpg|100px|left]]
: Module CPL (Courant porteur) au format USB, UEXT et Standalone.

<div style="clear:both"> </div>
== Projet "DomoTab" ==
* [[Products/DTPlug|Le DTPlug]]
[[Image:DTPlug.png|100px|left]]
: Passerelle DTPlug : Ethernet ---> 4x UEXT

<div style="clear:both"> </div>
* [[Products/PSMC|Module PSMC : Power Supply Monitor & Control]]
[[Image:PSMC.jpg|100px|left]]
: Module PSMC pour alimentation d'un module de communication, mesure de courant (consommation) et contrôle d'une prise (Nécessite un module de communication pour fonctionner).

<div style="clear:both"> </div>
== Adaptateurs divers ==
* [[Products/Adaptateur_Thermocouple|Adaptateur Thermocouple]]
[[Image:Adaptateur_Thermocouple.jpg|100px|left]]
: Adaptateur Thermocouples pour mesure de température (nécessite un module de communication pour fonctionner).

Fichier:LPC1224-BO.jpg

2020-09-03T12:59:23Z

Nathael : Nathael a téléversé une nouvelle version de Fichier:LPC1224-BO.jpg

Products

2020-09-03T12:57:54Z

Nathael : /* Modules de développement */

{{DISPLAYTITLE:Liste des produits}}
== Projet "Scialys" ==
* [[Products/Module_Scialys|Module Scialys]]
[[Image:Module_Scialys.jpg|100px|left]]
: Le module principal du système Scialys : gestion de l'auto-consommation.

<div style="clear:both"> </div>

== Extensions miniPC ==
* [[Products/PiSerialPower|Extension "PiSerialPower"]]
[[Image:PiserialPower.jpg|100px|left]]
: Extension d'alimentation et de debug pour cartes RaspberryPi (et modèles concurrents compatibles).

<div style="clear:both"> </div>
== Modules de développement ==
* [[Products/Module_GPIO_Demo|Module GPIO Démo]]
[[Image:Module_GPIO_Demo.jpg|100px|left]]
: Le module GPIO pour le DomoTab et le [[Products/DTPlug|DTPlug]].
: Le module GPIO-Démo est un module de développement pour les modules de communication du projet DomoTab.

<div style="clear:both"> </div>
* [[Products/LPC1224BO|LPC1224 Break-Out]]
[[Image:LPC1224-BO.jpg|100px|left]]
: La carte de développement LPC1224 Break-Out : un module de développement autonome (un port USB suffit) pour le microcontrôleur LPC1224 de NXP (ARM Cortex-M0).

<div style="clear:both"> </div>
* [[Products/LPC1224mbed|LPC1224-mbed]]
[[Image:LPC1224-mbed.jpg|60px|left]]
: La carte de développement LPC1224-mbed : une version "mbed ready du module de développement autonome pour le microcontrôleur LPC1224 de NXP (ARM Cortex-M0).

<div style="clear:both"> </div>
* [[Products/USB_UART|Adaptateur USB-UART]]
[[Image:USBtoUART.jpg|100px|left]]
: Adaptateur USB vers UART, et potentiellement UEXT.

<div style="clear:both"> </div>

== Modules de communication ==
* [[Products/Module_RFSub1G|Module RF Sub-1GHz]]
[[Image:Module_RFSub1G.jpg|100px|left]]
: Le module RF, version Standalone, USB, ou UEXT

<div style="clear:both"> </div>
* [[Products/Module_1Wire|Module 1Wire]]
[[Image:Module_1Wire.jpg|100px|left]]
: Module 1Wire au format UEXT.

<div style="clear:both"> </div>
* [[Products/Module_RS485|Module RS485]]
[[Image:Module_RS485.jpg|100px|left]]
: Module RS485 au format USB, UEXT et Standalone.

<div style="clear:both"> </div>
* [[Products/Module_KNX|Module KNX]]
[[Image:Module_KNX.jpg|100px|left]]
: Module KNX (filaire) au format USB, UEXT et Standalone.

<div style="clear:both"> </div>
* [[Products/Module_DMX|Module DMX]]
[[Image:Module_DMX.jpg|100px|left]]
: Module DMX (filaire) au format USB, UEXT et Standalone.

<div style="clear:both"> </div>
* [[Products/Module_CPL|Module CPL]]
[[Image:Module_CPL.jpg|100px|left]]
: Module CPL (Courant porteur) au format USB, UEXT et Standalone.

<div style="clear:both"> </div>
== Projet "DomoTab" ==
* [[Products/DTPlug|Le DTPlug]]
[[Image:DTPlug.png|100px|left]]
: Passerelle DTPlug : Ethernet ---> 4x UEXT

<div style="clear:both"> </div>
* [[Products/PSMC|Module PSMC : Power Supply Monitor & Control]]
[[Image:PSMC.jpg|100px|left]]
: Module PSMC pour alimentation d'un module de communication, mesure de courant (consommation) et contrôle d'une prise (Nécessite un module de communication pour fonctionner).

<div style="clear:both"> </div>
== Adaptateurs divers ==
* [[Products/Adaptateur_Thermocouple|Adaptateur Thermocouple]]
[[Image:Adaptateur_Thermocouple.jpg|100px|left]]
: Adaptateur Thermocouples pour mesure de température (nécessite un module de communication pour fonctionner).

Products

2020-09-03T03:10:48Z

Nathael : /* Projet "Scialys" */

{{DISPLAYTITLE:Liste des produits}}
== Projet "Scialys" ==
* [[Products/Module_Scialys|Module Scialys]]
[[Image:Module_Scialys.jpg|100px|left]]
: Le module principal du système Scialys : gestion de l'auto-consommation.

<div style="clear:both"> </div>

== Extensions miniPC ==
* [[Products/PiSerialPower|Extension "PiSerialPower"]]
[[Image:PiserialPower.jpg|100px|left]]
: Extension d'alimentation et de debug pour cartes RaspberryPi (et modèles concurrents compatibles).

<div style="clear:both"> </div>
== Modules de développement ==
* [[Products/Module_GPIO_Demo|Module GPIO Démo]]
[[Image:Module_GPIO_Demo.jpg|100px|left]]
: Le module GPIO pour le DomoTab et le [[Products/DTPlug|DTPlug]].
: Le module GPIO-Démo est un module de développement pour les modules de communication du projet DomoTab.

<div style="clear:both"> </div>
* [[Products/LPC1224BO|LPC1224 Break-Out]]
[[Image:LPC1224-BO.jpg|60px|left]]
: La carte de développement LPC1224 Break-Out : un module de développement autonome (un port USB suffit) pour le microcontrôleur LPC1224 de NXP (ARM Cortex-M0).

<div style="clear:both"> </div>
* [[Products/LPC1224mbed|LPC1224-mbed]]
[[Image:LPC1224-mbed.jpg|60px|left]]
: La carte de développement LPC1224-mbed : une version "mbed ready du module de développement autonome pour le microcontrôleur LPC1224 de NXP (ARM Cortex-M0).

<div style="clear:both"> </div>
* [[Products/USB_UART|Adaptateur USB-UART]]
[[Image:USBtoUART.jpg|100px|left]]
: Adaptateur USB vers UART, et potentiellement UEXT.

<div style="clear:both"> </div>

== Modules de communication ==
* [[Products/Module_RFSub1G|Module RF Sub-1GHz]]
[[Image:Module_RFSub1G.jpg|100px|left]]
: Le module RF, version Standalone, USB, ou UEXT

<div style="clear:both"> </div>
* [[Products/Module_1Wire|Module 1Wire]]
[[Image:Module_1Wire.jpg|100px|left]]
: Module 1Wire au format UEXT.

<div style="clear:both"> </div>
* [[Products/Module_RS485|Module RS485]]
[[Image:Module_RS485.jpg|100px|left]]
: Module RS485 au format USB, UEXT et Standalone.

<div style="clear:both"> </div>
* [[Products/Module_KNX|Module KNX]]
[[Image:Module_KNX.jpg|100px|left]]
: Module KNX (filaire) au format USB, UEXT et Standalone.

<div style="clear:both"> </div>
* [[Products/Module_DMX|Module DMX]]
[[Image:Module_DMX.jpg|100px|left]]
: Module DMX (filaire) au format USB, UEXT et Standalone.

<div style="clear:both"> </div>
* [[Products/Module_CPL|Module CPL]]
[[Image:Module_CPL.jpg|100px|left]]
: Module CPL (Courant porteur) au format USB, UEXT et Standalone.

<div style="clear:both"> </div>
== Projet "DomoTab" ==
* [[Products/DTPlug|Le DTPlug]]
[[Image:DTPlug.png|100px|left]]
: Passerelle DTPlug : Ethernet ---> 4x UEXT

<div style="clear:both"> </div>
* [[Products/PSMC|Module PSMC : Power Supply Monitor & Control]]
[[Image:PSMC.jpg|100px|left]]
: Module PSMC pour alimentation d'un module de communication, mesure de courant (consommation) et contrôle d'une prise (Nécessite un module de communication pour fonctionner).

<div style="clear:both"> </div>
== Adaptateurs divers ==
* [[Products/Adaptateur_Thermocouple|Adaptateur Thermocouple]]
[[Image:Adaptateur_Thermocouple.jpg|100px|left]]
: Adaptateur Thermocouples pour mesure de température (nécessite un module de communication pour fonctionner).

Products

2020-09-03T03:09:30Z

Nathael : /* Modules de développement */

{{DISPLAYTITLE:Liste des produits}}
== Projet "Scialys" ==
* [[Products/Scialys|Module Scialys]]
[[Image:Module_Scialys.jpg|100px|left]]
: Le module principal du système Scialys : gestion de l'auto-consommation.

<div style="clear:both"> </div>
== Extensions miniPC ==
* [[Products/PiSerialPower|Extension "PiSerialPower"]]
[[Image:PiserialPower.jpg|100px|left]]
: Extension d'alimentation et de debug pour cartes RaspberryPi (et modèles concurrents compatibles).

<div style="clear:both"> </div>
== Modules de développement ==
* [[Products/Module_GPIO_Demo|Module GPIO Démo]]
[[Image:Module_GPIO_Demo.jpg|100px|left]]
: Le module GPIO pour le DomoTab et le [[Products/DTPlug|DTPlug]].
: Le module GPIO-Démo est un module de développement pour les modules de communication du projet DomoTab.

<div style="clear:both"> </div>
* [[Products/LPC1224BO|LPC1224 Break-Out]]
[[Image:LPC1224-BO.jpg|60px|left]]
: La carte de développement LPC1224 Break-Out : un module de développement autonome (un port USB suffit) pour le microcontrôleur LPC1224 de NXP (ARM Cortex-M0).

<div style="clear:both"> </div>
* [[Products/LPC1224mbed|LPC1224-mbed]]
[[Image:LPC1224-mbed.jpg|60px|left]]
: La carte de développement LPC1224-mbed : une version "mbed ready du module de développement autonome pour le microcontrôleur LPC1224 de NXP (ARM Cortex-M0).

<div style="clear:both"> </div>
* [[Products/USB_UART|Adaptateur USB-UART]]
[[Image:USBtoUART.jpg|100px|left]]
: Adaptateur USB vers UART, et potentiellement UEXT.

<div style="clear:both"> </div>

== Modules de communication ==
* [[Products/Module_RFSub1G|Module RF Sub-1GHz]]
[[Image:Module_RFSub1G.jpg|100px|left]]
: Le module RF, version Standalone, USB, ou UEXT

<div style="clear:both"> </div>
* [[Products/Module_1Wire|Module 1Wire]]
[[Image:Module_1Wire.jpg|100px|left]]
: Module 1Wire au format UEXT.

<div style="clear:both"> </div>
* [[Products/Module_RS485|Module RS485]]
[[Image:Module_RS485.jpg|100px|left]]
: Module RS485 au format USB, UEXT et Standalone.

<div style="clear:both"> </div>
* [[Products/Module_KNX|Module KNX]]
[[Image:Module_KNX.jpg|100px|left]]
: Module KNX (filaire) au format USB, UEXT et Standalone.

<div style="clear:both"> </div>
* [[Products/Module_DMX|Module DMX]]
[[Image:Module_DMX.jpg|100px|left]]
: Module DMX (filaire) au format USB, UEXT et Standalone.

<div style="clear:both"> </div>
* [[Products/Module_CPL|Module CPL]]
[[Image:Module_CPL.jpg|100px|left]]
: Module CPL (Courant porteur) au format USB, UEXT et Standalone.

<div style="clear:both"> </div>
== Projet "DomoTab" ==
* [[Products/DTPlug|Le DTPlug]]
[[Image:DTPlug.png|100px|left]]
: Passerelle DTPlug : Ethernet ---> 4x UEXT

<div style="clear:both"> </div>
* [[Products/PSMC|Module PSMC : Power Supply Monitor & Control]]
[[Image:PSMC.jpg|100px|left]]
: Module PSMC pour alimentation d'un module de communication, mesure de courant (consommation) et contrôle d'une prise (Nécessite un module de communication pour fonctionner).

<div style="clear:both"> </div>
== Adaptateurs divers ==
* [[Products/Adaptateur_Thermocouple|Adaptateur Thermocouple]]
[[Image:Adaptateur_Thermocouple.jpg|100px|left]]
: Adaptateur Thermocouples pour mesure de température (nécessite un module de communication pour fonctionner).

Products/Module Scialys

2020-09-03T03:05:21Z

Nathael :

{{DISPLAYTITLE:Système Scialys}}

Le module Scialys est la partie centrale d'un système de gestion de l'auto-consommation permettant de rediriger l'excédant de production (et seulement lui) vers une charge comme un chauffe-eau ou un ensemble de radiateurs. Ce principe limite le renvoi vers le réseau et optimise la consommation de l'énergie produite localement, pouvant aller jusqu'à complètement effacer la consommation d'un chauffe-eau électrique.

[[Image:Module_Scialys.jpg|300px|right]]

== Fonctionnement ==
=== Principe ===
Le module Scialys est un système autonome dont le fonctionnement est relativement simple. Les deux capteurs de courant mesurent en continu la production locale (solaire, éolien, ...) et la consommation du logement. Lorsque la production devient supérieure à la consommation le module scialys commence à alimenter sa charge principale (le chauffe-eau) proportionnellement à la différence de production/consommation de façon à équilibrer les deux mesures et utiliser au maximum la production locale.

Si un autre appareil se met en marche, les capteurs le détectent immédiatement et la consommation de la charge est réduite pour rééquilibrer la consommation et la production.

Le système peut ainsi étaler la consommation d'un chauffe-eau électrique sur une partie de la journée, profitant même des journées peu ensoleillées (ou avec peu de vent pour les éloiènnes) pendant lesquelles la production reste très faible.

=== Maintien du confort ===
Si la production reste trop faible pendant plusieurs jours d'affilé, le capteur de température installé sur le chauffe-eau permet au module Scialys, si la température descend en dessous d'un seuil de température minimale configurable, de déclencher une marche forcée pour faire remonter la température de l'eau (temporisation ou seuil de température à atteindre) et ainsi continuer à fournir le niveau de confort attendu par tous.

=== Modules d'extension ===
Si la production est suffisante et une fois que l'eau a atteint sa température maximum, des modules d'extension (à venir) permettent de commander d'autres charges, augmentant ainsi l'utilisation de l'énergie excédentaire (batteries, chauffage, véhicule électrique, ...).

Il est aussi possible d'ajouter des modules de communication permettant l'intégration dans un système de domotique existant.

== Description technique ==
=== Hardware ===
==== Dimensions ====
==== Connecteurs ====
* Connecteur P1

=== Électronique ===
==== Système de contrôle ====
==== Interfaces de communication ====
==== Reset et mode mise à jour (ISP) ====
==== Écran, boutons et leds RGB ====
=== Logiciel ===

== Utilisation ==
== TODO List ==
== Documentation Technique et Schémas ==
== Historique ==

Products/PiSerialPower

2020-09-03T02:57:36Z

Nathael : Page créée avec « {{DISPLAYTITLE:Extension PiSerialPower}} right == Description == === Hardware === ==== Dimensions ==== ==== Connecteurs ==== * Connecteu... »

Products/Module Scialys

2020-09-03T02:55:48Z

Nathael : Page créée avec « {{DISPLAYTITLE:Système Scialys}} right == Description == === Hardware === ==== Dimensions ==== ==== Connecteurs ==== * Connecteur P1... »

{{DISPLAYTITLE:Système Scialys}}
[[Image:Module_Scialys.jpg|300px|right]]

== Description ==
=== Hardware ===
==== Dimensions ====
==== Connecteurs ====
* Connecteur P1

=== Electronique ===
==== Système de contrôle ====
==== Interfaces de communication ====
==== Reset et mode mise à jour (ISP) ====
==== Écran, boutons et leds RGB ====
=== Logiciel ===

== Utilisation ==
== TODO List ==
== Documentation Technique et Schémas ==
== Historique ==

Fichier:PiserialPower.jpg

2020-09-03T02:52:02Z

Nathael :

Products

2020-09-03T02:50:10Z

Nathael :

{{DISPLAYTITLE:Liste des produits}}
== Projet "Scialys" ==
* [[Products/Scialys|Module Scialys]]
[[Image:Module_Scialys.jpg|100px|left]]
: Le module principal du système Scialys : gestion de l'auto-consommation.

<div style="clear:both"> </div>
== Extensions miniPC ==
* [[Products/PiSerialPower|Extension "PiSerialPower"]]
[[Image:PiserialPower.jpg|100px|left]]
: Extension d'alimentation et de debug pour cartes RaspberryPi (et modèles concurrents compatibles).

<div style="clear:both"> </div>
== Modules de développement ==
* [[Products/Module_GPIO_Demo|Module GPIO Démo]]
[[Image:Module_GPIO_Demo.jpg|100px|left]]
: Le module GPIO pour le DomoTab et le DTPlug.

<div style="clear:both"> </div>
* [[Products/LPC1224BO|LPC1224 Break-Out]]
[[Image:LPC1224-BO.jpg|60px|left]]
: La carte de développement LPC1224 Break-Out : un module de développement autonome (un port USB suffit) pour le microcontrôleur LPC1224 de NXP (ARM Cortex-M0).

<div style="clear:both"> </div>
* [[Products/LPC1224mbed|LPC1224-mbed]]
[[Image:LPC1224-mbed.jpg|60px|left]]
: La carte de développement LPC1224-mbed : une version "mbed ready du module de développement autonome pour le microcontrôleur LPC1224 de NXP (ARM Cortex-M0).

<div style="clear:both"> </div>
* [[Products/USB_UART|Adaptateur USB-UART]]
[[Image:USBtoUART.jpg|100px|left]]
: Adaptateur USB vers UART, et potentiellement UEXT.

<div style="clear:both"> </div>
== Modules de communication ==
* [[Products/Module_RFSub1G|Module RF Sub-1GHz]]
[[Image:Module_RFSub1G.jpg|100px|left]]
: Le module RF, version Standalone, USB, ou UEXT

<div style="clear:both"> </div>
* [[Products/Module_1Wire|Module 1Wire]]
[[Image:Module_1Wire.jpg|100px|left]]
: Module 1Wire au format UEXT.

<div style="clear:both"> </div>
* [[Products/Module_RS485|Module RS485]]
[[Image:Module_RS485.jpg|100px|left]]
: Module RS485 au format USB, UEXT et Standalone.

<div style="clear:both"> </div>
* [[Products/Module_KNX|Module KNX]]
[[Image:Module_KNX.jpg|100px|left]]
: Module KNX (filaire) au format USB, UEXT et Standalone.

<div style="clear:both"> </div>
* [[Products/Module_DMX|Module DMX]]
[[Image:Module_DMX.jpg|100px|left]]
: Module DMX (filaire) au format USB, UEXT et Standalone.

<div style="clear:both"> </div>
* [[Products/Module_CPL|Module CPL]]
[[Image:Module_CPL.jpg|100px|left]]
: Module CPL (Courant porteur) au format USB, UEXT et Standalone.

<div style="clear:both"> </div>
== Projet "DomoTab" ==
* [[Products/DTPlug|Le DTPlug]]
[[Image:DTPlug.png|100px|left]]
: Passerelle DTPlug : Ethernet ---> 4x UEXT

<div style="clear:both"> </div>
* [[Products/PSMC|Module PSMC : Power Supply Monitor & Control]]
[[Image:PSMC.jpg|100px|left]]
: Module PSMC pour alimentation d'un module de communication, mesure de courant (consommation) et contrôle d'une prise (Nécessite un module de communication pour fonctionner).

<div style="clear:both"> </div>
== Adaptateurs divers ==
* [[Products/Adaptateur_Thermocouple|Adaptateur Thermocouple]]
[[Image:Adaptateur_Thermocouple.jpg|100px|left]]
: Adaptateur Thermocouples pour mesure de température (nécessite un module de communication pour fonctionner).

Products

2020-09-03T02:48:13Z

Nathael :

{{DISPLAYTITLE:Liste des produits}}
== Projet "Scialys" ==
* [[Products/Scialys|Module Scialys]]
[[Image:Module_Scialys.jpg|100px|left]]
: Le module principal du système Scialys : gestion de l'auto-consommation.

<div style="clear:both"> </div>
== Modules de développement ==
* [[Products/Module_GPIO_Demo|Module GPIO Démo]]
[[Image:Module_GPIO_Demo.jpg|100px|left]]
: Le module GPIO pour le DomoTab et le DTPlug.

<div style="clear:both"> </div>
* [[Products/LPC1224BO|LPC1224 Break-Out]]
[[Image:LPC1224-BO.jpg|60px|left]]
: La carte de développement LPC1224 Break-Out : un module de développement autonome (un port USB suffit) pour le microcontrôleur LPC1224 de NXP (ARM Cortex-M0).

<div style="clear:both"> </div>
* [[Products/LPC1224mbed|LPC1224-mbed]]
[[Image:LPC1224-mbed.jpg|60px|left]]
: La carte de développement LPC1224-mbed : une version "mbed ready du module de développement autonome pour le microcontrôleur LPC1224 de NXP (ARM Cortex-M0).

<div style="clear:both"> </div>
* [[Products/USB_UART|Adaptateur USB-UART]]
[[Image:USBtoUART.jpg|100px|left]]
: Adaptateur USB vers UART, et potentiellement UEXT.

== Modules de communication ==
<div style="clear:both"> </div>
* [[Products/Module_RFSub1G|Module RF Sub-1GHz]]
[[Image:Module_RFSub1G.jpg|100px|left]]
: Le module RF, version Standalone, USB, ou UEXT

<div style="clear:both"> </div>
* [[Products/Module_1Wire|Module 1Wire]]
[[Image:Module_1Wire.jpg|100px|left]]
: Module 1Wire au format UEXT.

<div style="clear:both"> </div>
* [[Products/Module_RS485|Module RS485]]
[[Image:Module_RS485.jpg|100px|left]]
: Module RS485 au format USB, UEXT et Standalone.

<div style="clear:both"> </div>
* [[Products/Module_KNX|Module KNX]]
[[Image:Module_KNX.jpg|100px|left]]
: Module KNX (filaire) au format USB, UEXT et Standalone.

<div style="clear:both"> </div>
* [[Products/Module_DMX|Module DMX]]
[[Image:Module_DMX.jpg|100px|left]]
: Module DMX (filaire) au format USB, UEXT et Standalone.

<div style="clear:both"> </div>
* [[Products/Module_CPL|Module CPL]]
[[Image:Module_CPL.jpg|100px|left]]
: Module CPL (Courant porteur) au format USB, UEXT et Standalone.

== Projet "DomoTab" ==
* [[Products/DTPlug|Le DTPlug]]
[[Image:DTPlug.png|100px|left]]
: Passerelle DTPlug : Ethernet ---> 4x UEXT

<div style="clear:both"> </div>
* [[Products/PSMC|Module PSMC : Power Supply Monitor & Control]]
[[Image:PSMC.jpg|100px|left]]
: Module PSMC pour alimentation d'un module de communication, mesure de courant (consommation) et contrôle d'une prise (Nécessite un module de communication pour fonctionner).

== Adaptateurs divers ==
<div style="clear:both"> </div>
* [[Products/PiSerialPower|Adaptateur "PiSerialPower"]]
[[Image:PiserialPower.jpg|100px|left]]
: Adaptateur d'alimentation et de debug pour cartes RaspberryPi (et modèles concurrents compatibles).

<div style="clear:both"> </div>
* [[Products/Adaptateur_Thermocouple|Adaptateur Thermocouple]]
[[Image:Adaptateur_Thermocouple.jpg|100px|left]]
: Adaptateur Thermocouples pour mesure de température (nécessite un module de communication pour fonctionner).

Fichier:Module Scialys.jpg

2020-09-03T02:47:07Z

Nathael :

Products/LPC1224mbed

2020-09-03T01:06:42Z

Nathael : Page créée avec « {{DISPLAYTITLE:LPC1224-mbed dev board}} right == Description == The LPC1224-mbed board is a clone of our LPC1224-BO board with the FTDI U... »

{{DISPLAYTITLE:LPC1224-mbed dev board}}
[[Image:LPC1224-mbed.png|300px|right]]

== Description ==
The LPC1224-mbed board is a clone of our LPC1224-BO board with the FTDI USB-to-UART bridge replaced by an LPC11U35 micro-controller in order to comply with mbed hardware platform requirements.

The LPC11U35 has an USB device interface and is connected to both the UART and the SWD interfaces of the LPC1224 micro-controller.

This allows drag-and-drop programming as the board will enumerate as a mass storage device on a host when the target micro-controller is put in ISP mode.

== How-To ==
To be written.

== TODO List ==
* Assemble first prototype
* Tests
* Submit to mbed
* Technical Documentation

== Technical documentation ==
The technical documentation is not yet available.

== History ==

Fichier:Module RFSub1G.jpg

2020-09-03T01:05:33Z

Nathael :

Fichier:DTPlug.png

2020-09-03T01:04:59Z

Nathael :

Fichier:LPC1224-BO.jpg

2020-09-03T01:04:21Z

Nathael :

Fichier:Module GPIO Demo.jpg

2020-09-03T01:03:03Z

Nathael :

Fichier:USBtoUART.jpg

2020-09-03T01:02:00Z

Nathael :

Products/USB UART

2020-09-03T00:59:55Z

Nathael : Page créée avec « {{DISPLAYTITLE:Adaptateur USB-UART}} right == Description == L'adaptateur USB-UART est un adaptateur simple et utile donnant accès à une l... »

Products/Module GPIO Demo

2020-09-03T00:58:59Z

Nathael : Page créée avec « {{DISPLAYTITLE:Module GPIO Démo}} right == Description == === Hardware === ==== Dimensions ==== ==== Connecteurs ==== * Connecteur P... »

{{DISPLAYTITLE:Module GPIO Démo}}
[[Image:Module_GPIO_Demo.jpg|300px|right]]

== Description ==
=== Hardware ===
==== Dimensions ====
==== Connecteurs ====
* Connecteur P1
* Connecteur P2
* Connecteur P3
* Connecteur P4
* Connecteur P5
* Connecteur P6 et P7
* Connecteur P8
==== Jumpers ====
* Jumper J1
* Jumper J2
* Jumper J3 et J4
=== Electronique ===
==== Micro-contrôlleur LPC1224 ====
==== RAM interne ====
==== Mémoire Flash interne ====
==== Interfaces de communication ====
==== GPIO ====
==== ADC ====
==== Reset et mode ISP ====
==== I²C ====
* Adresses I²C
* EEPROM externe
* Capteur de température
==== Boutons et Led utilisateur ====
==== Bridge USB-UART ====
=== Logiciel ===
==== Récupération des sources ====
==== Organisation des sources ====
==== Point d'entrée ====
==== Exemples ====
==== Compilation ====

== Utilisation ==
== TODO List ==
== Documentation Technique et Schémas ==
== Historique ==

Articles/Nathael

2020-09-03T00:56:48Z

Nathael : Page créée avec « * Electronique libre et DomoTab : conception d'un module électronique avec Kicad ** Kicad Reference Card ** Articles/... »

* Electronique libre et DomoTab : conception d'un module électronique avec Kicad
** [[Articles/Nathael/Domotab_et_elec_Libre_RefCard|Kicad Reference Card]]
** [[Articles/Nathael/Domotab_et_elec_Libre_partie1|Partie 1: Module de développement - Schéma]]
** [[Articles/Nathael/Domotab_et_elec_Libre_partie2|Partie 2: Module de développement - Schéma - Interfaces pour la programmation et l'identification]]
** [[Articles/Nathael/Domotab_et_elec_Libre_partie3|Partie 3: Du schéma au PCB]]
** [[Articles/Nathael/Domotab_et_elec_Libre_partie4|Partie 4: Un module en vrai, FabLab et fabrication maison]]
** [[Articles/Nathael/Domotab_et_elec_Libre_partie5|Partie 5: Programmation : premiers signes de vie]]
** [[Articles/Nathael/Domotab_et_elec_Libre_partie6|Partie 6: Programmation : échanges de données]]
** [[Articles/Nathael/Domotab_et_elec_Libre_partie7|Partie 7: Modification : station météo]]
** [[Articles/Nathael/Domotab_et_elec_Libre_partie8|Partie 8: Modification : commande d'une lampe]]
** [[Articles/Nathael/Domotab_et_elec_Libre_partie9|Partie 9: Debug]]

Articles/Dindinx

2020-09-03T00:56:30Z

Nathael : Page créée avec « * Réalisation de jeux sur LPC1224/SSD1306 (ARM Cortex-M0) * Pacman * Tetris »

* Réalisation de jeux sur LPC1224/SSD1306 (ARM Cortex-M0)
* [[Articles/Dindinx/Pacman|Pacman]]
* [[Articles/Dindinx/Tetris|Tetris]]

Utilisateur:Nathael

2020-09-02T23:23:49Z

Nathael : Page créée avec « Test »

Test

Utilisateur:Cyprien

2020-09-02T23:22:14Z

Nathael : Page vide créée

Articles/Nathael/Domotab et elec Libre partie5

2020-09-02T22:08:24Z

Nathael : /* Un peu de place pour la pile */

{{DISPLAYTITLE:Électronique et domotique libre - partie 5 : Programmation, Premiers signes de vie}}
<div style="float:left; margin-right: 2.5em;">__TOC__</div>

[[Image:DomoTab.png|200px|right]]
Programmation du module !

Nous avons vu dans le quatrième article comment fabriquer le module GPIO-Démo (ou toute version modifiée), nous allons désormais nous atteler à lui donner vie.

'''Note 1''' : La programmation sera faite en C, bien que d'autres langages puissent être utilisés, à la seule condition qu'il existe un compilateur qui puisse générer du code binaire pour ARM à partir de ce langage.

'''Note 2''' : Les tailles indiquées dans cet article dépendent de la version de GCC utilisée, et il est presque certain que vous obtiendrez des tailles différentes, comme par exemple une taille de 256Mo, un cas que j'ai eu fréquement en TP quand le compilateur créé la section data pour le bloc de données placé en RAM, à l'adresse 0x10000000, soit 256Mo.

<div style="float:right">par Nathael Pajani</div>

<div style="clear:right"> </div>
Paru dans le [http://boutique.ed-diamond.com/home/851-open-silicium-14.html numéro 14] du magazine Open Silicium.

<div style="clear:both"> </div>

== Les documentations techniques ==

La première étape lorsqu'on veut écrire du code pour un système embarqué qui utilise un micro-contrôleur, c'est d'en trouver la documentation technique.

L'accès aux documentations techniques est à mon avis un des critères principaux dans le choix des composants pour un projet, aussi bien pour les concepteurs que pour les utilisateurs.

Si vous avez réalisé la conception du circuit, vous aurez normalement déjà eu besoin de ces documentations, dans le cas contraire, c'est le moment de les récupérer.
Pour le module GPIO-Démo, il y a plusieurs documentations techniques nécessaires pour utiliser la totalité des fonctionnalités du module.
La première et la plus importante est celle du micro-contrôleur [7], mais vous aurez aussi besoin de celle du module, disponible sur le site de Techno-Innov [4], et de celles de l'EEPROM I2C, et du capteur de température I2C.

Encart : Pour ce qui est du bridge USB-UART, la documentation n'est pas nécessaire pour la programmation du micro-contrôleur et du module, mais elle le devient si vous voulez modifier la façon dont le composant s'identifie lorsque vous le connectez, par exemple pour pouvoir lui donner un nom spécifique ou simplifier l'identification. Cela ne sera cependant pas le sujet de cet article.

Pour récupérer les documentations techniques, vous avez le choix entre le site du fabriquant et celui du distributeur chez qui vous avec acheté les composants. Pour la majorité des composants j'utilise le site du distributeur (possible uniquement si il fourni les bonnes documentations), mais pour les micro-contrôleurs je consulte le site du fabriquant car il fourni aussi les "errata" (notes d'informations contenant les corrections sur la documentation) et le plus souvent des notes d'application qui indiquent comment utiliser le composant pour telle ou telle application (avec parfois des exemples de code).

== Outils de programmation ==

La deuxième étape ne concerne toujours pas le code que vous voulez écrire.

En effet, pour écrire du code vous n'avez pas besoin de la "cible" (target en anglais) qui est le matériel sur lequel vous allez exécuter la version compilée du code, mais uniquement d'un poste de développement, couramment appelé hôte (host en anglais).

Cependant, la cible en question n'a que faire des fichiers sources qui se trouvent sur votre poste de développement, et il vous faudra un certain nombre d'outils pour passer des fichiers source (quelque soit le langage) au code exécutable par votre carte électronique.

C'est aussi un point très important à mon sens dans le choix d'un système embarqué ou d'un micro-contrôleur : quels sont les outils dont j'aurais besoin pour passer de mon code source à un système fonctionnant avec ?

Dans le cas des micro-contrôleurs de la gamme LPC de NXP il existe de nombreuses solutions pour passer de l'un à l'autre, mais ce qui est intéressant à mon sens c'est qu'il est possible de le faire avec un minimum de matériel et de logiciel : une liaison série "TTL 3.3V", une chaîne de compilation croisée et un utilitaire pour "uploader" le code binaire.

=== Matériel : un port USB (et le PC qui va avec) ===

[[Image:14-Module sur USB.png|300px|right]]

Pour ce qui est de la liaison série "TTL 3.3V", il existe plein d'adaptateurs USB-UART fonctionnant en 3.3V, et pour le cas du module GPIO-Démo cet adaptateur est intégré sur le module, un port USB suffit donc.

L'accès à cette liaison série se fera via un fichier spécial dont le nom sera devrait ressembler à "/dev/ttyUSB0", le "USB0" pouvant différer selon votre système ("USB1", USB2", ... ou même "ACM0" avec d'autres adaptateurs).

=== Compilation : GNU ===

Pour ce qui est de la chaîne de compilation croisée, les micro-contrôleurs LPC de NXP utilisent des cœurs ARM Cortex-M*, très bien supportés par gcc, bien connu de tous les lecteurs de ce magazine (du moins je le pense), et parfaitement adapté à la cross-compilation.

Dit comme ça, c'est simple ... mais en fait, pas tant que ça.
Cette problématique pourrait faire l'objet d'un (petit ?) article, je ne l'inclurai donc pas ici, je vous donne juste quelques pistes et suppose que vous saurez trouver les informations sur le net. De mon côté je dois les intégrer à la documentation technique du module GPIO-Démo, mais ce n'est pas encore fait à l'heure où j'écris ces lignes :( [4].

Si vous n'avez pas déjà une chaîne de cross-compilation installée pour ARM vous avez globalement trois solutions : Debian/EmDebian (celle que j'utilise), Launchpad, et Crosstools-ng.

Le projet EmDebian fournit des paquets debian pour différentes chaînes de cross-compilation (ARM parmi tant d'autres), qui sont entrain d'être intégrées à Debian. Cela devrait simplifier les problèmes de dépôts et de dépendances dont souffrait les dépôts EmDebian, même si seule la version "arm-none-eabi" (qui nous suffit, nous n'avons pas besoin de libC) est actuellement intégrée dans SID sans problèmes de dépendances (j'ai bien dit "devrait").

Le site de Launchpad fourni aussi des versions binaires de la chaîne de cross-compilation GCC ARM.

La solution CrossTools-ng : recompilation de sa propre chaîne de compilation croisée : la solution du dernier recours, si votre distribution ne fournit pas de solution packagée et que les versions binaires non signées ne vous conviennent pas.

=== Programmation : lpctools (ou autre) ===

Enfin, pour ce qui est de l'utilitaire permettant de charger (uploader) le code binaire sur le micro-contrôleur (flasher le micro-contrôleur), je n'avais pas trouvé d'outil libre permettant de réaliser cette étape au moment où j'ai étudié la possibilité d'utiliser les micro-contrôleurs de NXP, mais le protocole série permettant de réaliser cette opération était documenté dans la documentation technique des micro-contrôleurs, il ne devait donc pas y avoir de problème de ce côté là.

La seule solution "gratuite" que j'avais trouvé à l'époque ne fonctionnait que sur un seul système (pas le miens), ne fournissait pas ses sources, et interdisait une utilisation commerciale sans payer une licence, hors je voulais justement en faire une utilisation commerciale.

J'ai donc pris quelques heures de mon temps pour coder un utilitaire permettant de programmer les micro-contrôleurs LPC, et placé le tout sous licence GPL v3 [5].
Le tout est désormais disponible sur le site de Techno-Innov, et est intégré depuis peu à la distribution Debian GNU/Linux (Sid et Jessie à l'heure de l'écriture de ces lignes).

J'ai entre-temps découvert d'autres projets permettant de programmer des micro-contrôleurs LPC, mais je ne les ai pas testés (nxpprog - licence MIT, mxli - GPLv3, pyLPCTools - GPLv2) et constaté qu'un autre paquet Debian fournit les outils permetant de programmer les micro-contrôleurs LPC de NXP : lpc21isp (qui dispose d'ailleurs d'une interface graphique : GLPC, qui elle n'est pas dans les dépôts). Voir liens [6] en fin d'article.

== Makefile - particularités pour la compilation croisée ==

Une dernière petite étape avant d'écrire notre code, bien que l'on se rapproche de la programmation, puisqu'il s'agit d'un élément essentiel de tout projet : la création du Makefile.

Dans le cas de la compilation pour une cible comme le module GPIO-Démo le Makefile doit inclure quelques éléments supplémentaires que l'on ne retrouve habituellement pas dans un Makefile classique.

Le premier élément concerne la définition du compilateur à utiliser. Nous utiliserons la variable "CROSS_COMPILE" à laquelle nous affecterons une valeur par défaut correspondant au préfixe du compilateur. Si vous voulez utiliser un compilateur correctement installé sur le système, il suffit d'utiliser le préfixe, sinon, il faudra ajouter devant la totalité du chemin donnant accès au compilateur.

Par exemple pour le compilateur EmDebian :
: CROSS_COMPILE ?= arm-linux-gnueabi-
ou avec un chemin complet pour un autre compilateur :
: CROSS_COMPILE ?= /usr/local/mon/compilateur/bin/arm-none-eabi-

Le "?=" permet de ne modifier la variable que si elle n'existe pas, notamment si elle n'est pas déjà présente dans la ligne de commande.

Cette variable est ensuite utilisée pour modifier la variable "CC" utilisée par "make" pour compiler les fichiers de code source C. Si vous utilisez un autre langage, modifiez la variable correspondante.
: CC = $(CROSS_COMPILE)gcc
Il est aussi possible d'en profiter pour spécifier une version du compilateur installé :
: CC = $(CROSS_COMPILE)gcc-4.7
Nous allons en profiter pour définir la variable "LD" qui correspond à l'éditeur de liens (linker en anglais) :
: LD = $(CROSS_COMPILE)ld

Il nous faut ensuite définir la cible pour laquelle nous voulons compiler. Dans notre cas il s'agit d'un cœur ARM Cortex-M0, qui utilise le jeu d'instructions "thumb" (instructions sur 16bits permettant d'obtenir un code plus compact), nous allons donc utiliser les options -mcpu et -mthumb de gcc pour lui indiquer notre besoin :
: CPU = cortex-m0
: CFLAGS = -Wall -mthumb -mcpu=$(CPU)

En plus de cela, nous allons demander au compilateur de ne pas reconnaître les fonctions pour lesquelles il a une définition interne (builtin) tout simplement parce que la majorité de ces fonctions dépendent d'un environnement très différent de celui de notre micro-contrôleur, soit par la présence d'une bibliothèque C, d'un système d'exploitation respectant la norme POSIX, ou d'une unité de calcul flottant.
Rien de tout ceci n'est vrai dans notre cas, et il est donc préférable que le compilateur nous informe si nous tentons d'utiliser ces fonctions sans l'avoir explicitement demandé en utilisant le préfixe "__builtin__".

Nous demanderons aussi au compilateur de bien placer les données et les fonctions dans leurs sections respectives. Malgré ce que dit la documentation de GCC, cela permet (au moins dans notre cas) de produire un binaire plus petit. Cela se fait à l'aide des directives d'optimisation "-ffunction-sections" et "-fdata-sections".

Nous ajouterons ces directives dans une variable dédiée :
: FOPTS = -fno-builtin -ffunction-sections -fdata-sections

Nous obtenons donc les lignes suivantes à ajouter à votre Makefile :
: CROSS_COMPILE ?= arm-linux-gnueabi-
: CC = $(CROSS_COMPILE)gcc
: LD = $(CROSS_COMPILE)ld
: CPU = cortex-m0
: FOPTS = -fno-builtin -ffunction-sections -fdata-sections
: CFLAGS = -Wall -Wextra -mthumb -mcpu=$(CPU) $(FOPTS)

Notre Makefile ressemblerait alors à ceci :
NAME = mod_gpio
CROSS_COMPILE ?= arm-linux-gnueabi-
CC = $(CROSS_COMPILE)gcc
LD = $(CROSS_COMPILE)ld
CPU = cortex-m0
FOPTS = -fno-builtin -ffunction-sections -fdata-sections
CFLAGS = -Wall -Wextra -mthumb -mcpu=$(CPU) $(FOPTS)

.PHONY: all
all: $(NAME)

SRC = $(wildcard *.c)
OBJS = $(SRC:.c=.o)

$(NAME): $(OBJS)
$(LD) $^ -o $@
Ce Makefile est encore incomplet et ne permet pas d'obtenir le binaire pour notre micro-contrôleur, mais nous ajouterons les parties manquantes plus tard.

En attendant, ce Makefile nous permettra de compiler le code que nous allons écrire, passons donc aux parties intéressantes, et le reste du Makefile sera bien plus simple à comprendre.

== Commençons simple ==

Pour ne pas trop compliquer les choses dès le début, nous allons tenter de faire clignoter la led bicolore présente sur le module GPIO-Démo.

Notre squelette de code ressemblera à s'y méprendre à ce que l'on pourrait avoir pour un programme plus commun :
/*
* Notre exemple simple pour Open Silicium
*/
void system_init(void)
{
/* System init ? */
}

int main(void)
{
/* Micro-controller init */
system_init();

while (1) {
/* Change the led state */
/* Wait some time */
}
return 0;
}
Si vous compilez ce petit morceau de code avec notre Makefile, vous obtiendrez un binaire qui globalement ne fait rien, mais a déjà une taille de 5.7 Ko.
C'est gros pour ne rien faire, d'autant que la mémoire Flash de notre micro-contrôleur ne fait que 32 Ko.

Si on regarde plus loin, par exemple avec l'utilitaire ''file'', on obtient quelques informations supplémentaires :
$ file mod_gpio
mod_gpio: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), [....], not stripped

Arghhh, notre binaire est un exécutable dynamique au format ELF, qui utilise des bibliothèques partagées !

Nous l'avons déjà évoqué, notre micro-contrôleur n'a pas de libC ni de système d'exploitation, notre binaire ne peut donc pas être dynamique (lié dynamiquement à des bibliothèques) !
Il nous faut donc faire l'édition de lien en "static", en apportant quelques modification à notre Makefile. Nous allons introduire une variable "LDFLAGS", que l'on ajoutera à la règle de compilation utilisée pour l'édition de liens.
LDFLAGS = -static
$(NAME): $(OBJS)
$(LD) $^ $(LDFLAGS) -o $@
Recompilons notre projet ... 608 Ko !!! Re-Argh !

Visiblement quelqu'un ajoute du code dont nous n'avons pas besoin. Il faut du moins l'espérer, sinon il ne sera jamais possible de faire rentrer un programme dans la flash de notre micro-contrôleur, qui fait toujours 32Ko.

L'option "static" demande à l'éditeur de lien de créer un binaire statique, mais résultat il nous ajoute tout ce qui est utile de la libC pour un exécutable ... pour un système Linux.
D'ailleurs, ''file'' nous dit bien que notre exécutable est au format ELF.

Pour commencer nous allons demander à l'éditeur de liens (ld) de ne pas inclure les éléments de démarrage dans notre binaire, car ils sont inutiles sur notre micro-contrôleur. Pour cela nous ajoutons l'option "-nostartfiles" à nos directives pour l'édition de liens.

Et hop, une recompilation plus tard, notre binaire ne fait plus que 1 Ko :)
Mais pour ''file'', ce binaire est toujours au format ELF, et gcc nous informe qu'il n'a pas trouvé de symbole d'entrée "_start" et qu'il utilise une adresse par défaut (nous l'avons cherché, cela fait partie de ce que nous avons demandé à l'éditeur de liens en ajoutant l'option "-nostartfiles").

En effet, le "main" de nos programmes en C n'est que le point de départ de l'exécution de notre code, mais pas celui du programme. Il est précédé par un certain nombre de routines (fonctions) d'initialisation, dont le point d'entrée est la routine "_start", qui appellera le main "classique".

Mais notre but n'est pas de créer un exécutable pour un système Linux, nous devons créer un binaire pour notre micro-contrôleur. Il est désormais temps de nous plonger dans la documentation du micro-contrôleur pour comprendre comment il démarre, pour pouvoir adapter notre code au démarrage du micro-contrôleur et fournir l'équivalent de cette routine "_start".

== Bootstrap ==

=== Table des vecteurs d'interruption ===

Pour avoir des informations sur le démarrage du micro-contrôleur LPC1224 dans sa documentation technique [7] il y a deux chapitres intéressants.

Nous pouvons nous référer au chapitre 4 (LPC122x System control) qui inclut une section sur le reset du micro-contrôleur (4.6 : Reset), dans laquelle on apprend qu'une fois que la condition de reset disparait et que les procédures internes se sont exécutées, le processeur commence l'exécution à l'adresse contenue dans le vecteur "Reset" du "boot block".

Nous avons ainsi quelques informations, mais qu'est-ce que le vecteur "Reset" et le "boot block" ? Cela nous mène au deuxième chapitre intéressant, le chapitre 25 sur le cœur ARM Cortex-M0. On y trouve une section sur le processeur (25.3 : Processor) avec une sous section concernant les exeptions (25.3.3 : Exception model).

Dans les informations sur les exceptions (25.3.3.2), et plus particulièrement l'exception "Reset", il est indiqué qu'après un "Reset" l'exécution reprend à l'adresse indiquée dans le vecteur "Reset" dans la table des vecteurs d'interruption.

Bien, cela confirme ce qui se trouvait dans le chapitre 4. Mais cette fois, nous avons une sous-section "25.3.3.4 Vector table", qui décrit cette fameuse table des vecteurs d'exception, précisant qu'elle contient l'addresse de toutes les routines de gestion des exceptions (les fameux "vecteurs" d'exception, dont le vecteur "Reset").

Remarquez au passage que les interruptions sont gérées de la même façon, l'addresse d'entrée des routines de gestion des interruptions se trouve dans cette même table.

Et en dessous de cette table, nous avons une autre information très intéressante : "The vector table is fixed at address 0x00000000".

Si l'on se réfère à la table 65 de la section "25.3.2 Memory model", et à la figure 2 de la section "2.3 Memory allocation", on découvre que cette adresse est en fait le début de la mémoire flash du micro-contrôleur, qui devra contenir notre code binaire.

Reste à créer cette table, et à la placer au bon endroit dans le code binaire compilé...

=== Les "handlers" et les "dummy handlers" ===

Nous allons commencer par la partie code.
Ce code peut être placé dans le même fichier que celui ou ce trouve notre fonction main, ou dans un autre fichier, cela n'a pas d'importance. Si vous vous référez au code du module GPIO-Démo disponible dans les dépôts git de Techno-Innov, vous trouverez ce code dans le fichier "core/bootstrap.c".

[[Image:Vecteurs_interruption.png|350px|right]]

/* Cortex M0 core interrupt handlers */
void Reset_Handler(void);
void NMI_Handler(void) __attribute__ ((weak, alias ("Dummy_Handler")));
void HardFault_Handler(void) __attribute__ ((weak, alias ("Dummy_Handler")));

void Dummy_Handler(void);

void *vector_table[] = {
0,
Reset_Handler,
NMI_Handler,
HardFault_Handler,
0,
/* [......] */
};

void Dummy_Handler(void) {
while (1);
}

void Reset_Handler(void) {
/* Our program entry ! */
}

Voici un petit morceau de code relativement court qui définit notre table de vecteur ainsi que les routines de gestion correspondantes.

Avant d'aller plus loin, faisons un petit point sur certains éléments : les attributs utilisés pour la déclaration de deux de nos routines de gestion des exceptions : "__attribute__ ((weak, alias ("Dummy_Handler")))"

Ces attributs permettent de définir un alias "faible" pour une fonction, ce qui veut dire que si le compilateur ne trouve pas de définition pour cette fonction, il pourra utiliser son alias, que nous avons défini plus bas. Au contraire, si dans un autre fichier (ou celui-ci) vous définissez l'une de ces fonctions, c'est votre définition qui sera utilisée.

Note : je n'ai pas mis la totalité de la table des vecteurs, cela n'a pas d'intérêt pour les explications, et notre programme fonctionnera sans, mais il faudrait la compléter pour un vrai programme, en faisant attention à l'ordre, à partir des informations de la figure 68 déjà évoquée, et de la table 4 du chapitre 3 concernant le gestionnaire d'interruptions (vous noterez la typo, il s'agit des numéros d'IRQ et non pas des numéros des vecteurs d'exception).

=== Appeler notre main() ===
Ce petit bout de code compile donc, puisque tout est défini, mais nous avons toujours l'avertissement concernant le symbole d'entrée "_start" qui n'a pas été trouvé. Nous ne sommes pas plus avancé.

Tout d'abord, nous avons déjà indiqué que le point d'entrée de notre code est la fonction main() (qui pourrait avoir n'importe quel nom), mais pour notre micro-controlleur la fonction d'entrée du programme est la routine de gestion de l'exception "Reset".

La solution pour faire le lien est toute simple : il suffit d'appeler la fonction main() depuis la routine de gestion de l'exception "Reset".
int main(void);
void Reset_Handler(void) {
/* Our program entry ! */
main();
}

=== Tisser des liens, c'est important ===
Cela ne résout cependant aucun de nos problèmes, nous allons donc devoir donner plus d'indications à l'éditeur de liens, en créant un script pour l'édition de lien (lpc_link_lpc1224.ld). Nous donnerons le nom de ce script à l'éditeur de liens en utilisant l'otion "-T''lpc_link_lpc1224.ld''".

Ce script d'édition de lien ("linker script" en anglais) est en fait un fichier qui décrit la mémoire de notre micro-contrôleur, ainsi que l'organisation que devra respecter notre binaire.

Nous allons donc commencer, toujours à partir des mêmes informations en provenance de la documentation technique, par définir quelle est la mémoire disponible, aussi bien la mémoire "vive" (SRAM) que la mémoire "morte" (FLASH).

MEMORY
{
sram (rwx) : ORIGIN = 0x10000000, LENGTH = 4k
flash (rx) : ORIGIN = 0x00000000, LENGTH = 32k
}
Nous définissons ainsi l'adresse et la taille (et les droits d'accès) de la sram et de la flash, qui deviennent deux blocs de mémoire disponibles pour l'éditeur de liens, qui pourra donc y placer du code et des données.

Il nous faut maintenant expliquer à l'éditeur de liens comment organiser le code et les données dans ces blocs de mémoire, et tout particulièrement notre tableau de vecteurs d'interruptions

Le code d'un programme est composé de "sections", dans lesquelles le compilateur place chaque fonction et chaque variable en fonction de différents critères, que l'on peut contrôler soit à partir de directives de compilation, soit d'attributs ajoutés dans notre code C

Nous allons donc modifier notre tableau de vecteurs d'interruptions pour lui ajouter un attribut "section" qui forcera l'éditeur de liens à le placer dans la section que nous avons défini.
: void *vector_table[] __attribute__ ((section(".vectors"))) = {

Et en parallèle, nous allons définir dans notre script quelles sont les sections que nous voulons trouver dans notre binaire, et dans quel ordre.
Commençons simple (si si, je vous assure), nous compliquerons plus tard :
SECTIONS {
. = ORIGIN(flash);
.text :
{
KEEP(*(.vectors))
*(.text*)
*(.rodata*)
} >flash
.data :
{
*(.data*)
*(.bss*)
} >sram
}
Pour commencer, nous définissons l'adresse courante (.) comme étant l'origine de du bloc de mémoire "flash" (le bloc de mémoire défini précédemment et auquel nous avons donné ce nom, bien qu'un autre nom aurait pu faire l'affaire).
Ceci est important pour que l'éditeur de liens puisse définir les adresses des fonctions pour l'exécution de notre code.
À partir de ce point nous définissons une section "text", dans laquelle nous allons demander à l'éditeur de lien de mettre plusieurs éléments, à commencer par notre fameuse table de vecteurs, en lui interdisant d'en changer la position !
Après quoi, nous lui demandons de placer l'ensemble du code, que le compilateur a placé dans des section ".text.*", puis les données en lecture seule (Read-Only data = rodata), et de placer le tout dans le bloc de mémoire "flash".

À la suite, nous créons une section "data", dans laquelle nous lui demandons de placer les données initialisées à des valeurs non nulles (data), puis les données initialement nulles (bss [8]), et de placer cette section en RAM.

Ne reste plus qu'une information à donner à l'éditeur de liens (pour l'instant): le point d'entrée de notre programme.
Ceci est relativement simple et explicite :
: ENTRY(Reset_Handler)

Dans notre Makefile la variable LDFLAGS devient :
: LDFLAGS = -static -nostartfiles -Tlpc_link_lpc1224.ld

Une compilation plus tard, sans avertissements cette fois, nous avons un binaire ... beaucoup trop gros : notre binaire fait maintenant plus de 66 Ko !

Soyons un peu curieux et allons donc voir ce qu'il contient, mais pas à la main, rassurez vous, utilisons un utilitaire fait exprès pour cela : ''objdump''. attention, il faut bien entendu utiliser la version "ARM" de objdump, donc avec le préfixe "CROSS_COMPILE", soit dans mon cas ''arm-linux-gnueabi-objdump'', avec l'option ''--disassemble-all'' (-D) :
: arm-linux-gnueabi-objdump -D mod_gpio > dump
Et là, surprise, la version "désassemblée" de notre binaire est plus petite que la version binaire (le fichier "dump" fait 2.2 Ko).

Regardons tout de même son contenu.
La première ligne nous informe que le format du fichier est "elf32-littlearm" ... pas grand chose à voir avec ce que nous voulions, un "simple" binaire (Notre micro-contrôleur n'a toujours pas appris à lire les exécutables au format ELF). Premier problème.

Quelqu'un est venu glisser une section ".note.gnu.build-id" avant notre section ".text", que l'éditeur de liens aimerait placer en début de RAM ("10000000 <_sram_base>"), ce qui n'a pas d'intérêt pour nous.

S'en suit tout de même notre section ".text", qui commence bien par notre table (enfin ! on nous écoute un peu !), suivie de nos quelques maigres fonctions. Notez les adresses des fonctions dans la table des vecteurs, qui sont toutes impaires. Ceci indique que notre processeur exécutera ces fonctions en mode "thumb" qui est bien le mode que nous avions demandé (-mthumb).

Et encore une fois, notre section ".text" n'est pas suivie de nos données, mais d'autres sections que nous n'avions pas demandées !
Certes, nous n'avons pas de variables, et l'éditeur de lien n'ayant rien à mettre dans notre section ".data", il ne l'a pas créée, mais au final nous sommes relativement loin de ce que nous voulions.

Nous allons donc demander à l'éditeur de liens de générer un petit peu moins de choses en ajoutant l'option ''-Wl,--build-id=none'' à nos directives de compilation (variable LDFLAGS de notre Makefile), ce qui nous donne un binaire moitié plus petit mais toujours trop gros.

=== Un binaire vraiment binaire ===
Mais nous ne pouvons pas en demander bien plus à l'éditeur de liens, dont le travail est de créer des exécutables au format ELF.
Pour créer d'autres types de binaire, nous devrons utiliser l'utilitaire ''objcopy'' (toujours la version ARM, donc en fait ''arm-linux-gnueabi-objcopy'').
Le travail de cet utilitaire est de créer des binaires à partir des exécutables ELF, en ne conservant que les sections qui nous intéressent (du moins, c'est l'usage que nous en ferons).

Nous allons demander à cet utilitaire de nous générer une image binaire à partir du résultat de notre compilation en ajoutant dans notre Makefile une cible "$(NAME).bin" qui deviendra notre cible par défaut et dépendra de la génération du fichier au format ELF :

all: $(NAME).bin

$(NAME).bin: $(NAME)
$(CROSS_COMPILE)objcopy -O binary $^ $@

Et notre objectif est enfin atteint, avec un binaire de ... 36 octets !<br />
Rappelez vous, je n'ai mis que 5 entrées dans ma table de vecteurs, soit 20 octets, suivis de quelques fonctions vides. Tout va bien.

== Un programme un peu plus utile ==

Nous allons désormais pouvoir nous occuper d'allumer nos Leds, en quelque sorte le "Hello world" de l'électronique.

=== Entrées et sorties ===
Du point de vue de notre micro-contrôleur, allumer ou éteindre une Led revient à changer l'état de la sortie correspondante.

Les entrées/sorties du microcontrôleur peuvent avoir plusieurs fonctions, mais hormis quelques exceptions elles sont par défaut configurées en entrées/sorties (GPIO (general Purpose Input Output) en anglais) avec la résistance de pull-up interne activée. Pour simplifier, nous laisserons donc cette étape de la configuration de côté pour l'instant, et reviendrons dessus lorsque nous attaquerons la programmation d'interfaces plus complexes.

: Note : Les exceptions sont les GPIO 13, 25 et 26 du port 0 (respectivement Reset, SWDIO et SWDCLK), qui permettent le reset et le debug, ainsi que quatre GPIO sur lesquelles la fonction "0" est réservée : les GPIO 30 et 31 du port 0 et les GPIO 0 et 1 du port 1.

=== Les registres ===
Pour changer l'état d'une de ces entrées/sorties, il faut commencer par la configurer en sortie, puis définir sont état.

Avant d'aller plus loin, il est important de comprendre que le processeur de notre micro-contrôleur ne voit que de la mémoire autour de lui. Il n'a pas accès directement aux signaux électriques.
Pour accéder aux fonctions spéciales comme l'état électrique d'une sortie le processeur doit donc modifier des données dans une zone mémoire spécifique, dédiée à cette sortie, que l'on appelle un registre.

Notre micro-contrôleur dispose d'un grand nombre de registres qui ont tous une taille de 32 bits, même si souvent certains bits ne sont pas utilisés (ils sont alors "réservés").
Ces registres particuliers, qui nous donnent accès aux fonctions spéciales du micro-contrôleur, comme la configuration et l'état des entrées sorties, sont accessibles chacun à une adresse fixe dans l'espace d'adressage du micro-contrôleur.

Nous avons déjà eu besoin d'informations sur cet espace d'adressage lorsque nous avons cherché des informations sur le démarrage du micro-contrôleur, il se trouve représenté sur la figure 2 dans la section "2.3 Memory allocation" du chapitre 2 (LPC122x Memory map).

L'adresse qui nous intéresse dépend du port sur lequel les leds sont connectées.
La led bicolore étant connectée sur le port 1 ce sont les registres présents à l'adresse 0x50010000 que nous devrons utiliser.
Cette adresse est aussi rappelée avec la description des registres dans le chapitre 8 (LPC122x General Purpose I/O (GPIO))

À partir de cette adresse se trouvent une série de registres permettant de contrôler les entrées/sorties du port 1. La modification du contenu de la mémoire accessible ainsi modifiera donc le comportement des entrées/sorties correspondantes ou leur état lorsqu'elles sont configurées en sortie.

Très (trop) souvent, pour accéder à ces registres, les programmeurs utilisent des définitions selon le principe suivant:
#define LPC_AHB_BASE (0x50000000UL)
#define LPC_GPIO_1_BASE (LPC_AHB_BASE + 0x10000)
#define PORT1_MASK (LPC_GPIO_1_BASE + 0x00)
#define PORT1_PIN (LPC_GPIO_1_BASE + 0x04)
#define PORT1_OUT (LPC_GPIO_1_BASE + 0x08)
/* [.....] */
Personnellement je trouve cette façon de faire très inefficace, et peu lisible (voire complètement illisible), et je préfère l'utilisation de structures.
Cela me semble beaucoup plus lisible, plus adapté pour accéder à de la mémoire qui est structurée, et apporte aussi un très net avantage lorsqu'il existe plusieurs ensembles de registres utilisant la même organisation, par exemple quand il y a plusieurs liaisons séries sur le micro-contrôleur, ou dans le cas qui nous intéresse pour l'instant, plusieurs ports d'entrées/sorties.
La définition se passe alors ainsi :
#define LPC_AHB_BASE (0x50000000UL)
#define LPC_GPIO_0_BASE (LPC_AHB_BASE + 0x00000)
#define LPC_GPIO_1_BASE (LPC_AHB_BASE + 0x10000)
/* General Purpose Input/Output (GPIO) */
struct lpc_gpio
{
volatile uint32_t mask; /* 0x00 : Pin mask, affects data, out, set, clear and invert */
volatile uint32_t in; /* 0x04 : Port data Register (R/-) */
volatile uint32_t out; /* 0x08 : Port output Register (R/W) */
volatile uint32_t set; /* 0x0C : Port output set Register (-/W) */
volatile uint32_t clear; /* 0x10 : Port output clear Register (-/W) */
volatile uint32_t toggle; /* 0x14 : Port output invert Register (-/W) */
uint32_t reserved[2];
volatile uint32_t data_dir; /* 0x20 : Data direction Register (R/W) */
/* [.....] */
};
#define LPC_GPIO_0 ((struct lpc_gpio *) LPC_GPIO_0_BASE)
#define LPC_GPIO_1 ((struct lpc_gpio *) LPC_GPIO_1_BASE)
À noter, l'utilisation du mot clé "volatile" qui interdira au compilateur d'optimiser les accès à ces registres en gardant des copies intermédiaires, forçant la lecture ou l'écriture immédiate.

Cette notation nous donne aussi l'information de la taille des données présentes à ces adresses, dans ce cas là, des valeurs sur 32 bits.

Pour l'utilisation dans le code, c'est ensuite très simple, il suffit de déclarer un pointeur vers cette structure, puis d'accéder au champ qui nous intéresse :
struct lpc_gpio* gpio1 = LPC_GPIO_1;
gpio1->out = 0;

=== Allumer les leds ===

Reste à déterminer quels sont les champs qui nous intéressent et quelles valeurs nous devons écrire dedans.
Pour configurer les pins reliées à nos Leds en sortie nous devons modifier le registre "DIR" (appelé "data_dir" dans la structure), et mettre les bits 4 et 5 à "1" puisque chaque bit de ce registre permet de configurer une des pins du port correspondant, le bit 0 pour la pin 0, le bit 1 pour la pin 1, et ainsi de suite (attention, ici les numéros de pins ne sont pas les numéros des pattes du composant).

Nous pouvons donc modifier notre main() pour obtenir le code suivant qui réalise cette opération de façon lisible, et positionne la Led verte à l'état "allumée", sans modifier l'état des autres sorties du port 1 :
/* The status LED is on GPIO Port 1, pin 4 (PIO1_4) and Port 1, pin 5 (PIO1_5) */
#define LED_RED 5
#define LED_GREEN 4
int main(void)
{
struct lpc_gpio* gpio1 = LPC_GPIO_1;
/* Micro-controller init */
system_init();
/* Configure the Status Led pins */
gpio1->data_dir |= (1 << LED_GREEN) | (1 << LED_RED);
/* Turn Green Led ON */
gpio1->set = (1 << LED_GREEN);
gpio1->clear = (1 << LED_RED);
while (1) {
/* Change the led state */
/* Wait some time */
}
}

[Encart : Décalages de bits] :
: La notation "<<" correspond à l'opérateur logique "décalage de bits vers la gauche" (">>" pour le décalage à droite). Voir l'article wikipedia sur le sujet, en Anglais, la version Française étant catastrophiquement incomplète [9].

== Mettre le code sur le micro-contrôleur : lpctools ==

Je sais que vous êtes de plus en plus impatients et que vous voulez voir le résultat de tout ceci en vrai, nous allons donc passer à la mise en flash sur le micro-contrôleur pour tester tout cela.

Je ne traiterais ici que le cas de la version 48 broches du micro-contrôleur LPC1224 (package LQFP48). A vous d'adapter si vous utilisez un autre micro-contrôleur, le principe étant très similaire pour tous les LPC de NXP. Pour les autres gammes de micro-contrôleurs, référez vous à leurs docs techniques et aux informations sur Internet.

=== Connexion ===
Si vous avez mis l'adaptateur USB-UART sur votre module comme proposé dans les articles précédents, l'étape de connexion au PC est simple, connectez votre module sur un port USB, directement ou via un câble en fonction du connecteur USB que vous avez choisi.

Sinon, il vous faudra un adaptateur USB-UART (souvent vendus comme adaptateurs USB-série) fonctionnant en 3.3V, et relier les signaux Rx et Tx aux signaux TXD0 et RXD0 correspondant à l'UART 0 du micro-contrôleur LPC1224 qui se trouvent sur le port 0, pins 1 et 2 (broches 16 et 17 du composant). Il est alors préférable d'avoir rendu ces signaux accesssibles sur un connecteur de votre choix, sans quoi il vous faudra souder des fils directement sur les pattes du micro-contrôleur ... possible, mais pas conseillé du tout).

=== Mode ISP ===

Il faut ensuite mettre le micro-contrôleur en mode programmation (ISP : "In System Programming" en anglais). Le chapitre 20 (LPC122x Flash ISP/IAP) indique qu'il faut maintenir la pin 12 du port 0 (broche 27) à l'état bas (0V) pendant au moins 3ms après avoir relaché le signal "Reset" (pin 13 du port 0, broche 28). La suite du chapitre décrit le protocole de programmation, uniquement utile si vous voulez créer votre propre utilitaire pour programmer le micro-contrôleur, ou si vous voulez réaliser des opérations très spécifiques.

Puisque nous avons placé des boutons poussoir reliant ces signaux à la masse, avec des résistance de "pull-up", cette opération est très simple : il faut appuyer sur les deux boutons en même temps, puis relacher le bouton reset avant de relacher le bouton ISP.
Lorsque tout c'est bien passé, la led bicolore doit avoir deux petits points lumineux à peine visibles dans l'obscurité (un rouge et un vert).

=== Dialogue avec le micro-contrôleur ===

La suite se passe sur le PC. Le paquet lpctools contient deux binaires : lpcisp et lpcprog.
Le premier donne accès aux opérations élémentaires du protocole de programmation, et ne nous sera pas utile. Le second permet de programmer le micro-contrôleur en utilisant une unique commande, bien que d'autres commandes permettent d'effectuer quelques opérations intéressantes.

Nous allons d'ailleurs commencer par une de ces autres opération : demander les identifiants de notre micro-contrôleur avec la commande "id".
La syntaxe des commandes lpcprog est simple, il suffit de lui passer un nom de device, que l'on passe comme argument de l'option "-d", une commande (argument de l'option "-c"), et si besoin le nom du fichier à utiliser.
Dans l'exemple suivant le module GPIO-Démo est identifié sur le poste de développement comme périphérique "ttyUSB0", nous utiliserons donc le ''device'' "/dev/ttyUSB0".
$ lpcprog -d /dev/ttyUSB0 -c id
Part ID 0x3640c02b found on line 26
Part ID is 0x3640c02b
UID: 0x2c0cf5f5 - 0x4b32430e - 0x02333834 - 0x4d7c501a
Boot code version is 6.1
La première ligne nous indique que lpcprog a reconnu le micro-contrôleur et qu'il sera donc possible de le programmer. (Si ce n'est pas le cas, vous devrez compléter le fichier de description des micro-contrôleurs).
Ensuite, lpcprog nous donne les informations propres au micro-contrôleur, à savoir son identifiant unique et la version du "boot code" qui se trouve en rom sur le micro-contrôleur.

Si vous avez un affichage similaire, tout va bien.
Sinon, vérifiez la connexion et que le micro-contrôleur est bien en mode ISP.

La programmation se fait ensuite très simplement avec la commande "flash", en ajoutant le nom du fichier binaire à envoyer.
$ lpcprog -d /dev/ttyUSB0 -c flash mod_gpio.bin
Part ID 0x3640c02b found on line 26
Flash now all blank.
Checksum check OK
Flash size : 32768, trying to flash 1 blocks of 1024 bytes : 1024
Writing started, 1 blocks of 1024 bytes ...
lpcprog se charge d'effacer la flash, de générer la somme de contrôle de l'entête et de la placer au bon endroit dans le binaire, et d'envoyer le tout au micro-contrôleur pour mise en flash.

Pour tester, il suffit d'appuyer sur le bouton Reset, et de constater qu'il ne se passe rien, ce qui n'est pas ce que nous attendions.

Il y a plusieurs problèmes.

=== Votre code s'il vous plait ! ===

Le premier vient de la génération de la somme de contrôle, ou plutôt de sa position dans notre binaire.
Tous les LPC de NXP utilisent (à ce jour de ce que j'ai pu voir) le même mécanisme pour déterminer si la flash contient une image valide avant d'essayer d'exécuter son contenu : la vérification du checksum des 8 premiers vecteurs d'interruption, qui doit être nulle.

Pour que ceci soit possible, conformément à la documentation technique des micro-contrôleurs, lpcprog calcule le complément à 2 des 7 premiers vecteurs, et le place dans le huitième.

Sauf que notre tableau ne fait pour l'instant que 5 "cases" et que la huitième case contenait en fait notre code exécutable, qui a été écrasé.

La première modification est donc de remplir au moins 8 cases de ce tableau, au pire avec des valeurs nulles, sinon, avec des valeurs correspondant à ce qui est attendu dans la documentation : les adresses des routines de gestion, ou au moins celle de notre routine "de remplacement" (Dummy_Handler()) lorsque la documentation indique que l'emplacement est utilisé (table 363 et figure 68 pour les exceptions, et table 4 pour les interruption).
void *vector_table[] __attribute__ ((section(".vectors"))) = {
0, /* 0 */
Reset_Handler,
NMI_Handler,
HardFault_Handler,
0,
0, /* 5 */
0,
/* Entry 7 (8th entry) must contain the 2’s complement of the check-sum
of table entries 0 through 6. This causes the checksum of the first 8
table entries to be 0 */
(void *)0xDEADBEEF, /* Actually, this is done using an external tool. */
0,
/* [.....] voir le code du module GPIO-Demo pour la suite */
};

Cependant ceci n'est pas suffisant (vous pouvez désormais le tester très simplement, je vous laisse faire).

=== Un peu de place pour la pile ===

Le dernier point un petit peu particulier est encore sur cette fameuse table des vecteurs, et concerne la première entrée.
Si vous regardez attentivement la figure 68, le vecteur "Reset" n'est que la deuxième entrée de la table.
La première est la valeur initiale du pointeur de la pile (Stack pointer), qui correspond en fait à son sommet puisque cette pile est remplie en faisant décroître les adresses (cette information se trouve dans le chapitre 25, mais cette fois je vous laisse chercher un petit peu).

Nous avons initialisé cette valeur à 0, ce qui forcément pose un soucis.

Pour obtenir la bonne valeur, nous pourrions coder en dur l'adresse du haut de notre sram, mais ce n'est pas propre.
Pour que tout soit fait correctement et automatiquement, nous allons modifier le script de l'édition de liens, et demander à '''ld''' de remplir cette adresse à notre place, en fonction de l'adresse de la sram et de sa taille.

Nous allons donc créer des variables dans notre script, juste après la définition de la mémoire disponible, et chose très importante, ces variables seront des variables externes utilisables dans notre code C !
: _sram_size = LENGTH(sram);
: _sram_base = ORIGIN(sram);
: _end_stack = (_sram_base + _sram_size);
Nous appelons le bas de la pile (la "fin" de la pile) '''_end_stack''', et plaçons cette fin de pile tout en haut de la mémoire vive.

Et pour l'utilisation dans notre code C, tout simplement :
extern unsigned int _end_stack;
void *vector_table[] __attribute__ ((section(".vectors"))) = {
&_end_stack, /* Initial SP value */ /* 0 */
Reset_Handler,
...

Si vous compilez votre code avec ces modifications, vous obtenez enfin un binaire qui allume la Led !

'''Note''' : Avec certaines versions de GCC la section data est créée et notre script d'édition de lien demande au compilateur de la placer au début de la RAM, ce qui créé un binaire de 256Mo. Il faut alors modifier le script d'édition de lien pour lui indiquer de placer les données en flash (tout en conservant les adresses en RAM). Pour ce faire, il faut ajouter "AT >flash" derrière le ">sram" après la section data.

== Conclusion ==

Nous avons enfin notre "Hello World !" version électronique, mais la route est encore longue.

Vous pourrez voir dans le prochain article que cette première étape n'était qu'une étape, et qu'il reste encore plusieurs étapes importantes avant de pouvoir vraiment commencer à écrire du code "fonctionnel", comme la gestion du "watchdog", la configuration de l'horloge interne, l'initialisation de la mémoire, et l'écriture des drivers pour chaque bloc fonctionnel (liaison série, I2C, SPI, ADC, ....).

Rendez-vous donc pour le second article dédié à la programmation de notre micro-contrôleur.

Merci pour votre lecture attentive !

== Les fichiers créés ==
Vous trouverez sur notre serveur le [http://techdata.techno-innov.fr/Modules/GPIO_Demo/Code_LM/Article_5/Makefile Makefile], le fichier C [http://techdata.techno-innov.fr/Modules/GPIO_Demo/Code_LM/Article_5/main.c main.c], et le script de lien [http://techdata.techno-innov.fr/Modules/GPIO_Demo/Code_LM/Article_5/lpc_link_lpc1224.ld lpc_link_lpc1224.ld]

== Liens - Bibliographie ==
* [1] https://gcc.gnu.org/onlinedocs/gcc-4.7.4/gcc/Option-Summary.html
* [2] https://sourceware.org/binutils/docs/binutils/objdump.html
* [3] https://sourceware.org/binutils/docs/binutils/readelf.html
* [4] Page du module et Manuel utilisateur : http://www.techno-innov.fr/technique-module-gpio-demo/ - http://techdata.techno-innov.fr/Modules/GPIO_Demo/System_Reference_Manual_Module_GPIO_Demo_v03.pdf
* [5] Dépôt GIT lpctools : http://git.techno-innov.fr/?p=lpctools
* [6] Lien vers d'autres outils pour programmer les LPC :
** mxli : http://www.windscooting.com/softy/mxli.html
** lpc21isp : http://sourceforge.net/projects/lpc21isp/
** nxpprog : http://sourceforge.net/projects/nxpprog/
** GLPC (GUI pour lpc21isp) : http://sourceforge.net/projects/glpc/
* [7] Manuel utilisateur du LPC1224 : http://www.nxp.com/documents/user_manual/UM10441.pdf
* [8] http://fr.wikipedia.org/wiki/Segment_BSS
* [9] http://en.wikipedia.org/wiki/Bitwise_operation

Articles/Nathael/Domotab et elec Libre partie5

2020-09-02T21:28:42Z

Nathael :

{{DISPLAYTITLE:Électronique et domotique libre - partie 5 : Programmation, Premiers signes de vie}}
<div style="float:left; margin-right: 2.5em;">__TOC__</div>

[[Image:DomoTab.png|200px|right]]
Programmation du module !

Nous avons vu dans le quatrième article comment fabriquer le module GPIO-Démo (ou toute version modifiée), nous allons désormais nous atteler à lui donner vie.

'''Note 1''' : La programmation sera faite en C, bien que d'autres langages puissent être utilisés, à la seule condition qu'il existe un compilateur qui puisse générer du code binaire pour ARM à partir de ce langage.

'''Note 2''' : Les tailles indiquées dans cet article dépendent de la version de GCC utilisée, et il est presque certain que vous obtiendrez des tailles différentes, comme par exemple une taille de 256Mo, un cas que j'ai eu fréquement en TP quand le compilateur créé la section data pour le bloc de données placé en RAM, à l'adresse 0x10000000, soit 256Mo.

<div style="float:right">par Nathael Pajani</div>

<div style="clear:right"> </div>
Paru dans le [http://boutique.ed-diamond.com/home/851-open-silicium-14.html numéro 14] du magazine Open Silicium.

<div style="clear:both"> </div>

== Les documentations techniques ==

La première étape lorsqu'on veut écrire du code pour un système embarqué qui utilise un micro-contrôleur, c'est d'en trouver la documentation technique.

L'accès aux documentations techniques est à mon avis un des critères principaux dans le choix des composants pour un projet, aussi bien pour les concepteurs que pour les utilisateurs.

Si vous avez réalisé la conception du circuit, vous aurez normalement déjà eu besoin de ces documentations, dans le cas contraire, c'est le moment de les récupérer.
Pour le module GPIO-Démo, il y a plusieurs documentations techniques nécessaires pour utiliser la totalité des fonctionnalités du module.
La première et la plus importante est celle du micro-contrôleur [7], mais vous aurez aussi besoin de celle du module, disponible sur le site de Techno-Innov [4], et de celles de l'EEPROM I2C, et du capteur de température I2C.

Encart : Pour ce qui est du bridge USB-UART, la documentation n'est pas nécessaire pour la programmation du micro-contrôleur et du module, mais elle le devient si vous voulez modifier la façon dont le composant s'identifie lorsque vous le connectez, par exemple pour pouvoir lui donner un nom spécifique ou simplifier l'identification. Cela ne sera cependant pas le sujet de cet article.

Pour récupérer les documentations techniques, vous avez le choix entre le site du fabriquant et celui du distributeur chez qui vous avec acheté les composants. Pour la majorité des composants j'utilise le site du distributeur (possible uniquement si il fourni les bonnes documentations), mais pour les micro-contrôleurs je consulte le site du fabriquant car il fourni aussi les "errata" (notes d'informations contenant les corrections sur la documentation) et le plus souvent des notes d'application qui indiquent comment utiliser le composant pour telle ou telle application (avec parfois des exemples de code).

== Outils de programmation ==

La deuxième étape ne concerne toujours pas le code que vous voulez écrire.

En effet, pour écrire du code vous n'avez pas besoin de la "cible" (target en anglais) qui est le matériel sur lequel vous allez exécuter la version compilée du code, mais uniquement d'un poste de développement, couramment appelé hôte (host en anglais).

Cependant, la cible en question n'a que faire des fichiers sources qui se trouvent sur votre poste de développement, et il vous faudra un certain nombre d'outils pour passer des fichiers source (quelque soit le langage) au code exécutable par votre carte électronique.

C'est aussi un point très important à mon sens dans le choix d'un système embarqué ou d'un micro-contrôleur : quels sont les outils dont j'aurais besoin pour passer de mon code source à un système fonctionnant avec ?

Dans le cas des micro-contrôleurs de la gamme LPC de NXP il existe de nombreuses solutions pour passer de l'un à l'autre, mais ce qui est intéressant à mon sens c'est qu'il est possible de le faire avec un minimum de matériel et de logiciel : une liaison série "TTL 3.3V", une chaîne de compilation croisée et un utilitaire pour "uploader" le code binaire.

=== Matériel : un port USB (et le PC qui va avec) ===

[[Image:14-Module sur USB.png|300px|right]]

Pour ce qui est de la liaison série "TTL 3.3V", il existe plein d'adaptateurs USB-UART fonctionnant en 3.3V, et pour le cas du module GPIO-Démo cet adaptateur est intégré sur le module, un port USB suffit donc.

L'accès à cette liaison série se fera via un fichier spécial dont le nom sera devrait ressembler à "/dev/ttyUSB0", le "USB0" pouvant différer selon votre système ("USB1", USB2", ... ou même "ACM0" avec d'autres adaptateurs).

=== Compilation : GNU ===

Pour ce qui est de la chaîne de compilation croisée, les micro-contrôleurs LPC de NXP utilisent des cœurs ARM Cortex-M*, très bien supportés par gcc, bien connu de tous les lecteurs de ce magazine (du moins je le pense), et parfaitement adapté à la cross-compilation.

Dit comme ça, c'est simple ... mais en fait, pas tant que ça.
Cette problématique pourrait faire l'objet d'un (petit ?) article, je ne l'inclurai donc pas ici, je vous donne juste quelques pistes et suppose que vous saurez trouver les informations sur le net. De mon côté je dois les intégrer à la documentation technique du module GPIO-Démo, mais ce n'est pas encore fait à l'heure où j'écris ces lignes :( [4].

Si vous n'avez pas déjà une chaîne de cross-compilation installée pour ARM vous avez globalement trois solutions : Debian/EmDebian (celle que j'utilise), Launchpad, et Crosstools-ng.

Le projet EmDebian fournit des paquets debian pour différentes chaînes de cross-compilation (ARM parmi tant d'autres), qui sont entrain d'être intégrées à Debian. Cela devrait simplifier les problèmes de dépôts et de dépendances dont souffrait les dépôts EmDebian, même si seule la version "arm-none-eabi" (qui nous suffit, nous n'avons pas besoin de libC) est actuellement intégrée dans SID sans problèmes de dépendances (j'ai bien dit "devrait").

Le site de Launchpad fourni aussi des versions binaires de la chaîne de cross-compilation GCC ARM.

La solution CrossTools-ng : recompilation de sa propre chaîne de compilation croisée : la solution du dernier recours, si votre distribution ne fournit pas de solution packagée et que les versions binaires non signées ne vous conviennent pas.

=== Programmation : lpctools (ou autre) ===

Enfin, pour ce qui est de l'utilitaire permettant de charger (uploader) le code binaire sur le micro-contrôleur (flasher le micro-contrôleur), je n'avais pas trouvé d'outil libre permettant de réaliser cette étape au moment où j'ai étudié la possibilité d'utiliser les micro-contrôleurs de NXP, mais le protocole série permettant de réaliser cette opération était documenté dans la documentation technique des micro-contrôleurs, il ne devait donc pas y avoir de problème de ce côté là.

La seule solution "gratuite" que j'avais trouvé à l'époque ne fonctionnait que sur un seul système (pas le miens), ne fournissait pas ses sources, et interdisait une utilisation commerciale sans payer une licence, hors je voulais justement en faire une utilisation commerciale.

J'ai donc pris quelques heures de mon temps pour coder un utilitaire permettant de programmer les micro-contrôleurs LPC, et placé le tout sous licence GPL v3 [5].
Le tout est désormais disponible sur le site de Techno-Innov, et est intégré depuis peu à la distribution Debian GNU/Linux (Sid et Jessie à l'heure de l'écriture de ces lignes).

J'ai entre-temps découvert d'autres projets permettant de programmer des micro-contrôleurs LPC, mais je ne les ai pas testés (nxpprog - licence MIT, mxli - GPLv3, pyLPCTools - GPLv2) et constaté qu'un autre paquet Debian fournit les outils permetant de programmer les micro-contrôleurs LPC de NXP : lpc21isp (qui dispose d'ailleurs d'une interface graphique : GLPC, qui elle n'est pas dans les dépôts). Voir liens [6] en fin d'article.

== Makefile - particularités pour la compilation croisée ==

Une dernière petite étape avant d'écrire notre code, bien que l'on se rapproche de la programmation, puisqu'il s'agit d'un élément essentiel de tout projet : la création du Makefile.

Dans le cas de la compilation pour une cible comme le module GPIO-Démo le Makefile doit inclure quelques éléments supplémentaires que l'on ne retrouve habituellement pas dans un Makefile classique.

Le premier élément concerne la définition du compilateur à utiliser. Nous utiliserons la variable "CROSS_COMPILE" à laquelle nous affecterons une valeur par défaut correspondant au préfixe du compilateur. Si vous voulez utiliser un compilateur correctement installé sur le système, il suffit d'utiliser le préfixe, sinon, il faudra ajouter devant la totalité du chemin donnant accès au compilateur.

Par exemple pour le compilateur EmDebian :
: CROSS_COMPILE ?= arm-linux-gnueabi-
ou avec un chemin complet pour un autre compilateur :
: CROSS_COMPILE ?= /usr/local/mon/compilateur/bin/arm-none-eabi-

Le "?=" permet de ne modifier la variable que si elle n'existe pas, notamment si elle n'est pas déjà présente dans la ligne de commande.

Cette variable est ensuite utilisée pour modifier la variable "CC" utilisée par "make" pour compiler les fichiers de code source C. Si vous utilisez un autre langage, modifiez la variable correspondante.
: CC = $(CROSS_COMPILE)gcc
Il est aussi possible d'en profiter pour spécifier une version du compilateur installé :
: CC = $(CROSS_COMPILE)gcc-4.7
Nous allons en profiter pour définir la variable "LD" qui correspond à l'éditeur de liens (linker en anglais) :
: LD = $(CROSS_COMPILE)ld

Il nous faut ensuite définir la cible pour laquelle nous voulons compiler. Dans notre cas il s'agit d'un cœur ARM Cortex-M0, qui utilise le jeu d'instructions "thumb" (instructions sur 16bits permettant d'obtenir un code plus compact), nous allons donc utiliser les options -mcpu et -mthumb de gcc pour lui indiquer notre besoin :
: CPU = cortex-m0
: CFLAGS = -Wall -mthumb -mcpu=$(CPU)

En plus de cela, nous allons demander au compilateur de ne pas reconnaître les fonctions pour lesquelles il a une définition interne (builtin) tout simplement parce que la majorité de ces fonctions dépendent d'un environnement très différent de celui de notre micro-contrôleur, soit par la présence d'une bibliothèque C, d'un système d'exploitation respectant la norme POSIX, ou d'une unité de calcul flottant.
Rien de tout ceci n'est vrai dans notre cas, et il est donc préférable que le compilateur nous informe si nous tentons d'utiliser ces fonctions sans l'avoir explicitement demandé en utilisant le préfixe "__builtin__".

Nous demanderons aussi au compilateur de bien placer les données et les fonctions dans leurs sections respectives. Malgré ce que dit la documentation de GCC, cela permet (au moins dans notre cas) de produire un binaire plus petit. Cela se fait à l'aide des directives d'optimisation "-ffunction-sections" et "-fdata-sections".

Nous ajouterons ces directives dans une variable dédiée :
: FOPTS = -fno-builtin -ffunction-sections -fdata-sections

Nous obtenons donc les lignes suivantes à ajouter à votre Makefile :
: CROSS_COMPILE ?= arm-linux-gnueabi-
: CC = $(CROSS_COMPILE)gcc
: LD = $(CROSS_COMPILE)ld
: CPU = cortex-m0
: FOPTS = -fno-builtin -ffunction-sections -fdata-sections
: CFLAGS = -Wall -Wextra -mthumb -mcpu=$(CPU) $(FOPTS)

Notre Makefile ressemblerait alors à ceci :
NAME = mod_gpio
CROSS_COMPILE ?= arm-linux-gnueabi-
CC = $(CROSS_COMPILE)gcc
LD = $(CROSS_COMPILE)ld
CPU = cortex-m0
FOPTS = -fno-builtin -ffunction-sections -fdata-sections
CFLAGS = -Wall -Wextra -mthumb -mcpu=$(CPU) $(FOPTS)

.PHONY: all
all: $(NAME)

SRC = $(wildcard *.c)
OBJS = $(SRC:.c=.o)

$(NAME): $(OBJS)
$(LD) $^ -o $@
Ce Makefile est encore incomplet et ne permet pas d'obtenir le binaire pour notre micro-contrôleur, mais nous ajouterons les parties manquantes plus tard.

En attendant, ce Makefile nous permettra de compiler le code que nous allons écrire, passons donc aux parties intéressantes, et le reste du Makefile sera bien plus simple à comprendre.

== Commençons simple ==

Pour ne pas trop compliquer les choses dès le début, nous allons tenter de faire clignoter la led bicolore présente sur le module GPIO-Démo.

Notre squelette de code ressemblera à s'y méprendre à ce que l'on pourrait avoir pour un programme plus commun :
/*
* Notre exemple simple pour Open Silicium
*/
void system_init(void)
{
/* System init ? */
}

int main(void)
{
/* Micro-controller init */
system_init();

while (1) {
/* Change the led state */
/* Wait some time */
}
return 0;
}
Si vous compilez ce petit morceau de code avec notre Makefile, vous obtiendrez un binaire qui globalement ne fait rien, mais a déjà une taille de 5.7 Ko.
C'est gros pour ne rien faire, d'autant que la mémoire Flash de notre micro-contrôleur ne fait que 32 Ko.

Si on regarde plus loin, par exemple avec l'utilitaire ''file'', on obtient quelques informations supplémentaires :
$ file mod_gpio
mod_gpio: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), [....], not stripped

Arghhh, notre binaire est un exécutable dynamique au format ELF, qui utilise des bibliothèques partagées !

Nous l'avons déjà évoqué, notre micro-contrôleur n'a pas de libC ni de système d'exploitation, notre binaire ne peut donc pas être dynamique (lié dynamiquement à des bibliothèques) !
Il nous faut donc faire l'édition de lien en "static", en apportant quelques modification à notre Makefile. Nous allons introduire une variable "LDFLAGS", que l'on ajoutera à la règle de compilation utilisée pour l'édition de liens.
LDFLAGS = -static
$(NAME): $(OBJS)
$(LD) $^ $(LDFLAGS) -o $@
Recompilons notre projet ... 608 Ko !!! Re-Argh !

Visiblement quelqu'un ajoute du code dont nous n'avons pas besoin. Il faut du moins l'espérer, sinon il ne sera jamais possible de faire rentrer un programme dans la flash de notre micro-contrôleur, qui fait toujours 32Ko.

L'option "static" demande à l'éditeur de lien de créer un binaire statique, mais résultat il nous ajoute tout ce qui est utile de la libC pour un exécutable ... pour un système Linux.
D'ailleurs, ''file'' nous dit bien que notre exécutable est au format ELF.

Pour commencer nous allons demander à l'éditeur de liens (ld) de ne pas inclure les éléments de démarrage dans notre binaire, car ils sont inutiles sur notre micro-contrôleur. Pour cela nous ajoutons l'option "-nostartfiles" à nos directives pour l'édition de liens.

Et hop, une recompilation plus tard, notre binaire ne fait plus que 1 Ko :)
Mais pour ''file'', ce binaire est toujours au format ELF, et gcc nous informe qu'il n'a pas trouvé de symbole d'entrée "_start" et qu'il utilise une adresse par défaut (nous l'avons cherché, cela fait partie de ce que nous avons demandé à l'éditeur de liens en ajoutant l'option "-nostartfiles").

En effet, le "main" de nos programmes en C n'est que le point de départ de l'exécution de notre code, mais pas celui du programme. Il est précédé par un certain nombre de routines (fonctions) d'initialisation, dont le point d'entrée est la routine "_start", qui appellera le main "classique".

Mais notre but n'est pas de créer un exécutable pour un système Linux, nous devons créer un binaire pour notre micro-contrôleur. Il est désormais temps de nous plonger dans la documentation du micro-contrôleur pour comprendre comment il démarre, pour pouvoir adapter notre code au démarrage du micro-contrôleur et fournir l'équivalent de cette routine "_start".

== Bootstrap ==

=== Table des vecteurs d'interruption ===

Pour avoir des informations sur le démarrage du micro-contrôleur LPC1224 dans sa documentation technique [7] il y a deux chapitres intéressants.

Nous pouvons nous référer au chapitre 4 (LPC122x System control) qui inclut une section sur le reset du micro-contrôleur (4.6 : Reset), dans laquelle on apprend qu'une fois que la condition de reset disparait et que les procédures internes se sont exécutées, le processeur commence l'exécution à l'adresse contenue dans le vecteur "Reset" du "boot block".

Nous avons ainsi quelques informations, mais qu'est-ce que le vecteur "Reset" et le "boot block" ? Cela nous mène au deuxième chapitre intéressant, le chapitre 25 sur le cœur ARM Cortex-M0. On y trouve une section sur le processeur (25.3 : Processor) avec une sous section concernant les exeptions (25.3.3 : Exception model).

Dans les informations sur les exceptions (25.3.3.2), et plus particulièrement l'exception "Reset", il est indiqué qu'après un "Reset" l'exécution reprend à l'adresse indiquée dans le vecteur "Reset" dans la table des vecteurs d'interruption.

Bien, cela confirme ce qui se trouvait dans le chapitre 4. Mais cette fois, nous avons une sous-section "25.3.3.4 Vector table", qui décrit cette fameuse table des vecteurs d'exception, précisant qu'elle contient l'addresse de toutes les routines de gestion des exceptions (les fameux "vecteurs" d'exception, dont le vecteur "Reset").

Remarquez au passage que les interruptions sont gérées de la même façon, l'addresse d'entrée des routines de gestion des interruptions se trouve dans cette même table.

Et en dessous de cette table, nous avons une autre information très intéressante : "The vector table is fixed at address 0x00000000".

Si l'on se réfère à la table 65 de la section "25.3.2 Memory model", et à la figure 2 de la section "2.3 Memory allocation", on découvre que cette adresse est en fait le début de la mémoire flash du micro-contrôleur, qui devra contenir notre code binaire.

Reste à créer cette table, et à la placer au bon endroit dans le code binaire compilé...

=== Les "handlers" et les "dummy handlers" ===

Nous allons commencer par la partie code.
Ce code peut être placé dans le même fichier que celui ou ce trouve notre fonction main, ou dans un autre fichier, cela n'a pas d'importance. Si vous vous référez au code du module GPIO-Démo disponible dans les dépôts git de Techno-Innov, vous trouverez ce code dans le fichier "core/bootstrap.c".

[[Image:Vecteurs_interruption.png|350px|right]]

/* Cortex M0 core interrupt handlers */
void Reset_Handler(void);
void NMI_Handler(void) __attribute__ ((weak, alias ("Dummy_Handler")));
void HardFault_Handler(void) __attribute__ ((weak, alias ("Dummy_Handler")));

void Dummy_Handler(void);

void *vector_table[] = {
0,
Reset_Handler,
NMI_Handler,
HardFault_Handler,
0,
/* [......] */
};

void Dummy_Handler(void) {
while (1);
}

void Reset_Handler(void) {
/* Our program entry ! */
}

Voici un petit morceau de code relativement court qui définit notre table de vecteur ainsi que les routines de gestion correspondantes.

Avant d'aller plus loin, faisons un petit point sur certains éléments : les attributs utilisés pour la déclaration de deux de nos routines de gestion des exceptions : "__attribute__ ((weak, alias ("Dummy_Handler")))"

Ces attributs permettent de définir un alias "faible" pour une fonction, ce qui veut dire que si le compilateur ne trouve pas de définition pour cette fonction, il pourra utiliser son alias, que nous avons défini plus bas. Au contraire, si dans un autre fichier (ou celui-ci) vous définissez l'une de ces fonctions, c'est votre définition qui sera utilisée.

Note : je n'ai pas mis la totalité de la table des vecteurs, cela n'a pas d'intérêt pour les explications, et notre programme fonctionnera sans, mais il faudrait la compléter pour un vrai programme, en faisant attention à l'ordre, à partir des informations de la figure 68 déjà évoquée, et de la table 4 du chapitre 3 concernant le gestionnaire d'interruptions (vous noterez la typo, il s'agit des numéros d'IRQ et non pas des numéros des vecteurs d'exception).

=== Appeler notre main() ===
Ce petit bout de code compile donc, puisque tout est défini, mais nous avons toujours l'avertissement concernant le symbole d'entrée "_start" qui n'a pas été trouvé. Nous ne sommes pas plus avancé.

Tout d'abord, nous avons déjà indiqué que le point d'entrée de notre code est la fonction main() (qui pourrait avoir n'importe quel nom), mais pour notre micro-controlleur la fonction d'entrée du programme est la routine de gestion de l'exception "Reset".

La solution pour faire le lien est toute simple : il suffit d'appeler la fonction main() depuis la routine de gestion de l'exception "Reset".
int main(void);
void Reset_Handler(void) {
/* Our program entry ! */
main();
}

=== Tisser des liens, c'est important ===
Cela ne résout cependant aucun de nos problèmes, nous allons donc devoir donner plus d'indications à l'éditeur de liens, en créant un script pour l'édition de lien (lpc_link_lpc1224.ld). Nous donnerons le nom de ce script à l'éditeur de liens en utilisant l'otion "-T''lpc_link_lpc1224.ld''".

Ce script d'édition de lien ("linker script" en anglais) est en fait un fichier qui décrit la mémoire de notre micro-contrôleur, ainsi que l'organisation que devra respecter notre binaire.

Nous allons donc commencer, toujours à partir des mêmes informations en provenance de la documentation technique, par définir quelle est la mémoire disponible, aussi bien la mémoire "vive" (SRAM) que la mémoire "morte" (FLASH).

MEMORY
{
sram (rwx) : ORIGIN = 0x10000000, LENGTH = 4k
flash (rx) : ORIGIN = 0x00000000, LENGTH = 32k
}
Nous définissons ainsi l'adresse et la taille (et les droits d'accès) de la sram et de la flash, qui deviennent deux blocs de mémoire disponibles pour l'éditeur de liens, qui pourra donc y placer du code et des données.

Il nous faut maintenant expliquer à l'éditeur de liens comment organiser le code et les données dans ces blocs de mémoire, et tout particulièrement notre tableau de vecteurs d'interruptions

Le code d'un programme est composé de "sections", dans lesquelles le compilateur place chaque fonction et chaque variable en fonction de différents critères, que l'on peut contrôler soit à partir de directives de compilation, soit d'attributs ajoutés dans notre code C

Nous allons donc modifier notre tableau de vecteurs d'interruptions pour lui ajouter un attribut "section" qui forcera l'éditeur de liens à le placer dans la section que nous avons défini.
: void *vector_table[] __attribute__ ((section(".vectors"))) = {

Et en parallèle, nous allons définir dans notre script quelles sont les sections que nous voulons trouver dans notre binaire, et dans quel ordre.
Commençons simple (si si, je vous assure), nous compliquerons plus tard :
SECTIONS {
. = ORIGIN(flash);
.text :
{
KEEP(*(.vectors))
*(.text*)
*(.rodata*)
} >flash
.data :
{
*(.data*)
*(.bss*)
} >sram
}
Pour commencer, nous définissons l'adresse courante (.) comme étant l'origine de du bloc de mémoire "flash" (le bloc de mémoire défini précédemment et auquel nous avons donné ce nom, bien qu'un autre nom aurait pu faire l'affaire).
Ceci est important pour que l'éditeur de liens puisse définir les adresses des fonctions pour l'exécution de notre code.
À partir de ce point nous définissons une section "text", dans laquelle nous allons demander à l'éditeur de lien de mettre plusieurs éléments, à commencer par notre fameuse table de vecteurs, en lui interdisant d'en changer la position !
Après quoi, nous lui demandons de placer l'ensemble du code, que le compilateur a placé dans des section ".text.*", puis les données en lecture seule (Read-Only data = rodata), et de placer le tout dans le bloc de mémoire "flash".

À la suite, nous créons une section "data", dans laquelle nous lui demandons de placer les données initialisées à des valeurs non nulles (data), puis les données initialement nulles (bss [8]), et de placer cette section en RAM.

Ne reste plus qu'une information à donner à l'éditeur de liens (pour l'instant): le point d'entrée de notre programme.
Ceci est relativement simple et explicite :
: ENTRY(Reset_Handler)

Dans notre Makefile la variable LDFLAGS devient :
: LDFLAGS = -static -nostartfiles -Tlpc_link_lpc1224.ld

Une compilation plus tard, sans avertissements cette fois, nous avons un binaire ... beaucoup trop gros : notre binaire fait maintenant plus de 66 Ko !

Soyons un peu curieux et allons donc voir ce qu'il contient, mais pas à la main, rassurez vous, utilisons un utilitaire fait exprès pour cela : ''objdump''. attention, il faut bien entendu utiliser la version "ARM" de objdump, donc avec le préfixe "CROSS_COMPILE", soit dans mon cas ''arm-linux-gnueabi-objdump'', avec l'option ''--disassemble-all'' (-D) :
: arm-linux-gnueabi-objdump -D mod_gpio > dump
Et là, surprise, la version "désassemblée" de notre binaire est plus petite que la version binaire (le fichier "dump" fait 2.2 Ko).

Regardons tout de même son contenu.
La première ligne nous informe que le format du fichier est "elf32-littlearm" ... pas grand chose à voir avec ce que nous voulions, un "simple" binaire (Notre micro-contrôleur n'a toujours pas appris à lire les exécutables au format ELF). Premier problème.

Quelqu'un est venu glisser une section ".note.gnu.build-id" avant notre section ".text", que l'éditeur de liens aimerait placer en début de RAM ("10000000 <_sram_base>"), ce qui n'a pas d'intérêt pour nous.

S'en suit tout de même notre section ".text", qui commence bien par notre table (enfin ! on nous écoute un peu !), suivie de nos quelques maigres fonctions. Notez les adresses des fonctions dans la table des vecteurs, qui sont toutes impaires. Ceci indique que notre processeur exécutera ces fonctions en mode "thumb" qui est bien le mode que nous avions demandé (-mthumb).

Et encore une fois, notre section ".text" n'est pas suivie de nos données, mais d'autres sections que nous n'avions pas demandées !
Certes, nous n'avons pas de variables, et l'éditeur de lien n'ayant rien à mettre dans notre section ".data", il ne l'a pas créée, mais au final nous sommes relativement loin de ce que nous voulions.

Nous allons donc demander à l'éditeur de liens de générer un petit peu moins de choses en ajoutant l'option ''-Wl,--build-id=none'' à nos directives de compilation (variable LDFLAGS de notre Makefile), ce qui nous donne un binaire moitié plus petit mais toujours trop gros.

=== Un binaire vraiment binaire ===
Mais nous ne pouvons pas en demander bien plus à l'éditeur de liens, dont le travail est de créer des exécutables au format ELF.
Pour créer d'autres types de binaire, nous devrons utiliser l'utilitaire ''objcopy'' (toujours la version ARM, donc en fait ''arm-linux-gnueabi-objcopy'').
Le travail de cet utilitaire est de créer des binaires à partir des exécutables ELF, en ne conservant que les sections qui nous intéressent (du moins, c'est l'usage que nous en ferons).

Nous allons demander à cet utilitaire de nous générer une image binaire à partir du résultat de notre compilation en ajoutant dans notre Makefile une cible "$(NAME).bin" qui deviendra notre cible par défaut et dépendra de la génération du fichier au format ELF :

all: $(NAME).bin

$(NAME).bin: $(NAME)
$(CROSS_COMPILE)objcopy -O binary $^ $@

Et notre objectif est enfin atteint, avec un binaire de ... 36 octets !<br />
Rappelez vous, je n'ai mis que 5 entrées dans ma table de vecteurs, soit 20 octets, suivis de quelques fonctions vides. Tout va bien.

== Un programme un peu plus utile ==

Nous allons désormais pouvoir nous occuper d'allumer nos Leds, en quelque sorte le "Hello world" de l'électronique.

=== Entrées et sorties ===
Du point de vue de notre micro-contrôleur, allumer ou éteindre une Led revient à changer l'état de la sortie correspondante.

Les entrées/sorties du microcontrôleur peuvent avoir plusieurs fonctions, mais hormis quelques exceptions elles sont par défaut configurées en entrées/sorties (GPIO (general Purpose Input Output) en anglais) avec la résistance de pull-up interne activée. Pour simplifier, nous laisserons donc cette étape de la configuration de côté pour l'instant, et reviendrons dessus lorsque nous attaquerons la programmation d'interfaces plus complexes.

: Note : Les exceptions sont les GPIO 13, 25 et 26 du port 0 (respectivement Reset, SWDIO et SWDCLK), qui permettent le reset et le debug, ainsi que quatre GPIO sur lesquelles la fonction "0" est réservée : les GPIO 30 et 31 du port 0 et les GPIO 0 et 1 du port 1.

=== Les registres ===
Pour changer l'état d'une de ces entrées/sorties, il faut commencer par la configurer en sortie, puis définir sont état.

Avant d'aller plus loin, il est important de comprendre que le processeur de notre micro-contrôleur ne voit que de la mémoire autour de lui. Il n'a pas accès directement aux signaux électriques.
Pour accéder aux fonctions spéciales comme l'état électrique d'une sortie le processeur doit donc modifier des données dans une zone mémoire spécifique, dédiée à cette sortie, que l'on appelle un registre.

Notre micro-contrôleur dispose d'un grand nombre de registres qui ont tous une taille de 32 bits, même si souvent certains bits ne sont pas utilisés (ils sont alors "réservés").
Ces registres particuliers, qui nous donnent accès aux fonctions spéciales du micro-contrôleur, comme la configuration et l'état des entrées sorties, sont accessibles chacun à une adresse fixe dans l'espace d'adressage du micro-contrôleur.

Nous avons déjà eu besoin d'informations sur cet espace d'adressage lorsque nous avons cherché des informations sur le démarrage du micro-contrôleur, il se trouve représenté sur la figure 2 dans la section "2.3 Memory allocation" du chapitre 2 (LPC122x Memory map).

L'adresse qui nous intéresse dépend du port sur lequel les leds sont connectées.
La led bicolore étant connectée sur le port 1 ce sont les registres présents à l'adresse 0x50010000 que nous devrons utiliser.
Cette adresse est aussi rappelée avec la description des registres dans le chapitre 8 (LPC122x General Purpose I/O (GPIO))

À partir de cette adresse se trouvent une série de registres permettant de contrôler les entrées/sorties du port 1. La modification du contenu de la mémoire accessible ainsi modifiera donc le comportement des entrées/sorties correspondantes ou leur état lorsqu'elles sont configurées en sortie.

Très (trop) souvent, pour accéder à ces registres, les programmeurs utilisent des définitions selon le principe suivant:
#define LPC_AHB_BASE (0x50000000UL)
#define LPC_GPIO_1_BASE (LPC_AHB_BASE + 0x10000)
#define PORT1_MASK (LPC_GPIO_1_BASE + 0x00)
#define PORT1_PIN (LPC_GPIO_1_BASE + 0x04)
#define PORT1_OUT (LPC_GPIO_1_BASE + 0x08)
/* [.....] */
Personnellement je trouve cette façon de faire très inefficace, et peu lisible (voire complètement illisible), et je préfère l'utilisation de structures.
Cela me semble beaucoup plus lisible, plus adapté pour accéder à de la mémoire qui est structurée, et apporte aussi un très net avantage lorsqu'il existe plusieurs ensembles de registres utilisant la même organisation, par exemple quand il y a plusieurs liaisons séries sur le micro-contrôleur, ou dans le cas qui nous intéresse pour l'instant, plusieurs ports d'entrées/sorties.
La définition se passe alors ainsi :
#define LPC_AHB_BASE (0x50000000UL)
#define LPC_GPIO_0_BASE (LPC_AHB_BASE + 0x00000)
#define LPC_GPIO_1_BASE (LPC_AHB_BASE + 0x10000)
/* General Purpose Input/Output (GPIO) */
struct lpc_gpio
{
volatile uint32_t mask; /* 0x00 : Pin mask, affects data, out, set, clear and invert */
volatile uint32_t in; /* 0x04 : Port data Register (R/-) */
volatile uint32_t out; /* 0x08 : Port output Register (R/W) */
volatile uint32_t set; /* 0x0C : Port output set Register (-/W) */
volatile uint32_t clear; /* 0x10 : Port output clear Register (-/W) */
volatile uint32_t toggle; /* 0x14 : Port output invert Register (-/W) */
uint32_t reserved[2];
volatile uint32_t data_dir; /* 0x20 : Data direction Register (R/W) */
/* [.....] */
};
#define LPC_GPIO_0 ((struct lpc_gpio *) LPC_GPIO_0_BASE)
#define LPC_GPIO_1 ((struct lpc_gpio *) LPC_GPIO_1_BASE)
À noter, l'utilisation du mot clé "volatile" qui interdira au compilateur d'optimiser les accès à ces registres en gardant des copies intermédiaires, forçant la lecture ou l'écriture immédiate.

Cette notation nous donne aussi l'information de la taille des données présentes à ces adresses, dans ce cas là, des valeurs sur 32 bits.

Pour l'utilisation dans le code, c'est ensuite très simple, il suffit de déclarer un pointeur vers cette structure, puis d'accéder au champ qui nous intéresse :
struct lpc_gpio* gpio1 = LPC_GPIO_1;
gpio1->out = 0;

=== Allumer les leds ===

Reste à déterminer quels sont les champs qui nous intéressent et quelles valeurs nous devons écrire dedans.
Pour configurer les pins reliées à nos Leds en sortie nous devons modifier le registre "DIR" (appelé "data_dir" dans la structure), et mettre les bits 4 et 5 à "1" puisque chaque bit de ce registre permet de configurer une des pins du port correspondant, le bit 0 pour la pin 0, le bit 1 pour la pin 1, et ainsi de suite (attention, ici les numéros de pins ne sont pas les numéros des pattes du composant).

Nous pouvons donc modifier notre main() pour obtenir le code suivant qui réalise cette opération de façon lisible, et positionne la Led verte à l'état "allumée", sans modifier l'état des autres sorties du port 1 :
/* The status LED is on GPIO Port 1, pin 4 (PIO1_4) and Port 1, pin 5 (PIO1_5) */
#define LED_RED 5
#define LED_GREEN 4
int main(void)
{
struct lpc_gpio* gpio1 = LPC_GPIO_1;
/* Micro-controller init */
system_init();
/* Configure the Status Led pins */
gpio1->data_dir |= (1 << LED_GREEN) | (1 << LED_RED);
/* Turn Green Led ON */
gpio1->set = (1 << LED_GREEN);
gpio1->clear = (1 << LED_RED);
while (1) {
/* Change the led state */
/* Wait some time */
}
}

[Encart : Décalages de bits] :
: La notation "<<" correspond à l'opérateur logique "décalage de bits vers la gauche" (">>" pour le décalage à droite). Voir l'article wikipedia sur le sujet, en Anglais, la version Française étant catastrophiquement incomplète [9].

== Mettre le code sur le micro-contrôleur : lpctools ==

Je sais que vous êtes de plus en plus impatients et que vous voulez voir le résultat de tout ceci en vrai, nous allons donc passer à la mise en flash sur le micro-contrôleur pour tester tout cela.

Je ne traiterais ici que le cas de la version 48 broches du micro-contrôleur LPC1224 (package LQFP48). A vous d'adapter si vous utilisez un autre micro-contrôleur, le principe étant très similaire pour tous les LPC de NXP. Pour les autres gammes de micro-contrôleurs, référez vous à leurs docs techniques et aux informations sur Internet.

=== Connexion ===
Si vous avez mis l'adaptateur USB-UART sur votre module comme proposé dans les articles précédents, l'étape de connexion au PC est simple, connectez votre module sur un port USB, directement ou via un câble en fonction du connecteur USB que vous avez choisi.

Sinon, il vous faudra un adaptateur USB-UART (souvent vendus comme adaptateurs USB-série) fonctionnant en 3.3V, et relier les signaux Rx et Tx aux signaux TXD0 et RXD0 correspondant à l'UART 0 du micro-contrôleur LPC1224 qui se trouvent sur le port 0, pins 1 et 2 (broches 16 et 17 du composant). Il est alors préférable d'avoir rendu ces signaux accesssibles sur un connecteur de votre choix, sans quoi il vous faudra souder des fils directement sur les pattes du micro-contrôleur ... possible, mais pas conseillé du tout).

=== Mode ISP ===

Il faut ensuite mettre le micro-contrôleur en mode programmation (ISP : "In System Programming" en anglais). Le chapitre 20 (LPC122x Flash ISP/IAP) indique qu'il faut maintenir la pin 12 du port 0 (broche 27) à l'état bas (0V) pendant au moins 3ms après avoir relaché le signal "Reset" (pin 13 du port 0, broche 28). La suite du chapitre décrit le protocole de programmation, uniquement utile si vous voulez créer votre propre utilitaire pour programmer le micro-contrôleur, ou si vous voulez réaliser des opérations très spécifiques.

Puisque nous avons placé des boutons poussoir reliant ces signaux à la masse, avec des résistance de "pull-up", cette opération est très simple : il faut appuyer sur les deux boutons en même temps, puis relacher le bouton reset avant de relacher le bouton ISP.
Lorsque tout c'est bien passé, la led bicolore doit avoir deux petits points lumineux à peine visibles dans l'obscurité (un rouge et un vert).

=== Dialogue avec le micro-contrôleur ===

La suite se passe sur le PC. Le paquet lpctools contient deux binaires : lpcisp et lpcprog.
Le premier donne accès aux opérations élémentaires du protocole de programmation, et ne nous sera pas utile. Le second permet de programmer le micro-contrôleur en utilisant une unique commande, bien que d'autres commandes permettent d'effectuer quelques opérations intéressantes.

Nous allons d'ailleurs commencer par une de ces autres opération : demander les identifiants de notre micro-contrôleur avec la commande "id".
La syntaxe des commandes lpcprog est simple, il suffit de lui passer un nom de device, que l'on passe comme argument de l'option "-d", une commande (argument de l'option "-c"), et si besoin le nom du fichier à utiliser.
Dans l'exemple suivant le module GPIO-Démo est identifié sur le poste de développement comme périphérique "ttyUSB0", nous utiliserons donc le ''device'' "/dev/ttyUSB0".
$ lpcprog -d /dev/ttyUSB0 -c id
Part ID 0x3640c02b found on line 26
Part ID is 0x3640c02b
UID: 0x2c0cf5f5 - 0x4b32430e - 0x02333834 - 0x4d7c501a
Boot code version is 6.1
La première ligne nous indique que lpcprog a reconnu le micro-contrôleur et qu'il sera donc possible de le programmer. (Si ce n'est pas le cas, vous devrez compléter le fichier de description des micro-contrôleurs).
Ensuite, lpcprog nous donne les informations propres au micro-contrôleur, à savoir son identifiant unique et la version du "boot code" qui se trouve en rom sur le micro-contrôleur.

Si vous avez un affichage similaire, tout va bien.
Sinon, vérifiez la connexion et que le micro-contrôleur est bien en mode ISP.

La programmation se fait ensuite très simplement avec la commande "flash", en ajoutant le nom du fichier binaire à envoyer.
$ lpcprog -d /dev/ttyUSB0 -c flash mod_gpio.bin
Part ID 0x3640c02b found on line 26
Flash now all blank.
Checksum check OK
Flash size : 32768, trying to flash 1 blocks of 1024 bytes : 1024
Writing started, 1 blocks of 1024 bytes ...
lpcprog se charge d'effacer la flash, de générer la somme de contrôle de l'entête et de la placer au bon endroit dans le binaire, et d'envoyer le tout au micro-contrôleur pour mise en flash.

Pour tester, il suffit d'appuyer sur le bouton Reset, et de constater qu'il ne se passe rien, ce qui n'est pas ce que nous attendions.

Il y a plusieurs problèmes.

=== Votre code s'il vous plait ! ===

Le premier vient de la génération de la somme de contrôle, ou plutôt de sa position dans notre binaire.
Tous les LPC de NXP utilisent (à ce jour de ce que j'ai pu voir) le même mécanisme pour déterminer si la flash contient une image valide avant d'essayer d'exécuter son contenu : la vérification du checksum des 8 premiers vecteurs d'interruption, qui doit être nulle.

Pour que ceci soit possible, conformément à la documentation technique des micro-contrôleurs, lpcprog calcule le complément à 2 des 7 premiers vecteurs, et le place dans le huitième.

Sauf que notre tableau ne fait pour l'instant que 5 "cases" et que la huitième case contenait en fait notre code exécutable, qui a été écrasé.

La première modification est donc de remplir au moins 8 cases de ce tableau, au pire avec des valeurs nulles, sinon, avec des valeurs correspondant à ce qui est attendu dans la documentation : les adresses des routines de gestion, ou au moins celle de notre routine "de remplacement" (Dummy_Handler()) lorsque la documentation indique que l'emplacement est utilisé (table 363 et figure 68 pour les exceptions, et table 4 pour les interruption).
void *vector_table[] __attribute__ ((section(".vectors"))) = {
0, /* 0 */
Reset_Handler,
NMI_Handler,
HardFault_Handler,
0,
0, /* 5 */
0,
/* Entry 7 (8th entry) must contain the 2’s complement of the check-sum
of table entries 0 through 6. This causes the checksum of the first 8
table entries to be 0 */
(void *)0xDEADBEEF, /* Actually, this is done using an external tool. */
0,
/* [.....] voir le code du module GPIO-Demo pour la suite */
};

Cependant ceci n'est pas suffisant (vous pouvez désormais le tester très simplement, je vous laisse faire).

=== Un peu de place pour la pile ===

Le dernier point un petit peu particulier est encore sur cette fameuse table des vecteurs, et concerne la première entrée.
Si vous regardez attentivement la figure 68, le vecteur "Reset" n'est que la deuxième entrée de la table.
La première est la valeur initiale du pointeur de la pile (Stack pointer), qui correspond en fait à son sommet puisque cette pile est remplie en faisant décroître les adresses (cette information se trouve dans le chapitre 25, mais cette fois je vous laisse chercher un petit peu).

Nous avons initialisé cette valeur à 0, ce qui forcément pose un soucis.

Pour obtenir la bonne valeur, nous pourrions coder en dur l'adresse du haut de notre sram, mais ce n'est pas propre.
Pour que tout soit fait correctement et automatiquement, nous allons modifier le script de l'édition de liens, et demander à '''ld''' de remplir cette adresse à notre place, en fonction de l'adresse de la sram et de sa taille.

Nous allons donc créer des variables dans notre script, juste après la définition de la mémoire disponible, et chose très importante, ces variables seront des variables externes utilisables dans notre code C !
: _sram_size = LENGTH(sram);
: _sram_base = ORIGIN(sram);
: _end_stack = (_sram_base + _sram_size);
Nous appelons le bas de la pile (la "fin" de la pile) '''_end_stack''', et plaçons cette fin de pile tout en haut de la mémoire vive.

Et pour l'utilisation dans notre code C, tout simplement :
extern unsigned int _end_stack;
void *vector_table[] __attribute__ ((section(".vectors"))) = {
&_end_stack, /* Initial SP value */ /* 0 */
Reset_Handler,
...

Si vous compilez votre code avec ces modifications, vous obtenez enfin un binaire qui allume la Led !

== Conclusion ==

Nous avons enfin notre "Hello World !" version électronique, mais la route est encore longue.

Vous pourrez voir dans le prochain article que cette première étape n'était qu'une étape, et qu'il reste encore plusieurs étapes importantes avant de pouvoir vraiment commencer à écrire du code "fonctionnel", comme la gestion du "watchdog", la configuration de l'horloge interne, l'initialisation de la mémoire, et l'écriture des drivers pour chaque bloc fonctionnel (liaison série, I2C, SPI, ADC, ....).

Rendez-vous donc pour le second article dédié à la programmation de notre micro-contrôleur.

Merci pour votre lecture attentive !

== Les fichiers créés ==
Vous trouverez sur notre serveur le [http://techdata.techno-innov.fr/Modules/GPIO_Demo/Code_LM/Article_5/Makefile Makefile], le fichier C [http://techdata.techno-innov.fr/Modules/GPIO_Demo/Code_LM/Article_5/main.c main.c], et le script de lien [http://techdata.techno-innov.fr/Modules/GPIO_Demo/Code_LM/Article_5/lpc_link_lpc1224.ld lpc_link_lpc1224.ld]

== Liens - Bibliographie ==
* [1] https://gcc.gnu.org/onlinedocs/gcc-4.7.4/gcc/Option-Summary.html
* [2] https://sourceware.org/binutils/docs/binutils/objdump.html
* [3] https://sourceware.org/binutils/docs/binutils/readelf.html
* [4] Page du module et Manuel utilisateur : http://www.techno-innov.fr/technique-module-gpio-demo/ - http://techdata.techno-innov.fr/Modules/GPIO_Demo/System_Reference_Manual_Module_GPIO_Demo_v03.pdf
* [5] Dépôt GIT lpctools : http://git.techno-innov.fr/?p=lpctools
* [6] Lien vers d'autres outils pour programmer les LPC :
** mxli : http://www.windscooting.com/softy/mxli.html
** lpc21isp : http://sourceforge.net/projects/lpc21isp/
** nxpprog : http://sourceforge.net/projects/nxpprog/
** GLPC (GUI pour lpc21isp) : http://sourceforge.net/projects/glpc/
* [7] Manuel utilisateur du LPC1224 : http://www.nxp.com/documents/user_manual/UM10441.pdf
* [8] http://fr.wikipedia.org/wiki/Segment_BSS
* [9] http://en.wikipedia.org/wiki/Bitwise_operation

Articles/Nathael/Domotab et elec Libre partie5

2020-09-02T21:22:33Z

Nathael : /* Tisser des liens, c'est important */

{{DISPLAYTITLE:Électronique et domotique libre - partie 5 : Programmation, Premiers signes de vie}}
<div style="float:left; margin-right: 2.5em;">__TOC__</div>

[[Image:DomoTab.png|200px|right]]
Programmation du module !

Nous avons vu dans le quatrième article comment fabriquer le module GPIO-Démo (ou toute version modifiée), nous allons désormais nous atteler à lui donner vie.

'''Note 1''' : La programmation sera faite en C, bien que d'autres langages puissent être utilisés, à la seule condition qu'il existe un compilateur qui puisse générer du code binaire pour ARM à partir de ce langage.

'''Note 2''' : Les tailles indiquées dans cet article dépendent de la version de GCC utilisé, et il est presque certain que vous obtiendrez des tailles différentes. Si il y a de trop gros écarts, c'est que vous avez fait une erreur, par exemple un cas que j'ai eu fréquement en TP : l'oubli du "AT >flash" pour le bloc de données placé en RAM, à l'adresse 0x10000000, soit 256Mo ... et produit un binaire de ... 256Mo :)

<div style="float:right">par Nathael Pajani</div>

<div style="clear:right"> </div>
Paru dans le [http://boutique.ed-diamond.com/home/851-open-silicium-14.html numéro 14] du magazine Open Silicium.

<div style="clear:both"> </div>

== Les documentations techniques ==

La première étape lorsqu'on veut écrire du code pour un système embarqué qui utilise un micro-contrôleur, c'est d'en trouver la documentation technique.

L'accès aux documentations techniques est à mon avis un des critères principaux dans le choix des composants pour un projet, aussi bien pour les concepteurs que pour les utilisateurs.

Si vous avez réalisé la conception du circuit, vous aurez normalement déjà eu besoin de ces documentations, dans le cas contraire, c'est le moment de les récupérer.
Pour le module GPIO-Démo, il y a plusieurs documentations techniques nécessaires pour utiliser la totalité des fonctionnalités du module.
La première et la plus importante est celle du micro-contrôleur [7], mais vous aurez aussi besoin de celle du module, disponible sur le site de Techno-Innov [4], et de celles de l'EEPROM I2C, et du capteur de température I2C.

Encart : Pour ce qui est du bridge USB-UART, la documentation n'est pas nécessaire pour la programmation du micro-contrôleur et du module, mais elle le devient si vous voulez modifier la façon dont le composant s'identifie lorsque vous le connectez, par exemple pour pouvoir lui donner un nom spécifique ou simplifier l'identification. Cela ne sera cependant pas le sujet de cet article.

Pour récupérer les documentations techniques, vous avez le choix entre le site du fabriquant et celui du distributeur chez qui vous avec acheté les composants. Pour la majorité des composants j'utilise le site du distributeur (possible uniquement si il fourni les bonnes documentations), mais pour les micro-contrôleurs je consulte le site du fabriquant car il fourni aussi les "errata" (notes d'informations contenant les corrections sur la documentation) et le plus souvent des notes d'application qui indiquent comment utiliser le composant pour telle ou telle application (avec parfois des exemples de code).

== Outils de programmation ==

La deuxième étape ne concerne toujours pas le code que vous voulez écrire.

En effet, pour écrire du code vous n'avez pas besoin de la "cible" (target en anglais) qui est le matériel sur lequel vous allez exécuter la version compilée du code, mais uniquement d'un poste de développement, couramment appelé hôte (host en anglais).

Cependant, la cible en question n'a que faire des fichiers sources qui se trouvent sur votre poste de développement, et il vous faudra un certain nombre d'outils pour passer des fichiers source (quelque soit le langage) au code exécutable par votre carte électronique.

C'est aussi un point très important à mon sens dans le choix d'un système embarqué ou d'un micro-contrôleur : quels sont les outils dont j'aurais besoin pour passer de mon code source à un système fonctionnant avec ?

Dans le cas des micro-contrôleurs de la gamme LPC de NXP il existe de nombreuses solutions pour passer de l'un à l'autre, mais ce qui est intéressant à mon sens c'est qu'il est possible de le faire avec un minimum de matériel et de logiciel : une liaison série "TTL 3.3V", une chaîne de compilation croisée et un utilitaire pour "uploader" le code binaire.

=== Matériel : un port USB (et le PC qui va avec) ===

[[Image:14-Module sur USB.png|300px|right]]

Pour ce qui est de la liaison série "TTL 3.3V", il existe plein d'adaptateurs USB-UART fonctionnant en 3.3V, et pour le cas du module GPIO-Démo cet adaptateur est intégré sur le module, un port USB suffit donc.

L'accès à cette liaison série se fera via un fichier spécial dont le nom sera devrait ressembler à "/dev/ttyUSB0", le "USB0" pouvant différer selon votre système ("USB1", USB2", ... ou même "ACM0" avec d'autres adaptateurs).

=== Compilation : GNU ===

Pour ce qui est de la chaîne de compilation croisée, les micro-contrôleurs LPC de NXP utilisent des cœurs ARM Cortex-M*, très bien supportés par gcc, bien connu de tous les lecteurs de ce magazine (du moins je le pense), et parfaitement adapté à la cross-compilation.

Dit comme ça, c'est simple ... mais en fait, pas tant que ça.
Cette problématique pourrait faire l'objet d'un (petit ?) article, je ne l'inclurai donc pas ici, je vous donne juste quelques pistes et suppose que vous saurez trouver les informations sur le net. De mon côté je dois les intégrer à la documentation technique du module GPIO-Démo, mais ce n'est pas encore fait à l'heure où j'écris ces lignes :( [4].

Si vous n'avez pas déjà une chaîne de cross-compilation installée pour ARM vous avez globalement trois solutions : Debian/EmDebian (celle que j'utilise), Launchpad, et Crosstools-ng.

Le projet EmDebian fournit des paquets debian pour différentes chaînes de cross-compilation (ARM parmi tant d'autres), qui sont entrain d'être intégrées à Debian. Cela devrait simplifier les problèmes de dépôts et de dépendances dont souffrait les dépôts EmDebian, même si seule la version "arm-none-eabi" (qui nous suffit, nous n'avons pas besoin de libC) est actuellement intégrée dans SID sans problèmes de dépendances (j'ai bien dit "devrait").

Le site de Launchpad fourni aussi des versions binaires de la chaîne de cross-compilation GCC ARM.

La solution CrossTools-ng : recompilation de sa propre chaîne de compilation croisée : la solution du dernier recours, si votre distribution ne fournit pas de solution packagée et que les versions binaires non signées ne vous conviennent pas.

=== Programmation : lpctools (ou autre) ===

Enfin, pour ce qui est de l'utilitaire permettant de charger (uploader) le code binaire sur le micro-contrôleur (flasher le micro-contrôleur), je n'avais pas trouvé d'outil libre permettant de réaliser cette étape au moment où j'ai étudié la possibilité d'utiliser les micro-contrôleurs de NXP, mais le protocole série permettant de réaliser cette opération était documenté dans la documentation technique des micro-contrôleurs, il ne devait donc pas y avoir de problème de ce côté là.

La seule solution "gratuite" que j'avais trouvé à l'époque ne fonctionnait que sur un seul système (pas le miens), ne fournissait pas ses sources, et interdisait une utilisation commerciale sans payer une licence, hors je voulais justement en faire une utilisation commerciale.

J'ai donc pris quelques heures de mon temps pour coder un utilitaire permettant de programmer les micro-contrôleurs LPC, et placé le tout sous licence GPL v3 [5].
Le tout est désormais disponible sur le site de Techno-Innov, et est intégré depuis peu à la distribution Debian GNU/Linux (Sid et Jessie à l'heure de l'écriture de ces lignes).

J'ai entre-temps découvert d'autres projets permettant de programmer des micro-contrôleurs LPC, mais je ne les ai pas testés (nxpprog - licence MIT, mxli - GPLv3, pyLPCTools - GPLv2) et constaté qu'un autre paquet Debian fournit les outils permetant de programmer les micro-contrôleurs LPC de NXP : lpc21isp (qui dispose d'ailleurs d'une interface graphique : GLPC, qui elle n'est pas dans les dépôts). Voir liens [6] en fin d'article.

== Makefile - particularités pour la compilation croisée ==

Une dernière petite étape avant d'écrire notre code, bien que l'on se rapproche de la programmation, puisqu'il s'agit d'un élément essentiel de tout projet : la création du Makefile.

Dans le cas de la compilation pour une cible comme le module GPIO-Démo le Makefile doit inclure quelques éléments supplémentaires que l'on ne retrouve habituellement pas dans un Makefile classique.

Le premier élément concerne la définition du compilateur à utiliser. Nous utiliserons la variable "CROSS_COMPILE" à laquelle nous affecterons une valeur par défaut correspondant au préfixe du compilateur. Si vous voulez utiliser un compilateur correctement installé sur le système, il suffit d'utiliser le préfixe, sinon, il faudra ajouter devant la totalité du chemin donnant accès au compilateur.

Par exemple pour le compilateur EmDebian :
: CROSS_COMPILE ?= arm-linux-gnueabi-
ou avec un chemin complet pour un autre compilateur :
: CROSS_COMPILE ?= /usr/local/mon/compilateur/bin/arm-none-eabi-

Le "?=" permet de ne modifier la variable que si elle n'existe pas, notamment si elle n'est pas déjà présente dans la ligne de commande.

Cette variable est ensuite utilisée pour modifier la variable "CC" utilisée par "make" pour compiler les fichiers de code source C. Si vous utilisez un autre langage, modifiez la variable correspondante.
: CC = $(CROSS_COMPILE)gcc
Il est aussi possible d'en profiter pour spécifier une version du compilateur installé :
: CC = $(CROSS_COMPILE)gcc-4.7
Nous allons en profiter pour définir la variable "LD" qui correspond à l'éditeur de liens (linker en anglais) :
: LD = $(CROSS_COMPILE)ld

Il nous faut ensuite définir la cible pour laquelle nous voulons compiler. Dans notre cas il s'agit d'un cœur ARM Cortex-M0, qui utilise le jeu d'instructions "thumb" (instructions sur 16bits permettant d'obtenir un code plus compact), nous allons donc utiliser les options -mcpu et -mthumb de gcc pour lui indiquer notre besoin :
: CPU = cortex-m0
: CFLAGS = -Wall -mthumb -mcpu=$(CPU)

En plus de cela, nous allons demander au compilateur de ne pas reconnaître les fonctions pour lesquelles il a une définition interne (builtin) tout simplement parce que la majorité de ces fonctions dépendent d'un environnement très différent de celui de notre micro-contrôleur, soit par la présence d'une bibliothèque C, d'un système d'exploitation respectant la norme POSIX, ou d'une unité de calcul flottant.
Rien de tout ceci n'est vrai dans notre cas, et il est donc préférable que le compilateur nous informe si nous tentons d'utiliser ces fonctions sans l'avoir explicitement demandé en utilisant le préfixe "__builtin__".

Nous demanderons aussi au compilateur de bien placer les données et les fonctions dans leurs sections respectives. Malgré ce que dit la documentation de GCC, cela permet (au moins dans notre cas) de produire un binaire plus petit. Cela se fait à l'aide des directives d'optimisation "-ffunction-sections" et "-fdata-sections".

Nous ajouterons ces directives dans une variable dédiée :
: FOPTS = -fno-builtin -ffunction-sections -fdata-sections

Nous obtenons donc les lignes suivantes à ajouter à votre Makefile :
: CROSS_COMPILE ?= arm-linux-gnueabi-
: CC = $(CROSS_COMPILE)gcc
: LD = $(CROSS_COMPILE)ld
: CPU = cortex-m0
: FOPTS = -fno-builtin -ffunction-sections -fdata-sections
: CFLAGS = -Wall -Wextra -mthumb -mcpu=$(CPU) $(FOPTS)

Notre Makefile ressemblerait alors à ceci :
NAME = mod_gpio
CROSS_COMPILE ?= arm-linux-gnueabi-
CC = $(CROSS_COMPILE)gcc
LD = $(CROSS_COMPILE)ld
CPU = cortex-m0
FOPTS = -fno-builtin -ffunction-sections -fdata-sections
CFLAGS = -Wall -Wextra -mthumb -mcpu=$(CPU) $(FOPTS)

.PHONY: all
all: $(NAME)

SRC = $(wildcard *.c)
OBJS = $(SRC:.c=.o)

$(NAME): $(OBJS)
$(LD) $^ -o $@
Ce Makefile est encore incomplet et ne permet pas d'obtenir le binaire pour notre micro-contrôleur, mais nous ajouterons les parties manquantes plus tard.

En attendant, ce Makefile nous permettra de compiler le code que nous allons écrire, passons donc aux parties intéressantes, et le reste du Makefile sera bien plus simple à comprendre.

== Commençons simple ==

Pour ne pas trop compliquer les choses dès le début, nous allons tenter de faire clignoter la led bicolore présente sur le module GPIO-Démo.

Notre squelette de code ressemblera à s'y méprendre à ce que l'on pourrait avoir pour un programme plus commun :
/*
* Notre exemple simple pour Open Silicium
*/
void system_init(void)
{
/* System init ? */
}

int main(void)
{
/* Micro-controller init */
system_init();

while (1) {
/* Change the led state */
/* Wait some time */
}
return 0;
}
Si vous compilez ce petit morceau de code avec notre Makefile, vous obtiendrez un binaire qui globalement ne fait rien, mais a déjà une taille de 5.7 Ko.
C'est gros pour ne rien faire, d'autant que la mémoire Flash de notre micro-contrôleur ne fait que 32 Ko.

Si on regarde plus loin, par exemple avec l'utilitaire ''file'', on obtient quelques informations supplémentaires :
$ file mod_gpio
mod_gpio: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), [....], not stripped

Arghhh, notre binaire est un exécutable dynamique au format ELF, qui utilise des bibliothèques partagées !

Nous l'avons déjà évoqué, notre micro-contrôleur n'a pas de libC ni de système d'exploitation, notre binaire ne peut donc pas être dynamique (lié dynamiquement à des bibliothèques) !
Il nous faut donc faire l'édition de lien en "static", en apportant quelques modification à notre Makefile. Nous allons introduire une variable "LDFLAGS", que l'on ajoutera à la règle de compilation utilisée pour l'édition de liens.
LDFLAGS = -static
$(NAME): $(OBJS)
$(LD) $^ $(LDFLAGS) -o $@
Recompilons notre projet ... 608 Ko !!! Re-Argh !

Visiblement quelqu'un ajoute du code dont nous n'avons pas besoin. Il faut du moins l'espérer, sinon il ne sera jamais possible de faire rentrer un programme dans la flash de notre micro-contrôleur, qui fait toujours 32Ko.

L'option "static" demande à l'éditeur de lien de créer un binaire statique, mais résultat il nous ajoute tout ce qui est utile de la libC pour un exécutable ... pour un système Linux.
D'ailleurs, ''file'' nous dit bien que notre exécutable est au format ELF.

Pour commencer nous allons demander à l'éditeur de liens (ld) de ne pas inclure les éléments de démarrage dans notre binaire, car ils sont inutiles sur notre micro-contrôleur. Pour cela nous ajoutons l'option "-nostartfiles" à nos directives pour l'édition de liens.

Et hop, une recompilation plus tard, notre binaire ne fait plus que 1 Ko :)
Mais pour ''file'', ce binaire est toujours au format ELF, et gcc nous informe qu'il n'a pas trouvé de symbole d'entrée "_start" et qu'il utilise une adresse par défaut (nous l'avons cherché, cela fait partie de ce que nous avons demandé à l'éditeur de liens en ajoutant l'option "-nostartfiles").

En effet, le "main" de nos programmes en C n'est que le point de départ de l'exécution de notre code, mais pas celui du programme. Il est précédé par un certain nombre de routines (fonctions) d'initialisation, dont le point d'entrée est la routine "_start", qui appellera le main "classique".

Mais notre but n'est pas de créer un exécutable pour un système Linux, nous devons créer un binaire pour notre micro-contrôleur. Il est désormais temps de nous plonger dans la documentation du micro-contrôleur pour comprendre comment il démarre, pour pouvoir adapter notre code au démarrage du micro-contrôleur et fournir l'équivalent de cette routine "_start".

== Bootstrap ==

=== Table des vecteurs d'interruption ===

Pour avoir des informations sur le démarrage du micro-contrôleur LPC1224 dans sa documentation technique [7] il y a deux chapitres intéressants.

Nous pouvons nous référer au chapitre 4 (LPC122x System control) qui inclut une section sur le reset du micro-contrôleur (4.6 : Reset), dans laquelle on apprend qu'une fois que la condition de reset disparait et que les procédures internes se sont exécutées, le processeur commence l'exécution à l'adresse contenue dans le vecteur "Reset" du "boot block".

Nous avons ainsi quelques informations, mais qu'est-ce que le vecteur "Reset" et le "boot block" ? Cela nous mène au deuxième chapitre intéressant, le chapitre 25 sur le cœur ARM Cortex-M0. On y trouve une section sur le processeur (25.3 : Processor) avec une sous section concernant les exeptions (25.3.3 : Exception model).

Dans les informations sur les exceptions (25.3.3.2), et plus particulièrement l'exception "Reset", il est indiqué qu'après un "Reset" l'exécution reprend à l'adresse indiquée dans le vecteur "Reset" dans la table des vecteurs d'interruption.

Bien, cela confirme ce qui se trouvait dans le chapitre 4. Mais cette fois, nous avons une sous-section "25.3.3.4 Vector table", qui décrit cette fameuse table des vecteurs d'exception, précisant qu'elle contient l'addresse de toutes les routines de gestion des exceptions (les fameux "vecteurs" d'exception, dont le vecteur "Reset").

Remarquez au passage que les interruptions sont gérées de la même façon, l'addresse d'entrée des routines de gestion des interruptions se trouve dans cette même table.

Et en dessous de cette table, nous avons une autre information très intéressante : "The vector table is fixed at address 0x00000000".

Si l'on se réfère à la table 65 de la section "25.3.2 Memory model", et à la figure 2 de la section "2.3 Memory allocation", on découvre que cette adresse est en fait le début de la mémoire flash du micro-contrôleur, qui devra contenir notre code binaire.

Reste à créer cette table, et à la placer au bon endroit dans le code binaire compilé...

=== Les "handlers" et les "dummy handlers" ===

Nous allons commencer par la partie code.
Ce code peut être placé dans le même fichier que celui ou ce trouve notre fonction main, ou dans un autre fichier, cela n'a pas d'importance. Si vous vous référez au code du module GPIO-Démo disponible dans les dépôts git de Techno-Innov, vous trouverez ce code dans le fichier "core/bootstrap.c".

[[Image:Vecteurs_interruption.png|350px|right]]

/* Cortex M0 core interrupt handlers */
void Reset_Handler(void);
void NMI_Handler(void) __attribute__ ((weak, alias ("Dummy_Handler")));
void HardFault_Handler(void) __attribute__ ((weak, alias ("Dummy_Handler")));

void Dummy_Handler(void);

void *vector_table[] = {
0,
Reset_Handler,
NMI_Handler,
HardFault_Handler,
0,
/* [......] */
};

void Dummy_Handler(void) {
while (1);
}

void Reset_Handler(void) {
/* Our program entry ! */
}

Voici un petit morceau de code relativement court qui définit notre table de vecteur ainsi que les routines de gestion correspondantes.

Avant d'aller plus loin, faisons un petit point sur certains éléments : les attributs utilisés pour la déclaration de deux de nos routines de gestion des exceptions : "__attribute__ ((weak, alias ("Dummy_Handler")))"

Ces attributs permettent de définir un alias "faible" pour une fonction, ce qui veut dire que si le compilateur ne trouve pas de définition pour cette fonction, il pourra utiliser son alias, que nous avons défini plus bas. Au contraire, si dans un autre fichier (ou celui-ci) vous définissez l'une de ces fonctions, c'est votre définition qui sera utilisée.

Note : je n'ai pas mis la totalité de la table des vecteurs, cela n'a pas d'intérêt pour les explications, et notre programme fonctionnera sans, mais il faudrait la compléter pour un vrai programme, en faisant attention à l'ordre, à partir des informations de la figure 68 déjà évoquée, et de la table 4 du chapitre 3 concernant le gestionnaire d'interruptions (vous noterez la typo, il s'agit des numéros d'IRQ et non pas des numéros des vecteurs d'exception).

=== Appeler notre main() ===
Ce petit bout de code compile donc, puisque tout est défini, mais nous avons toujours l'avertissement concernant le symbole d'entrée "_start" qui n'a pas été trouvé. Nous ne sommes pas plus avancé.

Tout d'abord, nous avons déjà indiqué que le point d'entrée de notre code est la fonction main() (qui pourrait avoir n'importe quel nom), mais pour notre micro-controlleur la fonction d'entrée du programme est la routine de gestion de l'exception "Reset".

La solution pour faire le lien est toute simple : il suffit d'appeler la fonction main() depuis la routine de gestion de l'exception "Reset".
int main(void);
void Reset_Handler(void) {
/* Our program entry ! */
main();
}

=== Tisser des liens, c'est important ===
Cela ne résout cependant aucun de nos problèmes, nous allons donc devoir donner plus d'indications à l'éditeur de liens, en créant un script pour l'édition de lien (lpc_link_lpc1224.ld). Nous donnerons le nom de ce script à l'éditeur de liens en utilisant l'otion "-T''lpc_link_lpc1224.ld''".

Ce script d'édition de lien ("linker script" en anglais) est en fait un fichier qui décrit la mémoire de notre micro-contrôleur, ainsi que l'organisation que devra respecter notre binaire.

Nous allons donc commencer, toujours à partir des mêmes informations en provenance de la documentation technique, par définir quelle est la mémoire disponible, aussi bien la mémoire "vive" (SRAM) que la mémoire "morte" (FLASH).

MEMORY
{
sram (rwx) : ORIGIN = 0x10000000, LENGTH = 4k
flash (rx) : ORIGIN = 0x00000000, LENGTH = 32k
}
Nous définissons ainsi l'adresse et la taille (et les droits d'accès) de la sram et de la flash, qui deviennent deux blocs de mémoire disponibles pour l'éditeur de liens, qui pourra donc y placer du code et des données.

Il nous faut maintenant expliquer à l'éditeur de liens comment organiser le code et les données dans ces blocs de mémoire, et tout particulièrement notre tableau de vecteurs d'interruptions

Le code d'un programme est composé de "sections", dans lesquelles le compilateur place chaque fonction et chaque variable en fonction de différents critères, que l'on peut contrôler soit à partir de directives de compilation, soit d'attributs ajoutés dans notre code C

Nous allons donc modifier notre tableau de vecteurs d'interruptions pour lui ajouter un attribut "section" qui forcera l'éditeur de liens à le placer dans la section que nous avons défini.
: void *vector_table[] __attribute__ ((section(".vectors"))) = {

Et en parallèle, nous allons définir dans notre script quelles sont les sections que nous voulons trouver dans notre binaire, et dans quel ordre.
Commençons simple (si si, je vous assure), nous compliquerons plus tard :
SECTIONS {
. = ORIGIN(flash);
.text :
{
KEEP(*(.vectors))
*(.text*)
*(.rodata*)
} >flash
.data :
{
*(.data*)
*(.bss*)
} >sram
}
Pour commencer, nous définissons l'adresse courante (.) comme étant l'origine de du bloc de mémoire "flash" (le bloc de mémoire défini précédemment et auquel nous avons donné ce nom, bien qu'un autre nom aurait pu faire l'affaire).
Ceci est important pour que l'éditeur de liens puisse définir les adresses des fonctions pour l'exécution de notre code.
À partir de ce point nous définissons une section "text", dans laquelle nous allons demander à l'éditeur de lien de mettre plusieurs éléments, à commencer par notre fameuse table de vecteurs, en lui interdisant d'en changer la position !
Après quoi, nous lui demandons de placer l'ensemble du code, que le compilateur a placé dans des section ".text.*", puis les données en lecture seule (Read-Only data = rodata), et de placer le tout dans le bloc de mémoire "flash".

À la suite, nous créons une section "data", dans laquelle nous lui demandons de placer les données initialisées à des valeurs non nulles (data), puis les données initialement nulles (bss [8]), et de placer cette section en RAM.

Ne reste plus qu'une information à donner à l'éditeur de liens (pour l'instant): le point d'entrée de notre programme.
Ceci est relativement simple et explicite :
: ENTRY(Reset_Handler)

Dans notre Makefile la variable LDFLAGS devient :
: LDFLAGS = -static -nostartfiles -Tlpc_link_lpc1224.ld

Une compilation plus tard, sans avertissements cette fois, nous avons un binaire ... beaucoup trop gros : notre binaire fait maintenant plus de 66 Ko !

Soyons un peu curieux et allons donc voir ce qu'il contient, mais pas à la main, rassurez vous, utilisons un utilitaire fait exprès pour cela : ''objdump''. attention, il faut bien entendu utiliser la version "ARM" de objdump, donc avec le préfixe "CROSS_COMPILE", soit dans mon cas ''arm-linux-gnueabi-objdump'', avec l'option ''--disassemble-all'' (-D) :
: arm-linux-gnueabi-objdump -D mod_gpio > dump
Et là, surprise, la version "désassemblée" de notre binaire est plus petite que la version binaire (le fichier "dump" fait 2.2 Ko).

Regardons tout de même son contenu.
La première ligne nous informe que le format du fichier est "elf32-littlearm" ... pas grand chose à voir avec ce que nous voulions, un "simple" binaire (Notre micro-contrôleur n'a toujours pas appris à lire les exécutables au format ELF). Premier problème.

Quelqu'un est venu glisser une section ".note.gnu.build-id" avant notre section ".text", que l'éditeur de liens aimerait placer en début de RAM ("10000000 <_sram_base>"), ce qui n'a pas d'intérêt pour nous.

S'en suit tout de même notre section ".text", qui commence bien par notre table (enfin ! on nous écoute un peu !), suivie de nos quelques maigres fonctions. Notez les adresses des fonctions dans la table des vecteurs, qui sont toutes impaires. Ceci indique que notre processeur exécutera ces fonctions en mode "thumb" qui est bien le mode que nous avions demandé (-mthumb).

Et encore une fois, notre section ".text" n'est pas suivie de nos données, mais d'autres sections que nous n'avions pas demandées !
Certes, nous n'avons pas de variables, et l'éditeur de lien n'ayant rien à mettre dans notre section ".data", il ne l'a pas créée, mais au final nous sommes relativement loin de ce que nous voulions.

Nous allons donc demander à l'éditeur de liens de générer un petit peu moins de choses en ajoutant l'option ''-Wl,--build-id=none'' à nos directives de compilation (variable LDFLAGS de notre Makefile), ce qui nous donne un binaire moitié plus petit mais toujours trop gros.

=== Un binaire vraiment binaire ===
Mais nous ne pouvons pas en demander bien plus à l'éditeur de liens, dont le travail est de créer des exécutables au format ELF.
Pour créer d'autres types de binaire, nous devrons utiliser l'utilitaire ''objcopy'' (toujours la version ARM, donc en fait ''arm-linux-gnueabi-objcopy'').
Le travail de cet utilitaire est de créer des binaires à partir des exécutables ELF, en ne conservant que les sections qui nous intéressent (du moins, c'est l'usage que nous en ferons).

Nous allons demander à cet utilitaire de nous générer une image binaire à partir du résultat de notre compilation en ajoutant dans notre Makefile une cible "$(NAME).bin" qui deviendra notre cible par défaut et dépendra de la génération du fichier au format ELF :

all: $(NAME).bin

$(NAME).bin: $(NAME)
$(CROSS_COMPILE)objcopy -O binary $^ $@

Et notre objectif est enfin atteint, avec un binaire de ... 36 octets !<br />
Rappelez vous, je n'ai mis que 5 entrées dans ma table de vecteurs, soit 20 octets, suivis de quelques fonctions vides. Tout va bien.

== Un programme un peu plus utile ==

Nous allons désormais pouvoir nous occuper d'allumer nos Leds, en quelque sorte le "Hello world" de l'électronique.

=== Entrées et sorties ===
Du point de vue de notre micro-contrôleur, allumer ou éteindre une Led revient à changer l'état de la sortie correspondante.

Les entrées/sorties du microcontrôleur peuvent avoir plusieurs fonctions, mais hormis quelques exceptions elles sont par défaut configurées en entrées/sorties (GPIO (general Purpose Input Output) en anglais) avec la résistance de pull-up interne activée. Pour simplifier, nous laisserons donc cette étape de la configuration de côté pour l'instant, et reviendrons dessus lorsque nous attaquerons la programmation d'interfaces plus complexes.

: Note : Les exceptions sont les GPIO 13, 25 et 26 du port 0 (respectivement Reset, SWDIO et SWDCLK), qui permettent le reset et le debug, ainsi que quatre GPIO sur lesquelles la fonction "0" est réservée : les GPIO 30 et 31 du port 0 et les GPIO 0 et 1 du port 1.

=== Les registres ===
Pour changer l'état d'une de ces entrées/sorties, il faut commencer par la configurer en sortie, puis définir sont état.

Avant d'aller plus loin, il est important de comprendre que le processeur de notre micro-contrôleur ne voit que de la mémoire autour de lui. Il n'a pas accès directement aux signaux électriques.
Pour accéder aux fonctions spéciales comme l'état électrique d'une sortie le processeur doit donc modifier des données dans une zone mémoire spécifique, dédiée à cette sortie, que l'on appelle un registre.

Notre micro-contrôleur dispose d'un grand nombre de registres qui ont tous une taille de 32 bits, même si souvent certains bits ne sont pas utilisés (ils sont alors "réservés").
Ces registres particuliers, qui nous donnent accès aux fonctions spéciales du micro-contrôleur, comme la configuration et l'état des entrées sorties, sont accessibles chacun à une adresse fixe dans l'espace d'adressage du micro-contrôleur.

Nous avons déjà eu besoin d'informations sur cet espace d'adressage lorsque nous avons cherché des informations sur le démarrage du micro-contrôleur, il se trouve représenté sur la figure 2 dans la section "2.3 Memory allocation" du chapitre 2 (LPC122x Memory map).

L'adresse qui nous intéresse dépend du port sur lequel les leds sont connectées.
La led bicolore étant connectée sur le port 1 ce sont les registres présents à l'adresse 0x50010000 que nous devrons utiliser.
Cette adresse est aussi rappelée avec la description des registres dans le chapitre 8 (LPC122x General Purpose I/O (GPIO))

À partir de cette adresse se trouvent une série de registres permettant de contrôler les entrées/sorties du port 1. La modification du contenu de la mémoire accessible ainsi modifiera donc le comportement des entrées/sorties correspondantes ou leur état lorsqu'elles sont configurées en sortie.

Très (trop) souvent, pour accéder à ces registres, les programmeurs utilisent des définitions selon le principe suivant:
#define LPC_AHB_BASE (0x50000000UL)
#define LPC_GPIO_1_BASE (LPC_AHB_BASE + 0x10000)
#define PORT1_MASK (LPC_GPIO_1_BASE + 0x00)
#define PORT1_PIN (LPC_GPIO_1_BASE + 0x04)
#define PORT1_OUT (LPC_GPIO_1_BASE + 0x08)
/* [.....] */
Personnellement je trouve cette façon de faire très inefficace, et peu lisible (voire complètement illisible), et je préfère l'utilisation de structures.
Cela me semble beaucoup plus lisible, plus adapté pour accéder à de la mémoire qui est structurée, et apporte aussi un très net avantage lorsqu'il existe plusieurs ensembles de registres utilisant la même organisation, par exemple quand il y a plusieurs liaisons séries sur le micro-contrôleur, ou dans le cas qui nous intéresse pour l'instant, plusieurs ports d'entrées/sorties.
La définition se passe alors ainsi :
#define LPC_AHB_BASE (0x50000000UL)
#define LPC_GPIO_0_BASE (LPC_AHB_BASE + 0x00000)
#define LPC_GPIO_1_BASE (LPC_AHB_BASE + 0x10000)
/* General Purpose Input/Output (GPIO) */
struct lpc_gpio
{
volatile uint32_t mask; /* 0x00 : Pin mask, affects data, out, set, clear and invert */
volatile uint32_t in; /* 0x04 : Port data Register (R/-) */
volatile uint32_t out; /* 0x08 : Port output Register (R/W) */
volatile uint32_t set; /* 0x0C : Port output set Register (-/W) */
volatile uint32_t clear; /* 0x10 : Port output clear Register (-/W) */
volatile uint32_t toggle; /* 0x14 : Port output invert Register (-/W) */
uint32_t reserved[2];
volatile uint32_t data_dir; /* 0x20 : Data direction Register (R/W) */
/* [.....] */
};
#define LPC_GPIO_0 ((struct lpc_gpio *) LPC_GPIO_0_BASE)
#define LPC_GPIO_1 ((struct lpc_gpio *) LPC_GPIO_1_BASE)
À noter, l'utilisation du mot clé "volatile" qui interdira au compilateur d'optimiser les accès à ces registres en gardant des copies intermédiaires, forçant la lecture ou l'écriture immédiate.

Cette notation nous donne aussi l'information de la taille des données présentes à ces adresses, dans ce cas là, des valeurs sur 32 bits.

Pour l'utilisation dans le code, c'est ensuite très simple, il suffit de déclarer un pointeur vers cette structure, puis d'accéder au champ qui nous intéresse :
struct lpc_gpio* gpio1 = LPC_GPIO_1;
gpio1->out = 0;

=== Allumer les leds ===

Reste à déterminer quels sont les champs qui nous intéressent et quelles valeurs nous devons écrire dedans.
Pour configurer les pins reliées à nos Leds en sortie nous devons modifier le registre "DIR" (appelé "data_dir" dans la structure), et mettre les bits 4 et 5 à "1" puisque chaque bit de ce registre permet de configurer une des pins du port correspondant, le bit 0 pour la pin 0, le bit 1 pour la pin 1, et ainsi de suite (attention, ici les numéros de pins ne sont pas les numéros des pattes du composant).

Nous pouvons donc modifier notre main() pour obtenir le code suivant qui réalise cette opération de façon lisible, et positionne la Led verte à l'état "allumée", sans modifier l'état des autres sorties du port 1 :
/* The status LED is on GPIO Port 1, pin 4 (PIO1_4) and Port 1, pin 5 (PIO1_5) */
#define LED_RED 5
#define LED_GREEN 4
int main(void)
{
struct lpc_gpio* gpio1 = LPC_GPIO_1;
/* Micro-controller init */
system_init();
/* Configure the Status Led pins */
gpio1->data_dir |= (1 << LED_GREEN) | (1 << LED_RED);
/* Turn Green Led ON */
gpio1->set = (1 << LED_GREEN);
gpio1->clear = (1 << LED_RED);
while (1) {
/* Change the led state */
/* Wait some time */
}
}

[Encart : Décalages de bits] :
: La notation "<<" correspond à l'opérateur logique "décalage de bits vers la gauche" (">>" pour le décalage à droite). Voir l'article wikipedia sur le sujet, en Anglais, la version Française étant catastrophiquement incomplète [9].

== Mettre le code sur le micro-contrôleur : lpctools ==

Je sais que vous êtes de plus en plus impatients et que vous voulez voir le résultat de tout ceci en vrai, nous allons donc passer à la mise en flash sur le micro-contrôleur pour tester tout cela.

Je ne traiterais ici que le cas de la version 48 broches du micro-contrôleur LPC1224 (package LQFP48). A vous d'adapter si vous utilisez un autre micro-contrôleur, le principe étant très similaire pour tous les LPC de NXP. Pour les autres gammes de micro-contrôleurs, référez vous à leurs docs techniques et aux informations sur Internet.

=== Connexion ===
Si vous avez mis l'adaptateur USB-UART sur votre module comme proposé dans les articles précédents, l'étape de connexion au PC est simple, connectez votre module sur un port USB, directement ou via un câble en fonction du connecteur USB que vous avez choisi.

Sinon, il vous faudra un adaptateur USB-UART (souvent vendus comme adaptateurs USB-série) fonctionnant en 3.3V, et relier les signaux Rx et Tx aux signaux TXD0 et RXD0 correspondant à l'UART 0 du micro-contrôleur LPC1224 qui se trouvent sur le port 0, pins 1 et 2 (broches 16 et 17 du composant). Il est alors préférable d'avoir rendu ces signaux accesssibles sur un connecteur de votre choix, sans quoi il vous faudra souder des fils directement sur les pattes du micro-contrôleur ... possible, mais pas conseillé du tout).

=== Mode ISP ===

Il faut ensuite mettre le micro-contrôleur en mode programmation (ISP : "In System Programming" en anglais). Le chapitre 20 (LPC122x Flash ISP/IAP) indique qu'il faut maintenir la pin 12 du port 0 (broche 27) à l'état bas (0V) pendant au moins 3ms après avoir relaché le signal "Reset" (pin 13 du port 0, broche 28). La suite du chapitre décrit le protocole de programmation, uniquement utile si vous voulez créer votre propre utilitaire pour programmer le micro-contrôleur, ou si vous voulez réaliser des opérations très spécifiques.

Puisque nous avons placé des boutons poussoir reliant ces signaux à la masse, avec des résistance de "pull-up", cette opération est très simple : il faut appuyer sur les deux boutons en même temps, puis relacher le bouton reset avant de relacher le bouton ISP.
Lorsque tout c'est bien passé, la led bicolore doit avoir deux petits points lumineux à peine visibles dans l'obscurité (un rouge et un vert).

=== Dialogue avec le micro-contrôleur ===

La suite se passe sur le PC. Le paquet lpctools contient deux binaires : lpcisp et lpcprog.
Le premier donne accès aux opérations élémentaires du protocole de programmation, et ne nous sera pas utile. Le second permet de programmer le micro-contrôleur en utilisant une unique commande, bien que d'autres commandes permettent d'effectuer quelques opérations intéressantes.

Nous allons d'ailleurs commencer par une de ces autres opération : demander les identifiants de notre micro-contrôleur avec la commande "id".
La syntaxe des commandes lpcprog est simple, il suffit de lui passer un nom de device, que l'on passe comme argument de l'option "-d", une commande (argument de l'option "-c"), et si besoin le nom du fichier à utiliser.
Dans l'exemple suivant le module GPIO-Démo est identifié sur le poste de développement comme périphérique "ttyUSB0", nous utiliserons donc le ''device'' "/dev/ttyUSB0".
$ lpcprog -d /dev/ttyUSB0 -c id
Part ID 0x3640c02b found on line 26
Part ID is 0x3640c02b
UID: 0x2c0cf5f5 - 0x4b32430e - 0x02333834 - 0x4d7c501a
Boot code version is 6.1
La première ligne nous indique que lpcprog a reconnu le micro-contrôleur et qu'il sera donc possible de le programmer. (Si ce n'est pas le cas, vous devrez compléter le fichier de description des micro-contrôleurs).
Ensuite, lpcprog nous donne les informations propres au micro-contrôleur, à savoir son identifiant unique et la version du "boot code" qui se trouve en rom sur le micro-contrôleur.

Si vous avez un affichage similaire, tout va bien.
Sinon, vérifiez la connexion et que le micro-contrôleur est bien en mode ISP.

La programmation se fait ensuite très simplement avec la commande "flash", en ajoutant le nom du fichier binaire à envoyer.
$ lpcprog -d /dev/ttyUSB0 -c flash mod_gpio.bin
Part ID 0x3640c02b found on line 26
Flash now all blank.
Checksum check OK
Flash size : 32768, trying to flash 1 blocks of 1024 bytes : 1024
Writing started, 1 blocks of 1024 bytes ...
lpcprog se charge d'effacer la flash, de générer la somme de contrôle de l'entête et de la placer au bon endroit dans le binaire, et d'envoyer le tout au micro-contrôleur pour mise en flash.

Pour tester, il suffit d'appuyer sur le bouton Reset, et de constater qu'il ne se passe rien, ce qui n'est pas ce que nous attendions.

Il y a plusieurs problèmes.

=== Votre code s'il vous plait ! ===

Le premier vient de la génération de la somme de contrôle, ou plutôt de sa position dans notre binaire.
Tous les LPC de NXP utilisent (à ce jour de ce que j'ai pu voir) le même mécanisme pour déterminer si la flash contient une image valide avant d'essayer d'exécuter son contenu : la vérification du checksum des 8 premiers vecteurs d'interruption, qui doit être nulle.

Pour que ceci soit possible, conformément à la documentation technique des micro-contrôleurs, lpcprog calcule le complément à 2 des 7 premiers vecteurs, et le place dans le huitième.

Sauf que notre tableau ne fait pour l'instant que 5 "cases" et que la huitième case contenait en fait notre code exécutable, qui a été écrasé.

La première modification est donc de remplir au moins 8 cases de ce tableau, au pire avec des valeurs nulles, sinon, avec des valeurs correspondant à ce qui est attendu dans la documentation : les adresses des routines de gestion, ou au moins celle de notre routine "de remplacement" (Dummy_Handler()) lorsque la documentation indique que l'emplacement est utilisé (table 363 et figure 68 pour les exceptions, et table 4 pour les interruption).
void *vector_table[] __attribute__ ((section(".vectors"))) = {
0, /* 0 */
Reset_Handler,
NMI_Handler,
HardFault_Handler,
0,
0, /* 5 */
0,
/* Entry 7 (8th entry) must contain the 2’s complement of the check-sum
of table entries 0 through 6. This causes the checksum of the first 8
table entries to be 0 */
(void *)0xDEADBEEF, /* Actually, this is done using an external tool. */
0,
/* [.....] voir le code du module GPIO-Demo pour la suite */
};

Cependant ceci n'est pas suffisant (vous pouvez désormais le tester très simplement, je vous laisse faire).

=== Un peu de place pour la pile ===

Le dernier point un petit peu particulier est encore sur cette fameuse table des vecteurs, et concerne la première entrée.
Si vous regardez attentivement la figure 68, le vecteur "Reset" n'est que la deuxième entrée de la table.
La première est la valeur initiale du pointeur de la pile (Stack pointer), qui correspond en fait à son sommet puisque cette pile est remplie en faisant décroître les adresses (cette information se trouve dans le chapitre 25, mais cette fois je vous laisse chercher un petit peu).

Nous avons initialisé cette valeur à 0, ce qui forcément pose un soucis.

Pour obtenir la bonne valeur, nous pourrions coder en dur l'adresse du haut de notre sram, mais ce n'est pas propre.
Pour que tout soit fait correctement et automatiquement, nous allons modifier le script de l'édition de liens, et demander à '''ld''' de remplir cette adresse à notre place, en fonction de l'adresse de la sram et de sa taille.

Nous allons donc créer des variables dans notre script, juste après la définition de la mémoire disponible, et chose très importante, ces variables seront des variables externes utilisables dans notre code C !
: _sram_size = LENGTH(sram);
: _sram_base = ORIGIN(sram);
: _end_stack = (_sram_base + _sram_size);
Nous appelons le bas de la pile (la "fin" de la pile) '''_end_stack''', et plaçons cette fin de pile tout en haut de la mémoire vive.

Et pour l'utilisation dans notre code C, tout simplement :
extern unsigned int _end_stack;
void *vector_table[] __attribute__ ((section(".vectors"))) = {
&_end_stack, /* Initial SP value */ /* 0 */
Reset_Handler,
...

Si vous compilez votre code avec ces modifications, vous obtenez enfin un binaire qui allume la Led !

== Conclusion ==

Nous avons enfin notre "Hello World !" version électronique, mais la route est encore longue.

Vous pourrez voir dans le prochain article que cette première étape n'était qu'une étape, et qu'il reste encore plusieurs étapes importantes avant de pouvoir vraiment commencer à écrire du code "fonctionnel", comme la gestion du "watchdog", la configuration de l'horloge interne, l'initialisation de la mémoire, et l'écriture des drivers pour chaque bloc fonctionnel (liaison série, I2C, SPI, ADC, ....).

Rendez-vous donc pour le second article dédié à la programmation de notre micro-contrôleur.

Merci pour votre lecture attentive !

== Les fichiers créés ==
Vous trouverez sur notre serveur le [http://techdata.techno-innov.fr/Modules/GPIO_Demo/Code_LM/Article_5/Makefile Makefile], le fichier C [http://techdata.techno-innov.fr/Modules/GPIO_Demo/Code_LM/Article_5/main.c main.c], et le script de lien [http://techdata.techno-innov.fr/Modules/GPIO_Demo/Code_LM/Article_5/lpc_link_lpc1224.ld lpc_link_lpc1224.ld]

== Liens - Bibliographie ==
* [1] https://gcc.gnu.org/onlinedocs/gcc-4.7.4/gcc/Option-Summary.html
* [2] https://sourceware.org/binutils/docs/binutils/objdump.html
* [3] https://sourceware.org/binutils/docs/binutils/readelf.html
* [4] Page du module et Manuel utilisateur : http://www.techno-innov.fr/technique-module-gpio-demo/ - http://techdata.techno-innov.fr/Modules/GPIO_Demo/System_Reference_Manual_Module_GPIO_Demo_v03.pdf
* [5] Dépôt GIT lpctools : http://git.techno-innov.fr/?p=lpctools
* [6] Lien vers d'autres outils pour programmer les LPC :
** mxli : http://www.windscooting.com/softy/mxli.html
** lpc21isp : http://sourceforge.net/projects/lpc21isp/
** nxpprog : http://sourceforge.net/projects/nxpprog/
** GLPC (GUI pour lpc21isp) : http://sourceforge.net/projects/glpc/
* [7] Manuel utilisateur du LPC1224 : http://www.nxp.com/documents/user_manual/UM10441.pdf
* [8] http://fr.wikipedia.org/wiki/Segment_BSS
* [9] http://en.wikipedia.org/wiki/Bitwise_operation

Articles/Nathael/Domotab et elec Libre partie5

2020-09-02T21:16:03Z

Nathael : /* Tisser des liens, c'est important */

{{DISPLAYTITLE:Électronique et domotique libre - partie 5 : Programmation, Premiers signes de vie}}
<div style="float:left; margin-right: 2.5em;">__TOC__</div>

[[Image:DomoTab.png|200px|right]]
Programmation du module !

Nous avons vu dans le quatrième article comment fabriquer le module GPIO-Démo (ou toute version modifiée), nous allons désormais nous atteler à lui donner vie.

'''Note 1''' : La programmation sera faite en C, bien que d'autres langages puissent être utilisés, à la seule condition qu'il existe un compilateur qui puisse générer du code binaire pour ARM à partir de ce langage.

'''Note 2''' : Les tailles indiquées dans cet article dépendent de la version de GCC utilisé, et il est presque certain que vous obtiendrez des tailles différentes. Si il y a de trop gros écarts, c'est que vous avez fait une erreur, par exemple un cas que j'ai eu fréquement en TP : l'oubli du "AT >flash" pour le bloc de données placé en RAM, à l'adresse 0x10000000, soit 256Mo ... et produit un binaire de ... 256Mo :)

<div style="float:right">par Nathael Pajani</div>

<div style="clear:right"> </div>
Paru dans le [http://boutique.ed-diamond.com/home/851-open-silicium-14.html numéro 14] du magazine Open Silicium.

<div style="clear:both"> </div>

== Les documentations techniques ==

La première étape lorsqu'on veut écrire du code pour un système embarqué qui utilise un micro-contrôleur, c'est d'en trouver la documentation technique.

L'accès aux documentations techniques est à mon avis un des critères principaux dans le choix des composants pour un projet, aussi bien pour les concepteurs que pour les utilisateurs.

Si vous avez réalisé la conception du circuit, vous aurez normalement déjà eu besoin de ces documentations, dans le cas contraire, c'est le moment de les récupérer.
Pour le module GPIO-Démo, il y a plusieurs documentations techniques nécessaires pour utiliser la totalité des fonctionnalités du module.
La première et la plus importante est celle du micro-contrôleur [7], mais vous aurez aussi besoin de celle du module, disponible sur le site de Techno-Innov [4], et de celles de l'EEPROM I2C, et du capteur de température I2C.

Encart : Pour ce qui est du bridge USB-UART, la documentation n'est pas nécessaire pour la programmation du micro-contrôleur et du module, mais elle le devient si vous voulez modifier la façon dont le composant s'identifie lorsque vous le connectez, par exemple pour pouvoir lui donner un nom spécifique ou simplifier l'identification. Cela ne sera cependant pas le sujet de cet article.

Pour récupérer les documentations techniques, vous avez le choix entre le site du fabriquant et celui du distributeur chez qui vous avec acheté les composants. Pour la majorité des composants j'utilise le site du distributeur (possible uniquement si il fourni les bonnes documentations), mais pour les micro-contrôleurs je consulte le site du fabriquant car il fourni aussi les "errata" (notes d'informations contenant les corrections sur la documentation) et le plus souvent des notes d'application qui indiquent comment utiliser le composant pour telle ou telle application (avec parfois des exemples de code).

== Outils de programmation ==

La deuxième étape ne concerne toujours pas le code que vous voulez écrire.

En effet, pour écrire du code vous n'avez pas besoin de la "cible" (target en anglais) qui est le matériel sur lequel vous allez exécuter la version compilée du code, mais uniquement d'un poste de développement, couramment appelé hôte (host en anglais).

Cependant, la cible en question n'a que faire des fichiers sources qui se trouvent sur votre poste de développement, et il vous faudra un certain nombre d'outils pour passer des fichiers source (quelque soit le langage) au code exécutable par votre carte électronique.

C'est aussi un point très important à mon sens dans le choix d'un système embarqué ou d'un micro-contrôleur : quels sont les outils dont j'aurais besoin pour passer de mon code source à un système fonctionnant avec ?

Dans le cas des micro-contrôleurs de la gamme LPC de NXP il existe de nombreuses solutions pour passer de l'un à l'autre, mais ce qui est intéressant à mon sens c'est qu'il est possible de le faire avec un minimum de matériel et de logiciel : une liaison série "TTL 3.3V", une chaîne de compilation croisée et un utilitaire pour "uploader" le code binaire.

=== Matériel : un port USB (et le PC qui va avec) ===

[[Image:14-Module sur USB.png|300px|right]]

Pour ce qui est de la liaison série "TTL 3.3V", il existe plein d'adaptateurs USB-UART fonctionnant en 3.3V, et pour le cas du module GPIO-Démo cet adaptateur est intégré sur le module, un port USB suffit donc.

L'accès à cette liaison série se fera via un fichier spécial dont le nom sera devrait ressembler à "/dev/ttyUSB0", le "USB0" pouvant différer selon votre système ("USB1", USB2", ... ou même "ACM0" avec d'autres adaptateurs).

=== Compilation : GNU ===

Pour ce qui est de la chaîne de compilation croisée, les micro-contrôleurs LPC de NXP utilisent des cœurs ARM Cortex-M*, très bien supportés par gcc, bien connu de tous les lecteurs de ce magazine (du moins je le pense), et parfaitement adapté à la cross-compilation.

Dit comme ça, c'est simple ... mais en fait, pas tant que ça.
Cette problématique pourrait faire l'objet d'un (petit ?) article, je ne l'inclurai donc pas ici, je vous donne juste quelques pistes et suppose que vous saurez trouver les informations sur le net. De mon côté je dois les intégrer à la documentation technique du module GPIO-Démo, mais ce n'est pas encore fait à l'heure où j'écris ces lignes :( [4].

Si vous n'avez pas déjà une chaîne de cross-compilation installée pour ARM vous avez globalement trois solutions : Debian/EmDebian (celle que j'utilise), Launchpad, et Crosstools-ng.

Le projet EmDebian fournit des paquets debian pour différentes chaînes de cross-compilation (ARM parmi tant d'autres), qui sont entrain d'être intégrées à Debian. Cela devrait simplifier les problèmes de dépôts et de dépendances dont souffrait les dépôts EmDebian, même si seule la version "arm-none-eabi" (qui nous suffit, nous n'avons pas besoin de libC) est actuellement intégrée dans SID sans problèmes de dépendances (j'ai bien dit "devrait").

Le site de Launchpad fourni aussi des versions binaires de la chaîne de cross-compilation GCC ARM.

La solution CrossTools-ng : recompilation de sa propre chaîne de compilation croisée : la solution du dernier recours, si votre distribution ne fournit pas de solution packagée et que les versions binaires non signées ne vous conviennent pas.

=== Programmation : lpctools (ou autre) ===

Enfin, pour ce qui est de l'utilitaire permettant de charger (uploader) le code binaire sur le micro-contrôleur (flasher le micro-contrôleur), je n'avais pas trouvé d'outil libre permettant de réaliser cette étape au moment où j'ai étudié la possibilité d'utiliser les micro-contrôleurs de NXP, mais le protocole série permettant de réaliser cette opération était documenté dans la documentation technique des micro-contrôleurs, il ne devait donc pas y avoir de problème de ce côté là.

La seule solution "gratuite" que j'avais trouvé à l'époque ne fonctionnait que sur un seul système (pas le miens), ne fournissait pas ses sources, et interdisait une utilisation commerciale sans payer une licence, hors je voulais justement en faire une utilisation commerciale.

J'ai donc pris quelques heures de mon temps pour coder un utilitaire permettant de programmer les micro-contrôleurs LPC, et placé le tout sous licence GPL v3 [5].
Le tout est désormais disponible sur le site de Techno-Innov, et est intégré depuis peu à la distribution Debian GNU/Linux (Sid et Jessie à l'heure de l'écriture de ces lignes).

J'ai entre-temps découvert d'autres projets permettant de programmer des micro-contrôleurs LPC, mais je ne les ai pas testés (nxpprog - licence MIT, mxli - GPLv3, pyLPCTools - GPLv2) et constaté qu'un autre paquet Debian fournit les outils permetant de programmer les micro-contrôleurs LPC de NXP : lpc21isp (qui dispose d'ailleurs d'une interface graphique : GLPC, qui elle n'est pas dans les dépôts). Voir liens [6] en fin d'article.

== Makefile - particularités pour la compilation croisée ==

Une dernière petite étape avant d'écrire notre code, bien que l'on se rapproche de la programmation, puisqu'il s'agit d'un élément essentiel de tout projet : la création du Makefile.

Dans le cas de la compilation pour une cible comme le module GPIO-Démo le Makefile doit inclure quelques éléments supplémentaires que l'on ne retrouve habituellement pas dans un Makefile classique.

Le premier élément concerne la définition du compilateur à utiliser. Nous utiliserons la variable "CROSS_COMPILE" à laquelle nous affecterons une valeur par défaut correspondant au préfixe du compilateur. Si vous voulez utiliser un compilateur correctement installé sur le système, il suffit d'utiliser le préfixe, sinon, il faudra ajouter devant la totalité du chemin donnant accès au compilateur.

Par exemple pour le compilateur EmDebian :
: CROSS_COMPILE ?= arm-linux-gnueabi-
ou avec un chemin complet pour un autre compilateur :
: CROSS_COMPILE ?= /usr/local/mon/compilateur/bin/arm-none-eabi-

Le "?=" permet de ne modifier la variable que si elle n'existe pas, notamment si elle n'est pas déjà présente dans la ligne de commande.

Cette variable est ensuite utilisée pour modifier la variable "CC" utilisée par "make" pour compiler les fichiers de code source C. Si vous utilisez un autre langage, modifiez la variable correspondante.
: CC = $(CROSS_COMPILE)gcc
Il est aussi possible d'en profiter pour spécifier une version du compilateur installé :
: CC = $(CROSS_COMPILE)gcc-4.7
Nous allons en profiter pour définir la variable "LD" qui correspond à l'éditeur de liens (linker en anglais) :
: LD = $(CROSS_COMPILE)ld

Il nous faut ensuite définir la cible pour laquelle nous voulons compiler. Dans notre cas il s'agit d'un cœur ARM Cortex-M0, qui utilise le jeu d'instructions "thumb" (instructions sur 16bits permettant d'obtenir un code plus compact), nous allons donc utiliser les options -mcpu et -mthumb de gcc pour lui indiquer notre besoin :
: CPU = cortex-m0
: CFLAGS = -Wall -mthumb -mcpu=$(CPU)

En plus de cela, nous allons demander au compilateur de ne pas reconnaître les fonctions pour lesquelles il a une définition interne (builtin) tout simplement parce que la majorité de ces fonctions dépendent d'un environnement très différent de celui de notre micro-contrôleur, soit par la présence d'une bibliothèque C, d'un système d'exploitation respectant la norme POSIX, ou d'une unité de calcul flottant.
Rien de tout ceci n'est vrai dans notre cas, et il est donc préférable que le compilateur nous informe si nous tentons d'utiliser ces fonctions sans l'avoir explicitement demandé en utilisant le préfixe "__builtin__".

Nous demanderons aussi au compilateur de bien placer les données et les fonctions dans leurs sections respectives. Malgré ce que dit la documentation de GCC, cela permet (au moins dans notre cas) de produire un binaire plus petit. Cela se fait à l'aide des directives d'optimisation "-ffunction-sections" et "-fdata-sections".

Nous ajouterons ces directives dans une variable dédiée :
: FOPTS = -fno-builtin -ffunction-sections -fdata-sections

Nous obtenons donc les lignes suivantes à ajouter à votre Makefile :
: CROSS_COMPILE ?= arm-linux-gnueabi-
: CC = $(CROSS_COMPILE)gcc
: LD = $(CROSS_COMPILE)ld
: CPU = cortex-m0
: FOPTS = -fno-builtin -ffunction-sections -fdata-sections
: CFLAGS = -Wall -Wextra -mthumb -mcpu=$(CPU) $(FOPTS)

Notre Makefile ressemblerait alors à ceci :
NAME = mod_gpio
CROSS_COMPILE ?= arm-linux-gnueabi-
CC = $(CROSS_COMPILE)gcc
LD = $(CROSS_COMPILE)ld
CPU = cortex-m0
FOPTS = -fno-builtin -ffunction-sections -fdata-sections
CFLAGS = -Wall -Wextra -mthumb -mcpu=$(CPU) $(FOPTS)

.PHONY: all
all: $(NAME)

SRC = $(wildcard *.c)
OBJS = $(SRC:.c=.o)

$(NAME): $(OBJS)
$(LD) $^ -o $@
Ce Makefile est encore incomplet et ne permet pas d'obtenir le binaire pour notre micro-contrôleur, mais nous ajouterons les parties manquantes plus tard.

En attendant, ce Makefile nous permettra de compiler le code que nous allons écrire, passons donc aux parties intéressantes, et le reste du Makefile sera bien plus simple à comprendre.

== Commençons simple ==

Pour ne pas trop compliquer les choses dès le début, nous allons tenter de faire clignoter la led bicolore présente sur le module GPIO-Démo.

Notre squelette de code ressemblera à s'y méprendre à ce que l'on pourrait avoir pour un programme plus commun :
/*
* Notre exemple simple pour Open Silicium
*/
void system_init(void)
{
/* System init ? */
}

int main(void)
{
/* Micro-controller init */
system_init();

while (1) {
/* Change the led state */
/* Wait some time */
}
return 0;
}
Si vous compilez ce petit morceau de code avec notre Makefile, vous obtiendrez un binaire qui globalement ne fait rien, mais a déjà une taille de 5.7 Ko.
C'est gros pour ne rien faire, d'autant que la mémoire Flash de notre micro-contrôleur ne fait que 32 Ko.

Si on regarde plus loin, par exemple avec l'utilitaire ''file'', on obtient quelques informations supplémentaires :
$ file mod_gpio
mod_gpio: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), [....], not stripped

Arghhh, notre binaire est un exécutable dynamique au format ELF, qui utilise des bibliothèques partagées !

Nous l'avons déjà évoqué, notre micro-contrôleur n'a pas de libC ni de système d'exploitation, notre binaire ne peut donc pas être dynamique (lié dynamiquement à des bibliothèques) !
Il nous faut donc faire l'édition de lien en "static", en apportant quelques modification à notre Makefile. Nous allons introduire une variable "LDFLAGS", que l'on ajoutera à la règle de compilation utilisée pour l'édition de liens.
LDFLAGS = -static
$(NAME): $(OBJS)
$(LD) $^ $(LDFLAGS) -o $@
Recompilons notre projet ... 608 Ko !!! Re-Argh !

Visiblement quelqu'un ajoute du code dont nous n'avons pas besoin. Il faut du moins l'espérer, sinon il ne sera jamais possible de faire rentrer un programme dans la flash de notre micro-contrôleur, qui fait toujours 32Ko.

L'option "static" demande à l'éditeur de lien de créer un binaire statique, mais résultat il nous ajoute tout ce qui est utile de la libC pour un exécutable ... pour un système Linux.
D'ailleurs, ''file'' nous dit bien que notre exécutable est au format ELF.

Pour commencer nous allons demander à l'éditeur de liens (ld) de ne pas inclure les éléments de démarrage dans notre binaire, car ils sont inutiles sur notre micro-contrôleur. Pour cela nous ajoutons l'option "-nostartfiles" à nos directives pour l'édition de liens.

Et hop, une recompilation plus tard, notre binaire ne fait plus que 1 Ko :)
Mais pour ''file'', ce binaire est toujours au format ELF, et gcc nous informe qu'il n'a pas trouvé de symbole d'entrée "_start" et qu'il utilise une adresse par défaut (nous l'avons cherché, cela fait partie de ce que nous avons demandé à l'éditeur de liens en ajoutant l'option "-nostartfiles").

En effet, le "main" de nos programmes en C n'est que le point de départ de l'exécution de notre code, mais pas celui du programme. Il est précédé par un certain nombre de routines (fonctions) d'initialisation, dont le point d'entrée est la routine "_start", qui appellera le main "classique".

Mais notre but n'est pas de créer un exécutable pour un système Linux, nous devons créer un binaire pour notre micro-contrôleur. Il est désormais temps de nous plonger dans la documentation du micro-contrôleur pour comprendre comment il démarre, pour pouvoir adapter notre code au démarrage du micro-contrôleur et fournir l'équivalent de cette routine "_start".

== Bootstrap ==

=== Table des vecteurs d'interruption ===

Pour avoir des informations sur le démarrage du micro-contrôleur LPC1224 dans sa documentation technique [7] il y a deux chapitres intéressants.

Nous pouvons nous référer au chapitre 4 (LPC122x System control) qui inclut une section sur le reset du micro-contrôleur (4.6 : Reset), dans laquelle on apprend qu'une fois que la condition de reset disparait et que les procédures internes se sont exécutées, le processeur commence l'exécution à l'adresse contenue dans le vecteur "Reset" du "boot block".

Nous avons ainsi quelques informations, mais qu'est-ce que le vecteur "Reset" et le "boot block" ? Cela nous mène au deuxième chapitre intéressant, le chapitre 25 sur le cœur ARM Cortex-M0. On y trouve une section sur le processeur (25.3 : Processor) avec une sous section concernant les exeptions (25.3.3 : Exception model).

Dans les informations sur les exceptions (25.3.3.2), et plus particulièrement l'exception "Reset", il est indiqué qu'après un "Reset" l'exécution reprend à l'adresse indiquée dans le vecteur "Reset" dans la table des vecteurs d'interruption.

Bien, cela confirme ce qui se trouvait dans le chapitre 4. Mais cette fois, nous avons une sous-section "25.3.3.4 Vector table", qui décrit cette fameuse table des vecteurs d'exception, précisant qu'elle contient l'addresse de toutes les routines de gestion des exceptions (les fameux "vecteurs" d'exception, dont le vecteur "Reset").

Remarquez au passage que les interruptions sont gérées de la même façon, l'addresse d'entrée des routines de gestion des interruptions se trouve dans cette même table.

Et en dessous de cette table, nous avons une autre information très intéressante : "The vector table is fixed at address 0x00000000".

Si l'on se réfère à la table 65 de la section "25.3.2 Memory model", et à la figure 2 de la section "2.3 Memory allocation", on découvre que cette adresse est en fait le début de la mémoire flash du micro-contrôleur, qui devra contenir notre code binaire.

Reste à créer cette table, et à la placer au bon endroit dans le code binaire compilé...

=== Les "handlers" et les "dummy handlers" ===

Nous allons commencer par la partie code.
Ce code peut être placé dans le même fichier que celui ou ce trouve notre fonction main, ou dans un autre fichier, cela n'a pas d'importance. Si vous vous référez au code du module GPIO-Démo disponible dans les dépôts git de Techno-Innov, vous trouverez ce code dans le fichier "core/bootstrap.c".

[[Image:Vecteurs_interruption.png|350px|right]]

/* Cortex M0 core interrupt handlers */
void Reset_Handler(void);
void NMI_Handler(void) __attribute__ ((weak, alias ("Dummy_Handler")));
void HardFault_Handler(void) __attribute__ ((weak, alias ("Dummy_Handler")));

void Dummy_Handler(void);

void *vector_table[] = {
0,
Reset_Handler,
NMI_Handler,
HardFault_Handler,
0,
/* [......] */
};

void Dummy_Handler(void) {
while (1);
}

void Reset_Handler(void) {
/* Our program entry ! */
}

Voici un petit morceau de code relativement court qui définit notre table de vecteur ainsi que les routines de gestion correspondantes.

Avant d'aller plus loin, faisons un petit point sur certains éléments : les attributs utilisés pour la déclaration de deux de nos routines de gestion des exceptions : "__attribute__ ((weak, alias ("Dummy_Handler")))"

Ces attributs permettent de définir un alias "faible" pour une fonction, ce qui veut dire que si le compilateur ne trouve pas de définition pour cette fonction, il pourra utiliser son alias, que nous avons défini plus bas. Au contraire, si dans un autre fichier (ou celui-ci) vous définissez l'une de ces fonctions, c'est votre définition qui sera utilisée.

Note : je n'ai pas mis la totalité de la table des vecteurs, cela n'a pas d'intérêt pour les explications, et notre programme fonctionnera sans, mais il faudrait la compléter pour un vrai programme, en faisant attention à l'ordre, à partir des informations de la figure 68 déjà évoquée, et de la table 4 du chapitre 3 concernant le gestionnaire d'interruptions (vous noterez la typo, il s'agit des numéros d'IRQ et non pas des numéros des vecteurs d'exception).

=== Appeler notre main() ===
Ce petit bout de code compile donc, puisque tout est défini, mais nous avons toujours l'avertissement concernant le symbole d'entrée "_start" qui n'a pas été trouvé. Nous ne sommes pas plus avancé.

Tout d'abord, nous avons déjà indiqué que le point d'entrée de notre code est la fonction main() (qui pourrait avoir n'importe quel nom), mais pour notre micro-controlleur la fonction d'entrée du programme est la routine de gestion de l'exception "Reset".

La solution pour faire le lien est toute simple : il suffit d'appeler la fonction main() depuis la routine de gestion de l'exception "Reset".
int main(void);
void Reset_Handler(void) {
/* Our program entry ! */
main();
}

=== Tisser des liens, c'est important ===
Cela ne résout cependant aucun de nos problèmes, nous allons donc devoir donner plus d'indications à l'éditeur de liens, en créant un script pour l'édition de lien (lpc_link_lpc1224.ld). Nous donnerons le nom de ce script à l'éditeur de liens en utilisant l'otion "-T''lpc_link_lpc1224.ld''".

Ce script d'édition de lien ("linker script" en anglais) est en fait un fichier qui décrit la mémoire de notre micro-contrôleur, ainsi que l'organisation que devra respecter notre binaire.

Nous allons donc commencer, toujours à partir des mêmes informations en provenance de la documentation technique, par définir quelle est la mémoire disponible, aussi bien la mémoire "vive" (SRAM) que la mémoire "morte" (FLASH).

MEMORY
{
sram (rwx) : ORIGIN = 0x10000000, LENGTH = 4k
flash (rx) : ORIGIN = 0x00000000, LENGTH = 32k
}
Nous définissons ainsi l'adresse et la taille (et les droits d'accès) de la sram et de la flash, qui deviennent deux blocs de mémoire disponibles pour l'éditeur de liens, qui pourra donc y placer du code et des données.

Il nous faut maintenant expliquer à l'éditeur de liens comment organiser le code et les données dans ces blocs de mémoire, et tout particulièrement notre tableau de vecteurs d'interruptions

Le code d'un programme est composé de "sections", dans lesquelles le compilateur place chaque fonction et chaque variable en fonction de différents critères, que l'on peut contrôler soit à partir de directives de compilation, soit d'attributs ajoutés dans notre code C

Nous allons donc modifier notre tableau de vecteurs d'interruptions pour lui ajouter un attribut "section" qui forcera l'éditeur de liens à le placer dans la section que nous avons défini.
: void *vector_table[] __attribute__ ((section(".vectors"))) = {

Et en parallèle, nous allons définir dans notre script quelles sont les sections que nous voulons trouver dans notre binaire, et dans quel ordre.
Commençons simple (si si, je vous assure), nous compliquerons plus tard :
SECTIONS {
. = ORIGIN(flash);
.text :
{
KEEP(*(.vectors))
*(.text*)
*(.rodata*)
} >flash
.data :
{
*(.data*)
*(.bss*)
} >sram AT >flash
}
Pour commencer, nous définissons l'adresse courante (.) comme étant l'origine de du bloc de mémoire "flash" (le bloc de mémoire défini précédemment et auquel nous avons donné ce nom, bien qu'un autre nom aurait pu faire l'affaire).
Ceci est important pour que l'éditeur de liens puisse définir les adresses des fonctions pour l'exécution de notre code.
À partir de ce point nous définissons une section "text", dans laquelle nous allons demander à l'éditeur de lien de mettre plusieurs éléments, à commencer par notre fameuse table de vecteurs, en lui interdisant d'en changer la position !
Après quoi, nous lui demandons de placer l'ensemble du code, que le compilateur a placé dans des section ".text.*", puis les données en lecture seule (Read-Only data = rodata), et de placer le tout dans le bloc de mémoire "flash".

À la suite, nous créons une section "data", dans laquelle nous lui demandons de placer les données initialisées à des valeurs non nulles (data), puis les données initialement nulles (bss [8]), et de placer cette section en RAM.

Ne reste plus qu'une information à donner à l'éditeur de liens (pour l'instant): le point d'entrée de notre programme.
Ceci est relativement simple et explicite :
: ENTRY(Reset_Handler)

Dans notre Makefile la variable LDFLAGS devient :
: LDFLAGS = -static -nostartfiles -Tlpc_link_lpc1224.ld

Une compilation plus tard, sans avertissements cette fois, nous avons un binaire ... beaucoup trop gros : notre binaire fait maintenant plus de 66 Ko !

Soyons un peu curieux et allons donc voir ce qu'il contient, mais pas à la main, rassurez vous, utilisons un utilitaire fait exprès pour cela : ''objdump''. attention, il faut bien entendu utiliser la version "ARM" de objdump, donc avec le préfixe "CROSS_COMPILE", soit dans mon cas ''arm-linux-gnueabi-objdump'', avec l'option ''--disassemble-all'' (-D) :
: arm-linux-gnueabi-objdump -D mod_gpio > dump
Et là, surprise, la version "désassemblée" de notre binaire est plus petite que la version binaire (le fichier "dump" fait 2.2 Ko).

Regardons tout de même son contenu.
La première ligne nous informe que le format du fichier est "elf32-littlearm" ... pas grand chose à voir avec ce que nous voulions, un "simple" binaire (Notre micro-contrôleur n'a toujours pas appris à lire les exécutables au format ELF). Premier problème.

Quelqu'un est venu glisser une section ".note.gnu.build-id" avant notre section ".text", que l'éditeur de liens aimerait placer en début de RAM ("10000000 <_sram_base>"), ce qui n'a pas d'intérêt pour nous.

S'en suit tout de même notre section ".text", qui commence bien par notre table (enfin ! on nous écoute un peu !), suivie de nos quelques maigres fonctions. Notez les adresses des fonctions dans la table des vecteurs, qui sont toutes impaires. Ceci indique que notre processeur exécutera ces fonctions en mode "thumb" qui est bien le mode que nous avions demandé (-mthumb).

Et encore une fois, notre section ".text" n'est pas suivie de nos données, mais d'autres sections que nous n'avions pas demandées !
Certes, nous n'avons pas de variables, et l'éditeur de lien n'ayant rien à mettre dans notre section ".data", il ne l'a pas créée, mais au final nous sommes relativement loin de ce que nous voulions.

Nous allons donc demander à l'éditeur de liens de générer un petit peu moins de choses en ajoutant l'option ''-Wl,--build-id=none'' à nos directives de compilation (variable LDFLAGS de notre Makefile), ce qui nous donne un binaire moitié plus petit mais toujours trop gros.

=== Un binaire vraiment binaire ===
Mais nous ne pouvons pas en demander bien plus à l'éditeur de liens, dont le travail est de créer des exécutables au format ELF.
Pour créer d'autres types de binaire, nous devrons utiliser l'utilitaire ''objcopy'' (toujours la version ARM, donc en fait ''arm-linux-gnueabi-objcopy'').
Le travail de cet utilitaire est de créer des binaires à partir des exécutables ELF, en ne conservant que les sections qui nous intéressent (du moins, c'est l'usage que nous en ferons).

Nous allons demander à cet utilitaire de nous générer une image binaire à partir du résultat de notre compilation en ajoutant dans notre Makefile une cible "$(NAME).bin" qui deviendra notre cible par défaut et dépendra de la génération du fichier au format ELF :

all: $(NAME).bin

$(NAME).bin: $(NAME)
$(CROSS_COMPILE)objcopy -O binary $^ $@

Et notre objectif est enfin atteint, avec un binaire de ... 36 octets !<br />
Rappelez vous, je n'ai mis que 5 entrées dans ma table de vecteurs, soit 20 octets, suivis de quelques fonctions vides. Tout va bien.

== Un programme un peu plus utile ==

Nous allons désormais pouvoir nous occuper d'allumer nos Leds, en quelque sorte le "Hello world" de l'électronique.

=== Entrées et sorties ===
Du point de vue de notre micro-contrôleur, allumer ou éteindre une Led revient à changer l'état de la sortie correspondante.

Les entrées/sorties du microcontrôleur peuvent avoir plusieurs fonctions, mais hormis quelques exceptions elles sont par défaut configurées en entrées/sorties (GPIO (general Purpose Input Output) en anglais) avec la résistance de pull-up interne activée. Pour simplifier, nous laisserons donc cette étape de la configuration de côté pour l'instant, et reviendrons dessus lorsque nous attaquerons la programmation d'interfaces plus complexes.

: Note : Les exceptions sont les GPIO 13, 25 et 26 du port 0 (respectivement Reset, SWDIO et SWDCLK), qui permettent le reset et le debug, ainsi que quatre GPIO sur lesquelles la fonction "0" est réservée : les GPIO 30 et 31 du port 0 et les GPIO 0 et 1 du port 1.

=== Les registres ===
Pour changer l'état d'une de ces entrées/sorties, il faut commencer par la configurer en sortie, puis définir sont état.

Avant d'aller plus loin, il est important de comprendre que le processeur de notre micro-contrôleur ne voit que de la mémoire autour de lui. Il n'a pas accès directement aux signaux électriques.
Pour accéder aux fonctions spéciales comme l'état électrique d'une sortie le processeur doit donc modifier des données dans une zone mémoire spécifique, dédiée à cette sortie, que l'on appelle un registre.

Notre micro-contrôleur dispose d'un grand nombre de registres qui ont tous une taille de 32 bits, même si souvent certains bits ne sont pas utilisés (ils sont alors "réservés").
Ces registres particuliers, qui nous donnent accès aux fonctions spéciales du micro-contrôleur, comme la configuration et l'état des entrées sorties, sont accessibles chacun à une adresse fixe dans l'espace d'adressage du micro-contrôleur.

Nous avons déjà eu besoin d'informations sur cet espace d'adressage lorsque nous avons cherché des informations sur le démarrage du micro-contrôleur, il se trouve représenté sur la figure 2 dans la section "2.3 Memory allocation" du chapitre 2 (LPC122x Memory map).

L'adresse qui nous intéresse dépend du port sur lequel les leds sont connectées.
La led bicolore étant connectée sur le port 1 ce sont les registres présents à l'adresse 0x50010000 que nous devrons utiliser.
Cette adresse est aussi rappelée avec la description des registres dans le chapitre 8 (LPC122x General Purpose I/O (GPIO))

À partir de cette adresse se trouvent une série de registres permettant de contrôler les entrées/sorties du port 1. La modification du contenu de la mémoire accessible ainsi modifiera donc le comportement des entrées/sorties correspondantes ou leur état lorsqu'elles sont configurées en sortie.

Très (trop) souvent, pour accéder à ces registres, les programmeurs utilisent des définitions selon le principe suivant:
#define LPC_AHB_BASE (0x50000000UL)
#define LPC_GPIO_1_BASE (LPC_AHB_BASE + 0x10000)
#define PORT1_MASK (LPC_GPIO_1_BASE + 0x00)
#define PORT1_PIN (LPC_GPIO_1_BASE + 0x04)
#define PORT1_OUT (LPC_GPIO_1_BASE + 0x08)
/* [.....] */
Personnellement je trouve cette façon de faire très inefficace, et peu lisible (voire complètement illisible), et je préfère l'utilisation de structures.
Cela me semble beaucoup plus lisible, plus adapté pour accéder à de la mémoire qui est structurée, et apporte aussi un très net avantage lorsqu'il existe plusieurs ensembles de registres utilisant la même organisation, par exemple quand il y a plusieurs liaisons séries sur le micro-contrôleur, ou dans le cas qui nous intéresse pour l'instant, plusieurs ports d'entrées/sorties.
La définition se passe alors ainsi :
#define LPC_AHB_BASE (0x50000000UL)
#define LPC_GPIO_0_BASE (LPC_AHB_BASE + 0x00000)
#define LPC_GPIO_1_BASE (LPC_AHB_BASE + 0x10000)
/* General Purpose Input/Output (GPIO) */
struct lpc_gpio
{
volatile uint32_t mask; /* 0x00 : Pin mask, affects data, out, set, clear and invert */
volatile uint32_t in; /* 0x04 : Port data Register (R/-) */
volatile uint32_t out; /* 0x08 : Port output Register (R/W) */
volatile uint32_t set; /* 0x0C : Port output set Register (-/W) */
volatile uint32_t clear; /* 0x10 : Port output clear Register (-/W) */
volatile uint32_t toggle; /* 0x14 : Port output invert Register (-/W) */
uint32_t reserved[2];
volatile uint32_t data_dir; /* 0x20 : Data direction Register (R/W) */
/* [.....] */
};
#define LPC_GPIO_0 ((struct lpc_gpio *) LPC_GPIO_0_BASE)
#define LPC_GPIO_1 ((struct lpc_gpio *) LPC_GPIO_1_BASE)
À noter, l'utilisation du mot clé "volatile" qui interdira au compilateur d'optimiser les accès à ces registres en gardant des copies intermédiaires, forçant la lecture ou l'écriture immédiate.

Cette notation nous donne aussi l'information de la taille des données présentes à ces adresses, dans ce cas là, des valeurs sur 32 bits.

Pour l'utilisation dans le code, c'est ensuite très simple, il suffit de déclarer un pointeur vers cette structure, puis d'accéder au champ qui nous intéresse :
struct lpc_gpio* gpio1 = LPC_GPIO_1;
gpio1->out = 0;

=== Allumer les leds ===

Reste à déterminer quels sont les champs qui nous intéressent et quelles valeurs nous devons écrire dedans.
Pour configurer les pins reliées à nos Leds en sortie nous devons modifier le registre "DIR" (appelé "data_dir" dans la structure), et mettre les bits 4 et 5 à "1" puisque chaque bit de ce registre permet de configurer une des pins du port correspondant, le bit 0 pour la pin 0, le bit 1 pour la pin 1, et ainsi de suite (attention, ici les numéros de pins ne sont pas les numéros des pattes du composant).

Nous pouvons donc modifier notre main() pour obtenir le code suivant qui réalise cette opération de façon lisible, et positionne la Led verte à l'état "allumée", sans modifier l'état des autres sorties du port 1 :
/* The status LED is on GPIO Port 1, pin 4 (PIO1_4) and Port 1, pin 5 (PIO1_5) */
#define LED_RED 5
#define LED_GREEN 4
int main(void)
{
struct lpc_gpio* gpio1 = LPC_GPIO_1;
/* Micro-controller init */
system_init();
/* Configure the Status Led pins */
gpio1->data_dir |= (1 << LED_GREEN) | (1 << LED_RED);
/* Turn Green Led ON */
gpio1->set = (1 << LED_GREEN);
gpio1->clear = (1 << LED_RED);
while (1) {
/* Change the led state */
/* Wait some time */
}
}

[Encart : Décalages de bits] :
: La notation "<<" correspond à l'opérateur logique "décalage de bits vers la gauche" (">>" pour le décalage à droite). Voir l'article wikipedia sur le sujet, en Anglais, la version Française étant catastrophiquement incomplète [9].

== Mettre le code sur le micro-contrôleur : lpctools ==

Je sais que vous êtes de plus en plus impatients et que vous voulez voir le résultat de tout ceci en vrai, nous allons donc passer à la mise en flash sur le micro-contrôleur pour tester tout cela.

Je ne traiterais ici que le cas de la version 48 broches du micro-contrôleur LPC1224 (package LQFP48). A vous d'adapter si vous utilisez un autre micro-contrôleur, le principe étant très similaire pour tous les LPC de NXP. Pour les autres gammes de micro-contrôleurs, référez vous à leurs docs techniques et aux informations sur Internet.

=== Connexion ===
Si vous avez mis l'adaptateur USB-UART sur votre module comme proposé dans les articles précédents, l'étape de connexion au PC est simple, connectez votre module sur un port USB, directement ou via un câble en fonction du connecteur USB que vous avez choisi.

Sinon, il vous faudra un adaptateur USB-UART (souvent vendus comme adaptateurs USB-série) fonctionnant en 3.3V, et relier les signaux Rx et Tx aux signaux TXD0 et RXD0 correspondant à l'UART 0 du micro-contrôleur LPC1224 qui se trouvent sur le port 0, pins 1 et 2 (broches 16 et 17 du composant). Il est alors préférable d'avoir rendu ces signaux accesssibles sur un connecteur de votre choix, sans quoi il vous faudra souder des fils directement sur les pattes du micro-contrôleur ... possible, mais pas conseillé du tout).

=== Mode ISP ===

Il faut ensuite mettre le micro-contrôleur en mode programmation (ISP : "In System Programming" en anglais). Le chapitre 20 (LPC122x Flash ISP/IAP) indique qu'il faut maintenir la pin 12 du port 0 (broche 27) à l'état bas (0V) pendant au moins 3ms après avoir relaché le signal "Reset" (pin 13 du port 0, broche 28). La suite du chapitre décrit le protocole de programmation, uniquement utile si vous voulez créer votre propre utilitaire pour programmer le micro-contrôleur, ou si vous voulez réaliser des opérations très spécifiques.

Puisque nous avons placé des boutons poussoir reliant ces signaux à la masse, avec des résistance de "pull-up", cette opération est très simple : il faut appuyer sur les deux boutons en même temps, puis relacher le bouton reset avant de relacher le bouton ISP.
Lorsque tout c'est bien passé, la led bicolore doit avoir deux petits points lumineux à peine visibles dans l'obscurité (un rouge et un vert).

=== Dialogue avec le micro-contrôleur ===

La suite se passe sur le PC. Le paquet lpctools contient deux binaires : lpcisp et lpcprog.
Le premier donne accès aux opérations élémentaires du protocole de programmation, et ne nous sera pas utile. Le second permet de programmer le micro-contrôleur en utilisant une unique commande, bien que d'autres commandes permettent d'effectuer quelques opérations intéressantes.

Nous allons d'ailleurs commencer par une de ces autres opération : demander les identifiants de notre micro-contrôleur avec la commande "id".
La syntaxe des commandes lpcprog est simple, il suffit de lui passer un nom de device, que l'on passe comme argument de l'option "-d", une commande (argument de l'option "-c"), et si besoin le nom du fichier à utiliser.
Dans l'exemple suivant le module GPIO-Démo est identifié sur le poste de développement comme périphérique "ttyUSB0", nous utiliserons donc le ''device'' "/dev/ttyUSB0".
$ lpcprog -d /dev/ttyUSB0 -c id
Part ID 0x3640c02b found on line 26
Part ID is 0x3640c02b
UID: 0x2c0cf5f5 - 0x4b32430e - 0x02333834 - 0x4d7c501a
Boot code version is 6.1
La première ligne nous indique que lpcprog a reconnu le micro-contrôleur et qu'il sera donc possible de le programmer. (Si ce n'est pas le cas, vous devrez compléter le fichier de description des micro-contrôleurs).
Ensuite, lpcprog nous donne les informations propres au micro-contrôleur, à savoir son identifiant unique et la version du "boot code" qui se trouve en rom sur le micro-contrôleur.

Si vous avez un affichage similaire, tout va bien.
Sinon, vérifiez la connexion et que le micro-contrôleur est bien en mode ISP.

La programmation se fait ensuite très simplement avec la commande "flash", en ajoutant le nom du fichier binaire à envoyer.
$ lpcprog -d /dev/ttyUSB0 -c flash mod_gpio.bin
Part ID 0x3640c02b found on line 26
Flash now all blank.
Checksum check OK
Flash size : 32768, trying to flash 1 blocks of 1024 bytes : 1024
Writing started, 1 blocks of 1024 bytes ...
lpcprog se charge d'effacer la flash, de générer la somme de contrôle de l'entête et de la placer au bon endroit dans le binaire, et d'envoyer le tout au micro-contrôleur pour mise en flash.

Pour tester, il suffit d'appuyer sur le bouton Reset, et de constater qu'il ne se passe rien, ce qui n'est pas ce que nous attendions.

Il y a plusieurs problèmes.

=== Votre code s'il vous plait ! ===

Le premier vient de la génération de la somme de contrôle, ou plutôt de sa position dans notre binaire.
Tous les LPC de NXP utilisent (à ce jour de ce que j'ai pu voir) le même mécanisme pour déterminer si la flash contient une image valide avant d'essayer d'exécuter son contenu : la vérification du checksum des 8 premiers vecteurs d'interruption, qui doit être nulle.

Pour que ceci soit possible, conformément à la documentation technique des micro-contrôleurs, lpcprog calcule le complément à 2 des 7 premiers vecteurs, et le place dans le huitième.

Sauf que notre tableau ne fait pour l'instant que 5 "cases" et que la huitième case contenait en fait notre code exécutable, qui a été écrasé.

La première modification est donc de remplir au moins 8 cases de ce tableau, au pire avec des valeurs nulles, sinon, avec des valeurs correspondant à ce qui est attendu dans la documentation : les adresses des routines de gestion, ou au moins celle de notre routine "de remplacement" (Dummy_Handler()) lorsque la documentation indique que l'emplacement est utilisé (table 363 et figure 68 pour les exceptions, et table 4 pour les interruption).
void *vector_table[] __attribute__ ((section(".vectors"))) = {
0, /* 0 */
Reset_Handler,
NMI_Handler,
HardFault_Handler,
0,
0, /* 5 */
0,
/* Entry 7 (8th entry) must contain the 2’s complement of the check-sum
of table entries 0 through 6. This causes the checksum of the first 8
table entries to be 0 */
(void *)0xDEADBEEF, /* Actually, this is done using an external tool. */
0,
/* [.....] voir le code du module GPIO-Demo pour la suite */
};

Cependant ceci n'est pas suffisant (vous pouvez désormais le tester très simplement, je vous laisse faire).

=== Un peu de place pour la pile ===

Le dernier point un petit peu particulier est encore sur cette fameuse table des vecteurs, et concerne la première entrée.
Si vous regardez attentivement la figure 68, le vecteur "Reset" n'est que la deuxième entrée de la table.
La première est la valeur initiale du pointeur de la pile (Stack pointer), qui correspond en fait à son sommet puisque cette pile est remplie en faisant décroître les adresses (cette information se trouve dans le chapitre 25, mais cette fois je vous laisse chercher un petit peu).

Nous avons initialisé cette valeur à 0, ce qui forcément pose un soucis.

Pour obtenir la bonne valeur, nous pourrions coder en dur l'adresse du haut de notre sram, mais ce n'est pas propre.
Pour que tout soit fait correctement et automatiquement, nous allons modifier le script de l'édition de liens, et demander à '''ld''' de remplir cette adresse à notre place, en fonction de l'adresse de la sram et de sa taille.

Nous allons donc créer des variables dans notre script, juste après la définition de la mémoire disponible, et chose très importante, ces variables seront des variables externes utilisables dans notre code C !
: _sram_size = LENGTH(sram);
: _sram_base = ORIGIN(sram);
: _end_stack = (_sram_base + _sram_size);
Nous appelons le bas de la pile (la "fin" de la pile) '''_end_stack''', et plaçons cette fin de pile tout en haut de la mémoire vive.

Et pour l'utilisation dans notre code C, tout simplement :
extern unsigned int _end_stack;
void *vector_table[] __attribute__ ((section(".vectors"))) = {
&_end_stack, /* Initial SP value */ /* 0 */
Reset_Handler,
...

Si vous compilez votre code avec ces modifications, vous obtenez enfin un binaire qui allume la Led !

== Conclusion ==

Nous avons enfin notre "Hello World !" version électronique, mais la route est encore longue.

Vous pourrez voir dans le prochain article que cette première étape n'était qu'une étape, et qu'il reste encore plusieurs étapes importantes avant de pouvoir vraiment commencer à écrire du code "fonctionnel", comme la gestion du "watchdog", la configuration de l'horloge interne, l'initialisation de la mémoire, et l'écriture des drivers pour chaque bloc fonctionnel (liaison série, I2C, SPI, ADC, ....).

Rendez-vous donc pour le second article dédié à la programmation de notre micro-contrôleur.

Merci pour votre lecture attentive !

== Les fichiers créés ==
Vous trouverez sur notre serveur le [http://techdata.techno-innov.fr/Modules/GPIO_Demo/Code_LM/Article_5/Makefile Makefile], le fichier C [http://techdata.techno-innov.fr/Modules/GPIO_Demo/Code_LM/Article_5/main.c main.c], et le script de lien [http://techdata.techno-innov.fr/Modules/GPIO_Demo/Code_LM/Article_5/lpc_link_lpc1224.ld lpc_link_lpc1224.ld]

== Liens - Bibliographie ==
* [1] https://gcc.gnu.org/onlinedocs/gcc-4.7.4/gcc/Option-Summary.html
* [2] https://sourceware.org/binutils/docs/binutils/objdump.html
* [3] https://sourceware.org/binutils/docs/binutils/readelf.html
* [4] Page du module et Manuel utilisateur : http://www.techno-innov.fr/technique-module-gpio-demo/ - http://techdata.techno-innov.fr/Modules/GPIO_Demo/System_Reference_Manual_Module_GPIO_Demo_v03.pdf
* [5] Dépôt GIT lpctools : http://git.techno-innov.fr/?p=lpctools
* [6] Lien vers d'autres outils pour programmer les LPC :
** mxli : http://www.windscooting.com/softy/mxli.html
** lpc21isp : http://sourceforge.net/projects/lpc21isp/
** nxpprog : http://sourceforge.net/projects/nxpprog/
** GLPC (GUI pour lpc21isp) : http://sourceforge.net/projects/glpc/
* [7] Manuel utilisateur du LPC1224 : http://www.nxp.com/documents/user_manual/UM10441.pdf
* [8] http://fr.wikipedia.org/wiki/Segment_BSS
* [9] http://en.wikipedia.org/wiki/Bitwise_operation

Articles/Nathael/Domotab et elec Libre partie5

2020-09-02T21:13:19Z

Nathael :

{{DISPLAYTITLE:Électronique et domotique libre - partie 5 : Programmation, Premiers signes de vie}}
<div style="float:left; margin-right: 2.5em;">__TOC__</div>

[[Image:DomoTab.png|200px|right]]
Programmation du module !

Nous avons vu dans le quatrième article comment fabriquer le module GPIO-Démo (ou toute version modifiée), nous allons désormais nous atteler à lui donner vie.

'''Note 1''' : La programmation sera faite en C, bien que d'autres langages puissent être utilisés, à la seule condition qu'il existe un compilateur qui puisse générer du code binaire pour ARM à partir de ce langage.

'''Note 2''' : Les tailles indiquées dans cet article dépendent de la version de GCC utilisé, et il est presque certain que vous obtiendrez des tailles différentes. Si il y a de trop gros écarts, c'est que vous avez fait une erreur, par exemple un cas que j'ai eu fréquement en TP : l'oubli du "AT >flash" pour le bloc de données placé en RAM, à l'adresse 0x10000000, soit 256Mo ... et produit un binaire de ... 256Mo :)

<div style="float:right">par Nathael Pajani</div>

<div style="clear:right"> </div>
Paru dans le [http://boutique.ed-diamond.com/home/851-open-silicium-14.html numéro 14] du magazine Open Silicium.

<div style="clear:both"> </div>

== Les documentations techniques ==

La première étape lorsqu'on veut écrire du code pour un système embarqué qui utilise un micro-contrôleur, c'est d'en trouver la documentation technique.

L'accès aux documentations techniques est à mon avis un des critères principaux dans le choix des composants pour un projet, aussi bien pour les concepteurs que pour les utilisateurs.

Si vous avez réalisé la conception du circuit, vous aurez normalement déjà eu besoin de ces documentations, dans le cas contraire, c'est le moment de les récupérer.
Pour le module GPIO-Démo, il y a plusieurs documentations techniques nécessaires pour utiliser la totalité des fonctionnalités du module.
La première et la plus importante est celle du micro-contrôleur [7], mais vous aurez aussi besoin de celle du module, disponible sur le site de Techno-Innov [4], et de celles de l'EEPROM I2C, et du capteur de température I2C.

Encart : Pour ce qui est du bridge USB-UART, la documentation n'est pas nécessaire pour la programmation du micro-contrôleur et du module, mais elle le devient si vous voulez modifier la façon dont le composant s'identifie lorsque vous le connectez, par exemple pour pouvoir lui donner un nom spécifique ou simplifier l'identification. Cela ne sera cependant pas le sujet de cet article.

Pour récupérer les documentations techniques, vous avez le choix entre le site du fabriquant et celui du distributeur chez qui vous avec acheté les composants. Pour la majorité des composants j'utilise le site du distributeur (possible uniquement si il fourni les bonnes documentations), mais pour les micro-contrôleurs je consulte le site du fabriquant car il fourni aussi les "errata" (notes d'informations contenant les corrections sur la documentation) et le plus souvent des notes d'application qui indiquent comment utiliser le composant pour telle ou telle application (avec parfois des exemples de code).

== Outils de programmation ==

La deuxième étape ne concerne toujours pas le code que vous voulez écrire.

En effet, pour écrire du code vous n'avez pas besoin de la "cible" (target en anglais) qui est le matériel sur lequel vous allez exécuter la version compilée du code, mais uniquement d'un poste de développement, couramment appelé hôte (host en anglais).

Cependant, la cible en question n'a que faire des fichiers sources qui se trouvent sur votre poste de développement, et il vous faudra un certain nombre d'outils pour passer des fichiers source (quelque soit le langage) au code exécutable par votre carte électronique.

C'est aussi un point très important à mon sens dans le choix d'un système embarqué ou d'un micro-contrôleur : quels sont les outils dont j'aurais besoin pour passer de mon code source à un système fonctionnant avec ?

Dans le cas des micro-contrôleurs de la gamme LPC de NXP il existe de nombreuses solutions pour passer de l'un à l'autre, mais ce qui est intéressant à mon sens c'est qu'il est possible de le faire avec un minimum de matériel et de logiciel : une liaison série "TTL 3.3V", une chaîne de compilation croisée et un utilitaire pour "uploader" le code binaire.

=== Matériel : un port USB (et le PC qui va avec) ===

[[Image:14-Module sur USB.png|300px|right]]

Pour ce qui est de la liaison série "TTL 3.3V", il existe plein d'adaptateurs USB-UART fonctionnant en 3.3V, et pour le cas du module GPIO-Démo cet adaptateur est intégré sur le module, un port USB suffit donc.

L'accès à cette liaison série se fera via un fichier spécial dont le nom sera devrait ressembler à "/dev/ttyUSB0", le "USB0" pouvant différer selon votre système ("USB1", USB2", ... ou même "ACM0" avec d'autres adaptateurs).

=== Compilation : GNU ===

Pour ce qui est de la chaîne de compilation croisée, les micro-contrôleurs LPC de NXP utilisent des cœurs ARM Cortex-M*, très bien supportés par gcc, bien connu de tous les lecteurs de ce magazine (du moins je le pense), et parfaitement adapté à la cross-compilation.

Dit comme ça, c'est simple ... mais en fait, pas tant que ça.
Cette problématique pourrait faire l'objet d'un (petit ?) article, je ne l'inclurai donc pas ici, je vous donne juste quelques pistes et suppose que vous saurez trouver les informations sur le net. De mon côté je dois les intégrer à la documentation technique du module GPIO-Démo, mais ce n'est pas encore fait à l'heure où j'écris ces lignes :( [4].

Si vous n'avez pas déjà une chaîne de cross-compilation installée pour ARM vous avez globalement trois solutions : Debian/EmDebian (celle que j'utilise), Launchpad, et Crosstools-ng.

Le projet EmDebian fournit des paquets debian pour différentes chaînes de cross-compilation (ARM parmi tant d'autres), qui sont entrain d'être intégrées à Debian. Cela devrait simplifier les problèmes de dépôts et de dépendances dont souffrait les dépôts EmDebian, même si seule la version "arm-none-eabi" (qui nous suffit, nous n'avons pas besoin de libC) est actuellement intégrée dans SID sans problèmes de dépendances (j'ai bien dit "devrait").

Le site de Launchpad fourni aussi des versions binaires de la chaîne de cross-compilation GCC ARM.

La solution CrossTools-ng : recompilation de sa propre chaîne de compilation croisée : la solution du dernier recours, si votre distribution ne fournit pas de solution packagée et que les versions binaires non signées ne vous conviennent pas.

=== Programmation : lpctools (ou autre) ===

Enfin, pour ce qui est de l'utilitaire permettant de charger (uploader) le code binaire sur le micro-contrôleur (flasher le micro-contrôleur), je n'avais pas trouvé d'outil libre permettant de réaliser cette étape au moment où j'ai étudié la possibilité d'utiliser les micro-contrôleurs de NXP, mais le protocole série permettant de réaliser cette opération était documenté dans la documentation technique des micro-contrôleurs, il ne devait donc pas y avoir de problème de ce côté là.

La seule solution "gratuite" que j'avais trouvé à l'époque ne fonctionnait que sur un seul système (pas le miens), ne fournissait pas ses sources, et interdisait une utilisation commerciale sans payer une licence, hors je voulais justement en faire une utilisation commerciale.

J'ai donc pris quelques heures de mon temps pour coder un utilitaire permettant de programmer les micro-contrôleurs LPC, et placé le tout sous licence GPL v3 [5].
Le tout est désormais disponible sur le site de Techno-Innov, et est intégré depuis peu à la distribution Debian GNU/Linux (Sid et Jessie à l'heure de l'écriture de ces lignes).

J'ai entre-temps découvert d'autres projets permettant de programmer des micro-contrôleurs LPC, mais je ne les ai pas testés (nxpprog - licence MIT, mxli - GPLv3, pyLPCTools - GPLv2) et constaté qu'un autre paquet Debian fournit les outils permetant de programmer les micro-contrôleurs LPC de NXP : lpc21isp (qui dispose d'ailleurs d'une interface graphique : GLPC, qui elle n'est pas dans les dépôts). Voir liens [6] en fin d'article.

== Makefile - particularités pour la compilation croisée ==

Une dernière petite étape avant d'écrire notre code, bien que l'on se rapproche de la programmation, puisqu'il s'agit d'un élément essentiel de tout projet : la création du Makefile.

Dans le cas de la compilation pour une cible comme le module GPIO-Démo le Makefile doit inclure quelques éléments supplémentaires que l'on ne retrouve habituellement pas dans un Makefile classique.

Le premier élément concerne la définition du compilateur à utiliser. Nous utiliserons la variable "CROSS_COMPILE" à laquelle nous affecterons une valeur par défaut correspondant au préfixe du compilateur. Si vous voulez utiliser un compilateur correctement installé sur le système, il suffit d'utiliser le préfixe, sinon, il faudra ajouter devant la totalité du chemin donnant accès au compilateur.

Par exemple pour le compilateur EmDebian :
: CROSS_COMPILE ?= arm-linux-gnueabi-
ou avec un chemin complet pour un autre compilateur :
: CROSS_COMPILE ?= /usr/local/mon/compilateur/bin/arm-none-eabi-

Le "?=" permet de ne modifier la variable que si elle n'existe pas, notamment si elle n'est pas déjà présente dans la ligne de commande.

Cette variable est ensuite utilisée pour modifier la variable "CC" utilisée par "make" pour compiler les fichiers de code source C. Si vous utilisez un autre langage, modifiez la variable correspondante.
: CC = $(CROSS_COMPILE)gcc
Il est aussi possible d'en profiter pour spécifier une version du compilateur installé :
: CC = $(CROSS_COMPILE)gcc-4.7
Nous allons en profiter pour définir la variable "LD" qui correspond à l'éditeur de liens (linker en anglais) :
: LD = $(CROSS_COMPILE)ld

Il nous faut ensuite définir la cible pour laquelle nous voulons compiler. Dans notre cas il s'agit d'un cœur ARM Cortex-M0, qui utilise le jeu d'instructions "thumb" (instructions sur 16bits permettant d'obtenir un code plus compact), nous allons donc utiliser les options -mcpu et -mthumb de gcc pour lui indiquer notre besoin :
: CPU = cortex-m0
: CFLAGS = -Wall -mthumb -mcpu=$(CPU)

En plus de cela, nous allons demander au compilateur de ne pas reconnaître les fonctions pour lesquelles il a une définition interne (builtin) tout simplement parce que la majorité de ces fonctions dépendent d'un environnement très différent de celui de notre micro-contrôleur, soit par la présence d'une bibliothèque C, d'un système d'exploitation respectant la norme POSIX, ou d'une unité de calcul flottant.
Rien de tout ceci n'est vrai dans notre cas, et il est donc préférable que le compilateur nous informe si nous tentons d'utiliser ces fonctions sans l'avoir explicitement demandé en utilisant le préfixe "__builtin__".

Nous demanderons aussi au compilateur de bien placer les données et les fonctions dans leurs sections respectives. Malgré ce que dit la documentation de GCC, cela permet (au moins dans notre cas) de produire un binaire plus petit. Cela se fait à l'aide des directives d'optimisation "-ffunction-sections" et "-fdata-sections".

Nous ajouterons ces directives dans une variable dédiée :
: FOPTS = -fno-builtin -ffunction-sections -fdata-sections

Nous obtenons donc les lignes suivantes à ajouter à votre Makefile :
: CROSS_COMPILE ?= arm-linux-gnueabi-
: CC = $(CROSS_COMPILE)gcc
: LD = $(CROSS_COMPILE)ld
: CPU = cortex-m0
: FOPTS = -fno-builtin -ffunction-sections -fdata-sections
: CFLAGS = -Wall -Wextra -mthumb -mcpu=$(CPU) $(FOPTS)

Notre Makefile ressemblerait alors à ceci :
NAME = mod_gpio
CROSS_COMPILE ?= arm-linux-gnueabi-
CC = $(CROSS_COMPILE)gcc
LD = $(CROSS_COMPILE)ld
CPU = cortex-m0
FOPTS = -fno-builtin -ffunction-sections -fdata-sections
CFLAGS = -Wall -Wextra -mthumb -mcpu=$(CPU) $(FOPTS)

.PHONY: all
all: $(NAME)

SRC = $(wildcard *.c)
OBJS = $(SRC:.c=.o)

$(NAME): $(OBJS)
$(LD) $^ -o $@
Ce Makefile est encore incomplet et ne permet pas d'obtenir le binaire pour notre micro-contrôleur, mais nous ajouterons les parties manquantes plus tard.

En attendant, ce Makefile nous permettra de compiler le code que nous allons écrire, passons donc aux parties intéressantes, et le reste du Makefile sera bien plus simple à comprendre.

== Commençons simple ==

Pour ne pas trop compliquer les choses dès le début, nous allons tenter de faire clignoter la led bicolore présente sur le module GPIO-Démo.

Notre squelette de code ressemblera à s'y méprendre à ce que l'on pourrait avoir pour un programme plus commun :
/*
* Notre exemple simple pour Open Silicium
*/
void system_init(void)
{
/* System init ? */
}

int main(void)
{
/* Micro-controller init */
system_init();

while (1) {
/* Change the led state */
/* Wait some time */
}
return 0;
}
Si vous compilez ce petit morceau de code avec notre Makefile, vous obtiendrez un binaire qui globalement ne fait rien, mais a déjà une taille de 5.7 Ko.
C'est gros pour ne rien faire, d'autant que la mémoire Flash de notre micro-contrôleur ne fait que 32 Ko.

Si on regarde plus loin, par exemple avec l'utilitaire ''file'', on obtient quelques informations supplémentaires :
$ file mod_gpio
mod_gpio: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), [....], not stripped

Arghhh, notre binaire est un exécutable dynamique au format ELF, qui utilise des bibliothèques partagées !

Nous l'avons déjà évoqué, notre micro-contrôleur n'a pas de libC ni de système d'exploitation, notre binaire ne peut donc pas être dynamique (lié dynamiquement à des bibliothèques) !
Il nous faut donc faire l'édition de lien en "static", en apportant quelques modification à notre Makefile. Nous allons introduire une variable "LDFLAGS", que l'on ajoutera à la règle de compilation utilisée pour l'édition de liens.
LDFLAGS = -static
$(NAME): $(OBJS)
$(LD) $^ $(LDFLAGS) -o $@
Recompilons notre projet ... 608 Ko !!! Re-Argh !

Visiblement quelqu'un ajoute du code dont nous n'avons pas besoin. Il faut du moins l'espérer, sinon il ne sera jamais possible de faire rentrer un programme dans la flash de notre micro-contrôleur, qui fait toujours 32Ko.

L'option "static" demande à l'éditeur de lien de créer un binaire statique, mais résultat il nous ajoute tout ce qui est utile de la libC pour un exécutable ... pour un système Linux.
D'ailleurs, ''file'' nous dit bien que notre exécutable est au format ELF.

Pour commencer nous allons demander à l'éditeur de liens (ld) de ne pas inclure les éléments de démarrage dans notre binaire, car ils sont inutiles sur notre micro-contrôleur. Pour cela nous ajoutons l'option "-nostartfiles" à nos directives pour l'édition de liens.

Et hop, une recompilation plus tard, notre binaire ne fait plus que 1 Ko :)
Mais pour ''file'', ce binaire est toujours au format ELF, et gcc nous informe qu'il n'a pas trouvé de symbole d'entrée "_start" et qu'il utilise une adresse par défaut (nous l'avons cherché, cela fait partie de ce que nous avons demandé à l'éditeur de liens en ajoutant l'option "-nostartfiles").

En effet, le "main" de nos programmes en C n'est que le point de départ de l'exécution de notre code, mais pas celui du programme. Il est précédé par un certain nombre de routines (fonctions) d'initialisation, dont le point d'entrée est la routine "_start", qui appellera le main "classique".

Mais notre but n'est pas de créer un exécutable pour un système Linux, nous devons créer un binaire pour notre micro-contrôleur. Il est désormais temps de nous plonger dans la documentation du micro-contrôleur pour comprendre comment il démarre, pour pouvoir adapter notre code au démarrage du micro-contrôleur et fournir l'équivalent de cette routine "_start".

== Bootstrap ==

=== Table des vecteurs d'interruption ===

Pour avoir des informations sur le démarrage du micro-contrôleur LPC1224 dans sa documentation technique [7] il y a deux chapitres intéressants.

Nous pouvons nous référer au chapitre 4 (LPC122x System control) qui inclut une section sur le reset du micro-contrôleur (4.6 : Reset), dans laquelle on apprend qu'une fois que la condition de reset disparait et que les procédures internes se sont exécutées, le processeur commence l'exécution à l'adresse contenue dans le vecteur "Reset" du "boot block".

Nous avons ainsi quelques informations, mais qu'est-ce que le vecteur "Reset" et le "boot block" ? Cela nous mène au deuxième chapitre intéressant, le chapitre 25 sur le cœur ARM Cortex-M0. On y trouve une section sur le processeur (25.3 : Processor) avec une sous section concernant les exeptions (25.3.3 : Exception model).

Dans les informations sur les exceptions (25.3.3.2), et plus particulièrement l'exception "Reset", il est indiqué qu'après un "Reset" l'exécution reprend à l'adresse indiquée dans le vecteur "Reset" dans la table des vecteurs d'interruption.

Bien, cela confirme ce qui se trouvait dans le chapitre 4. Mais cette fois, nous avons une sous-section "25.3.3.4 Vector table", qui décrit cette fameuse table des vecteurs d'exception, précisant qu'elle contient l'addresse de toutes les routines de gestion des exceptions (les fameux "vecteurs" d'exception, dont le vecteur "Reset").

Remarquez au passage que les interruptions sont gérées de la même façon, l'addresse d'entrée des routines de gestion des interruptions se trouve dans cette même table.

Et en dessous de cette table, nous avons une autre information très intéressante : "The vector table is fixed at address 0x00000000".

Si l'on se réfère à la table 65 de la section "25.3.2 Memory model", et à la figure 2 de la section "2.3 Memory allocation", on découvre que cette adresse est en fait le début de la mémoire flash du micro-contrôleur, qui devra contenir notre code binaire.

Reste à créer cette table, et à la placer au bon endroit dans le code binaire compilé...

=== Les "handlers" et les "dummy handlers" ===

Nous allons commencer par la partie code.
Ce code peut être placé dans le même fichier que celui ou ce trouve notre fonction main, ou dans un autre fichier, cela n'a pas d'importance. Si vous vous référez au code du module GPIO-Démo disponible dans les dépôts git de Techno-Innov, vous trouverez ce code dans le fichier "core/bootstrap.c".

[[Image:Vecteurs_interruption.png|350px|right]]

/* Cortex M0 core interrupt handlers */
void Reset_Handler(void);
void NMI_Handler(void) __attribute__ ((weak, alias ("Dummy_Handler")));
void HardFault_Handler(void) __attribute__ ((weak, alias ("Dummy_Handler")));

void Dummy_Handler(void);

void *vector_table[] = {
0,
Reset_Handler,
NMI_Handler,
HardFault_Handler,
0,
/* [......] */
};

void Dummy_Handler(void) {
while (1);
}

void Reset_Handler(void) {
/* Our program entry ! */
}

Voici un petit morceau de code relativement court qui définit notre table de vecteur ainsi que les routines de gestion correspondantes.

Avant d'aller plus loin, faisons un petit point sur certains éléments : les attributs utilisés pour la déclaration de deux de nos routines de gestion des exceptions : "__attribute__ ((weak, alias ("Dummy_Handler")))"

Ces attributs permettent de définir un alias "faible" pour une fonction, ce qui veut dire que si le compilateur ne trouve pas de définition pour cette fonction, il pourra utiliser son alias, que nous avons défini plus bas. Au contraire, si dans un autre fichier (ou celui-ci) vous définissez l'une de ces fonctions, c'est votre définition qui sera utilisée.

Note : je n'ai pas mis la totalité de la table des vecteurs, cela n'a pas d'intérêt pour les explications, et notre programme fonctionnera sans, mais il faudrait la compléter pour un vrai programme, en faisant attention à l'ordre, à partir des informations de la figure 68 déjà évoquée, et de la table 4 du chapitre 3 concernant le gestionnaire d'interruptions (vous noterez la typo, il s'agit des numéros d'IRQ et non pas des numéros des vecteurs d'exception).

=== Appeler notre main() ===
Ce petit bout de code compile donc, puisque tout est défini, mais nous avons toujours l'avertissement concernant le symbole d'entrée "_start" qui n'a pas été trouvé. Nous ne sommes pas plus avancé.

Tout d'abord, nous avons déjà indiqué que le point d'entrée de notre code est la fonction main() (qui pourrait avoir n'importe quel nom), mais pour notre micro-controlleur la fonction d'entrée du programme est la routine de gestion de l'exception "Reset".

La solution pour faire le lien est toute simple : il suffit d'appeler la fonction main() depuis la routine de gestion de l'exception "Reset".
int main(void);
void Reset_Handler(void) {
/* Our program entry ! */
main();
}

=== Tisser des liens, c'est important ===
Cela ne résout cependant aucun de nos problèmes, nous allons donc devoir donner plus d'indications à l'éditeur de liens, en créant un script pour l'édition de lien (lpc_link_lpc1224.ld). Nous donnerons le nom de ce script à l'éditeur de liens en utilisant l'otion "-T''lpc_link_lpc1224.ld''".

Ce script d'édition de lien ("linker script" en anglais) est en fait un fichier qui décrit la mémoire de notre micro-contrôleur, ainsi que l'organisation que devra respecter notre binaire.

Nous allons donc commencer, toujours à partir des mêmes informations en provenance de la documentation technique, par définir quelle est la mémoire disponible, aussi bien la mémoire "vive" (SRAM) que la mémoire "morte" (FLASH).

MEMORY
{
sram (rwx) : ORIGIN = 0x10000000, LENGTH = 4k
flash (rx) : ORIGIN = 0x00000000, LENGTH = 32k
}
Nous définissons ainsi l'adresse et la taille (et les droits d'accès) de la sram et de la flash, qui deviennent deux blocs de mémoire disponibles pour l'éditeur de liens, qui pourra donc y placer du code et des données.

Il nous faut maintenant expliquer à l'éditeur de liens comment organiser le code et les données dans ces blocs de mémoire, et tout particulièrement notre tableau de vecteurs d'interruptions

Le code d'un programme est composé de "sections", dans lesquelles le compilateur place chaque fonction et chaque variable en fonction de différents critères, que l'on peut contrôler soit à partir de directives de compilation, soit d'attributs ajoutés dans notre code C

Nous allons donc modifier notre tableau de vecteurs d'interruptions pour lui ajouter un attribut "section" qui forcera l'éditeur de liens à le placer dans la section que nous avons défini.
: void *vector_table[] __attribute__ ((section(".vectors"))) = {

Et en parallèle, nous allons définir dans notre script quelles sont les sections que nous voulons trouver dans notre binaire, et dans quel ordre.
Commençons simple (si si, je vous assure), nous compliquerons plus tard :
SECTIONS {
. = ORIGIN(flash);
.text :
{
KEEP(*(.vectors))
*(.text*)
*(.rodata*)
} >flash
.data :
{
*(.data*)
*(.bss*)
} >sram
}
Pour commencer, nous définissons l'adresse courante (.) comme étant l'origine de du bloc de mémoire "flash" (le bloc de mémoire défini précédemment et auquel nous avons donné ce nom, bien qu'un autre nom aurait pu faire l'affaire).
Ceci est important pour que l'éditeur de liens puisse définir les adresses des fonctions pour l'exécution de notre code.
À partir de ce point nous définissons une section "text", dans laquelle nous allons demander à l'éditeur de lien de mettre plusieurs éléments, à commencer par notre fameuse table de vecteurs, en lui interdisant d'en changer la position !
Après quoi, nous lui demandons de placer l'ensemble du code, que le compilateur a placé dans des section ".text.*", puis les données en lecture seule (Read-Only data = rodata), et de placer le tout dans le bloc de mémoire "flash".

À la suite, nous créons une section "data", dans laquelle nous lui demandons de placer les données initialisées à des valeurs non nulles (data), puis les données initialement nulles (bss [8]), et de placer cette section en RAM.

Ne reste plus qu'une information à donner à l'éditeur de liens (pour l'instant): le point d'entrée de notre programme.
Ceci est relativement simple et explicite :
: ENTRY(Reset_Handler)

Dans notre Makefile la variable LDFLAGS devient :
: LDFLAGS = -static -nostartfiles -Tlpc_link_lpc1224.ld

Une compilation plus tard, sans avertissements cette fois, nous avons un binaire ... beaucoup trop gros : notre binaire fait maintenant plus de 66 Ko !

Soyons un peu curieux et allons donc voir ce qu'il contient, mais pas à la main, rassurez vous, utilisons un utilitaire fait exprès pour cela : ''objdump''. attention, il faut bien entendu utiliser la version "ARM" de objdump, donc avec le préfixe "CROSS_COMPILE", soit dans mon cas ''arm-linux-gnueabi-objdump'', avec l'option ''--disassemble-all'' (-D) :
: arm-linux-gnueabi-objdump -D mod_gpio > dump
Et là, surprise, la version "désassemblée" de notre binaire est plus petite que la version binaire (le fichier "dump" fait 2.2 Ko).

Regardons tout de même son contenu.
La première ligne nous informe que le format du fichier est "elf32-littlearm" ... pas grand chose à voir avec ce que nous voulions, un "simple" binaire (Notre micro-contrôleur n'a toujours pas appris à lire les exécutables au format ELF). Premier problème.

Quelqu'un est venu glisser une section ".note.gnu.build-id" avant notre section ".text", que l'éditeur de liens aimerait placer en début de RAM ("10000000 <_sram_base>"), ce qui n'a pas d'intérêt pour nous.

S'en suit tout de même notre section ".text", qui commence bien par notre table (enfin ! on nous écoute un peu !), suivie de nos quelques maigres fonctions. Notez les adresses des fonctions dans la table des vecteurs, qui sont toutes impaires. Ceci indique que notre processeur exécutera ces fonctions en mode "thumb" qui est bien le mode que nous avions demandé (-mthumb).

Et encore une fois, notre section ".text" n'est pas suivie de nos données, mais d'autres sections que nous n'avions pas demandées !
Certes, nous n'avons pas de variables, et l'éditeur de lien n'ayant rien à mettre dans notre section ".data", il ne l'a pas créée, mais au final nous sommes relativement loin de ce que nous voulions.

Nous allons donc demander à l'éditeur de liens de générer un petit peu moins de choses en ajoutant l'option ''-Wl,--build-id=none'' à nos directives de compilation (variable LDFLAGS de notre Makefile), ce qui nous donne un binaire moitié plus petit mais toujours trop gros.

=== Un binaire vraiment binaire ===
Mais nous ne pouvons pas en demander bien plus à l'éditeur de liens, dont le travail est de créer des exécutables au format ELF.
Pour créer d'autres types de binaire, nous devrons utiliser l'utilitaire ''objcopy'' (toujours la version ARM, donc en fait ''arm-linux-gnueabi-objcopy'').
Le travail de cet utilitaire est de créer des binaires à partir des exécutables ELF, en ne conservant que les sections qui nous intéressent (du moins, c'est l'usage que nous en ferons).

Nous allons demander à cet utilitaire de nous générer une image binaire à partir du résultat de notre compilation en ajoutant dans notre Makefile une cible "$(NAME).bin" qui deviendra notre cible par défaut et dépendra de la génération du fichier au format ELF :

all: $(NAME).bin

$(NAME).bin: $(NAME)
$(CROSS_COMPILE)objcopy -O binary $^ $@

Et notre objectif est enfin atteint, avec un binaire de ... 36 octets !<br />
Rappelez vous, je n'ai mis que 5 entrées dans ma table de vecteurs, soit 20 octets, suivis de quelques fonctions vides. Tout va bien.

== Un programme un peu plus utile ==

Nous allons désormais pouvoir nous occuper d'allumer nos Leds, en quelque sorte le "Hello world" de l'électronique.

=== Entrées et sorties ===
Du point de vue de notre micro-contrôleur, allumer ou éteindre une Led revient à changer l'état de la sortie correspondante.

Les entrées/sorties du microcontrôleur peuvent avoir plusieurs fonctions, mais hormis quelques exceptions elles sont par défaut configurées en entrées/sorties (GPIO (general Purpose Input Output) en anglais) avec la résistance de pull-up interne activée. Pour simplifier, nous laisserons donc cette étape de la configuration de côté pour l'instant, et reviendrons dessus lorsque nous attaquerons la programmation d'interfaces plus complexes.

: Note : Les exceptions sont les GPIO 13, 25 et 26 du port 0 (respectivement Reset, SWDIO et SWDCLK), qui permettent le reset et le debug, ainsi que quatre GPIO sur lesquelles la fonction "0" est réservée : les GPIO 30 et 31 du port 0 et les GPIO 0 et 1 du port 1.

=== Les registres ===
Pour changer l'état d'une de ces entrées/sorties, il faut commencer par la configurer en sortie, puis définir sont état.

Avant d'aller plus loin, il est important de comprendre que le processeur de notre micro-contrôleur ne voit que de la mémoire autour de lui. Il n'a pas accès directement aux signaux électriques.
Pour accéder aux fonctions spéciales comme l'état électrique d'une sortie le processeur doit donc modifier des données dans une zone mémoire spécifique, dédiée à cette sortie, que l'on appelle un registre.

Notre micro-contrôleur dispose d'un grand nombre de registres qui ont tous une taille de 32 bits, même si souvent certains bits ne sont pas utilisés (ils sont alors "réservés").
Ces registres particuliers, qui nous donnent accès aux fonctions spéciales du micro-contrôleur, comme la configuration et l'état des entrées sorties, sont accessibles chacun à une adresse fixe dans l'espace d'adressage du micro-contrôleur.

Nous avons déjà eu besoin d'informations sur cet espace d'adressage lorsque nous avons cherché des informations sur le démarrage du micro-contrôleur, il se trouve représenté sur la figure 2 dans la section "2.3 Memory allocation" du chapitre 2 (LPC122x Memory map).

L'adresse qui nous intéresse dépend du port sur lequel les leds sont connectées.
La led bicolore étant connectée sur le port 1 ce sont les registres présents à l'adresse 0x50010000 que nous devrons utiliser.
Cette adresse est aussi rappelée avec la description des registres dans le chapitre 8 (LPC122x General Purpose I/O (GPIO))

À partir de cette adresse se trouvent une série de registres permettant de contrôler les entrées/sorties du port 1. La modification du contenu de la mémoire accessible ainsi modifiera donc le comportement des entrées/sorties correspondantes ou leur état lorsqu'elles sont configurées en sortie.

Très (trop) souvent, pour accéder à ces registres, les programmeurs utilisent des définitions selon le principe suivant:
#define LPC_AHB_BASE (0x50000000UL)
#define LPC_GPIO_1_BASE (LPC_AHB_BASE + 0x10000)
#define PORT1_MASK (LPC_GPIO_1_BASE + 0x00)
#define PORT1_PIN (LPC_GPIO_1_BASE + 0x04)
#define PORT1_OUT (LPC_GPIO_1_BASE + 0x08)
/* [.....] */
Personnellement je trouve cette façon de faire très inefficace, et peu lisible (voire complètement illisible), et je préfère l'utilisation de structures.
Cela me semble beaucoup plus lisible, plus adapté pour accéder à de la mémoire qui est structurée, et apporte aussi un très net avantage lorsqu'il existe plusieurs ensembles de registres utilisant la même organisation, par exemple quand il y a plusieurs liaisons séries sur le micro-contrôleur, ou dans le cas qui nous intéresse pour l'instant, plusieurs ports d'entrées/sorties.
La définition se passe alors ainsi :
#define LPC_AHB_BASE (0x50000000UL)
#define LPC_GPIO_0_BASE (LPC_AHB_BASE + 0x00000)
#define LPC_GPIO_1_BASE (LPC_AHB_BASE + 0x10000)
/* General Purpose Input/Output (GPIO) */
struct lpc_gpio
{
volatile uint32_t mask; /* 0x00 : Pin mask, affects data, out, set, clear and invert */
volatile uint32_t in; /* 0x04 : Port data Register (R/-) */
volatile uint32_t out; /* 0x08 : Port output Register (R/W) */
volatile uint32_t set; /* 0x0C : Port output set Register (-/W) */
volatile uint32_t clear; /* 0x10 : Port output clear Register (-/W) */
volatile uint32_t toggle; /* 0x14 : Port output invert Register (-/W) */
uint32_t reserved[2];
volatile uint32_t data_dir; /* 0x20 : Data direction Register (R/W) */
/* [.....] */
};
#define LPC_GPIO_0 ((struct lpc_gpio *) LPC_GPIO_0_BASE)
#define LPC_GPIO_1 ((struct lpc_gpio *) LPC_GPIO_1_BASE)
À noter, l'utilisation du mot clé "volatile" qui interdira au compilateur d'optimiser les accès à ces registres en gardant des copies intermédiaires, forçant la lecture ou l'écriture immédiate.

Cette notation nous donne aussi l'information de la taille des données présentes à ces adresses, dans ce cas là, des valeurs sur 32 bits.

Pour l'utilisation dans le code, c'est ensuite très simple, il suffit de déclarer un pointeur vers cette structure, puis d'accéder au champ qui nous intéresse :
struct lpc_gpio* gpio1 = LPC_GPIO_1;
gpio1->out = 0;

=== Allumer les leds ===

Reste à déterminer quels sont les champs qui nous intéressent et quelles valeurs nous devons écrire dedans.
Pour configurer les pins reliées à nos Leds en sortie nous devons modifier le registre "DIR" (appelé "data_dir" dans la structure), et mettre les bits 4 et 5 à "1" puisque chaque bit de ce registre permet de configurer une des pins du port correspondant, le bit 0 pour la pin 0, le bit 1 pour la pin 1, et ainsi de suite (attention, ici les numéros de pins ne sont pas les numéros des pattes du composant).

Nous pouvons donc modifier notre main() pour obtenir le code suivant qui réalise cette opération de façon lisible, et positionne la Led verte à l'état "allumée", sans modifier l'état des autres sorties du port 1 :
/* The status LED is on GPIO Port 1, pin 4 (PIO1_4) and Port 1, pin 5 (PIO1_5) */
#define LED_RED 5
#define LED_GREEN 4
int main(void)
{
struct lpc_gpio* gpio1 = LPC_GPIO_1;
/* Micro-controller init */
system_init();
/* Configure the Status Led pins */
gpio1->data_dir |= (1 << LED_GREEN) | (1 << LED_RED);
/* Turn Green Led ON */
gpio1->set = (1 << LED_GREEN);
gpio1->clear = (1 << LED_RED);
while (1) {
/* Change the led state */
/* Wait some time */
}
}

[Encart : Décalages de bits] :
: La notation "<<" correspond à l'opérateur logique "décalage de bits vers la gauche" (">>" pour le décalage à droite). Voir l'article wikipedia sur le sujet, en Anglais, la version Française étant catastrophiquement incomplète [9].

== Mettre le code sur le micro-contrôleur : lpctools ==

Je sais que vous êtes de plus en plus impatients et que vous voulez voir le résultat de tout ceci en vrai, nous allons donc passer à la mise en flash sur le micro-contrôleur pour tester tout cela.

Je ne traiterais ici que le cas de la version 48 broches du micro-contrôleur LPC1224 (package LQFP48). A vous d'adapter si vous utilisez un autre micro-contrôleur, le principe étant très similaire pour tous les LPC de NXP. Pour les autres gammes de micro-contrôleurs, référez vous à leurs docs techniques et aux informations sur Internet.

=== Connexion ===
Si vous avez mis l'adaptateur USB-UART sur votre module comme proposé dans les articles précédents, l'étape de connexion au PC est simple, connectez votre module sur un port USB, directement ou via un câble en fonction du connecteur USB que vous avez choisi.

Sinon, il vous faudra un adaptateur USB-UART (souvent vendus comme adaptateurs USB-série) fonctionnant en 3.3V, et relier les signaux Rx et Tx aux signaux TXD0 et RXD0 correspondant à l'UART 0 du micro-contrôleur LPC1224 qui se trouvent sur le port 0, pins 1 et 2 (broches 16 et 17 du composant). Il est alors préférable d'avoir rendu ces signaux accesssibles sur un connecteur de votre choix, sans quoi il vous faudra souder des fils directement sur les pattes du micro-contrôleur ... possible, mais pas conseillé du tout).

=== Mode ISP ===

Il faut ensuite mettre le micro-contrôleur en mode programmation (ISP : "In System Programming" en anglais). Le chapitre 20 (LPC122x Flash ISP/IAP) indique qu'il faut maintenir la pin 12 du port 0 (broche 27) à l'état bas (0V) pendant au moins 3ms après avoir relaché le signal "Reset" (pin 13 du port 0, broche 28). La suite du chapitre décrit le protocole de programmation, uniquement utile si vous voulez créer votre propre utilitaire pour programmer le micro-contrôleur, ou si vous voulez réaliser des opérations très spécifiques.

Puisque nous avons placé des boutons poussoir reliant ces signaux à la masse, avec des résistance de "pull-up", cette opération est très simple : il faut appuyer sur les deux boutons en même temps, puis relacher le bouton reset avant de relacher le bouton ISP.
Lorsque tout c'est bien passé, la led bicolore doit avoir deux petits points lumineux à peine visibles dans l'obscurité (un rouge et un vert).

=== Dialogue avec le micro-contrôleur ===

La suite se passe sur le PC. Le paquet lpctools contient deux binaires : lpcisp et lpcprog.
Le premier donne accès aux opérations élémentaires du protocole de programmation, et ne nous sera pas utile. Le second permet de programmer le micro-contrôleur en utilisant une unique commande, bien que d'autres commandes permettent d'effectuer quelques opérations intéressantes.

Nous allons d'ailleurs commencer par une de ces autres opération : demander les identifiants de notre micro-contrôleur avec la commande "id".
La syntaxe des commandes lpcprog est simple, il suffit de lui passer un nom de device, que l'on passe comme argument de l'option "-d", une commande (argument de l'option "-c"), et si besoin le nom du fichier à utiliser.
Dans l'exemple suivant le module GPIO-Démo est identifié sur le poste de développement comme périphérique "ttyUSB0", nous utiliserons donc le ''device'' "/dev/ttyUSB0".
$ lpcprog -d /dev/ttyUSB0 -c id
Part ID 0x3640c02b found on line 26
Part ID is 0x3640c02b
UID: 0x2c0cf5f5 - 0x4b32430e - 0x02333834 - 0x4d7c501a
Boot code version is 6.1
La première ligne nous indique que lpcprog a reconnu le micro-contrôleur et qu'il sera donc possible de le programmer. (Si ce n'est pas le cas, vous devrez compléter le fichier de description des micro-contrôleurs).
Ensuite, lpcprog nous donne les informations propres au micro-contrôleur, à savoir son identifiant unique et la version du "boot code" qui se trouve en rom sur le micro-contrôleur.

Si vous avez un affichage similaire, tout va bien.
Sinon, vérifiez la connexion et que le micro-contrôleur est bien en mode ISP.

La programmation se fait ensuite très simplement avec la commande "flash", en ajoutant le nom du fichier binaire à envoyer.
$ lpcprog -d /dev/ttyUSB0 -c flash mod_gpio.bin
Part ID 0x3640c02b found on line 26
Flash now all blank.
Checksum check OK
Flash size : 32768, trying to flash 1 blocks of 1024 bytes : 1024
Writing started, 1 blocks of 1024 bytes ...
lpcprog se charge d'effacer la flash, de générer la somme de contrôle de l'entête et de la placer au bon endroit dans le binaire, et d'envoyer le tout au micro-contrôleur pour mise en flash.

Pour tester, il suffit d'appuyer sur le bouton Reset, et de constater qu'il ne se passe rien, ce qui n'est pas ce que nous attendions.

Il y a plusieurs problèmes.

=== Votre code s'il vous plait ! ===

Le premier vient de la génération de la somme de contrôle, ou plutôt de sa position dans notre binaire.
Tous les LPC de NXP utilisent (à ce jour de ce que j'ai pu voir) le même mécanisme pour déterminer si la flash contient une image valide avant d'essayer d'exécuter son contenu : la vérification du checksum des 8 premiers vecteurs d'interruption, qui doit être nulle.

Pour que ceci soit possible, conformément à la documentation technique des micro-contrôleurs, lpcprog calcule le complément à 2 des 7 premiers vecteurs, et le place dans le huitième.

Sauf que notre tableau ne fait pour l'instant que 5 "cases" et que la huitième case contenait en fait notre code exécutable, qui a été écrasé.

La première modification est donc de remplir au moins 8 cases de ce tableau, au pire avec des valeurs nulles, sinon, avec des valeurs correspondant à ce qui est attendu dans la documentation : les adresses des routines de gestion, ou au moins celle de notre routine "de remplacement" (Dummy_Handler()) lorsque la documentation indique que l'emplacement est utilisé (table 363 et figure 68 pour les exceptions, et table 4 pour les interruption).
void *vector_table[] __attribute__ ((section(".vectors"))) = {
0, /* 0 */
Reset_Handler,
NMI_Handler,
HardFault_Handler,
0,
0, /* 5 */
0,
/* Entry 7 (8th entry) must contain the 2’s complement of the check-sum
of table entries 0 through 6. This causes the checksum of the first 8
table entries to be 0 */
(void *)0xDEADBEEF, /* Actually, this is done using an external tool. */
0,
/* [.....] voir le code du module GPIO-Demo pour la suite */
};

Cependant ceci n'est pas suffisant (vous pouvez désormais le tester très simplement, je vous laisse faire).

=== Un peu de place pour la pile ===

Le dernier point un petit peu particulier est encore sur cette fameuse table des vecteurs, et concerne la première entrée.
Si vous regardez attentivement la figure 68, le vecteur "Reset" n'est que la deuxième entrée de la table.
La première est la valeur initiale du pointeur de la pile (Stack pointer), qui correspond en fait à son sommet puisque cette pile est remplie en faisant décroître les adresses (cette information se trouve dans le chapitre 25, mais cette fois je vous laisse chercher un petit peu).

Nous avons initialisé cette valeur à 0, ce qui forcément pose un soucis.

Pour obtenir la bonne valeur, nous pourrions coder en dur l'adresse du haut de notre sram, mais ce n'est pas propre.
Pour que tout soit fait correctement et automatiquement, nous allons modifier le script de l'édition de liens, et demander à '''ld''' de remplir cette adresse à notre place, en fonction de l'adresse de la sram et de sa taille.

Nous allons donc créer des variables dans notre script, juste après la définition de la mémoire disponible, et chose très importante, ces variables seront des variables externes utilisables dans notre code C !
: _sram_size = LENGTH(sram);
: _sram_base = ORIGIN(sram);
: _end_stack = (_sram_base + _sram_size);
Nous appelons le bas de la pile (la "fin" de la pile) '''_end_stack''', et plaçons cette fin de pile tout en haut de la mémoire vive.

Et pour l'utilisation dans notre code C, tout simplement :
extern unsigned int _end_stack;
void *vector_table[] __attribute__ ((section(".vectors"))) = {
&_end_stack, /* Initial SP value */ /* 0 */
Reset_Handler,
...

Si vous compilez votre code avec ces modifications, vous obtenez enfin un binaire qui allume la Led !

== Conclusion ==

Nous avons enfin notre "Hello World !" version électronique, mais la route est encore longue.

Vous pourrez voir dans le prochain article que cette première étape n'était qu'une étape, et qu'il reste encore plusieurs étapes importantes avant de pouvoir vraiment commencer à écrire du code "fonctionnel", comme la gestion du "watchdog", la configuration de l'horloge interne, l'initialisation de la mémoire, et l'écriture des drivers pour chaque bloc fonctionnel (liaison série, I2C, SPI, ADC, ....).

Rendez-vous donc pour le second article dédié à la programmation de notre micro-contrôleur.

Merci pour votre lecture attentive !

== Les fichiers créés ==
Vous trouverez sur notre serveur le [http://techdata.techno-innov.fr/Modules/GPIO_Demo/Code_LM/Article_5/Makefile Makefile], le fichier C [http://techdata.techno-innov.fr/Modules/GPIO_Demo/Code_LM/Article_5/main.c main.c], et le script de lien [http://techdata.techno-innov.fr/Modules/GPIO_Demo/Code_LM/Article_5/lpc_link_lpc1224.ld lpc_link_lpc1224.ld]

== Liens - Bibliographie ==
* [1] https://gcc.gnu.org/onlinedocs/gcc-4.7.4/gcc/Option-Summary.html
* [2] https://sourceware.org/binutils/docs/binutils/objdump.html
* [3] https://sourceware.org/binutils/docs/binutils/readelf.html
* [4] Page du module et Manuel utilisateur : http://www.techno-innov.fr/technique-module-gpio-demo/ - http://techdata.techno-innov.fr/Modules/GPIO_Demo/System_Reference_Manual_Module_GPIO_Demo_v03.pdf
* [5] Dépôt GIT lpctools : http://git.techno-innov.fr/?p=lpctools
* [6] Lien vers d'autres outils pour programmer les LPC :
** mxli : http://www.windscooting.com/softy/mxli.html
** lpc21isp : http://sourceforge.net/projects/lpc21isp/
** nxpprog : http://sourceforge.net/projects/nxpprog/
** GLPC (GUI pour lpc21isp) : http://sourceforge.net/projects/glpc/
* [7] Manuel utilisateur du LPC1224 : http://www.nxp.com/documents/user_manual/UM10441.pdf
* [8] http://fr.wikipedia.org/wiki/Segment_BSS
* [9] http://en.wikipedia.org/wiki/Bitwise_operation

Fichier:Vecteurs interruption.png

2020-09-02T20:57:45Z

Nathael :

Fichier:14-Module sur USB.png

2020-09-02T20:57:20Z

Nathael :

Articles/Nathael/Domotab et elec Libre partie4

2020-09-02T20:56:27Z

Nathael : /* Génération des fichiers Gerbers */

{{DISPLAYTITLE:Électronique et domotique libre - partie 4 : Un module en vrai, FabLabs et fabrication maison}}
<div style="float:left; margin-right: 2.5em;">__TOC__</div>

[[Image:DomoTab.png|200px|right]]
Les trois articles précédents (parus dans les [http://boutique.ed-diamond.com/open-silicium/490-os7.html numéros 7] et [http://boutique.ed-diamond.com/open-silicium/497-os8.html 8] d'[http://boutique.ed-diamond.com/16-open-silicium Open Silicium]) vous ont présenté la partie conception sur ordinateur d'un module pour le projet DomoTab. Il est maintenant temps de passer de la conception à la réalisation, et de fabriquer le module que nous avons conçu.

<div style="float:right">par Nathael Pajani</div>

<div style="clear:right"> </div>
Paru dans le [http://boutique.ed-diamond.com/open-silicium/791-open-silicium-13.html numéro 13] du magazine Open Silicium.

<div style="clear:both"> </div>

== Petite vérification ==

Avant de rentrer dans le vif du sujet, une note pour ceux qui n'ont pas réalisé le schéma proposé dans les articles précédant : vérifiez que vous avez prévu un moyen simple pour accéder à l'interface de programmation du microcontrôleur choisi, si possible un bouton reset, et un moyen permettant de mettre le microcontrôleur en mode programmation si besoin.

== Dernière étape sur ordinateur ==

Les articles précédents nous ont permis de créer le schéma du module GPIO-Demo et de réaliser le routage pour préparer la réalisation des PCB (Printed Circuit Board, ou Circuits Imprimés (CI) en français).
Il reste une dernière étape avant la fabrication : la génération des plans de fabrication.
Cette étape dépendra grandement de la solution choisie pour la fabrication du PCB.
Certains sous-traitants acceptent directement le format natif KiCad, mais ils sont assez rares et la majorité des fabricants acceptent le format Gerber.
Cependant si vous souhaitez réaliser vos PCB vous même aucun de ces deux formats ne vous sera utile et nous verrons plus tard comment procéder.

=== Fichiers Gerber et "layers" ===
[[Image:06-Gerbview-01.png|400px|right]]
Les plans de fabrication les plus utilisés sont au format Gerber. Il s'agit d'un ensemble de fichiers décrivant chacun une couche ("layer" en anglais) du circuit imprimé final : couches de cuivre, contours, perçages (trous métallisés et trous non métallisés sur deux couches différentes), sérigraphies, vernis épargne, et masques de soudure.
Toutes ces couches correspondent aux couches que l'on a sous KiCad (pcbnew), rien de nouveau donc. Cependant, toutes ne seront pas forcément présentes en fonction de votre circuit et de la finition que vous désirez.

Le nombre de couches de cuivre dépendra de ce que vous aurez choisi pour le routage de votre circuit, donc deux couches dans le cas du module que nous avons créé, mais cela peut aller de une seule couche de cuivre, à dix couches pour les circuits les plus complexes et les plus denses. Lorsqu'il y a plus de deux couches la fabrication "maison" sur un seul PCB n'est plus possible, et les prix grimpent.

La couche de contour correspond aux découpes du circuit imprimé. Tous les fabricants n'acceptent pas les découpes complexes, renseignez vous avant de payer si votre circuit comporte des découpes intérieures ou des découpes courbes.

Les couches de perçage correspondent aux trous pour les composants "traversants" et aux vias (pour les trous métallisés) et aux trous de fixation ou de placement de certains connecteurs qui ont des picots de placement en plastique (trous non métallisés).
Lorsque vous visualisez les fichiers gerbers sous KiCad (gerbview) les trous sont représentés par des formes géométriques diverses, une par diamètre de perçage, mais les trous auront bien la forme que vous avez définie :)

Les couches suivantes sont optionnelles, mais bien utiles.

Les couches de vernis épargne (dessus et dessous) définissent un masque de vernis qui sera appliqué sur la carte pour recouvrir les zones ne nécessitant pas de soudures. C'est cette couche qui définit la couleur de la carte. Dans certains cas le vernis vert est inclus dans le prix de fabrication, mais les couleurs moins habituelles (rouge, bleu, noir, ...) impliquent un surcoût parfois non négligeable.
Cette couche est générée automatiquement à partir des données des empreintes des composants et d'un paramètre global sous KiCad qui se trouve dans le menu Dimensions --> Marge Masque des Pads ([RefCard-5.26]). Dans la majorité des cas il n'est pas nécessaire de laisser de marge supplémentaire, et une valeur de 0 fait l'affaire. Les cas particuliers peuvent être définis dans l'empreinte du composant.
L'utilisation des couches de vernis donne un rendu beaucoup plus propre et facilite grandement la soudure des composants CMS.

Les couches de sérigraphie (dessus et dessous) définissent les textes et autres tracés imprimés en blanc (dans la très grande majorité des cas) sur votre PCB. Ces textes vous aideront à placer les composants lors de la fabrication et à repérer les connecteurs ou les broches qui vous intéressent lors de l'utilisation.
Bien souvent une seule couche de sérigraphie suffit.

Les masques de soudure (dessus et dessous) servent à la fabrication des pochoirs pour les composants CMS. Ils ne sont nécessaires que si vous désirez faire fabriquer un pochoir métallique en découpe laser. Ce pochoir est très utile si vous avez de nombreux composants CMS, et PCB-Pool le propose gratuitement pour les petites quantités (moins de 100 PCB), mais il est possible de le réaliser dans un FabLab en découpe laser avec une feuille de plastique (voir plus loin).

=== Génération des fichiers Gerbers ===
[[Image:06-Trace_Gerbers-01.png|600px|right]]
Sous KiCad la génération des fichiers Gerbers se fait via le menu Fichiers --> Tracer ([RefCard-5.27]).
KiCad supporte plusieurs types de fichiers, il faut bien sélectionner "Gerber".

Je vous conseille de créer un dossier pour les fichiers gerbers, cela simplifiera la création d'une archive pour envoyer les fichiers au sous-traitant qui fabriquera vos cartes.

Il faut ensuite sélectionner les bonnes couches à inclure dans l'export.
Toutes les couches actives dans votre projet se trouvent dans la colonne de gauche, à vous de vérifier que celles qui vous intéressent sont bien cochées.

Les couches de cuivres sont notées "*.Cu", les couches de vernis épargne sont les "*.Mask", les couches de sérigraphie correspondent aux "*.SilkS" (pour Silk Screen), les couches pour les pochoirs CMS sont les "*.Paste" (pour "Solder Paste", ou "pâte/crème à souder" en français), et les contours du PCB sont sur la couche "Edge.Cuts".

Pour le reste des cases à cocher, il me semble que les cases cochées par défaut conviennent, sinon reportez vous à la capture d'écran (Figure à droite).

Il faut ensuite "Tracer" (ce qui génère les fichiers sélectionnés), puis "Créer les Fichiers de Perçage".
Pour les fichiers de perçage, il faut bien sélectionner le format Gerber, et cliquer sur "Drill file" et "Plan de perçage".
Je ne sais pas si les deux sont utiles, mais j'envoie systématiquement les deux et je n'ai pas eu de problème ni de retour ou remarques, donc je continue comme ça :)

Pour la suite, il ne vous restera plus qu'à faire une archive (zip le plus souvent) pour envoyer votre PCB en fabrication.

Vous pouvez vérifier les fichiers en utilisant l'utilitaire gerbview qui est intégré à la suite KiCad, et qui vous permet d'activer ou désactiver les couches une à une (après les avoir "chargées" une première fois), et ainsi vérifier que vous n'en avez pas oublié une, ou qu'il n'y a pas d'erreur par rapport à ce que vous attendiez (trop de textes sur la couche sérigraphie, plans de masse pas mis à jours, ....)

=== Version "fait maison" : fichiers SVG ===

Pour la version fait maison, les fichiers Gerbers ne sont pas utiles, mais KiCad permet l'export au format SVG des différentes couches de fabrication.

L'interface d'export se trouve dans le menu Fichiers --> Export SVG ([RefCard-5.28]). Dans la majorité des cas seules les couches de cuivre sont intéressantes, mais vous pouvez très bien ajouter des guides de placement sur une couche "utilisateur" (Eco*.User) et vouloir les imprimer aussi, ainsi que le contour du circuit, pour faciliter la découpe finale.

De même, compte tenu de la difficulté d'impression de la sérigraphie, vous pouvez imprimer une partie des textes sur la couche de cuivre, ce qui vous permet de disposer de quelques indications supplémentaires sur votre PCB sans devoir jouer du marqueur.

Dans ce cas là, vous pouvez choisir de tout imprimer dans le même fichier, ce qui vous évite de devoir replacer les différents éléments correctement à partir de plusieurs fichiers.

N'oubliez pas de cocher le tracé en miroir, que ce soit pour la technique de l'insolation (pour que l'encre soit au plus près du cuivre et le protège mieux, permettant des tracés plus fins), ou la technique de décalcomanie (voir plus loin).

Vous pouvez ensuite visualiser le résultat avec Inkscape, et éventuellement regrouper plusieurs PCB.

Il est possible de faire des PCB double couche, quelque soit la technique utilisée, mais attention, l'alignement doit être précis, il faudra donc penser à mettre des repères qui permettront de positionner les masques lors de la fabrication. Ces repères peuvent être placés sous KiCad ou sous Inkscape, mais il est préférable de le faire sous KiCad car ils resteront présents si vous faites des modifications, ce qui n'est pas le cas pour la version Inkscape.

'''Attention''' : Dans le cas de la fabrication maison de circuits simple couches avec des composants traversants, ceux-ci doivent être placés de l'autre côté du PCB lors du placement des composants sous KiCad pour pouvoir être soudés sur les pistes.

'''Note''' : Il est possible, lorsqu'il n'y a que quelques pistes sur la couche de cuivre du dessous, de ne faire qu'un PCB simple couche, et de remplacer les pistes manquantes par des morceaux de pattes de composants ou des fils.

== Fabrication du PCB ==

=== Home Made et FabLab/ElectroLab ===

La fabrication maison de cartes électroniques n'est pas très compliquée et peut être à la portée de tous ... ou presque.

Pour ceux qui ont accès à l'Electrolab de Nanterre (http://www.electrolab.fr/), ils vous donneront des indications bien plus précises et détaillées que celles que je pourrais vous donner ici, et surtout, en échange d'une cotisation modique (comme pour tout FabLab) vous aurez accès à du matériel vous permettant de réaliser vos circuits imprimés.

Mais pour le reste de la France ... il faut se débrouiller (renseignez vous tout de même, le FabLab le plus prêt de chez vous a peut-être une partie du matériel, ou sera intéressé pour s'équiper).

Il y a globalement trois techniques pour fabriquer des PCB sans faire appel aux services d'un sous-traitant professionnel : La méthode classique "isolation / révélation", la méthode "décalcomanie", et la méthode usinage.

Les trois méthodes ne diffèrent que par les premières étapes, je détaillerais les étapes suivantes dans la partie "finitions" qui sera commune aux trois méthodes.

==== Insolation / révélation ====
Cette méthode nécessite l'utilisation de plaques pré-sensibilisées, que vous allez "graver" en trois étapes. Je n'ai personnellement pas re-testé cette solution, que j'avais mise en œuvre à l'école, car je n'aime pas trop manipuler les produits chimiques dangereux, et que je n'ai pas d'insoleuse UV, mais vous trouverez de nombreux tutoriels sur internet, et je vais vous en présenter rapidement le principe.

La première étape est l'insolation, ou exposition. La plaque de cuivre pré-sensibilisée est recouverte d'un film sensible aux UV. La plaque doit être exposée aux UV à travers un "typon" qui n'est autre qu'une impression du circuit imprimé sur film transparent. Il vous faudra donc disposer d'une insoleuse à UV.

L'étape suivante, la révélation, utilise un premier produit dangereux, la soude, pour dissoudre les parties du film photosensible qui ont été exposées. Attention, j'ai bien dit produit dangereux, utilisation de gants et de lunettes de protection obligatoire.

La troisième étape, la gravure proprement dite, utilise un autre produit dangereux (mais moins) et surtout qui tache définitivement les tissus : le perchlorure de fer. Celui-ci va attaquer le cuivre qui n'est plus protégé par le film photosensible, ne laissant du cuivre que pour les pistes, faisant apparaître le circuit imprimé.
Pour accélérer le processus et éviter de gaspiller une grande quantité de produit, il est possible d'utiliser une éponge et de frotter délicatement la surface du PCB avec un coin de l'éponge imbibé de perchlorure de fer.
Le film de protection est ensuite retiré avec de l'alcool à bruler (il doit être possible de tester avec de l'acétone ou de l'alcool à 70°).

==== Décalcomanies ====
[[Image:07-Decalco-01.png|400px|right]]
Il existe une première alternative à la solution "classique", qui utilise le principe des décalcomanies.

Cette solution est en deux étapes, et utilise des plaques de cuivre non pré-sensibilisées, une imprimante laser (obligatoire) et une plastifieuse pour la première partie et toujours du perchlorure de fer pour la gravure.

Le dessin de votre carte doit être imprimé sur un papier à décalcomanie (je n'ai testé que celui proposé par "PCB-Fab-In-A-Box" dans leur kit, mais je pense que d'autres font l'affaire), puis transféré à chaud avec une pression régulière sur le circuit imprimé.
C'est cette étape qui est critique et qu'il faut parfois reprendre plusieurs fois, surtout si vous ne pouvez pas vous procurer une des plastifieuses spécifiées par "PCB-Fab-In-A-Box", que Amazon refuse de livrer en dehors des États-Unis.

Pour améliorer les résultats, il faut frotter la plaque de cuivre avec une éponge abrasive type "tampongex" (éponges vertes) pour la nettoyer, puis la chauffer à l'aide d'un fer à repasser (attention, elle devient brulante) avant d'y déposer le décalcomanie et de passer le tout dans la plastifieuse. Il est possible de se passer de la plastifieuse, mais le dosage de la pression avec le fer à repasser est alors critique.

Le papier est ensuite décollé en faisant tremper le tout une minute dans l'eau, et si tout c'est bien passé, l'encre est alors déposée sur le cuivre. Si il y a des pistes rompues, ou des parties qui n'ont pas collé sur le cuivre, il est possible de recommencer en enlevant l'encre qui s'est déposée avec de l'acétone.

[[Image:07-Decalco-02.png|400px|right]]

Le site "PCB-Fab-In-A-Box" conseille ensuite d'appliquer une couche de protection à l'aide d'un film plastique (fourni dans leur Kit), mais avec ma plastifieuse je n'ai pas réussi à le déposer correctement, et la gravure se passe très bien sans.

Ensuite il faut procéder à la gravure avec le perchlorure de fer, comme pour la méthode précédente, l'astuce avec l'éponge étant toujours valable.

Cette méthode permet d'obtenir des pistes assez fines, mais nécessite plusieurs essais pour prendre en main la technique d'application des décalcomanies.

==== Usinage ====
La troisième méthode utilise une fraiseuse numérique pour retirer le cuivre inutile par gravure mécanique et non plus gravure chimique.

Il vous faut alors transformer votre fichier SVG en tracé de découpe et la machine fait le reste. Il doit être possible de faire percer les vias et autres trous au même moment ou avec un autre outil, mais je n'ai pas pu tester cette solution car les pistes utilisées pour mes PCB ont été jugées trop fines par les personnes disposant d'une fraiseuse qui auraient pu réaliser des essais.

==== Finitions ====
Une fois le cuivre gravé, il reste encore deux étapes.

La première étape est optionnelle, il s'agit de l'étamage chimique des pistes. Il suffit pour cela de faire tremper le circuit dans une solution d'étain chimique jusqu'à ce que les pistes aient changé de couleur.

La deuxième étape est le perçage des vias et des différents trous pour les composants. L'utilisation d'une petite perceuse sur colonne permet un travail bien plus efficace et précis, mais reste que les trous des vias ne seront pas métallisés.

La métallisation des trous des vias peut se faire de façon chimique, mais cela demande un peu (beaucoup) de matériel et une installation en conséquence, tandis que la deuxième consiste simplement à utiliser de pattes de composants que vous avez coupées lors de l'assemblage d'un autre circuit pour relier les deux côtés du circuit imprimé en les soudant de chaque côté sur les pastilles, et en coupant avec une pince coupante tout ce qui dépasse.

==== Liens utiles ====
* http://wiki.jelectronique.com/realisation_de_circuits_imprimes
* http://alain.canduro.free.fr/circuits.htm

=== FabLabs et mutualisation des ressources ===
Les trois techniques présentées précédemment sont très pratiques pour réaliser un prototypage rapide, mais nécessitent toutes un peu de matériel, qui, bien que peu coûteux pour les deux premières solutions, représente au final entre 50 et 300 euros, et prend de la place.

Il peut être intéressant de trouver un FabLab qui dispose de toute ou partie de ce matériel, ou qui serait intéressé pour l'acquérir, libérant de la place chez vous et permettant de mutualiser l'ensemble des coûts, et éventuellement de tester les différentes solution.

La dernière étape est l'application d'un vernis sur la totalité du circuit. Il faut choisir un vernis thermosoudable qui permettra de souder les composants malgré la couche de vernis. Je n'ai personnellement jamais testé, je ne connais pas la tenue des ces vernis et leur comportement lors de la soudure autre qu'au fer à souder.

=== Services de fabrication en ligne ===

[[Image:07-Fab_PCB-01.png|400px|right]]

Si vous n'avez pas la fibre DIY jusqu'au bout des doigts, ou que manipuler des produits chimiques potentiellement dangereux ne vous amuse pas plus que moi, il existe des services de fabrication un peu partout dans le monde pour faire fabriquer des circuits imprimés avec une qualité professionnelle (ce sont souvent ceux utilisés par les professionnels) à un coût raisonnable (voir défiant toute concurrence).

Attention, je ne parle pas ici de personnes qui se proposent de faire des circuit imprimés en utilisant une des méthodes citées ci-dessus à votre place, pour un tarif souvent plus élevé que les fabriquant industriels, avec les même délais, et pour une qualité qui n'a rien de comparable avec ce que proposent les fabricants industriels.

Bien entendu, si vous êtes extrêmement pressés et que vous voulez pouvoir tester votre circuit dans l'heure, ceci n'est pas une solution.

J'ai testé plusieurs services de fabrication en ligne, dont PCB-Pool, qui produit en Irelande, Dipoles Electroniques, qui produit en France, PCB Train, qui produit en Angleterre, et Seeed Studio qui produit en chine.

Chaque fabriquant a ses avantages et inconvénients, que je vais essayer de vous présenter, mais qui n'engagent que moi.

* PCB-Pool (https://www.pcb-pool.com) : les plus chers (ou pas), mais avec un réel service ajouté de vérification du circuit imprimé, la possibilité d'envoyer votre circuit au format natif KiCad (pas de possibilité d'erreur sur la génération des Gerbers), et le pochoir CMS en métal découpé au laser ... disons inclus dans le prix de base sur les quantités inférieures à 100 pièces.
: Délai "standard" de 8 jours ouvrés, plusieurs modes de livraison, possibilité de livraison plus rapide en payant plus cher.
: Tarif : 140€ HT pour un circuit de 100mm x 160mm double face, vernis et sérigraphie double face, avec pochoir CMS en délai 5 jours, mais cela passe à 85€ HT sur le délai standard 8 jours avec une seule face de sérigraphie.
: SAV / Support en Français.
: Possibilité de réalisations plus techniques (pistes plus fines, perçages plus fins) ou de délais plus cours (jusqu'à 2 jours).

* Dipole Electronique (http://www.dipole-electronique.fr/) : même service que PCB-Pool, mais l'envoi des fichiers se fait par mail au format Gerber, le format est fixe (ils font les découpes du contour, rassurez vous), et vous avez moins d'options de fabrication sur l'offre "prototypes taille fixe".
: Délai "standard" de 5 jours ou 10 jours.
: Tarif : 60€ HT pour un circuit de 100mm x 160mm double face, vernis et sérigraphie double face, '''sans''' pochoir CMS, en délai 5 jours, et 45€ HT sur le délai de 10 jours.
: Pochoir CMS métal en découpe laser : forfait de 70€ HT.
: SAV / Support en Français.

* PCB Train : j'ai été très déçu par leur prestation, lorsque vous sélectionnez les délais rapides il faut lire les petits caractères pour comprendre qu'il n'y aura ni vernis ni sérigraphie, la sélection des produits est globalement incompréhensible, pour un prix équivalent à PCB-Pool sans le pochoir CMS gratuit.

* Seeed Studio (http://www.seeedstudio.com/service/) : Low cost, mais haute qualité. Envoi des fichiers en ligne au format Gerber, et peu d'options (obligatoirement vernis et sérigraphie double face pour les circuits double face), mais vu le tarif, difficile de se plaindre.
: Délai : variable, en général l'envoi se fait sous 5 jours, et possibilité de livraison gratuite si vous n'êtes pas pressés (en dessous d'un certain poids)
: Tarif : à partir de 10$ pour 5 circuits de 5cm x 5cm, prix croissant par pas de 5cm, décroissants en volume (classique) et options payantes (finition, couleur du vernis), pour comparaison, 46$ pour 5 circuits imprimés de 10cm x 15cm
: Pochoir CMS en métal à partir de 70$
: SAV / Support en Anglais.
: Autre avantage : la possibilité de grouper votre commande avec plein de gadgets intéressants ou d'outils ou de matériel de prototypage, comme une pince brucelle à pointe fine pour le placement des composants CMS si vous n'en avez pas.

Il en existe bien entendu beaucoup d'autres, mais je ne les ai pas testés. J'avais trouvé une liste avec des commentaires, mais je ne la retrouve pas.

Personnellement j'utilise PCB-Pool quand j'ai des contraintes spécifiques (délais, taille des pistes et perçages, ou que j'ai besoin d'un pochoir CMS métallique pour une production en série), et sinon soit Dipoles Electroniques pour les productions en série (made in France :) et Seeed Studio quand le budget est serré.

Ha oui, un point hyper important que j'allais oublier pour PCB-Pool : le suivi des étapes de production, avec photo de votre PCB entre chaque étape ... quoi ? je suis le seul que ça intéresse ?

== Achat des composants ==

[[Image:07-Kit.png|400px|right]]

Maintenant que votre circuit est en cours de fabrication, plutôt que de trépigner d'impatience en attendant les informations de suivi de fabrication par email, je vous propose de vous pencher sur la commande des composants (cela vous fera un deuxième sujet d'impatience pour trépigner de plus belle).

Cette étape devrait être rapide si vous avez bien noté les références des composants sélectionnés lors de vos recherches pour la conception du circuit, mais rien ne vaut une ultime vérification. Vérifiez bien les boîtiers sélectionnés (de nombreuses références sont disponibles en plusieurs boîtiers, qu'il s'agisse des condensateurs et résistances (0402, 0603, 0805, ...), des diodes, transistors, régulateurs (SOT-23, SOT363, SOT-223, TO-92, SOD, ...) ou même des microcontôleurs (QFN, TQFP, TSOP, SOIC, ...).

Deux solutions s'offrent à vous. Chercher à économiser chaque centime en écumant les sites de tous les revendeurs de France et de Navare, et payer plein plein plein (plein) de frais de port (après avoir perdu encore plus de temps), ou sélectionner un unique fournisseur au catalogue bien fourni, pour éventuellement avoir les frais de port gratuits car vous commandez plus qu'une certaine somme.

Je n'ai pas d'accords commerciaux avec les différents fournisseurs de composants (pas plus que pour les services de fabrication de circuits imprimés, malheureusement), mais je vous conseillerais tout de même ceux que j'utilise courament, à savoir Farnell, Mouser et DigiKey. Je ne peux que déconseiller Conrad (chers, site mal foutu, et encore plus chers avec un compte pro !) et Electronique Diffusion (qui renvoie vers le site all-datasheets pour les documentations techniques sans donner le fabriquant des composants vendus !!!).

Ma préférence va à Farnell dont j'aime bien l'interface et le système de recherche (et la livraison gratuite le lendemain pour les comptes pro sur le stock Europe), mais c'est une question de préférence personnelle, et il m'arrive de commander chez les deux autres fournisseurs cités quand je ne trouve pas un composant ou quand j'ai besoin d'un gros volume, les réductions en volume étant parfois plus intéressantes (mais pas toujours).

(PS : Dans le cas du module GPIO-Demo, vous pouvez aussi acheter notre Kit.)

== ... et du matériel ==

Si vous n'êtes pas équipé, il est aussi temps d'acheter le matériel manquant, il vous sera de toutes façons utile pour plein de projets, il n'y a rien de spécifique.

J'ai dressé une petite liste qui devrait vous permettre de vous en sortir avec votre circuit :
* Un fer à souder. (Je déconseille fortement les fers sans station permettant de régler la température, une station qui tient la route coûtant dans les 60 euros, ce n'est pas un investissement déraisonnable. Lisez l'article sur ce sujet dans le premier numéro de "Hackable Magazine" si vous êtes sceptiques.)
* De l'étain. (Personnellement, je n'ai pas trouvé d'étain sans plomb utilisable, mais vous pouvez essayer.)
* De la tresse à dessouder.
* Une pince coupante. (De préférence avec la ligne de coupe au bord des mâchoires pour pouvoir couper à ras.)
* Une pince brucelle
* Un multimètre (Avec fonction "bip" pour tester la continuité des pistes ... ou les courts-circuits :( )
* Une plancha. (Si si, vous avez bien lu. Tout type de poêle électrique devrait faire l'affaire.)
* Une petite loupe. (Toujours pratique pour vérifier les soudures.)

== Masque de soudure ==

[[Image:07-Pochoir-01.png|400px|right]]

Il y a heureusement une deuxième activité que vous pouvez pratiquer (trépigner ne sert à rien (si si, je vous assure), et ça fatigue (au moins votre entourage)) en attendant vos cartes électroniques (et vos composants maintenant). Si vous n'avez pas commandé le pochoir CMS en métal et que vous choisissez cette solution pour la soudure, c'est la fabrication du pochoir CMS en plastique (à condition d'avoir accès à une machine de découpe laser, mais si ce n'est pas le cas il y a une alternative ... qui vous fera trépigner d'impatience une fois de plus).

Le Pochoir CMS (ou masque de soudure) est habituellement une fine feuille de métal (120 à 175 microns d'épaisseur) qui est utilisée par les fabricants de cartes électroniques pour mettre la soudure sur le circuit imprimé avant le placement des composants et le passage en four pour la soudure.
Cette plaque est percée de trous, un pour chaque "pad" de chaque composant CMS, délimitant un volume équivalant à la quantité de soudure nécessaire pour souder la patte du composant sans faire de pâté pour qu'il n'y ait pas de court circuit.

Le soucis du pochoir CMS en métal c'est son prix, impossible d'en inclure un dans chaque Kit du module GPIO-Démo. Il me fallait une solution alternative, et j'ai donc pensé à faire la même chose avec la machine de découpe laser du FabLab de Lyon (La Fabrique d'Objets Libres). Le problème, c'est qu'elle ne peux pas couper le métal, j'ai donc du me rabattre sur le plastique.

L'étape la plus compliquée est de trouver des feuilles de plastique dont l'épaisseur est spécifiée par le commerçant, et de la même épaisseur que les pochoirs métalliques, donc de l'ordre de 150 microns. L'épaisseur est primordiale, car c'est elle qui donnera la quantité de soudure déposée.

Les premiers plastiques que j'ai trouvé avec l'épaisseur spécifiée sont des rhodoids alimentaires (175 microns et 130 microns), mais ils sont difficile à acheter autrement qu'en ligne, et sont souvent de grande taille (60cm x 40cm), donc pas pratiques à manipuler, mais en cherchant bien on en trouve de dimension raisonnable (A4).
Et je suis tombé par hasard sur des feuilles plastiques pour premières pages de dossiers (ceux que l'on relie, que l'on doit rendre en quatre exemplaires pour nos projets et qui finiront au fond d'une poubelle dans quelques années^W semaines) dont l'épaisseur est spécifiée sur la pochette : 130 microns, pile ce qu'il faut, et bien moins cher que le rodhoid alimentaire, si ce n'est qu'il faut en acheter 100 feuilles.

Après quelques tests réalisés au FabLab, j'ai fini par obtenir un pochoir plastique très convenable à partir de la couche "Solder Paste" de KiCad, mais il faut cependant faire quelques retouches du fait de la rétractation du plastique quand il est fondu par le laser. Pour obtenir un résultat correct en prenant en compte ce problème de rétractation du plastique qui donne des trous plus grands que prévu, il faut diminuer la taille de certaines pastilles.

Pour le faire, j'utilise Inkscape après avoir exporté la couche "Solder Paste" en SVG.
Il faut commencer par dégrouper toutes les pastilles, sans quoi leur position change quand on applique la réduction au groupe. Il faut ensuite ne laisser que les bords, qui seront les traits de coupe, car KiCad exporte des rectangles pleins.

Vous pouvez enfin sélectionner les pastilles "de taille moyenne" pour les réduire de 20 à 60% (selon l'épaisseur du plastique que vous avez trouvé, le type de plastique, et la puissance du laser lors de la découpe, et le type de composant).

Je sais que "de taille moyenne" ne veut rien dire du tout, et je vais donc l'expliquer.
Il n'est pas nécessaire de faire de modification pour les grandes pastilles comme les pattes de fixation de connecteurs ou les plans de masse des régulateurs de tension. Passé 3mm x 3mm, il faut laisser la pastille telle quelle.
Il en va de même pour les composants en boîtier 0402, car si le trou est trop petit la soudure colle au plastique et reste dans le trou du pochoir quand on le retire, ce qui n'est pas l'effet recherché.
Pour tous les autres trous, il faut appliquer une réduction, plus ou moins grande en fonction de la feuille de plastique, mais aussi du type de composant et de l'espacement des broches. Pour les circuits intégrés comme le microcontrôleurs du module, mais aussi l'EEPROM, la porte multifonction, ou le capteur de température, je fais une réduction plus importante (50% à 60%) que pour le reste des composants (20% à 40%), pour limiter ou supprimer les courts-circuits lors de la soudure qui se produisent quand il y a trop de soudure.

Une fois les pastilles réduites (en veillant bien à conserver leur position), vous pouvez ajouter un contour pour que le pochoir se détache de la feuille. Veillez dans ce cas à le faire plus grand que le circuit imprimé, ce qui permettra de le fixer, et faites attention à ne pas faire un contour continu, sans quoi le plastique risque de se replier pendant la découpe du fait de l'aspiration. Pour éviter cela, il suffit de laisser de petits espaces qui rattachent le pochoir au reste de la feuille (moins de 1mm de large), ce qui maintiendra le pochoir pendant la découpe et permettra de détacher le pochoir sans outils, juste en tirant dessus.

Vous pouvez maintenant aller au FabLab le plus proche si vous en avez un qui ait une machine de découpe Laser pour faire votre découpe.
Si ce n'est pas le cas, vous pouvez demander à un FabLab qui en a une, si ils peuvent vous faire la découpe en leur envoyant le plastique et une enveloppe timbrée pour le retour, avec un petit quelque chose pour le travail, négocié avec eux au préalable (et tous les FabLab de France qui ont une découpe Laser vont me maudire).
Ou bien utiliser les services de Pololu, qui proposent cette solution depuis quelques temps, soit parce qu'ils ont fait le même constat et eu la même idée que moi, soit parce que mon idée a voyagé (laissez moi croire en la deuxième solution svp), même si ils proposent ce service un peu cher à mon goût. http://www.pololu.com/product/446

Et enfin, avant d'utiliser le pochoir, je le "racle" avec une règle métallique pour enlever les surépaisseurs de plastique sur les bords des trous, du fait de la rétractation du plastique pendant la découpe.

Vous voila avec un (joli) pochoir CMS à moindre frais (en tout cas normalement bien moins de 70 euros), même si il ne tiendra pas des centaines d'utilisation, et ne peux pas être nettoyé à l'acétone. J'en ai utilisé certains une dizaine de fois, et je me sers d'une petite épingle pour nettoyer les restes d'étain une fois sec.

== Assemblage ==
Après quelques (trop nombreux) jours d'attente, vous avez enfin reçu votre circuit imprimé et vos composants, et vous allez pouvoir attaquer la suite des réjouissances :)

Bien entendu, il existe des sociétés spécialisées dans la réalisation des étapes suivantes pour des prototypes, mais les coût sont souvent non négligeables, et le résultat pas toujours au rendez-vous (composants inversés, mal soudés, ...).
A noter que certaines sociétés de fabrication de PCB proposent ce service ... à condition que vous utilisiez un logiciel propriétaire pour envoyer les données d'assemblage :(

=== Dépose de l'étain ===

[[Image:07-Pochoir-02.png|400px|right]]

Mais attention, ne vous précipitez pas, il faut commencer par un petit check-up, il est encore temps.
Avant de mettre de l'étain plein partout, vérifiez que vous avez bien reçu tous les composants, que vous n'en avez pas oublié, et que les empreintes correspondent bien. Il est encore temps de commander les références manquantes, en revanche, une fois l'étain appliqué avec le pochoir, il commence à sécher, et même si il est toujours possible de positionner les composants plus tard, c'est bien plus sympa quand ils "collent" dans le "gel" qui compose l'étain "en pâte" (ou crème à braser, ou étain "liquide", qui n'est autre que des micro billes d'étain dans un gel).

Vous avez tout ? Bien. Pas d'erreur de miroir sur les pattes des composants ? Parfait ! (Et oui, c'est du vécu).

Mais avant de vous lancer, un dernier préparatif : vérifiez que vous avez accès à un schéma de votre carte, pour pouvoir placer les composants au bon endroit une fois l'étain déposé sur le circuit.

'''Note''' : Pour ceux qu'un texte et quelques photos ne sauraient contenter, j'ai fait une vidéo de l'assemblage du module GPIO Demo, voir le lien en fin d'article.

Vous pouvez enfin attaquer les choses sérieuses, et dans une petite heure (ou moins, parce que vous êtes très fort) vous aurez votre nouveau jouet rien qu'à vous.

La première étape, dégraisser le circuit imprimé, pour que le gel adhère bien. Frottez le légèrement avec un chiffon non abrasif et un peu d'alcool, sans insister (normalement les circuits arrivent relativement propres, mais nos doigts ne le sont pas toujours).

Ensuite, le plus simple pour fixer le circuit pour l'application de l'étain avec le pochoir (ou tout autre méthode en fait) c'est la "patafix" (ou tout équivalent, je n'ai pas d'actions non plus). Cette matière semi collante permet de maintenir en même temps le circuit imprimé et le pochoir CMS que vous allez devoir aligner correctement. Pour cette opération, le pochoir en plastique transparent offre un très net avantage sur son homologue en métal opaque, mais on s'en sort dans tous les cas. Veillez à ce que la patafix n'empêche pas le pochoir d'être parfaitement plaqué au circuit imprimé.

Déposez un (tout petit) peu d'étain sur le pochoir (si vous avez de l'étain en seringue c'est plus pratique), et étalez le avec une spatule (j'utilise un morceau de pochoir métallique découpé dans un vieux pochoir inutile, et j'ai mis un morceau "prédécoupé" sur les pochoirs en plastique du kit du module GPIO Demo, mais n'importe quel morceau de plastique avec un bord droit fait l'affaire).
Appuyez bien sur le pochoir pour qu'il reste plaqué au circuit pendant toute l'opération, mais sans le faire bouger.
Remplissez bien tous les trous, puis raclez l'étain qui est en trop, pour qu'il ne reste que la bonne quantité d'étain dans les trous.

Vous pouvez maintenant passer au plus délicat, retirer le pochoir sans le faire bouger, et en laissant l'étain sur le circuit imprimé. Ne paniquez pas, vous pourrez recommencer plusieurs fois si besoin.
J'ai constaté que pour bien laisser tout l'étain sur le circuit il faut retirer le pochoir en le pliant, comme si il s'enroulait autour d'un rouleau.

Vérifiez bien qu'il ne reste pas (ou presque) d'étain dans les trous du pochoir, et si vous êtes satisfaits du résultat vous pouvez passer à la suite. Vérifiez aussi que l'étain ne se soit pas glissé sous le pochoir pendant l'application pour former de gros pâtés. Sinon, nettoyez le pochoir (sommairement) et recommencez à l'étape ... un peu plus haut quoi.

=== Placer les composants ===

[[Image:08-Placement-01.png|400px|right]]

Il ne vous reste que quelques étapes, mais celle-ci est peut-être bien la plus minutieuse, et la plus longue.

Vous allez maintenant pouvoir placer les composants CMS sur votre circuit. Attention, ne placez pas les composants traversants, ils gêneraient pour l'étape suivante.

Personnellement je préfère commencer par les petits composants, car ils collent au gel quand celui-ci est bien frais, et ne bougent plus quand on tourne ou déplace le circuit imprimé.
Pour ce faire, j'utilise une pince brucelle avec une pointe très fine, mais une simple pince à épiler peut faire l'affaire.

Une fois le composant positionné correctement, c'est à dire avec toutes les pattes ou les extrémités au dessus d'un plot de soudure, j'applique une petite pression sur le composant pour qu'il colle bien au gel et ne bouge plus par la suite. Cela évite notamment les composants qui se déplacent pendant que l'étain fond et se retrouvent en l'air, soudés par une seule patte ou d'un seul côté.

Attention à ne sortir qu'une référence de composants à la fois, ils sont tellement petits qu'il est difficile de lire les références sur les composants, ou même n'ont pas de références imprimée du tout (les condensateurs et les inductances par exemple).

Attention aussi au sens pour les composants polarisés (diodes, leds, certains condensateurs) ou avec plus de deux pattes. Il y a le plus souvent un indicateur, parfois sous le composant (pour les leds), parfois difficile à détecter, et il faut alors se référer à la documentation technique (ou utiliser une loupe, ou les deux).

Continuez avec les références suivantes, pour finir par les plus gros composants, que je place en dernier pour qu'ils ne gênent pas pour la pose des autres composants, mais aussi parce qu'une fois que le gel a un peu séché il est possible de bouger le composant sans déplacer l'étain, et de ne le "faire tenir" par une petite pression que lorsque le positionnement est bon.

Allez, plus que quelques composants à placer, courage ! (Oui, on a créé des machines pour ça, mais elles ne sont pas dans nos budgets).

=== Soudure CMS ===

[[Image:08-Plancha-01.png|400px|right]]

Passons aux choses sérieuses : sortez la plancha !

Pour souder des composants CMS il existe différentes méthodes, mais si l'on en croit les tests que l'équipe de Sparkfun a réalisé le plus efficace c'est la plancha (ou toute surface chaude équivalente : poêle électrique, machine à crêpes, ou même une vieille poêle sur le gaz (attention aux problèmes conjugaux ...)).

Cette étape est la plus simple : on pose le circuit imprimé sur la plancha (composants sur le dessus bien entendu), on la branche, et on attends.
C'est aussi la plus dangereuse : la plancha va atteindre plus de 250°C ! Gare aux brulures, à ne faire qu'accompagné d'un adulte (responsable ? ça existe ?).
En fonction de la puissance de la plancha, cela dure entre 2 et 5 minutes, et l'étain se met à fondre, soudant les composants.
On voit très bien quand l'étain fond car il devient brillant.

Une fois que le processus a commencé, cela va très vite, et il ne faut pas insister si quelques points ne veulent pas fondre tout de suite, car les autres composants sont entrain de cuire. Il faut retirer la carte de la plancha tout de suite, en faisant bien attention à la garder à l'horizontal car ils ne sont plus tenus en place par le gel. Si vous inclinez la carte à ce moment la, les composants vont glisser (Il faut entre 4 et 10 secondes à l'étain pour solidifier). Pour cela les plancha sont bien pratiques car elles ont généralement une zone sans rebord, ce qui permet de faire glisser la carte vers le bord et de la saisir avec une pince avant de la déposer sur une surface protégée (surtout pas sur du plastique, elle est autour de 200°C !)

Ça y est, c'est fait, c'est soudé ! Enfin ...

=== Reprise des faux contacts ===

[[Image:08-Shorts-01.png|400px|right]]

Bon, en théorie, tout c'est bien passé et il n'y a pas de faux contacts.
Malheureusement, même avec un pochoir CMS métallique certaines pattes de circuits intégrés peuvent être reliées par de l'étain si il y en avait un petit peu trop.

Dans ce cas là, pas d'affolement, la première chose à faire : ne surtout pas prendre le fer à souder ou remettre la carte sur la plancha. La première étape est de reprendre le schéma de la carte.

Et oui, j'ai parfois passé près d'une demie heure à tenter d'enlever la soudure qui faisait contact entre deux pattes ... reliées par un fil sur le schéma.

Si effectivement le schéma dit qu'il ne devrait pas y avoir de contact, utilisez la tresse à dessouder et le fer pour enlever le surplus d'étain, en mettant un morceau propre de la tresse à dessouder entre l'étain à enlever et le fer à souder. Testez avec le multimètre pour vérifier que le court-circuit a bien disparu.

Il faut aussi finir de souder les composants des bords de la carte qui n'auraient pas été soudés sur la plancha.
Pour ceux-ci, pas besoin de rajouter de soudure, il suffit de poser le fer à souder (chaud) très proche de la pastille (ou sur la pastille) pour que l'étain fonde et soude le composant.

Profitez-en pour vérifier que tous les composants sont bien soudés des deux côtés.

Attention, vous pourrez avoir l'impression que certains composants sont mal soudés ou qu'il n'y a pas assez de soudure car la quantité de soudure utilisée avec cette méthode est très faible et que la soudure ne forme pas de pâté. C'est normal. Pour vous rassurer, vous pouvez utiliser la même méthode que pour finir de souder les composants dont l'étain n'avait pas fondu à la plancha. Vous verrez alors l'étain briller un peu plus, et re-solidifier lorsque vous retirez le fer.

=== Soudure des composants traversants ===

Avant dernière étape avant de jouer avec votre circuit : souder les composants traversants, et éventuellement ajouter de la soudure sur les pads de fixation des gros composants et des connecteurs.

Pour cela rien de magique (quoique, voir l'astuce qui suit). Mettez en place le composant (attention au brochage si il y en a un), positionnez votre fer à souder en contact avec le circuit imprimé et la patte du composant que vous voulez souder, puis apportez la soudure, et retirez la soudure et le fer (dans cet ordre).

Petite astuce : utilisez de la patafix pour maintenir le composant en place et pour maintenir le circuit sur le plan de travail. Depuis que j'utilise cette technique ma troisième main sert de support aux toiles d'araignées ...

== Tests ==

Dernière étape avant de passer à la programmation, qui fera l'objet du prochain article : les tests électriques.

Ne mettez pas votre circuit sous tension tout de suite, certains composants ne tiennent pas longtemps en cas de court circuit, même alimentés par l'USB.

Utilisez le multimètre pour vérifier qu'il n'y a pas de court circuit entre le +5V et la masse, entre le +3V et la masse, et pour ne pas risquer d'endommager les ports USB de votre PC/HUB (certains sont très fragiles), vérifiez aussi entre les deux pistes USB (D+ et D-) et la masse et le +5V.

Si vous n'êtes pas trop impatient, vous pouvez aussi tester entre chaque pattes consécutives des circuits intégrés, mais vérifiez bien le schéma en même temps, toujours pour éviter de passer des heures à vouloir enlever un court-circuit qui n'en est pas un.

Tous est bon ? et bien c'est fini pour cette fois.

Si vous avez réalisé le circuit du module GPIO Demo, vous pouvez le connecter sur un port USB de votre PC.

Le microcontrôleur doit se mettre automatiquement en mode programmation (ISP) et la led bicolore doit faire apparaitre deux point lumineux très très faibles (vert et rouge).

Si votre noyau a bien le support FTDI (suffisamment récent pour avoir le composant FT230XS, plus récent que 2.6.28 de mémoire), vous aurez alors un nouveau ttyUSB (présent dans /dev/, et annoncé dans les logs du noyau), et en envoyant le caractère '?' le microcontrôleur devrait répondre "Synchronised".

Rendez-vous dans l'article suivant pour l'écriture du code en C, la compilation, et la programmation avec l'utilitaire lpcprog :)

+++

== Liens ==
FabLabs :
* [http://www.electrolab.fr/ ElectroLab de Nantère]
* [http://www.fablab-lyon.fr/ Fabrique d'Objets Libres] (FabLab de Lyon)
Informations sur la fabrication de circuits imprimés :
* http://wiki.jelectronique.com/realisation_de_circuits_imprimes
* http://alain.canduro.free.fr/circuits.htm
Fabricants de circuits imprimés :
* [https://www.pcb-pool.com/ PCB-Pool]
* [http://www.dipole-electronique.fr/ Dipole-Electronique]
* [http://www.seeedstudio.com/service/ Seeed Studio]
Module GPIO Demo :
* [http://www.techno-innov.fr/technique-module-gpio-demo/ Page du module sur notre site]
* [https://www.youtube.com/watch?v=dtVMRGIdkGQ Vidéo de l'assemblage du module sur Youtube]

Fichier:08-Shorts-01.png

2020-09-02T20:55:57Z

Nathael :