fichier de conf - C - Programmation
Marsh Posté le 30-06-2006 à 11:54:41
ham222 a écrit : j'ai fait un client et un serveur avec sockets tcp/ip (sous linux), et tout fonctionne mais je demande comment faire le fichier de configuration dans le serveur et qui permet de socker les @IP de clients permettant de charger ce fichier de conf au lieu de donner à chaque fois l'adresse du client. |
Un bête fichier texte... Ou un .ini... Si tu sais gérer les fichiers, c'est trivial...
Marsh Posté le 30-06-2006 à 18:48:05
Emmanuel Delahaye a écrit : Un bête fichier texte... Ou un .ini... Si tu sais gérer les fichiers, c'est trivial... |
Il serait peut-être intéressant de créer une librairie dédiée à la gestion de ce genre de fichier......
Marsh Posté le 30-06-2006 à 20:12:56
Sve@r a écrit : Il serait peut-être intéressant de créer une librairie dédiée à la gestion de ce genre de fichier...... |
http://mapage.noos.fr/emdel/clib.htm
Module INI...
Marsh Posté le 01-07-2006 à 11:00:56
On en viendrait preque à croire que C est productif.
Dis-moi Emmanuel, tu n'as jamais essayé de faire qq chose d'utile avec un autre langage que C ? Genre D ? Si ça se trouve, tu pourrais aimer ?
Marsh Posté le 01-07-2006 à 11:43:31
el muchacho a écrit : On en viendrait preque à croire que C est productif. |
J'ai principalement travaillé en embarqué, alors la question ne s'est jamais vraiment posée. Mais on fait de belles applications en C de 1 à 10 Mlignes...
Marsh Posté le 03-07-2006 à 07:52:37
Ouais, je suis d'accord. Jusqu'à 10 000 lignes, ça va. De 10 à 30 000, ça passe encore si on code pas trop dégueu, là où ça se complique, c'est au-delà de 30 000. Mais ça tombe bien, c'est au-dela de 10 000 lignes que les langages OO présentent de l'intérêt.
Marsh Posté le 03-07-2006 à 08:41:27
el muchacho a écrit : Ouais, je suis d'accord. Jusqu'à 10 000 lignes, ça va. De 10 à 30 000, ça passe encore si on code pas trop dégueu, là où ça se complique, c'est au-delà de 30 000. Mais ça tombe bien, c'est au-dela de 10 000 lignes que les langages OO présentent de l'intérêt. |
Deux réponses :
1 - En embarqué, on a pas trop le choix.
- Assembleur (non merci, j'ai déjà donné, 50 Klignes de MASM 51 Intel, ca ira comme ça)
- C (dispo à 99%)
- C++ (pas toujours disponible, usine à gaz...)
2 - J'écris en COO
http://mapage.noos.fr/emdel/clib.htm
Marsh Posté le 03-07-2006 à 10:23:11
bonjour M. Emmanuel
vous qui êtes specialiste de l'embarqué,en quoi un processeur est optimisé réseau? en fait je dispose d'une machine embarqué equipé du processeur MPC8560 de motorola basé sur PowerQUICC 3, on me dit que ce processeur est optimisé réseau et voila que j'ai parcouru toute la doc et le driver de mes cartes gigabits mais je ne vois pas de fonctions accelerateur. je veux savoir si la difference entre celle là et un processeur normal se limite à la frequence de traitement ?
merci.
Marsh Posté le 03-07-2006 à 11:12:51
ham222 a écrit : en quoi un processeur est optimisé réseau? en fait je dispose d'une machine embarqué |
Attention, ce n'est pas la machine qui est embarquée (une meilleure traduction de embedded est 'enfoui'), mais le programme...
Citation : |
C'est confus tout ça...
Le processeur est PowerPC. Le microcontôleur MPC8560 est basé sur le micro-processeur PowerPC et un processeur annexe RISC micro-programmable orienté réseau haut débit...
Citation : |
Si les drivers ont été conçus pour ce microcontrôleur, ils font déjà leur travail comme il faut. Les fonctions 'accelerateurs' sont dans le RISC.
Essaye de comprendre l'architecture du MPC8560 (PowerQUICC 3)...
Marsh Posté le 03-07-2006 à 11:41:23
Quant tu me dit processeur annexe RISC micro-programmable orienté réseau haut débit... , est ce que cela veut dire s'il traite rapidement les paquets rapidement tout seul sans programmation de ma part?
Et si ces fonctions accelerateurs sont dans le RISC, ça demande pas non plus de programmation.
En fait moi je dispose des modules noyaux qui font du traitement des paquets des flux RTP (SNAT) et je veux faire ce travail par le processeur (puisqu'il est optimisé réseau) au lieu du noyau. Je peux être trop vague dans mes expliactions, car c'est mon premier vrai projet de l'embarqué.
Marsh Posté le 03-07-2006 à 14:48:36
ham222 a écrit : Quant tu me dit processeur annexe RISC micro-programmable orienté réseau haut débit... , est ce que cela veut dire s'il traite rapidement les paquets rapidement tout seul sans programmation de ma part? |
Oui, c'est son boulot. La seule programmation requise est la configuration et l'établissement des liens physiques désirés. Ensuite, le traitement des trames (filtrage, routage) au niveau 2 et 3 est automatique. Si besoin est, un traitement vers les couches suéreires peut être implémenté dans le code du MPC (dans ce cas, on active l'interruption trame et on se branche dessus).
L'usage d'un PQ3, ça ne s'invente pas. Il y a une doc conséquente et des forums et/ou listes de diffusions spécialisés en anglais.
Citation : |
C'est pas un petit projet. Il faut comprendre comment fonctionne la couche réseau actuelle dans le noyau, comment fonctionne le PQ3 et faire les modifs qui vont avec. C'est pas trop un projet de débutant, ou alors avec un tuteur sur place qui sait ce qu'il faut faire...
Personnellement, je ne connais pas les détails. Il faut voir aussi si le microcode par défaut supporte RTP (connais pas) sinon, voir avec Freescale si il y a un microcode plus spécialisé... C'est peut être payant...
Marsh Posté le 03-07-2006 à 15:23:33
merci de votre aide tu m'apprends déjà beaucoup. Tu m'a donné la réponse à pas mal des choses, car j'ai passé plus de 2 semaines à étudier les code du driver gigabit du MPC8560 pour savoir ce qu'il capable de faire. pour moi la fonction de traitement des packets devait se trouver dans le driver de controleur gigabit. et finalement je n'ai rien vue et j'ai décidé de faire autrement:a savoir embarquer les modules noyaux (déja existant:car le produit que je veux embarquer dans la carte fonctionne mais tout est soft ) puis essayer d'optimiser en jouant sur les regidtres de configuartion.
Marsh Posté le 30-06-2006 à 11:37:59
j'ai fait un client et un serveur avec sockets tcp/ip (sous linux), et tout fonctionne mais je demande comment faire le fichier de configuration dans le serveur et qui permet de socker les @IP de clients permettant de charger ce fichier de conf au lieu de donner à chaque fois l'adresse du client.