Formation aux PIC

Loading thread data ...

Guillaume a écrit :

Puisque le polémique tourne autour du langage utilisé, voici mon petit 1% :

je suis entré dans le monde des pic par l'assembleur (merci biggonof), par ce que c'est le langage que j'avais appris à l'école (dans le temps...). J'ai été tout a fait satisfait d'avoir ces compétences tant que je restai aux pic16, mais maintenant mes besoins m'obligent a passer aux pic18, et là il faudrait plutôt que je connaisse le C, et a presque 40 balais et autre chose a faire dans la journée ... apprendre un nouveau langage : bonjour la galère !!! (au passage, si quelqu'un connait un équivalent des cours de biggonof pour le C : je suis preneur !)

Donc mon conseil : laisse tomber le basic et l'assembleur passe au C tout de suite !

Laurent

Reply to
Laurent CLAUDE

"Stephane Legras-Decussy" a écrit

======== Bien sûr, seulement pour ceux qui tiennent à y rester. ( J'en connais qui ont débutés même pas en assembleur mais en langage machine "brut" (notation polonaise HPxxx) et qui ont dépassé le C en suivant tranquillement "le progrès" ... )

Reply to
maioré

========= Ben oui "break" n'est pas une instruction "honteuse" réservée aux débutant , switch( ... break;

Reply to
maioré

Oh!

Ecire en C ce ne serait pas plutôt de la fainéantise ?

De toutes façons, je me répète, impossible de programmer les PIC sans connaitre les différents registres.

Maitrise les qq instructions de base est certainement plus facile que de se lancer dans les dédales tortueux du C...

Il n'y a pas plus de frime à maitriser l'assembleur du PIC que de snober le monde parce que l'on écrit du C.

jj

Reply to
jj

s

e/

Il semblerait que son utilisation soit recommand=E9 dans un 'switch' ;-)

--

-Stan

Reply to
Stan

maioré se fendait de cette prose :

Quel rapport entre le langage machine et la notation polonaise ???

--
LeLapin
Reply to
LeLapin

maioré wrote: .....

La prog des machines HP ça n'est pas franchement du langage machine brut, il ne faut pas non plus exagérer ;-)

J'ai débuté sur de ls TI-57 (celle avec 50pas ET 8 mémoire, la vraie avec les leds rouges) ensuite j'ai connu le HP-15C, derrière j'ai touché suffisament à du PC-1401 (de chez Sharp) pour aller jusqu'a programmer un desassembleur .... en langage machine, du vrai, celui où pour afficher un mot t'es obligé de te fader l'allumage des pixels un par un (... ou de trouver la routine qui le fait !! ;-D ), ça n'avait franchement rien à voir avec ce que tu peut faire avec une HP (Le langage de cette dernière reste de l'interprété !). A la fin j'arrivais même à te pisser directement le code d'un truc simple en hexadécimal.

Enfin, 'ai eu (et j'ai encore !) une HP28, toujours pareil, le langage reste de l'interprété, même si c'était diaboliquement optimisé ! Là aussi il était possible de programmer directement dans le langage de la bète, mais ça demandait une gymnastique bidouilleuse pas franchement tentante.

Tout ça pour dire qu'au final la programmation des calculettes en RPN n'a rien à voir avec le langage machine si ce n'est de devoir charger les valeurs dans les registres avant d'effectuer l'opération voulue.

Ok, programmer en assembleur (ou pire en LM quand il n'existe pas d'assembleur) c'est bourrin. Mais plus que de chercher à en tirer de la fierté c'est sur la performance du programme obtenu qu'il y a vraiment de quoi être fier. Avec nos machine actuelles, si un windows était programmé en assembleur ça n'aurait vraiment plus rien à voir question performance (et accessoirement ça occuperait notablement moins de place ;-D )

Franchement sur un truc qui me parait aussi simple qu'un PIC (gestion d'entrées et de sorties), l'assembleur me semble vraiment optimal et ce serait dommage de s'encombrer de trucs lourds lorsque l'on peut s'en contenter sans risquer la crise de nerfs.

--
Eric
Reply-to valide, laissez tel quel !
 Click to see the full signature
Reply to
Eric PETIT

"jj" a écrit dans le message de news:4ab27a39$0$23486$ snipped-for-privacy@news.orange.fr...

C'est tout simplement bien plus productif que l'assembleur. Dépassé une certaine quantité de code, l'assembleur ce n'est plus maintenable facilement, et souvent illisible en général par une autre personne que celle qui l'a écrit voir même l'auteur original, quelques années après qui ne s'est jamais demandé pourquoi il avait codé ça ou ça ou fait telle astuce :-)

Les registres n'ont rien à voir avec le langage de programmation, on accède aux registres des périphériques internes (timer, i2c, port E/S, registres de config, etc) aussi bien en C qu'en assembleur, nul besoin de connaitre les registres "cpu" pour coder en C (je différencie bien le cpu/alu dont on a pas besoin de savoir comment il fonctionnent et les périph où là forcément, sans datasheet on fait pas grand chose, que ça soit en asm ou en C)

