Réalisation d'une carte basée sur un PIC32MX

[schneiderj]

Humm... j'ai raconté une connerie cet après midi ! Il est logique que la résistance aux bornes des résistances de 49.9 ohms soit faible puisqu'elle sont en parallèle avec la partie magnétique du RJ45 !
Donc mon problème n'est pas là...
-----

[invitef9ccb542]

Bonjour,

Si les led de la partie ethernet s'allume c'est que la liaison entre le dp et le rj45 est bonne, surtout s'il y a la diode Link et la diode 100M.
Il faut chercher sur le logiciel:
- d'abord voir si la partie initialisation du dp se passe bien avec un breakpoint en surveillant à l'oscillo la liaison sérielle MDIO/MDC entre le pic et le dp.
- ensuite regarder si les signaux TX/RX sont actifs

[schneiderj]

Bonjour et merci pour ton aide !

Si les led de la partie ethernet s'allume c'est que la liaison entre le dp et le rj45 est bonne, surtout s'il y a la diode Link et la diode 100M.

Les trois LED sont actives, donc c'est déjà cela de fait.

Il faut chercher sur le logiciel:
- d'abord voir si la partie initialisation du dp se passe bien avec un breakpoint en surveillant à l'oscillo la liaison sérielle MDIO/MDC entre le pic et le dp.
- ensuite regarder si les signaux TX/RX sont actifs

Je sens que cela va se gâter : la partie logiciel est plus que conséquente .
A quel endroit faut-il que je mette un breakpoint ?

Pour surveiller les signaux TX/RX, il doit falloir un oscillo dont la gamme de fréquence soit assez importante : celui que j'ai sous la main (le mien vaut 350 € environs et est directement connecté au PC par USB. Il n'est pas sûr qu'il faille l'affaire ! Je peux prendre l'oscillo du boulot, mais je n'ai jamais eu besoin de contrôler des signaux ayant une telle fréquence je ne sais donc pas si cela sera possible. Je vais regarder cela demain.

Jean-Marie

[schneiderj]

- d'abord voir si la partie initialisation du dp se passe bien avec un breakpoint en surveillant à l'oscillo la liaison sérielle MDIO/MDC entre le pic et le dp.

Tu es un dieux ! Probablement un petit dieux au regard de beaucoup, mais pour moi, ce soir, tu es le top des Dieux.

J'ai regardé du côté de MDIO et MDC rien à dire à priori comme cela. Je vais lire le datasheet pour connaitre ce qui est dit à ce sujet. Et là, bingo !!! Je lis qu'il faut une résistance de 1.5 k en pull up et de mémoire il me semble que j'ai une valeur de 33 ohms seulement. Ni de une, ni de deux je refais chauffer le fer à souder, fais sauter cette pauvre résistance qui n'avait rien demandé et en met une belle toute neuve de 1.5 k.

Je branche le circuit, et je constate que les LED du switch s'énervent pas mal. Je tente une connexion avec Firefox... et hop, la page est affiché en un clin d'oeil !

Bon je file me coucher... cela n'est que le début. Mais lorsque le hard fonctionne c'est nettement mieux.

Punaise que j'ai pu apprendre avec cette réalisation.

Encore merci au forum et à son esprit
Jean-Marie

[schneiderj]

Bonjour,

Quelques nouvelles de cette carte et commentaires par rapport à cette réalisation.

Les erreurs vues à ce jour :

1. oublie des résistances pull up de l'I2C
2. les entrées shutdown et enable du MAX211 sont flottantes... à connecter à VSS
3. Beaucoup plus embêtant : le boitier de la mémoire flash n'a pas été correctement dessiné. La patte 5 est face à la patte 1...

Les améliorations possibles :

• Ajouter des points pour fixer les sondes de l'oscilloscope ou de l'analyseur logique sur l'I2C, SPI, RS232...

Autrement ce circuit me donne entièrement satisfaction. Durant mes congés et entre deux randonnées et un apéro j'ai commencé à bricolé avec la partie Ethernet et l'exemple de Microchip. Ce n'est pas vraiment très simple, pas mal d fichiers à modifier sans avoir beaucoup d'explication, mais avec l'aide de la documentation et du forum de Microchip j'ai réussi à m'en sortir tant bien que mal... mais en me passant de la mémoire flash pour les raisons données un peu plus haut.
Les bases étant maintenant acquise, il me reste à développer l’application à proprement parlé. A titre d’exemple voici une capture d'écran de Mozilla : je récupère les données d'un ADS1100 que j'affiche sous deux format dans le navigateur : en texte pour la valeur actuelle et graphique pour avoir une visualisation de l'évolution de cette donnée.



