LOCODUINO - l'Arduino pour le train miniature

OU l'assembleur ça me rappelle dans les années 80, en tant qu'étudiant pour programmer sur des platines didactiques à base de 8080 et 8085 et z80 8 bits c'étail le bon temps des processeurs Intel et Zilog.

ca ressemblait a ça: pas d'écran ni de clavier azerty juste un afficheurs et quelques touches

L’Arduino a été développé à l'origine dans un but éducatif et de ce fait les difficultés de la programmation ont été gommées le plus possible. abstraction de la notion de ports d'entrée sortie, des registres, des différents modules inclus dans le microcontrôleur (SPI,I2C,ADC,TIMER etc..)
Pour cela une librairie a été développée qui offre non seulement une interface simplifié mais également une bonne protection contre les bêtises que l'on peut écrire en codant: accéder à un port qui n'existe pas, outrepasser les capacités d'un timer...
Le revers de la médaille c'est que ces fonctions de librairie passent plus de temps à vérifier la "légalité" de l'ordre donné qu'a faire le boulot proprement dit.


A titre d'exemple voici un petit (petit, petit) morceau de code qui fait clignoter la LED d'un arduino, connectée au bit 5 du port B de l'atmega328p, pin numérotée 13 dans la nomenclature Arduino

Code:

void loop()
{

  digitalWrite(LED_BUILTIN, HIGH);   // turn the LED on (HIGH is the voltage level)
  digitalWrite(LED_BUILTIN, LOW);    // turn the LED off by making the voltage LOW

}

Ce code génère un signal d'une fréquence d'environ 148KHz

Code:

void loop()
{

PORTB |= (1 << PB5) ;    
PORTB &= ~(1 << PB5) ;

}

Ce dernier morceau de code qui de prime abord, fait la même chose, génère un signal à environ 2MHz, ce n'est pas de l'assembleur mais du C.

Et dans la plupart des cas c'est suffisant pour obtenir de bonnes performances. A mon sens la différence de performance entre le C et l'assembleur ne justifie pas l'effort à fournir pour écrire en assembleur.
Ceci dit, d'un point de vue pédagogique, cela permet de mieux comprendre le fonctionnement de notre microcontrôleur favori et par la suite de coder avec plus de soin et d'efficacité, donc à pratiquer un petit peu pour la culture.

Pour la petite histoire, le Z80, microprocesseur inclus dans le ZX81 est toujours en vente !

DAN57FRN a écrit:

OU l'assembleur ça me rappelle dans les années 80, en tant qu'étudiant pour programmer sur des platines didactiques à base de 8080 et 8085 et z80 8 bits c'étail le bon temps des processeurs Intel et Zilog.

ca ressemblait a ça: pas d'écran ni de clavier azerty juste un afficheurs et quelques touches

Bonjour à tous,

Merci pour cette séquence nostalgie. J'ai connu le même genre de cartes durant mes études, cela ne nous rajeunit pas.

Dans les années 80-90, j'ai fait du développement pour systèmes embarqués en Modula-2 (langage conçu en Suisse), puis en C. Les seules fois où j'ai eu recours à l'assembleur, c'était pour patcher le code généré par le compilateur C directement en mémoire afin de vérifier la correction d'un bug. Comme il fallait une bonne vingtaine de minutes pour compiler l'ensemble du projet, c'était un gain de temps appréciable.

La taille de nos projets à microcontrôleurs ou Arduino et la rapidité des PC actuels font que le patch n'est plus nécessaire car la compilation est très rapide.

Pour compléter la discussion au sujet de l'assembleur, je ne suis pas non plus persuadé qu'il soit nécessaire d'y recourir pour nos projets, sauf peut-être avec le tout petit Attiny 13 qui n'a que 1 K de mémoire programme, 64 octets de RAM et 64 octets d'EEPROM.

CleoN a très bien illustré le gain de vitesse entre une version Arduino et C avec avr.lib d'un même programme. À titre indicatif, le binaire de mon projet actuel basé sur l'Attiny45 occupe environ 800 bytes. Le programme n'est pas terminé, mais il comporte déjà la lecture de 2 boutons poussoir, le clignotement d'une led de contrôle, le contrôle du PWM et une routine d'interruption. Même lorsqu'il sera complet, il devrait aisément tenir dans les 4 K de mémoire programme. Par curiosité, j'irai voir à quoi ressemble l'assembleur produit par le compilateur gcc-avr.

