Discussion :

[wilsonstevo]

Bonsoir,
je suis un passionné des systems embarques mais malheureusement j´ai aucune connaissance dans le domaine. De ce fait j´aimerai comprendre comment se manipule les registres, on reconnait les interface qui nous sont utile sur uc, en bref un cours ou livre qui pourra méxpliquer en detail le uc. J´ai une connaissance avancée en programmation c/c++.
je souhaiterai mieux comprendre la signification des termes comme avr32, EEPROM et pourquoi il doit toujours se trouver dans un pcb etc..

Merci d´avance

[Vincent PETIT]

Salut,
La question est vaste. Je ne pense pas qu'un seul livre puisse regrouper les thèmes :
- Microcontrôleur (µC)
- Électronique (Mémoire EEPROM, ...)
- Les circuits imprimés (PCB)

On pourrait écrire une livre complet rien que sur les PCB et la manière dont on doit le concevoir tellement c'est technique. Pourtant on dirait pas ! Dessiner un plan de masse efficace, les plans 0V, les freins thermiques, les empreintes de composants en fonction du process de fabrication, les pièges de la CEM avec les couplages inductifs/capacitifs, couplage carte chassie, boucle de masse, le cross talk (diaphonie), ligne de garde, les pistes wiggle (zigzag, on en voit sur le Raspberry) .....

Tu as plusieurs manières de voir les choses :
1) Vision Informatique des systèmes embarqués, orientée software au dessus de la couche HAL (Hardware Layer Abstraction)

- Se tourner vers Arduino car il permet de se concentrer sur le soft.
- Pas besoin de trop se préoccuper du micro en tant que tel ni même des registres.
- Beaucoup de shield (carte électroniques) existent et forment des accessoires/périphériques
- Beaucoup de ressources sur le internet

2) Vision Électronique des systèmes embarqués, orientées hardware et soft en dessous de la couche HAL

- Éplucher un microcontrôleur de A à Z
- Un peu de notion d'électronique seront nécessaires pour comprendre les mécanismes d'un micro.
- Manipuler les registres au coeur du micro
- Le soft se fera a partir de rien (pas de bibliothèque) et pour faire bien il te faut connaître l'ensemble du micro et de ses registres.

Les visions 1 et 2 ont des avantages et inconvénients.

Vision 1)
Avantages : Motivant ! Travail de prototypage rapide, efficace à court terme, grosse communauté, simple car bibliothèques déjà faites...
Inconvénients : Peu de maîtrise du micro, passer sur une autre cible est donc très compliqué, débogage compliqué.

Vision 2)
Avantages : Maîtrise du micro, migration facile vers d'autres cible, débogage facilité puisque tu es à l'origine des bibliothèques.
Inconvénients : Décourageant, plus long à prendre en main car les outils ne sont pas les mêmes, refaire la couche HAL ou certaine partie, les communautés dépendent des fabricants de micro par exemple Microchip est probablement le microcontrôleur le plus rependue, entre autre car il est majoritairement utilisé par les amateurs. Ensuite tu as le fabricant Atmel avec sa gamme de micro AVR (Arduino UNO est basé sur un micro Atmel ATMEGA328P) que tu retrouves chez beaucoup de professionnel avec un pied dans le grand public via Arduino. Puis il y a tous les autres, avec les communautés moins grandes mais plus pointues car professionnelles : Texas Instruments, Freescale, NXP, ST, Renesas, TOSHIBA, ...

C'est un curseur a placer entre "Maîtrise et Efficacité" tout simplement.

Puisque tu es dans l'informatique, je peux prendre une image très concrète d'un tel choix :
Souhaites tu utiliser un framework ou souhaites tu réaliser un framework ?

ps : Arduino c'est excellent pour démarrer ensuite tout dépendra du choix que tu veux faire.
Regarde, les tutoriels Arduino de f-leb http://f-leb.developpez.com/ ça te donnera un très bonne idée.

Puis dit nous ce que tu souhaites apprendre.

A+
Vincent

[wilsonstevo]

Merci deja Vincent pour ton temps et l´explication apportée. Le lien je le trouve très interessant. De ce fait je commencerai d´abord par la et toujours dans l´intention dans un futur proche d´aller dans la vision electronique.
Je souhaiterai de ce fait realiser un framework et serai ravis aussi si tu(si je peux tutoyer ) m´envoies des liens dans ce sens.

Merci A+
Wilsonstevo

[Vincent PETIT]

