Modules WVMicrocontroleur chipset et Opensource

vierax
Sapin
Sapin
Messages : 260
Enregistré le : dim. 29 sept. 2013, 01:53
Ecigarette (s) utilisée (s) : ¤ Dany Extreme V2 (= Pipeline Pro 2)
Tayfun GSL
454 Big Block
¤ VAMO V5 Mukey double barrel en filaire avec un transfo 9V (matos de secours)
Igo-L

Fiber Freaks (première version) densité 1 ou 2 selon l'humeur + coton Bacon
base maison 90% PG végétal, 10% eau, nico 3.2 mg/mL
Arômes favoris : Hibiscus, Caramel Beurre Salé, Poire, Violette, Red Astair, Noisette, Châtaigne, Mandarine et Framboise
+ petits DIY allday : (Myrtille, Mûre, Kiwi) ou (Crêpe, Érable, Pécan)
Vape parfois sans arôme
Genre : Non spécifié
Âge : 33

Re: Microcontroleur chipset et Opensource

Messagepar vierax » dim. 25 sept. 2016, 13:19

C'est futé d'utiliser la fréquence de l'oscillateur pour faire le comptage au lieu d'utiliser un compteur software, ça économise vraiment bien les ressources (ça doit même alléger la SRAM, non ?). Même si ça bouffe plus de place sur l'eeprom on gagne en autonomie :)
Je ne suis pas codeur mais je constate que tous les projets qui veulent utiliser les AVR de manière à exprimer le plein potentiel des cartes utilisent du C (avec des bout d'ASM parfois) et pas du tout l'IDE Arduino (le compilateur doit être peu optimisé).
Quand je vois que les Teensy 3 utilisent des SOC ARM pour toujours plus de puissance, je me dis que ton micro-OS améliore encore l'expérience avec les humbles AVR.
Ça promet :)

djinn
Pommier
Pommier
Messages : 96
Enregistré le : sam. 1 nov. 2014, 13:20
Genre : Non spécifié
Âge : 43

Re: Microcontroleur chipset et Opensource

Messagepar djinn » dim. 25 sept. 2016, 15:23

vierax a écrit :Je ne suis pas codeur mais je constate que tous les projets qui veulent utiliser les AVR de manière à exprimer le plein potentiel des cartes utilisent du C (avec des bout d'ASM parfois) et pas du tout l'IDE Arduino (le compilateur doit être peu optimisé).

Oui. Arduino présente une sur-couche au-dessus de C++, qui fournit une interface (API) générique et simple d'accès. Plein de librairies sont disponibles pour gérer tout type de matériel sans avoir à en connaître tous les détails; Super pratique pour un prototypage rapide par exemple. L'inconvénient c'est que toute cette abstraction pèse son poids: par exemple, une librairie graphique gérant mon écran OLED pèse dans les 20Ko de FLASH et demande plus d'1Ko de RAM. Alors que ma tiny85 ne dispose que de 6.5Ko de FLASH (1.5Ko étant pris par le boot-loader USB) et 512 octets de RAM en tout et pour tout!
Se rapprocher du matériel permet de faire gains à ce niveau. En comparaison, ma propre librairie graphique (certes plus limitée en fonctionnalités) pèse ~1Ko et ne demande que 128 octets de RAM, tout en étant plus rapide. Mais le code (en C) est plus spécialisé et moins portable. Et il faut souvent l'écrire ―quoiqu'on puisse s'inspirer des librairies existantes, Arduino ou autre.

L'approche "système d'exploitation" se situe à un autre niveau: on peut l'appliquer aussi bien dans un environnement Arduino que pur C. Elle tient à la façon dont on structure et on organise son application.
Au lieu d'un long programme où les taches sont moins clairement définies, et dont le code s'entremêle en partie, on a un ensemble de taches autonomes définies séparément qu'on peut facilement ré-ordonnancer, que soit pour la configuration (présence/absence de tel matériel/telle fonctionnalité) ou pendant l'exécution (pour passer d'un mode ou d'une fonctionnalité à un autre).
Avec une seule tache (blink), les ~80 octets supplémentaires de l'OS ne sont pas vraiment justifiés. Mais ajoutons une seconde LED qui doit clignoter à une fréquence différente de la première…
Dans l'approche OS il suffit de rajouter une seconde tache:

Code : Tout sélectionner

#define TASKS  /* name    period delay active  */\
                 (blink,     100,    0,    ON)  /* Blink 1st LED every 1s */\
                 (blin2,      33,    0,    ON)  /* Blink 2nd LED every 0.33s */\
Avec une approche plus "monolithique", ça n'est pas aussi simple. En Arduino,il faudrait transformer cette fonction:

Code : Tout sélectionner

// the loop function runs over and over again forever
void loop() {
  digitalWrite(1, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);              // wait for a second
  digitalWrite(1, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);              // wait for a second
}
… pour faire clignoter la seconde LED à une fréquence incompatible avec la première. C'est vite le bordel. :)

vierax a écrit :Quand je vois que les Teensy 3 utilisent des SOC ARM pour toujours plus de puissance, je me dis que ton micro-OS améliore encore l'expérience avec les humbles AVR.

Ouais, l'un dans l'autre ça aide à sortir de bonnes perfs de ces bon vieux 8bits sans trop avoir à galérer…
À la base on avait dans l'idée avec gdb de pondre un truc bien modulaire, du genre tu rentrerais tes caractéristiques désirée (en terme de matériel et fonctionnalités) et ça te sortirait un firmware sur-mesure, voire le schéma du PCB… Organiser ça en taches permet d'automatiser ce process. :mrgreen:


Retourner vers « Modules WV »

Qui est en ligne

Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 2 invités