Bon il me reste beaucoup à faire car je ne connais pas javascript, alors pour ce qui est des librairies basées sur ce dernier...
Et la stack Ethernet, comment dire ? C'est énorme et dès qu'une RTC Microchip sera à l'ordre du jour, je vais m'inscrire afin d'éclairer mes lanternes !

Jean-Marie

[schneiderj]

Bonsoir,

je n'ai pas de bole... une RTC concernant la pile tcpip est organisée dans 2 semaines... juste lorsque je dois aller à Madrid pour un salon .

Ce qui fait que j'avance, mais à petit pas.
Mon problème du moment : je récupère les données de mon application sur le navigateur internet et pour l'instant je stocke les données sur l'EEPROM de512 K, puis par RS232 je les transfert vers le PC.
Mais j'aimerais me passer de la connection RS232... maintenant que j'ai la partie éthernet qui fonctionne.
J'ai regardé du côté de javascript pour stocker les données localement, soit dans un fichier texte, soit dans une base de données. Mais cela n'a pas l'air de le faire...

Et que pensez-vous de l'utilisation du serveur ftp ? Est-il utilisable pour récupérer les données de l'EEPROM ?
Ou peut être une autre solution ?

Jean-Marie

[invitef9ccb542]

Bonsoir,

Le serveur ftp est une façon simple d'échanger des fichiers, à condition d'avoir un système de fichier du coté du PIC32, ce dont je ne suis pas sûr.

L'autre alternative est de faire un serveur TCP, mais il faut accepter de faire un peu d'informatique:
- définir un protocole d'échange.
- un serveur sur le pic32.
- un client sur le PC qui récupère les données.

J'avais donné deux-trois explications dans ce topic:
http://forums.futura-sciences.com/el...-fichiers.html

[RISC]

Salut Schneider,

Je pense que tu trouveras un client FTP pour la stack TCP/IP Microchip ici.

a+

[schneiderj]

Merci pour vos réponses !

Salut Schneider,

Je pense que tu trouveras un client FTP pour la stack TCP/IP Microchip ici.

a+

RISC je n'en suis pas encore tout à fait certain, mais j'ai belle et bien l'impression que pour le FTP il faut un système de fichier en FAT16.
Dans ce cas je ne vais pas pouvoir faire avec.

Mais je retiens l'idée du client FTP au lieu du serveur : je voyais un système inverse, serveur géré par le PIC et client sur le PC.
En attendant d'avoir un système qui puisse héberger un système de fichier, je vais étudier de près la solution proposée par jlcms.

Jean-Marie

[RISC]

Salut,

Coté file system il y a aussi des solutions ;=)
Dans les librairies Microchip il y a des librairies FAT16/FAT32.
Il y a d'ailleurs un projet qui montre comment avoir un webserveur dont les pages HTML se trouvent sur une carte SD ou même sur une clé USB.
Sinon tu peux aussi utiliser les librairies open source FatFS qui ont été portées sur le PIC32.

a+

[schneiderj]

Bonjour,

j'ai laissé de côté l'idée du ftp (serveur ou client). Je vais utiliser le serveur TCP : j'ai testé le principe (enfin le principe du serveur entre mes mains ), j'arrive à faire communiquer mon client avec le serveur.

Mais pour l'instant tout n'est pas rose : je n'arrive à envoyer depuis le serveur que des petites trames de 20 bytes. Et selon ce que j'ai compris il doit être possible d'envoyer jusqu'à plus de 1500 bytes... je suis loin du compte.

