Go Down

Topic: Choix modèle Arduino (Read 336 times) previous topic - next topic

frantzgac

Bonjour
J'ai débuté avec une Arduino Uno sur laquelle j'ai fait quelques tests concluants avec notamment un capteur de température.
Je voudrais maintenant réaliser un capteur de mouvement permettant de mémoriser 1h30 de déplacement pour une application médico sportive.
J'envisage d'utiliser une carte Arduino Due puisque cette carte embarque 512Kb de mémoire flash ce qui devrait suffire.
Ma question : est-ce que la mémoire flash de cette carte se remet à zéro si la carte est désalimentée.
Selon wikipedia une "mémoire flash" ne s'efface que si on la remet à zéro explicitement comme une EEPROM. Est-ce le cas de celle de la "Due"
Merci

J-M-L

Ecrire dans la mémoire flash depuis votre programme est plutôt compliqué à cause de l'architecture matérielle sur un UNO. Sur un DUE j'ai jamais essayé.

Si vous prenez un "arduino" à base d'ESP, genre Wemos D1 vous pourrez alors utiliser le SPIFFS (SPI Flash Filing System) pour y écrire et ce sera persistant. les APIs sont simples et ressemble à de l'accès fichier



Please do not PM me for help,  others will benefit as well if you post your question publicly on the forums
Pas de messages privés SVP

Christian_R

La mémoire flash conserve le code Arduino hors tension, les variables en mémoire vive sont effacées, celles écrites en flash sont gardées.

La zone mémoire est partagée entre code et data, et le nombre de réinscriptions des cellules de mémoire flash est limité (mais largement élevé).

Une carte SD avec un lecteur est une bonne alternative, c'est possible sur toutes les cartes arduino.
Christian

J-M-L

#3
Jun 14, 2018, 09:21 pm Last Edit: Jun 14, 2018, 09:23 pm by J-M-L
Une carte SD avec un lecteur est une bonne alternative, c'est possible sur toutes les cartes arduino.
oui mais quitte à acheter une carte, le wemos D1 par exemple pour ~3 euros sur eBay en chine va lui donner un processeur performant et 4M de flash avec un système de fichier simple à utiliser... pas de fils à brancher pour rajouter une carte SD à un UNO et bcp moins cher au final (le Wemos coûtera sans doute moins cher que juste la carte SD, sans parler du reste)...(et une interface wifi  en plus)
Please do not PM me for help,  others will benefit as well if you post your question publicly on the forums
Pas de messages privés SVP

_pepe_

#4
Jun 14, 2018, 10:14 pm Last Edit: Jun 14, 2018, 10:52 pm by _pepe_
Bonsoir

À titre d'information, on trouve par ici une bibliothèque permettant d'écrire dans la mémoire Flash de l'Arduino Due.