J'ai commencé à programmer au début des années 80, en assembleur parce que c'était la mode et que les compilos C ne courraient pas les rues, l'assembleur est le langage de programmation le plus compliqué et le moins pratique qui soit, n'importe quel autre langage c'est de la rigolade à coté.

Le C est d'une simplicité enfantine et il est universel, toujours utilisé depuis 1972...

Meuh non que vas-tu chercher là, je ne snob pas ceux qui codent en assembleur, j'ai fait 10 ans de 68000 archarné et j'aimais ça, je dit simplement qu'en 2009, apprendre l'assembleur sur une architecture particulière est une perte de temps et que quitte à apprendre un langage, autant apprendre le C c'est plus utile, et on évite de "s'enfermer" dans un type d'architecture, par exemple quand je faisait du 68000 je ne pouvais pas concevoir de programmer sur du intel, leur assembleur étant trop imbitable et le codage en little-endian quelque chose que je n'ai jamais pu concevoir trop chiant à débugger, ma conclusion était donc que intel c'est de la merde, ce qui était très con de ma part, ils n'étaient pas pire ni mieux, juste que n'étant pas habitué à leur assembleur ne les avais écartés de ma vue vite fait :-) alors qu'en C on jongle de l'un à l'autre les doigts dans le nez et on en a rien à cirer de la façon dont sont rangés les octets ou si le processeur est 8, 16, 32 ou 64 bits (à l'alignement des pointeurs près).

Bien sur il faut apprendre le fonctionnement des timers,E/S,paramétrages, etc suivant les modèles mais ça ça vaut pour n'importe quel modèle et franchement ils se ressemblent tous à quelques détails pres, quand tu connais la logique des microcontroleurs/microprocesseurs, en quelques minutes tu peux lire n'importe quel datasheet de n'importe quel constructeur t'es pas perdu, savoir que pour régler le diviseur du timer X il faut mettre le 3ème bit du registre Y à 1 n'a rien à voir avec le langage, ça se fait aussi bien en C qu'en asm.

j'ai fait énormément d'assembleur 68000, le jour où je suis passé au C ça a été la délivrance, sans déconner, c'est là que j'ai commencé à faire des choses beaucoup plus interressantes de mon point de vue, non pas parce que je ne savais pas le faire en assembleur, mais tout simplement parce que ça représentait un boulot monstrueux à coder.

Le nombre de registres cpu, le registre d'état, les type d'adressages, et tous les trucs chiant au possible à faire en assembleur on les oublie très vite et sans le moindre regret, comme faire un appel de fonction en passant plusieurs paramètres sur la pile, pour les dépiler ensuite dans la fonction, on a vu plus marrant, gérer la sauvegrade/restauration du contexte lors des interruptions, ou même faire un bête "printf" en assembleur c'est pas passionnant, en C ça prend 5 secondes le temps de taper 1 ligne de code... ou même programmer un dsp en asm, faut être un peu fou :-)

En C on se concentre uniquement sur l'algo et pas sur les détails et on se surprend à faire des programmes extremement complexes et qui font énormémént de choses, même en étant débutant en très peu de temps.

Ensuite une fois que le prog tourne, ok on peut faire du profiling et optimiser par ci par là avec un peu d'assembleur quelques % de code à la main si vraiment ça sert à quelque chose, maintenant les cpu sont tellement puissants que ça ne sert à rien d'aller grapiller 2 cycles d'horloge par ci,

4 par là et devoir repasser à l'assembleur devient de moins en moins utile, je dis pas que ça sert à rien, mais ça sert de moins en moins.

L'assembleur a l'air plus facile au tout début, parce qu'en 3 ou 4 instructions on fait clignoter une led sur une sortie c'est ludique ok, et en C ça demande un peu plus d'énrobage et ça a l'air compliqué au premier abord pour faire la même chose. Mais une fois que le squelette est fait et qu'il faut coder un comportement complexe on va bien plus vite en C.

Comme je disais au début, la vraie utilité du C en dehors qu'on va plus vite, c'est que c'est universel, ça sert partout, même sous windows, linux, mac, une fois qu'on sait programmer en C on fait n'importe quoi sur n'importe quelle plateforme, que ça soit nu vieux clou ou le tout dernier processeur de la mort qui vient de sortir, quelqu'un qui sait programmer en C sur son pic 8 bits, il peut aller aussi bien lire du code C à destination d'un atmel 32 bits ou le code du noyaux linux sur archi ia64 par exemple ou même porter du code d'un cpu à l'autre sans trop de difficultés, en asm, ben faut tout réécrire...

Pascal

Reply to
Pinball-Man

============ La HP9100 (pas une machine d'écolier étant donné son poids ) cent nonante six pas de programme, mémoire tores, cartes magnétiques ... n'en'etait pas loin ...

Reply to
maioré

"LeLapin" a écrit

============ C'est vrai, que seuls les inities peuvent comprendre le rapport

Reply to
maioré

+1 comme il a été dit plus haut, à part quelques lignes très spécifiques en asm, et encore plusieurs compilos dispos avec forum, exemples etc... j'utilise CCS (
formatting link
)

