transfert PC vers SD arduino

bonjour a tous
je souhaite copier un fichier de données present sur mon PV, a l’aide de hyper terminal par le port serie pour l’enregistrer sur la SD card installée sur mon arduino.
afin de faire des mises a jour d’un fichier de code d’accés.
vous comprendrez que je veux eviter de sortir la SD pour faire la copie a partir du PC, ce serait trop simple.
pouvez vous m’aider, quelques lignes me serait utiles
merci

L'intérêt d'une SD est le support de fichiers, soit enregistrés sur PC et lus par l'ARDUINO, soit l'inverse.
Il serait plus simple et plus fiable d'utiliser l'EEPROM si 1024 octets suffisent.

Sinon voir les exemples de la librairie SDFat.

merci de m'avoir
lu, je monte un projet de clavier avec un stockage de 400 codes a 5 chiffres.
la partie stockage des codes dans la SD et leur traitement de comparaison lors de la saisie au clavier fonctionne
ma fonction d'envoi du fichier vers le pc fonctionne egalement
cela me permet de faire des modifications de code.
je voudrait pouvoir renvoyer le fichier modifie du pc vers la sd

400 codes à 5 chiffres : EEPROM sera trop petit.

Si la mémoire n'a pas pour vocation d'être remplie sur un PC, une option intéressante pourrait être une FLASH SPI du genre W25Q16

Ce n'est pas que je n'aime pas le µSD mais j'ai eu trop de déboires avec ce genre de support sur ARDUINO.

Il serait plus simple et plus fiable d'utiliser l'EEPROM si 1024 octets suffisent.

400 codes à 5 chiffres : EEPROM sera trop petit.

Des affirmations... mais je préfère les explications qu'aux affirmations.

Pour garder en mémoire un code à 5 chiffres, il suffit de deux octets et un bit. Comme je suis hyper généreux, je vais même les stocker dans deux octets et demi. 400 de ces machins, cela fait 1000 octets,
Ça tient largement! Et si on utilise deux octets et un bit, le découpage est un peu plus compliqué, mais on peut alors stocker 480 mots de passe dans l'EEPROM


Je suis habitué à découper les octets depuis que j'utilise la Uno, parce qu'il y a le même problème avec la RAM ou la FLASH

Premier exemple, (n'est pas de moi): les afficheurs TFT utilisent soit 3 octets pour ranger les trois composantes couleurs (je n'ai vu personne le faire) ou un mot de 16 bits découpé en 5+6+5 (plus tordu que 2 1/2)

Deuxième exemple, (n'est pas de moi): La plupart des registres des l'Atmel sont découpée. Soit le premier registre décrit du convertisseur analogique
ImageCiDessus.jpg
Les 8 bits ont été découpés en 3 paquets, 2 bits ensembles, un tout seul et un nombre sur 4 bits

Je vois passer régulièrement des appels de fonctions (ce n'est pas la seule)
if (!file.open("Folder1/file1.txt", O_WRONLY | O_CREAT)) {...
au lieu de:
if (!file.open("Folder1/file1.txt", O_WRONLY , O_CREAT)) {...

J'en utilise aussi.

ImageCiDessus.jpg

Pour garder en mémoire un code à 5 chiffres, il suffit de deux octets et un bit. Comme je suis hyper généreux, je vais même les stocker dans deux octets et demi. 400 de ces machins, cela fait 1000 octets,

Tu envisages sérieusement de conseiller cette solution ?
Ce n'est pas que je déconseille mais tout dépendra de grosmatou2, et surtout de ses connaissances en programmation.
Comme il demande de l'aide concernant l'écriture SD sur ARDUINO, ce n'est pas cuit d'avance.

Ce qu'il est important de comprendre est que la fiabilité de la gestion SD sur ARDUINO est plus que variable.
Ce qui fonctionne à l'instant ne fonctionnera peut-être pas dans une heure ou le jour suivant.
Le résultat dépend de deux facteurs :

  • le hardware, surtout côté alimentation, découplage ...
  • la SD elle-même

Certaines µSD donnent de mauvais résultats.
La Kingston SDHC 4Gb que j'ai utilisé sur un serveur WEB Ethernet produisait des défauts aléatoires : fichier non trouvé, présence de caractères étranges lors de lectures. Avec une Sandisk Extreme SDHC le résultat était bien plus fiable.
Par contre en modifiant le hardware (découplage plus important ou mélange électrochimique + polyester ou tantale) j'aurais peut-être obtenu un résultat correct avec la Kingston. Qui sait ?

Le problème est que c'était un serveur WEB et que les problèmes se voient tout de suite sur la page du navigateur.
Avec un système enfoui sans écran les dysfonctionnements se verront certainement beaucoup moins.
En tous cas si la solution SD est maintenue il faut absolument signaler les erreurs d'ouverture de fichier, au minimum : buzzer, écran, LED rouge, etc.

En bref la solution SD demandera une longue série de tests sérieux pour être sûr qu'elle fonctionne.
Ensuite la fiabilité dans le temps dépendra des conditions : humidité, poussière, etc.

Il existe des modules Flash SPI W25Q16 pas plus difficiles à câbler qu'un module SD (c'est aussi du SPI) et qui offrent 16Mbits donc 2Mo d'espace.
On trouve de plus grosses versions.

Tu envisages sérieusement de conseiller cette solution ?
Ce n'est pas que je déconseille mais tout dépendra de grosmatou2, et surtout de ses connaissances en programmation.
Comme il demande de l'aide concernant l'écriture SD sur ARDUINO, ce n'est pas cuit d'avance.

En principe, j'essaie de ne jamais conseiller d'utiliser une solution plutôt qu'un autre. Cela dépend beaucoup du vécu de chacun, de son niveau de programmation... Je m'amuse bien à découper les entiers, j'ai défini une police de caractères vectorielle dans laquelle je range dans un int les vecteurs (droites ou cercle, et si c'est une droite, coordonnés de départ, longueur, direction, et présence ou pas d’empattements...), et pourtant je n'ai pas encore réussi à utiliser la FatSd!

Ce qui me parait important c'est de donner les solutions possibles. Et c'est à la personne de choisir la solution qui lui convient. Si c'était moi, j'utiliserai l'EEPROM avec ces renseignements, Si c'était toi, tu utiliserai peut être la flash SPI, un autre ferait encore autre chose...

Dans mon vécu, j'ai utilisé l'EEPROM pour y stocker l'étalonnage suite à un équilibrage de deux moteurs de propulsion. Je n'ai jamais eu de problèmes avec sur des dizaines de cartes programmées. J'ai su m'en servir, il est donc normal que je penche vers cette solution. Pour moi, c'est une solution simple, sans matériel supplémentaire. Pour d'autres c'est une solution aléatoire voir complexe.

Mais là ou je ne suis pas d'accord, c'est de dire que l'on ne peut pas mettre 500 mots de passe de 5 chiffres en EEPROM.

Et c’est à la personne de choisir la solution qui lui convient.

C’est exactement ça.

C’est bien pour cela que je ne déconseille pas la SD, mais que j’avertis des dangers, et que ne déconseille pas ta solution, si le demandeur la comprend et peut l’implémenter.