Ce paramétre est défini ici (TCPIP ETH795.h) :

		#define TCP_CONFIGURATION
		ROM struct
		{
			BYTE vSocketPurpose;
			BYTE vMemoryMedium;
			WORD wTXBufferSize;
			WORD wRXBufferSize;
		} TCPSocketInitializer[] = 
		{
			//{TCP_PURPOSE_GENERIC_TCP_CLIENT, TCP_PIC_RAM, 125, 1200},
			{TCP_PURPOSE_GENERIC_TCP_SERVER, TCP_PIC_RAM, 20, 20},
			{TCP_PURPOSE_TELNET, TCP_PIC_RAM, 200, 150},
			//{TCP_PURPOSE_TELNET, TCP_PIC_RAM, 200, 150},

par cette ligne : {TCP_PURPOSE_GENERIC_TCP_SERVE R, TCP_PIC_RAM, 20, 20}.

Mais si j'augmente la valeur de wTXBufferSize à 1500 par exemple l'application plante lorsque je fais appel au serveur. En utilisant une valeur plus faible comme 30, cela fonctionne... mais je n'ai que 20 caractères de transmis...

pourriez-vous m'indiquer la démarche à suivre pour modifier la taille de ce buffer ?

Merci
Jena-Marie

[RISC]

Salut,

Si tu repars sur le principe d'une connection TCP, je te recommande de partir du projet de test du débit TCP ou UDP qui se trouve dans les librairies MLA : http://www.microchip.com/MLA.
Après installation tu as toute la description du projet dans ce document :
c:\Microchip Solutions v2012-10-15\Microchip\Help\TCPIP Stack Help.chm
Tu cherches dans release notes, Stack Performance.
Ce projet permet de mesurer la performance TCP en fonction de la taille FIFO.

a+

[schneiderj]

Salut,

Si tu repars sur le principe d'une connection TCP, je te recommande de partir du projet de test du débit TCP ou UDP qui se trouve dans les librairies MLA : http://www.microchip.com/MLA.
Après installation tu as toute la description du projet dans ce document :
c:\Microchip Solutions v2012-10-15\Microchip\Help\TCPIP Stack Help.chm
Tu cherches dans release notes, Stack Performance.
Ce projet permet de mesurer la performance TCP en fonction de la taille FIFO.

a+

Merci !

ceci m'a permis de comprendre un certain nombre de point et de créer mon propre module (enfin créer est un bien grand mot ), en reprenant un mixte entre les deux modules TCPPerformanceTest et GenericTCPServer. Cela marche bien, mais j'ai tout de même quelques questions :

Dans ce code :

	// Transmit as much data as the TX FIFO will allow
	while(w >= 12+27+5+32u)
	{
...
		// Place all data in the TCP TX FIFO
		TCPPutArray(MySocket, vBuffer, sizeof(vBuffer));
		TCPPutROMString(MySocket, (ROM BYTE*)": We are currently achieving ");
		TCPPutROMArray(MySocket, (ROM BYTE*)"       ", 5-strlen((char*)vBytesPerSecond));
		TCPPutString(MySocket, vBytesPerSecond);
		TCPPutROMString(MySocket, (ROM BYTE*)"00 bytes/second TX throughput.\r\n");

		w -= 12+27+5+32;
		dwBytesSent += 12+27+5+32;
	}

pourquoi w -= 12+27+5+32; ? Car je compte pour :

• TCPPutArray(MySocket, vBuffer, sizeof(vBuffer)) : 10 bytes
• TCPPutROMString(MySocket, (ROM BYTE*)": We are currently achieving ") : 29 bytes
• TCPPutROMArray(MySocket, (ROM BYTE*)" ", 5-strlen((char*)vBytesPerSecond) ) : 7 bytes
• TCPPutString(MySocket, vBytesPerSecond) : 0 bytes (compté ci-dessus)
• TCPPutROMString(MySocket, (ROM BYTE*)"00 bytes/second TX throughput.\r\n") : 32 bytes

Ce qui donne 10+29+7+32 bytes. Alors pourquoi 12+27+5+32 ?

Voici pour la premiére question. La suite un peu plus tard !

Jean-Marie

[schneiderj]

Bonsoir,

bon j'avance.Enfin j'avançais... car avec mon module je transfert bien mes données (pour l'instant des valeurs allant de 1 à 15000 codées sur 2 bytes). Mais il y a un "trou" de temps en temps (mais toujours au même endroit).
Voici un extrait d'un fichier excel :


et le code utilisé :

            if (NombreBytesEnvoye < NombreBytesATranferrer)
            {
                if((NombreBytesEnvoye + Increment) > NombreBytesATranferrer)
                {
                    Increment = NombreBytesATranferrer - NombreBytesEnvoye;
                }
                
                while (wMaxPut >= NBRE_DATA_TX_BUFFER)
                {
                    if (j >= Increment )
                    {
                        DonneI2C[0] = EEPROM_ADDRESS;
                        DonneI2C[1] = AdresseActuelle_H;
                        DonneI2C[2] = AdresseActuelle_L;
                        EepromRead(DonneI2C, Increment);

                        if (AdresseActuelle_L > (UINT8) (AdresseActuelle_L + Increment))
                            AdresseActuelle_H++;
                        AdresseActuelle_L += Increment;

                        j = 0;
                        jOld = 0;
                    }
                    else
                        jOld = j;
                    
                    while (j < Increment)
                    {
                        for (i = 0; i <NBRE_DATA_TX_BUFFER; i++)
                        {
                            AppBuffer[i] = DonneI2C[j];
                            j++;
                        }
                        // Place all data in the TCP TX FIFO
                        TCPPutArray(MySocket, AppBuffer, sizeof (AppBuffer));
                        if( wMaxPut > NBRE_DATA_TX_BUFFER)
                        {
                            wMaxPut -= NBRE_DATA_TX_BUFFER;
                        }
                        else
                        {
                            NombreBytesEnvoye += j - jOld;
                            return;
                        }
                    }
                    NombreBytesEnvoye += j - jOld;
                }
            }
            else
            {
                // Close the socket connection.
                TCPClose(MySocket);
                TCPServerState = SM_HOME;
                return;
            }
            // No need to perform any flush.  TCP data in TX FIFO will automatically transmit itself after it accumulates for a while.  If you want to decrease latency (at the expense of wasting network bandwidth on TCP overhead), perform and explicit flush via the TCPFlush() API.

            break;

En suivant l’exécution de ce code à partir de TCPPutArray et lorsque les valeurs transférées vont de 995 à 999 (avec un Buffer pour Tx de 2000 et Tr de 20), AppBuffer contient bien les bytes voulues, mais seul arrive sur le client (confirmé par Wireshack) des valeurs égales à 0.

Si je récupère le flux envoyer par le module TCPPerformance, je constate qu'aucun phénomène de ce type n'apparait...

J'ai donc une con... dans mon code. Je me bagarre avec depuis hier, mais rien à faire : je ne trouve pas.
Pourriez-vous (enfin je pense à RISC...) me dire qu'elles sont les éléments à maitriser pour arriver à faire fonctionner ce serveur ?

Merci pour votre aide
Jean-Marie

[RISC]

Salut,

La seule chose qui me vienne à l'esprit c'est que ta trame prend trop de temps à être formée et que la stack "loupe" des infos car elle est "bloquée" trop longtemps.
Essaye de mesurer le temps que tu passe dans ta routine en utilisant le stopwatch de MPLAB X avec ton ICD3 ou ton real-Ice.
Compare au projet TCPperformance pour voir si les temps sont du même ordre de grandeur.

a+

[invitef9ccb542]

Bonjour,

Pour moi il est inconcevable, d'avoir dans une même suite d'instruction l'accès à l'eeprom et la communication réseau, comme le dit RISC, il y a un risque (désolé), que cette opération prenne trop de temps.
"Normalement" on doit avoir les données à transmettre dans un buffer, avec une routine qui va les lire dans ce buffer et les envoyer sur le réseau. Cette routine doit être déclenchée par une interruption, elle même déclenchée par un état "ready to send".

Il y a un autre truc qui me chagrine c'est que tu ne récupère pas le retour de la fonction TCPPutArray. Normalement c'est suivant le nombre transmis que l'on sait si l'on doit renvoyer le complément.

[schneiderj]

Encore une fois merci à vous deux !

Salut,

La seule chose qui me vienne à l'esprit c'est que ta trame prend trop de temps à être formée et que la stack "loupe" des infos car elle est "bloquée" trop longtemps.
Essaye de mesurer le temps que tu passe dans ta routine en utilisant le stopwatch de MPLAB X avec ton ICD3 ou ton real-Ice.
Compare au projet TCPperformance pour voir si les temps sont du même ordre de grandeur.

a+

C'est effectivement le problème de mon code : en remplaçant l'appel à la fonction I2C par une simple boucle tout fonctionne comme attendu.
Uniquement le fait de lire 1000 bytes au lieu de 200 à chaque appel des données, ou modifier la fréquence de l'I2C de 100 à 400 kHz améliore la situation. Mais améliore seulement... cela ne traite pas la cause !

Bonjour,

Pour moi il est inconcevable, d'avoir dans une même suite d'instruction l'accès à l'eeprom et la communication réseau, comme le dit RISC, il y a un risque (désolé), que cette opération prenne trop de temps.
"Normalement" on doit avoir les données à transmettre dans un buffer, avec une routine qui va les lire dans ce buffer et les envoyer sur le réseau. Cette routine doit être déclenchée par une interruption, elle même déclenchée par un état "ready to send".

Il y a un autre truc qui me chagrine c'est que tu ne récupère pas le retour de la fonction TCPPutArray. Normalement c'est suivant le nombre transmis que l'on sait si l'on doit renvoyer le complément.

Si je pose des questions sur le forum c'est que je sais que ce que je suis en train de bricoler ne va pas. Je viens donc discuter pour résoudre mes problèmes, mais aussi pour apprendre. Et comme vos réponses sont pertinentes et qu'elles (me, mais je pense qu'elles peuvent être utilent à d'autres personnes) permettent d'avancer, je ne vois pas pourquoi tu te sens désolé ou chagriné ! Appelons un chat, un chat .

Je retourne à mon code, enfin un peu plus tard, car pour l'instant j'ai une ribambelle de souche de thuya qui m'appellent... ce n'est pas drôle, mais il faut le faire !
Je reviens un peu plus tard avec un début de réflexion et probablement quelques nouvelles questions.

Jean-Marie

[invitef9ccb542]

Si je pose des questions sur le forum c'est que je sais que ce que je suis en train de bricoler ne va pas. Je viens donc discuter pour résoudre mes problèmes, mais aussi pour apprendre. Et comme vos réponses sont pertinentes et qu'elles (me, mais je pense qu'elles peuvent être utilent à d'autres personnes) permettent d'avancer, je ne vois pas pourquoi tu te sens désolé ou chagriné ! Appelons un chat, un chat .
Jean-Marie

tu as raison, j'étais mal réveillé. quoi qu'il en soit teste le retour de la fonction TCPPutArray, tu verra que tu envoie moins de données que tu crois. Laisse tomber les aspects "interruption" et "multithread".

[schneiderj]

tu as raison, j'étais mal réveillé. quoi qu'il en soit teste le retour de la fonction TCPPutArray, tu verra que tu envoie moins de données que tu crois. Laisse tomber les aspects "interruption" et "multithread".

Mais non, pas mal réveillé, juste un peu agacé , cela m'arrive également !

J'ai essayé d'écrire sur le schéma suivant ce que je pense faire : mais attention je n'ai pas pris en compte les tous les contrôles qui devront être mis en place. C'est uniquement un schéma de principe par rapport au transfert de données.

[

Qu'en pensez-vous ?

Jean-Marie

[schneiderj]

Bonjour,

je viens de faire une simple modification à mon code (http://forums.futura-sciences.com/el...ml#post4251757), en remplaçant le premier while par un if.
Les résultats sont impeccables !

Mais je ne tiens pas compte du nombre de bytes effectivement envoyer : il faut que je le mette en place.

Jean-Marie

[RISC]

Salut,

La règle très importante pour la stack TCP/IP : ne jamais faire de code "bloquant" (tester une conditon avec IF mais jamais boucler avec while pour éviter de bloquer la stack).
C'est la technique "Round-Robin". Si l'évènement n'est pas arrivé on attend l'itération suivante.
Si tu as besoin de délais dans ton appli, il faut utiliser les types TICK (TICK_SECONDE, TICK_MINUTE,TICK_HOUR) et les fonctions pour retrouver le temps (TICK TickGet() , TICK TickGetDiv256() , TICK TickGetDiv64K() ). Voir la documentation pour les détails

TICK doneAt = TickGet() + TICK_SECOND/10;

case SM_WAIT:
if((LONG)(TickGet() – doneAt) > 0)
    // Perform timeout function after 100ms...

a+

[schneiderj]

Bonsoir,

cela fait un moment que je n'ai pas posté à propos de ce sujet. L'ossature du projet est terminée et toutes les fonctions prisent séparément fonctionnent :

• la lecture des deux ADC par I2C
• la commande des "périphériques" par RS232 (cryostat, polarimètre et pompe)
• La commande des électrovannes
• l'enregistrement des données sur l'EEPROM (en I2C)
• la communication par http pour contrôler le fonctionnement de l'application
• la récupération de données par TCP

J'en suis à plus de 4000 lignes de code et cela commence à être le bazar lorsque l'ensemble des périphériques fonctionnent et que j'ai un bug dans le code... le coupable peut être difficile à dénicher !

Et justement j'ai un souci avec la lecture des données en provenance du polarimètre, problème que je n'avais pas lorsque le code était non bloquant.
Toutes les 250 milli secondes la fonction suivant est appelée :

UINT8 MesurerRotation(char cBuffer[])
{
    static DWORD startTime;
    //UINT8 static StatusInitialisation = 0;
    static UINT8 ReceptionData = 0; // ce controle va permettre d'executer cetyaine partie du code incluse dans un switch case en 2 ou 3 fois,
    // Comme par exemple envoi de donn?e par RS232, puis r?ception de ces donn?es

    char Commande[20] = "";
    char Reponse[20];
    char* ReponseValide1 = "";
    UINT8 Negatif = 0;
    UINT8 MessageSize = 0;

    // initialisation de la connexion par envoi de la commande status
    if (ReceptionData == 0)
    {
        strcpy(Commande, "GET RESULT");
        SendDataBuffer(Commande, Polarimetre.id);
        ReceptionData = 1; // nous passons � la r�ception des donn�es
        startTime = TickGet();
    }
    else if (ReceptionData == 1)
    {
        if (UARTReceivedDataIsAvailable(Polarimetre.id))
        {
            MessageSize = 2;
            GetDataBuffer(Reponse, MessageSize, Polarimetre.id);
            ReponseValide1 = strstr(Reponse, "OK");

            if (ReponseValide1 != NULL)
            {
                Negatif = 1;
		ReceptionData = 0;
                cBuffer = Reponse;
            }
            else
            {
                Negatif = 0;
            }
        }//Delayms(5000);
        else if ((LONG) (TickGet() - startTime) > TICK_SECOND * 5) {
            ReceptionData = 0;
            NouvelleAction = 0;
            Negatif = 0;
            startTime = TickGet(); // Nous devons attendre 2 secondes avant l'op�ration suivante
        }
    }
    // delay_s(1);
    return Negatif;
}

Lors du premier passage dans cette fonction, une demande est faite au polarimetre pour qu'il envoi la valeur de la mesure. Puis lors des passages suivants nous vérifions si des données sont disponnibles en lecture. Et souvant l'execution du code est bloqué dans la fonction GetDataBuffer(Reponse, MessageSize, Polarimetre.id); que voici :

UINT32 GetDataBuffer(char *buffer, UINT32 max_size, UART_MODULE idModule)
{
    UINT8 character = 0;

    while ((character != 0x0D)) //(num_char < max_size) | 
    {

        while ((!UARTReceivedDataIsAvailable(idModule))); //
        character = UARTGetDataByte(idModule);
        *buffer = character;
        buffer++;

        if ((U1STA & 0b10) == 0b10)
            break;
    }

    *buffer = '\0';

    return 1;
}

car le caractère 0x0D n'est pas reçu : une partie du message a été perdue lors de la réception.

Hormis l'ajout d'un code de contrôle dans la boucle de réception qui permettrait de sortir du "while ((!UARTReceivedDataIsAvailable (idModule))); " je ne vois pas trop ce que je peux faire pour éviter ce problème.
Mais même si je règle ce problème, ceci ne va pas corriger le problème initiale qui semble être que l’exécution du programme est trop tente lorsque le polarimètre commence à émettre son message : une fois le buffer de réception rempli, les dernier bytes sont perdus.
Auriez-vous une idée qui apporterait une solution à ce problème ?

Merci
Jean-Marie

[invite03481543]

Bonsoir,

pourquoi travailles-tu avec un code bloquant?
Tu devrais traiter ce type d'infos en interruption.
Tu gardes ta fonction mais tu l'appelles via l'interruption du buffer de reception, du coup plus besoin de while mais plutot un do-while.

[bobflux]

Il ne faut pas que ça bloque : si tu as du code bloquant, alors il te faudra un OS multitâches style freertos.

Si ton protocole de communication est orienté ligne, comme c'est généralement le cas, le plus simple est d'avoir un buffer de port série capable de contenir une ligne complète, et d'effectuer le traitement quand le caractère de fin de ligne est reçu.

[schneiderj]

Merci pour vos réponses !

Je n'avais pas envisagé cette solution... car depuis le début je fais un blocage avec celles-ci ! Avec les PIC18 je n'avais pas de problème avec la manipulation directe des bits correspondant. Mais avec le C32 et le nombre impressionnant de ceux-ci j'ai fini par abandonner cette stratégie pour utiliser les expressions du C32.

Mais je me perds dans la documentation : par exemple je suis incapable de trouver dans la documentation (aussi bien celle relative au interruption que celle de l'UART) de l'aide pour ConfigIntUART2 !
J'ai finalement trouvé grâce à MPLABX : "go to implementation" ! Mais quel bazar...


Jean-Marie

[RISC]

Salut,

Je n'avais pas envisagé cette solution... car depuis le début je fais un blocage avec celles-ci

Pour la partie webserveur / TCP/IP, une bonne compréhension du fonctionnement de la pile aide beaucoup notamment pour éviter les fonctions blocantes dont j'ai déjà parlé. C'est un des aspects évoqué dans la formation webserveur de Microchip.

Mais avec le C32 et le nombre impressionnant de ceux-ci j'ai fini par abandonner cette stratégie pour utiliser les expressions du C32.

Effectivement, il y a 4 adresses par registres du PIC32...en fonction de l'opération logique à faire (ET, OU, OU exclusif) le compilateur choisit la bonne adresse ;=)

Mais je me perds dans la documentation : par exemple je suis incapable de trouver dans la documentation (aussi bien celle relative au interruption que celle de l'UART) de l'aide pour ConfigIntUART2 !

Quelle documentation utilises-tu ?
Quel compilateur (C32 ou XC32) ?

J'ai finalement trouvé grâce à MPLABX : "go to implementation" ! Mais quel bazar...

La navigation des fonctions, des variables, des fichiers est effectivement beaucoup plus simple dans MPLAB X.

a+

[schneiderj]

Merci RISC pour ta réponse !

Salut,
Pour la partie webserveur / TCP/IP, une bonne compréhension du fonctionnement de la pile aide beaucoup notamment pour éviter les fonctions blocantes dont j'ai déjà parlé. C'est un des aspects évoqué dans la formation webserveur de Microchip.

C'est ce que j'aurai aimé faire depuis début septembre, mais il faut réussir à bloquer une ou deux journée et cela suffisament à l'avance... j'aurais éviter pas mal de soucis lors de la mise en place des fonctions que j'utilise !
Aujourd'hui je souhaite suivre une formation concernant REAL ICE, je pensais le prendre en main avec le temps, mais il n'en est rien, en particulier pour les fonctions que je souhaitais exploitées comme "instructions trace ".

Quelle documentation utilises-tu ?
Quel compilateur (C32 ou XC32) ?

La navigation des fonctions, des variables, des fichiers est effectivement beaucoup plus simple dans MPLAB X.

Depuis la sortie de MPLAB.X V1.5, je n'utilise plus que cet IDE (avant j'avais des problèmes avec REAL ICE) et pour l'édition des fichiers NotePad++.

Comme compilateur j'utilise encore C32 V2.02. Pour la documentation j'utilisais exclusivement la documentation fournie lors de l'installation de C32 (dont les fichier pdf situé dans le répertoire \doc\pic32-lib-help). Mais d'après ce que je viens de lire, il vaut mieux utiliser l'aide de MPLAB.X qui serait plus à jour que tous les autres fichiers fournis. Qu'en penses-tu ?

Jean-Marie

[schneiderj]

Rebonjour,

voici le code que je teste depuis lundi, mais sans succès : je n'ai pas d'entrée dans la fonction qui gère l’interruption de Rx de UART2.

Structure qui défini l'élément RS232 :

#define RX_BUFFER_SIZE 32     // RX buffer size

typedef struct {
    UART_MODULE id;
    UART_LINE_CONTROL_MODE NbreBits;
    UART_LINE_CONTROL_MODE Parity;
    UART_LINE_CONTROL_MODE StopBits;
    UINT32 DataRate;
    UINT8 Initialise;
    UINT8 *Rx_buffer; // RX buffer
    UINT8 *Tx_buffer; // TX buffer
    UINT8 *Rx_Recieved;
    UINT8 *Tx_Recieved;
} RS_232;


// *****************************************************************************
// Section: d�finition des p�rif�rique RS232
// *****************************************************************************
// *****************************************************************************
extern RS_232 PompePeristaltique;
extern RS_232 Polarimetre;
extern RS_232 Julabo;

extern UINT8 UART1_Buffer_Rx[RX_BUFFER_SIZE];
extern UINT8 UART1_NbreBytes_Rx;

L'initialisation des périfériques RS232 est assuré par cette fonction :

void UARTInitialise(RS_232 NomRS232) {
    UARTConfigure(NomRS232.id, UART_ENABLE_PINS_TX_RX_ONLY); // UART_ENABLE_PINS_TX_RX_ONLY
    UARTSetFifoMode(NomRS232.id, UART_INTERRUPT_ON_TX_NOT_FULL | UART_INTERRUPT_ON_RX_NOT_EMPTY);
    UARTSetLineControl(NomRS232.id, NomRS232.NbreBits | NomRS232.Parity | NomRS232.StopBits);
    UARTSetDataRate(NomRS232.id, GetPeripheralClock(), NomRS232.DataRate);
    UARTEnable(NomRS232.id, UART_ENABLE_FLAGS(UART_PERIPHERAL | UART_RX | UART_TX));

    // Configure UART Interrupt
    switch (NomRS232.id) {
        case UART1:
        {}

        case UART2:
        {
            INTEnable(INT_U2RX, INT_ENABLED); // RX Interrupt is enabled
            INTEnable(INT_U2TX, INT_DISABLED); // TX Interrupt is disabled, no need to fire into it now, only when we need to send out somethings!!
            INTSetVectorPriority(NomRS232.id, INT_PRIORITY_LEVEL_2);
            INTSetVectorSubPriority(NomRS232.id, INT_SUB_PRIORITY_LEVEL_0);

            // Set system to manage the multi-vectored mode
            INTConfigureSystem(INT_SYSTEM_CONFIG_MULT_VECTOR);
            // Enable the interrupt handling from the core
            INTEnableInterrupts();
            break;
        }

Dans la fonction main() j'initialise le Timer4 :

    // Configuration du timer1 qui va servir à compter les secondes
    //~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    // using external clock, 1:1 prescale
    OpenTimer4(T4_ON | T4_SOURCE_INT | T4_PS_1_1, 65535);

    // set up the timer interrupt with a priority of 5
    ConfigIntTimer4(T4_INT_ON | T4_INT_PRIOR_5);

    // enable multi-vector interrupts
    INTEnableSystemMultiVectoredInt();
    INTEnableInterrupts();

Ce qui m’amène à un commentaire : INTEnableSystemMultiVectoredIn t provient d'un exemple donnée par miccrochip. Hors je viens de voir que cette fonction est décrite dans fichier nommé xx_legacy. Il est donc préférable que je la remplace par : INTConfigureSystem(INT_SYSTEM_ CONFIG_MULT_VECTOR);
RISC qu'en penses-tu ?


Puis toujours dans la fonction main () l'initialisation de ma RS232 :

    while (1) {

        if (TMR2 > DELAY) {
            LED1 = LED1^1;
            TMR2 = 0;
        }

        if (NouvelleSeconde == 1) {
            NombreSecondes++;
            NouvelleSeconde = 0;

            UARTInitialise(Polarimetre);
        }
    }

    return 0;
}


UINT8 InitialisationPolarimetre(void)
{
    static UINT8 StatusInitialisation = 0;
    static UINT8 ReceptionData; // ce controle va permettre d'executer cetyaine partie du code incluse dans un switch case en 2 ou 3 fois,
    // Comme par exemple envoi de donn?e par RS232, puis r?ception de ces donn?es

    char Commande[30];
    char Reponse[20];
    char* ReponseValide1;

    switch (StatusInitialisation)
    {
        case 0: // Initialisation
        {
            //////////////////////////////////////////////////////////////////////////////
            //////////////////////////////////////////////////////////////////////////////
            // Caract�ristique du Polarimetre
            // Baud : 9600
            // Parity : none
            // Controle : Software
            // Nbre bits :

            Polarimetre.id = UART2;
            Polarimetre.Rx_buffer = &UART2_Buffer_Rx;
            Polarimetre.Rx_Recieved = &UART2_NbreBytes_Rx;
            UART2_NbreBytes_Rx = 0;
            Polarimetre.NbreBits = UART_DATA_SIZE_8_BITS;
            Polarimetre.Parity = UART_PARITY_NONE;
            Polarimetre.StopBits = UART_STOP_BITS_1;
            Polarimetre.DataRate = 9600;
            UARTInitialise(Polarimetre);
			
            StatusInitialisation = 1; // nous passons au case 1
            ReceptionData = 0;
            break;
        } //Delayms(260);

            // La demande de mise en ligne du polarimetre est faite.
            // Attente de sa r�ponse qui est OK
        case 1:
        {
            // initialisation de la connexion par envoi de la commande status
            if (ReceptionData == 0)
            {
                strcpy(Commande, "ONLINE");
                SendDataBuffer(Commande, Polarimetre.id);
                ReceptionData = 1; // nous passons � la r�ception des donn�es
            }
            else if (ReceptionData == 1)
            {
                if (UARTReceivedDataIsAvailable(Polarimetre.id))
                {
                    GetDataBuffer(Reponse, Polarimetre.id);
                    ReponseValide1 = strstr(Reponse, "OK");

                    if (ReponseValide1 != NULL)
                    {
                        StatusInitialisation = 2;
                        ReceptionData = 0;
                    }
                    else
                    {
                        ReceptionData = 0;
                    }
                }
            }
            break;
        }

            // allumage de la lampe et attente que celle-ci soit op�rationnelle
        case 2:
        {

Et pour finir la fonction qui devrait gérer l'interruption, mais qui ne voit rien venir !

void __ISR(_UART2_VECTOR, ipl2) IntUart2Handler(void) {
    // Is this an RX interrupt?
    if (INTGetFlag(INT_U2RX)) {
        // Clear the RX interrupt Flag
        INTClearFlag(INT_U2RX);

        // Echo what we just received.
        UART2_Buffer_Rx[UART2_NbreBytes_Rx] = ReadUART2();
        UART2_NbreBytes_Rx++;
    }

    // We don't care about TX interrupt
    if (INTGetFlag(INT_U2TX)) {
        INTClearFlag(INT_U2TX);
    }
}

Toutes ces informations sont un peu longues... j’espère que vous arriverez à me suivre ! Et peut être à relever un problème dans ce code...
Remarque : l'interruption du Timer4 fonctionne correctement.

Jean-Marie

[schneiderj]

J'ai trouvé au moins une de mes erreurs : je n'utilisais pas la bonne macro dans INTSetVectorPriority...
Voici l'expression correcte :

INTSetVectorPriority(INT_UART_2_VECTOR, INT_PRIORITY_LEVEL_2);

Mais tout ne fonctionne pas encore correctement !
Jean-Marie

[RISC]

Salut,

J'ai trouvé un exemple de code pour l'UART sur les PIC32 ici.
Ce projet tourne sur l'EXPLORER16 avec (entre autre) un module processeur PIC32MX795F512L. Tu pourras peut-être le tester si tu as cette carte qui possède un connecteur série DB9.

Tu y verras les différentes étapes pour configurer l'UART.
Je te recommande dans un premier temps de l'adapter à ta carte et de faire tourner cet exemple tout seul.
Ensuite il devrait être relativement simple de l'intégrer à ton projet ;=)
Quand les projets deviennent complexes il vaut mieux valider les modules logiciels un par un

a+