Philippe

Reply to
Philippe

maioré wrote:

Stan wrote:

Ouais ouais, bien entendu :P Je voulais dire : "dans une boucle", mais... Vous l'auriez compris ^^

Reply to
cLx

maioré se fendait de cette prose :

Désolé, j'ai commencé l'assembleur en 78 (et assemblé à la main au début), et je ne vois pas le rapport avec la notation polonaise. Peux-tu expliquer ?

--
LeLapin
Reply to
LeLapin

"Stan" a écrit dans le message de news: snipped-for-privacy@j9g2000vbp.googlegroups.com...

j'utilise très souvent break pour sortir d'un for( ) après condition...

Reply to
Stephane Legras-Decussy

"Laurent CLAUDE" a écrit dans le message de groupe de discussion : 4ab2736f$0$15162$

+1 (enfin +0.5)

Quelque connaissances en assembleur restent quand même utiles pour écrire de petite routines hyper optimisée (surtout en ce qui concerne la gestion de interruptions par exemple)

Maintenant moi, a mon avis C ou Basic ça n'a pas vraiment d'importance à ce niveau. Avec un bon compilateur et si on ne code pas avec les pieds, que ce soit écrit en C ou en Basic (je parle du basic dans sa version moderne) donnera au final à peu prêt le même code assembleur. Donc jusqu'a preuve du contraire, pour moi dire que l'un et plus optimisé que l'autre pour ce genre d'application, c'est de la querelle de cloché et du trollage en règle. (on parle bien de compilateurs pour le RISC des PICs et non pas de je ne sais quelle connerie d'interpréteur embarqué) Moi j'ai choisit le compilateur basic Proton+ parce qu'après en avoir essayé plusieurs il me semblait le plus performant et le plus complet, avec une philosophie de programmation proche de celle du VB qui je connaissais déjà bien (et non j'ai jamais eu besoin de faire de GOTO en VB, puisque c'est visiblement ce que l'on reproche au Basic).

Maintenant je suis d'accord, quelqu'un qui n'a aucune connaissance particulière en programmation et qui souhaite se lancer à tout intérêt à partir sur le C, en ce qui concerne la programmation sur PIC, comme je l'ai dis ça ne fait pas une énorme différence (on ne peut pas reprocher au C d'être plus compliqué que le Basic pour ce genre d'application) et ce qui sera acquis comme connaissance sur le PIC sera toujours utile et plus universel pour programmer sur PC ou autre.

Reply to
AGL

Moi, je trouve que la vraie mauvaise id=E9e dans cette histoire, c'est le "PIC". D'abord de quel PIC parle-t-on : PIC 16 ? "assembleur facile car seulement 35 instructions RISC =E0 apprendre "??. "35 instructions" signifie plut=F4t un jeu d'instructions tr=E8s "pauvre" et avec plein de pi=E8ges. Bon exemples de Doumai :

formatting link
bleur/Assembleur.htm . Risc- S=FBrement pas. Lorsque la notion de "Risc" est apparue dans les ann=E9es 90, l'id=E9e =E9tait qu'un compilateur pouvait produire un code plus efficace avec des jeux d'instructions r=E9duits bie adapt=E9s. Oui, mais l'asm PIC16 est tout sauf adapt=E9 aux compilateurs pour langages de haut niveau. L'assembleur PIC 16 s'apparente plus =E0 du microcode qu'=E0 un jeu d'instructions RISC. Bref, choisissez d'abord un =B5C r=E9cent et performant et si vous voulez commencer absolument en Basic, essayez Bascom pour AVR ou embrayez directement vers le C (il n'y a pas besoin d'=E9crire du code en asm pour les interruptions), et quasi tous les micros ont leur compilateur C gratuit, ce qui n'est pas le cas du basic.

th. (GCC sur ColdFire)

Reply to
thm

alors qu'il est tellement plus élégant de donner à la variable de la boucle la valeur finale pour en sortir ;-) for (i=0;i

Reply to
Philippe

"Eric PETIT" a écrit dans le message de news: 4ab29a3a$0$11330$ snipped-for-privacy@news.free.fr...

le problème c'est le programmeur lambda est persuadé de programmer asm à la main mieux que ne le ferait un compilateur C...

hors c'est faux... ça fait mal à l'ego mais bon...

meme en C on retrouve le meme syndrome, on peut écrire du C compact et difficilement lisible...

ça flatte le programmeur mais ça compile en donnant exactement le meme asm que le C écrit en version "neuneu"....
Reply to
Stephane Legras-Decussy

"AGL" a écrit

============ Le gros avantage du "C" est l'usage des fonctions avec passage et retour d'arguments de valeur Que l'on peu stocker dans des fichiers " include " et utiliser universellement dans n'importe quel autre nouveau programme (elles ne se compilent que si elles peuvent etre appelées par le programme "main")

Reply to
Pierre_Edouard

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.