Davantage de mémoire Arduino Leonardo ?

28 ko c'est la mémoire flash, celle où est stocké le "code". Une fois programmée elle ne bouge plus. La RAM permet de manipuler temporairement des données (variables etc ...) et s'efface dès qu'elle n'est plus alimentée (un RESET quoi). Le préfixe const d'une déclaration, permet de stocker la variable dans la mémoire flash, alors que si tu ne l'utilises pas elle sera stocké dans la RAM (mais sera modifiable). L'EEPROM est une mémoire pour stocker des variables durablement, elle est programmable par le code. Par exemple : tu as un four commandé par arduino avec un écran LCD, l'utilisateur peut régler dessus les paramètre de régulation. Il faut que ces paramètres soit maintenu même si on débranche la prise, et qu'on ait pas non plus à rebrancher le four au pc dès qu'on veut faire une manip. C'est la que l'EEPROM entre en jeu.

Faut pas oublier qu'il ne s'agit que de micro-contrôleurs 8 bits aux ressources limitées.
Les programmes sont stockées dans la flash de l'AVR.
Dans la Leonardo il y a 32 KO de Flash dont 4 KO occupés par le bootloader
2.5KO de RAM et 1KO d'EEPROM.

Faut programmer économe et optimisé :grin:

Sinon t'as des cartes plus performantes embarquant un vrai Linux genre Raspberry Pi ou BeagleBoard.

L'avantage principal de l'Arduino c'est qu'il est très facile d'accès pour les néophytes et relativement bon marché.

Faut programmer économe et optimisé smiley-mr-green

Faut prendre exemple sur Microsoft ?
Bon, d'accord [] -->

Effectivement B@tto, merci pour l'explication ! C'est bien la mémoire flash que je souhaite agrandir !

patg_:
Faut pas oublier qu'il ne s'agit que de micro-contrôleurs 8 bits aux ressources limitées.
[...]
Faut programmer économe et optimisé :grin:

Ceci dit avec 3 lignes de code on peut épuiser le microcontroleur 10 fois plus qu'avec 100Mo de programme, tout dépend de ce qu'on demande :slight_smile: Si je veux faire du traitement qui recquiert beaucoup de conditions et de tests booleans, je prends beaucoup de place dans la mémoire flash pour finalement un traitement assez facile pour l'Arduino !
Surtout si je switche sur 2 shields en même temps ! :smiley:

Donc on ne peut pas vraiment étendre cette mémoire ...?

Recherches la différence entre un microprocesseur et un micro-contrôleur ainsi que sur les architectures internes des deux (Von Neuman et Harward) et tu comprendra la réponse de B@tto.

Un micro-controleur n'est pas conçu pour faire de la grosse programmation mais pour être au plus du matériel.
Il ne fait pas ce que fait un microprocesseur mais il fait des choses qu'un microprocesseur ne sait pas faire.

PS avec 32k de mémoire l'ATMega328p est déjà considéré comme un "gros" microcontrôleur.

Je connais la difference entre micro controleur et microprocesseur :slight_smile:

Le traitement simple auquel je pense est largement a la porté d'un Arduino.

Bien qu'il soit consideré comme gros, le Due a 512Ko, c'est quand même 20 fois plus gros que le Leonardo, même si ca n'est pas la même bete, je parle simplement de davantage de memoire flash !

Ben où est le problème alors ?

Et puis bien souvent c'est la RAM qui est problématique, avant que tu arrives à remplir les 28 ko de flash ...

68tjs:
Ben où est le problème alors ?

Je cherche à avoir plus de mémoire flash, je demande s'il y a un moyen simple de dépasser les 28Ko.

B@tto:
Et puis bien souvent c'est la RAM qui est problématique, avant que tu arrives à remplir les 28 ko de flash ...

Pas pour les petits trucs que je fais, c'est à dire du traitement basique avec beaucoup de lecture/écriture, et carte SD pour les vrais stockages, très peu de variables :slight_smile:
28Ko de flash ça se remplit vite quand on manipule l'Ethernet shield en weblient /webserver et qu'en plus on joue avec un LCD, et puis on ne sait jamais, dans des projets futurs.

Enfin dans les cas que tu évoques (et comme je le disais avant) c'est la RAM qui est problématique.

Je ne connais pas exactement le fonctionnement du codage pour Arduino niveau hardware, d'autant plus que la compilation est assez particulière (de ce qu'on m'en a dit), mais à priori créer et détruire rapidement des variables passe correctement même avec la RAM limitée dont je dispose, enfin d'après les tests que j'ai fait jusque là.

Le seul problème que j'ai en pleine face pour l'heure c'est surtout que mon code est vraiment limité en taille en lui même, donc, de ce que j'en ai compris, par la mémoire flash, les 28Ko en question, non ?

C'est ça. Il ya la mega sinon avec 256 KB

D'accord donc il faut se baser sur la mémoire flash de la carte à l'achat et c'est tout ? Merci pour vos réponses en tout cas ! :slight_smile:

