Multiplexeurs et PIC ?!

[invite9eed411b]

Bonjour à tous !

Je me présente rapidement vu que c'est mon premier post sur ce forum: Je m'appelle Bertrand, j'ai 21 ans et je suis en deuxième année d'école d'ingénieur à Paris.

Dans le cadre de mon projet d'étude, je suis en train de réaliser un contrôleur MIDI. Pour ceux qui ne savent pas à quoi ça sert, il s'agit en gros d'une table de mixage pour des logiciels de MAO.

J'ai trouvé un site super pour réaliser ce projet www.ucapps.de

Je me suis donc grandement inspiré des choix technologiques de ce site, à savoir l'utilisation d'un PIC.

J'en suis à la phase de programmation, et je bloque complètement!! (a vrai dire je débute complètement dans la programmation des pics )
Il faut que mon pic soit capable de faire une conversion ana/num pour un grand nombre de potentiomètres (32). D'où l'utilisation de 4 multiplexeurs 4051.

Si j'ai bien compris il faut donc que j'utilise 4 entrées RA du pic pour effectuer la conversion ana/num, et trois sorties pour piloter les multiplexeurs.

Donc, tout simplement, je fais appel à vous pour savoir si vous connaissez un exemple de programmes pouvant réaliser cette fonction?

Deuxième question:
J'aimerai n'envoyer à mon ordinateur que la/les valeur(s) du/des potentiomètre(s) que je tourne et non pas toutes les valeurs. Je me suis dis qu'il fallait mémoriser la valeur de tous les potentiomètres à l'instant t, les comparer avec les valeurs à l'instant t+1 et ne placer dans le registre du pin TX que les valeurs qui diffèrent.
Est-ce le meilleur choix ?
Si oui, comment réaliser cette comparaison?

J'ai un peu survolé le datasheet du PIC, ainsi qu'un tutorial sur la programmation, mais c'est encore trés flou !!!

Merci pour votre aide!
-----

[Jack]

Bonjour,

tu ne nous renseignes pas sur le type de pic que tu as retenu, ni sur le langage non plus. Je suppose que ce sera en C vu qu'il ne doit pas s'agir d'une petite application.

Donc, tout simplement, je fais appel à vous pour savoir si vous connaissez un exemple de programmes pouvant réaliser cette fonction?

SI tu veux développer une appli autour d'un µcontrôleur, il va bien falloir t'investir dans la lecture de la doc d'une manière ou d'une autre et commencer par faire un ou deux petits programmes pour voir si tu as bien compris la philosophie de la programmation de ce genre de petites bêtes.

Du coup, le bout de programme que tu cherches ne devrait plus vraiment te poser de problème: ça revient toujours à envoyer des 1 et des 0 au bon endroit et au bon moment.

A+

[invite9eed411b]

Salut !

tu ne nous renseignes pas sur le type de pic que tu as retenu

Et bien à vrai dire, le site sur lequel je suis allé conseille l'utilisation d'un PIC 18F452. En effet la personne qui est à l'origine du site a développé une sorte d'OS pour le PIC18F452 qui contient déja toutes les variables nécessaires au bon fonctionnement du contrôleur:http://www.ucapps.de/mios_fr.html. Il ne reste alors qu'a définir le nombre de potentiomètres, de boutons poussoir, la présence d'un écran LCD ... bref c'est trés pratique, facile à installer et à utiliser, mais trés dur à expliquer devant un jury!

Pour ma part, j'aimerai vraiment réaliser mon programme pour ne pas simplement copier tout et ne rien comprendre. Sachant que rien ne m'empêche d'installer l'OS plus tard, j'opterai donc pour le PIC18F452

Je suppose que ce sera en C vu qu'il ne doit pas s'agir d'une petite application.

En effet je pense que ça sera plus facile, même si pour le moment je regarde surtout comment programmer en assembleur.

J'ai encore un peu réfléchi au pilotage du multiplexeur et au programme, et si j'ai bien compris, pour chacune des combinaisons des 3 bits de contrôle, je vais devoir :

- faire l'acquisition des tensions sur mes pins RA<0:3>
- faire la conversion analogique/numérique
- faire la différence entre la valeur à t et celle à t-1
- si elles diffèrent envoyer la nouvelle valeur dans TXREG et mettre à jour le registre t-1
- + acquisitions des boutons poussoir qui sont aussi multiplexés, et activation des leds pour les boutons poussoirs enclenchés (on verra ça plus tard !! )

