=====Configuration sur pc superviseur=====
faire en sorte que je n'ai pas a me relogger toutes les 5minutes
Configuration systeme->Comportement de l'espace de travail->Verrouillage de l'écran->Verrouiller l'écran après 99 minutes
=====Admin réseau windows 10=====
Lister les voisins:
netsh int ipv4 show nei
Lister la table de routage:
netsh int ipv4 show route
Lister les interfaces réseau et les adresses:
netsh int ipv4 show addr
Ne plus utiliser ipconfig /all car il ne liste pas les plusieurs adresses IPv4 que peut avoir une même interface
Pour renouveler les baux dhcp, ce n'est pas automatique sous windows à la déconnexion/reconnexion, il faut faire:
ipconfig /renew
Il y a scp en ligne de commande!
Pour redemander chargement toutes les 600 secondes: marche mais pénible car la page n'est pas forcement rechargée au même endroit...
~~NOCACHE~~
Informations pour les enseignants:
Se logger sur le pc superviseur en tant que: ge2i pass:ge2i
Utiliser le genre masculin pour socket car c'est un anglicisme: https://fr.wiktionary.org/wiki/socket
Les binaires pour les pc superviseur sont stockés en local sur les machines dans /usr/local/binaries/lanceEN.py pour ER2EN et lance.py pour ER2AU
Les fichiers binaires pour les superviseurs sont récupérables sur: https://bvdp.inetdoc.net/files/iut/tp_pic/binaries/
feuillet à imprimer pour 2 étudiants: https://bvdp.inetdoc.net/files/iut/tp_pic/fiche_etudiant.pdf
feuillet de validation par groupe: https://bvdp.inetdoc.net/files/iut/tp_pic/feuille_valid.xlsx
Cheatsheet outils iproute2: https://www.inetdoc.net/pdf/iproute-cheatsheet.pdf
pour vider la table ARP en sudo:
sudo ip neigh flush dev eth0
pour filtrer les requetes et réponses ARP avec Wireshark à partir de l'adresse MAC:
arp.src.hw_mac==00:04:A3:13:0B:86
ou
((eth.dst == 00:04:a3:10:dc:84) || (eth.src == 00:04:a3:10:dc:84) ) && arp
{{https://bvdp.inetdoc.net/files/iut/tp_pic/warning.jpeg}}
POUR ACCEDER A L'INTEGRALITE DU SUJET DE TP:
Si vous êtes en salle ER2AU, se connecter (en cliquant en haut à droite sur s'identifier) en tant que : utilisateur=au, mot de passe=au
Si vous êtes en salle ER2EN, se connecter (en cliquant en haut à droite sur s'identifier) en tant que : utilisateur=en, mot de passe=en
Polycopié du cours: https://bvdp.inetdoc.net/files/iut/cours_preparation_pic_qt_2021_complet_numbered.pdf
A FAIRE A LA FIN DE CHAQUE SEANCE POUR COPIER VOS FICHIERS SUR UN DISQUE PARTAGE (ET PERMETTRE LA RECUPERATION DES FICHIERS SI UN MEMBRE DU BINOME EST ABSENT)
copier coller dans une console:
rsync -av --delete ~/TCPIP_Demo_App_etudiant /mnt/etu/
et compléter la ligne en appuyant 3 fois sur la touche Tabulation, puis entrée.
------------------------------------------------------------
===== TP Bus de communication : Initiation au micro-contrôleur PIC32 et utilisation d'un réseau local pour l'échange de données via sockets UDP =====
==== Objectifs ====
L'objectif de cette série de TP est d'illustrer la communication entre des dispositifs « industriels » de type micro-contrôleurs et des ordinateurs via un réseau Ethernet. Dans un premier temps, vous utiliserez un micro-contrôleur PIC 32 bits de la marque Microchip, programmé à l'aide de l'environnement de développement MPLABX. Ce micro-contrôleur dispose d'un grand nombre d'interfaces de communication dont l'interface ethernet intégrée que nous allons exploiter pour échanger des informations avec un serveur et d'autres cartes PIC. Pour réaliser cela, nous utiliserons des fonctions de la pile (Librairie) TCP/IP Microchip.
Lors des quatre premières heures de TP, vous devrez développer une application sur ce PIC pour qu'il dialogue avec une application déjà écrite sur un PC distant appelé « superviseur ».
Ensuite, vous développerez une application sur PC pour dialoguer avec la carte PIC, sujet présenté dans: [[tpqt]]
====Présentation des réseaux====
Le réseau utilisé pour faire communiquer les cartes PIC et les PC utilise un VLAN sur le réseau de l'IUT:
{{https://bvdp.inetdoc.net/files/iut/tp_pic/ArchiRéseauER+IoT-0.png}}
{{https://bvdp.inetdoc.net/files/iut/tp_pic/ArchiRéseauER+IoT-1.png}}
Durant le TP, nous utiliserons le VLAN disponible sur les port 3 et 4 du commutateur placé sur chaque table. Voici ses caractéristiques:
— VLAN 1600 —
préfixe réseau : 172.16.0.0/26
passerelle par défaut : 172.16.0.1
plage @IP statiques (pour les cartes PIC) : 172.16.0.2 - 33
plage @IP DHCP avec baux statiques (pour les PC) : 172.16.0.34 - 62
IP du PC superviseur : 172.16.0.49
{{https://bvdp.inetdoc.net/files/iut/tp_pic/ArchiRéseauER+IoT-2.png}}
Durant le TP, nous utiliserons le VLAN disponible sur les port 3 et 4 du commutateur placé sur chaque table. Voici ses caractéristiques:
— VLAN 1606 —
préfixe réseau : 172.16.6.0/26
passerelle par défaut : 172.16.6.1
plage @IP statiques (pour les cartes PIC) : 172.16.6.2 - 33
plage @IP DHCP avec baux statiques (pour les PC) : 172.16.6.34 - 62
IP du PC superviseur : 172.16.6.49
Dans la salle, un PC va faire office de superviseur, dans le sens où il va permettre de centraliser les informations issues des différentes cartes PIC et de les piloter à distance.
Ce VLAN utilise des adresses en /26 et possède donc un masque 255.255.255.192.
L'adresse IP 172.16.0.49 est attribuée dynamiquement au PC superviseur grâce à un bail DHCP.
L'adresse IP 172.16.6.49 est attribuée dynamiquement au PC superviseur grâce à un bail DHCP.
Chaque carte PIC numérotée x doit être configurée pour avoir une adresse statique différente en fonction du numéro de la carte.
La carte PIC numérotée x est adressée par l'IP 172.16.0.x.
La carte PIC numérotée x est adressée par l'IP 172.16.6.x.
Le VLAN contient le PC superviseur, les différentes cartes PIC ainsi que les PC utilisés par les étudiants.
Sur le PC superviseur, une application nommée BroadcastReceiver est exécutée en 14 exemplaires, chacune dialoguant avec une unique carte PIC grâce à des numéros de port différents.
Le schéma suivant récapitule l'ensemble des matériels et logiciels que nous allons utiliser dans cette série de TP. Les différents éléments seront expliqués au fur et à mesure. A chaque étape, vous devez être capable d'identifier les portions utilisées et leur rôle. Vous devrez remplir les cases jaunes sur la feuille distribuée lors du TP.
{{https://bvdp.inetdoc.net/files/iut/tp_pic/schemareseauPIC-2018-au-en-horizontal.png}}
===Détermination des adresses===
Pour connaître les adresses IP et MAC des interfaces d'un appareil sous linux, saisir dans une console (ouverte en tapant ALT+F2 puis lxterm) la commande suivante (qui remplace avantageusement: ifconfig -a)
ip addr ls
La commande affiche les différentes interfaces présentes sur la machine. Dans les salles de TP, il y a 2 interfaces filaires par machine, et il vous incombe de déterminer laquelle est connectée à chaque réseau ou VLAN (en fonction de l'IP associée).
L'adresse MAC de chaque interface est affichée sur la ligne "Adresse physique"
Pour connaître l'adresse MAC d'une machine distante, nous pouvons utiliser le mécanisme d'ARP (Adress Resolution Protocol). Pour cela, nous envoyons une requête de ping à la machine distante en tapant dans une console (Pour terminer l'exécution de la commande ping, taper CTRL+C):
ping adresse_IP
Si la machine depuis laquelle cette commande est lancée ne connaît pas encore l'adresse MAC correspondant à cette IP, elle va envoyer une requête ARP sur le réseau pour demander quel dispositif possède cette IP. Le dispositif en question, s'il est présent et qu'il est capable de répondre à la requête, va alors répondre à la requête ARP. (puis plus tard au ping...). La machine qui a lancé la requête ARP va ensuite stocker dans une table la correspondance entre les adresses IP et MAC et cette table sera visible en saisissant dans une console la commande suivante (qui remplace avantageusement: arp -a):
ip neigh ls
Pour consulter la table de routage en IPv4:
ip route ls
Pour consulter la table de routage en IPv6 (non utilisée dans le TP):
ip -6 route ls
====Présentation du format d'échange des données====
Chaque application BroadcastReceiver réalise la tâche suivante: Tout d'abord, elle ouvre des sockets UDP (canal de communication, se reporter au cours de réseau) pour communiquer:
- En émission: Superviseur avec l'IP 172.16.0.49 et le port UDP 30002+10*x vers carte PIC avec l'IP 172.16.0.x et le port 30002+10*x
- En réception: Carte PIC avec l'IP 172.16.0.x et le port UDP 30001+10*x vers Superviseur avec l'IP 172.16.0.49 et le port 30001+10*x
Par exemple, l'application 3 communiquant avec la carte PIC 3 émet ses informations vers l'IP PIC 172.16.0.3 port 30032 et les reçoit sur le port 30031. La figure suivante montre la fenêtre de cette application:
{{https://bvdp.inetdoc.net/files/iut/tp_pic/appliQT1en.png}}
- En émission: Superviseur avec l'IP 172.16.6.49 et le port UDP 30002+10*x vers carte PIC avec l'IP 172.16.6.x et le port 30002+10*x
- En réception: Carte PIC avec l'IP 172.16.6.x et le port UDP 30001+10*x vers Superviseur avec l'IP 172.16.6.49 et le port 30001+10*x
Par exemple, l'application 3 communiquant avec la carte PIC 3 émet ses informations vers l'IP PIC 172.16.6.3 port 30032 et les reçoit sur le port 30031. La figure suivante montre la fenêtre de cette application:
{{https://bvdp.inetdoc.net/files/iut/tp_pic/appliQT1au.png}}
Ensuite l'application BroadcastReceiver affiche les datagrammes UDP reçus sous forme d'une chaîne de caractères, et si la chaîne est conforme au format attendu, elle visualise l'état des trois boutons dont la valeur a été passée via des variables que nous nommerons b1state, b2state et b3state (actif à 1). Une variable compteur est également transmise pour comptabiliser le nombre de trames émises par le PIC. Le format à respecter a été choisi arbitrairement comme une chaîne ASCII générée par :
sprintf(chaine,"compteur= %6d b1:%d b2:%d b3:%d\n",compteuretudiant,b1state,b2state,b3state);
La fonction sprintf fonctionne de la même façon que le printf sauf que la chaine, au lieu d'être affichée sur une console, est écrite dans une variable de type tableau de caractères dont l'adresse de début est passée en premier paramètres de la fonction sprintf. Dans cet exemple, la variable char chaine[100] est donc remplie avec les caractères qui auraient normalement été affichés si l'on avait exécuté la fonction printf.
L'application permet également de commander les LED de la carte PIC. Elle dispose pour cela de 4 Boutons. Les boutons « Led0 », « Led1 » et « Led2 » doivent faire commuter l'état des leds correspondantes sur la carte PIC lors d'un appui, alors que le bouton « start clignote LED0 » permet de commuter automatiquement la led0 toutes les 2 secondes. Chaque commutation d'une Led numérotée i est pilotée en envoyant une chaine ASCII générée par:
sprintf(chaine,"%d",i) ;
Pour rappel, l'objectif de ce premier TP est de développer l'application tournant sur le PIC qui va émettre l'état des boutons et commander les LED.
====Présentation de la carte de développement====
La carte utilisée est une PIC32 Ethernet Starter Kit.
La documentation de cette carte est disponible dans le fichier: https://bvdp.inetdoc.net/files/iut/tp_pic/doc/PIC32_Starter_Kits_Users_Guide_DS61159A.pdf
La documentation du micro-contrôleur PIC32MX est dans le fichier: https://bvdp.inetdoc.net/files/iut/tp_pic/doc/PIC32MX-61156D.pdf
Pour les plus curieux, le schéma de la carte est visible sur: https://bvdp.inetdoc.net/files/iut/tp_pic/doc/PIC32ESKSchematics.pdf
La structure interne du PIC32 est visible sur l'image suivante:
{{https://bvdp.inetdoc.net/files/iut/tp_pic/pic32intern.png}}
La carte possède des E/S simples à utiliser, 3 LED et 3 boutons:
- bouton SW1: Actif à l'état bas et connecté au bit 6 du port D (RD6)
- bouton SW2: Actif à l'état bas et connecté au bit 7 du port D (RD7)
- bouton SW3: Actif à l'état bas et connecté au bit 13 du port D (RD13)
- LED 0: actif à l'état haut et connectée au bit 0 du port D (RD0)
- LED 1: actif à l'état haut et connectée au bit 1 du port D (RD1)
- LED 2: actif à l'état haut et connectée au bit 2 du port D (RD2)
Cette carte est dotée d'une connectivité variée:
- Interface USB Host: La carte peut être raccordée à des périphériques (clef usb, souris,clavier...)
- Interface USB OnTheGo: La carte peut être raccordée comme un périphérique (Device) à un hôte (PC ou autre carte micro-contrôleur) ou comme un hôte au choix.
- Interface USB Debug: Cette interface USB est connectée à un second micro-contrôleur PIC de la carte de développement servant au chargement et au test des programmes. Cette interface est également utilisée pour alimenter la carte en 5V via le bus USB.
- Interface Ethernet 10/100: Cette interface permet de raccorder la carte à un réseau ethernet.
- Connecteur d'extension: ce connecteur de 120 broches permet d'utiliser diverses broches et interfaces du micro-contrôleur.
===Structure interne du micro-contrôleur===
Le micro contrôleur est de type 32 bits, il est donc capable d'effectuer des opérations directement sur des registres de 32 bits. Comme nous allons le programmer en langage C, cela se traduira principalement par une plus grande vitesse d'exécution des calculs sur les grands nombres.
Le micro-contrôleur intègre la partie MAC (Média Access Control), la couche PHY (PHYsique) étant quand à elle réalisée par le composant DP83848C de chez Texas Instrument, voir le fichier: https://bvdp.inetdoc.net/files/iut/tp_pic/doc/1668041.pdf
=====Développement sur PIC=====
Le développement de l'application se fait en langage C. Nous utiliserons une version un peu allégée du projet de démo "TCP/IP Demo App" dans lequel nous ajouterons une tâche de communication utilisant 2 sockets UDP.
====Structure de l'application à construire====
Le code que vous devez développer doit être écrit uniquement dans deux fichiers etudiantSocketApp.c et etudiantSocketApp.h. Ces fichiers définissent 2 fonctions appelées par le programme principal:
- une fonction void etudiantSocketAppInit(); appelée une fois en début de programme.
- une fonction void etudiantSocketAppTask(); appelée en boucle dans le programme à une cadence dépendant des autres tâches à exécuter. Par exemple, le micro contrôleur exécute une tâche de réponse au PING comme nous le verrons plus loin. Il ne faut donc pas que la fonction etudiantSocketAppTask soit bloquante, au risque de bloquer l'exécution d'autres services.
Durant le développement de votre application, vous pourrez utiliser la fonction DBPRINTF(char texte[]); pour afficher dans la console debug des messages courts indiquant l'état du programme. Veillez à utiliser cette fonctionnalité avec parcimonie car elle est très lente.
Veillez également à ce que la chaine passée en paramètre soit bien terminée par \n pour déclencher l'envoi effectif de la chaine sur l'interface debug. Dans le cas contraire, vous pourrez faire un appel à:
DBPRINTF("\n");
L'affichage des infos de debug dans le champ Output->DBPRINTF (droite de Starter Kits dans la partie inférieure de MPLABX).
===Note sur les types===
Afin de différencier les entiers sur 8,16 et 32 bits, 3 types sont définis:
- DWORD pour des entiers sur 32 bits.
- WORD pour des entiers sur 16 bits.
- BYTE pour des entiers sur 8 bits.
D'autres types sont également définis: UDP_SOCKET, UDP_PORT, NODE_INFO...
===Sockets MICROCHIP===
L'application à développer utilise une interface propre à MICROCHIP pour l'utilisation des sockets. Son usage reste très proche de celui des Sockets BSD vus en TP de réseau. La documentation complète de la pile TCP/IP est disponible dans le fichier: https://bvdp.inetdoc.net/files/iut/tp_pic/doc/TCPIPStackHelp.chm
Cliquer sur Index puis sur UDP pour accéder à la partie qui nous sera utile. Le schéma suivant montre les différentes fonctions correspondant à l'utilisation d'une socket UDP:
{{https://bvdp.inetdoc.net/files/iut/tp_pic/udpmicrochip.png}}
Nous nous restreindrons à utiliser les sockets dans un seul sens de communication à la fois et nous utiliserons donc deux sockets manipulés via deux variables globales pour établir et maintenir la communication bidirectionnelle:
UDP_SOCKET udpsock; //utilisé pour l'émission depuis le PIC
UDP_SOCKET udpsock2; //utilisé pour la réception depuis le PIC
Chaque socket doit ensuite être ouvert dans la fonction etudiantSocketAppInit() par un appel à la fonction:
UDP_SOCKET UDPOpen( UDP_PORT localPort, NODE_INFO * ptr_remoteNode, UDP_PORT remotePort);
Dans notre projet, les paramètres **localPort** et **remotePort** auront des valeurs effectives identiques pour un même socket: le numéro du port. **ptr_remoteNode** est un pointeur sur une structure qui permet d'identifier l'hôte distant connecté avec le socket. Cette structure est constituée de deux tableaux d'octets IPAddr.v[] et MACAddr.v[] codant respectivement l'adresse IP et l'adresse MAC de l'hôte distant. Pour ouvrir un socket en réception depuis n'importe quel hôte, il faut passer la valeur **NULL** comme paramètre effectif ptr_remoteNode.
La fonction **UDPClose()** ne sera pas utilisée dans notre application, car les 2 sockets sont ouverts à l'initialisation et utilisés tout au long de l'exécution du programme.
===Socket en émission===
Pour émettre des données sur un socket en émission, il faut s'assurer qu'il y ait de la place dans son buffer d'émission (FIFO). Pour déterminer la place disponible, nous utiliserons la fonction suivante qui retourne le nombre de caractères que l'on peut émettre sur un socket:
WORD UDPIsPutReady( UDP_SOCKET s);
S'il y a suffisamment de place pour émettre les données, une chaîne de caractères **cData** contenant **wDataLen** caractères peut être copiée dans le buffer d'émission par un appel à la fonction:
WORD UDPPutArray( BYTE * cData, WORD wDataLen); //retourne le nombre de caractères effectivement émis.
Finalement, pour demander l'émission effective des données du buffer d'émission sur l'interface, il faut faire appel à la fonction :
void UDPFlush();
===Socket en réception===
Le socket en réception utilise d'autres fonctions. La fonction **UDPIsGetReady()** retourne le nombre de caractères pouvant être lus sur un socket, car disponible dans le buffer de réception:
WORD UDPIsGetReady( UDP_SOCKET s);
Les caractères (au nombre de **wDataLen**) sont ensuite lus vers une chaîne **cData** par la fonction:
WORD UDPGetArray( BYTE * cData, WORD wDataLen);
===Gestion du temps===
La fonction **etudiantSocketAppTask()** n'est pas appelée à intervalle de temps constant. Pour définir la périodicité (le nombre de fois que la tâche doit être exécutée par seconde), on utilise un timer que l'on vient scruter (mécanisme de scrutation plutôt que d'interruption) à chaque appel de la fonction **etudiantSocketAppTask()** pour savoir s'il est temps d'exécuter la tâche.
Après avoir défini la variable globale DWORD tim = 0; et la constante
#define ETUDIANTSOCKETAPP_OCCURENCE_PAR_SEC 5ul //pour 5 fois par secondes,
la fonction **etudiantSocketAppTask()** possède cette structure:
void etudiantSocketAppTask()
{
if(TickGet() -tim >= TICK_SECOND/ ETUDIANTSOCKETAPP_OCCURENCE_PAR_SEC)
{
tim = TickGet();
compteur++; //Tâche à exécuter, incrémentation d'un compteur par exemple....
}
}
===Génération et décodage de chaînes de caractères ASCII===
Nous allons utiliser des tableaux de caractères pour l'émission et la réception des données via les sockets car ce sont les paramètres d'entrées/sorties utilisés par les fonctions disponibles pour l'envoi et la réception de datagrammes. Pour rappel, les fonctions permettant d'écrire et de lire dans une chaîne de caractères **chainecarac** la chaîne de caractères formatée **format** (par exemple ''Bonjour %d'') sont:
int sprintf(char* chainecarac, const char * format, ... );
int sscanf(char* chainecarac, const char * format, ... );
La fonction strlen retourne le nombre de caractères d'une chaîne **chainecarac** terminée par le caractère '\0' (sans compter le caractère '\0'):
int strlen(char* chainecarac);
===Lecture de l'état des boutons===
L'état des 3 boutons est lu et affecté à des variables grâce à:
b1state=(int)!PORTReadBits(IOPORT_D, BIT_6);
b2state=(int)!PORTReadBits(IOPORT_D, BIT_7);
b3state=(int)!PORTReadBits(IOPORT_D, BIT_13);
===Commande des LED===
Les Leds sont changées d'état en exécutant:
LED0_IO ^= 1; //opérateur Ou exclusif avec opérande 1 = complémentation
LED1_IO ^= 1;
LED2_IO ^= 1;
Il est bien sûr possible de commander les leds par valeur par exemple avec:
LED1_IO = 0;
LED1_IO = 1;
LED1_IO = b2state;
====Remarques importantes:====
- Dans tout le TP, vous veillerez à ne pas commenter ou casser du code précédemment validé. Chaque exercice doit ajouter des fonctionnalités, en maintenant le bon fonctionnement des fonctionnalités précédentes!
- Ne brancher le câble réseau sur l'interface du PIC que lorsque vous voulez tester votre programme sur la carte.
- Les cartes PIC ainsi que les câbles réseaux sont numérotés, il est IMPERATIF de n'utiliser que votre câble et votre carte et de régler correctement l'adresse IP de votre carte via le fichier "TCPIPConfig PIC32 Internal Ethernet.h".
- Votre application est contenue uniquement dans les fichiers etudiantSocketApp.c et etudiantSocketApp.h. Vous n'avez pas à modifier d'autres fichiers hormis "TCPIPConfig PIC32 Internal Ethernet.h" pour les réglages d'adresses IP.
- Ne jamais brancher une carte PIC sur le réseau sans avoir préalablement chargé votre programme... Elle contient peut être un mauvais programme qui va polluer tout le réseau et empêcher vos collègues de travailler!
- La carte de développement PIC32 est alimentée par le port USB, ne pas chercher à l'alimenter par une alimentation externe.
- Ne pas changer la position des cavaliers sur les cartes.
=====Travail demandé=====
====Avant de coder...====
==Identification des binômes==
- Remplir la feuille de présence pour déterminer qui utilise quelle carte et quelle adresse IP.
==Identification des éléments utiles sur le schéma et analyse des couches réseau==
- Repérer sur le schéma à remplir les éléments utilisés pour faire dialoguer la carte PIC avec le PC superviseur..
- Établir un schéma faisant apparaître les différentes couches réseau impliquées.
==Récupération du projet==
POUR LA PREMIERE SEANCE UNIQUEMENT!, Copier/coller dans une console:
echo commence
cd ~
wget https://bvdp.inetdoc.net/files/iut/tp_pic/install_linux/TCPIP_Demo_App_etudiant.zip
unzip TCPIP_Demo_App_etudiant.zip
rm TCPIP_Demo_App_etudiant.zip
echo fini
==Initialisation du système de gestion de version en local==
POUR LA PREMIERE SEANCE UNIQUEMENT!, Copier/coller dans une console:
echo commence
cd ~/TCPIP_Demo_App_etudiant
git init
git add etudiantSocketApp.c ./Alternative_Configurations/TCPIPConfig_PIC32_Internal_Ethernet.h etudiantSocketApp.h MainDemo.c
git commit -m'initial version'
gitk &
echo fini
Vous pouvez ensuite fermer l'outils gitk qui permet de voir les changements entre les différentes versions.
==Lancement de l'outils de développement==
- Brancher la carte de développement sur le port USB du PC.
- Lancer mplabX, en ouvrant un terminal et en saisissant mplab_ide
- Dans mplabX, cliquer sur File->Open project et choisir le projet Projet.X dans le dossier ~/TCPIP_Demo_App_etudiant
- Par la suite, en cas de message d'erreur indiquant que la carte ne peut pas être réinitialisée, il faudra fermer MPLABX et le relancer.
==Configuration de l'adresse IP de chaque carte==
L'adresse IP associée à chaque carte est dite 'statique', c'est à dire qu'elle est attribuée à chaque carte par le programme de chacune d'elle, au lieu d'être attribuée par un serveur (on parle alors d'adresse 'dynamique' fournie par un serveur DHCP)
- Ouvrir « TCPIPConfig PIC32 Internal Ethernet.h » dans le projet (en déroulant à gauche Header files)
- Localiser le réglage de l'adresse IP et du masque dans ce fichier et remplacer les valeurs par celles qui conviennent. Par exemple, pour régler le quatrième octet de l'IP à la valeur 100:
#define MY_DEFAULT_IP_ADDR_BYTE4 {100ul}
Le masque est réglé à l'aide des macros **MY_DEFAULT_MASK_BYTE1** à **4**, de la même manière.
Le suffixe ul apres la valeur 100 signifie que la valeur est une constante à interpréter en tant que **Unsigned Long**.
==Chargement de votre programme et utilisation du mode debug==
- Cliquer sur Debug->Debug project. NB: la première compilation est lente (qq dizaines de secondes) mais les suivantes seront plus rapides car seuls les fichiers modifiés seront recompilés (sauf si vous modifiez « TCPIPConfig PIC32 Internal Ethernet.h ») . Quand "User Program Running" s'affiche dans la fenêtre sous le code, la compilation et le chargment de l'application sont terminées.
- Placer des points d'arrêt dans votre programme, en cliquant sur le numéro de la ligne (petit carré rouge apparaît), pour le désactiver, cliquer à nouveau sur le carré.
- Presser Debug->debug project pour charger le programme dans le micro contrôleur et lancer le mode debug (Debug->Finish debugger session)
====Exercice 1: Test de communication avec la carte ====
Il y a plusieurs tâches fonctionnant en (pseudo)parallèle sur le PIC, notamment un service de réponse au PING.
- Votre carte étant en fonctionnement (programme en cours d’exécution) et raccordée au réseau, lancer une demande de PING depuis votre PC avec l'adresse de votre carte. Si celle-ci est connectée au réseau et en fonction, elle doit répondre et l'outil ping doit afficher le temps mis par la carte pour répondre (généralement moins d'une milliseconde sur ce réseau local). Cette opération peut être réalisée en saisissant par exemple dans une console:
ping 172.16.0.2
ping 172.16.6.2
{{https://bvdp.inetdoc.net/files/iut/tp_pic/validation.png}}
Une fois la réponse au ping validée, mettre à jour le suivi de version en saisissant dans une console:
echo commence
cd ~/TCPIP_Demo_App_etudiant
git commit -a -m'ping working'
gitk &
echo fini
====Exercice 2: Prise en main des E/S ====
- Débrancher le cable réseau pour cet exercice.
- Dans la fonction **etudiantSocketAppTask()**, recopier l'état des boutons sur les LEDs correspondantes **à une cadence d'une fois par seconde**.
- Afficher sur l'interface debug la chaîne qui devrait être envoyé au superviseur pour donner l'état des boutons à l'aide de la fonction **DBPRINTF** présentée plus haut. La chaîne affichée devra être générée dans le tableau **chaine** que vous aurez déclaré préalablement avec une taille suffisante. Le remplissage du tableau se fera à l'aide de la fonction **sprintf**:
sprintf(chaine,"compteur= %6d b1:%d b2:%d b3:%d\n",compteuretudiant,b1state,b2state,b3state);
{{https://bvdp.inetdoc.net/files/iut/tp_pic/validation.png}}
Mettre à jour le suivi de version en saisissant dans une console:
echo commence
cd ~/TCPIP_Demo_App_etudiant
git commit -a -m'E/S working'
gitk &
echo fini
====Exercice 3: Réception de commandes des LED ====
- Compléter les fonctions **etudiantSocketAppInit()** et **etudiantSocketAppTask()** pour gérer la réception périodique des chaînes de caractères commandant les LED depuis le PC superviseur. Pour cela, vous devrez ouvrir un socket écoutant sur le bon numéro de port et depuis n'importe quelle IP. Veillez à définir un tableau de caractères en mémoire et à ne pas tenter de lire plus de caractères qu'il n'y a de place dans ce tableau. Vous pourrez au choix traiter un ordre de commutation des LEDS par appel de la fonction **etudiantSocketAppTask()** ou bien traiter autant d'ordres que possible (en fonction de la taille de votre tableau)
- Vous penserez à commenter **UNIQUEMENT** les lignes de votre programme qui pilotent les leds à partir de l'état des boutons pour ne pas interférer avec la commande des LEDs depuis le réseau. Conserver tout le reste du code en place, notamment la lecture de l'état des boutons et l'affichage de la chaine dans **DBPRINTF**.
- Tester votre programme en demandant sur le PC superviseur, via l'application BroadcastReceiver qui communique avec votre carte PIC, de commuter chacune des LEDs.
{{https://bvdp.inetdoc.net/files/iut/tp_pic/validation.png}}
Mettre à jour le suivi de version en saisissant dans une console:
echo commence
cd ~/TCPIP_Demo_App_etudiant
git commit -a -m'led working'
gitk &
echo fini
====Exercice 4: Émission de l'état des boutons ====
- Compléter les fonctions **etudiantSocketAppInit()** et **etudiantSocketAppTask()** pour gérer l'envoi périodique à une fréquence d'un Hertz de la chaîne de caractères codant l'état des boutons poussoirs vers le PC superviseur. La chaîne envoyée sur le socket devra contenir le caractère '\0'.
Pour cette tâche, il faut configurer l'ouverture du socket avec une seule machine sur le réseau. Dans un premier temps, nous n'utiliserons pas le mécanisme ARP et nous devrons donc régler l'adresse IP et l'adresse MAC de la machine distante (le PC superviseur) avant d'ouvrir le socket en définissant une variable globale **NODE_INFO myRemoteNode;** puis en l'initialisant dans la fonction **etudiantSocketAppInit()** avec les valeurs que vous aurez déterminées grâce aux commandes ping et arp:
myRemoteNode.IPAddr.v[0] = XXX; //Adresse IP du PC superviseur, premier octet (de poids fort)
myRemoteNode.IPAddr.v[1] = XXX;
myRemoteNode.IPAddr.v[2] = XXX;
myRemoteNode.IPAddr.v[3] = XXX;
myRemoteNode.MACAddr.v[0]= XXX; //Adresse MAC du PC superviseur, premier octet (de poids fort)
myRemoteNode.MACAddr.v[1]= XXX;
myRemoteNode.MACAddr.v[2]= XXX;
myRemoteNode.MACAddr.v[3]= XXX;
myRemoteNode.MACAddr.v[4]= XXX;
myRemoteNode.MACAddr.v[5]= XXX;
Ensuite, passer un pointeur sur **myRemoteNode** en paramètre à la fonction **UDPOpen()** lors de l'ouverture du socket en émission.
{{https://bvdp.inetdoc.net/files/iut/tp_pic/validation.png}}
Mettre à jour le suivi de version en saisissant dans une console:
echo commence
cd ~/TCPIP_Demo_App_etudiant
git commit -a -m'buttons working'
gitk &
echo fini
====Exercice 5: Gestion de l'ARP pour la communication avec le PC superviseur====
On souhaite maintenant mettre en place le mécanisme d'ARP dans l'application sur le PIC. Vous allez dans un premier temps "casser" l'initialisation de **myRemoteNode.MACAddr.v[i]** en mettant des 0 dans toutes les cases et nous allons utiliser les fonctions suivantes pour remplir automatiquement ce tableau:
ARPResolve(type pointeur sur adresse IP );
et
bool ARPIsResolved(type pointeur sur adresse IP, type pointeur sur adresse MAC)
Dans la fonction **etudiantSocketAppTask()**, à l'intérieur de la tâche périodique à 1Hz, ajouter une machine à état **simple** (l'état étant codé par une variable **static int**) permettant de faire des requêtes ARP avec la fonction **ARPResolve**. Ceci permet d'envoyer une requette ARP avec l'adresse IP passée en argument. Dans les appels suivants de la fonction** etudiantSocketAppTask()**, il vous faudra tester si **ARPIsResolved** a renvoyé **TRUE**, ce qui signifie que la réponse ARP est arrivée et donc que le champ adresse MAC est mis à jour. Dans ce cas il faudra ouvrir le socket (une seule fois) puis effectuer l'envoi des données comme dans l'exercice précédent. Dans le cas contraire, il faudra appeler à nouveau **ARPResolve** pour envoyer une nouvelle requête.
Il est important que la fonction **etudiantSocketAppTask()** soit NON BLOQUANTE!
////////////////////////////////////////////////////////////////////////////////
// Finite State Machine .dot diagram autogenerated by FsmProcess V 1.0 B. VANDEPORTAELE LAAS-CNRS 2016
////////////////////////////////////////////////////////////////////////////////
digraph finite_state_machine {
rankdir=LR;
ranksep=0.5;
nodesep=0.1;
///////////////////////////////////////////////////////////////////////////////////////////////////////////
// Finite State Machine Name: arp2
///////////////////////////////////////////////////////////////////////////////////////////////////////////
//////////////////display states//////////////////
//---------State: 0 -----------------
{ rank = same;
state_0 [shape=doublecircle, fixedsize=true, width=0.63, label= "0" ];
//Action on state:
stateaction_0 [shape=box,label= <> ];
//attach the action on the state
state_0 ->stateaction_0 [arrowhead=none ] ;
};
//---------State: 1 -----------------
{ rank = same;
state_1 [shape=circle,fixedsize=true,width=0.63, label= "1" ];
//Action on state:
stateaction_1 [shape=box,label= <> ];
//attach the action on the state
state_1 ->stateaction_1 [arrowhead=none ] ;
};
//////////////////display transitions//////////////////
state_0 -> state_1[ shape=box, label= <> ];
}
Pour débugger, vous pourrez afficher l'adresse IP demandée dans la requête ARP à l'aide de:
sprintf(chaine, "ARPResolve adresse IP= %d.%d.%d.%d\n", myRemoteNode.IPAddr.v[0], myRemoteNode.IPAddr.v[1], myRemoteNode.IPAddr.v[2], myRemoteNode.IPAddr.v[3]);
DBPRINTF(chaine);
Puis afficher l'adresse MAC obtenue à l'aide de
sprintf(chaine, "ARP OK: adresse mac= %02x:%02x:%02x:%02x:%02x:%02x\n", myRemoteNode.MACAddr.v[0], myRemoteNode.MACAddr.v[1], myRemoteNode.MACAddr.v[2], myRemoteNode.MACAddr.v[3], myRemoteNode.MACAddr.v[4], myRemoteNode.MACAddr.v[5]);
DBPRINTF(chaine);
Tester l'émission avec le mécanisme d'ARP avec le PC superviseur. Utiliser le logiciel Wireshark sur le PC superviseur pour observer la requête et la réponse ARP suivies des datagrammes UDP échangés entre votre carte PIC et l'application correspondante sur le PC superviseur.
{{https://bvdp.inetdoc.net/files/iut/tp_pic/validation.png}}
Mettre à jour le suivi de version en saisissant dans une console:
echo commence
cd ~/TCPIP_Demo_App_etudiant
git commit -a -m'ARP working'
gitk &
echo fini
Solution:
static int state=0;
if (state==0)
{
DBPRINTF("ARPResolve\n");
ARPResolve(& (myRemoteNode.IPAddr));
state=1;
}
else if (state==1)
{
DBPRINTF("ARPIsResolved\n");
if(!ARPIsResolved(& (myRemoteNode.IPAddr), & (myRemoteNode.MACAddr)))
ARPResolve(& (myRemoteNode.IPAddr));
else
state=2;
}else
DBPRINTF("youpi\n");
Solution avec affichage adresse MAC sur dbprintf
static int state = 0;
if (state == 0) {
ARPResolve(& (myRemoteNode.IPAddr));
if (ARPIsResolved(& (myRemoteNode.IPAddr), & (myRemoteNode.MACAddr))) {
state = 1;
}
} else if (state == 1) {
DBPRINTF("ARP OK\n");
sprintf(chaine, "adresse mac= %02x:%02x:%02x:%02x:%02x:%02x\n",myRemoteNode.MACAddr.v[0],myRemoteNode.MACAddr.v[1],myRemoteNode.MACAddr.v[2],myRemoteNode.MACAddr.v[3],myRemoteNode.MACAddr.v[4],myRemoteNode.MACAddr.v[5] );
DBPRINTF(chaine);
udpsock = UDPOpen(30131, &myRemoteNode, 30131);
state = 2;
} else if (state == 2) {
sprintf(chaine, "compteur= %6d b1:%d b2:%d b3:%d\n", compteuretudiant, b1state, b2state, b3state);
DBPRINTF(chaine);
N2 = UDPIsPutReady(udpsock);
if (N2 > strlen(chaine)) {
UDPPutArray(chaine, strlen(chaine));
UDPFlush();
}
}
BYTE resolu=0;
//A faire à 1Hz:
if(resolu==0)
{
ARPResolve(&info_superviseur.IPAddr);
if(ARPIsResolved(&info_superviseur.IPAddr,&info_superviseur.MACAddr))
{
resolu=1;
DBPRINTF("ARP OK\n");
sprintf(chaine, "adresse mac= %02x:%02x:%02x:%02x:%02x:%02x\n",info_superviseur.MACAddr.v[0],info_superviseur.MACAddr.v[1],info_superviseur.MACAddr.v[2],info_superviseur.MACAddr.v[3],info_superviseur.MACAddr.v[4],info_superviseur.MACAddr.v[5] );
DBPRINTF(chaine);
}
}
else
{
//la tache d'émission périodique
}
===Communication avec votre PC===
Récupérer l'éxecutable de l'application broadcastreceiver sur votre machine:
echo commence
cd ~/TCPIP_Demo_App_etudiant
wget bvdp.inetdoc.net/files/iut/tp_pic/binaries/broadcastreceiver
chmod a+x broadcastreceiver
echo fini
Ensuite saisir dans la console en substituant les paramètres par leur valeurs correctes:
./broadcastreceiver AdresseIPCartePIC PortUDPReceptionSurPC PortUDPEmissionSurPC
par exemple pour la carte PIC numéro 17:
./broadcastreceiver 172.16.0.17 30171 30172
==Vielle version windows==
Récupérer le dossier « commum/2AU/PIC/socketqtbroastreceiver »
Configurer l'application BroadcastReceiver en éditant le script « lancer.bat » (click droit, modifier) pour configurer les ports UDP en émission et en réception. La syntaxe est la suivante
broadcastReceiver IP_destination port_UDP_émission port_UDP_réception paramètres_optionnels_de_réglages_de_la_fenêtre
par exemple:
start broadcastreceiver 192.168.1.100 27016 27017 10 40 500 130
Déterminer les adresses IP (et MAC) de l'adaptateur réseau Realteck du PC étudiant en lançant ipconfig /all dans une console.
Modifier le code du PIC en conséquence (adresses IP (et MAC si ARP non fonctionnel) destinataire et numéros de ports).
Vérifier la communication entre le PC et le PIC
{{https://bvdp.inetdoc.net/files/iut/tp_pic/validation.png}}
Mettre à jour le suivi de version en saisissant dans une console:
echo commence
cd ~/TCPIP_Demo_App_etudiant
git commit -a -m'reglage de l adresse IP du pc etudiant'
gitk &
echo fini
------------------------------------------------------------
Commentaire pour watch, or le débugger déconne:
- Utiliser View->Watch pour suivre les valeurs de variables (par exemple le compteur incrémenté à chaque appel de la fonction etudiantSocketAppTask() ). Pour cela, sélectionner le nom de la variable dans la liste et cliquer sur add, la variable ainsi que sa valeur sont alors ajoutés en bas de liste. Pour visualiser la valeur d'un registre à usage spécial, procéder de la même façon dans la liste SFR.
=====Solutions=====
Paire de fichiers permettant le fonctionnement dans les 2 salles, avec ARP. Il faut uniquement régler:
//numéro de la salle 0 pour EN, 6 pour AU
#define MY_DEFAULT_IP_ADDR_BYTE3 (0ul)
//numéro de la carte PIC
#define MY_DEFAULT_IP_ADDR_BYTE4 (13ul)
// 34; pour le pc superviseur , un autre numero pour un pc étudiant
#define MY_DEFAULT_GATE_BYTE4 (34ul)
/*********************************************************************
*
* Microchip TCP/IP Stack Demo Application Configuration Header
*
*********************************************************************
* FileName: TCPIPConfig.h
* Dependencies: Microchip TCP/IP Stack
* Processor: PIC18, PIC24F, PIC24H, dsPIC30F, dsPIC33F, PIC32
* Compiler: Microchip C32 v1.10 or higher
* Microchip C30 v3.12 or higher
* Microchip C18 v3.34 or higher
* HI-TECH PICC-18 PRO 9.63PL2 or higher
* Company: Microchip Technology, Inc.
*
* Software License Agreement
*
* Copyright (C) 2002-2010 Microchip Technology Inc. All rights
* reserved.
*
* Microchip licenses to you the right to use, modify, copy, and
* distribute:
* (i) the Software when embedded on a Microchip microcontroller or
* digital signal controller product ("Device") which is
* integrated into Licensee's product; or
* (ii) ONLY the Software driver source files ENC28J60.c, ENC28J60.h,
* ENCX24J600.c and ENCX24J600.h ported to a non-Microchip device
* used in conjunction with a Microchip ethernet controller for
* the sole purpose of interfacing with the ethernet controller.
*
* You should refer to the license agreement accompanying this
* Software for additional information regarding your rights and
* obligations.
*
* THE SOFTWARE AND DOCUMENTATION ARE PROVIDED "AS IS" WITHOUT
* WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING WITHOUT
* LIMITATION, ANY WARRANTY OF MERCHANTABILITY, FITNESS FOR A
* PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT SHALL
* MICROCHIP BE LIABLE FOR ANY INCIDENTAL, SPECIAL, INDIRECT OR
* CONSEQUENTIAL DAMAGES, LOST PROFITS OR LOST DATA, COST OF
* PROCUREMENT OF SUBSTITUTE GOODS, TECHNOLOGY OR SERVICES, ANY CLAIMS
* BY THIRD PARTIES (INCLUDING BUT NOT LIMITED TO ANY DEFENSE
* THEREOF), ANY CLAIMS FOR INDEMNITY OR CONTRIBUTION, OR OTHER
* SIMILAR COSTS, WHETHER ASSERTED ON THE BASIS OF CONTRACT, TORT
* (INCLUDING NEGLIGENCE), BREACH OF WARRANTY, OR OTHERWISE.
*
*
* Author Date Comment
*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Howard Schlunder 10/04/2006 Original
* Ken Hesky 07/01/2008 Added ZG2100-specific features
* SG 03/25/2009 Added ZGLinkMgrII specific features
********************************************************************/
#ifndef __TCPIPCONFIG_H
#define __TCPIPCONFIG_H
#include "GenericTypeDefs.h"
#include "Compiler.h"
#define GENERATED_BY_TCPIPCONFIG "Version 1.0.3383.23374"
// =======================================================================
// Application Options
// =======================================================================
/* Application Level Module Selection
* Uncomment or comment the following lines to enable or
* disabled the following high-level application modules.
*/
//#define STACK_USE_UART // Application demo using UART for IP address display and stack configuration
//#define STACK_USE_UART2TCP_BRIDGE // UART to TCP Bridge application example
//#define STACK_USE_IP_GLEANING
#define STACK_USE_ICMP_SERVER // Ping query and response capability
#define STACK_USE_ICMP_CLIENT // Ping transmission capability
//#define STACK_USE_HTTP_SERVER // Old HTTP server
//#define STACK_USE_HTTP2_SERVER // New HTTP server with POST, Cookies, Authentication, etc.
//#define STACK_USE_SSL_SERVER // SSL server socket support (Requires SW300052)
//#define STACK_USE_SSL_CLIENT // SSL client socket support (Requires SW300052)
//#define STACK_USE_AUTO_IP // Dynamic link-layer IP address automatic configuration protocol
//#define STACK_USE_DHCP_CLIENT // Dynamic Host Configuration Protocol client for obtaining IP address and other parameters
//#define STACK_USE_DHCP_SERVER // Single host DHCP server
//#define STACK_USE_FTP_SERVER // File Transfer Protocol (old)
//#define STACK_USE_SMTP_CLIENT // Simple Mail Transfer Protocol for sending email
//#define STACK_USE_SNMP_SERVER // Simple Network Management Protocol v2C Community Agent
//#define STACK_USE_SNMPV3_SERVER // Simple Network Management Protocol v3 Agent
//#define STACK_USE_TFTP_CLIENT // Trivial File Transfer Protocol client
//#define STACK_USE_GENERIC_TCP_CLIENT_EXAMPLE // HTTP Client example in GenericTCPClient.c
//#define STACK_USE_GENERIC_TCP_SERVER_EXAMPLE // ToUpper server example in GenericTCPServer.c
//#define STACK_USE_TELNET_SERVER // Telnet server
//#define STACK_USE_ANNOUNCE // Microchip Embedded Ethernet Device Discoverer server/client
#define STACK_USE_DNS // Domain Name Service Client for resolving hostname strings to IP addresses
//#define STACK_USE_DNS_SERVER // Domain Name Service Server for redirection to the local device
//#define STACK_USE_NBNS // NetBIOS Name Service Server for repsonding to NBNS hostname broadcast queries
//#define STACK_USE_REBOOT_SERVER // Module for resetting this PIC remotely. Primarily useful for a Bootloader.
//#define STACK_USE_SNTP_CLIENT // Simple Network Time Protocol for obtaining current date/time from Internet
//#define STACK_USE_UDP_PERFORMANCE_TEST // Module for testing UDP TX performance characteristics. NOTE: Enabling this will cause a huge amount of UDP broadcast packets to flood your network on the discard port. Use care when enabling this on production networks, especially with VPNs (could tunnel broadcast traffic across a limited bandwidth connection).
//#define STACK_USE_TCP_PERFORMANCE_TEST // Module for testing TCP TX performance characteristics
//#define STACK_USE_DYNAMICDNS_CLIENT // Dynamic DNS client updater module
#define STACK_USE_BERKELEY_API // Berekely Sockets APIs are available
//#define STACK_USE_ZEROCONF_LINK_LOCAL // Zeroconf IPv4 Link-Local Addressing
//#define STACK_USE_ZEROCONF_MDNS_SD // Zeroconf mDNS and mDNS service discovery
// =======================================================================
// Data Storage Options
// =======================================================================
/* MPFS Configuration
* MPFS is automatically included when required for other
* applications. If your custom application requires it
* otherwise, uncomment the appropriate selection.
*/
//#define STACK_USE_MPFS
//#define STACK_USE_MPFS2
/* MPFS Storage Location
* If html pages are stored in internal program memory,
* comment both MPFS_USE_EEPROM and MPFS_USE_SPI_FLASH, then
* include an MPFS image (.c or .s file) in the project.
* If html pages are stored in external memory, uncomment the
* appropriate definition.
*
* Supported serial flash parts include the SST25VFxxxB series.
*/
//#define MPFS_USE_EEPROM
//#define MPFS_USE_SPI_FLASH
/* EEPROM Addressing Selection
* If using the 1Mbit EEPROM, uncomment this line
*/
//#define USE_EEPROM_25LC1024
/* EEPROM Reserved Area
* Number of EEPROM bytes to be reserved before MPFS storage starts.
* These bytes host application configurations such as IP Address,
* MAC Address, and any other required variables.
*
* For MPFS Classic, this setting must match the Reserved setting
* on the Advanced Settings page of the MPFS2 Utility.
*/
#define MPFS_RESERVE_BLOCK (137ul)
/* MPFS File Handles
* Maximum number of simultaneously open MPFS2 files.
* For MPFS Classic, this has no effect.
*/
#define MAX_MPFS_HANDLES (7ul)
// =======================================================================
// Network Addressing Options
// =======================================================================
/* Default Network Configuration
* These settings are only used if data is not found in EEPROM.
* To clear EEPROM, hold BUTTON0, reset the board, and continue
* holding until the LEDs flash. Release, and reset again.
*/
#define MY_DEFAULT_HOST_NAME "MCHPBOARD"
#define MY_DEFAULT_MAC_BYTE1 (0x00) // Use the default of 00-04-A3-00-00-00
#define MY_DEFAULT_MAC_BYTE2 (0x04) // if using an ENCX24J600, MRF24WB0M, or
#define MY_DEFAULT_MAC_BYTE3 (0xA3) // PIC32MX6XX/7XX internal Ethernet
#define MY_DEFAULT_MAC_BYTE4 (0x00) // controller and wish to use the
#define MY_DEFAULT_MAC_BYTE5 (0x00) // internal factory programmed MAC
#define MY_DEFAULT_MAC_BYTE6 (0x00) // address instead.
#define MY_DEFAULT_IP_ADDR_BYTE1 (172ul)
#define MY_DEFAULT_IP_ADDR_BYTE2 (16ul)
//numéro de la salle 0 pour EN, 6 pour AU
#define MY_DEFAULT_IP_ADDR_BYTE3 (0ul)
//numéro de la carte PIC
#define MY_DEFAULT_IP_ADDR_BYTE4 (13ul)
#define MY_DEFAULT_MASK_BYTE1 (255ul)
#define MY_DEFAULT_MASK_BYTE2 (255ul)
#define MY_DEFAULT_MASK_BYTE3 (255ul)
#define MY_DEFAULT_MASK_BYTE4 (172ul)
#define MY_DEFAULT_GATE_BYTE1 MY_DEFAULT_IP_ADDR_BYTE1
#define MY_DEFAULT_GATE_BYTE2 MY_DEFAULT_IP_ADDR_BYTE2
#define MY_DEFAULT_GATE_BYTE3 MY_DEFAULT_IP_ADDR_BYTE3
// 34; pour le pc superviseur , un autre numero pour un pc étudiant
#define MY_DEFAULT_GATE_BYTE4 (34ul)
#define MY_DEFAULT_PRIMARY_DNS_BYTE1 (169ul)
#define MY_DEFAULT_PRIMARY_DNS_BYTE2 (254ul)
#define MY_DEFAULT_PRIMARY_DNS_BYTE3 (1ul)
#define MY_DEFAULT_PRIMARY_DNS_BYTE4 (1ul)
#define MY_DEFAULT_SECONDARY_DNS_BYTE1 (0ul)
#define MY_DEFAULT_SECONDARY_DNS_BYTE2 (0ul)
#define MY_DEFAULT_SECONDARY_DNS_BYTE3 (0ul)
#define MY_DEFAULT_SECONDARY_DNS_BYTE4 (0ul)
// =======================================================================
// PIC32MX7XX/6XX MAC Layer Options
// If not using a PIC32MX7XX/6XX device, ignore this section.
// =======================================================================
#define ETH_CFG_LINK 0 // set to 1 if you need to config the link to specific following parameters
// otherwise the default connection will be attempted
// depending on the selected PHY
#define ETH_CFG_AUTO 1 // use auto negotiation
#define ETH_CFG_10 1 // use/advertise 10 Mbps capability
#define ETH_CFG_100 1 // use/advertise 100 Mbps capability
#define ETH_CFG_HDUPLEX 1 // use/advertise half duplex capability
#define ETH_CFG_FDUPLEX 1 // use/advertise full duplex capability
#define ETH_CFG_AUTO_MDIX 1 // use/advertise auto MDIX capability
#define ETH_CFG_SWAP_MDIX 1 // use swapped MDIX. else normal MDIX
#define EMAC_TX_DESCRIPTORS 2 // number of the TX descriptors to be created
#define EMAC_RX_DESCRIPTORS 8 // number of the RX descriptors and RX buffers to be created
#define EMAC_RX_BUFF_SIZE 1536 // size of a RX buffer. should be multiple of 16
// this is the size of all receive buffers processed by the ETHC
// The size should be enough to accomodate any network received packet
// If the packets are larger, they will have to take multiple RX buffers
// The current implementation does not handle this situation right now and the packet is discarded.
// =======================================================================
// Transport Layer Options
// =======================================================================
/* Transport Layer Configuration
* The following low level modules are automatically enabled
* based on module selections above. If your custom module
* requires them otherwise, enable them here.
*/
//#define STACK_USE_TCP
//#define STACK_USE_UDP
/* Client Mode Configuration
* Uncomment following line if this stack will be used in CLIENT
* mode. In CLIENT mode, some functions specific to client operation
* are enabled.
*/
#define STACK_CLIENT_MODE
/* TCP Socket Memory Allocation
* TCP needs memory to buffer incoming and outgoing data. The
* amount and medium of storage can be allocated on a per-socket
* basis using the example below as a guide.
*/
// Allocate how much total RAM (in bytes) you want to allocate
// for use by your TCP TCBs, RX FIFOs, and TX FIFOs.
#define TCP_ETH_RAM_SIZE (0ul)
#define TCP_PIC_RAM_SIZE (16384ul)
#define TCP_SPI_RAM_SIZE (0ul)
#define TCP_SPI_RAM_BASE_ADDRESS (0x00)
// Define names of socket types
#define TCP_SOCKET_TYPES
#define TCP_PURPOSE_GENERIC_TCP_CLIENT 0
#define TCP_PURPOSE_GENERIC_TCP_SERVER 1
#define TCP_PURPOSE_TELNET 2
#define TCP_PURPOSE_FTP_COMMAND 3
#define TCP_PURPOSE_FTP_DATA 4
#define TCP_PURPOSE_TCP_PERFORMANCE_TX 5
#define TCP_PURPOSE_TCP_PERFORMANCE_RX 6
#define TCP_PURPOSE_UART_2_TCP_BRIDGE 7
#define TCP_PURPOSE_HTTP_SERVER 8
#define TCP_PURPOSE_DEFAULT 9
#define TCP_PURPOSE_BERKELEY_SERVER 10
#define TCP_PURPOSE_BERKELEY_CLIENT 11
#define END_OF_TCP_SOCKET_TYPES
#if defined(__TCP_C)
// Define what types of sockets are needed, how many of
// each to include, where their TCB, TX FIFO, and RX FIFO
// should be stored, and how big the RX and TX FIFOs should
// be. Making this initializer bigger or smaller defines
// how many total TCP sockets are available.
//
// Each socket requires up to 56 bytes of PIC RAM and
// 48+(TX FIFO size)+(RX FIFO size) bytes of TCP_*_RAM each.
//
// Note: The RX FIFO must be at least 1 byte in order to
// receive SYN and FIN messages required by TCP. The TX
// FIFO can be zero if desired.
#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},
//{TCP_PURPOSE_TELNET, TCP_PIC_RAM, 200, 150},
//{TCP_PURPOSE_FTP_COMMAND, TCP_PIC_RAM, 100, 40},
//{TCP_PURPOSE_FTP_DATA, TCP_PIC_RAM, 0, 128},
{TCP_PURPOSE_TCP_PERFORMANCE_TX, TCP_PIC_RAM, 2000, 1},
//{TCP_PURPOSE_TCP_PERFORMANCE_RX, TCP_PIC_RAM, 40, 2000},
{TCP_PURPOSE_UART_2_TCP_BRIDGE, TCP_PIC_RAM, 256, 256},
{TCP_PURPOSE_HTTP_SERVER, TCP_PIC_RAM, 1500, 1500},
{TCP_PURPOSE_HTTP_SERVER, TCP_PIC_RAM, 1500, 1500},
{TCP_PURPOSE_DEFAULT, TCP_PIC_RAM, 1000, 1000},
{TCP_PURPOSE_BERKELEY_SERVER, TCP_PIC_RAM, 25, 20},
//{TCP_PURPOSE_BERKELEY_SERVER, TCP_PIC_RAM, 25, 20},
//{TCP_PURPOSE_BERKELEY_SERVER, TCP_PIC_RAM, 25, 20},
//{TCP_PURPOSE_BERKELEY_CLIENT, TCP_PIC_RAM, 125, 100},
};
#define END_OF_TCP_CONFIGURATION
#endif
/* UDP Socket Configuration
* Define the maximum number of available UDP Sockets, and whether
* or not to include a checksum on packets being transmitted.
*/
#define MAX_UDP_SOCKETS (10u)
#define UDP_USE_TX_CHECKSUM // This slows UDP TX performance by nearly 50%, except when using the ENCX24J600 or PIC32MX6XX/7XX, which have a super fast DMA and incurs virtually no speed pentalty.
/* Berkeley API Sockets Configuration
* Note that each Berkeley socket internally uses one TCP or UDP socket
* defined by MAX_UDP_SOCKETS and the TCPSocketInitializer[] array.
* Therefore, this number MUST be less than or equal to MAX_UDP_SOCKETS + the
* number of TCP sockets defined by the TCPSocketInitializer[] array
* (i.e. sizeof(TCPSocketInitializer)/sizeof(TCPSocketInitializer[0])).
* This define has no effect if STACK_USE_BERKELEY_API is not defined and
* Berkeley Sockets are disabled. Set this value as low as your application
* requires to avoid waisting RAM.
*/
#define BSD_SOCKET_COUNT (5u)
// =======================================================================
// Application-Specific Options
// =======================================================================
// -- HTTP2 Server options -----------------------------------------------
// Maximum numbers of simultaneous HTTP connections allowed.
// Each connection consumes 2 bytes of RAM and a TCP socket
#define MAX_HTTP_CONNECTIONS (2u)
// Optional setting to use PIC RAM instead of Ethernet/Wi-Fi RAM for
// storing HTTP Connection Context variables (HTTP_CONN structure for each
// HTTP connection). Undefining this macro results in the Ethernet/Wi-Fi
// RAM being used (minimum PIC RAM usage, lower performance). Defining
// this macro results in PIC RAM getting used (higher performance, but uses
// PIC RAM). This option should not be enabled on PIC18 devices. The
// performance increase of having this option defined is only apparent when
// the HTTP server is servicing multiple connections simultaneously.
//#define HTTP_SAVE_CONTEXT_IN_PIC_RAM
// Indicate what file to serve when no specific one is requested
#define HTTP_DEFAULT_FILE "index.htm"
#define HTTPS_DEFAULT_FILE "index.htm"
#define HTTP_DEFAULT_LEN (10u) // For buffer overrun protection.
// Set to longest length of above two strings.
// Configure MPFS over HTTP updating
// Comment this line to disable updating via HTTP
#define HTTP_MPFS_UPLOAD "mpfsupload"
//#define HTTP_MPFS_UPLOAD_REQUIRES_AUTH // Require password for MPFS uploads
// Certain firewall and router combinations cause the MPFS2 Utility to fail
// when uploading. If this happens, comment out this definition.
// Define which HTTP modules to use
// If not using a specific module, comment it to save resources
#define HTTP_USE_POST // Enable POST support
#define HTTP_USE_COOKIES // Enable cookie support
#define HTTP_USE_AUTHENTICATION // Enable basic authentication support
//#define HTTP_NO_AUTH_WITHOUT_SSL // Uncomment to require SSL before requesting a password
// Define the listening port for the HTTP server
#define HTTP_PORT (80u)
// Define the listening port for the HTTPS server (if STACK_USE_SSL_SERVER is enabled)
#define HTTPS_PORT (443u)
// Define the maximum data length for reading cookie and GET/POST arguments (bytes)
#define HTTP_MAX_DATA_LEN (100u)
// Define the minimum number of bytes free in the TX FIFO before executing callbacks
#define HTTP_MIN_CALLBACK_FREE (16u)
#define STACK_USE_HTTP_APP_RECONFIG // Use the AppConfig web page in the Demo App (~2.5kb ROM, ~0b RAM)
#define STACK_USE_HTTP_MD5_DEMO // Use the MD5 Demo web page (~5kb ROM, ~160b RAM)
#define STACK_USE_HTTP_EMAIL_DEMO // Use the e-mail demo web page
// -- SSL Options --------------------------------------------------------
#define MAX_SSL_CONNECTIONS (2ul) // Maximum connections via SSL
#define MAX_SSL_SESSIONS (2ul) // Max # of cached SSL sessions
#define MAX_SSL_BUFFERS (4ul) // Max # of SSL buffers (2 per socket)
#define MAX_SSL_HASHES (5ul) // Max # of SSL hashes (2 per, plus 1 to avoid deadlock)
// Bits in SSL RSA key. This parameter is used for SSL sever
// connections only. The only valid value is 512 bits (768 and 1024
// bits do not work at this time). Note, however, that SSL client
// operations do currently work up to 1024 bit RSA key length.
#define SSL_RSA_KEY_SIZE (512ul)
// -- Telnet Options -----------------------------------------------------
// Number of simultaneously allowed Telnet sessions. Note that you
// must have an equal number of TCP_PURPOSE_TELNET type TCP sockets
// declared in the TCPSocketInitializer[] array above for multiple
// connections to work. If fewer sockets are available than this
// definition, then the the lesser of the two quantities will be the
// actual limit.
#define MAX_TELNET_CONNECTIONS (1u)
// Default local listening port for the Telnet server. Port 23 is the
// protocol default.
#define TELNET_PORT 23
// Default local listening port for the Telnet server when SSL secured.
// Port 992 is the telnets protocol default.
#define TELNETS_PORT 992
// Force all connecting clients to be SSL secured and connected via
// TELNETS_PORT. Connections on port TELNET_PORT will be ignored. If
// STACK_USE_SSL_SERVER is undefined, this entire setting is ignored
// (server will accept unsecured connections on TELNET_PORT and won't even
// listen on TELNETS_PORT).
//#define TELNET_REJECT_UNSECURED
// Default username and password required to login to the Telnet server.
#define TELNET_USERNAME "admin"
#define TELNET_PASSWORD "microchip"
// -- SNMP Options -------------------------------------------------------
// Comment following line if SNMP TRAP support is needed
//#define SNMP_TRAP_DISABLED
//#define SNMP_STACK_USE_V2_TRAP
#if defined(STACK_USE_SNMPV3_SERVER)
#define SNMP_V1_V2_TRAP_WITH_SNMPV3
#endif
// This is the maximum length for community string.
// Application must ensure that this length is observed.
// SNMP module adds one byte extra after SNMP_COMMUNITY_MAX_LEN
// for adding '\0' NULL character.
#define SNMP_COMMUNITY_MAX_LEN (8u)
#define SNMP_MAX_COMMUNITY_SUPPORT (3u)
#define NOTIFY_COMMUNITY_LEN (SNMP_COMMUNITY_MAX_LEN)
// Default SNMPv2C community names. These can be overridden at run time if
// alternate strings are present in external EEPROM or Flash (actual
// strings are stored in AppConfig.readCommunity[] and
// AppConfig.writeCommunity[] arrays). These strings are case sensitive.
// An empty string means disabled (not matchable).
// For application security, these default community names should not be
// used, but should all be disabled to force the end user to select unique
// community names. These defaults are provided only to make it easier to
// start development. Specifying more strings than
// SNMP_MAX_COMMUNITY_SUPPORT will result in the later strings being
// ignored (but still wasting program memory). Specifying fewer strings is
// legal, as long as at least one is present. A string larger than
// SNMP_COMMUNITY_MAX_LEN bytes will be ignored.
#define SNMP_READ_COMMUNITIES {"public", "read", ""}
#define END_OF_SNMP_READ_COMMUNITIES
#define SNMP_WRITE_COMMUNITIES {"private", "write", "public"}
#define END_OF_SNMP_WRITE_COMMUNITIES
#endif
#define __ETUDIANTSOCKETAPP_C
//il faut mettre cette définition avant tous les includes, car les .h y font référence
#define PIC32_STARTER_KIT
//inclusions d'entêtes de base
#include "TCPIPConfig.h"
#include "TCPIP_Stack/TCPIP.h"
#include "MainDemo.h" // Needed for SaveAppConfig() prototype
//2 sockets microchip
UDP_SOCKET udpsock; //utilisé pour l'émission depuis le pic
UDP_SOCKET udpsock2; //utilisé pour la réception depuis le pic
unsigned int nbtramesrecues = 0; //nombre de trames recues depuis le pc
DWORD tim = 0;
NODE_INFO myRemoteNode;
unsigned int compteuretudiant = 0;
int NUMERO_CARTE = MY_DEFAULT_IP_ADDR_BYTE4;
/////////////////////////////////////////////////////////
void etudiantSocketAppInit() { //adresse IP du pc avec lequel la carte pic communique
if (MY_DEFAULT_IP_ADDR_BYTE3==0)
DBPRINTF("configuration pour salle ER2EN\n");
else if (MY_DEFAULT_IP_ADDR_BYTE3==0)
DBPRINTF("configuration pour salle ER2AU\n");
else
DBPRINTF("configuration pour aucune salle :(\n");
myRemoteNode.IPAddr.v[0] = 172;
myRemoteNode.IPAddr.v[1] = 16;
myRemoteNode.IPAddr.v[2] = MY_DEFAULT_IP_ADDR_BYTE3; //0 pour EN, 6 pour AU
myRemoteNode.IPAddr.v[3] = MY_DEFAULT_GATE_BYTE4; // 34; pour le pc superviseur
char chaine[100];
sprintf(chaine, "IP du PC avec lequel la carte doit communiquer: %d.%d.%d.%d\n", myRemoteNode.IPAddr.v[0], myRemoteNode.IPAddr.v[1], myRemoteNode.IPAddr.v[2], myRemoteNode.IPAddr.v[3]);
DBPRINTF(chaine);
//adresse MAC du pc avec lequel la carte pic communique, déterminée par ARP
/*myRemoteNode.MACAddr.v[0] = 0xfe;
myRemoteNode.MACAddr.v[1] = 0x16;
myRemoteNode.MACAddr.v[2] = 0xf9;
myRemoteNode.MACAddr.v[3] = 0x03;
myRemoteNode.MACAddr.v[4] = 0x33;
myRemoteNode.MACAddr.v[5] = 0xa4;
*/
//ouverture de la socket en emission depuis le pic
//NE SURTOUT PAS FAIRE ICI SI l'ARP est activé, car on ne connait pas encore l'adresse MAC dans myRemoteNode
//udpsock=UDPOpen(30001+NUMERO_CARTE*10,&myRemoteNode, 30001+NUMERO_CARTE*10);
//ouverture de la socket en réception par le pic
udpsock2 = UDPOpen(30002 + NUMERO_CARTE * 10, NULL, 30002 + NUMERO_CARTE * 10);
sprintf(chaine, "BVDP: emission sur port %d, reception sur port %d\n", 30001 + NUMERO_CARTE * 10, 30002 + NUMERO_CARTE * 10);
DBPRINTF(chaine);
}
/////////////////////////////////////////////////////////
void etudiantSocketAppTask() {
unsigned int b1state, b2state, b3state; //3 variables représentant l'état des boutons
#define BVDPSOCKETAPP_TAILLE_BUFFER 100
char chaine[BVDPSOCKETAPP_TAILLE_BUFFER];
unsigned int nb = 0; //comptabilise le nombre d'octets envoyés ou reçus
//tim est utilisé ici pour avoir une execution périodique de la tâche
//La periodicité par seconde est définie par la constante BVDPSOCKETAPP_OCCURENCE_PAR_SEC
#define BVDPSOCKETAPP_OCCURENCE_PAR_SEC 1ul
if (TickGet() - tim >= TICK_SECOND / BVDPSOCKETAPP_OCCURENCE_PAR_SEC) {
tim = TickGet();
static int ARPstate = 0;
if (ARPstate == 0) {
sprintf(chaine, "ARPResolve adresse IP= %d.%d.%d.%d\n", myRemoteNode.IPAddr.v[0], myRemoteNode.IPAddr.v[1], myRemoteNode.IPAddr.v[2], myRemoteNode.IPAddr.v[3]);
DBPRINTF(chaine);
ARPResolve(& (myRemoteNode.IPAddr));
if (ARPIsResolved(& (myRemoteNode.IPAddr), & (myRemoteNode.MACAddr))) {
DBPRINTF("ARPIsResolved\n");
ARPstate = 1;
}
} else if (ARPstate == 1) {
sprintf(chaine, "ARP OK: adresse mac= %02x:%02x:%02x:%02x:%02x:%02x\n", myRemoteNode.MACAddr.v[0], myRemoteNode.MACAddr.v[1], myRemoteNode.MACAddr.v[2], myRemoteNode.MACAddr.v[3], myRemoteNode.MACAddr.v[4], myRemoteNode.MACAddr.v[5]);
DBPRINTF(chaine);
//ouverture de la socket en emission depuis le pic
udpsock = UDPOpen(30001 + NUMERO_CARTE * 10, &myRemoteNode, 30001 + NUMERO_CARTE * 10);
ARPstate = 2;
} else if (ARPstate == 2) {
//récupère l'état des boutons et les stocke dans des variables
b1state = (int) !PORTReadBits(IOPORT_D, BIT_6);
b2state = (int) !PORTReadBits(IOPORT_D, BIT_7);
b3state = (int) !PORTReadBits(IOPORT_D, BIT_13);
compteuretudiant++;
//génère une chaine de caractère à émettre
sprintf(chaine, "compteur= %6d b1:%d b2:%d b3:%d\n", compteuretudiant, b1state, b2state, b3state);
DBPRINTF(chaine);
if (UDPIsPutReady(udpsock) > strlen(chaine)) {
UDPPutArray((BYTE*)chaine, strlen(chaine));
UDPFlush();
}
}
}
//lit le nombre de caractères disponibles en réception
nb = UDPIsGetReady(udpsock2);
if (nb != 0) {
nbtramesrecues++;
sprintf(chaine, "Datagrame recu numero %d\n", nbtramesrecues);
DBPRINTF(chaine);
//lit ce nombre de caractères vers la variable chaine, en limitant nb à la taille de la chaine pour éviter d'écraser d'autres données
if (nb > BVDPSOCKETAPP_TAILLE_BUFFER)
nb = BVDPSOCKETAPP_TAILLE_BUFFER;
UDPGetArray((BYTE*)chaine, nb);
//pour un éventuel affichage des 6 premiers caractères de la chaine reçue dans la fenêtre debug
//chaine[6]=0; DBPRINTF("r: %s\n",chaine);
int i;
for (i = 0; i < nb; i++) {
if (chaine[i] == '0')
LED0_IO ^= 1;
if (chaine[i] == '1')
LED1_IO ^= 1;
if (chaine[i] == '2')
LED2_IO ^= 1;
}
}
}
#define MY_DEFAULT_IP_ADDR_BYTE1 (172ul)
#define MY_DEFAULT_IP_ADDR_BYTE2 (16ul)
#define MY_DEFAULT_IP_ADDR_BYTE3 (0ul)
#define MY_DEFAULT_IP_ADDR_BYTE4 (15ul)
il faut adapter l'ip et les numéros de ports:
set QTDIR=C:\applis\Qt\2010.01\qt
set PATH=C:\applis\Qt\2010.01\qt\bin
set PATH=%PATH%;C:\applis\Qt\2010.01\bin;C:\applis\Qt\2010.01\mingw\bin
set PATH=%PATH%;%SystemRoot%\System32
set QMAKESPEC=win32-g++
start socketqtbroadcastreceiver/broadcastreceiver 172.16.0.2 30041 30042 10 40 500 130
Solutions:
===réglages à faire pour la carte 104 en ER2AU:===
myRemoteNode.IPAddr.v[0] = 192;
myRemoteNode.IPAddr.v[1] = 168;
myRemoteNode.IPAddr.v[2] = 1;
myRemoteNode.IPAddr.v[3] = 201;
myRemoteNode.MACAddr.v[0] = 0x00;
myRemoteNode.MACAddr.v[1] = 0x50;
myRemoteNode.MACAddr.v[2] = 0x22;
myRemoteNode.MACAddr.v[3] = 0xB1;
myRemoteNode.MACAddr.v[4] = 0x08;
myRemoteNode.MACAddr.v[5] = 0xE9;
udpsock=UDPOpen(30041,&myRemoteNode, 30041);
udpsock2=UDPOpen(30042,NULL, 30042);
#define MY_DEFAULT_IP_ADDR_BYTE1 (192ul)
#define MY_DEFAULT_IP_ADDR_BYTE2 (168ul)
#define MY_DEFAULT_IP_ADDR_BYTE3 (1ul)
#define MY_DEFAULT_IP_ADDR_BYTE4 (104ul)
set QTDIR=C:\applis\Qt\2010.01\qt
set PATH=C:\applis\Qt\2010.01\qt\bin
set PATH=%PATH%;C:\applis\Qt\2010.01\bin;C:\applis\Qt\2010.01\mingw\bin
set PATH=%PATH%;%SystemRoot%\System32
set QMAKESPEC=win32-g++
start socketqtbroadcastreceiver/broadcastreceiver 192.168.1.104 27016 27017 10 40 500 130
start D:/qt/socketqtBertrandbroadcastreceiver/debug/broadcastreceiver 192.168.1.101 30011 30012 2 25 400 80
start D:/qt/socketqtBertrandbroadcastreceiver/debug/broadcastreceiver 192.168.1.103 30031 30032 2 135 400 80
start D:/qt/socketqtBertrandbroadcastreceiver/debug/broadcastreceiver 192.168.1.105 30051 30052 2 245 400 80
start D:/qt/socketqtBertrandbroadcastreceiver/debug/broadcastreceiver 192.168.1.107 30071 30072 2 355 400 80
start D:/qt/socketqtBertrandbroadcastreceiver/debug/broadcastreceiver 192.168.1.109 30091 30092 2 465 400 80
start D:/qt/socketqtBertrandbroadcastreceiver/debug/broadcastreceiver 192.168.1.111 30111 30112 2 575 400 80
start D:/qt/socketqtBertrandbroadcastreceiver/debug/broadcastreceiver 192.168.1.113 30131 30132 2 685 400 80
start D:/qt/socketqtBertrandbroadcastreceiver/debug/broadcastreceiver 192.168.1.115 30151 30152 2 685 400 80
start D:/qt/socketqtBertrandbroadcastreceiver/debug/broadcastreceiver 192.168.1.102 30021 30022 502 25 400 80
start D:/qt/socketqtBertrandbroadcastreceiver/debug/broadcastreceiver 192.168.1.104 30041 30042 502 135 400 80
start D:/qt/socketqtBertrandbroadcastreceiver/debug/broadcastreceiver 192.168.1.106 30061 30062 502 245 400 80
start D:/qt/socketqtBertrandbroadcastreceiver/debug/broadcastreceiver 192.168.1.108 30081 30082 502 355 400 80
start D:/qt/socketqtBertrandbroadcastreceiver/debug/broadcastreceiver 192.168.1.110 30101 30102 502 465 400 80
start D:/qt/socketqtBertrandbroadcastreceiver/debug/broadcastreceiver 192.168.1.112 30121 30122 502 575 400 80
start D:/qt/socketqtBertrandbroadcastreceiver/debug/broadcastreceiver 192.168.1.114 30141 30142 502 685 400 80
start D:/qt/socketqtBertrandbroadcastreceiver/debug/broadcastreceiver 192.168.1.116 30161 30162 2 685 400 80
===réglages à faire pour la carte 104 en ER2EN:===
#define MY_DEFAULT_IP_ADDR_BYTE1 (172ul)
#define MY_DEFAULT_IP_ADDR_BYTE2 (16ul)
#define MY_DEFAULT_IP_ADDR_BYTE3 (0ul)
#define MY_DEFAULT_IP_ADDR_BYTE4 (2ul)
il faut adapter l'ip et les numéros de ports:
set QTDIR=C:\applis\Qt\2010.01\qt
set PATH=C:\applis\Qt\2010.01\qt\bin
set PATH=%PATH%;C:\applis\Qt\2010.01\bin;C:\applis\Qt\2010.01\mingw\bin
set PATH=%PATH%;%SystemRoot%\System32
set QMAKESPEC=win32-g++
start socketqtbroadcastreceiver/broadcastreceiver 172.16.0.5 30041 30042 10 40 500 130
start D:/etudiants/socketqtbroadcastreceiver/broadcastreceiver 172.16.0.2 30011 30012 2 25 400 80
start D:/etudiants/socketqtbroadcastreceiver/broadcastreceiver 172.16.0.4 30031 30032 2 135 400 80
start D:/etudiants/socketqtbroadcastreceiver/broadcastreceiver 172.16.0.6 30051 30052 2 245 400 80
start D:/etudiants/socketqtbroadcastreceiver/broadcastreceiver 172.16.0.8 30071 30072 2 355 400 80
start D:/etudiants/socketqtbroadcastreceiver/broadcastreceiver 172.16.0.10 30091 30092 2 465 400 80
start D:/etudiants/socketqtbroadcastreceiver/broadcastreceiver 172.16.0.12 30111 30112 2 575 400 80
start D:/etudiants/socketqtbroadcastreceiver/broadcastreceiver 172.16.0.14 30131 30132 2 685 400 80
start D:/etudiants/socketqtbroadcastreceiver/broadcastreceiver 172.16.0.16 30151 30152 2 685 400 80
start D:/etudiants/socketqtbroadcastreceiver/broadcastreceiver 172.16.0.3 30021 30022 502 25 400 80
start D:/etudiants/socketqtbroadcastreceiver/broadcastreceiver 172.16.0.5 30041 30042 502 135 400 80
start D:/etudiants/socketqtbroadcastreceiver/broadcastreceiver 172.16.0.7 30061 30062 502 245 400 80
start D:/etudiants/socketqtbroadcastreceiver/broadcastreceiver 172.16.0.9 30081 30082 502 355 400 80
start D:/etudiants/socketqtbroadcastreceiver/broadcastreceiver 172.16.0.11 30101 30102 502 465 400 80
start D:/etudiants/socketqtbroadcastreceiver/broadcastreceiver 172.16.0.13 30121 30122 502 575 400 80
start D:/etudiants/socketqtbroadcastreceiver/broadcastreceiver 172.16.0.15 30141 30142 502 685 400 80
start D:/etudiants/socketqtbroadcastreceiver/broadcastreceiver 172.16.0.17 30161 30162 2 685 400 80
=====streaming audio via RTP=====
http://x.heurtebise.free.fr/Enseignements/ATER/LP/Streaming/PDF/Streaming_VLC.pdf
http://fr.wikipedia.org/wiki/Real-time_Transport_Protocol
http://en.wikipedia.org/wiki/Real-time_Transport_Protocol
http://en.wikipedia.org/wiki/Service_Access_Point
https://www.google.fr/search?q=vlc+sap&ie=utf-8&oe=utf-8&gws_rd=cr&ei=6T8BVb6IHcXjaKCVgLAP
http://pmonaco.blogspot.fr/2010/08/radio-privee-sur-freebox-avec-vlc.html
http://stackoverflow.com/questions/25125930/streaming-media-rtp-and-shoutcast
https://wiki.videolan.org/SAP
https://wiki.videolan.org/MiniSAPServer/
vlc input_stream
--
sout "#module1{
option1=parameter1{parameter
-
option1},option2=
parameter2}:module2{option1=...,option2=...}:..."
vlc -vvv mon_fichier.mp4 --sout #rtp{dst=ip_destination,port=1234,sdp=rtsp://ip_du_serveur:8500/S000_0}'
vlc -vvv jonathan_chirp.wav --sout #rtp{dst=127.0.0.1,port=1234,sdp=rtsp://ip_du_serveur:8500/S000_0}'
=====Manip Avec Arduino et Shield Ethernet=====
ATTENTION; les signaux passent par le connecteur à 6 broches, mettre la carte shield en contact avec l'uno et utiliser des spacers pour pouvoir ajouter des shields par dessus
En remplacement de la carte pic n1 avec IP 172.16.0.2
#include // needed for Arduino versions later than 0018
#include
#include // UDP library from: bjoern@cs.stanford.edu 12/30/2008
// Enter a MAC address and IP address for your controller below.
// The IP address will be dependent on your local network:
byte mac[] = {
0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED
};
IPAddress ip(172, 16, 0, 2);
unsigned int localPortEm = 30011;
unsigned int localPortRec = 30012;
// buffers for receiving and sending data
char packetBuffer[UDP_TX_PACKET_MAX_SIZE]; //buffer to hold incoming packet,
char ReplyBuffer[100] = "acknowledged"; // a string to send back
// An EthernetUDP instance to let us send and receive packets over UDP
EthernetUDP UdpRec;
EthernetUDP UdpEm;
IPAddress ipSuperviseur(172, 16, 0, 54);
int compteur = 0;
int b1state = 0;
int b2state = 0;
int b3state = 0;
unsigned long temps = 0;
unsigned long tempsold = 0;
void setup() {
// start the Ethernet and UDP:
Ethernet.begin(mac, ip);
UdpRec.begin(localPortRec);
UdpEm.begin(localPortEm);
Serial.begin(9600);
Serial.println("Début ");
}
void loop() {
Serial.print("l");
// if there's data available, read a packet
int packetSize = UdpRec.parsePacket();
if (packetSize)
{
Serial.print("Received packet of size ");
Serial.println(packetSize);
Serial.print("From ");
IPAddress remote = UdpRec.remoteIP();
for (int i = 0; i < 4; i++)
{
Serial.print(remote[i], DEC);
if (i < 3)
{
Serial.print(".");
}
}
Serial.print(", port ");
Serial.println(UdpRec.remotePort());
// read the packet into packetBufffer
UdpRec.read(packetBuffer, UDP_TX_PACKET_MAX_SIZE);
Serial.println("Contents:");
packetBuffer[packetSize]=0; //ajoute fin de chaine
Serial.println(packetBuffer);
switch (packetBuffer[0])
{
case '0':
Serial.println("led 0");
break;
case '1':
Serial.println("led 1");
break;
case '2':
Serial.println("led 2");
break;
default:
break;
}
}
temps = millis ();
if ((temps - tempsold) > 1000)
{
tempsold = temps;
sprintf(ReplyBuffer, "compteur= %6d b1:%d b2:%d b3:%d\n", compteur, b1state, b2state, b3state);
UdpEm.beginPacket(ipSuperviseur, localPortEm);
UdpEm.write(ReplyBuffer);
UdpEm.endPacket();
compteur++;
}
delay(10);
}
http://www.arduino.cc/en/Main/ArduinoEthernetShield
http://www.arduino.cc/en/uploads/Main/arduino-ethernet-shield-06-schematic.pdf
PB carte réseau machine TF_EN_E1
carte changée
ip addr ls
3: eth2: mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether e8:de:27:03:54:89 brd ff:ff:ff:ff:ff:ff
numérotée eth2 au lieu de eth1 à cause de la règle udev:
sudo nano /etc/udev/rules.d/70-persistent-net.rules
# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="54:04:a6:1d:27:84", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
# PCI device 0x10ec:0x8139 (8139too)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:22:b1:41:f6", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
# PCI device 0x10ec:0x8139 (8139too)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="e8:de:27:03:54:89", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"
il faut faire en sorte que la carte e8:de:27:03:54:89 soit nommée eth1
====Problème avec java qui indique qu'il faut faire mise à jour====
java.io.IOException: Permission non accordée
at java.io.UnixFileSystem.createFileExclusively(Native Method)
at java.io.File.createTempFile(File.java:2024)
at java.io.File.createTempFile(File.java:2070)
[catch] at org.netbeans.modules.remote.support.LocalFileSystemProvider.getRootFileSystem(LocalFileSystemProvider.java:127)
at org.netbeans.modules.remote.support.LocalFileSystemProvider.isMine(LocalFileSystemProvider.java:233)
at org.netbeans.modules.remote.spi.FileSystemProvider.normalizeAbsolutePath(FileSystemProvider.java:149)
at org.netbeans.modules.cnd.remote.fs.CndFileSystemProviderImpl.normalizeAbsolutePathImpl(CndFileSystemProviderImpl.java:134)
at org.netbeans.modules.cnd.spi.utils.CndFileSystemProvider$DefaultProvider.normalizeAbsolutePathImpl(CndFileSystemProvider.java:491)
at org.netbeans.modules.cnd.spi.utils.CndFileSystemProvider.normalizeAbsolutePath(CndFileSystemProvider.java:181)
at org.netbeans.modules.cnd.utils.cache.CndFileUtils.normalizeAbsolutePath(CndFileUtils.java:314)
at org.netbeans.modules.cnd.utils.FSPath.(FSPath.java:77)
at org.netbeans.modules.cnd.utils.FSPath.toFSPath(FSPath.java:66)
at org.netbeans.modules.cnd.modelimpl.csm.core.ModelImpl.findFile(ModelImpl.java:501)
at org.netbeans.modules.cnd.modelutil.CsmUtilities.getCsmFiles(CsmUtilities.java:500)
at org.netbeans.modules.cnd.modelutil.CsmUtilities.getCsmFile(CsmUtilities.java:545)
at org.netbeans.modules.cnd.modelutil.CsmUtilities.getCsmFile(CsmUtilities.java:356)
at org.netbeans.modules.cnd.highlight.semantic.MarkOccurrencesHighlighter.runImpl(MarkOccurrencesHighlighter.java:209)
at org.netbeans.modules.cnd.highlight.semantic.MarkOccurrencesHighlighter.run(MarkOccurrencesHighlighter.java:173)
at org.netbeans.modules.parsing.impl.TaskProcessor.callParserResultTask(TaskProcessor.java:573)
at org.netbeans.modules.parsing.impl.TaskProcessor$CompilationJob.run(TaskProcessor.java:744)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1423)
at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033)
dernier appel dans gedit /opt/microchip/mplabx/v3.61/mplab_ide/bin/mplab_ide
eval launchexec \
--jdkhome '"$jdkhome"' \
--clusters '"$mplab_ide_clusters"' \
-J-Dnetbeans.importclass=org.netbeans.upgrade.AutoUpgrade \
--branding mplab \
-J-Djava.io.tmpdir=/tmp/mplab_ide \
${default_options} \
'"$@"'
il stocke les paramètres dans /tmp/mplab_ide
ls -l /tmp
drwxr-xr-x 5 lsl2441a utilisateurs du domaine 4096 févr. 15 09:59 mplab_ide
alors que je suis loggé en ge2i
===Solution à faire à chaque login utilisateur==
cd /tmp
sudo mv mplab_ide mplab_ide.old