Taille des programmes

Bonjour,
J'ai dans l'idée de développer un programme plutôt conséquent pour ma nouvelle carte Arduino Uno.
Or je vois que par exemple l'exemple basique de serveur web de 30 lignes occupe à lui seul déjà plus de 40% de la mémoire...
Je me pause donc des questions quand à la faisabilité d'un projet dont le code devrait faire plus de 10 000 (c'est un serveur web plus ou moins basique).
Merci

Tu va devoir optimiser ton code. Ensuite, pour ce qui est des pages à retourner, elles peuvent être stoquées sur une carte sd. C'est toujours ça de moins (et je suppose que c'est une grosse partie du code). Ça demande pas beaucoup d'investissement matériel, d'autant que les shield ethernet et wifi ont un slot pour microSD. Si ton shield n'est pas un officiel, et qu'il n'en a pas, un adaptateur microSD classique et 6 résistances font l'affaire.

Bonjour,

Utilise webduino pour le serveur web :wink:
Ensuite met tout le code des pages HTML sur une carte SD, optimise ton code autant que possible, etc ...
Le nombre de ligne ça ne veut rien dire, tu peut faire un programme d'une ligne qui prennent 100% de la mémoire, comme un programme de plusieurs centaines de ligne qui en prennent 30% :wink:

Merci.
Enfin quand je dis taille dans la mémoire, je parle de celle du programme non des variables..etc Il y a quand même corrélation entre longueur et taille d'un programme.
Bien sur les pages web seront stocké sur une carte sd, j'ai un shield officiel.
Est il possible au passage d’exécuter du code puis la carte SD ?

Alatar:
Enfin quand je dis taille dans la mémoire, je parle de celle du programme non des variables..etc Il y a quand même corrélation entre longueur et taille d'un programme.

Pas forcément :wink:

const char PROGMEM s[30720] = { 0 };

Et voila en une ligne j'ai mis à genoux toute la mémoire flash du microcontrôleur/

Le compilateur fait un sacré paquet de truc dans ton dos, il ne faut pas croire qu'une ligne de C = une instruction assembleur.
Quand le compilateur optimise (et si tu lui as préparé le terrain) il peut te faire passer des codes de +1000 lignes (de codes, pas de commentaires) dans moins de 2Ko.
Par contre si tu fait les choses à la truelle il te sortira des codes de 100 lignes qui font 16Ko ou plus.

Alatar:
Est il possible au passage d’exécuter du code puis la carte SD ?

Lit ça Architecture de type Harvard — Wikipédia :wink:
Réponse : non, c'est physiquement impossible.

Si tu veut vraiment faire ça tourne toi vers la netduino, c'est du C# -> machine virtuelle -> exécution de code depuis n'importe où.

Réponse : non, c'est physiquement impossible.

Tu n'est pas un peu catégorique là ? La famille AVR ont la capacité de se reprogrammer
tout en exécutant du code (flash memory with read-while-write capabilities). C'est ce qu'utilise
le bootloader de l'arduino.

marcha:
Tu n'est pas un peu catégorique là ?

Exécuter du code depuis une carte SD est impossible, je suis ca-té-go-ri-que.
L'architecture du CPU ne le permet pas, tout comme l'exécution depuis la RAM.

marcha:
La famille AVR ont la capacité de se reprogrammer tout en exécutant du code (flash memory with read-while-write capabilities).

Tu lit de travers :wink:
"read while write" = "lecture pendant écriture", il n'est jamais fait état d'une quelconque possibilité d’exécuter du code.
Pouvoir reprogrammer la flash en interne n'est pas du tout pareil que d’exécuter du code depuis un périphérique de stockage externe !

marcha:
C'est ce qu'utilise le bootloader de l'arduino.

Attention : un bootloader n’exécute pas de code, il copie du code, c'est pas du tout la même chose.
Au final le code est bien dans la mémoire flash de l'AVR.

Des bootloaders par carte SD pour arduino ça existe (cherche sur le forum ou sur google ;)) mais il prennent de la place et limite donc d'autant la place libre pour ton programme.