Ça veut donc dire qu'a tout moment je vais avoir besoin de 32 registres dans lesquels il y aura la valeur de mes potars à t-1 ??
Est-ce que mon raisonnement est bon ?

[Jack]

je mettrais une sortie du pic par multiplexeur afin d'éviter d'ajouter des circuits logiques supplémentaires.

Ça veut donc dire qu'a tout moment je vais avoir besoin de 32 registres dans lesquels il y aura la valeur de mes potars à t-1 ??

Pourquoi des registres. Stocke-les en RAM dans un tableau par exemple.

A+

[A voir en vidéo sur Futura]

[invite9eed411b]

je mettrais une sortie du pic par multiplexeur afin d'éviter d'ajouter des circuits logiques supplémentaires.

Pourquoi? Ici je n'ai pas besoin de circuit logique supplémentaire si?
Et puis avec trois sorties du PIC je peux "écouter" en même temps 1 entrée sur chaque multiplexeur.
D'aprés le datasheet j'ai :

INPUT STATES

INH ___C B A___“ON” CHANNEL(S)
0 _____0 0 0_______0
0 _____0 0 1_______1
0 _____0 1 0_______2
0 _____0 1 1_______3
0 _____1 0 0_______4
0 _____1 0 1_______5
0 _____1 1 0_______6
0 _____1 1 1_______7
1 _____X X X ______None

Il suffit donc que je relie toutes les entrées A des mux ensembles, les B ensembles ...

Stocke-les en RAM dans un tableau par exemple.

A bé oui !

Merci en tous cas d'aider un bon gros naze dans mon genre!

[Qristoff]

Bonsoir,
Il existe aussi la solution d'utiliser des ADC déportés comme l'AD7490 avec 16 entrées et liaison SPI avec ton PIC.
http://www.analog.com/en/analog-to-d...s/product.html
A+

[Jack]

Pourquoi? Ici je n'ai pas besoin de circuit logique supplémentaire si?

Non, tu as raison.

[Jack]

Bonsoir,
Il existe aussi la solution d'utiliser des ADC déportés comme l'AD7490 avec 16 entrées et liaison SPI avec ton PIC.
http://www.analog.com/en/analog-to-d...s/product.html
A+

L'idée est bonne, mais il va falloir faire gaffe aux boitiers si Bertrand31000 doit réaliser la gravure de la carte. Il faut être hyper soigneux pour graver et souder un boitier TSSOP.

A+

[Qristoff]

Evidemment ! mais les gens ne disent jamais si c'est pour une appli pro, une appli sérieuse ou une appli "coin de table"... alors !
J'espère qu'en école, on les forme aux nouvelles techno de report, sinon ils vont pas être déçu du voyage !
quels sont tes moyens Bertrand ?

[invite9eed411b]

Bonsoir,
Il existe aussi la solution d'utiliser des ADC déportés comme l'AD7490 avec 16 entrées et liaison SPI avec ton PIC.
http://www.analog.com/en/analog-to-d...s/product.html
A+

L'idée est bonne, mais il va falloir faire gaffe aux boitiers si Bertrand31000 doit réaliser la gravure de la carte. Il faut être hyper soigneux pour graver et souder un boitier TSSOP.

A+

A oui effectivement ça à l'air bien comme composant, je connaissais pas du tout! Mais comme l'a dit Jack ça risque d'être compliqué lors de la soudure !

Sinon j'aimerai revenir sur le programme. Je me suis posé la question des interruptions. Je me demande si je dois en prendre compte ou si la boucle principale sera assez rapide pour ne pas fournir en sortie une latence trop "gênante" (env 30ms) ?

Par exemple, si j'envoie sur ABC => 000, càd que j'envoie sur RA<0:3> les 4 tensions des entrées 1 des mux, que je fais mes instructions citées plus haut, et qu'au même moment, je bouge un potentiomètre sur l'entrée 8 d'un des mux, peut-on avoir une petite idée du temps nécessaire pour traiter ce changement de valeur?

Le schéma préconise une quartz à 10Mhz, soit si je me trompe pas, 2.500.000 instructions par seconde. Ça m'a l'air plus que raisonnable non ?

[invite9eed411b]

Evidemment ! mais les gens ne disent jamais si c'est pour une appli pro, une appli sérieuse ou une appli "coin de table"... alors !
J'espère qu'en école, on les forme aux nouvelles techno de report, sinon ils vont pas être déçu du voyage !
quels sont tes moyens Bertrand ?

