De rien

De manière générale en programmation il y a de nombreuses manières de faire, mais toutes n'ont pas la même qualité... Au cas où tu ne connaitrais pas, tu peux regarder les tutoriaux du Site du Zero, je les trouve particulièrement bien faits et accessibles pour débuter. Par exemple : http://www.siteduzero.com/tutoriel-3-13993-la-programmation-modulaire.html

++

Stéphane (Snootlab) te l'a expliqué

Dans ton fichier d'entête (*.h), tu mets le prototype de la fonction :

Code:

int lireAniSimple(int , int , int , int , int );

Et dans le fichier source, l'implémentation, en gros le corps, les instructions exécutées par ta fonction :

Code:

int lireAniSimple(int Hanimation, int Hsortie, int Hplein, int Htempo, int Hi)
{
      //ta fonction
}

J'ai essayé de mettre les variables des fonctions en static, celles du sketch seront en volatile (utilisation d'une interruption).

En effet c'est normal que ça ne compile pas, le mot clé static s'utilise lors de la déclaration d'une variable, pas sur un argument de fonction...

++

Quelles variables as-tu essayé de mettre en static ? Les arguments de ta fonction ? Je pensais à celles déclarées dans ton sketch...

Par contre je crois comprendre que tu as des implémentations de fonctions dans animations.h !? Si oui c'est à proscrire : le fichier d'entête (*.h) constitue l'API de ta bibliothèque (prototypes de fonctions, etc) alors que le fichier source (*.c ou *.cpp) en contient l'implémentation.

++

De rien PapyDuino  En effet tu peux mettre un extrait de code dans le corps de ton message et joindre ton fichier en plus, c'est certainement plus lisible pour un code conséquent...

++

Salut,

Tu peux aussi joindre ton fichier source à ton message. Dans la fenêtre de rédaction, si tu déplies Additional Options tu trouveras un champ pour le faire...

Salut,

Je suis d'accord avec Snootlab concernant le nom des variables. Par contre on n'a parfois pas le choix et deux variables ont le même nom. Dans ce cas il faut réduire leur portée à l'aide du mot clé static à défaut de pouvoir les mettre en private dans le sketch. Par exemple :

Code:

static int i = 0;

Dans ton exemple, il est même possible de pousser plus loin puisque la variable i n'est utilisée que dans la fonction loop :

Code:

void loop(){
    static int i = 0;
    // ...
}

++

Salut,

Pour delay et de nombreuses autres fonctions des bibliothèques Arduino il faut inclure WProgram.h

++

La taille du tableau "trame" n'est pas suffisante, dans le pire des cas la chaîne dépasse les 12 caractères

cos(Theta)*1000 entier ne peut pas faire plus que 5 caractères (-1000) *3 =15 + 2';' = 17 caractères.
Dans ce cas, Trame[16] devrait suffire, ou je me trompe?

Là tu n'accordes que 16 octets. Hors tu peux avoir au maximum 17 octets + le caractère de fin de chaîne '\0'. Donc il te faut Trame[18]...

Le compilateur lève juste un warning, mais comme l'IDE Arduino compile avec l'option -w tu ne l'as pas vu :

On peut changer cette option, où bien il faut compiler avec gcc?

Je ne sais pas si on peut changer les flags de compilation tout en conservant l'IDE Arduino, en tout cas je n'ai pas trouvé...

Le compilateur lève juste un warning, mais comme l'IDE Arduino compile avec l'option -w tu ne l'as pas vu :

format '%d' expects type 'int', but argument 4 has type 'long int'

PS : n'oublie pas d'ajuster la taille de ton tableau...

Salut,

La taille du tableau "trame" n'est pas suffisante, dans le pire des cas la chaîne dépasse les 12 caractères. Il faut donc dimensionner correctement le tableau. Ensuite l'utilisation de sprintf ne prenant pas en compte la taille, la mémoire est corrompue. Pour plus de sécurité, il faut privilégier l'utilisation de snprintf.

Enfin comme l'écrit Skywodd, il est préférable d'utiliser des %ld pour formater les valeurs...

++

Salut,

A priori c'est la ligne

Code:

setSyncProvider(RTC.get);

qui ne va pas, l'argument RTC.get  n'est pas du type attendu par la méthode setSyncProvider.

Quelle bibliothèque utilises-tu ? Quelle-est l'API de la méthode setSyncProvider ?

++

L'aspect coût est une chose. Mais selon les systèmes, il peut être nécessaire de limiter le nombre de connexions GPRS pour économiser du temps CPU et de l'énergie. A voir si c'est un critère pour Promete...

A l'heure actuelle chaque connexion gprs coûte encore assez cher en France et il semble y avoir des coûts fixes liés aux headers, etc... Il semble plus économique de faire moins de transmissions avec des fichiers un poil plus gros.

En effet, c'est cher, long et ça consomme énormément d'énergie (du moins par rapport aux autres fonctions).

Coté stockage j'imaginais volontiers un carte SD, cela ne coute plus grand chose (hardware et carte), ou sur clé USB ?

En prenant un microcontrôleur suffisamment gros tu fais l'économie d'une mémoire externe. Mais si justement tu ajoutes un support externe, un Atmega328 suffira... A toi de faire le choix  Quelque soit le support, le problème du nombre de cycles d'écriture se posera. Toute mémoire lâchera un jour ou l'autre, mais en choisissant bien, la station météo aura été remplacée avant que ça n'arrive... Et puis plusieurs solutions sont envisageables pour réduire les écritures en mémoire...

Coté technique, la plupart des capteurs identifiés retournent une valeur en tension (0-1V) ou courant (4-20mA). La conversion en valeur se fait au travers d'une équation linéaire, voire polynomiale. Je ne pense pas que les quelques conversions à faire toutes les minutes (disons 5-6 capteurs par station type) soient insurmontable pour une seule UNO.

Pour ça en effet l'Atmega328 de l'Arduino Uno fera l'affaire.

Ainsi 1 capteur génère 2-3 variables par horodatage dans le fichier. Avec 5-6 capteurs, on parle de 15 valeurs par ligne de fichier, soit 180 valeurs par heure, soit 4320 valeurs par jour soit un fichier d'environ 40 ko. Sachant qu'à l'heure actuelle, la plupart de nos clients ne retiennent qu'une valeur par heure soit des fichiers journaliers de 4-5 ko.

3-4 fois par jour, la station transfère son fichier vers le serveur via gprs, ethernet, wifi,...

C'est là qu'est ma crainte concernant la mémoire, dans le pire cas avec les volumes de données les plus importants... Où comptes-tu stocker tes données ?

Pour pouvoir être affirmatif il faudrait avoir beaucoup plus de billes. Pour ma supposition, je me base sur mon expérience. Je bosse sur une plateforme similaire, en terme d'architecture, à ce que fait ou veux faire Promete.

Dans le cas du système d'acquisition de données météo, il faudra gérer la communication avec les capteurs, stocker les mesures avant de les transmettre, etc... Tout dépend du volume de données, de la fréquence des acquisitions, du nombre de capteurs, etc...

Au sujet des consultants, je ne pense pas qu'il y en ait beaucoup à être "spécialiste Arduino", mais en élargissant aux consultants en informatique industrielle / systèmes temps réel tu devrais trouver ton bonheur. Outre la CCI, tu peux peut-être te renseigner auprès de réseaux comme le Réseau Entreprendre. Le plus souvent ils sont en relations avec des consultants ou bureaux d'études.