Je suis tout a fait d'accord avec tes explications. Mais la question initiale était:

Est il possible au passage d’exécuter du code puis la carte SD ?

Je suis d'accord de le cpu ne peut adresser directement le code dans la carte SD. Par contre
il est capable de se reprogrammer partiellement avec du code provenant de la carte SD. puis
de l'exécuter dans sa mémoire flash. Donc je trouve trop catégorique de répondre que c'est
physiquement impossible.

marcha:
Je suis d'accord de le cpu ne peut adresser directement le code dans la carte SD. Par contre
il est capable de se reprogrammer partiellement avec du code provenant de la carte SD. puis
de l'exécuter dans sa mémoire flash. Donc je trouve trop catégorique de répondre que c'est
physiquement impossible.

Tu le dit toi même : "le cpu ne peut adresser directement le code dans la carte SD", l’exécution depuis la carte SD est donc bien physiquement impossible.
Il faut utiliser les termes adéquats, "exécuter depuis" et "copier depuis" n'ont pas la même finalité !

Remarque : copier un programme partiellement n'est pas une bonne idée. Cela voudrait dire que tu vas gérer un système de pagination, copier les pages manquantes dynamiquement, etc etc ...
Autant dire que tu auras flinguer la mémoire flash avant que ton système soit fonctionnel (la mémoire flash n'as pas une durée de vie infini en écriture).

Tu le dit toi même : "le cpu ne peut adresser directement le code dans la carte SD", l’exécution depuis la carte SD est donc bien physiquement impossible.
Il faut utiliser les termes adéquats, "exécuter depuis" et "copier depuis" n'ont pas la même finalité !

Pareil pour la Flash, le CPU n'exécute pas le code depuis la flash, mais copie l'instruction dans l'unité de traitement. Donc on peut jouer sur les termes adéquats
pendant longtemps :slight_smile:

Ce que je trouve dommage en disant simplement que c'est "physiquement impossible", c'est que tu coupe court à une voie de recherche possible qui consiste à placer
du code dans la SD card. Que ce soit du code AVR ou un autre type de code interprété n'est pas bien important. C'est pour ça que je suis intervenu, car la question
de l'auteur de ce post porte sur la possibilité d'avoir un programme conséquent. Et si il atteint les limite du CPU, alors la voie de placer du code dans la SD card
est à évaluer.

J'approuve par contre que le fait de reprogrammer la flash a ses limites.

Pour ce qui est de la mémoire si une librairie est utiliser une seul de ses fonctions peut valoir énormément de lignes de c derrière qui elle seul val plusieurs centaine voir millier de lignes d'assembleur

marcha

Ce que je trouve dommage en disant simplement que c'est "physiquement impossible", c'est que tu coupe court à une voie de recherche possible qui consiste à placer
du code dans la SD card

je suis d'accord avec skywodd l'architecture Harvard a été conçu de sorte a fonctionne d'une manière bien précise, aucun programme ne pourra changer cela, ça peu choquer les doux rêveur, mais la programmation ne fait pas de son utilisateur un dieu XD

aucun programme ne pourra changer cela

Rien ne t'empêche de programmer un interpréteur qui vas traiter du code dans un langage quelconque
situé en RAM, en EEPROM, ailleurs dans la Flash ou sur tout autre support.

Voici un topic qui en parle:

Bien sur on perd en performance avec une couche supplémentaire, mais suivant les applications cela peut être une solution.

Exemple en Basic avec une SD Card: Arduino BASIC Interpreter Using LCD, Keyboard, And SD | Hackaday

marcha:
Pareil pour la Flash, le CPU n'exécute pas le code depuis la flash, mais copie l'instruction dans l'unité de traitement. Donc on peut jouer sur les termes adéquats
pendant longtemps :slight_smile:

Le fait qu'il y ai une étape de "fetch, hold and execute" vers le registre d'instruction du CPU c'est chercher la petite bête pour avoir raison ...
Le cpu fait de l'adressage sur la mémoire flash pour l'exécution, c'est la définition même d'une exécution depuis une source quelconque, ici la flash.
Dans un processeur x86 (ou autre) avec un cache d'exécution je serait plus mitigé, mais ici il n'y a pas de cache ...

marcha:
Ce que je trouve dommage en disant simplement que c'est "physiquement impossible", c'est que tu coupe court à une voie de recherche possible qui consiste à placer
du code dans la SD card. Que ce soit du code AVR ou un autre type de code interprété n'est pas bien important. C'est pour ça que je suis intervenu, car la question de l'auteur de ce post porte sur la possibilité d'avoir un programme conséquent. Et si il atteint les limite du CPU, alors la voie de placer du code dans la SD card
est à évaluer.

Seul Alatar serait en mesure de dire ce qu'il veut vraiment faire :wink:

Mais je pense très sérieusement que Alatar n'as pas envie de faire une machine virtuelle, un compilateur/assembleur et/ou un langage de programmation dédié pour son projet.
A mon avis tout ce qu'il veut savoir c'est si il peut coller son programme AVR tel quel sur une carte SD et le lancer sans se casser la tête, chose impossible.

Ensuite il ne faut pas tout mélanger !
Code compilé natif, bytecode pré-compilé (+ machine virtuelle), code interprété (script texte), ... ce n'est pas la même chose !

Un code natif tourne à la vitesse processeur, 16Mips environ (chaque instruction ne fait pas 1 tick d'horloge mais on va pas chipoter) sur un arduino classique.
Un code pré-compilé, si tu arrives à faire du 100Kips c'est déjà un miracle (je le sait puisque je code une machine virtuelle en ce moment même. 100Kips = 1600 tick cpu (à 16MHz) par instruction = pas grand chose en fait).
Un code interprété ... 1 Kips, 2Kips grand maximum ... une vrai misère ...

Et ne pas oublier que coder un langage de script requiére des connaissances par forcément évidente, ni à la porté de tous ...
Faire une machine virtuelle requiére des connaissances en conception d'émulateur CPU et de programmation assembleur.
Faire un moteur de script requiére des connaissances en langage de script (forcément) et en manipulation de texte (parsing, tokenisation, ...).

marcha:
Rien ne t'empêche de programmer un interpréteur qui vas traiter du code dans un langage quelconque
situé en RAM, en EEPROM, ailleurs dans la Flash ou sur tout autre support.
(...)
Bien sur on perd en performance avec une couche supplémentaire, mais suivant les applications cela peut être une solution.

Tu sembles oublier un point : ce n'est plus du tout de "l'arduino", voir même du C/C++.
Apprendre la syntaxe du BASIC (ou autre) c'est bien beau mais tu perd bien plus que des performances, tu perds aussi tout le travail réalisé par les autres membres (librairies, codes, tuto, ...).
Dans certaines circonstances cela peut effectivement être d'une grande utilité mais là ce n'est clairement pas le cas ...

Âpres d'un point de vue code rien ne t'empêche de concevoir (où de porter) un émulateur d'AVR8 + hardware ATmega sur un ATmega ...
Par contre tout ce qui sera lié au temps sera faussé ...

Je ne remet pas en question tout ce que tu dis. Mais il n'y a pas que l'auteur d'un post qui est concerné
par ce que tu écrit. Cela sert de base de connaissance pour d'autres qui tomberont sur ce topic.

Poser des dogmes tels que "c'est physiquement impossible" c'est fermer la porte à d'autres pistes qui
peuvent intéresser d'autres lecteurs.

Ceci dit maintenant qu'un bon nombre de possibilités ont été débattues. Ce post me semble assez complet.

Je te laisse donc poster le dernier mot :slight_smile:

Comme dit plus haut seul une machine virtuel pourrais émuler la lecture d'un programme hors de l'eeprom (un peu comme java) mais ce principe rend la lecture des programmes lente et lourde,
personnellement pour m'être frotter a l'assembleur du x86 j'imagine sans peine le travaille titanesque qu'une machine virtuel demanderais sur l'ATmega328,

Ma conclusion est qu'une machine virtuel est faisable mais difficile et peu efficace,
Pour ce qui est d'exécuter un programme sans passer par l'architecture Harvard prévu a cette effet est physiquement impossible.

lacolombenoir:
personnellement pour m'être frotter a l'assembleur du x86 j'imagine sans peine le travaille titanesque qu'une machine virtuel demanderais sur l'ATmega328,

C'est pas si compliqué, une fois le principe compris tu peut écrire sans probléme une machine virtuelle en 2-3 heures :wink:

Une machine virtuelle (basique) ce compose que de 3 fonctions :

  • lecture d'une instruction et switch d'exécution
  • lecture d'un registre / valeur pointée
  • écriture d'un registre / valeur pointée

Voici un exemple qui passe sur un ATmega sans probléme. C'est une version d'essai, la "vrai" version est en cours d'étude (gros travail de conception pour la partie instruction) :

Bonjour.
J'ai lu ce topic alors que je cherchais un moyen de faire des cartouches de jeu pour ma future console à base d'arduino (qui bugue toujours avec TVout au passage) .
Mon idée: pourquoi utiliser une machine virtuelle au détriment des performances, au lieu d'une machine réelle ?
En effet, j'ai vu sur le net qu'il était possible de reprogrammer une arduino avec une autre arduino, le code étant stocké sur une carte SD. (http://www.semageek.com/bootdrive-programmer-un-arduino-avec-un-autre-arduino-a-partir-dune-carte-sd/)
En gros, avec une arduino UNO comme carte mère et une arduino Mini (voire un ATtiny ...) comme diskLoader, il serait possible de reprogrammer l'arduino via une carte SD, donc de changer son code !

Bien sur, il faut attribuer une ID à chaque SD pour éviter d'avoir à copier des données inutilement à chaque démarrage . Pour ça, un fichier du type "id.txt" contenant 1 chiffre suffit.

Ensuite, ben y'a plus qu'a couper le diskLoader et la machine tourne !

(le seul problème, c'est que comme c'est une console, et que l'on modifie le code, le piratage est alors facile, mais tout le monde s'en fout ^^)

En espérant vous avoir aidé .

Geeker:
En gros, avec une arduino UNO comme carte mère et une arduino Mini (voire un ATtiny ...) comme diskLoader, il serait possible de reprogrammer l'arduino via une carte SD, donc de changer son code !

Comme précisé plus haut tu as des bootloaders tout en un (pas besoin de deux cartes donc) qui utilisent directement une carte SD pour la programmation.

Geeker:
Bien sur, il faut attribuer une ID à chaque SD pour éviter d'avoir à copier des données inutilement à chaque démarrage . Pour ça, un fichier du type "id.txt" contenant 1 chiffre suffit.

Si tu part sur ce principe le plus simple est de faire un entête situé à une adresse fixe contenant les détails du jeu, comme pour une vrai cartouche de jeu.

Geeker:
(le seul problème, c'est que comme c'est une console, et que l'on modifie le code, le piratage est alors facile, mais tout le monde s'en fout ^^)

A mon avis personne ne viendra voler ton code ... à moins de lancer le prochain FinalFantasy :roll_eyes:

Par contre tu sembles oublier un autre petit détails ...
Cf datasheet de l'ATmega328p page 1 :

High Endurance Non-volatile Memory Segments
– 4/8/16/32KBytes of In-System Self-Programmable Flash program memory
– 256/512/512/1KBytes EEPROM
– 512/1K/1K/2KBytes Internal SRAM
Write/Erase Cycles: 10,000 Flash/100,000 EEPROM
– Data retention: 20 years at 85°C/100 years at 25°C(1)
– Optional Boot Code Section with Independent Lock Bits
In-System Programming by On-chip Boot Program
True Read-While-Write Operation
– Programming Lock for Software Security

10K programmation ça te laisse une bonne marge mais ce n'est pas infini ...

Sinon tu peut chercher "UzeBox" sur google, c'est exactement ce que tu cherches à faire.

10 000 cycle d'écriture/lecture en flash ??? Je pensait plus ! (genre 1 000 000)
C'est aussi pour ça qu'il faut attribuer une ID aux cartouches: pour éviter les copies inutiles !
Sur ce, je file me payer des shields pour cette future console !