TECHNOLOGIE SEPTEMBRE-OCTOBRE 2006
TECHNOLOGIE SEPTEMBRE-OCTOBRE 2006
Dans le cadre d’activités en STS
Systèmes électroniques, les PSoC
constituent une solution très intéres-
sante, aussi bien pour la création d’un
nouveau système embarqué (« Éla-
borer une nouvelle maquette ») que
pour l’évolution d’un système indus-
triel existant («Adapter le logiciel à
un nouveau cahier des charges »).
En effet, l’intégration des fonctions
analogiques et numériques en fait un
composant adapté à de nombreuses
applications, telles que le pilotage de
bases robotiques mobiles comportant
plusieurs capteurs numériques et ana-
logiques, une interface USB/IrDA, un
contrôleur de machine brushless, une
boussole électronique, un chargeur de
batteries, etc.
Si le développement d’applications
PSoC avec le logiciel PSoC Designer ne
requiert pas de connaître l’architecture
des blocs analogiques et numériques
(au sens hardware), la connaissance
minimale des registres et du cœur du
microcontrôleur est nécessaire pour
l’utilisation de fonctions telles que les
ports d’entrée/sortie. En effet, l’écri-
ture ou la lecture d’un port se fait
par l’utilisation directe du registre
(PRTxDR, «x » étant le numéro du
port). Ainsi, en faisant des parallèles
entre le logiciel PSoC Designer mas-
quant les registres et la documenta-
tion complète des PSoC, on montre à
l’étudiant que rien n’est magique et
que l’architecture, qui paraît souple
(et qui l’est relativement), est en réa-
lité « gravée» dans le silicium.
La programmation
de fonctions internes
La mise en œuvre des fonctions
internes au PSoC (CAN, I2C, LCD,
timer, etc.) se réalise toujours selon
le même schéma.
L’environnement de développement
PSoC Designer offre plusieurs vues du
projet : la première concerne la biblio-
thèque de ressources (fonctions), la
deuxième est relative au placement
des fonctions dans le PSoC, à leur
configuration et interconnexion, et
la dernière permet le développement
de l’application en langage assem-
bleur ou en C.
L’architecture de l’outil
de développement PSoC Designer
La documentation
D
émarrer avec les PSoC requiert l’aide des docu-
ments constructeur. Chaque fonction a son chier
d’aide associé.
Le manuel de référence des PSoC en donne les caracté-
ristiques hardware complètes :
Technical_reference_manual.pdf (ou TRM)
Pour chaque famille de PSoC, Cypress propose une
datasheet moins détaillée que le TRM, donnant les carac-
téristiques électriques, les performances, le brochage, les
types de boîtiers. Le côté applicatif est détaillé dans deux
chiers, qui présentent les jeux d’instructions du micro-
contrôleur, les fonctions assembleur ou C, la manière de
traiter les interruptions en C, etc.:
Assembly Language User Guide.pdf
C Language Compiler User Guide.pdf
Le site PSoCDeveloper et celui de Cypress donnent un
nombre croissant de notes d’application, documents
incontournables également:
www.psocdeveloper.com
www.cypress.com
Enn, ce dernier ore de nombreux exemples d’applica-
tion de la technologie CapSense, à télécharger:
http://www.cypress.com/publishedcontent/publish/
design_resources/more_resources/contents/
psoc_r__example_projects___cy3212_capsense_
training_14.zip
ration ni développement n’ont encore
été réalisés. Dans le cas d’une évo-
lution d’un projet PSoC existant, le
clonage de ce dernier est possible:
on peut ainsi conserver son « patri-
moine » (fonctions, code assembleur
ou langage C, configuration du PSoC)
et le transférer à un PSoC de n’im-
porte quelle autre famille
–
en gar-
dant à l’esprit que si celui-ci possède
moins de ressources, PSoC Designer
n’intégrera qu’une partie des fonctions
du projet original.
Un projet auquel il manquerait des
fonctions peut évoluer simplement
par clonage sur un PSoC ayant plus
de ressources. À ce stade du projet,
les concepteurs du système embarqué
(carte électronique) et ceux de l’ap-
plication (PSoC) voient leurs déve-
loppements intimement liés. Tous
ont des contraintes : les premiers en
termes de routage de la carte, et les
seconds, de ressources matérielles
(broches d’entrée/sortie du microcon-
trôleur, routage interne du PSoC…).
Si le système est flexible, toutes les
configurations ne sont pas possibles
ou permises, et il convient de soigner
cette étape, notamment quand la réa-
lisation de la carte et celle de l’appli-
cation sont confiées à deux groupes
d’étudiants distincts.
Le déroulement du projet se pour-
suit par le codage de l’applicatif et
les tests. Le modèle de développe-
ment adapté pour les projets PSoC
est celui de la spirale: l’analyse des
besoins conduit aux spécifications,
vient ensuite le développement d’un
prototype (configuration et code), et
enfin la réalisation. Ce processus est
réitéré en revenant à l’analyse des
besoins. C’est l’occasion pour l’étudiant
de maîtriser rapidement la démarche
méthodologique. Il est fortement con-
seillé de la suivre pour valider suc-
cessivement chacune des fonctions
intégrées au PSoC (configuration,
développement, tests, validation)…
même si, compte tenu de leur abon-
dance, le nombre d’itérations peut
être élevé et la convergence vers les
objectifs du projet (délais, produit fini)
difficile à atteindre
–
d’où la néces-
sité d’un pilotage efficace par l’équipe
pédagogique.