bonjour :
je cherche un cour concernant la programmation des hards ( mémoire, lcd,microcontroleur) en C
merci d'avance
Version imprimable
bonjour :
je cherche un cour concernant la programmation des hards ( mémoire, lcd,microcontroleur) en C
merci d'avance
Je n'en connais pas mais on peut beaucoup apprendre la dessus en regardant les sources de Linux.
Eh bien disons que
- Soit on travaille avec un OS (si petit soit il) linux embarqué, noyau temps réel. Dans ce cas, il faut lire la doc de l'OS.
Un exemple de doc:
http://kadionik.ftp-developpez.com/s...c-embarque.pdf
- Soit vous désirez attaquer le hardware directement, dans ce cas il faut gérer des accès mémoire en direct : il faut initialiser des pointeurs aux valeurs que vous désirez puis lire ou écrire à ces adresse.
à vrais dire dire je veux programmer un pross fait pour des application embarqués ( NIOS2) et donc j'aurais besoin d'adapter des codes C au hardware que j 'utilise ainsi que ses perephirique la plate forme de developpement je l 'ai deja mais il s'avère qu'il faut adopter une sytaxe peu différente de ce qu'on connais du classique C j'éspère que j ai reussi à éclaircir ce que je veux et j'attends vos réponses et merci
En faite c'est un peu special, le C ne change pas, le C reste le C dans tous les cas mais dans du developpement vraiment systeme tu te retrouve a faire des trucs dont tu n'est pas habituer.
Par exemple en robotique on codait sur des cartes avec des microcontroleurs et genre on voit qu'au final on se sert pas mal des decalages de bits, de mettre des bit a 0 ou 1 dans certaines variable.
Ensuite c'est la ou j'ai decouverts de trucs comme les pragma code et autre pour faire des gestionnaire d'interuption hautes et basses.
je pense que le meilleur moyen est que tu cible bien le type de materiel sur lequel tu va bosser et ensuite tu trouvera des documentations relatives qui t'aideront bien dans le domaine.
Voila voila, cible bien ton architecture , ce que tu va utiliser, et ce que tu veux en faire
Exact, il n'y a pas de syntaxe C pour l'embarqué.Citation:
le C reste le C
Il faut "juste" faire attention à la taille de mémoire que l'on réserve (taille de tableaux par exemple).
Ensuite, le processeur doit être livré avec une filière de développement. Celle-ci fournis des librairies de bas niveau.
Il est vrai qu'il existe l'instruction#pragma qui permet à la filière de développement de connaître des informations particulières.
a oui par contre on decouvre des nouveaux trucs sympa, genre sur des petites cartes, essayer de passer plein d'arguments a une fonction avec pas mal de trucs et .... il aime vraiment pas ...
Je ne comprends pas. Ici nous sommes dans un forum technique, pourriez-vous être précis ?Citation:
a oui par contre on decouvre des nouveaux trucs sympa, genre sur des petites cartes, essayer de passer plein d'arguments a une fonction avec pas mal de trucs et .... il aime vraiment pas ...
lesquelles ?Citation:
sur des petites cartes
un exemple ?Code:essayer de passer plein d'arguments a une fonction avec pas mal de trucs
Salut tout le monde,
L'embarqué n'est fondamentalement pas différent de ce vous avez l'habitude de programmer... Certes les types changent, par exemple un int ou un unsigned int fait généralement 16 bits sur un processeur 8 bits (int étant si je ne m'abuse par convention la largeur du bus d'adresses), d'où l'intérêt d'un fichier "datatypes.h" facile à réécrire au cas où il faudrait faire tourner l'appli sur un PC ou un autre micro.
L'embarqué, ça veut aussi souvent dire que les couches de bas niveau sont à écrire au lieu de se contenter d'un bête #include <machintruc.h>.
Et toujours dans un souci de compatibilité (avec un PC, voire un autre microcontrôleur), bien séparer les couches matérielles et logicielles. Prenons par exemple un driver de LCD. La couche de bas niveau, c'est uniquement les fonctions LCD_Init() et LCD_PutPixel(x,y,[color]). La gestion des fontes et des différents putchar etc... se fait dans une couche de niveau supérieure mais faisant totalement abstraction du hardware. Ainsi, pour émuler le LCD sur un PC, il suffit de réécrire avec SDL les deux fonctions LCD_Init et LCD_PutPixel. Pour le faire tourner sur un autre micro, même chose, deux fonctions à réécrire.
Tout devrait être écrit comme ça, non seulement pour la lisibilité mais aussi pour la réutilisation des programmes. En effet, il est ridicule de réinventer la roue à chaque nouveau projet, réécrire le bas niveau est plus que suffisant. Sur certains compilos pour l'embarqué, il suffit d'écrire une fonction putchar pour pouvoir bénéficier de toutes les couches supérieures, dont printf0. , et d'écrire une fonction getchar pour le scanf0.
A+
Pfeuh
resalut à tous
peut être que je vais rediriger le " debat " vers unautre axe celui d'avoir vos conseils afin d'adapter son code c comme à mentioner bayard comme on va faire attention au taille des tableau surveiller la memoire pointeur etc....
merci
Je pense que tu voulais dire 'bus de données' (le bus d'adresse n'a rien à voir avec la largeur des types, sauf pour les pointeurs, bien sûr). En fait, la taille de int est de 16-bit minimum (c'est exigé par le langage C) et dans la réalité, ça correspond souvent à la taille des registres internes de données :Citation:
Envoyé par pfeuh
x86 réel : AX, BX, CX etc. : 16-bit
x86 protégé : EAX, EBX, ECX etc. : 32-bit
Par contre, en 8051, un int fait 16-bit, alors que les registre (A, B) font 8-bit...
De même, en 68k, les registres D0 à D7 font 32-bit, mais les compilateurs ont une option pour le type int : 2 octets ou 4 octets...
etc.
Ne pas tirer de conclusions hâtives...
je parlais des cartes de "test" sur lesquel on s'exerce techniquement, je n'ai pas appris le model par coeur désolé, c'est le genre de carte avec un micropic, des led et autres afficheurs lcd pour s'entrainer. Va sur le net tu en trouvera bcp, mais j'ai fais ceci pendant mes etudes.Citation:
Envoyé par Bayard
tu veux vraiment un appel de fonction avec beaucoup d'arguments comme exemple ?
ok mafonction(arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8, arg9, arg10, arg11);
sinon plus serieusement, tu peux imaginer une machine a etat assé complexe pour un robot avec par mal d'information, je voulais ici dire qu'il vaut mieu avoir une structure global que de passer tout plein de variable a une fonction, et que ce genre de configuration matériel peut etre moins souple qu'un pc dernier cri.
Ceci etait pour completer mes derniers posts, qui disaient que le C reste le C meme dans de l'embarqué ou autre, mais ta maniere de programmer peut etre différente (pragma code, faire gaffe a certains trucs comme explique plus haut ...)
Voila ... si tu veux que je precise plus ou autre, fait moi signe ...
Tu as raison de dire qu'il faut éviter d'avoir des dizaines de paramètres à une fonction, mais c'est un principe général, même si les effet dévastateurs de cette pratique sont plus rapidement visibles en embarqué où la pile est faible (quelques ko).Citation:
Envoyé par Elboras
La solution n'est pas "une structure global" (sic !), mais une ou des structures regroupant les données intelligemment, peut-être créée statiquement si l'allocation dynamique pose des problèmes, mais dont les adresses sont transmises aux fonctions via des pointeurs sur structures.
J'ai écrit des millions de lignes de codes pour embarqué selon ce principe, et je n'ai jamais eu de problème, sauf (et ça n'a rien à voir) dans les parties de l'exécution où la pile (stack) est très faible, notamment pendant le test mémoire qui s'effectue sur une pile utilisant un petit bout de mémoire interne du micro-contrôleur (MC68302). Là, il a fallut compter les octets...
quand je disais une structure globale, je ne parlais pas de mettre toute les variables dans une seul structure, mais par exemple de mettre les quelques variables de la machine a etat dans cette structure, les autres variables dans d'autre.
Cependant, j'allouais toujours statiquement personnelement, l'environnement que j'avais ne m'aurais pas permis d'allouer facilement de la memoire dynamiquement (de plus jetais en 1ere annee).
Sinon oui, ce sont des habitude de programmation a avoir sur tout type d'appareil, mais je me rappel juste que nos profs nous disaient de faire tres attention a pas passer pas mal de variable a une fonction.
Je dois dire que je n'en ai jamais ete a devoir compter les octets pour m'en sortir :) mais ca a du etre une bonne experience
Salut,
Merci m'sieur, je m'endormirai moins bête ce soir! ;)Citation:
Envoyé par Emmanuel Delahaye
A+
Pfeuh