Disons que comme c'est un sujet qui ne nous était pas imposé, que nous ne sommes pas en collaboration avec une entreprise, je dirais que c'est une "appli sérieuse".
En effet, il faudra à la fin du projet, rendre un produit "fini", fonctionnel, répondant au CDC, que l'on rédigera bien évidement quand le produit sera fini, histoire de respecter tous les points

Non plus sérieusement, il faut quand même faire preuve d'une certain aspect professionnel, et d'une mise en application des connaissances acquises. De là à faire une carte de jeune génération, je n'irai pas jusque là! Il faut bien sûr prendre en compte l'encombrement du boitier mais ce n'est pas primordial!

Pour ce qui est du budget, l'école finance l'achat des composants, et me permet de fabriquer les pcb. Pour ce qui est du boitier en lui-même (gravure face avant + carter +¨alim ) c'est moi qui finance. Comme je souhaite conserver le contrôleur, disons que c'est une opération plus qu'avantageuse !

[Jack]

Le schéma préconise une quartz à 10Mhz, soit si je me trompe pas, 2.500.000 instructions par seconde. Ça m'a l'air plus que raisonnable non ?

Vu que le pic est un processeur RISC, 2 500 000 instructions/s n'est pas forcément plus rapide qu'un CISC qui tourne à 1 000 000 instructions/s.

Mais, vu ton appli, le 18F devrait faire l'affaire. Il faudrait aussi faire une estimation des ressources mémoire pour voir si elles seront suffisantes.

Sinon j'aimerai revenir sur le programme. Je me suis posé la question des interruptions. Je me demande si je dois en prendre compte ou si la boucle principale sera assez rapide pour ne pas fournir en sortie une latence trop "gênante" (env 30ms) ?

Contrairement à ce qu'on pourrait croire au premier abord, travailler avec des interruptions facilite le travail en rendant les différentes tâches plus faciles à maintenir et à développer car relativement indépendantes. L'idéal serait que l'OS avec lequel tu comptes travailler soit temps réel et te permette de gérer tes tâches.

A+

[invite9eed411b]

Contrairement à ce qu'on pourrait croire au premier abord, travailler avec des interruptions facilite le travail en rendant les différentes tâches plus faciles à maintenir et à développer car relativement indépendantes. L'idéal serait que l'OS avec lequel tu comptes travailler soit temps réel et te permette de gérer tes tâches.