CleoN a écrit:

A mon sens la différence de performance entre le C et l'assembleur ne justifie pas l'effort à fournir pour écrire en assembleur.

Indépendamment des performances, je vois deux cas où le C ne peut tout simplement pas faire :
1 - engendrer un signal à fréquence élevée et temporellement précis (bit banging).
2 - changer le contexte d'exécution (co-routines ou multitâche)

OK pour le bit banging, vraiment à fréquence élevée.
Quand à faire du multitâche, sur un aussi petit microcontrôleur, j'ai du mal à trouver une utilité.

Mon point de vue est peut être influencé par l'overdose d'assembleur que j'ai mangé dans ma jeunesse :
Z80, 6502, 6809, 68000, 68020, 68hc11, 68332, ARM.

CleoN a écrit:

Quand à faire du  multitâche, sur un aussi petit microcontrôleur, j'ai du mal à trouver une utilité.

Les Arduino ARM Cortex (et compatibles) sont loins d'être petits, les plus gros peuvent être comparés à des PC d'il y a 20 ans, mais c'est vrai que ce n'est pas le même langage machine que celui que présente Christian.

Bonjour à tous,

Merci pour ces échanges très intéressants.

Un système à microcontrôleur peut avoir besoin de gérer plusieurs tâches en pseudo-parallèle. Il n'est cependant pas nécessaire de faire appel à un noyau temps-réel préemptif. Dans mes projets, j'ai utilisé les techniques suivantes en C/C++, toutes pouvant être considérées comme du multitâche coopératif:

• Plusieurs machines d'états appelées l'une après l'autre dans la boucle principale. Les machines d'états s'implémentent sous forme de fonctions et variables d'états ou d'objets en C++. Dans ce dernier cas, un mécanisme tel que celui employé dans la librairie ScheduleTable de JLB garantit l'exécution des méthodes faisant évoluer chaque machine d'états. L'Arduino qui gère les trains de mon réseau hivernal a ainsi plus d'une dizaine de tâches pseudo-parallèles: une tâche par zone de détection, une tâche pour les aiguillages, une pour l'affichage LCD, une pour le TCO, une pour la gare cachée, etc.
  
• Les protothreads: http://dunkels.com/adam/pt/. Le mécanisme se base sur l'instruction switch encapsulée dans des macros pour mémoriser l'endroit où la tâche rend la main et doit reprendre. On peut ainsi facilement programmer un traitement séquentiel devant se dérouler en plusieurs pas.
  

Bonne fin de journée.

C'est clair qu'avec la famille ARM on change de catégorie , aussi bien en fréquence de calcul qu'en capacité mémoire, sans compter un vrai gestionnaire d'interruption, un contrôleur mémoire et du calcul en virgule flottante !

Peut on encore appeler ça un microcontrôleur ? Un SOC (System On a Chip) ?

@SavignyExpress: Tu m'avais fait découvrir en effet il y a quelques années les protothreads, très  intéressants pour imbriquer différents automates, que je n'ai toujours pas eu l'occasion d'utiliser.

Aaaahhhh je me rends compte de ma bévue, j'ai confondu ! C'est un ami qui avait le ZX81, moi j'ai eu le Spectrum et le Spectrum+2 (ce dernier doit encore exister au grenier chez mes parents, mais je ne sais pas si j'oserai le brancher à nouveau un jour, trop peur qu'il parte en fumée !)

J'ai également pratiqué de l'assembleur pendant mes études : sur 68000 au lycée, puis sur Sun/Solaris à l'université. C'est effectivement intéressant pour la culture, de savoir comment ça se passe sous le capot. Ca ouvre l'esprit pour ceux qui en ont besoin.