Bonjour,

En gros pour résumer ma vision de la chose :
J'ai fait passer un synthétiseur chiptune 100% codé en C orienté objets dans un ATtiny45 (4Ko de flash, 512 octets de RAM).
Commentaire compris le code fait 2600 lignes, ça laisse matière à réfléchir.

28Ko de flash et +2Ko de RAM c'est la richesse tu peut me croire :wink:
À l'heure actuelle j'ai eu un seul et unique projet qui ne soit pas passer en flash sur une UNO (prog d'interface graphique , pas assez de place pour les bitmaps).
Si tu sait coder propre et en minimisant ton empreinte mémoire tu peut faire ce que tu veut avec 28Ko de flash.
C'est la RAM qui pose souvent le plus de problème ...

Après si t'est tétu -> STM32F4 discovery, 1Mo de flash, 256Ko de RAM, cpu ARM 32bits à 168MHz.
Si t'arrive à mettre à genou ce monstre de puissance (embarqué) c'est que ton application n'est soit pas bien pensé, soit pas faite pour tourner sur un µC embarqué :wink:

Alors c'est que je bouffe du flash sans m'en rendre compte ! Ca serait pas simplement les librairies qui prendraient des tonnes de place ? Effectivement en trifouillant davantage, je me rends compte qu'écrire de gros morceaux consomme peu de place en définitive.

En tout cas merci pour le nom, je retiens, on ne sait jamais !

Les requêtes POST en webclient me rendront fou.

Si tu n'utilises pas l'IDE Arduino attention aux options de compilation :
utiliser des bibliothèques statiques avec les options pour le linker qui vont bien -> voir tous les sujet sur l'utilisation d'Eclipse ou Code::block c'est détaillé.

Mizur:
28Ko de flash ça se remplit vite quand on manipule l'Ethernet shield en weblient /webserver et qu'en plus on joue avec un LCD, et puis on ne sait jamais, dans des projets futurs.

oulala... ben non. je monte mon serveur http et cela consomme rien... et j'ai de l'embarqué : jquery, jcarrousel, jquery mobile, etc etc ... donc je te garantie que le probleme est ton code et pas la mémoire flash ... mon serveur va fournir tout le backoffice de gestion dynamique de mes peripheriques et le controle/config de chaque sensor etc ... il y a du lourd et la mémoire n'est pas du tout un problème.

perso je pense que ton code n'est pas adapté a la "machine". on est pas sur un pc, il faut adapter le code a l'arduino. moi je m'éclate... bon je prog depuis vingts ans faut dire ...

Je ne code pas depuis 20 ans mais je ne pense pas que ça soit mon code le problème :slight_smile: Je n'ai pas non plus dit que j'avais rempli les 28Ko, j'ai encore du chemin.

Ceci dit le serveur http prend sans doute moins de subtilités que le client avec l'arduino, qui est vraiment pas simple à manipuler et qui doit s'adapter à chaque site visité (sauf si on se base sur du commun genre json ou rss); pas que le serveur soit "simple" à faire, mais le client demande beaucoup de blabla pour peu de matière en sortie, et ce pour chaque nouveau serveur visité.

mouaaiisss.
bon fun :wink:

ce n'était une réponse constructive désolé ...

que tu sois client ou serveur sur ton arduino tu vas manipuler de gros data et en arduino au vu des capacités "technologique" proposés tu ne peux pas faire comme sur un ordinateur de "bureau" : charger un fichier en mémoire, pour le parser a ta guise (même si tu consommes un webservice qui te retourne de l'xml ou json, rss... tu pourrais a la limite parser d'un coup mais je te le déconseille, mais tout dépend de ton api et de tout ce quelle dois traiter également).
Tu dois donc utiliser des buffers, et cela que tu sois le client (en réception) ou en émission en tant que serveur ou en réponse client et ces ces buffers que tu vas manipuler.
Sans buffer tu n'arriveras a rien sur l'arduino ou alors ton api sera super longue en temps de traitement de l'information (réception ou émission : client ou serveur) et ton api instable (si tu as une fuite de mémoire ton arduino va rebooter...), après tout dépend effectivement des performances recherchés de ton application et des taches // qu'elle doit traiter, car si en natif l'arduino ne fais pas le muli thread et est donc bloquant, il est cependant très simple de le mettre en place et de créer des traitements non bloquant pour chaque traitement effectué. (imagine que pendant l'envoi ou la reception de ta page ton api soit bloqué pendant tout le traitement de l'information emisse ou receptionnée... c'est relativement bloquant ! c'est le cas de le dire ! ton api est paralisée pendant tout le temps que tu vas traiter ta page, et utiliser les interruptions proposés par arduino ne résoud rien du tout).

donc dans l'un ou l'autre cas il n'y a aucune difficultée. Construire une requête POST n'est pas plus compliqué que de parser une réponse et ce, quelque en soit la taille de la réponse et de la réception ou le protocole utilisé. faut juste s'adapter a l'arduino et faire pas plus que ce qu'il t'accorde.