Salut,
Bien sur que tu peux me tutoyer !

Par contre, je pense que quand tu parles du lien que j'ai donné, tu fais référence à l'autre sujet que tu as posté dans le forum. Je pense que dans un soucis de clarté, il faudrait que tu répondes dans les sujets concernés
Sinon, un personne qui serait intéressé par la même chose que toi, ne va pas comprendre pourquoi une question est posée à un endroit et la réponse autre part. Pire encore, il pourrait ne pas voir que la réponse est ailleurs.
Je vais donc répondre uniquement à la question initiale (si tu avais des questions sur Wake et Inhibt du protocole LIN, pose les dans l'autre sujet que tu as ouvert comme ça tous les autres membres pourront aussi voir et participer)

Ok, donc tu veux explorer un micro-contrôleur.

Je te conseille de prendre plusieurs points en considérations :
Comme tu te doutes, des micro-contrôleurs il y en a beaucoup et surtout à tous les prix.

Il y a des microcontôleurs 8 bits, 16 bits, 32 bits ARM et bien entendu plus ils sont gros et plus leur apprentissage est complexe. Je te recommande un petit microcontrôleur le temps de la prise en main et la découverte car tu vas vite te rendre compte qu'ils fonctionnent quasiment tous de la même façon, peu importe.

Le prix est la disponibilité des outils de programmation/débogage/développement représente un coût.

Généralement le kit pour développer comprend
Compilateur C -> Débogueur -> Sonde débogage/programmateur (l'interface PC/micro) -> Micro-contrôleur souvent sur une carte de développement.

Suivant le micro-contrôleur que tu choisis, le prix va changer.


Exemple avec Arduino (prix approximatif)

Compilateur C = GCC-AVR + Eclipse comme IDE donc gratuit
Débogueur = GDB/Avarice/Avrdude donc gratuit
Sonde de débogage/programmateur = ATMEL ICE à 80€
Microcontrôleur sur sa carte de développement = Arduino UNO à 20€

On est à 100€ pour le top du top. Tu peux te passer de la sonde de débogage à 80€ pourquoi pas, tu pourras toujours programmer ton micro, je te rassure ! Mais sans elle, tu ne pourras pas voir l'état de tes registres en direct, pas de possibilité de faire des points d'arrêt, de faire du mode pas à pas etc... Tu programmes et tu essayes. Quand il y a un gros bug genre pointeur qui déborde sur un micro, il y a pas d'erreur Segment Fault car pas d'OS, si la pile déborde idem et sans débogueur c'est pas du tout évident de voir.
Très répendu donc il y a beaucoup de ressources sur le net.
Il y a de la littérature française sur le sujet.
Souvent les utilisateurs se passent de la sonde alors que dans l'industrie c'est tout simplement inimaginable !


Exemple avec Microchip (prix approximatif)

Compilateur C = C18 C compiler + MPLAB tout est gratuit
Débogueur = Intégré à MPLAB donc gratuit
Sonde de débogage/programmateur = PICkit à 50€
Microcontrôleur sur sa carte de développement = PICDEM, il y en a vers les 20€

On est à 70€ pour le tout mais il y a la possibilité de déboguer en pas à pas + point d'arrêt + voir les registres en direct etc...
Très répendu chez les amateurs d'électronique donc il y a beaucoup de ressources sur le net.
La sonde PICkit est obligatoire car elle fait office de programmateur + débogueur en même temps
Il y a de la littérature française sur le sujet.


Exemple avec Texas Instruments (prix approximatif)

Compilateur C = GCC-MSP + Eclipse comme IDE donc gratuit
Débogueur = GDB-MSP + MSPDEBUG donc gratuit
Sonde de débogage/programmateur = Intégré dans la carte de développement donc gratuit
Microcontrôleur sur sa carte de développement = LaunchPad de Texas Instruments, il y en a vers les 12€

On est à juste 12€ pour le tout et il y a la possibilité de déboguer en pas à pas + point d'arrêt + voir les registres en direct etc...
Par contre Texas Instruments est très répendu mais plus chez les pro que chez les amateurs donc il y a beaucoup moins de ressources sur le net.
Il n'y a pas (encore) de littérature française sur le sujet mais en anglais oui il y en a.


Tu peux faire ce comparatif avec n'importe quel autre micro, tu verras que certain n'ont que des compilateurs payants et chers (Keil ou IAR.) Le choix est vaste et il y a des avantages et des inconvénients mais ça tu t'en doutais car en informatique c'est la même chose. Il suffit de devoir choisir un langage en fonction d'un projet donné pour voir apparaître beaucoup de questions, de compromis et de choix à faire.

Qu'est ce qui t'intéresserait le plus ?
https://www.arduino.cc/en/Main/ArduinoBoardUno
http://www.microchip.com/Development...1-f410ae4069dc
http://www.ti.com/ww/en/launchpad/la...-msp.html#tabs

[wilsonstevo]

Merci une fois de plus, l´arduino uno kit je l´ai acheté il y´a de cela peu et je me suis justement rendu compte que les bibliothèque me sont deja disponible a utilisé mais j´ai pas de sonde de debogage(ou peut-être c´est dans le kit mais je me rend pas compte) que je trouve deja cher car l´arduino uno m´a couté aussi environ 90euro. Mais jaurai surement souhaité acheté un microcontroller séparé et pouvoir inserer les composant que j´aurais besoin et utilise GCC+ elcipse pour le developement.
Qu´en penses tu?
ou serait-il mieux actuellement de commencer par arduino uno? si tu connais aussi ou je pourrai suivre une bonne formation a bon prix(moin cher) dans les environs de straßbourg je serai ravi.

Merci d´avance
A+

[Vincent PETIT]

L'apprentissage d'un microcontrôleur n'est pas forcément long a condition de :
- Avoir les bases communes entre l'électronique et l'informatique (le binaire)
- Ne pas griller les étapes
- Ne pas être fâché avec l'anglais car toutes les doc constructeurs sont en anglais (anglais technique, heureusement)

Donc tu as déjà un Arduino UNO. Pour la sonde Atmel ICE, elle n'est pas livrée avec, tu as simplement dans ce kit : le PCB (circuit imprimé) Arduino équipé du microcontrôleur avec le nécessaire pour le programmer mais rien pour le déboguer. Donc tu ne peux que programmer, lancer le soft et voir si ça fait ce que tu voulais ou pas. Bien sur il y a des moyens de faire du débogage logiciel en faisant des "println", autrement dit comme tu fais probablement avec ton PC lorsque tu programmes en langage C, c'est à dire faire des "printf" pour aider au débogage/mise au point.
Tu l'as vraiment payé 90€ ?????

Mais jaurai surement souhaité acheté un microcontroller séparé et pouvoir inserer les composant que j´aurais besoin

Si tu regardes sur le PCB, tu vas voir qu'il n'y a pas grand chose de plus que le micro Atmel ATMEGA328P.

Concernant le logiciel, tu as 2 choix possibles :
- Soit tu prends l'environnement de développement Arduino
- Soit tu prends Eclipse + GCC-AVR + AVRDUDE, le dernier étant celui qui te servira à programmer le micro-contrôleur depuis Eclipse. Il existe des plugins tout fait pour gérer ça (je l'ai fait il y a environ 10 mois).

Moi a ta place et vu que tu souhaites vraiment voir le coeur du micro, je commencerai avec Eclipse + le plugin qui va bien + GCC-AVR + AVRDUDE.
Pour commencer en langage C, tu as ça par exemple http://brittonkerin.com/cduino/lessons.html
Et avec la datasheet http://www.atmel.com/images/Atmel-82...t_Complete.pdf tu décodes le programme.

Exemple :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
#include <avr/io.h>
#include <util/delay.h>
 
//
// Assumptions:
// 	- LED connected to PORTB (arduino boards have LED L onboard)
// 	- F_CPU is defined to be your cpu speed (preprocessor define)
//
// NOTE: the file in blink/blink.c is a better place for look for an example of 
// how to address individual IO pins.
//
// WARNING: this technique doesn't translate to all the other IO pins on a
// typical arduino, because the arduino bootloader uses some of them for its
// own purposes (e.g. PD0 is set up as the RX pin for serial communication,
// which precludes its use as an output).  The unconnected IO pins are
// presumably ok to use, or you can just nuke the bootloader with an
// AVRISPmkII or similar device.
 
int main (void)
{
	/* set all pins of PORTB for output*/
	DDRB = 0xFF;
 
	while (1) {
		/* set all pins of PORTB high */
		PORTB = 0xFF;
		_delay_ms(500);
 
		/* set all pins of PORTB low */
		PORTB = 0x00;
		_delay_ms(500);
	}
	return 0;
}

A l'aide de la doc constructeur, tu essayes de comprendre ce que c'est que ces registres DDRB et PORTB, comment on les manipule et à quoi ils servent dans le micro ? Voir le chapitre 14.2.1 (page 76)

ps : La première fois qu'on ouvre une doc constructeur ça fait très peur mais une fois qu'on s'est forcé un peu on comprend vite comment lire efficacement une datasheet et tout son contenue (c'est le mode d'emploi du micro) Bien sur il y a des choses que tu ne comprendras pas tout de suite et le forum est justement là pour ça.

[Auteur]

Donc tu as déjà un Arduino UNO. (...) Tu l'as vraiment payé 90€ ?????

Il existe des kits de démarrage qui contiennent un Arduino, des composants de base (résistances, led, condensateurs, transistors, etc.), une breadboard, un moteur, un servo-moteur, des straps...


Une chose qui est possible avec l'Arduino UNO (version DIP) : après l'avoir programmé en utilisant la platine et l'environnement de développement on peut le séparer de sa platine et l'installer dans un circuit de sa création.

Pour les formations avec Arduino (en tout cas pour la base et réaliser des petits projets), il y a les MJC ou les FabLab. Mais pour aller plus loin, il faut regarder sur le net. L'Arduino étant assez populaire on peut trouver facilement des idées.


Parmi les microcontrôleurs ARM, il y a aussi les STM32 montés sur les platines Nucleo. La platine coûte une dizaine d'euros : http://www.st.com/web/catalog/tools/...sc=stm32nucleo

[Vincent PETIT]

Il existe des kits de démarrage qui contiennent un Arduino, des composants de base (résistances, led, condensateurs, transistors, etc.), une breadboard, un moteur, un servo-moteur, des straps...

Ok, alors je comprends mieux le prix.

[Kannagi]

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
#include <avr/io.h>
#include <util/delay.h>
 
//
// Assumptions:
// 	- LED connected to PORTB (arduino boards have LED L onboard)
// 	- F_CPU is defined to be your cpu speed (preprocessor define)
//
// NOTE: the file in blink/blink.c is a better place for look for an example of 
// how to address individual IO pins.
//
// WARNING: this technique doesn't translate to all the other IO pins on a
// typical arduino, because the arduino bootloader uses some of them for its
// own purposes (e.g. PD0 is set up as the RX pin for serial communication,
// which precludes its use as an output).  The unconnected IO pins are
// presumably ok to use, or you can just nuke the bootloader with an
// AVRISPmkII or similar device.
 
int main (void)
{
	/* set all pins of PORTB for output*/
	DDRB = 0xFF;
 
	while (1) {
		/* set all pins of PORTB high */
		PORTB = 0xFF;
		_delay_ms(500);
 
		/* set all pins of PORTB low */
		PORTB = 0x00;
		_delay_ms(500);
	}
	return 0;
}

les DDRB et PORTB sont en variable global ?
Ce n'est pas tant l'utilisation des variable global qui me choque (quoique) , mais que personnellement je n'écris jamais mes I/O de cette façon.

Personnellement j'écris toujours mes I/O comme ceci "*((volatile unsigned int *)(REG))"
Et donc je le met en define :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

#define RW_REGISTER(REG) 	*((volatile unsigned int *)(REG))

Alors mon code suivant serait plus pour un ATtiny DDRB et PORTB sont sur "4 bits" , les 4 bits de poids fort sont inutilisé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
#define AVR_SET_PORTB(_portb0,_portb1,_portb2,_portb3) \
		((unsigned int)_portb0 <<  0  ) \
		((unsigned int)_portb1 <<  1  ) \
		((unsigned int)_portb2 <<  2  ) \
		((unsigned int)_portb3 <<  3  )
		
#define AVR_SET_DDRB(_ddrb0,_ddrb1,_ddrb2,_ddrb3) \
		((unsigned int)_ddrb0 <<  0  ) \
		((unsigned int)_ddrb1 <<  1  ) \
		((unsigned int)_ddrb2 <<  2  ) \
		((unsigned int)_ddrb3 <<  3  )

Et donc cela serait mieux d'écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
#define PORTB 0x02 //Pour le ATtiny
RW_REGISTER(PORTB) = AVR_SET_PORTB(1,1,1,1);

Cela n'est peut être pas dérangeant sur des processeur 8 bits (même si cela demande forcément de bien connaître la machine pour comprendre les I/O) , mais sur des machines a 32 ou 64 bits un poil plus complexe faire des nombres magique comme : 0x80457F01 , c'est totalement illisible :p
De plus j'éviter les variables global autant que possible ,et le define est une bonne solution.

[Delias]

Bonjour Kannagi

La définition des registres des AVR est implémentée dans un .h spécifique à chaque micro de la famille lié par avr/io.h
Par exemple pour DDRB sur un ATTiny 2313 (iotn2313.h):

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
/* Data Direction Register, Port B PORTB[7:0] */
#define DDRB    _SFR_IO8(0x17)
 
#define DDB7    7
#define DDB6    6
#define DDB5    5
#define DDB4    4
#define DDB3    3
#define DDB2    2
#define DDB1    1
#define DDB0    0

Et il existe également la macro _BV qui vient automatiquement avec le io.h (défini dans sfr_defs.h inclus par common.h lui-même inclus par io.h)

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

#define _BV(bit) (1 << (bit))

Tout cela est défini dans un gros jeu de fichier .h fournis directement avec le GCC-AVR. Et les datasheets reprennent cette façon de coder.
L'utilisation au bit par bit se fait de la manière suivante:

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
  DDRD |= _BV(DDD0);  // ASM: SBI DDRD, 0; (Set Bit in I/O Register)
  PORTD &= ~(_BV(PD0));  // ASM: CBI PORTD, 0; (Clear Bit in I/O Register)
  PORTB = _BV(PB7) | _BV(PB5) | _BV(PB4);  //ASM: LDI r24, 0xB0; OUT PORTB, r24;

Alors oui on peut les réécrire, mais est-ce que cela apporte vraiment quelque chose? D'autant que les adresses des registres peuvent changer d'un micro à l'autre. Donc quand tu changes de micro tu es bon pour réécrire tes définitions.

Il me semble que les PIC travaillent avec la même philosophie.

Delias

[Kannagi]

Je vois s'il existe deja des macros et defines pas de souci
J'imagine que "_SFR_IO8" est équivalent a mon RW_REGISTER :p

Après je n'ai jamais codé pour un l'AVR Atmel en passant , je me suis juste intéressait dessus ^^

[Delias]

Oui presque, le type est uint8_t et il y ajout du décalage de 0x20 qui existe entre l'espace I/O et l'espace SRAM. Ces points sont spécifiques à l'architecture AVR.
Edit: En fait il y a une double définition, celle ci-dessus c'est pour le code en C, et il y a une deuxième qui ne renvoie que l'adresse (sans l'offset) et qui est utilisée dans les parties en ASM.

Mon travail de diplôme fut sur un DSP TI dont chaque registre était défini par un Union d'un Uint32 et d'une structure de bits, permettant l'accès aux registres (de 32bit) sous la forme PORTB.all ou PORTB.bits.PB17. Mine de rien c'était vachement pratique pour le codage et l'utilisation de la complétion automatique. (J'ai repris les noms AVR, depuis le temps j'ai oublié ceux de TI )

Delias

[Vincent PETIT]

Salut,

De plus j'éviter les variables global autant que possible ,et le define est une bonne solution.

En effet, si on ne fait pas attention on a parfois des belles surprises surtout lors de l'appel d'une fonction qui l'utilise.

A l'appel de la fonction on empile, la variable globale est mise dans un registre de travail interne du CPU lors du traitement dans la fonction mais une fois sortie de la fonction, on dépile et la variable globale n'est pas mise à jour.

Si on précise au compilateur que c'est une variable globale (avec le mot clé volatile sur GCC) alors ce que j'ai écrit juste au dessus se transforme en :

A l'appel de la fonction on empile, la variable globale est mise dans un registre de travail interne du CPU lors du traitement dans la fonction mais avant de sortir de la fonction la variable globale est mise à jour et après on dépile.

Exemple d'un problème courant.

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
int v_globale = 0;
 
 
void func (void)
{
   v_globale += 1; 
// ici v_globale va être placé dans un registre interne
// on va lui faire + 1 et pourquoi diable est ce que le 
// micro irait lire le registre de travail et remettre cette 
// valeur dans la RAM ? Aucune instruction ne lui demande !
}
 
 
int main (void)
{
   func();
 
   return 0;
}

Après je n'ai jamais codé pour un l'AVR Atmel en passant , je me suis juste intéressait dessus

Pour avoir lu plusieurs de tes sujets, tu ne rencontrerais aucun problème a programmer ce genre de composant.