En revanche, développer en assembleur, très peu pour moi. Je comprends que certaines applications pointues puissent y avoir recours, et pourtant je doute que ce soit nécessaire dans notre hobby (mais peut-être qu'il y a un cas ...).

Il est vrai qu'aujourd'hui la plupart des développements ne se préoccupent plus des plus fines optimisations, que ce qu'on fait aujourd'hui dans une application développée en C# pourrait tourner sur une machine d'il y a 15 ans si on la développait en assembleur, mais il y a un argument purement financier derrière tout ça : on développe beaucoup plus vite en C# qu'en C, et encore plus vite qu'en assembleur. Qui voudrait payer ses licences logicielles 10 à 100 fois plus chères en raison du coût de développement ? Personne ... Il est moins cher d'acheter une machine plus performante.

D'ailleurs, on est arrivés depuis quelques années à un point où l'overhead des langages évolués n'augmente plus (ou très très peu).

Pour en revenir à l'Arduino, ça m'a fait plaisir de me replonger dans des optimisations pour gagner de l'espace programme ou de la mémoire vive dans mes programmes comme au bon vieux temps, mais je me suis contenter d'optimisations sur le langage C, pas d'assembleur !

On en revient toujours au ratio temps passé / gain. D'ailleurs, avec les puces ESP8266 et ESP32, on commence à avoir largement ce qu'il faut en capacité de stockage programme/mémoire vive pour faire tout ce qu'on veut dans notre loisir ! D'ailleurs, quand ça déborde, il faut souvent revenir au précepte de base, segmenter les choses ! Plutôt qu'un Arduino pour tout faire, autant mettre un Arduino par tâche élémentaire, plus facile à maintenir !

Même si parfois pour faire un programme plus universel il est pratique de tout mettre dans le même programme. A propos du multi-tâches, je l'ai implémenté aussi, selon le principe de la machine d'états (une fonction loop dans chaque objet, et une loop principale qui se contente de faire le tour des objets instanciés et d'appeler leur fonction loop), et franchement, ça va largement bien pour notre usage modélistique !

Néanmoins merci pour cette tranche de discussion qui m'a replongé dans mon passé !

Bonjour à vous tous,

Je confirme la dernier paragraphe de Sierramike, je le fais dans tous mes programmes, cela facilité le debug aussi.
Bon Arduino à tous!

A+
Yves

J'avais vu un réseau ou 1 canton = 1 arduino. A 5€ la carte, ça vaut le coup de se simplier les choses.

@SavignyExpress

Tu évoquais dans ton dernier message les machines d'états.
Pour les débutants en Arduino je les invite à lire ce tutoriel disponible sur le forum Arduino francophone

Il y a un article sur le sujet sur Locoduino également : https://www.locoduino.org/spip.php?article25

jlb tu as raison

Désolé de ne pas l'avoir cité dans mon message

Pas de soucis

Fantasio a écrit:

@SavignyExpress

Tu évoquais dans ton dernier message les machines d'états.
Pour les débutants en Arduino je les invite à lire ce tutoriel disponible sur le forum Arduino francophone

Vachement bien ! même pour les non debutants

Merci.

Je suis ,comme beaucoup sur le forum et le site Locoduino, pour le partage des infos et j'espère ça pourra motiver certains d'entre nous à se lancer dans l'Arduino.

Bonjour,

Je me permets juste une contribution de faible intérêt, en tant que lecteur silencieux, pour indiquer aux rédacteurs du site LOCODUINO que dans certains cas minoritaires comme le mien, la valeur ajoutée de leurs contributions (en l'occurrence sur l'assembleur) était inestimable.

Merci,

Olivier

Ça c'est du challenge !!!

Quelques questions, j'ai toujours été curieux des choix et des aventures des uns et des autres...sur le plan technique s'entend, bien sûr  !

N'existe il pas une version de GCC pour la famille PIC ?

Il me semble que la consommation des locos est bien supérieure à celle d'un microcontroleur, comment fais tu ?
Train a clé ? Batterie de voiture ?

Peut être pourrais tu installer un (des) panneaux solaires.

Pour garder un œil sur ma maison de campagne j'ai installé un arduino pro mini, avec un panneau solaire, une carte sim900 équipée de sa carte SIM (forfait à 2€), une batterie (2x18650) et quelques capteurs.
Pour l'instant il n'y a que 4 capteurs de température + surveillance de la tension batterie et tension panneau solaire.

J'ai déjà dû beaucoup jongler avec la consommation, utiliser les modes de sommeil profond etc... Et il y a des périodes en décembre et janvier, si le temps est couvert ou je n'ai  plus de communication.

Pour un réseau de train, sans faire de calcul, je gage qu'il faut une belle surface de panneau solaire.

Tiens nous au courant de tes avancées, le sujet est intéressant.

Bonjour,

Je souhaitais juste indiquer aux rédacteurs du site LOCODUINO que dans certains cas minoritaires comme le mien, la valeur ajoutée de leurs contributions (en l'occurrence sur l'assembleur) était inestimable.

Merci,

Olivier

Je te proposerais bien une reconversion sur les microcontrôleur Atmel, mais je sais que quand on est habitué à une famille, c'est difficile de changer.
Encore que si tu écris essentiellement du C, tu ne verras pas vraiment la différence.

Bonjour à tous,

Je reviens de quelques jours passés chez mes beaux-parents et je découvre cet échange très enrichissant sur assembleur ou pas assembleur (je copie Shakespeare).
Bien évidemment, je me réjouis de ce débat et chacun peut bien évidemment penser ce qu'il veut sur le sujet. Pour ma part, je crois avoir été clair dans mes articles, l'assembleur est plus difficile à déboguer, demande d'acquérir des connaissances, bref beaucoup de travail alors que le C est beaucoup plus accessible et facile à modifier ou à maintenir.
C'est pourquoi l'article d'aujourd'hui pourrait convaincre certains.

Si vous avez suivi la série d'articles sur l'assembleur depuis le début, l'article d'aujourd'hui vous paraîtra très intéressant. En effet, il vous propose de mélanger dans un même programme, du code en C et du code en assembleur.
Vous pouvez ainsi développer votre application en C (ou C++) ou plus simplement avec les fonctions d'Arduino ; vous bénéficiez alors de la convivialité de ce langage et de sa facilité de mise au point. Et lorsque c'est nécessaire, vous développez certaines fonctions en assembleur afin de bénéficier de l'avantage de ce langage (accès aux ressources du microcontrôleur pour faire exactement ce que vous voulez, respect d'un timing rigoureux, compacité du code, etc.).
Alors, si ce programme vous tente, la lecture de l'article commence ICI.

En conclusion, notre rôle chez LOCODUINO, c'est de vous proposer différentes techniques pour programmer vos microcontrôleurs ou vos cartes Arduino. Mais c'est à vous de savoir si ces techniques vous apportent ou non quelque chose. Et effectivement, dans notre hobby, les cas où l'assembleur devient VRAIMENT nécessaire doivent rester relativement rares. Mais cela aussi je vous l'avais dit...

Bonne lecture et pour certains, bon développement.

Bonjour à tous,

L'article d'aujourd'hui va sans doute vous paraître très théorique, mais il est indispensable pour introduire l'article de la semaine prochaine qui vous proposera des applications pratiques des notions développées aujourd'hui (et en plus, des applications qui ont une utilité en modélisme ferroviaire).

En plus, c'est le dernier article à être aussi technique, car la série va bientôt se terminer. Dans l'article, nous passons en revue trois notions fondamentales en assembleur : l'adressage, la gestion de la pile, le timing d'un programme.

Je ne vous en dis pas plus, si cela vous intéresse, c'est ICI.

Bonjour à tous,

L'article que nous publions aujourd'hui est récréation pour tout le monde ! En effet, ces travaux pratiques vont vous permettre d'appliquer les notions théoriques vues dans le précédent article afin de contrôler directement en assembleur des périphériques d'affichage.
Bien évidemment, les programmes proposés ne font pas autant de choses que les bibliothèques d'Arduino, mais c'est un début qui peut être développé et surtout, sur le même principe, on peut créer des animations lumineuses comme de la signalisation ferroviaire, des feux de carrefours ou des enseignes de commerçant.
C'est bien la récréation, alors profitez en ! C'est par ICI !

Bonjour à tous,

Je sais que vous êtes quelques uns à attendre le dernier épisode de la série "L'assembleur" mais celui-ci n'est pas tout à fait prêt. En effet, nous voulons que ce dernier article soit le plus complet possible et nous avons besoin d'un peu de temps pour le compléter. Ce n'est que partie remise.

L'article que je vous propose aujourd'hui s'adresse à ceux qui n'ont jamais pratiqué Arduino mais qui en ont entendu parler. Et parmi eux, il y en a sans doute beaucoup qui n'ont ni l'envie ni le courage d'apprendre à programmer. Mais doivent-ils pour autant renoncer à utiliser Arduino sur leur réseau ?

Et bien nous pensons que non car les montages proposés par LOCODUINO peuvent être reproduits tels qu'ils sont, sans rien changer, et la seule chose qu'il faut savoir faire est de récupérer le programme et le verser dans une carte Arduino.

C'est ce qu'explique l'article dont le titre devrait vous encourager à le lire : Comment utiliser Arduino sans apprendre à programmer ?

Bonne lecture.