assembleur BIGONOFF depassé

[holala02]

Bonjour.

je viens de lire le tuto de BIGONOFF et sincerement il n'est pas clair il va vite et le Mplabx qu'il utilise est depasser je me sens perdu, y'a il pas un nouveau tuto ou bien quelqu'un qui peut renouveler le tuto de BIGONOFF ?

Merci
-----

[elektrax]

quelle est encore la nécessité d'apprendre l'assembleur µC 8 bits à l'heure actuelle ?
au niveau amateur, çà me dépasse....

[freepicbasic]

Tu lis la doc BigOnOff puis tu pause des questions précises sur ce forum , sur ce que tu ne comprend pas !
Si tu connais l'Anglais, tu lis aussi les datasheets.

Mplab est un Macro assembleur puissant, il permet de faire des programmes complexes.


Sinon, tu te met à l'Arduino qui se programme en C, il y a des masses de sites qui en parlent.

[sandrecarpe]

Ou alors tu restes sur pic si tu veux apprendre vraiment quelques chose....
Tu peux le faire en C aussi et c'est la façon de faire aujourd'hui

Je pense qu'avoir des bases d'assembleur ce n'est pas plus mal pour comprendre le fonctionnement d'un micro

On trouve plein de doc et de tuto sur le compilateur XC8 de microchip (leur compilateur C), mais bien sûr et comme toujours en anglais. Après avoir compris les bases (lire/écrire dans les registres, manipuler les bits etc...) tu comprendras que la doc de ton micro sera ton meilleur guide

[A voir en vidéo sur Futura]

[paulfjujo]

bonjour,

quelle est encore la nécessité d'apprendre l'assembleur µC 8 bits à l'heure actuelle ?

Pourquoi Microchip /ATMEL continue-t-il à vendre des MCU 8 bits ..
Pas besoin de marteau -pilon pour enfoncer une punaise

Apprendre l'ASM:

La necessité ? AUCUNE ,
si on se contente de programmer un ARDUINO avec toutes les biblioteques et programmes
diffusées à foison sur le web .. et par les constructeurs de modules interfaces .
c'est un simple jeu de construction , pas grave si on ne comprends pas les details.

