enregistrer fichier en flash ou sram possible?

bonjour tout le monde,
avant de me prendre la tête pendant des heures pour rien, je pose ma question avant.
est ce possible de faire un file_get_content et de l'enregistrer non pas sur une SD mais en flash ou sram?
variables du style
a=100 b=50 etc...
et utiliser ces variables après, même s'il y a une coupure de jus sur le nono.

merci d'avance

file_get_content() c'est une fonction PHP, pas Arduino que je sache.
Que cherches tu as faire ?

autant pour moi, je voulais dire un get.
recuprer un fichier avec des données sur un server et les enregistrer pour s'en servir par la suite comme si j'utilisais eeprom write read.

Salut,

infobarquee:
avant de me prendre la tête pendant des heures pour rien, je pose ma question avant.
est ce possible de faire un file_get_content et de l'enregistrer non pas sur une SD mais en flash ou sram?
variables du style
a=100 b=50 etc...
et utiliser ces variables après, même s'il y a une coupure de jus sur le nono.

Dafuq !? J'ai rien compris ...

file_get_content() -> langage PHP
flash -> progmem avec le fusible "Self programming" activé, mais à par pour un bootloader c'est impossible à gérer
sram ->2Ko max c'est juste à mon avis et surtout à la moindre coupure de l'alim tout est perdu

A mon avis le mieux c'est encore l'EEPROM :wink:

Croisé avec Skywodd

l'EEPROM interne me parait la bonne solution.
La SRAM interne n'est pas sauvegardée en cas de coupure de courant.

Si pas assez de place en interne, il y a aussi des E2PROM I2C ou SPI

barbudor:
Si pas assez de place en interne, il y a aussi des E2PROM I2C ou SPI

Ou sinon dans le pire des cas il existe aussi des mémoire flash SPI (genre AT45DB16 -> 2Mo), mais c'est un peu galère a utiliser (2v7, nombre de cycles R/W limité, ...).

bon ben voila, j'ai ma réponse déjà. :slight_smile:
j'ai l'impression de passer pour le boulet du jour :grin: vais prendre des vacances moi.
je vais retourner sur l'eeprom mais je voudrais éviter l'udp, vu les déboires que cela procure au dessus de 3 variables envoyées sur le nono.

lol parfois on mets les gens sur un pieds d'estale et quand on ce rend compte qu'ils savent pas qu'ils ont une EEPROM bien pratique contre les coupures de courant on les en redescend xDDDD

Prend des vacances ton cerveau te remerciera :slight_smile: ( tous ça amicalement bien sur :slight_smile: )

Skizo !

infobarquee:
j'ai l'impression de passer pour le boulet du jour :grin: vais prendre des vacances moi.

Vacances :bave:

infobarquee:
je vais retourner sur l'eeprom mais je voudrais éviter l'udp, vu les déboires que cela procure au dessus de 3 variables envoyées sur le nono.

Rappel sur le datagramme UDP :

  • pas d'acquittement = pas de gestion de pertes de paquets
  • pas d'ordonnancement = les paquets arrivent dans l'ordre ou ils veulent (c'est pas une FIFO)
  • pas de checksum = les erreurs de communications sont laissé entre les mains du dév
    Avantage : ya aucun controle donc c'est beaucoup plus rapide (et prioritaire sur le TCP)

Si tu n'arrive pas à transmettre 3 variables de plusieurs octets en UDP c'est que tu as du te prendre les pieds dans une de ces "caractéristiques".

je sais qu'il y a une eeprom sur le nono en cas de coupure de courant.
mais vu les déboires que cela procure lorsque l'on envoie en udp plus de 3 variables, je cherche une soluce paliative.

Ne mélange pas les problèmes d'UDP et l'EEPROM.
Ce n'est pas parce que tu as un problème dans un cas que tu dois tout jeter.
A ce que j'ai compris sur l'autre topic il n'a pas été démontré d'interaction entre EEPROM et UDP.
C'est juste un problème d'UDP et de FIFO dans le WS5100.

je ne jete rien, mais je cherche une solution paliative à ce problème avec l'udp en plus de ma question sur le flash et sram pour un autre projet.