Formation aux PIC
Guillaume
auriez vous une rï¿œfï¿œrence d'un 'bon'livre de formation aux PICs,
programmation en Basic ?
j'en ai vu quelques uns mais tous m'ont semblￜ 'formation' avec
'faisons ensemble'. donc on fait les exemples et aprï¿œs on ne peut aller
plus loin parce que les rￜgles gￜnￜrales et la mￜthode n'ont pas ￜtￜ
expliquï¿œs.
Merci
rvlegran
Bonjour
AMHA il faut distinguer au moins 2 choses (et cela concerne tous les ï¿œc
)
- bien connaitre et comprendre l'architecture de la cible
- bien connaitre les limitations du langage dit haut niveau utilisￜ.
Vous semblez avoir choisi la prog de pic en basic, on peut
effectivement faire de belles choses, mais cela necessite avant tout de
l'apprentissage et etre conscient des limites.
Ne serait ce dￜjￜ que dans le choix du "basic" utilisￜ (et des pic
supportï¿œs).
J'ai lachￜ la prog pic depuis dￜjￜ un certain temps
mais j'avais fait testￜ/evaluￜ (et donc ma reponse n'est peut etre plus
up to date :oￜ )
les produits de Crownhill (proton)
et Mikrobasic
Chacun avait/ont evidemment des qualitï¿œs et des defauts
Crowhill sortait gagnant des benchs pour simplement utiliser le MASM
officiel de Microchip .
Pour le reste ET apres apprentissage les doc fournies permettent dￜjￜ
un beau decrassage dans l'apprentissage.
Si vous faite cela dans une demarche amateur, l'important est plus dￜjￜ
d'avoir "un bon board d'experimentation" que de choisir ou se
polariser sur un langage
Rvl
yvon
"Guillaume" <gtch...@free.fr> a ï¿œcrit dans le message de
news:4ab0d143$0$27802$426a...@news.free.fr...
tu as "s'initier ￜ la programmation des picbasic" de Guy Isabel (ETSF)
librairie DUNOD
complet .
amicalement yv
>
Pierre_Edouard
"Guillaume" <gtch...@free.fr> a �crit
> bonjour
>
> auriez vous une r�f�rence d'un 'bon'livre de formation aux PICs,
> programmation en Basic ?
> j'en ai vu quelques uns mais tous m'ont sembl� 'formation' avec 'faisons
> ensemble'. donc on fait les exemples et apr�s on ne peut aller plus loin
> parce que les r�gles g�n�rales et la m�thode n'ont pas �t� expliqu�s.
============
Pour ce former � la programmation en basic il faut commencer par se former
"au basic" choisir un basic de base et "travailler" sur un PC pour se
familiariser avec les instructions de sa structure et de leur utilit�. (
On peut avec un PC simuler les fonctions principales d'un �C comme les
entr�es et sorties , les interruptions l'affichage et bien s�r les
algorithmes ...)
Ensuite, choisir le logiciel d'exploitation basic que tu choisiras
d'utiliser pour la famille "PIC" et s'exercer sur l'outil
Note aussi que tu peux �galement commencer directement avec le langage "C" ,
pas plus difficile � assimiler
jj
je pense que c'est une erreur commune que de croire que l'on peut
programmer un pic en basic sans autres connaissances.
en effet, tu devras utiliser les fils d'entrï¿œe sortie, les registres
internes, temporisateurs etc, et lￜ, la connaissance du PIC cible est
incontournable.
Lorsque tu sera capable de faire des petits programmes simples, du genre
faire clignoter une led, alors tu pourras passer au basic.
JJ
vede
> bonjour
>
> auriez vous une référence d'un 'bon'livre de formation aux PICs,
> programmation en Basic ?
> j'en ai vu quelques uns mais tous m'ont semblé 'formation' avec
> 'faisons ensemble'. donc on fait les exemples et après on ne peut aller
> plus loin parce que les règles générales et la méthode n'ont pas été
> expliqués.
>
> Merci
bonjour à tous,
je ne connais pas proton...
mais l'aide et les exemples de MikroBasic
sont une trés bonne base...pour débuter avec
les pics en basic...
vede
;O]
Philippe
Dans l'ignorance du pic et du basic, je pense qu'il faut oublier le
basic pour programmer d suite en assembleur. Les 35 instructions restent
accessible, le reste n'ï¿œtant que de l'analyse en assembleur comme en
basic..
A+
--
02ￜ44'45"E 45ￜ30'50"N
Philippe Vessaire Ò¿Ó¬
cLx
Les 35 instructions, c'est pour les petits pics de la gamme 16f. Maintenant,
avec les 18f et autres, il y en a plus, pas ï¿œnormï¿œment beaucoup plus, certes,
mais personnellement, je prï¿œfï¿œres quand mï¿œme programmer en C++, c'est plus
lisible et maintenable, et surtout portable d'un pic ￜ l'autre, et mￜme sur
la gamme au dessus. Et avec le compilateur que j'utilise, c'est intￜgrￜ ￜ
MPLAB et trï¿œs performant (si on sait ce que l'on fait nï¿œanmoins, l'exemple
type est un dï¿œcalage de beaucoup de bits dans une boucle, comme les pics (les
16f en tout cas) ne sait dï¿œcaler que de 1 bit, il va faire une boucle pour
les n dï¿œcalages, donc ï¿œa fait une boucle imbriquï¿œe et c'est pourri ;)
Donc faut toujours connaï¿œtre un minimum la cible pour ne pas faire n'importe
quoi, quel que soit le langage, voire jeter un coup d'oeil sur le code gￜnￜrￜ
aprï¿œs.
--
cLx
era
Le livre:
"S'initier ￜ la programmation des PIC"
"Basic et Assembleur"
de Alain REBOUX
Stephane Legras-Decussy
"Philippe" <No....@ailleurs.net> a �crit dans le message de news:
2783341.kQq0lBPeGt@GastonCoute...
> Dans l'ignorance du pic et du basic, je pense qu'il faut oublier le
> basic pour programmer d suite en assembleur. Les 35 instructions restent
> basic..
faire de l'assembleur RISC c'est un crime
contre l'humanit�... c'est le boulot d'un
compilateur...
et sinon je vois pas l'interet du basic,
le C �tant l'id�al pour programmer des
uC...
jj
s'est pas fait tout seul !
JJ
vede
<killyours...@yesnocancel.com> wrote:
> "Philippe" <No.S...@ailleurs.net> a écrit dans le message de news:
> 2783341.kQq0lBPeGt@GastonCoute...
>
> > Dans l'ignorance du pic et du basic, je pense qu'il faut oublier le
> > basic pour programmer d suite en assembleur. Les 35 instructions restent
> > basic..
>
> faire de l'assembleur RISC c'est un crime
> compilateur...
>
> et sinon je vois pas l'interet du basic,
> uC...
bonsoir à tous,
dans ce cas...
pour débuter en asm avec les pics...
il existe une bible...
les cours de Bigonoff...
vede
;O]
ps sinon le bouquin d'Alain REBOUX est trés sympa...
et lui aussi (il répond aux questions par mail)...
vede
> 2783341.kQq0lBPeGt@GastonCoute...
>
> > Dans l'ignorance du pic et du basic, je pense qu'il faut oublier le
> > basic pour programmer d suite en assembleur. Les 35 instructions restent
> > basic..
>
> faire de l'assembleur RISC c'est un crime
> compilateur...
>
> et sinon je vois pas l'interet du basic,
> uC...
hi
>le C étant l'idéal pour programmer des uC...
là, va y avoir polémique...
ou c'est un troll ;O]
l'idéal...c'est l'asm... ;O]
à moins de vraiment maitriser
le pic... et ton compilo C...
vede
;O]
Pierre_Edouard
../..
> > Dans l'ignorance du pic et du basic, je pense qu'il faut oublier le
> > basic pour programmer d suite en assembleur. Les 35 instructions restent
> > basic..
>
> faire de l'assembleur RISC c'est un crime
> compilateur...
>
> et sinon je vois pas l'interet du basic,
> uC...
hi
>le C �tant l'id�al pour programmer des uC...
l�, va y avoir pol�mique...
ou c'est un troll ;O]
l'id�al...c'est l'asm... ;O]
� moins de vraiment maitriser
le pic... et ton compilo C...
=============
Ne penser exclusivement que "asm" est du bricolage, comme un menuisier qui
s'interdirait d'utiliser une scie �lectrique ou la raboteuse ...
En r�alit� il faut "tout" conna�tre �galement l'asm car parfois on
l'utilise (qui est aussi un langage traducteur du niveau bas ) pour cr�er
des fonctions particuli�res au sein d'un programme en langage de haut
niveau "C" ou analogue ou "plus" .
L'avantage pour un amateur, de commencer par un langage de haut niveau est
de ne pas gal�rer des heures et des jours sur un fichier ASM pour �crire le
fameux "Hello Word" cher aux asm'istes
Stephane Legras-Decussy
"vede" <ved...@gmail.com> a �crit dans le message de news:
99597e23-6a54-4528...@g23g2000vbr.googlegroups.com...
>l'id�al...c'est l'asm... ;O]
>le pic... et ton compilo C...
je pense qu'on ne peux pas g�n�raliser
le mot 'assembleur'...
il y a les CISC et les RISC...
les CISC c'est intel ou mieux motorola (freescale)...
l� ok �a se fait � la main, c'est plaisant...
j'en ai fait des centaines de lignes...
par contre les RISC des PIC, c'est absolument
imbitable... (m�me avec le super cours de bigonoff)
pour moi c'est obligatoire de faire du C sur
un PIC... et je ne vois pas le probl�me pour acc�der
au moindre recoin du micro puisque tous les registres
sont d�clar�s en une ligne, par exemple :
#include "p18f452.h"
ensuite c'est quand m�me super facile d'�crire
PORTBbits.RB0 = 1 ;
Stephane Legras-Decussy
"Pierre_Edouard" <xxp...@pecherie.fr> a �crit dans le message de news:
4ab14e98$0$17753$ba4a...@news.orange.fr...
> L'avantage pour un amateur, de commencer par un langage de haut niveau est
> de ne pas gal�rer des heures et des jours sur un fichier ASM pour �crire
> le
> fameux "Hello Word" cher aux asm'istes
par contre je ne vois pas du tout l'interet
de faire du basic... ce truc est compl�tement
obsol�te et c'est faux de croire que c'est
plus simple que le C...
on peut m�me faire des goto en C si on
est nostalgique...
Pinball-Man
news:4ab13a00$0$17762$ba4a...@news.orange.fr...
Sauf que celui qui a �crit le compilo, l'a fait en tenant compte du temps de
traitement de chaque instruction des possibilit� de r�organiser les
instructions suivant le pipleine et plein d'autres astuces que le commun des
mortel est totalement incapable de faire sur plus de 10 lignes de code
assembleur :)
Bref, programmer en assembleur �a ne sert absolument � rien � part sur des
cas tr�s sp�cifiques de quelques lignes de codes qui sont mieux optimis�es
par un humain que le compilo mais c'est rare, de toute fa�on un programme
tout en assembleur d�s que �a d�passe quelques centaines de lignes de code
c'est plus maintenable, par contre �a flatte l'�go "moi je sais programmer
en assembleur" :-).
Pascal
maior�
"Stephane Legras-Decussy" <killyo...@yesnocancel.com> a �crit dans le
message de news: 4ab17540$0$10847$426a...@news.free.fr...
>
> "Pierre_Edouard" <xxp...@pecherie.fr> a �crit dans le message de news:
> 4ab14e98$0$17753$ba4a...@news.orange.fr...
>> L'avantage pour un amateur, de commencer par un langage de haut niveau
>> est
>> de ne pas gal�rer des heures et des jours sur un fichier ASM pour �crire
>> le
>> fameux "Hello Word" cher aux asm'istes
>
> par contre je ne vois pas du tout l'interet
> de faire du basic... ce truc est compl�tement
> obsol�te et c'est faux de croire que c'est
> plus simple que le C...
Oui tout � fait, sauf pour les "anciens" qui ont d�but�s en basic et ont
tenu a y rester ...
>
> on peut m�me faire des goto en C si on
> est nostalgique...
Pas trop n�cessaire, mais certainement , pas de honte , seul le r�sultat
compte , d'ailleurs le
"langage final machine" est bourr� de go to's
Stan
> ========
> Pas trop nécessaire, mais certainement , pas de honte , seul le résultat
> compte , d'ailleurs le
Sauf que, ce qui est produit par le compilateur n'a pas pour finalité
à être relu.
Le processeur s'y retrouvera bien dans ses 'goto' ;
En revanche, le code _source_ est fait pour être compréhensible par
des humains, et là,
même si on peut programmer proprement avec quelques 'goto', ça
reste quand même une source d'erreurs au codage.
Il y a néanmoins des exceptions : en C, par exemple, dans certains cas
rares
vouloir éviter des 'goto' avec des 'if/else' ou des ruptures 'continue/
break' peut
rendre le source moins lisible.
--
-Stan
Stephane Legras-Decussy
"maior�" <.....@sndpa.fr> a �crit dans le message de news:
4ab1e2c4$0$12642$ba4a...@news.orange.fr...
> ===========
> Oui tout � fait, sauf pour les "anciens" qui ont d�but�s en basic et
> ont tenu a y rester ...
j'ai d�marr� en basic en 1985... quel bonheur
de passer � autre chose ! :-)
cLx
> Il y a n�anmoins des exceptions : en C, par exemple, dans certains cas
> rares
> vouloir �viter des 'goto' avec des 'if/else' ou des ruptures 'continue/
> break' peut
> rendre le source moins lisible.
Ah mais j'aime bien "break", moi ! :D
Laurent CLAUDE
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
maior�
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" ... )
maior�
"cLx" <clx...@gmail.com> a �crit dans le message de news:
h8tqao$c03$1...@news.trigofacile.com...
Ben oui "break" n'est pas une instruction "honteuse" r�serv�e aux d�butant
, switch( ... break;
jj
> des cas tr�s sp�cifiques de quelques lignes de codes qui sont mieux
> optimis�es par un humain que le compilo mais c'est rare, de toute fa�on
> un programme tout en assembleur d�s que �a d�passe quelques centaines de
> lignes de code c'est plus maintenable, par contre �a flatte l'�go "moi
> je sais programmer en assembleur" :-).
>
> Pascal
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
Stan
> > rares
> > vouloir éviter des 'goto' avec des 'if/else' ou des ruptures 'continue/
> > break' peut
> > rendre le source moins lisible.
>
> Ah mais j'aime bien "break", moi ! :D
Il semblerait que son utilisation soit recommandé dans un 'switch' ;-)
--
-Stan
LeLapin
>
> "Stephane Legras-Decussy" <killyo...@yesnocancel.com> a �crit
>>
>> "maior�" <.....@sndpa.fr> a �crit dans le message de news:
>> 4ab1e2c4$0$12642$ba4a...@news.orange.fr...
>>> ===========
>>> Oui tout � fait, sauf pour les "anciens" qui ont d�but�s en basic et
>>> ont tenu a y rester ...
>>
>> j'ai d�marr� en basic en 1985... quel bonheur
>> de passer � autre chose ! :-)
>========
> 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)
Quel rapport entre le langage machine et la notation polonaise ???
--
LeLapin
Eric PETIT
.....
> 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" ... )
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 !
Texte brut vivement conseill� !!
Pinball-Man
>> Bref, programmer en assembleur �a ne sert absolument � rien � part sur
>> des cas tr�s sp�cifiques de quelques lignes de codes qui sont mieux
>> optimis�es par un humain que le compilo mais c'est rare, de toute fa�on
>> un programme tout en assembleur d�s que �a d�passe quelques centaines de
>> lignes de code c'est plus maintenable, par contre �a flatte l'�go "moi je
>> sais programmer en assembleur" :-).
>>
>> Pascal
>
>
> Oh!
>
> Ecire en C ce ne serait pas plut�t de la fain�antise ?
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
:-)
> De toutes fa�ons, je me r�p�te, impossible de programmer les PIC sans
> connaitre les diff�rents registres.
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)
> Maitrise les qq instructions de base est certainement plus facile que de
> se lancer dans les d�dales tortueux du 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...
> 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.
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
maior�
"LeLapin" <Ip...@NOSPAM-neuf.fr> a �crit
>>
> Quel rapport entre le langage machine et la notation polonaise ???
C'est vrai, que seuls les inities peuvent comprendre le rapport
maior�
"Eric PETIT" <bidon...@petit-ecran.net.invalid> a �crit dans le message de
news: 4ab29a3a$0$11330$426a...@news.free.fr...
> maior� wrote:
> .....
>> 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" ... )
>
> La prog des machines HP �a n'est pas franchement du langage machine brut,
> il ne faut pas non plus exag�rer ;-)
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 ...
Philippe
> Donc mon conseil : laisse tomber le basic et l'assembleur passe au C
> tout de suite !
>
> Laurent
+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 ( http://www.ccsinfo.com )
Philippe
cLx
>>> rares
>>> vouloir �viter des 'goto' avec des 'if/else' ou des ruptures 'continue/
>>> break' peut
>>> rendre le source moins lisible.
>> Ah mais j'aime bien "break", moi ! :D
maior� wrote:
> Ben oui "break" n'est pas une instruction "honteuse" r�serv�e aux
> d�butant, switch( ... break;
Stan wrote:
> Il semblerait que son utilisation soit recommand� dans un 'switch' ;-)
Ouais ouais, bien entendu :P Je voulais dire : "dans une boucle", mais...
Vous l'auriez compris ^^
LeLapin
>
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
Stephane Legras-Decussy
"Stan" <t...@neuf.fr> a �crit dans le message de news:
764e9985-4dd9-4be4...@j9g2000vbp.googlegroups.com...
>Il semblerait que son utilisation soit recommand� dans un 'switch' ;-)
j'utilise tr�s souvent break pour sortir
d'un for( ) apr�s condition...
AGL
"Laurent CLAUDE" <laurent.claude_PAS_DE_PUB_@fr_PAS_DE_PUB_ee.fr> a ï¿œcrit
dans le message de groupe de discussion : 4ab2736f$0$15162$
> Donc mon conseil : laisse tomber le basic et l'assembleur passe au C tout
> de suite !
+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.
thm
le "PIC". D'abord de quel PIC parle-t-on : PIC 16 ? "assembleur facile
car seulement 35 instructions RISC à apprendre "??. "35 instructions"
signifie plutôt un jeu d'instructions très "pauvre" et avec plein de
pièges. Bon exemples de Doumai : http://pagesperso-orange.fr/doumai/Assembleur/Assembleur.htm
. Risc- Sûrement pas. Lorsque la notion de "Risc" est apparue dans les
années 90, l'idée était qu'un compilateur pouvait produire un code
plus efficace avec des jeux d'instructions réduits bie adaptés. Oui,
mais l'asm PIC16 est tout sauf adapté aux compilateurs pour langages
de haut niveau. L'assembleur PIC 16 s'apparente plus à du microcode
qu'à un jeu d'instructions RISC.
Bref, choisissez d'abord un µC récent 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'écrire 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)
Philippe
> j'utilise tr�s souvent break pour sortir
> d'un for( ) apr�s condition...
>
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<10;i++) {
...
...
if (condition) i=10; // � la fin de la boucle, tu sors
}
bon ok, moi aussi, je sors ;-)
Philippe
Stephane Legras-Decussy
"Eric PETIT" <bidon...@petit-ecran.net.invalid> a �crit dans le message de
news: 4ab29a3a$0$11330$426a...@news.free.fr...
> 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.
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"....
maior�
"LeLapin" <Ip...@NOSPAM-neuf.fr> a �crit dans le message de news:
XnF9C8AC470...@217.112.180.250...
Les operations math�matiques (particuli�rement chez HP) sur les premiers
ordinateurs (langage proche du langage machine , comme d'ailleurs certaines
calculatrices programmables un peu apr�s ) s'organisaient en notation
polonaise (inverse)
exemple:
2 [enter]
5 [enter]
+ [enter] resultat 7
3 [enter]
* [enter] r�sultat 21
Pierre_Edouard
"AGL" <chev...@lavache.com> a �crit
>
>
> "Laurent CLAUDE" <laurent.claude_PAS_DE_PUB_@fr_PAS_DE_PUB_ee.fr> a �crit
> dans le message de groupe de discussion : 4ab2736f$0$15162$
>> Donc mon conseil : laisse tomber le basic et l'assembleur passe au C tout
>> de suite !
>
> +1 (enfin +0.5)
>
> 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
============
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")
cLx
> 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"....
Exact ! J'avais essay� de faire avec deux entiers :
a = a^b;
b = a^b;
a = a^b;
Cela inverse a et b sans utiliser de variable temporaire, moins d'acc�s
m�moire et tout �a, en seulement trois cycles...
Gcc avec les options d'optimisations activ�es a compris la manoeuvre, a vir�
les xors et a cod� �a de fa�on diff�rente. Outch !
Et le pire, c'est que le test �tait au d�but, avant que je ne lui emp�che :
printf("%d %d\n", a, b);
a = a^b;
b = a^b;
a = a^b;
printf("%d %d\n", a, b);
... qu'il a remplac� par :
printf("%d %d\n", a, b);
printf("%d %d\n", b, a);
Le petit malin ;))
N'emp�che, c'est assez impressionnant, je trouve.
--
cLx
LeLapin
>
> "LeLapin" <Ip...@NOSPAM-neuf.fr> a �crit dans le message de news:
> XnF9C8AC470...@217.112.180.250...
>> maior� se fendait de cette prose :
>>
>>>
>>> "LeLapin" <Ip...@NOSPAM-neuf.fr> a �crit
>>>>>
>>>> Quel rapport entre le langage machine et la notation polonaise ???
>>>============
>>> C'est vrai, que seuls les inities peuvent comprendre le rapport
>>
>> 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
>==========
> Les operations math�matiques (particuli�rement chez HP) sur les
> premiers ordinateurs (langage proche du langage machine , comme
> d'ailleurs certaines calculatrices programmables un peu apr�s )
> s'organisaient en notation polonaise (inverse)
> exemple:
> 2 [enter]
> 5 [enter]
> + [enter] resultat 7
> 3 [enter]
> * [enter] r�sultat 21
Je ne consid�re pas les calculettes programmables comme des �P, ni m�me
comme des processeurs de minis et de mainframes, �a n'a rien � voir. Je ne
vois donc toujours pas le rapport. La syntaxe de tous les processeurs
depuis Von Neumann est sous la forme "instruction - cible et/ou objet".
Votre exemple serait donc (dans un code simplifi� imaginaire) :
Mov x, #2
Add x, #5
Mul x, #21...
Je ne vois rien de polonais l�-dedans, � la rigueur un peu de hongrois ;)
--
LeLapin
Stephane Legras-Decussy
"Philippe" <pasd...@aol.com> a �crit dans le message de news:
4ab3cde0$0$10016$426a...@news.free.fr...
> 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<10;i++) {
>
> ...
> ...
> if (condition) i=10; // � la fin de la boucle, tu sors
> }
>
wouha, super obfuscatoire !
si je dois recruter un programmeur, je disqualifie
un gars qui m'�crit �a... :-)
Stephane Legras-Decussy
"cLx" <clx...@gmail.com> a �crit dans le message de news:
h90koq$1i3$1...@news.trigofacile.com...
> N'emp�che, c'est assez impressionnant, je trouve.
pareil.... et encore plus impressionnant, l'intelligence
des gars capables d'�crire GCC...
Pinball-Man
news:4ab29a3a$0$11330$426a...@news.free.fr...
> 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.
Moi je trouve pas, pour le fun je colle ci dessous un programme en C que
j'ai �cris en 2 ou 3 soir�es, sur un tout petit 12F675 (8 broches) vraiment
minuscule, je pr�cise que je n'avais jamais approch� de pr�s ni de loin ce
composant, c'est un petit automate � �tat pour controler de fa�on soit
manuelle soit full-automatique suivant le temps d'appui sur les boutons,
avec gestion des e/s (capteurs, v�rins, boutons, un buzzer) l'ouverture et
la fermeture d'une capote �lectrique de voiture sans connaitre le moins du
monde l'assembleur de ce composant et comme vous pouvez le voir il n'y a pas
la moindre ligne de code asm("....") .
Je suis sur que m�me un d�butant saura comprendre comment �a marche sans y
passer des nuits parce que "visuellement" �a ressemble � quelque chose,
c'est simpliste et j'aurais pu le faire en assembleur, mais franchent, aucun
interet. et si demain ce composant n'est plus dispo, en adaptant quelques
trucs je peux passer � un autre mod�le qui n'a rien � voir ou m�me une autre
marque (atmel par exemple que j'aime bien aussi car tr�s performants) en
changeant juste les port io, l'initialisation et la gestion du timer qui est
un peu diff�rente.
#include <htc.h>
__CONFIG(CPD & PROTECT & BOREN & MCLRDIS & PWRTEN & WDTEN & INTIO);
// Tempo de passage en automatique
#define AUTO_TIMEOUT 20 // 2 secondes (valeur exprim�e en 1/10 de s car le
timer tourne � 10Hz)
// E/S
#define OPEN_PUSHED GPIO0 // ENTREE bouton 'ouverture' logique positive
#define CLOSE_PUSHED GPIO1 // ENTREE bouton 'fermeture' logique positive
#define CMD_BUZZER GPIO2 // SORTIE buzzer, logique positive
#define PUMP_STOPPED GPIO3 // ENTREE entr�e pompe, logique inverse (1 =
pompe arr�t�e, 0 = pompe en marche)
#define CMD_NOT_OPENING GPIO4 // SORTIE commande d'ouverture logique
NEGATIVE (1 = repos, 0 = simul bouton ouverture)
#define CMD_NOT_CLOSING GPIO5 // SORTIE commande de fermeture logique
NEGATIVE (1 = repos, 0 = simul bouton fermeture)
// Etats de l'automate
typedef enum STATE {
STOPPED, // A l'arret (capote ouverte, ferm�e ou arr�t�e en cours de
cycle)
MANUAL_OPENING, // Ouverture en mode manuel
MANUAL_CLOSING, // Fermeture en mode manuel
AUTO_OPENING, // D�but d'ouverture en mode auto apr�s tempo et bouton
toujours appuy�
AUTO_CLOSING, // idem en fermeture
FULL_AUTO, // mode s�quentiel enti�rement automatique, les boutons sont
relach�s
WAIT_RELEASE // mode s�quentiel ou manuel stopp� en cours de route, attend
le relachement des boutons
} STATE;
// d�clare les fonctions de chaque �tat
void stopped(void);
void manual_opening(void);
void manual_closing(void);
void auto_opening(void);
void auto_closing(void);
void full_auto(void);
void wait_release(void);
// Etat courant, � l'arret par d�faut au boot
static volatile STATE state;
// Timeout d'appui pour passer en auto apr�s X secondes
static volatile char timeout_auto;
// Programme principal
void main()
{
// efface les flags de reset
PCON = 0;
// tous les ports sont des E/S num�riques
ANSEL = 0b00000000;
// minimise la conso des ports analogiques inutilis�s
CMCON = 0b00000111;
// les options (presacler timer 0 au maxi 1:256) weak pullup
OPTION = 0b00000111;
// R�gle le sens des ports d'entr�e/sorties
TRISIO = 0b00001011;
// Weak pull up
WPU = 0b00000011;
// d�sactive les sorties
CMD_BUZZER = 0;
CMD_NOT_OPENING = 1;
CMD_NOT_CLOSING = 1;
// efface timeout
timeout_auto = 0;
// efface timer
TMR0 = 0;
// Etat par d�faut au reset
// on v�rifie que les touches ne sont pas appuy�es
state = WAIT_RELEASE;
// Boucle infinie
while(1) {
// efface chien de garde anti-plantage
CLRWDT();
// Effectue les actions suivant l'�tat de l'automate
// uniquement quand le timer 0 d�clenche pour limiter
// la vitesse de traitement (et les rebonds intempestifs)
// Le timer tourne � 1Mhz / 256 soit 3904Hz donc 195 = 20Hz
if(TMR0 > 194) {
// Reset du timer
TMR0 = 0;
switch(state)
{
case STOPPED:
stopped();
break;
case MANUAL_OPENING:
manual_opening();
break;
case MANUAL_CLOSING:
manual_closing();
break;
case AUTO_OPENING:
auto_opening();
break;
case AUTO_CLOSING:
auto_closing();
break;
case FULL_AUTO:
full_auto();
break;
case WAIT_RELEASE:
wait_release();
break;
}
}
}
}
// A l'arret
void stopped()
{
// Si on appuie sur ouverture ou fermeture (mais pas les 2 en m�me
temps...)
if((OPEN_PUSHED || CLOSE_PUSHED) && !(OPEN_PUSHED && CLOSE_PUSHED)) {
char closing;
// reinitialise le timeout de passage en automatique
timeout_auto = 0;
// active la fermeture / ouverture
closing = CLOSE_PUSHED;
CMD_NOT_CLOSING = ! closing;
CMD_NOT_OPENING = closing;
// change d'�tat et passe en manuel
state = closing ? MANUAL_CLOSING : MANUAL_OPENING;
}
}
// d�but de l'ouverture (en manuel)
void manual_opening()
{
// bouton d'ouverture relach�
if(! OPEN_PUSHED) {
CMD_NOT_OPENING = 1; // stoppe la commande d'ouverture
state = STOPPED; // change d'�tat passe � l'arret
}
else {
// ne passe pas en mode auto tant que la pompe n'a pas d�marr�
// ou si elle s'arrete en cours de route en mode manuel (fin de s�quence)
if(PUMP_STOPPED) {
if(timeout_auto > 0) {
timeout_auto = 0;
CMD_NOT_OPENING = 1; // stoppe la commande d'ouverture
CMD_BUZZER=1; // allume le buzzer
state = WAIT_RELEASE; // attend que le bouton soit relach�
}
}
else {
// incr�mente le timer du mode automatique
// si le timer auto est arriv� au bout, on passe en auto
if(timeout_auto++ >= AUTO_TIMEOUT) {
CMD_BUZZER = 1; // active le buzzer
state = AUTO_OPENING; // change d'�tat, passe en ouverture automatique
}
}
}
}
// d�but de la fermeture (en manuel)
void manual_closing()
{
// bouton de fermeture relach�
if(! CLOSE_PUSHED) {
CMD_NOT_CLOSING = 1; // stoppe la commande de fermeture
state = STOPPED; // change d'�tat passe � l'arret
}
else {
// ne passe pas en mode auto tant que la pompe n'a pas d�marr�
// ou si elle s'arrete en cours de route en mode manuel (fin de s�quence)
if(PUMP_STOPPED) {
if(timeout_auto > 0) {
timeout_auto = 0;
CMD_NOT_CLOSING = 1; // stoppe la commande de fermeture
CMD_BUZZER=1; // allume le buzzer
state = WAIT_RELEASE; // attend que le bouton soit relach�
}
}
else {
// incr�mente le timer du mode automatique
// si le timer auto est arriv� au bout, on passe en auto
if(timeout_auto++ >= AUTO_TIMEOUT) {
CMD_BUZZER = 1; // active le buzzer
state = AUTO_CLOSING; // change d'�tat, passe en fermeture automatique
}
}
}
}
// d�but du mode automatique, le bouton ouverture est toujours appuy�
void auto_opening()
{
// abandonne le mode auto si la pompe s'arrete en cours de route (fin de
s�quence)
if(PUMP_STOPPED) {
timeout_auto = 0;
CMD_NOT_OPENING = 1; // stoppe la commande d'ouverture
CMD_BUZZER = 1; // stoppe le buzzer
state = WAIT_RELEASE; // attend que le bouton soit relach�
}
else {
// le bouton d'ouverture est relach�, on passe en mode full auto
if(! OPEN_PUSHED) {
CMD_BUZZER = 0; // stoppe le buzzer au relachement
state = FULL_AUTO; // passe en �tat full auto
}
}
}
// d�but du mode automatique, le bouton fermeture est toujours appuy�
void auto_closing()
{
if(PUMP_STOPPED) {
timeout_auto = 0;
CMD_NOT_CLOSING = 1; // stoppe la commande de fermeture
CMD_BUZZER=1; // allume le buzzer
state = WAIT_RELEASE; // attend que le bouton soit relach�
}
else {
// le bouton de fermeture est relach�, on passe en mode full auto
if(! CLOSE_PUSHED) {
CMD_BUZZER = 0; // stoppe le buzzer au relachement
state = FULL_AUTO; // passe en �tat full auto
}
}
}
void full_auto()
{
// stoppe la commande si la pompe ne tourne plus
if(PUMP_STOPPED) {
// cycle termin� normalement
CMD_NOT_OPENING = 1; // stoppe la commande d'ouverture
CMD_NOT_CLOSING = 1; // stoppe la commande de fermeture
CMD_BUZZER = 0; // stoppe le buzzer
state = STOPPED; // change d'�tat passe � l'arret
}
// stoppe en cours de route si un des boutons est appuy�
else if(OPEN_PUSHED || CLOSE_PUSHED) {
// stopp� en cours de route, met le buzzer en route
CMD_NOT_OPENING = 1; // stoppe la commande d'ouverture
CMD_NOT_CLOSING = 1; // stoppe la commande de fermeture
CMD_BUZZER=1; // allume le buzzer
state = WAIT_RELEASE; // attend que le bouton soit relach�
}
}
// abandon du mode auto en cours de route
// ou fin de cycle normal en manuel
void wait_release()
{
// on attend que le bouton soit relach� pour repasser en mode stopp�
if(! (OPEN_PUSHED || CLOSE_PUSHED)) {
CMD_BUZZER=0;
state = STOPPED; // passe en �tat stopp�
}
}
Stephane Legras-Decussy
"jj" <jeanjacque...@wanadoo.fr> a �crit dans le message de news:
4ab27a39$0$23486$ba4a...@news.orange.fr...
> Maitrise les qq instructions de base est certainement plus facile que de
> se lancer dans les d�dales tortueux du C...
?? d�dales tortueux ?
�a c'est de la m�connaissance du C...
les plus timides peuvent meme �crire du C sans
fonction et sans pointeur...
une seule fonction principale main(),
que des variables globales... des goto
pour les branchements...
un d�butant pige le truc en une demi-heure...
vede
<killyours...@yesnocancel.com> wrote:
> "jj" <jeanjacques.goess...@wanadoo.fr> a écrit dans le message de news:
> 4ab27a39$0$23486$ba4ac...@news.orange.fr...
>
> > Maitrise les qq instructions de base est certainement plus facile que de
>
> ?? dédales tortueux ?
>
> ça c'est de la méconnaissance du C...
>
> les plus timides peuvent meme écrire du C sans
> fonction et sans pointeur...
>
> une seule fonction principale main(),
> que des variables globales... des goto
> pour les branchements...
>
bonjour à tous,
qu'est ce que j'avais dit ;O]
j'aurai jamais du parler de l'asm ;O]
bon dimanche à tous,
vede
;O]
Stan
<killyours...@yesnocancel.com> wrote:
> "Stan" <t...@neuf.fr> a écrit dans le message de news:
> 764e9985-4dd9-4be4-81a4-82cd5f210...@j9g2000vbp.googlegroups.com...
>
> >Il semblerait que son utilisation soit recommandé dans un 'switch' ;-)
>
> j'utilise très souvent break pour sortir
> d'un for( ) après condition...
Oui, mais relis ma phrase et essaye d'écrire un switch sans break...
Ca en limite quelque peu l'utilisation, alors que dans les autres
cas...
--
-Stan
Stan
> universellement dans n'importe quel autre nouveau programme (elles ne se
> compilent que si elles peuvent etre appelées par le programme "main")
N'importe quoi.
Il ne faut pas confondre édition des liens et compilation.
--
-Stan
Pierre_Edouard
"Stan" <t...@neuf.fr> a �crit dans le message de news:
3f240717-f3f3-4feb...@s6g2000vbp.googlegroups.com...
On 18 sep, 20:28, "Pierre_Edouard" <xxp....@pecherie.fr> wrote:
> universellement dans n'importe quel autre nouveau programme (elles ne se
> compilent que si elles peuvent etre appel�es par le programme "main")
N'importe quoi.
Il ne faut pas confondre �dition des liens et compilation.
==========
C'est toi le " n'importe quoi" le nouveau programme compile forcement les
fichiers include edit�s "en clair" et comme je l'ai dit , seulement les
fonctions suceptibles d'etre utilis�es
Philippe
> si je dois recruter un programmeur, je disqualifie
> un gars qui m'�crit �a... :-)
c'est de la discrimination, je vais contacter la Halde bouhhhhh ;-)
Pinball-Man
news:4ab71c6c$0$23444$ba4a...@news.orange.fr...
Sans rentrer dans une pol�mique, les includes, c'est quand m�me fait pour
d�clarer les prototypes des fonctions et les types mais pas pour y �crire du
code.
M�me si en effet le compilo s'en fout compl�tement et �a ne le g�ne pas du
tout que le code soit dans les includes parce qu'en r�alit� il ne fait que
"merger" les .h avec les .c, rien n'emp�che de mettre tout le code dedans,
et beaucoup de programmeurs, par facilit� et moi le premier(j'ai pas dit
fain�antise :-) ) y mettent des fonctions dans des #define (c'est pas bien
non plus), dans des inline (mieux) ou carr�ment des fonctions compl�tes
(crado :-)) ).
Ca se fait d'ailleurs assez souvent de fa�on assez natuelle en c++ on a
tendance � laisser dans les .h les prototypes et aussi le code des m�thodes
microscopiques (quelques lignes) et les m�thodes inline, et les const mais
bon, si on veut faire proprement, c'est le code dans le .c et uniquement les
prototypes et d�clarations de types dans les .h il ne doit rien avoir �
compiler qui "produise" du code autre que les glue d'appel aux
fonctions/m�thodes externes. le mieux c'est de faire une ou plusieurs
librairie + des headers, dont les fonctiones ne sont link�es automatiquement
au programme final que si elles sont utilis�es, c'est propre et
r�utilisable, et on ne compile la lib que lorsqu'elle �volue et tous les
programmes en b�n�ficient (tant qu'on ne fait qu'ajouter de nouvelles
fonctiones sans changer les prototypes des fonctions existantes �videmment)
et moins il y a de code dans les .h, moins il y a de d�pendances avec les
programmes qui s'en servent (dans une lib, il y a les .h "internes" juste
pour compiler la lib et les .h "interfaces" qui sont des .h simplifi�s �
destination des clients de la librairie, sorte de contrat d'interface avec
le strict minimum).
bon si c'est pour faire un petit prog en C de quelques parges sur un �c, �a
change pas la face du monde si tout est dans 1 seul .c m�me sans include ou
si on mets quelques fonction dans des .h...
Pascal
Pierre_Edouard
"Pinball-Man" <n...@spam.please.com> a �crit
>>
> Sans rentrer dans une pol�mique, les includes, c'est quand m�me fait pour
> d�clarer les prototypes des fonctions et les types mais pas pour y �crire
> du code.
Mon outil de travail proc�de de cette fa�on
../..
#include<stdlib.h>
#include<string.h>
#include<lcd_elcd.c>
#include<pcf8583.c>
../..
Les "fichiers include" <.... > certains compris dans la biblioth�que du
fournisseur ou �labor�s soi-m�me sont �crit en code ( C ou ASM ou les
deux ) et sont compil�s en m�me temps que le nouveau programme, par le
compilateur dont on sait bien s�r que c'est le travail du "pr�s processeur"
Stan
> "Stan" <t...@neuf.fr> a écrit dans le message de news:
> 3f240717-f3f3-4feb-a342-381174461...@s6g2000vbp.googlegroups.com...
> On 18 sep, 20:28, "Pierre_Edouard" <xxp....@pecherie.fr> wrote:
>
> > universellement dans n'importe quel autre nouveau programme (elles ne se
>
> N'importe quoi.
> Il ne faut pas confondre édition des liens et compilation.
> ==========
> C'est toi le " n'importe quoi" le nouveau programme compile forcement les
> fonctions suceptibles d'etre utilisées
On 21 sep, 08:24, "Pierre_Edouard" <xxp....@pecherie.fr> wrote:
> "Stan" <t...@neuf.fr> a écrit dans le message de news:
> 3f240717-f3f3-4feb-a342-381174461...@s6g2000vbp.googlegroups.com...
> On 18 sep, 20:28, "Pierre_Edouard" <xxp....@pecherie.fr> wrote:
>
> > universellement dans n'importe quel autre nouveau programme (elles ne se
> > compilent que si elles peuvent etre appelées par le programme "main")
>
> N'importe quoi.
> Il ne faut pas confondre édition des liens et compilation.
> ==========
> C'est toi le " n'importe quoi" le nouveau programme compile forcement les
> fichiers include edités "en clair" et comme je l'ai dit , seulement les
> fonctions suceptibles d'etre utilisées
' elles ne se compilent que si elles peuvent etre appelées par le
programme "main") ', si
cette phrase se rapporte aux fonctions, est est fausse ou mal
exprimée.
L'appel et la compilation du corps de la fonction (définition /
déclaration) sont deux choses indépendantes.
L'un comme l'autre peut être effectué indépendemment lors de la
compilation.
C'est à l'édition des liens que cela est résolu.
Et comme indiqué plus loin dans le fil, mettre du code dans des
includes est une mauvaise habitude.
Sur un projet très gros, si la modularité des fichiers est mauvaise,
une simple modif d'un source fera
perdre un temps fou en recompilant des choses qui ne devraient pas
l'être.
D'ou l'importance de dissocier la déclaration de la définition.
--
-Stan
Pinball-Man
Normalement le lcd_elcd.c et pcf8583.c devraient �tre compil�s � part
(ajout�s dans le projet ou bien en faire une lib) et donc g�n�rer un .o (ou
�quivalent), il devrait y avoir un lcd_elcd.h et un pcf8583.h qui ne servent
qu'� d�clarer les fct/types utilis�s dans les .c et rien d'autre et c'est
l'�dition des lien finale qui recompose le binaire d�finitif avec tous les
fichiers compil�s .o
Mais comme j'ai dit, tel que tu le montres �a marche aussi, juste que c'est
pas �l�gant, c'est d�tourner la fonction de preprocesseur et c'est surtout
pas efficace chaque fois que tu changes 1 ligne de codes quelque part, il
faut tout recompiler, alors que si les .o sont recombin�s � la fin (les .c
�tant corrcetement d�clar�s dans un makefile ou dans le projet), seul le
fichier .c touch� se recompile et pas les autres
Pascal
Pierre_Edouard
>
> Normalement le lcd_elcd.c et pcf8583.c devraient �tre compil�s � part
> (ajout�s dans le projet ou bien en faire une lib) et donc g�n�rer un .o
> (ou �quivalent), il devrait y avoir un lcd_elcd.h et un pcf8583.h qui ne
> servent qu'� d�clarer les fct/types utilis�s dans les .c et rien d'autre
> et c'est l'�dition des lien finale qui recompose le binaire d�finitif avec
> tous les fichiers compil�s .o
>
> Mais comme j'ai dit, tel que tu le montres �a marche aussi, juste que
> c'est pas �l�gant, c'est d�tourner la fonction de preprocesseur et c'est
> surtout pas efficace chaque fois que tu changes 1 ligne de codes quelque
> part, il faut tout recompiler, alors que si les .o sont recombin�s � la
> fin (les .c �tant corrcetement d�clar�s dans un makefile ou dans le
> projet), seul le fichier .c touch� se recompile et pas les autres
C'est la fa�on recommand�e de proc�der par le fabricant de l'outil de
d�veloppement,
la fa�on la plus simple. les "fichiers include" , ( que l'on peut aussi
baptiser xxx.h que xxx.c , ) sont stock�s en code source, cela permet de
les modifier � loisir.
Il est possible bien s�r avec cet outil de compiler les fichiers sources ,
header et les autres , s�par�ment mais je ne vois pas l'in�l�gance de
cliquer sur <make> pour compiler ou recompiler le tout . au final, le volume
est le m�me.
Apr�s quoi le pr�prosesseur, c'est son r�le, les appelle pour g�n�rer le
code ex�cutable dans l'ordre ou " ils sont d�clar�s"
Rappelons que le sujet discut� concerne la mise en oeuvre et la
programmation c ou basic "amateur" de �C, de peu souvent plus de 64 k,
le temps d'ex�cution de la recompilation de l'ensemble ne prend que quelques
secondes.
Et qu'en outre ma r�flexion de comparaison basic <=> C sur le sujet [
n'etait que] ( le "C" bien pratique (entre autre) � cause surtout du
principe des fonctions dont certaines universelles, stock�es (en clair)
dans un r�pertoire de r�serve et rappelables tr�s simplement par
l'instruction "#include"). c'est tout.
Pierre_Edouard
"Stan" <t...@neuf.fr> a �crit
.../... D'ou l'importance de dissocier la d�claration de la d�finition.
.../...
===========
Inutile de se perdre dans un bavardage inutile , je n'admet simplement pas
les remarques � l'accent d�sobligeant comme "n'importe quoi"
En sus, je n'ai pas oppos� la d�claration est la d�finition j'ai
simplement fait remarqu� aux tenants du basic que les "c" permet
l'�laboration de fonctions "universelles" que l'on peut regrouper dans des
"fichiers include" et que l'on peut appeler et compiler lors de la cr�ation
d'un programme .
Guillaume
> "Stan" <t...@neuf.fr> a ï¿œcrit
>
> .../... D'ou l'importance de dissocier la dï¿œclaration de la dï¿œfinition.
> .../...
> ===========
> Inutile de se perdre dans un bavardage inutile , je n'admet simplement pas
> En sus, je n'ai pas opposￜ la dￜclaration est la dￜfinition j'ai
> simplement fait remarquￜ aux tenants du basic que les "c" permet
> l'ï¿œlaboration de fonctions "universelles" que l'on peut regrouper dans des
> "fichiers include" et que l'on peut appeler et compiler lors de la crï¿œation
> d'un programme .
C'est ce que je craignais: chacun a ses habitudes et trouve que c'est
la solution 'la meilleure'. Un autre demande pourquoi et dit que non,
et c'est parti dans des ï¿œchanges d'experts.
je ne suis pas programmeur, ne souhaite pas le devenir, je veux juste
faire des bricoles sans me prendre la tï¿œte. OK pour connaï¿œtre ce qu'il
faut (registres etc.) mais pas OK pour mordre dans la discussion sur
les 'includes': c'est du chinois.
donc je crois que je vais qd mï¿œme aller vers le basic avec tous ses
inconvￜnients, c'est le plus ￜloignￜ de l'esprit programmeur.
merci de vos lumiￜres, cela m'a bien aidￜ en creux.
Pinball-Man
news:4ab8e3dd$0$382$426a...@news.free.fr...
Mais non, c'est un dï¿œtail, on peut trï¿œs bien faire du C pour ï¿œC dans 1 seul
fichier on peut trï¿œs bien vivre sans faire de lib, de projets avec plusieurs
.c sï¿œparï¿œs et includes ni mï¿œme faire de fonctions, on peut tout coder dans
le main ï¿œa ne marchera pas plus mal :)
Et petit ￜ petit, tu pourras apprendre les concepts plus poussￜs, fonctions,
include, librairies, etc... il n'y a pas besoin d'ï¿œtre un expert en C pour
faire du bidouillage sur ï¿œC.
Oublions la discussion sur les bonnes pratiques du C:
Nul besoin d'ï¿œtre un expert en C pour s'y mettre, ï¿œa va te prendre le mï¿œme
temps que le basic ￜ apprendre, il est trￜs simple, if/else, for(), quelques
accolades et avec ￜa on fait ￜ peu prￜs tout, (mￜme le switch on peut aussi
trï¿œs bien s'en passer au dï¿œbut :-) ), mais au moins, tu auras appris un
langage universel.
voilￜ un squelette minimal par exemple, tu tￜlￜcharges mplab
http://ww1.microchip.com/downloads/en/DeviceDoc/MPLAB_IDE_8_36.zip
il est livrￜ avec (copiￜ betement de la doc du compilo htc) c'est un example
tout bete pour faire clignoter les sorties du port B d'un pic 16f877 bien
connu:
#include <htc.h>
__CONFIG(XT & WDTDIS & PWRTDIS & BORDIS & LVPEN & WRTEN & DEBUGEN & DUNPROT
& UNPROTECT);
void init(void)
{
// port directions: 1=input, 0=output
TRISB = 0b00000000;
}
char counter;
void main(void)
{
counter = 0;
init();
while (1){
PORTB = counter;
_delay(10000);
counter++;
}
}
voilￜ, c'est quand mￜme simple tu trouves pas ?
tu peux partir de lￜ pour faire quelque chose de plus complexe petit ￜ
petit, sans forcï¿œment faire de fonctions, juste en ajoutant des
initialisations au besoin dans init() et en ajoutant du code intelligent
dans le "while".
et quand tu auras fait un peu trop de code dans le main ou trop de
copiￜ/coller, alors tu te diras qu'il sera temps de faire des fonctions, etc
et petit ￜ petit tu feras ￜvoluer le code en mￜme temps que tu apprends les
base du langage, qui reste, faut il le rappeler, simpliste.
tu remarqueras qu'on ne doit jamais sortir du while(), sinon on sort de
main() aussi et lￜ le cpu s'arrete ou reset tout seul mais ￜa n'a rien ￜ
voir avec le C c'est valable en assembleur et en basic aussi il faut
toujours une boucle infinie quelque part sur les ï¿œC.
Si tu as activￜ le watchdog il faut rￜguliￜrement appeler CLRWDT() avant
qu'il que le watchdog ne dï¿œclenche un reset automatique, note que le
watchdog, c'est aussi super facultatif en "bidouillage" on peut trï¿œs bien
s'en passer aussi.
Pascal
Guillaume
Bonjour Pascal
ï¿œa c'est constructif.
je vais aller voir, comme quoi une explication simple d'un sujet simple
reflￜte mieux la rￜalitￜ !
merci encore
cordialement
Guillaume
Pinball-Man
> Pinball-Man avait soumis l'idï¿œe :
>> "Guillaume" <gtch...@free.fr> a ï¿œcrit dans le message de
>> news:4ab8e3dd$0$382$426a...@news.free.fr...
>>> Aprï¿œs mï¿œre rï¿œflexion, Pierre_Edouard a ï¿œcrit :
>>>> "Stan" <t...@neuf.fr> a ï¿œcrit
>>>>
>
>
> ï¿œa c'est constructif.
> je vais aller voir, comme quoi une explication simple d'un sujet simple
> reflￜte mieux la rￜalitￜ !
> merci encore
En fait pour bien commencer, perso je me fixerais un but, mï¿œme un truc
bateau et pas forcￜment super compliquￜ, mais quelque chose qui permet, en
fin de projet, d'avoir progressￜ en douceur sans se prendre la tￜte tout de
suite en se lanï¿œant dans quelque chose qui parait insurmontable, je donne un
exemple totalement au hasard mais qui permet de montrer comment en partant
d'un petit truc, et en le faisant ￜvoluer on peu arriver ￜ faire quelque
chose de sympa, sans forcï¿œment balancer tout le code d'avant, c'est bien sï¿œr
bateau et dￜjￜ vu 1000 fois mais ￜa fait dￜjￜ pas mal le tour de la question
une fois que tout est fini t'es devenu un expert :-) donc mon exemple:
- commencer par faire un tï¿œlï¿œrupteur tout bï¿œte: gestion d'une seule entrï¿œe
et d'une seule sortie, un coup j'appuie, ï¿œa allume, un coup j'appuie ï¿œa
ï¿œteint.
- lￜ tu vas te rendre compte que ￜa ne marche pas bien ￜ cause des rebonds
des fois ï¿œa marche, des fois pas, il faudra ajouter un anti-rebonds logique
sur l'entrï¿œe, il y a plusieurs faï¿œons de faire, la plus simple ï¿œtant de
gï¿œrer un bete dï¿œlai avant de valider une action, ou de ne lire l'entrï¿œe que
toutes les X milisecondes, ou de faire une bascule logicielle, ou une
combinaison des 2, etc.
- puis ajouter un timer, le tï¿œlï¿œrupteur se transforme alors en minuterie
basique, un appui dï¿œclenche un timer qui ï¿œteint la sortie au bout de X
secondes.
- ensuite ajouter une gestion 'maline': si lampe ï¿œteinte et appui bref =
minuterie, si lampe ï¿œteinte et appui long ï¿œa allume la sortie sans
minuterie, si lampe allumï¿œe et appui bref = ï¿œa relance la minuterie, si
appui long et lampe allumï¿œe alors ï¿œa annule la minuterie et ï¿œa ï¿œteint la
sortie. lￜ dￜjￜ t'as un tￜlￜrupteur/minuterie de luxe :)
- puis viendra probablement l'envie de commande un peu plus qu'une seule
sortie et un bouton, alors rajouter des boutons de "setup" pour rï¿œgler la
durï¿œe, durï¿œe que tu stockera bien sur dans la mï¿œmoire eeprom et tu feras
clignoter lentement une autre sortie correspondant au nombre de minutes
rï¿œglï¿œes, ï¿œa fait 3 entrï¿œes et 2 sorties.
- puis ajouter un ￜcran lcd, lￜ ￜa se corse, mais pas tant que ￜa car il
existe des tas de librairies toute faites (comme en basic et en seembleur
bien sur) pour commander un lcd, c'est pas trￜs compliquￜ ￜ gￜrer. tu
pourras alors ajouter l'indication du rï¿œglage de durï¿œe et lors de l'appui un
dï¿œcompte... (je te passe le dï¿œtail de comment connecter un lcd il a des
milliers d'exemples c'est toujours ￜ peu prￜs pareil en 4 ou 8 fils)
- puis transformer tout ï¿œa en horloge, tout en gardant la minuterie,
afficher l'heure/minute/seconde, rï¿œglable bien sur depuis des boutons.
- ensuite continuer et permettre de programmer un allumage/extinction ￜ une
certaine heure
- puis gï¿œrer plusieurs plages horaires pour faire un simulateur de
prï¿œsence/programmateur
- ajouter une fonctione random pour faire des allumages "au hasard" dans
certaines plages
- puis ajouter un circuit d'extension I2C, par exemple pour permettre de
piloter plus de sorties ￜ diffￜrentes heures ou rￜcupￜrer l'heure, puisqu'il
y a des composants "horloge" tout faits.
- puis ajouter une gestion usb en ￜmulation rs232, lￜ c'est dￜjￜ plus
compliquￜ, il faut la petite interface usb qui va bien, mais pas mal de
petites cartes de dï¿œveloppement l'ont et avec un bï¿œte terminal sous windows
tu envoies des ordres ￜ ton systￜme pour allumer/ￜteindre tel ou tel sortie.
- etc, dￜjￜ si t'arrives lￜ, ￜ mon avis, t'auras plus besoin de personne
pour programmer en C :-)
Pascal
Guillaume
Je te remercie beaucoup. je vais carrï¿œment imprimer ton mail et suivre
ce dvpt. j'ai ￜtￜ voir les compilateurs et il faut encore comprendre le
hard dont j'ai besoin...
Jean-Christophe
> j'ai été voir les compilateurs et il faut
> encore comprendre le hard dont j'ai besoin...
En general les kits de developpement sont fournis avec
des exemples de code dont la difficulte est tres progressive,
permettant justement d'evoluer en programmation de uC,
que ce soit en ASM ou en C. Si tu preferes monter toi-meme
ton circuit electronique, ces packages d'exemples peuvent
etre downloades a part et tu peux utilement t'en inspirer.
Jean-Christophe
> la façon la plus simple. les "fichiers include" ,
> ( que l'on peut aussi baptiser xxx.h que xxx.c , )
Non : un fichier include est un ".H", pas un ".C"
> sont stockés en code source,
Non : un fichier include ".H" ne contient pas de code, mais
uniquement les prototypages des fonctions, et les definitions
des structures de donnees afin de pouvoir ensuite linker
l'ensemble des fichiers source et des librairies.
> Après quoi le préprosesseur, c'est son rôle, les appelle pour générer le
> code exécutable dans l'ordre ou " ils sont déclarés"
Non : le travail du preprocesseur n'est pas de compiler,
mais de pre-processer le code source avant la compilation,
comme par exemple l'interpretation des macros via "#define".
La compilation est le job du compilateur, comme son nom l'indique.
> Rappelons que le sujet discuté concerne la mise en oeuvre et la
> programmation c ou basic "amateur" de µC, de peu souvent plus de 64 k,
Non : la limite de 64Ko due aux 16 bits d'adresses est depassee depuis
longtemps.
> Et qu'en outre ma réflexion de comparaison basic <=> C sur le sujet [
> n'etait que] ( le "C" bien pratique (entre autre) à cause surtout du
> principe des fonctions dont certaines universelles, stockées (en clair)
> dans un répertoire de réserve et rappelables très simplement par
> l'instruction "#include"). c'est tout.
Non : dans le cas que tu cites, les fichiers d'include ne contiennent
que les declarations des fonctions et structures de donnees
necessaires
au compilateur puis au linker pour generer le code d'appel des
fonctions
predefinies, et celles-ci ne sont pas "en clair" mais pre-compilees
en code machine dans les fichiers objet de la librairie.
Slartibartfast
> Inutile de se perdre dans un bavardage inutile , je n'admet simplement pas
> les remarques à l'accent désobligeant comme "n'importe quoi"
Si tu racontes n'importe quoi c'est normal que tu te fasses tailler un
costard.
Slartibartfast
> Les "fichiers include" <.... > certains compris dans la bibliothèque du
> fournisseur ou élaborés soi-même sont écrit en code ( C ou ASM ou les
> deux ) et sont compilés en même temps que le nouveau programme, par le
> compilateur dont on sait bien sûr que c'est le travail du "près processeur"
On sait bien sur que "près processeur" signifie "pas loin du
processeur"
et on sait bien sur que cela n'a pas de sens.
On sait bien sur que "préprocesseur" signifie "avant le processeur"
et on sait bien sur que cela a un sens.
Avant d'ecrire des aneries que d'autres pourraient croire
et ainsi faire passer ta propre maladie a des innocents,
tu devrais d'abord tenter de comprendre ce que tu lis,
au lieu d'adopter ce ton docte qui te ridiculise.
Stan
> On Sep 21, 3:07 pm, "Pierre_Edouard" :
>
> > la façon la plus simple. les "fichiers include" ,
> > ( que l'on peut aussi baptiser xxx.h que xxx.c , )
>
> Non : un fichier include est un ".H", pas un ".C"
Pas d'accord.
Le rôle de la directive "include" est de charger un fichier c'est
tout.
Fichier qui sera analysé avant (d'où le nom de fichier d'entête) celui
où la directive est invoquée.
Le reste n'est que convention ou habitude, mais dans la norme,
c'est son seul rôle.
> Non : un fichier include ".H" ne contient pas de code, mais
> uniquement les prototypages des fonctions, et les definitions
> des structures de donnees afin de pouvoir ensuite linker
> l'ensemble des fichiers source et des librairies.
Ils sont même utiles avant le linkage, ,à la compilation, pour le
controle du typage .
--
-Stan
Jean-Christophe
> > On Sep 21, 3:07 pm, "Pierre_Edouard" :
> > > la façon la plus simple. les "fichiers include" ,
> > > ( que l'on peut aussi baptiser xxx.h que xxx.c , )
> > Non : un fichier include est un ".H", pas un ".C"
> Pas d'accord. Le rôle de la directive "include"
> est de charger un fichier c'est tout.
Je suis d'accord, et je ne dis pas le contraire.
Ne pas confondre la directive "#include" avec "fichier d'include".
Un fichier d'include pourrait tout aussi bien etre une table de
donnees.
> Fichier qui sera analysé avant (d'où le nom de fichier d'entête) celui
> où la directive est invoquée.
> Le reste n'est que convention ou habitude, mais dans la norme,
> c'est son seul rôle.
Agreed.
> > Non : un fichier include ".H" ne contient pas de code, mais
> > uniquement les prototypages des fonctions, et les definitions
> > des structures de donnees afin de pouvoir ensuite linker
> > l'ensemble des fichiers source et des librairies.
> Ils sont même utiles avant le linkage, ,à la compilation, pour le
> controle du typage .
CQFD
Jean-Christophe
> Je ne considère pas les calculettes programmables comme des µP, ni même
> comme des processeurs de minis et de mainframes, ça n'a rien à voir.
> Je ne vois donc toujours pas le rapport.
Lui non plus, et c'est d'ailleurs pour ca qu'il a disparu.
> La syntaxe de tous les processeurs depuis Von Neumann
> est sous la forme "instruction - cible et/ou objet".
Cette phrase est trop compliquee pour notre "ami" :
il va donc faire une recherche sur Google & Wikipedia.
> Votre exemple serait donc (dans un code simplifié imaginaire) :
> Mov x, #2
> Add x, #5
> Mul x, #21...
Apres avoir confondu (entre autres) les Coulombs avec les Joules,
comment esperer qu'il ne confonde pas le circuit integre specialise
d'une calculette avec le circuit integre generique qu'est un uP ?
> Je ne vois rien de polonais là-dedans, à la rigueur un peu de hongrois ;)
Hongrois ce qu'on veut groire ...
Jean-Christophe
> si quelqu'un connait des cours pour le C : je suis preneur !
"Le langage C" par Kernighan & Ritchie.
( 35 Euros ) ISBN : 2-10-048734-5
http://www.dunod.com/livre-dunod-9782100487349-le-langage-c.html
Pinball-Man
�volutions du langage, au moins jusqu'au C89 et C99 qui sont quand m�me
moins strict que le C originel de K&R comme par exemple pouvoir d�clarer des
variables n'importe o� dans le code, pouvoir utiliser les commentaires � la
C++ avec // le support des inline (C99) qui rendent obsol�tes les #define,
etc...
maior�
> Non : un fichier include ".H" ne contient pas de code,
==============
De quel type de [code] parlez-vous , code source ? code
ex�cutable(machine) ? ...
Pinball-Man
sympa avec plein de p�riph pour jouer avec:
un truc comme �a
http://www.myavr.fr/4-myavr-board-2-usb.html
avec des modules plug&play (ou presque...)
http://www.myavr.fr/4-modules-d-extension
parfait pour bidouiller (un lcd, une horloge � pile, capteurs divers etc)
ou pour les plus fortun�s avec un afficheur dot matrix et tout:
http://www.myavr.fr/54-plateforme-avancee-mk3.html
Pascal
Pinball-Man
il y a 50 fa�on de faire, des bonnes des pas bonnes, des �l�gantes, des
moches, mais au final, souvent, le r�sultat est le m�me, avec le
pr�processeur on fait ce qu'on veut, on peut y foutre du code, des header,
des types, des commentaires, des data, etc, au final de toute fa�on en
sortie du preprocesseur tout est en vrac dans 1 seul fichier pour chaque
.obj / .o g�n�r�.
ensuite c'est une question de philosophie et de fa�on de travailler, souvent
les bidouilleurs n'ont que faire de tout le bazar de .h, lib, .c makefiles,
etc... alors que dans le monde pro, on en a des centaines, voir des milliers
et que ce sont rarement les m�mes personnes qui font les lib de celles qui
les utilisent, le .h (proto/contrat d'interface peu importe comment on
appelle �a) est le seul lien entre un prog client et une librairie fournie.
Pascal
Jean-Christophe
> > Non : un fichier include ".H" ne contient pas de code,
> De quel type de [code] parlez-vous , code source ?
> code exécutable(machine) ? ...
Tsss ...
Jean-Christophe
> il faudrait renommer cette discussion "formation aux bonnes pratiques du C",
Ou plutot faire suive sur un NG adequat, genre: <comp.lang.c>
Jean-Christophe
> A vérifier quand même que l'édition a été mise à jour avec les dernières
> évolutions du langage, au moins jusqu'au C89 et C99 qui sont quand même
> moins strict que le C originel de K&R comme par exemple pouvoir déclarer des
> variables n'importe où dans le code, pouvoir utiliser les commentaires à la
> C++ avec // le support des inline (C99) qui rendent obsolètes les #define,
K&R = C "ANSI" !
Laurent CLAUDE
> On Sep 25, 6:38 pm, "Pinball-Man" :
>
>> On Sep 17, 6:35 pm, Laurent CLAUDE
>> si quelqu'un connait des cours pour le C : je suis preneur !
>
> "Le langage C" par Kernighan & Ritchie.
> ( 35 Euros ) ISBN : 2-10-048734-5
> http://www.dunod.com/livre-dunod-9782100487349-le-langage-c.html
>
>> moins strict que le C originel de K&R comme par exemple pouvoir d�clarer des
>> C++ avec // le support des inline (C99) qui rendent obsol�tes les #define,
>
> K&R = C "ANSI" !
>
Mais j'ai une question stupide ;-) :
Ok, le C peut convenir pour tout un tas de �P et �C, mais dans mon cas
je souhaite l'apprendre pour du PIC.
Ne serait il pas "mieux" (plus simple) de trouver une doc qui ne
parlerait du C que pour ce type de composant ?
J'ai un peu peur de me perdre dans des apprentissages qui ne me seront
pas utiles...
cdlt,
Laurent
Jean-Christophe
|> "Le langage C" par Kernighan & Ritchie.
|> (35 Euros) ISBN : 2-10-048734-5
|> http://www.dunod.com/livre-dunod-9782100487349-le-langage-c.html
> Ok, le C peut convenir pour tout un tas de µP et µC,
> mais dans mon cas je souhaite l'apprendre pour du PIC.
Il me semble que tu n'as pas bien saisi :
Le C est un language qui ne *depend pas* de la cible materielle.
Un des interets du C est justement de ne pas etre specifique
a une machine : il n'existe pas un C pour Microchip,
un autre pour Motorola/Freescale, un autre pour Intel, etc ...
Un *meme* programme C correctement ecrit pourra etre compile,
suivant le uC cible, en differents codes machine, destines
a plusieurs uC differents, provenant de fabricants differents.
(exception faite des routines bas niveau specifiques au uC)
C'est le compilateur qui transcrit le C en language machine
qui va generer du code executable pour un uC particulier.
Donc ta question "apprendre le C pour du PIC" n'a pas de sens,
car le C n'est pas destine a un uC particulier, comprends-tu ?
> Ne serait il pas "mieux" (plus simple) de trouver une doc
> qui ne parlerait du C que pour ce type de composant ?
Apprendre le C est *independant* du fait d'apprendre
les PIC. Que tu utilises un PIC, un 68HC16, ou un
uP Intel, la connaissance du C te servira toujours,
quel que soit le hardware que tu utiliseras.
> J'ai un peu peur de me perdre dans des
> apprentissages qui ne me seront pas utiles...
Apprendre le C n'est certainement pas inutile !
GuessWhat
char *p = "stn", *s =
"Si tu racontes n'importe quoi c'est normal"
" que tu te fasses tailler un costard."
*strrchr( s, *p++ ) = *(p+1);
*strrchr( s, *p++ ) = *p;
printf( "%s \n", s );
// ;-)
Laurent CLAUDE
> Le C est un language qui ne *depend pas* de la cible materielle.
> Un des interets du C est justement de ne pas etre specifique
> a une machine : il n'existe pas un C pour Microchip,
> un autre pour Motorola/Freescale, un autre pour Intel, etc ...
Ha... je m'attendais a cette r�ponse !
C'est confirm� : ma question �tait stupide !!!
Merci
Laurent
maior�
"Laurent CLAUDE" <laurent.claude_PAS_DE_PUB_@fr_PAS_DE_PUB_ee.fr> a �crit
> Mais j'ai une question stupide ;-) :
> Ok, le C peut convenir pour tout un tas de �P et �C, mais dans mon cas je
> souhaite l'apprendre pour du PIC.
> Ne serait il pas "mieux" (plus simple) de trouver une doc qui ne parlerait
> du C que pour ce type de composant ?
> J'ai un peu peur de me perdre dans des apprentissages qui ne me seront pas
> utiles...
Il existe de nombreux outils (compilateurs) pour les �C PIC en langage C,
tous � peu pr�s semblables quand aux instructions et structures du
standard_C , ( pour ceci , n'importe quel cours ou document concernant le
"langage C" conviendra )
... mais tous diff�rents en ce qui concerne les biblioth�ques tr�s
sp�cifiques, de fonctions et l'ecriture de la gestion des outils du �C
concern�.
Exemple comparatif ici de quelques compilateurs PIC (commerciaux)
http://www.ccsinfo.com/content.php?page=newcompilercomp
Stan
J'espère que tu ne manipules pas les pointeurs
comme ça dans tes programmes embarqués.
--
-Stan
GuessWhat
> > char *p = "stn", *s =
> > "Si tu racontes n'importe quoi c'est normal"
> > " que tu te fasses tailler un costard."
> > *strrchr( s, *p++ ) = *(p+1);
> > *strrchr( s, *p++ ) = *p;
> > printf( "%s \n", s );
|> J'espère que tu ne manipules pas les pointeurs
|> comme ça dans tes programmes embarqués.
Ca marche tres bien, merci !
Stan
Tu t'es déja demandé où était réservé l'espace mémoire de 'p' et 's' ?
Et comment on appelle ces déclarations ?
--
-Stan
Jean-Christophe
|> C'est confirmé : ma question était stupide !!!
Nooon pas du tout : il n'y a pas de question stupide,
ce qui serait stupide c'est de ne pas chercher a comprendre.
GuessWhat
> > char *p = "stn", *s =
> > "Si tu racontes n'importe quoi c'est normal"
> > " que tu te fasses tailler un costard."
> > *strrchr( s, *p++ ) = *(p+1);
> > *strrchr( s, *p++ ) = *p;
> > printf( "%s \n", s );
|> Tu t'es déja demandé où était réservé l'espace mémoire de 'p' et
's' ?
|> Et comment on appelle ces déclarations ?
Ca fait 20 ans que je code en C, merci.
As-tu compris ce que fait ce code,
juste en le lisant, sans le faire tourner ?
Stan
> On Sep 26, 9:19 pm, Stan <t...@neuf.fr>
>
> > > char *p = "stn", *s =
> > > "Si tu racontes n'importe quoi c'est normal"
> > > " que tu te fasses tailler un costard."
> > > *strrchr( s, *p++ ) = *(p+1);
> > > *strrchr( s, *p++ ) = *p;
> > > printf( "%s \n", s );
>
> |> Tu t'es déja demandé où était réservé l'espace mémoire de 'p' et
> 's' ?
> |> Et comment on appelle ces déclarations ?
>
> Ca fait 20 ans que je code en C, merci.
Quelle réponse pertinente.
> As-tu compris ce que fait ce code,
> juste en le lisant, sans le faire tourner ?
Pourquoi, il est sensé être difficile à comprendre ( en plus d'avoir
un comportement indéfini ) ?
A moins d'avoir confondu char *p avec char p[] ?
--
-Stan
Laurent CLAUDE
> ... mais tous diff�rents en ce qui concerne les biblioth�ques tr�s
> sp�cifiques, de fonctions et l'ecriture de la gestion des outils du �C
> concern�.
> Exemple comparatif ici de quelques compilateurs PIC (commerciaux)
> http://www.ccsinfo.com/content.php?page=newcompilercomp
>
>
Ouais !! merci tr�s bon lien
C'est aussi ce type de r�ponse que j'appelais avec cette question !
cdlt,
GuessWhat
>> char *p = "stn", *s =
>> "Si tu racontes n'importe quoi c'est normal"
>> " que tu te fasses tailler un costard."
>> *strrchr( s, *p++ ) = *(p+1);
>> *strrchr( s, *p++ ) = *p;
>> printf( "%s \n", s );
> Quelle réponse pertinente.
C'est quoi cette agression, quel est ton probleme ?
Il faut ta permission pour ecrire du C ?
>> As-tu compris ce que fait ce code,
>> juste en le lisant, sans le faire tourner ?
> Pourquoi, il est sensé être difficile à comprendre
> ( en plus d'avoir un comportement indéfini ) ?
Je constate juste que tu ne reponds pas.
Fais tourner ce code avec un compilo ANSI.
> A moins d'avoir confondu char *p avec char p[] ?
Tu n'as jamais écrit
char *str = "texte";
au lieu de
char str[] = "texte";
Tu devrais essayer, juste par curiosité.
Pour le reste, je n'ai pas l'intention
de me battre avec toi, j'ai passé l'age.
Pinball-Man
news:f17d1d5a-ac1d-44eb...@s6g2000vbp.googlegroups.com...
On Sep 26, 8:11 pm, Stan :
> > char *p = "stn", *s =
> > "Si tu racontes n'importe quoi c'est normal"
> > " que tu te fasses tailler un costard."
> > *strrchr( s, *p++ ) = *(p+1);
> > *strrchr( s, *p++ ) = *p;
> > printf( "%s \n", s );
au hasard : �a remplace costard par connard ?
mais ton programme ne marchera jamais sur un �C, les constantes (la chaine s
et p) sont stock�es en ROM et ne seraient pas modifiables ou sous
unix/windows tu aurais droit � une belle erreur de segmentation.
il faut faire :
char *s=strdup("......");
et free(s) � la fin (bien que �a ne serve absolument � rien dans ce cas vu
qu'il n'y a que �a comme code et qu'ensuite le programme sort :-) )
Pascal
GuessWhat
>> char *p = "stn", *s =
>> "Si tu racontes n'importe quoi c'est normal"
>> " que tu te fasses tailler un costard."
>> *strrchr( s, *p++ ) = *(p+1);
>> *strrchr( s, *p++ ) = *p;
>> printf( "%s \n", s );
> au hasard : ça remplace costard par connard ?
Bingo !
> mais ton programme ne marchera jamais sur un µC
Qui parle de uC ?
Je parle de C, pas de la cible matérielle.
> les constantes (la chaine s et p) sont stockées
> en ROM et ne seraient pas modifiables
Un compilo ANSI a qui on déclare
const char *s = "texte";
va maintenir le pointeur 's' et la chaine ASCII constantes,
car c'est bien cela la sens du mot "const".
Un compilo ANSI a qui on déclare
char *s = "texte";
va stocker le pointeur et la chaine ASCII en RAM,
et permettra donc leur modification a tous deux.
Si ce n'est pas le cas alors le compilo n'est pas ANSI.
> sous unix/windows tu aurais droit à une belle erreur de segmentation.
Aucune raison d'avoir une erreur de segmentation !
Ce code ne cause problème qu'à certaines personnes,
et non à un compilateur C qui respecte la norme ANSI.
Jean-Christophe
> A moins d'avoir confondu char *p avec char p[] ?
C'est exactement la meme chose.
maior�
"Pinball-Man" <n...@spam.please.com> a �crit dans le message de news:
4abf2a62$0$31796$426a...@news.free.fr...
> "GuessWhat" <folk...@free.fr> a �crit dans le message de
> news:f17d1d5a-ac1d-44eb...@s6g2000vbp.googlegroups.com...
> On Sep 26, 8:11 pm, Stan :
>
>> > char *p = "stn", *s =
Ou alors on peut ecrire
char *p[] = "stn";
Jean-Christophe
|>> char *p = "stn"
> Ou alors on peut ecrire
> char *p[] = "stn";
Certainement pas.
char *p[] designe un tableau de pointeurs.
Il ne peut donc etre initialise avec une chaine de caracteres.
Slartibartfast
> char *p[] = "stn";
Aussi nul en programmation qu'en électronique.
GuessWhat
> Ou alors on peut ecrire
> char *p[] = "stn";
MDR
Stan
Pas tout à fait, surtout lors de la déclaration.
char *p = "toto";
p[2] = 'i'; /* affectation sur le const : résultat indéfini*/
char p[] = "toto";
p[2] = 'i'; /* ok */
la première version est un héritage des anciens compilo, préservé pour
une compatibilité avec des millions de lignes déjà écrite.
Les programmeurs sérieux préférent déclarer : const char* p = "toto",
ce qui controle toute modif à la compilation.
--
-Stan