Sinon, on trouve dans le commerce des modules de mémoire EEPROM avec interface I2C bon marché (par exemple à base de 24C512 contenant 64Ko organisés en blocs de 128 octets) dont on peut éventuellement utiliser plusieurs exemplaires pour augmenter la capacité (par exemple jusqu'à 512Ko avec 8 modules 24C512). Leur intérêt est de pouvoir réaliser des dataloggers avec de petits Arduinos AVR (Uno, Pro Mini, « standalone », ...) en évitant le recours à une carte SD dont la mise en œuvre est plus compliquée et plus coûteuse en ressources (système de fichiers, blocs de 512 octets, latence aléatoire, ...).

windaube21

bonjour

la question est que 512kb n'est pas de trop ?

dans l'eeprom il y a de quoi faire et au pire il y a des eeprom externe qui sont relativement facile a faire fonctionné

et avec un code relativement simple on peut lui faire cracher tout le contenue de l'eeprom dans le serial 

ard_newbie

Comme déjà indiqué, la bibliothèque DueFlashStorage permet d'écrire dans la Flash (et bien entendu la Flash ne s'efface pas après une coupure d'alimentation). Cependant, le nombre d'écritures sur un octet de Flash est probablement de l'ordre de 100000 mais pas plusieurs millions, donc la fréquence des mises à jour est à regarder de près.

A noter que des gens "rusés" se sont souvenus que sur une carte DUE il y a un 16U2, et que celui-ci embarque 512 octets d'EEPROM, ce qui fait qu'avec quelques qualités de soudeur, il est possible d'exploiter cette EEPROM:

https://forum.arduino.cc/index.php?topic=191298.0

https://github.com/m3741/due_eeprom

Pour une sauvegarde de données à rythme très intensif, il y a les FRAM connectables en I2C, comme celle-ci:

https://www.adafruit.com/product/1895






_pepe_

#7
Jun 15, 2018, 09:20 am Last Edit: Jun 15, 2018, 09:42 am by _pepe_
Le nombre de cycles d'écriture minimum par bloc donné par le constructeur est :
- de 30 000 à 25°C et d'au moins 10 000 à 85°C pour la mémoire Flash du SAM3XE (256 octets par bloc) ;
- de 100 000 pour la mémoire EEPROM de l'ATmega16U2 (4 octets par bloc) ;
- de 1 000 000 à 25°C et 3,3V pour les mémoires EEPROM modèles AT24C256C (64 octets par bloc) et  AT24C512C (128 octets par bloc).
Le nombre effectif de cycles d'écriture sans erreur peut être beaucoup plus élevé, mais sans garantie.

De plus, pour estimer la durée de vie minimale de la mémoire, il faut tenir compte de la taille des blocs et de la stratégie d'écriture dans le nombre de cycles d'écriture nécessaires aux opérations.


Si la durée de vie garantie paraît insuffisante, alors il faut plutôt se tourner vers une mémoire RAM non volatile.

On trouve notamment les mémoires SRAM sauvegardée par pile (NVSRAM ou SRAM et pile extérieure) dont le nombre de cycles d'écriture n'est pas limité. Par exemple, une puce 23LCV1024 à interface SPI (20 MHz max.) présente 128 Ko de SRAM non volatile avec une durée de rétention garantie de 20 ans.

windaube21

je pense que le nombre de cycle d'écriture peut être négliger

enfin je ne sais pas, les carte SD, les clé usb, les SSD normalement sont limiter en ecriture et pourtant je n'est jamais "tué" une clé usb ou autre

au pire on tue une eeprom externe a 1euro ?



après ce n'est qu'une question de gout et de couleur

_pepe_

#9
Jun 15, 2018, 05:29 pm Last Edit: Jun 15, 2018, 05:52 pm by _pepe_
La durée de vie limitée ne doit pas être négligée. Ce n'est pas une question de coût de la mémoire, mais de fiabilité du système qu'on conçoit et dont on attend qu'il restitue correctement les données qu'on y enregistre. En règle générale, les conséquences d'une erreur de fonctionnement d'un appareil dépassent très largement 1€. Et parfois, ça peut même coûter très cher.


Quand une mémoire Flash est donnée pour 10 000 cycles d'écriture, il est probable qu'elle ne présente des erreurs d'écriture ou de rétention qu'au-delà de 100 000 cycles. Mais si l'utilisation qu'on en fait consiste à y écrire un octet à la fois par effacement et réécriture complète du bloc, et toujours sur les mêmes blocs, alors pour une mémoire organisée en blocs de 512 octets, des erreurs survenant au bout de 150 000 cycles entraîneraient des dysfonctionnements avant 300 utilisations. Dans le cadre d'une seule utilisation par jour, la durée de vie de l'appareil serait alors inférieure à 1 an. Il n'est pas impossible que d'autres appareils identiques puissent fonctionner durant plus de 10 ans sans erreur, et qu'à l'inverse certains posent problème dès le second mois d'utilisation, mais rien ne permet de le prédire.

La seule façon de concevoir un appareil absolument fiable est de s'en tenir aux données du constructeur. En l'absence d'une stratégie adaptée, avec 10 000 cycles et des blocs de 512 octets, une écriture octet par octet imposerait de limiter la vie de l'appareil (ou bien juste de sa mémoire) à seulement 19 utilisations. Passé cette limite, on joue à la roulette.


Les clé USB et les cartes SD contiennent un micro-contrôleur rapide qui est chargé, entre autres, de soulager la mémoire Flash des effets des écritures multiples et de veiller à ce que les blocs utilisés ne soient pas défectueux. Mais il arrive un moment où, en dépit de tous les algorithmes astucieux mis en œuvre, le dispositif n'est plus capable d'assurer un fonctionnement convenable, et où le taux d'erreurs se met à augmenter de façon notable.

Pour cette même raison l'utilisation des SSD a nécessité l'adaptation des systèmes d'exploitation au prix d'une perte de performances, parce que les méthodes d'enregistrement applicables aux disques durs classiques (à plateaux magnétiques) entraînait leur usure prématurée.

lesept

Je suppose que les clés USB ou DD utilisent des codes correcteurs (SEC, SECDED, etc) ?
A force d'essayer on finit par réussir... Donc, plus ça rate, plus on a de chances que ça marche (proverbe Sharduinok).

_pepe_

Je suppose que les clés USB ou DD utilisent des codes correcteurs (SEC, SECDED, etc) ?
Oui. Mais sans ces codes de détection et de correction d'erreur, les dispositifs à mémoire Flash de grande capacité seraient inutilisables tellement les erreurs sont récurrentes.

En fait, le défaut de rétention des données n'est pas la seule cause d'erreur, et ces codes ne sont qu'une des solutions mises en œuvre simultanément pour y faire face.

frantzgac

Bonjour et merci pour vos nombreuses contributions qu'il va me falloir un peu de temps pour comprendre attendu que les matériels dont vous parlez me sont inconnus.
Concernant les réécritures je ne crois pas vraiment avoir de souci de ce côté là puisqu'il s'agit de stocker des mesures (32 octets la mesure) durant 1h30 à raison de quelques dizaines par secondes. Mais l'opération sera répétée au maximum une centaine de fois en dehors des tests.
En revanche j'ai une contrainte de poids, de volume et de  prix car le matériel doit être solidement arrimé à un corps humain qui bouge et ceci en 15 exemplaires.
C'est sans doute ces contraintes qui vont déterminer le choix technique.

J-M-L

#13
Jun 17, 2018, 10:14 pm Last Edit: Jun 17, 2018, 10:19 pm by J-M-L
En revanche j'ai une contrainte de poids, de volume et de  prix car le matériel doit être solidement arrimé à un corps humain qui bouge et ceci en 15 exemplaires.
C'est sans doute ces contraintes qui vont déterminer le choix technique.
oui donc ça milite pour un truc tout intégré.. je pense que le Wemos/Lolin D1 mini est un bon choix (mais il est en 3.3V) car pas cher et embarque la mémoire dont vous avez besoin + tout petit (la carte pèse 10g, Longueur = 34.2mm, Largeur=25.6mm)


--> Quel capteur de mouvement souhaitez vous utiliser?


Please do not PM me for help,  others will benefit as well if you post your question publicly on the forums
Pas de messages privés SVP

frantzgac

Bonjour

j'ai pour le moment entre les mains un VMA204 déjà obsolète semble t il d'après Velleman et donc le marquage des connections

IN1 IN2 GND VCC
CS SCO SCA SCL

ne correspond pas à la documentation :

GND VCC SCL SDA

Ce n'est pas très grave étant donné que je l'ai acheté à fin de test. Le capteur restera sans doute à déterminer. Cela dit j'aimerais assez tester ce capteur.

Sur le site Wemos on trouve ceci https://wiki.wemos.cc/products:d1:d1_mini

Si cette carte peut être programmée avec les mêmes outils de développement qu'une arduino je suis prêt à faire le test. Reste à déterminer les branchements du VM204, à moins que vous m'en préconisiez un autre ?

Et la communauté de développeur sur Wemos est-elle aussi prolifique que celle sur Arduino ?









Go Up