Par contre un vrai amateur cherchera à comprendre et pour cela s'appuiera sur les connaissance de bases
d'un (MCU) Microcontroleur, datasheet, registres utilisés et donc
d'une visibilté totale que si on utilise l' ASM
qui est le niveau le plus bas,le plus proche du MCU.
(sachant que la programmation 100% Manuelle en Hexadecimal a déja existé avant le langage d'Assemblage
( appelé communément Assembleur), pratiqué sur un KIM6502 !

Si on se cantonne à un MCU precis, il devient aussi facile de le programmer en ASM ,
de se constituer ses propres bibliotheques, et rivaliser avec le Langage C.
La difficulté de l'ASM est qu'il faut s'adapter si on change la reference du MCU utilisé
alors que c'est relativement transparent si on utilise un langage évolué comme le C.

Bien qu'un Langage C pour MCU , ne soit pas aussi universel que le langage C ANSI de base,
puisque necessite la definition de tous les registres du MCU utilisé.

..ou bien quelqu'un qui peut renouveler le tuto de BIGONOFF ?

La critique est aisée, mais l'art est difficile .
alors vas-y, propose toi, de le mettre à jour .

[antek]

je viens de lire le tuto de BIGONOFF et sincerement il n'est pas clair il va vite et le Mplabx qu'il utilise est depasser je me sens perdu, y'a il pas un nouveau tuto ou bien quelqu'un qui peut renouveler le tuto de BIGONOFF ?

En partant de rien il faut quelques mois pour maitriser ses cours (et pas le tuto). Et à la fin tu es capable de comprendre n'importe quel µC à partir de la datasheet.
C'est toi qui choisit la vitesse, MPLAB (sans X) est disponible pour Windows et fonctionne correctement pour les anciens µC (16f84, 877, etc).

Il n'est pas clair ou tu ne comprends pas ?!

[jiherve]

Bonjour,

Bien qu'un Langage C pour MCU , ne soit pas aussi universel que le langage C ANSI de base,
puisque nécessite la définition de tous les registres du MCU utilisé.

C'est vrai pour tous les langages haut niveau car au final il faudra bien pisser du code machine, c'est juste caché/moins visible!
L'assembleur c'est tout de même la meilleure solution pour faire cracher ses tripes à un petit µC 8bits , c'est moins vrai pour les gros processeurs(32bits) plus à même d'encaisser du C et pour lesquels le compilateur sera bien plus efficace car ayant beaucoup plus d'instructions puissantes à disposition.
JR

[webscience]

Bonjour,

Je pratique l'assembleur sur pratiquement tous les microcontrôleurs Pic(8 bits), et je suis vraiment pas déçu, j'ai commencé avec les leçons de
Monsieur Bigonoff(un grand merci à lui).

Le problème, c'est que beaucoup de personne n'ont même pas les bases les plus courante, et pourtant Monsieur Bigonoff c'est donnée
beaucoup du mal à expliquer tout ça.

C'est pas facile, je le reconnais, mais si on fait pas un effort de compréhension on peut y arriver.

Il y a pas mal de gens qui son près à expliquer tout ça, mais il faut avoir le courage de le demandé, un forum qui est pas mal et sans aucune Pub
c'est celui là www.fantaspic.fr/

A+

[freepicbasic]

La nostalgie des Microchip 16Fxx et les joies du PCLATH et des rp0 , rp1 et du stack prog riquiqui.
Quant au stack data, c'est du DIY...

[bobflux]

À l'époque des STM32 à 2€, pour des projets perso, programmer des 8 bits en assembleur n'est plus très utile.

Par contre, l'assembleur t'apprend comment fonctionne la machine, ça fait mettre les mains dans le cambouis, et ces connaissances sont bien utiles. De plus, regarder l'assembleur produit par le compilateur C permet parfois de lever des bugs.

Je dirais qu'il faut en faire un peu, pour l'expérience.

[webscience]

Bonsoir,

écrit par : bobflux
À l'époque des STM32 à 2€, pour des projets perso, programmer des 8 bits en assembleur n'est plus très utile.

Sauf que maintenant dans la nouvelle série sur 16F et 18F il y a de quoi faire, ils peuvent tourner à 64Mhz.


A+

[nornand]

À l'époque des STM32 à 2€, pour des projets perso, programmer des 8 bits en assembleur n'est plus très utile.

Par contre, l'assembleur t'apprend comment fonctionne la machine, ça fait mettre les mains dans le cambouis, et ces connaissances sont bien utiles. De plus, regarder l'assembleur produit par le compilateur C permet parfois de lever des bugs.

Je dirais qu'il faut en faire un peu, pour l'expérience.

tout a fait et dans certain cas d'optimiser des portions de code.

[Vincent PETIT]

Salut,
Programmer en assembleur (ou avoir programmé en assembleur) permet également de bien maîtriser la gestion de la mémoire. J'ai vu des bibliothèques avec un tel niveau d'encapsulation, des fonctions qui en appellent d'autres qui elles même en appellent d'autres et ainsi de suite, que de toute évidence ceux qui les ont écrit l'on fait sans se soucier d'un débordement de pile. Sur certain PIC c'est encore plus critique car la pile est matérielle.

[jiherve]

Bonjour,

J'ai vu des bibliothèques avec un tel niveau d'encapsulation, des fonctions qui en appellent d'autres qui elles même en appellent d'autres et ainsi de suite, que de toute évidence ceux qui les ont écrit l'on fait sans se soucier d'un débordement de pile.

çà je l'ai vécu il y a bien longtemps sur 6809 , l’écriture soft avait été confié à un "spécialiste " adepte des logiciel hyper structurés résultat à la première compilation : out of memory!,
j'avais renvoyé le spécialiste à ses chères études sur mainframe.
Mais indépendamment de çà il y a maintenant des effets beaucoup plus subtils avec les caches, une application peut être totalement ruinée par un mésusage de la mémoire dont la possibilité ne sera même pas envisagée par un programmeur lambda.
JR

[penthode]

perso , j'ai appris les µ en 1996 avec les cours de Maître BIgonoff .

donc passage obligé par l'ASM.

ça ma donné une structure intellectuelle incomparable !

même maintenant , dans le cas d'une "petite" appli ,
je ne me sers pas de langage compilé

[bobflux]

çà je l'ai vécu il y a bien longtemps sur 6809 , l’écriture soft avait été confié à un "spécialiste " adepte des logiciel hyper structurés résultat à la première compilation : out of memory!, j'avais renvoyé le spécialiste à ses chères études sur mainframe.

Oui, d'ailleurs y'a pas longtemps je compilais un code pour un LPC111x, un petit cortex-M0... et le printf de la stdlib fait genre 10 ou 20 ko de binaire ! La moitié de la flash... C'est à pleurer. J'en ai refait un vite fait avec un minimum de features, dans une taille plus raisonnable...

> Mais indépendamment de çà il y a maintenant des effets beaucoup plus subtils avec les caches, une application peut être totalement ruinée par un mésusage de la mémoire dont la possibilité ne sera même pas envisagée par un programmeur lambda.

En effet, le prefetch et les locks pas alignés sur les lignes de cache c'est un champ de mines...

[gcortex]

L'assembleur permettait de faire des rotations de bits, des opérations BCD et des sorties sauvages de boucles !

[gcortex]

Sans apprendre l'assembleur, un rapide coup d'oeil sur les instructions.
C'est bien de savoir par exemple que l'UAL ne fait pas les divisions.

[Bigonoff]

Salut à tous
------------

Un internaute me signale qu'on parle de moi, vu que ça fait des lustres que je ne me suis pas connecté, je réponds maintenant.

Mplabx qu'il utilise est depasser je me sens perdu, y'a il pas un nouveau tuto

Comme tu l'indiques, tu utilises MPLAB-X, mais mes cours sont basés sur MPLAB-IDE: Ce n'est pas le même IDE. Donc soit tu convertis ce que j'explique à MPLAB-X (faut lire le manuel de MPLAB-X), soit tu télécharges MPLAB-IDE qui est disponible sur le site de Microchip. MPLAB-X ne présente un intérêt que si tu utilises une plateforme non-windows, vu que cet IDE tourne sous Linux et sur Mac.

Bref, le cours est parfaitement à jour, tu t'es juste trompé d'IDE.

quelle est encore la nécessité d'apprendre l'assembleur µC 8 bits à l'heure actuelle ? au niveau amateur, çà me dépasse.

Ça ne dépasse que ceux qui n'ont pas fait l'effort d'apprendre. Sans cette démarche fondamentale on se retrouve à programmer des microcontrôleurs dont on ignore au final le comportement intrinsèque.
On n'est pas plus obligé d'apprendre le langage d'assemblage d'un micro (au moins un) que d'avoir des notions de mécanique pour conduire un véhicule. De là à dire que "ça te dépasse" il y a une marge.

c'est un simple jeu de construction , pas grave si on ne comprends pas les details.

Oui, tout à fait. Du reste, je suis tombé il y a pas longtemps sur un adepte de jeu de construction Arduino: Il devait faire une régulation de puissance par triac. Je lui ai fourni le tableau calculé des retards de phase nécessaires pour avoir 50 paliers de puissance d'intervalles identiques, il n'a pas compris de quoi je parlais. Au final j'ai compris que c'était un "programmeur jeu de construction": Il a acheté un gradateur pour maison avec un bouton rotatif, a acheté le module Arduino pour pilotage de moteur pas-à-pas, il a relié le moteur au potentiomètre, a effectué un retour de mesure via un module de conversion analogique, et a utilisé les librairies toutes faites: Son "programme" fait tourner le moteur qui fait tourner le potentiomètre qui change la tension de sortie de son gradateur domestique.
C'est à ça qu'on arrive quand on fait du "légo" pour s'éviter l'apprentissage. Certes, ça fonctionne... à condition de rester dans les clous et de ne pas rencontrer le moindre problème. Quant à l'encombrement et au coût...

La nostalgie des Microchip 16Fxx et les joies du PCLATH et des rp0 , rp1 et du stack prog riquiqui.
Quant au stack data, c'est du DIY

Plus un micro est simple et plus il est "facile" à étudier et à décortiquer dans son intégralité. Tu veux t'amuser à écrire un cours aussi complet que les miens (4 tomes pour plus de 1000 pages) pour un ARM LPC1768, juste histoire de rigoler un coup?

Le principe de mes cours est expliqué: Étudier une famille de microcontrôleurs simples pour en comprendre tous les mécanismes... et ensuite pouvoir comprendre les bases de tous les autres micros qu'on sera amené à étudier.
Donc, soit on prend simple, soit.... c'est IMPOSSIBLE d'écrire une doc complète exhaustive. Mais bon, il faut avoir consacré des milliers d'heures bénévolement à écrire des ouvrages destinés aux autres pour comprendre.

J'ai réalisé à l'époque des projets fonctionnels sur de "bêtes" 16F876 bien plus intéressants que certains aujourd'hui qui utilisent des micro 32 bits sous-exploités et qui surconsomment de l'énergie. En fait, travailler avec des ressources réduites impose une plus grande rigueur dans le développement et un supplément d'ingéniosité. Et ça, c'est très utile à ceux qui vont se lancer dans de futurs challenges.

À l'époque des STM32 à 2€, pour des projets perso, programmer des 8 bits en assembleur n'est plus très utile.

Pour des projets perso, peut-être... et encore.
Ensuite, juste pour info, plus de la moitié (et de loin) de mes cours sont téléchargés... par des écoles ou des étudiants qui font des études supérieures (au vu de mes retours de courrier).

Et enfin, STM32 etc,, mouais, mais moi je programme aussi des microcontrôleurs 32 bits, pour l'instant j'ai des projets publiques utilisant des ARM Cortex M3 LPC-1768: La doc de base, c'est plus de 1000 pages.... dont une partie renvoie sur d'autres docs (module USB HOST par exemple) qui font encore plusieurs milliers de pages. Le tout avec des concepts avancés style "DMA", et j'en passe.
Et, force est de constater que, lorsqu'on essaye de faire des projets publiques sur ce genre de composants.... soit la majorité des internautes sont "largués" parce que, justement, ils n'ont pas les bases, soit se contentent d'utiliser des librairies "toutes faites" (les miennes ou les officielles) et donc, au final... ne comprennent pas ce qu'ils font. Ben évidemment ce n'est pas indispensable de tout comprendre... mais dans ce cas il suffit de ne pas télécharger et lire mes cours: Des tutos sur Arduino et autres Légos, ce n'est pas ce qui manque, c'est simplement d'une autre nature.

Mes cours sont destinés à pouvoir "comprendre comment ça fonctionne", et non à "comment produire une appli qui fonctionne à moindre effort": À chaque cahier des charges un résultat différent, mes cours sont très clairement orientés sur la compréhension des mécanismes, ils ne s'adressent en aucun cas à celui qui veut écrire une appli qui fonctionne plus ou moins en 10 minutes sur le coin d'une table. Pour ça, effectivement, il y a Arduino et Cie: Ce n'est pas mauvais, c'est juste un autre objectif qui est ciblé.

Sinon, juste pour info, mes cours sont écrits jusqu'aux 18F, qui permettent de faire des choses pour le moins intéressantes. Et ne pas oublier non plus que les PIC 8 bits n'ont pas été créés pour l'amateur... mais pour l'industrie... qui s'en sert, sinon ces composants n'existeraient simplement plus.

Maintenant, quelques avantages d'un langage d'assemblage:

- En cas de bug du compilateur, ou de production automatique de code optimisé: En "assembleur" on comprend pourquoi ça plante: Je programme les ARM en C et j'ai découvert un bug au niveau du compilateur utilisé: Sans connaissance d'un langage d'assemblage, c'est casse-tête assuré

- Le langage d'assemblage m'a permis de détecter un bug vicieux dans le noyau de toute une famille de PIC (18Fxx2, 18Fxx8 etc): Je l'ai signalé à Microchip, on a eu des échanges à ce sujet, et, au final, toute la famille a été retirée et remplacée par des 18Fxx20, 18Fxx80 etc. En C, bonjour la panade pour comprendre ce qui se passait.

- La plupart des datasheets ne parlent pas du C: Sans des connaissances de base en programmation d'assemblage, il y a des explications qu'on ne peut simplement pas comprendre.

- L'apprentissage du langage d'assemblage sur un PIC 16F c'est.... 35 instructions à retenir. Dès lors, comparé au C je vois mal la difficulté. Parce que, les utilisateurs de langages évolués confondent... le langage et les librairies fournies avec le compilateur.

- Sur les micros puissants, il y a des instructions en mode protégé... qui ne sont simplement PAS ACCESSIBLES avec un compilateur, on est CONTRAINT d'utiliser le langage d'assemblage, même si, le plus souvent, le constructeur fourni une librairie en langage d'assemblage pour simplifier l'utilisation. Bref, un compilateur... ça ne fonctionne pas dans tous les cas.

Au final le C n'a strictement rien de portable sur les microcontrôleurs, vu que les microcontrôleurs c'est 1% de langage et 99% d'I/O. Or, le C ne gère pas les I/O et donc c'est librairies propriétaires "non standard" à tous les étages.
Au final on doit quand même étudier le micro lui-même, sauf à n'utiliser que des librairies et donc à accepter qu'on utilise un bridage du micro utilisé, vu qu'on ne peut utiliser que ce qui a été prévu dans les librairies, avec les limites imposées par les librairies.

Allez, juste quelques lignes de C sur un ARM cortex M3:

LPC_SC->PCONP |= PCONP_PCCAN1;
LPC_CANAF->AFMR = 2;
NVIC_SetPriority(CAN_IRQn,prio rityLevel);

Ma question est: Quand on a étudié le C, est-ce qu'on comprend ce bout de code? Parce que, j'ai l'impression que ça nécessite pour être compris d'étudier le micro, et 99% de mes cours ça explique le micro, pas le langage.

Et si maintenant on désire comprendre un micro, on doit lire le datasheet. Or, que dit un datasheet sur le C? Rien, ça ne fait pas partie du micro. Dans un datasheet de micro on va trouver des exemples en langage d'assemblage. Par exemple, un exemple tiré du manuel utilisateur du LPC1768:

LDM R8,{R0,R2,R9} ; LDMIA is a synonym for LDM
STMDB R1!,{R3-R6,R11,R12}
STM R5!,{R5,R4,R9} ; Value stored for R5 is unpredictable
LDM R2, {} ; There must be at least one register in the list

On a l'air malin si on ne comprend pas la philosophie d'un langage d'assemblage.


Bref, je résume:

- Est-ce utile d'étudier les PIC 8 bits?
Oui si on cherche à comprendre "comment ça marche" ou si on veut maîtriser les coûts au cent près et l'encombrement au mm près (industrie).
Non si on veut juste un résultat au plus simple et au plus rapide avec un budget "amateur" et pour une production d'une pièce unique.

- Est-ce utile d'étudier un langage d'assemblage?
Oui si on veut pouvoir optimiser pour des applications critiques, comprendre tous les datasheets, se sortir d'impasses manifestes
Non si on veut juste utiliser les librairies fournies en standard avec un compilateur

-Est-ce que mes cours sont dépassés?
Oui si le but est de réaliser des "trucs qui marchent" avec le minimum de temps d'investissement
Non si le but est d'avoir une base pour apprendre le monde des microcontrôleurs

-Est-ce judicieux d'écrire en C?
Oui si la cible s'y prête et que l'application le permet: C'est un gain de temps considérable par rapport à la programmation en langage d'assemblage, surtout sur les micros complexes (pour les PIC 8 bits... bof)

Je n'ai JAMAIS dit qu'il fallait éviter le C, j'ai dit que c'était inapproprié pour un micro 8 bits de la famille 16F, déjà à cause des limitations hardwares: Mais si on ne cherche pas à exploiter 100% du composant, le C est une alternative.

Le "bon" langage dépend de la cible et du projet. Personnellement,
- je programme les micros 8 bits (du 6502 aux PIC18F en passant par les 8051 et autres) en langage d'assemblage
- je programme les microcontrôleurs sans OS 32 bits en C majoritairement
- Je programme les microprocesseurs sous Android en Kotlin, ceux sous Windows en C#
- Je programme sur web en PHP et HTML (j'ai horreur du web)

Mes ouvrages ne sont pas "l'apologie du langage d'assemblage", ce sont des ouvrages destinés à fournir les bases à ceux qui veulent évoluer dans le monde des microcontrôleurs afin de les rendre les plus autonomes possibles (savoir lire un datasheet, comprendre les concepts de base, savoir déboguer un code, etc.

Maintenant, chacun fait comme il l'entend, bien évidemment. En ce qui me concerne je supprimerai mon site lorsque plus personne ne téléchargera mes cours: Pour l'instant ce n'est pas le cas et je continue de recevoir du courrier qui montre que des gens qui sortent actuellement d'écoles supérieures ont utilisé ces cours. Ceci en comprenant qu'en plus la France n'est pas le nombril du monde, et que j'ai plein de courriers de personnes qui n'ont pas un choix conséquent en terme de microcontrôleurs ni de budget suffisant pour acheter "tout fait". Bref, j'ai fait le boulot, je l'ai partagé, autant que ça serve à un maximum de personnes. Quand ce ne sera plus le cas, j'arrêterai, sachant que, de toute façon, moi-même j'arrive doucement en "fin de carrière".

Comprenez quand même que pour un Français, acheter un bouquin sur Arduino de 50€ et un pack de base de 100€ c'est anecdotique: On clique et on commande en ligne, on est débité sur sa carte de crédit. Dans d'autres pays du monde il faut galérer pour trouver un bouquin et le coût anecdotique pour un Français devient le budget mensuel alimentaire dans certains pays. Ces autres pays méritent bien de profiter de ce qu'ont profité les Français lorsqu'ils trouvaient ça "utile", même si aujourd'hui ils préfèrent un produit plus "plat préparé".

[jiherve]

Bonjour,
ah que d'air frais,cela fait du bien en periode de confinement!
Moi je suis Propeller addict car j'adore les machines //!
JR

[MathSACO]

Je suis bien d'accord avec ce que dit Bigonoff que je salue au passage.

J'ajouterais à ce qu'il a dit que l'assembleur permet de gagner en vitesse d’exécution. J'ai déjà analysé du code généré par un compilateur C (ou peut-être basic, je ne me souviens plus), c'était d'une lourdeur incroyable et le µC prenait 15 cycles là où le programme en assembleur n'en demandait que 4. De la même façon, lorsqu'on a besoin d'un timing précis, compté en cycle d'horloge dans le cas d'une communication synchrone par exemple, il est difficile de s'en sortir sans assembleur. C'est moins vrai pour les µC plus puissants qui disposent en hard d'interfaces SPI et I2C.

J'ai déjà réalisé des montages qui communiquent entre eux (réalisant une chaine de 4 appareils qui communiquent chacun avec l'appareil qui le précède (sauf le premier) et celui qui le suit(sauf le dernier)) et il aurait été délicat de le faire sans assembleur, avec notamment la gestion des time-out en cas de défaillance ou de surcharge µC d'une carte.

[Unitrode]

Le C est de (très loin) le langage du monde embarqué, l'assembleur reste incontournable pour des fonctions bien particulières où il est nécessaire d'optimiser certaines choses.
Peut être 10% du code s'il fallait donner un rapport.
Dire qu'il est difficile de se passer de l'assembleur n'a pas vraiment de sens, tout dépend du contexte et du besoin (des exigences) que réclame l'application.
Programmer tout en assembleur ne sert strictement à rien aujourd'hui, en tout cas serait contre productif en industrie, les compilateurs C ont grandement évolué ainsi que les micros.

Après pour l'efficacité ça dépend plus de la qualité du programmeur, de sa formation sur le micro, pas du langage.
C'est un fait pas un avis perso.

[Unitrode]

Bonjour,
ah que d'air frais,cela fait du bien en periode de confinement!
Moi je suis Propeller addict car j'adore les machines //!
JR

Comme je te comprends.

[Unitrode]

Je suis beaucoup moins d'accord avec cette affirmation:

Au final le C n'a strictement rien de portable sur les microcontrôleurs, vu que les microcontrôleurs c'est 1% de langage et 99% d'I/O. Or, le C ne gère pas les I/O et donc c'est librairies propriétaires "non standard" à tous les étages.

Un code C bien écrit, comme tout langage structuré, est organisé en bibliothèques de fonctions (ADC, CAN, uart, FSM, etc) qui décrivent des fonctions haut niveau, parfaitement transposables vers un micro (8, 16 ou 32 bits) quelconque.
Pour en avoir écrit dans ma vie quelques wagons sur au moins 6 familles de micros différentes, je peux en témoigner.
Les I/O se déclarent dans un module à part (io.h, init.h, etc).

Comprenez quand même que pour un Français, acheter un bouquin sur Arduino de 50€ et un pack de base de 100€ c'est anecdotique: On clique et on commande en ligne, on est débité sur sa carte de crédit. Dans d'autres pays du monde il faut galérer pour trouver un bouquin et le coût anecdotique pour un Français devient le budget mensuel alimentaire dans certains pays. Ces autres pays méritent bien de profiter de ce qu'ont profité les Français lorsqu'ils trouvaient ça "utile", même si aujourd'hui ils préfèrent un produit plus "plat préparé".

Je ne vois pas pourquoi tu stigmatises les français... ça diminue ta démonstration que je partage pour le reste.
Je ne pense pas que les Belges soient en reste de ta constatation, comme tout le reste de l'Europe et au-delà.
Dans tous les pays, y compris ici et chez toi, il y a des gens qui ne pourront pas mettre 100 euros, ni même 20, et je ne pense pas non plus que lorsque la principale préoccupation est de se nourrir chaque jour, le choix d'un micro ou d'un langage soit si important.

[f6exb]

Pour ceux qui veulent télécharger le cours, dépêchez-vous avant une possible clôture du site.

[Bigonoff]

Un code C bien écrit, comme tout langage structuré, est organisé en bibliothèques de fonctions (ADC, CAN, uart, FSM, etc) qui décrivent des fonctions haut niveau, parfaitement transposables vers un micro (8, 16 ou 32 bits) quelconque.

Ben oui, tu tombes droit dans l'erreur que j'ai pourtant explicitement indiquée: Le C n'est PAS PORTABLE pour un microcontrôleur, ce sont les LIBRAIRIES qui permettent de donner l'illusion de la portabilité.
Parce que soit tu utilises des librairies "toutes faites" dont tu ne peux agir sur le contenu... soit tu écris tes propres librairies, ce qui t'oblige à plonger dans le coeur du micro... avec du code non portable.

Les librairies sont propriétaires d'une part, différentes d'un compilateur à l'autre d'autre part, et de plus ces mêmes librairies existent... pour le langage d'assemblage. Chez Microchip, par exemple (puisqu'on parle PIC à la base) des tonnes de librairies fonctionnelles sont fournies en code source.... d'assemblage.

Moi, j'écris moi-même mes librairies, parce que je vais souvent aux limites de ce qu'on peut exploiter, et si je te copie un extrait d'une de mes librairies en C concernant un micro moderne 32 bits, je te souhaite bien du plaisir pour y trouver la moindre trace de portabilité.
La syntaxe du langage est portable... rien d'autre, surtout sur un microcontrôleur.

Si tu veux du vrai "portable" alors ça existe, mais souvent sur micros avec OS, genre framework dotnet ou plateforme Java... mais pas vraiment grâce au langage de programmation, mais grâce au langage intermédiaire recompilé à la volée par un compilateur JIT (Just In Time).

Dire qu'il est difficile de se passer de l'assembleur n'a pas vraiment de sens, tout dépend du contexte et du besoin (des exigences) que réclame l'application.

Comme tu dis: ça dépend du contexte et des besoins. Du coup, comprends que par conséquent dire que ça ne sert à rien n'a pas non plus de sens.
J'ai bien précisé dans mon précédent commentaire que c'était utile mais pas indispensable. En fait, ça dépend surtout des connaissances qu'on cherche à acquérir sur le sujet: Si je transpose il y a des tireurs sportifs qui tirent mais n'en ont rien à cirer de la façon dont on recharge une balle.... et d'autres qui vont étudier le sujet pour se peaufiner leurs balles aux petits oignons.

Toi (ou quelqu'un d'autre), tu n'as pas envie d'étudier et/ou d'utiliser le langage d'assemblage? Ben tu as parfaitement raison: Si à toi ça ne sert à rien il serait débile de d'imposer cette contrainte à toi-même. Il faut juste imaginer que ça peut être utile à d'autres... pour des raisons qui les concernent.

Note cependant une anecdote amusante: J'ai déjà dialogué par mail avec des personnes qui disaient que c'était inutile de parler de langage d'assemblage, pour toutes sortes de raisons, dont certaines évoquées ici. Cependant, en creusant dans la conversation, je me suis aperçu qu'en fait, ces personnes... étaient déjà passées par la case "assembleur" au cours de leurs études: Bref, certains trouvent ça "inutile", MAIS quand ils lisent un datasheet.... ils le lisent avec les connaissances qu'ils ont déjà acquises... et qui incluent les bases qu'ils estiment aujourd'hui inutiles... pour les autres. Ça m'a toujours un peu interpellé.

Juste pour info: Toi-même, as-tu déjà étudié un langage d'assemblage?

Je ne vois pas pourquoi tu stigmatises les français... ça diminue ta démonstration que je partage pour le reste.

je ne stigmatise rien du tout, où diable as-tu imaginé ça???? Je dis que bien souvent ceux qui postent sur des sites où on parle français ont tendance à penser qu'ils s'adressent à des Français ou des personnes "du même niveau de développement", et donc quand ils pensent "Il suffit d'utiliser ceci et de payer cela", ils oublient simplement que c'est plus simple pour eux que pour d'autres parties du monde. Ce n'est pas de la stigmatisation, c' est juste une remarque pour montrer que par défaut on a naturellement tendance à extrapoler sa propre situation. Tiens, tu veux une anecdote? Lorsque j'ai publié mes tout premiers cours, je les ai mis dans un fichier rar: J'ai reçu des tonnes de mails d'internautes africains qui me disaient: "On ne sait pas charger les cours parce qu'on n'a accès à Internet que via des cyber-cafés et on ne sait charger que sur une disquette". Du coup, j'ai du scinder mes cours en fichiers tenant sur une disquette (aujourd'hui c'est terminé avec les clés USB mais j'ai du faire ça durant des années). Comme quoi, ce n'est pas simple d'extrapoler la situation de gens dont on ignore tout: Mon "avantage" c'est que je n'ai pas besoin d'extrapoler, dès que je fais quelque chose de "non accessible" pour tous, hop je reçois immédiatement des mails, et j'essaye de rectifier.

Mes cours sont téléchargés partout dans le monde: La semaine dernière j'ai reçu un mail de Colombie, plusieurs d'Afrique noire, de pays de l'est etc. Et, pour info, je dis "Français", mais j'y assimile "Belges," Suisses" etc: C'était une image pour parler du niveau de vie des internautes.

et je ne pense pas non plus que lorsque la principale préoccupation est de se nourrir chaque jour, le choix d'un micro ou d'un langage soit si important.

Ben, tu ne penses pas... mais tu as tort. J'ai reçu des tonnes de mails de personnes du monde qui me disent "merci pour vos cours, on n'a pas les moyens de s'acheter un livre". Et également des tonnes de mails de gens qui me disent "Je trouve des 16F84 mais pas des 18F". Ce n'est pas parce que des gens sont pauvres qu'ils n'ont pas envie de s'instruire, bien au contraire. Et la plupart de ces internautes ne cherchent pas à se faire un montage rigolo pour le fun, ils veulent apprendre pour se sortir de leur pauvreté.

Bref, j'ai un retour réel de ce que veulent les internautes sur le sujet dont on parle. C'est du reste pour ça aussi que mes cours évoluent, j'essaye de prendre en compte ce qu'on me demande.

Le C est de (très loin) le langage du monde embarqué

Ben non, tu continues d'extrapoler ton propre cas. Par exemple il y a des milliers de développeurs qui font de l'embarqué sous Android, ils n'en ont rien à cirer du C, c'est soit Java soit Kotlin, soit plus rarement C++.
Dans le monde des micros puissants, c'est plutôt plus souvent C++ que C.
Ceci pour ne prendre que deux exemples.

Le C est certes très utilisé, mais ce n'est pas le seul langage. Sans compter que ce langage est une véritable passoire et que lorsqu'on veut l'utiliser à l'extrême on se retrouve en fait à manipuler le code... comme si on programmait directement en langage d'assemblage.

Pire, je dirais même que pour bien programmer efficacement en C.... il faut avoir compris comment ça va se traduire niveau micro. Par exemple si tu copies un tableau d'octets de taille conséquente (des trames Ethernet, par exemple), il est plus efficace de faire des copies par blocs de 4 octets, donc en "trompant" le compilateur pour lui faire croire qu'il manipule des entiers. Pour faire ça, il faut comprendre ce qui se passe derrière. Pareil si on crée des fonctions de librairies avec plusieurs paramètres: Il faut savoir le nombre de registres internes du processeurs qui vont être affectés au passage des paramètres avant que le compilateur ne soit contraint d'utiliser la pile, ce qui est gourmand. De nouveau, ça nécessite de comprendre les processus bas-niveau.

Alors, est-ce que tous ceux qui programment ont besoin d'optimiser jusqu'à ce genre de choses? Bien sûr que non, surtout lorsqu'on voit les micros utilisés sur le net par rapport aux besoins réels. Par contre, est-ce que c'est utile de savoir le faire? Et bien moi je pense que oui, et donc je pense "légitime" d'avoir envie d'étudier le langage d'assemblage sur un micro simple.

Programmer tout en assembleur ne sert strictement à rien aujourd'hui

Ne sert à rien... pour toi.
Manifestement, ça sert toujours à d'autres. Mon système domotique "Domocan CE" est intégralement écrit en langage d'assemblage, et personne ne s'en plaint. Écrire ça en C aurait été pour le moins hasardeux, vu les contraintes temporelles.

Après pour l'efficacité ça dépend plus de la qualité du programmeur, de sa formation sur le micro, pas du langage.

Ben, "de sa formation", ça inclut, pour moi, les bases en programmation "machine".

C'est un fait pas un avis perso

On appelle ça "un argument d'autorité", pas glop!

Sinon, j'ai précisé ce qui précède mais ce n'est nullement une "attaque" ni une "défense", c'est juste pour préciser ma position et montrer qu'il n'est pas toujours simple de s'extraire de son cas personnel pour tenter d'imaginer les besoins des autres: J'ai un avantage sur toi, c'est que je suis rappelé à l'ordre par mails dès que je fais de fausses suppositions;

Pour ceux qui veulent télécharger le cours, dépêchez-vous avant une possible clôture du site.

Pas d'inquiétude, le site n'est pas encore fermé. En outre les cours se trouvent un peu partout sur le net, et même si le site est down, les liens de téléchargement resteront fonctionnels. Au pire je republierai ailleurs.

Merci à tous pour le soutien ici et durant toutes ces années

[paulfjujo]

bonjour,



je suis tout à fait d'accord que l'ASM reste indispenssable pour les MCU .
d'autant que la portabilité en C est loin d'etre parfaite entre differents type 16F,18F
et que meme elle ne l'est plus du tout avec les tres rescent PIC comme la serie 18FxxQ10
avec MikroC. obligé de passer par l'ASM ou MPLABX et XC8

Je suis mme souvent confronté à utiliser de l'ASM dans un programme en C
on a heureusement cette possibilité sous mikroC
exemple :
UART3 (100% en ASM) avec UART1 et UART2 hardware (en C)
Multiples Registreq à decalage 96 bits
..

pour moi, le langage C est plus efficace avec les differents Microprocesseurs que les Micro Controleurs.
et in fine, dans ce langage C
on retrouve quasiment tous les registres du MCU
on fait donc deja plus ou moins de l'ASM , en C , avec des mnemoniques differents.

Les codes des librairies du compilateur ne sont pas accessibles..
mais on peut recrerer les notres via un codage plus pres de l'ASM que du C

il faut dire que chaque nouveau MCU a ue datasheet de 600 à 800 pages ..
avec des interfaces hardware de plus en plus cossu
Cette partie Hardware simplifiant beaucoup la programmation
qui est d'office placée à un plus haut niveau , qui fait tendre l' ASM vers un langage dit , evolué.

Ce ne sont pas les adeptes de Fantaspic.fr qui me contredirons , avec les Pro ASM
Nota: Meme si j'utilise mikroC, je ne renie pas mon appartenance aussi à l' ASM de mes debuts.

Merçi Bigonoff

[jiherve]

bonsoir
je pense qu'Unitrode sous entend code certifiable sous le terme embarqué et pour çà il n'existe que 3 possibilités à ma connaissance:
Assembleur, C (C++ ?), ADA.
De toutes façons quelque soit le langage évolué les couches basses seront écrites en assembleur et donc cela ne sera pas du tout portable, par contre on peut faire en sorte que ces couches basses partagent un formalisme constant d'un µC/µP à un autre, exemple le "printf " qui fait nécessairement appel au ressources particulière du processeur ( dieu sait si les UART peuvent être implémentés de façon différentes d'un processeur à un autre) est normalisé.
Mais la connaissance de l'assembleur et de l'architecture du processeur sont effectivement indispensables si l'on veut pouvoir être efficace
JR

[Vincent PETIT]

Salut,

je pense qu'Unitrode sous entend code certifiable sous le terme embarqué et pour çà il n'existe que 3 possibilités à ma connaissance:
Assembleur, C (C++ ?), ADA.

Ce sont plutôt des recommandations, exemple EN 61508 (Nucléaire & Oil & Gas) . On peut quand même s'y aventurer avec un autre langage mais.... (va falloir en faire des démonstrations)



Ici on voit que le C avec des règles de codage MIRA-C, sont hautement recommandé pour du SIL1, recommandé par SIL mais il y a mieux avec ADA et pour SIL3 et 4 le C avec règle est sans recommandation (charge au client de faire une démonstration poussée de fiabilité). Pour la DO174 (l'équivalent mais pour la défense & aérospatial) je ne l'ai jamais eu en main.

[Unitrode]

ADA est orienté objet et intervient préférablement sur les couches haut niveau système, c'est hors cadre du sujet dont nous parlons ici (code embarqué bas niveau, driver de périphériques, gestion de sous systèmes), mais Vincent PETIT et jiherve ont vu juste sur les contraintes industrielles et la méthodologie que cela requiert.
J'ai bien conscience que cela ne peut être compris sur un forum de hobbystes, sans vouloir vexer personne.
Juste que voir le C à travers des IDE grand public ou pratiquer sur des micros non certifiés SIL (comme Microchip par exemple) n'y aide pas vraiment.