Je suis pas sûr de voir comment ça va marcher dans mon cas (peut être parce que je n'ai pas encore tout compris sur les interruptions ... )
Comment je vais détecter le mouvement d'un potar sans looper sur les combinaisons ABC et vérifier que la valeur à l'instant t est différente que celle à t-1 ?

Que deviendrait alors mon main? Un programme qui n'attend que les interruptions ?

Et encore une question à propos de la programmation: comment on fait pour compiler du C sous MPLAB 8 ?

[Jack]

Que deviendrait alors mon main? Un programme qui n'attend que les interruptions ?

oui.

Comment je vais détecter le mouvement d'un potar sans looper sur les combinaisons ABC et vérifier que la valeur à l'instant t est différente que celle à t-1 ?

Il faut lancer un timer qui va générer une interruption toutes les x ms.

Et encore une question à propos de la programmation: comment on fait pour compiler du C sous MPLAB 8 ?

Je ne suis pas très compétant en cicuits microchip, mais je pense que l'installation d'un compilateur va l'intégrer à mplab. Reste à choisir ton compilateur.

A+

[invite9eed411b]

Il faut lancer un timer qui va générer une interruption toutes les x ms.

J'ai du mal à saisir là ....

Qu'est sensée faire cette interruption dans mon cas?

[Jack]

J'ai du mal à saisir là ....

Qu'est sensée faire cette interruption dans mon cas?

Eh bien tu parles de scruter tes entrées périodiquement. Tu programmes un des timers du pic pour générer une interruption toutes les x ms, avec x = période de scrutation. Quel que soit ce que faisait le pic, il partira en interruption (c'est le principe des interruptions).
Il te reste à écrire ce programme d'interruption.

A+

[Qristoff]

Salut à tous,
je pense que le programme principal doit être uniquement consacré au codage permanent des entrées analogiques en boucle et que les interruptions doivent être reservées aux inters.
La boucle du programme principal sur les 4 entrées ADC venant des MUX et en cas d'action sur un inter, hop, on saute à l'interruption sur changement d'une entrée de pic. ça me parait plus logique par rapport au besoin du post #3

[invite9eed411b]

Salut à tous,
je pense que le programme principal doit être uniquement consacré au codage permanent des entrées analogiques en boucle et que les interruptions doivent être reservées aux inters.
La boucle du programme principal sur les 4 entrées ADC venant des MUX et en cas d'action sur un inter, hop, on saute à l'interruption sur changement d'une entrée de pic. ça me parait plus logique par rapport au besoin du post #3

Ok trés bien!
Par contre il faut que je respecte le montage préconisé sur le site pour plus tard pouvoir installer le vrai programme en téléchargement sur le site.

J'ai fait rapidement un petit PDF montrant les entrées utilisées.
ICI

L'entrée du PIC utilisée pour les boutons peut-elle faire l'objet d'une source d'interruption ?

[invite9eed411b]

Re !

Je viens de passer la journée sur le projet et j'ai un peu avancé!
Donc j'ai créé un fichier port.h

//
// Configuration des ports
//

#ifndef PORT_H
#define PORT_H
#include <p18f452.h>

// --------------------------------  //


#define AMUX1 PORTAbits.RA0   // Déclaration de la partie Analogique //
#define AMUX2 PORTAbits.RA1
#define AMUX3 PORTAbits.RA2
#define AMUX4 PORTAbits.RA3
#define AMUX5 PORTAbits.RA5
#define AMUX6 PORTEbits.RE0
#define AMUX7 PORTEbits.RE1
#define AMUX8 PORTEbits.RE2

#define AMUXA PORTCbits.RC0  // Déclaration des pins de pilotage des MUX //
#define AMUXB PORTCbits.RC1
#define AMUXC PORTCbits.RC3

#define NUMREG PORTDbits.RD1  // Déclaration de la partie Boutons Poussoir //
#define NUMCLK PORTDbits.RD3
#define NUMLD PORTDbits.RD2

#define LEDREG PORTDbits.RD0  // Déclaration de la partie LED //
#define LEDSCLK PORTDbits.RD3
#define LEDRCLK PORTDbits.RD2

// ----------------------------------- //

#define TRISACONF 0xFF // tout en input
#define TRISBCONF 0xFF // PortB non utilisé
#define TRISCCONF 0xF4 // 1111 0100 RC0,1,3 en output
#define TRISDCONF 0xF3 // 1111 0011 RD1,0 en input , RD2,3 en output
#define TRISECONF 0xFF // tout en input

#endif

Un fichier d'initialisation init.h

 //=============== INITIALISATION DES PORTS I/O ===============//

#include <port.h>
#include <p18f452.h>

void 
init(void)
{
	
 	PORTA = 0;        // Sorties portA a 0
 	PORTB = 0;        // sorties portB a 0
 	PORTC &= 0xC0;
 	PORTD = 0;        // sorties portD a 0
 	PORTE = 0;        // sorties portE a 0
 
 	ADCON0 = 0x45;       // 
 	ADCON1 = 0x80;       //

 	TRISA = TRISACONF;      // '1' entree ; '0' sortie
 	TRISB = TRISBCONF;     // '1' entree ; '0' sortie
 	TRISC = TRISCCONF;      // '1' entree ; '0' sortie
 	TRISD = TRISDCONF;      // '1' entree ; '0' sortie
 	TRISE = TRISECONF;}

Ensuite un début de fichier pour la conversion analogique can.h

// CAN //

#include <port.h>
#include <p18f452.h>
#include <stdio.h>

void can(void)

{	ADCON0=0x45; // CAN sur AN0 (RA0)

// ranger résultat conversion tableau //
// comparer avec valeur précédente //
// si != envoyer via USART //

	ADCON0=0x4D; // CAN sur AN1 (RA1)

// ranger résultat conversion tableau //
// comparer avec valeur précédente //
// si != envoyer via USART //

	ADCON0=0x55; // CAN sur AN2 (RA2)

// ranger résultat conversion tableau //
// comparer avec valeur précédente //
// si != envoyer via USART //

	ADCON0=0x5D; // CAN sur AN3 (RA3)

// ranger résultat conversion tableau //
// comparer avec valeur précédente //
// si != envoyer via USART //

	ADCON0=0x65; // CAN sur AN4 (RA5)

// ranger résultat conversion tableau //
// comparer avec valeur précédente //
// si != envoyer via USART //

	ADCON0=0x6D; // CAN sur AN5 (RE0)

// ranger résultat conversion tableau //
// comparer avec valeur précédente //
// si != envoyer via USART //

	ADCON0=0x75; // CAN sur AN6 (RE1)

// ranger résultat conversion tableau //
// comparer avec valeur précédente //
// si != envoyer via USART //

	ADCON0=0x7D;} // CAN sur AN7 (RE2)

// ranger résultat conversion tableau //
// comparer avec valeur précédente //
// si != envoyer via USART //

// ranger résultat conversion tableau //

et le début du main.c

//============= MBOX ===================//

#include <port.h>

#include <p18f452.h>
#include <stdio.h>
#include <can.h>
#include <init.h>


void main(void)
{

init(); // On initialise les registres avec les valeurs ci-desssus et celles dans port.h

while(1)
{
    AMUXA=0; // Entrée 1 des mux
	AMUXB=0;
	AMUXC=0;

can(); // Conversion analogique 

	AMUXA=1; // Entrée 2 des mux
	AMUXB=0;
	AMUXC=0;

can();

	AMUXA=0; // Entrée 3 des mux
	AMUXB=1;
	AMUXC=0;

can();

	AMUXA=1; // Entrée 4 des mux
	AMUXB=1;
	AMUXC=0;

can();

	AMUXA=0; // Entrée 5 des mux
	AMUXB=0;
	AMUXC=1;

can();

	AMUXA=1; // Entrée 6 des mux
	AMUXB=0;
	AMUXC=1;

can();

	AMUXA=0; // Entrée 7 des mux
	AMUXB=1;
	AMUXC=1;

can();

	AMUXA=1; // Entrée 8 des mux
	AMUXB=1;
	AMUXC=1;

}


}

1) Ce que j'aimerai tester maintenant, c'est la présence d'une tension comprise entre 0 et 5v sur les pins AN<7:0> pour voir si la CAN fonctionne.

Savez-vous comment simuler ceci sous MPLAB ?

[invite9eed411b]

Bonjour à tous!

Voilà, j'avance petit à petit dans la programmation du PIC et je rencontre un petit problème qui va me rendre chauve à force de me gratter la tête !

#include <port.h>
#include <p18f452.h>
#include <stdio.h>
#include <adc.h>
#include <can.h>
#include <stdlib.h>
#include <delays.h>

// On initialise les registres avec les valeurs ci-desssus et celles dans port.h


void main(void)
{
	PORTA = 0;        // Sorties portA a 0
 	PORTB = 0;        // sorties portB a 0
 	PORTC &= 0xC0;
 	PORTD = 0;        // sorties portD a 0
 	PORTE = 0;        // sorties portE a 0
    

	//ADCON1 = 0x80;
 	//ADCON0 = 0x40;      
 
 	
 	TRISA = TRISACONF;      // '1' entree ; '0' sortie
 	TRISB = TRISBCONF;     // '1' entree ; '0' sortie
 	TRISC = TRISCCONF;      // '1' entree ; '0' sortie

	TRISD = TRISDCONF;      // '1' entree ; '0' sortie
 	TRISE = TRISECONF;

boucle();

// interruption des boutons poussoirs //
}

void boucle(void)
{
while(1)
{
    AMUXA=0; // Entrée 1 des mux
	AMUXB=0;
	AMUXC=0;

can0(); // Conversion analogique 


	AMUXA=1; // Entrée 2 des mux
	AMUXB=0;
	AMUXC=0;

can1();

	AMUXA=0; // Entrée 3 des mux
	AMUXB=1;
	AMUXC=0;

can2();

	AMUXA=1; // Entrée 4 des mux
	AMUXB=1;
	AMUXC=0;

can3();

	AMUXA=0; // Entrée 5 des mux
	AMUXB=0;
	AMUXC=1;

can4();

	AMUXA=1; // Entrée 6 des mux
	AMUXB=0;
	AMUXC=1;

can5();

	AMUXA=0; // Entrée 7 des mux
	AMUXB=1;
	AMUXC=1;

can6();

	AMUXA=1; // Entrée 8 des mux
	AMUXB=1;
	AMUXC=1;

can7();}
}

Donc voilà, pour moi ça a l'air correct, mais lorsque je compile, j'ai ce message d'erreur :

MPLAB C18 v3.30 (evaluation)
Copyright 2000-2009 Microchip Technology Inc.
Days remaining until evaluation becomes feature limited:  46
C:\Mbox\main.c:17:Error: syntax error
----------------------------------------------------------------------
Debug build of project `C:\Mbox\Mbox.mcp' failed.
Preprocessor symbol `__DEBUG' is defined.
Thu Mar 26 23:30:52 2009
----------------------------------------------------------------------
BUILD FAILED

Je vois pas le problème de syntaxe au niveau de main !!!!

S'il vous plait, aidez moi !