alors jai une question mon sinus est pas mal quand je le regarde sous excel voir même bien jusqu'à 200hz
seulement toutes les 4 périodes on a une perte et je sais pas ce qui peux engendré cette perte c'est quand même étrange... je peux te montrer la courbe ?
voila l'image
alors j'ai pensé que c'était car mon programme n'était pas dans une interruption ou n'a pas une priorité suffisante j'ai pour objectif de le déclencher sur interruption aujourd'hui
j'ai modifier les registres :
sbi(ADCSRA, ADPS2);
sbi(ADCSRA, ADPS1);
sbi(ADCSRA, ADPS0);
mais en gros ca change rien le problème ne vient pas de l'adc
j'ai encore un doute sur mon flush de fin de programme c'est peut être lui qui crée ca on peut remplacé la commande flush par autre chose ?
ps: pour information mon signal GBF arrive sur une résistance de 1K entre la pin A et la la masse.
Peut-être qu'en mettant le programme dont tu parles on comprendrait mieux.
Mettez votre code actuel:
je crois que vous faites encore une conversion en float, qui prend du temps (surtout à écrire en ASCII), de la place sur la SD(1 ou 2 cars) et qu'excel fait mieux et plus vite.
votre flush est aussi simple à retirer (un close suffit, à la fin) ne serait ce que pour le remettre (simple à expérimenter)
il y a peut être autre chose à retirer ou accélérer (en aveugle, on ne sait pas)
Si vous voulez passer à un mode interruption, vous consommerez plus de cycles : l'appel et le retour de l'ISR + la gestion des mécanismes de synchronisation: si votre code n'est pas déjà très rapide, vous croirez résoudre un problème mais vous le complexifierez.
Artouste vous a lié vers un exemple tout fait qui gère un nombre paramétrable de voies, écrit en binaire sur la carte (très rapide...) et transmet par la jonction série le contenu de ce fichier à la demande.
Vous avez donc le choix entre le prendre tel quel, avec >= 800 lignes , l'adapter à une voie et vivre très heureux (je pense, à la lecture du source), mais un peu frustré de ne pas avoir testé vous même ou essayer d'évoluer progressivement vers quelque chose de plus simple, que vous comprendrez...
#include <SPI.h> // Pour la communication SPI
#include <SD.h> // Pour la communication avec la carte SD
const byte chipSelect =4;
const char* output_data = "datalog.txt";
int compteurtrain;
byte FLAGTrain ;
float voltage;
#ifndef cbi
#define cbi(sfr, bit) (_SFR_BYTE(sfr) &= ~_BV(bit))
#endif
#ifndef sbi
#define sbi(sfr, bit) (_SFR_BYTE(sfr) |= _BV(bit))
#endif
const unsigned long DBM = 1;
unsigned long Temps;
int D2 =2;
File dataFile;
void setup()
{
int32_t Timebufout=0;
SPI.setClockDivider(SPI_CLOCK_DIV2); // augmente la vitesse du bus SPI
sbi(ADCSRA, ADPS2); // division par 16 sur l'adc
cbi(ADCSRA, ADPS1);
cbi(ADCSRA, ADPS0);
compteurtrain=0;
FLAGTrain=0; // mise a Zero du flag
//Serial.begin(2000000);
/*Initialisation il y a un train*/
pinMode(0, INPUT); // entrée de déclenchement pour enregistrement coordonnée avec le FLAG
/*Initialisation SPI*/
pinMode(10, OUTPUT); // Arduino UNO
/*test initialisation SDCARD*/
if (!SD.begin(chipSelect))
{
Serial.println("Card failed, or not present");
return;
}
Serial.println("card initialized.");
dataFile = SD.open("datalog.txt", FILE_WRITE);
}
/*fonction de boucle*/
void loop()
{
FLAGTrain=digitalRead(D2);
if ( FLAGTrain == 1) // pour ma futur entrée sur interruption
{
compteurtrain=compteurtrain+1;
dataFile.println("");
dataFile.print("****************objet N°");
dataFile.print(compteurtrain);
dataFile.println("****************");
dataFile.println("");
for(int t=1; t < 10000 ; t++)
{
//int32_t Time=micros();
int ADCTension = analogRead(A0); // déclaration de "ADCTension" qui prend la valeur de A0.
//float Tension = ADCTension*(5.0/1023.0); // déclaration de "Tension" avec convertion en Volt.
dataFile.println(ADCTension);
//dataFile.print(" - ");
//dataFile.println(Time);
}
}
dataFile.flush();
}
dbrion06:
je crois que vous faites encore une conversion en float, qui prend du temps (surtout à écrire en ASCII), de la place sur la SD(1 ou 2 cars) et qu'excel fait mieux et plus vite.
je ne souhaite pas utilisé le pc avec excel car je veux un système d'enregistrement autonome en milieu isolé.
l'exemple dont tu parle je le trouve pas... je vais regardé en arrière ....
mais tu sais je suis pas la pour embêter je veux juste apprendre et comprendre vous parlez de beaucoup de chose comme si c'était banale et moi je m'accroche derrière pour digérer chaque mot ... On peut être indulgent non? sans te vexé ... j'ai besoin plus de vous que vous de moi ... dans les fait. je suis pas la pour vous embêter mais pour me remettre dans une matière très immersive .
Pour vos essais:
mettez le code gérant le SD et l'analog à la fin du setup; arrêtez -et FERMEZ, par close() - quand le nombre de lignes souhaité est rempli; à ce stade, le fichier est disponible, rempli comme souhaité -et vous n'avez pas besoin de faire un flush toutes les 2 millisecondes: il force, comme le close, une écriture physique : ceci m'est confirmé par SD - Arduino Reference
A noter que des écritures physiques répéteées sur une carte SD sont potentiellement nuisibles (usure prématurée) et ralentissent (un sync, qui est un équivalent fonctionnel généralisé à tous les fichiers ouverts, peut prendre des minutes....)
Votre choix de SD au lieu de SDFat n'est pas judicieux: SDFat a le même mode d'emploi -pas de code à réécrire- , mais étend les foctionnalités.
Artouste vous a lié un exemple livré avec SDFat qui a tout -et plus - ce qu'il vous faut. -et je l'en remercie, ainsi que mon vendeur de SDs- : gestion du temps, gestion d'un buffer circulaire, gestion de la SD, transmission sans l'arracher vers le PC...
Si je vous dis de mettre tout en setup, c'est que vous êtes sur qu'un fichier ne sera écrit qu'une fois, bien comme il faut et que loop peut être employé utilement, soit à ne rien faire (pas d'écritures répétées lors d'essais), soit, en clignotant des LEDs, vous signaler que c'est fini...
" l'ASCII est plus rapide ? du fait qu'il propage moins de bit pour écrire une information ? "
L'ASCII est ce qui se fait de plus lent:
un octet nécessite , avec les formats lisibles usuels, l'écriture/ la transmission de 3 octets en décimal (jusqu'à 255); 2 octets en hexadecimal (est encore lisible). Et j'ai oublié le signe, qui rajoute un caractère (-127...)
Si vous avez des réels -floats- , et que vous les stockiez/transmettiez en ASCII, vous allez faire dépenser beaucoup de temps (au vu des cadences infernales souhaitées- à transmettre une information dégradée (vous mettez deux chiffres après le séparateur décimal- ex: 3.14- que se passe-t-il si la vraie conversion vous a donné 3.142? Il est bien un peu dégradé?
C'est le binaire qui est le plus rapide (mais le moins fiable et un être humain ne peut pas le lire.... à moins d'^tre heroique, stoîque et très patient, le temps passé à le décoder par un humain est il judicieusement dépensé)...
et le plus économe en stockage : on stocke/transmet un octet tel qu'il est.
"l'exemple dont tu parles je ne m'en rappel pas "
C'est le post 9 en toute première lecture, il me semble parfait... et j'aurai besoin de SD dans quelques semaines.
"et jai pas mal expérimenté..."
Il n'y a pas de mal à expérimenter, mais il faut faire une expérience à la fois, comprendre pourquoi elle est satisfaisante ou pas -et c'est plus interessant pour vos lecteurs que d'avoir un énorme produit mal fini-, être sûr que cette expérience servira à votre projet, et ne continuer que si vous avez compris (surtout si, comme je crois, vous avez une solution toute faite, grâce à Artouste, vous dispensant de l'inquiétude liée au risque qu'un projet n'aboutisse pas.
OUI je comprend j'ai regardé le code en binaire j'y ai rien compris ^^ et
je suis parti un peux dans tout les sens aussi en voulant bien faire, j'ai lu navigué sur divers site en essayant de trouvé des solution aléatoirement.
Bon si tu acceptes toujours de m'aider je fais quoi je mets le bout de code que j'ai a la poubelle et je pars de 0?
si je dois le reprendre car on peut en faire quelque chose il me semble logique de redéfinir son utilité a tes yeux histoire qu'on sache si on est sur la bonne voie.
Nous avons un système autonome sur batterie qui enregistre les vibrations du sol via un accéléromètre quand un train passe a proximité avec le temps entre chaque sample (le passage d'un train dure 8s).
On dois faire plusieurs mesures car plusieurs train par jour.
pour ne pas enregistré en permanence j'ai doublé la voie de l’accéléromètre avec un aop qui sature le signal et le bloque a 5v se qui fait un jolie signal de 0-5v prévenant de l'arrivé du train et qui va me servir a déclencher l'enregistrement sur interruption via la voie D2.
a l'aide d'un oscilloscope j'ai vue que les fréquence qui m'interresse sont entre 0-400hz mais les principal entre 0-200hz et je suis preneur de la fréquence de sample la plus élevé possible mais qui fait le travail
Voila pour ca
dit moi ton avis je refait tout ou je peux m'en sortir je ne connais que le C l'assembleur sa remonte a 15ans le vhdl a 4ans
si je prend la solution a artouste peut tu m'aider a la comprendre et la modifier ?
Avez vous des délais à tenir ou des engagements?
si oui, la solution d'Artouste peut être vue comme une belle boîte noire clés en main, avec des chances de fonctionner non liées à la bonne volontés d'autres personnes (qui peuvent tomber malades, avoir des engagements, essayer de règler des problèmes d'amis, etc...)
sinon, développer soi même est la meilleure solution pour apprendre ... à son rythme, en sériant les problèmes.
Je vais me placer dans la première hypothèse:
il y a une ligne à modifier(no 15),
const uint8_t PIN_LIST[] = {0, 1, 2, 3, 4};
(le nombre de pattes à gérer en est déduit, en première lecture, très proprement.
et une autre ligne qui correspond à la cadence d'échantillonnage (no 33)
// Sample rate in samples per second.
const float SAMPLE_RATE = 5000; // Must be 0.25 or greater.
Je suis à peu près sûr qu'il stocke tel quel, sans la moindre operation (peut être faut il faire la conversion au dépouillement, en temps différé....)
Il assure automatiquement la renumerotation des fichiers...jusqu'à 99 (lignes 696)
le nom des fichiers est fixé ligne 76
Tout ça , c'esr séduisant
Ce qui l'est moins, c'est ça :
#if RAMEND < 0X8FF
#error
#endif
(sur un arduino uno, c'est inquietant -pour le librairie ou pour moi); un arduino mega 2560 a ce qu'il faut (et plus il a de buffers, plus il est rapide)
Il a besoin d'une liaison serie (pour déclencher le log, convertir son fichier binaire en csv, ou transmettre les données sur la jonction série; les appels à Serial sont un peu partout, ceux où il dialogue (on peut très bien emettre "en l'air") sont assez localisés.
Dans une première étape -5000 échantillons /seconde: cela fait 1E4 octets à stocker en binaire; par jour, cela fait 1E5*1E4 1 Giga: ce n'est pas délirant de stocker tout, le temps que les commandes soient modifiées...
Toute la logique du loop est à adapter (en gros, il enregistre ou convertit les binaires en csv)
Je pencherais toujours vers la modification de cet exemple.... en le testant tel quel, et en lui ôtant lentement des fonctionnalités
Je vais te posé les questions à la suite :
j'ai un problème de compilation qui est du à la pièce rapporté AnalogBinLogger.h
je l'ai bêtement copier coller dans le même dossier mais sa mets No such file or directory
pour la ligne 30 je comprend que c'est les pin analogique de la carte que je dois utilisé j'ai mis pour A0:
const uint8_t PIN_LIST[] = {0};
Ligne 87 jai mis :
// SD chip select pin.
const uint8_t SD_CS_PIN = 4;
"j'ai un problème de compilation qui est du à la pièce rapporté AnalogBinLogger.h "
Il faut le mettre dans le même dossier, l'invoquer avec des "" -pas des chevrons < > -(et il apparaîtra comme un onglet supplémentaire: si il n'apparaît pas, c'est qu'il y a un problème). La version pour PC (sert à décoder les binaires; dans extras) ou RPi se compile très bien sur un PC -mais je n'ai pas les fichiers binaires ad hoc pour vérifier complètement son fonctionnement-
Quel est le message d'horreur? (je ne peux pas imaginer toutes les sources d'erreur)
Le reste du paramètrage m'a l'air bon....(compatible avec vos codes précédents; le numero de ligne suggèrerait que nous avons la même source...)
L'auteur recommande, dans les readme:
d'utiliser un arduino >= 1.6.x
d'utiliser un arduino mega -pour des problèmes de vitesse , liés aux buffers-
Pour votre info : j'ai accès à l'ide arduino (voire au materiel) uniquement le week end et je ne peux qu'utiliser ma tête et un PC le reste du temps...
il est invoquer comme cela ca me semble bien comme tu l'as precisié :
#include "AnalogBinLogger.h"
quand j'ouvre le analogbinder.ino ca ouvre aussi le point .h ca me fait deux onglet sur la même fenêtre il le trouve donc bien.
le code erreur
nalogBinLogger:26:29: error: AnalogBinLogger.h: No such file or directory
compilation terminated.
exit status 1
AnalogBinLogger.h: No such file or directory
c'est peut être sur la ligne d'avant que ca coince
#include "FreeStack.h"
je ne trouve le dossier .h nul part et je ne trouvé aucune bibliothèque associé.
j'ai installé un bibli SdFat par contre qui était signé au nom de l'auteur "greiman"
pour l'instant je ne dispose que d'une uno en dernière version soit 1.8.9.
Alors j'ai utilisé l'exemple de la librairie que j'ai télécharger sur ide qui est le même et ca marche je comprend pas...
je test le programme en se moment
Votre diagnostic est correct, pour autant que je puisse en juger: c'est bien FreeStack.h qui manque
Il est dans xxx/SDFAT/src/
Vous avez le choix entre 2 choses, soit le copier dans le répertoire courant (vous mettant un onglet de plus), soit de l'invoquer avec des chevrons < >, vous faisant bénéficier d'éventuelles mises à jour de SDfat...
Votre arduino 1.8.9 n'a jamais soulevé l'indignation des foules , et je suis satisfait de sa version (je peux être pinailleur sur les origines et les numérotations des sources, parce que c'est une source -parmi d'autres, en grand nombre- de malentendus et de quiproquos)
je fais des testes ca se passe bien je pense je vais le laissé en enregistrement sur 5 jours et récolter mes résultat après.
du coup je vais avoir le temps de faire mieux par moi même mais il est clair que au vue des premiers résultat je n'était pas sur la bonne voie... et je suis content de ne pas avoir persévérer même si ça me fait un peux mal de l’admettre.
je vais essayer de modifier ce programme déjà pour comprendre ce qu'il réalise et voir comment il est si rapide. Puis je me lancerai sur le miens car ce projet n'est pas fini mais dison que la je n'aurai plus le stresse d'une date butoirs et je vais mieux m'organisé. je te remercie et je vais surement te sollicité encore un peux.
en faite je m'éclate énormément 
j'aurai jamais du m'éloigner de la programmation pour faire de l’électronique analogique en faite j'aime les 2.
Avez vous fait des calculs de volume?
Vous étiez sur la bonne voie; cependant, il faut voir que vous avez un employeur et considérer le risque de contagion de mauvaises habitudes (aller butiner sur l'étrange toile des trucs qui marchent et qui peuvent être mal écrits est de plus en plus à la mode -et j'en participe- ; mieux vaudrait, à mon sens, admirer un code qui est complexe, mais bien commenté et assez structuré que de commencer à écrire à la va vite, sous diverses pressions).
A noter que ce code ne peut fonctionner (excusez du peu) "qu"'avec des avr-s -et un mega2560 serait très confortable : le gain de temps peut amplement justifier l'achat d'un arduino plein de pattes) -; si pour diverses raisons (transmettre sans fil des données... rupture de stocks ... baisse de prix) vous voulez changer de type d'arduino, ce sera un peu plus compliqué qu'un code simple commis par soi même...
je viens de voir que le code ma générer un fichier de 80mo pour 1h d'enregistrement donc 2go par 24h soit sur 5jour un fichier 10go
Le hic c'est que excel ne l'a pa supporté sur 1 h alors sur 5jours n'en parlons pas...
Meme mathlab a dit over-range
ca va être compliqué mais il faudrait crée un dossier n+1 tout les x nombres de point.
je vais faire une sauvegarde du code et commencé a le modifier.
Vous pouvez découper cet henaurme fichier sur un PC, ou au moins en visualiser le contenu, en adaptant les fichiers de sdfat/extras/AnalogBinLoggerExtras/ (si votre PC a un compilateur C, sous windows, ce n'est pas évident...)
gnuplot est très bien (à la fois léger et OS agnostic ) Cependant, dans certains environnements informatiques professionnels, il faut passer par un tyranneau système pour l'installer -faut pas le dire comme ça si on veut un poste de travail confortable, je suppose: on dit un sys ad: admlinistrateur système - au même titre qu'un compilateur C...
Il y a un autre point bloquant: même si on arrive à le tronçonner (ce n'est pas compliqué avec les programmes extras livrés avec SdFat), il ne faut pas oublier (et je parie que le posteur originel le saura, d'une façon ou d'une autre) que la taille maxi de la FAT32, pour un fichier donné, est de 4 G . FAT32 — Wikipédia m'a confirmé des souvenirs desagréables
Ceci confirme que le choix d'enregistrer à la demande (et seulement à la demande, avec une patte mise à 1) est un choix prioritaire.