Programmer en C et assembleur

[invite352bbdac]

Bonjour à tous,

Je reprends la programmation pour µC et µP en C mais surtout en assembleur pour picoblaze-3.

Mon but est de surveiller l'état d'un port tout en ayant la main sur le picoblaze-3.

Le début de code don't je me souviens en travaillant avec Cvavr ou avr studio (ATMEGA8515) était :

while(x==1){

//Do something

}

On est bien sur une boucle infinite en C ici !

A priori, il n'est pas conseillé d'appliquer ceci pour mon cas en assembleur.

Quelques liens utiles :

http://stackoverflow.com/questions/2...nguage-emu8086

JUMP est equivalent au while ou do while je crois.

Merci d'avance.
-----

[Seb.26]

C'est quoi la question ???

[invite352bbdac]

Savoir si on peut surveiller de manière continue la valeur d'une PIN d'entrée du picoblaze-3 et déclencher une function si c'est le cas.

Pour ca, il est nécessaire de faire une boucle infinite non? Je ne me souviens plus du déroulement d'un programme classique, quand est-ce qu'un programme s'arrête?

Je revois mes cours ce soir parce que la rien ne va plus.

[Ikhar84]

Bonjour

Une vrai boucle infinie qui tue :

while(1) {
//traitement
}

Là, n'ayant pas le code comple on ne peut garantir que x soit, contiennt un moment ou un autre, la valeur 1, et dans ce cas la boucle se termine...
En général il vaut mieux éviter les boucles infinies et prévoir un cas de sortie de la boucle...
Mais sans connaître les détails du code...

[A voir en vidéo sur Futura]

[gcortex]

Ba oui en assembleur :

config
Loop
programme
JMP Loop

JMP, BRA ou GOTO suivant le langage et la longueur du saut.

[paulfjujo]

bonsoir

Mon but est de surveiller l'état d'un port tout en ayant la main sur le picoblaze-3.

que signifie tout en ayant la main sur le picoblaze ?

Pour avoir un programme qui tourne , effectue une tache de fond
et qu'un etat logique de port le deroute sur une action specifique,
il faut utiliser les interruptions
sur un PIC :
interruption sur pin dedié RB0
ou interruption commune sur les 4 pins du PORTB7..B5

[gcortex]

çà dépend : je fais 99% de mes programmes sans interruption !
sinon le paralax ?

[antek]

Je ne me souviens plus du déroulement d'un programme classique, quand est-ce qu'un programme s'arrête ?

Un programme ne s'arrête jamais.

[Ikhar84]

...Ou à la derniere instruction (précedent la derniere accolade fermante) du "main" ou équivalent suivant le langage...
Une boucle aussi infinie soit elle ne fait que retarder l'échéance...

[Ikhar84]

Oups :
Sauf cas de "break" prématuré bien sûr...
(return, exit et conssorts...)

[antek]

...Ou à la derniere instruction (précedent la derniere accolade fermante) du "main" ou équivalent suivant le langage...
Une boucle aussi infinie soit elle ne fait que retarder l'échéance...

Et en langage machine (ou assembleur) ça donne quoi ?
Parce que je vois pas comment le compteur programme s'arrête de compter.

[Ikhar84]

Bonsoir Antek je répondais en pensant au C bien sûr...
Pas de label et autre goto...
Considérés en C (et langages apparentés) comme le Devil...

Donc un fil d'execution linéaire, les appels de fonctions, tests conditionnels, boucle ne sont que des étapes du fil d'execution principal...

Aprés c'est un point de vue fonctionnel, si on boucle indéfiniment, par exemple, le code qui suit la boucle ne peut être atteint, mais il fait parti du fil d'execution (théoriquement) même si certains compilateurs n'aiment pas trop...

Du point de vue du programme, ces étapes ne font que retarder l'échéances, d'une certaine façon. Les boucles exploitent une "faille" du resonnement pour moi en introduisant une boucle toujours vrai, volontairement ou pas...

while (true) {}
while (1) {}
for (int i=1; i>0 ; i++) {} //bien vicieuse celle là
//...

On peut aussi bien sûr parler du multithread ou même des fork() où là le fil d'execution devient plus ou moins distinct (piles et contexte mémoire distinct ou pas...)

Bien entendu ce n'est que mon point de vue.
Et je ne répondais qu'à la question concernant le C.
Côté assembleur je te laisse la main avec plaisir ...
(je suis très très mauvais en asm... je sais j'ai honte...)

En tout cas merci pour tes nombreux posts efficaces !

[antek]

Oui mais enfin la machine (matérielle) ne fonctionne pas selon les critères d'un langages de haut niveau.

[bobflux]

Bonsoir Antek je répondais en pensant au C bien sûr...
Pas de label et autre goto...
Considérés en C (et langages apparentés) comme le Devil...

Goto est indispensable en C, c'est la seule façon de gérer les erreurs proprement.
Dans d'autres langages plus évolués, on appelle cela des exceptions...

[invite5637435c]

Là, n'ayant pas le code comple on ne peut garantir que x soit, contiennt un moment ou un autre, la valeur 1, et dans ce cas la boucle se termine...

Pas sûr qu'un tel charabia va aider le demandeur....

[invite5637435c]

Goto est indispensable en C, c'est la seule façon de gérer les erreurs proprement.
Dans d'autres langages plus évolués, on appelle cela des exceptions...

Hello bob,

goto en C? Non tu te trompes.
Goto est utilisé uniquement par des gens qui ne connaissent pas le C, je dirai même plus c'est à bannir totalement!

[bobflux]

No problem, très cher.

Mettons une fonction qui alloue diverses ressources, et qui doive nettoyer derrière elle en cas d'erreur. Voici un exemple normal :

{
	char *a=NULL, *b=NULL, *c=NULL;
	FILE *f = NULL;
	
	a = malloc( ... );
	if(!a) goto error;
	
	f = fopen( ... );
	if(!f) goto error;

	if( condition )
	{
		if( !( b = malloc( ... ))) goto error;
		(traitement)
		if( !( c = malloc( ... ))) goto error;
	}
	else
	{
		if( !( c = malloc( ... ))) goto error;
		(traitement)
		if( !( b = malloc( ... ))) goto error;
	}
	
	fclose, free...
	return ...
	
error:
	if(a) free(a);
	if(b) free(b);
	if(c) free(c);
	if(f) fclose(f);
	return ERROR;
}

Voici maintenant un exemple avec la méthode quiche, sans GOTO :

{
	char *a = malloc( ... );
	if(!a) return ERROR;
	
	f = fopen( ... );
	if(!f)
	{
		free(a);
		return ERROR;
	}
		
	void *b, *c;
	if( condition )
	{
		b = malloc( ... )
		if(!b)
		{
			free(a);
			fclose(f);
			return ERROR;
		}
		(traitement)
		c = malloc( ... )
		if(!c)
		{
			free(a);
			free(b);
			fclose(f);
			return ERROR;
		}
	}
	else
	{
		c = malloc( ... )
		if(!c)
		{
			free(a);
			free(b);
			fclose(f);
			return ERROR;
		}
		(traitement)
		b = malloc( ... )
		if(!b)
		{
			free(a);
			free(c);
			fclose(f);
			return ERROR;
		}
	}
	
	fclose, free...
	return ...
}

Tu remarqueras que la quantité de merdier dans les if() de nettoyage en cas d'erreur grossit au fur et à mesure, ainsi que la probabilité qu'on en oublie un. La majorité du code devient de la gestion d'erreur sans intérêt, alors que la méthode goto garde cette gestion simple, et non intrusive, comme le font les exceptions.

Question subsidiaire : quand tu y reviens dans 6 mois et que tu rajoutes un malloc(), dans le premier cas tu as un seul free() à ajouter. Dans le second, combien vas-tu en oublier ?

Bonus : essaie avec un truc au milieu de la fonction qui duplique une liste chaînée allouée dynamiquement, avec un traitement qui peut échouer pour chaque élément...

[invite5637435c]

Mon but est de surveiller l'état d'un port tout en ayant la main sur le picoblaze-3.

Le début de code don't je me souviens en travaillant avec Cvavr ou avr studio (ATMEGA8515) était :

while(x==1){

//Do something

}

On est bien sur une boucle infinite en C ici !

A priori, il n'est pas conseillé d'appliquer ceci pour mon cas en assembleur.

Quelques liens utiles :

http://stackoverflow.com/questions/2...nguage-emu8086

JUMP est equivalent au while ou do while je crois.

Merci d'avance.

Jump est un saut comme son nom l'indique, il ne faut pas comparer un langage machine à un langage évolué tel que C, la démarche n'est pas exactement la même.
Un petit rappel s'impose:
L'assembleur (ou langage machine) est une traduction plus usuelle pour l'homme et qui utilise des "opcodes" (operation code) c'est à dire des instructions hexadécimales qui vont agir directement sur la couche matérielle du µC (couche 0).
Le C est un langage dit "haut niveau" et donc utilise des instructions plus puissantes, dans le sens beaucoup plus lisible et plus proche de notre logique d'humain et surtout en quasi totale indépendance de la cible (le µC), tout du moins pour la partie applicative du programme.
Ainsi un code C peut être porté sur d'autres cibles, moyennant très peu de modifications, contrairement à l'assembleur qui lui est intimement lié au matériel exploité.
Ces instructions haut niveau sont d'abord traitées et manipulées par le préprocesseur pour pouvoir être traduites (assemblé) par le compilateur qui génère un fichier objet.
Ensuite le linker entre en scène quand il y a plusieurs sources à relier entre eux et/ou des librairies à associer au code principal, on obtient alors un fichier exécutable par le µC cible.

L'avantage du C est essentiellement lié aux objectifs suivants:

-> temps de développement bien plus court sur des projets plus complexes.
-> un même développeur connaissant C permet de ne pas avoir x développeurs connaissant le langage machine pour chaque µC.
-> facilité de maintenance du code sans devoir y passer des semaines quand le développeur n'est pas celui qui a écrit le code original.

Pour autant l'insertion de code assembleur est indispensable dans un programme en C afin d'optimiser certaines fonctions ou optimiser la taille du code généré.
Pour par exemple faire entrer un code dans un µC plus petit en terme de mémoire programme, donc moins cher.

La connaissance des 2 langages est indispensable pour faire la différence entre un programme fonctionnel (sur table) et un programme optimisé et sécurisé (industriel).
Notamment il est parfois difficile, voir impossible, de savoir comment le compilateur optimise certaines parties de traitements qui peuvent traduire des faiblesses système voir des bugs.
Pour finir, un programmeur digne de ce nom se doit de connaitre la couche matérielle de la cible, donc doit être capable d'ouvrir le capot et de mettre les mains dans le moteur.

[invite5637435c]

Bob ton exemple est parfait pour ce que je viens de dire juste avant.
L'écriture de code exclusivement en C abouti à faire usage de goto, on peut même affirmer que goto a été créé par des softeux bien en peine à comprendre les mécanismes matériels vu de la couche haut niveau.
Or le traitement dynamique de la mémoire est typiquement ce qui doit être traité en assembleur.
D'ailleurs il n'est pas étonnant de constater que les contrôleurs AMDEC des parties logicielles se focalisent en premier sur l'usage de ces goto, niche à bugs.

[invite5637435c]

Vu qu'on en est à parler plus profondément, l'usage intempestif des "if", "else" souvent au détriment des "swicth case" conduit à des codes "spaghettis" d'où il devient difficile de s'y retrouver.
De même l'usage de machines d'états est rarement enseigné aujourd'hui, ce qui rend les choses encore moins solide d'un point de vue fonctionnel.
Pour en revenir à l'usage du "goto", je laisserai le dernier mot aux créateurs du C (K&R)

"C provides the infinitely-abusable goto statement, and labels to branch to.Formally, the goto is never necessary, and in practice it is almost always easyto write code without it. We have not used goto in this book."

[invite5637435c]

Un dernier truc, pour maintenir un code avec le moins de risque possible d'oublis ou d'erreurs cela consiste aussi à le commenter correctement, tant au niveau du code lui même que des révisions, des entêtes de fonctions, des input/output, etc.
Comme ça 1 semaine ou 6 mois plus tard tu retrouves tes petits sans problèmes.
La programmation implique une rigueur toute particulière qui se voit dès l'ouverture du fichier, et en générale cette rigueur se retrouve dans la manière d'écrire le code, soit c'est du "arlequin" soit c'est du "Ronsard".
J'ai constaté que les gens les plus fainéants (en apparence) sont souvent les mieux organisés (dans leur tête), vu qu'ils n'aiment pas dépenser leur énergie inutilement

[pm42]

No problem, très cher.
Mettons une fonction qui alloue diverses ressources, et qui doive nettoyer derrière elle en cas d'erreur. Voici un exemple normal :

Chacun son truc mais là j'ai un gros doute. J'ai écrit pas mal de code en C pour des éditeurs de logiciel et des projets open-source et je n'ai jamais utilisé goto.
Dans ton exemple, je peux penser à pas mal de solutions pour éviter goto justement.

Ton écriture duplique également la déallocation des ressources avant ton return principal (cas normal) et dans le goto (avec les if)...
Ce qui veut dire que si tu en ajoutes une, tu vas devoir gérer sa désallocation en 2 endroits.

Sinon, goto n'est pas du tout la même chose que les exceptions dans les autres langages puisqu'il ne permet pas le saut à du code de traitement d'erreur défini dans une fonction appelante n'importe où dans la pile. Pour cela en C, il y a setjmp/longjmp.

[inviteb9f49292]

Chacun son truc mais là j'ai un gros doute. J'ai écrit pas mal de code en C pour des éditeurs de logiciel et des projets open-source et je n'ai jamais utilisé goto.
Dans ton exemple, je peux penser à pas mal de solutions pour éviter goto justement.

Et pourtant si... le "GOTO considered harmfull" a été pris au pieds de la lettre par toute une génération de codeurs sans aucune mise en perspective... Alors que son utilisation pour gérer les "multiples entrées - unique sortie" et clairement plus lisible et plus maintenable... L'exemple de Bobfuck n'est peut-être pas assez travaillé mais il est parlant. Et pour trouver des des codes open-source où cette technique est utilisée il suffit de jeter un oeil au noyau linux par exemple, OpenSSL (Heartbleed avec déclenché une fureur car le bug était dû à un goto copié-collé)...

Sinon, goto n'est pas du tout la même chose que les exceptions dans les autres langages puisqu'il ne permet pas le saut à du code de traitement d'erreur défini dans une fonction appelante n'importe où dans la pile. Pour cela en C, il y a setjmp/longjmp.

Effectivement, la localité (intra-fonction et intra-thread) est une énorme différence... et setjmp/longjmp est bien un moyen d'implémenter un mécanisme d'exceptions en C. Mais c'est un aspect que je trouve plutôt marrant, on casse l'utilisation de goto alors que ça reste très localisé, mais je n'entends pas de critique sur l'utilisation des exceptions qui rends quasiment impossible la réflexion sur le chemin prit par le code, et donc apporte sont lot de problème de gestion de ressource...

Pour en revenir au débat initial:

Pour autant l'insertion de code assembleur est indispensable dans un programme en C afin d'optimiser certaines fonctions ou optimiser la taille du code généré.
Pour par exemple faire entrer un code dans un µC plus petit en terme de mémoire programme, donc moins cher.

La connaissance des 2 langages est indispensable pour faire la différence entre un programme fonctionnel (sur table) et un programme optimisé et sécurisé (industriel).
Notamment il est parfois difficile, voir impossible, de savoir comment le compilateur optimise certaines parties de traitements qui peuvent traduire des faiblesses système voir des bugs.
Pour finir, un programmeur digne de ce nom se doit de connaitre la couche matérielle de la cible, donc doit être capable d'ouvrir le capot et de mettre les mains dans le moteur.

Je te trouve trop radical. J'ai beaucoup bossé sur MSP430 (et ARM7 mais c'est beaucoup plus gros) et j'ai fait plusieurs projet sans écrire (ni lire) aucune ligne d'assembleur (pas des projets du week-end dans le garage, mais du pro). Il est vrai que je profitais d'un compilateur fonctionnel (mspgcc) et des couches basses déjà écrite (FreeRTOS). J'ai dû m'y mettre pour réécrire les couches basses de FreeRTOS sur la nouvelle mouture de GCC, j'en ai bavé parce que je ne connaissais pas l'assembleur (mais pas principalement), maintenant ça marche... et j'ai tout oublié de l'assembleur MSP430...
Mais je fais la distinction entre connaître l'assembleur, et connaître la plateforme, ce qui est pour le coup indispensable.
(nous sommes bien d'accord que cette discussion n'est valide que pour les micro-contrôleur, pour le commun des développeurs "haut-niveau" l'assembleur a encore moins d'intérêt)

[pm42]

Et pourtant si... le "GOTO considered harmfull" a été pris au pieds de la lettre par toute une génération de codeurs sans aucune mise en perspective... Alors que son utilisation pour gérer les "multiples entrées - unique sortie" et clairement plus lisible et plus maintenable... L'exemple de Bobfuck n'est peut-être pas assez travaillé mais il est parlant.

Oui, on peut nuancer en effet. Ma remarque portait sur les affirmations que je trouve très contestables de bobfuck parce qu'à l'emporte-pièce justement :
1) on ne peut pas se passer de goto
2) c'est équivalent aux exceptions

Et son exemple est justement mauvais.
Maintenant, du goto bien fait peut être acceptable et on trouve facilement des critères pour cela. Je préfère l'écriture de petites fonctions courtes voir de pointeurs de fonctions en mode "continuations" pour la lisibilité et la réutilisabilité du code, en gros en important dans le C des concepts de langages plus évolués.
Mais j'ai aussi écrit du code embarqué avec ressources contraintes et je reconnais que dans ce cas notamment (et pas exclusivement), cette stratégie plus coûteuse n'est pas forcément la meilleure.

mais je n'entends pas de critique sur l'utilisation des exceptions qui rends quasiment impossible la réflexion sur le chemin prit par le code, et donc apporte sont lot de problème de gestion de ressource...

Et pourtant. Pour la gestion de ressources, certains langages supportent une logique ARM (pas le proc, l'automatic ressource management) qui règle le problème. Le try avec resources de Java 7 est un exemple.
Et les langages fonctionnels évitent les exceptions pour garder l'intégrité référentielle. Perso, je code comme ça maintenant quand je fais du Scala.

[inviteb9f49292]

Maintenant, du goto bien fait peut être acceptable et on trouve facilement des critères pour cela.

J'insiste, le goto est la meilleur solution pour le type de problème soulevé par Bobfuck (même si son exemple n'est pas bon)

Je préfère l'écriture de petites fonctions courtes voir de pointeurs de fonctions en mode "continuations" pour la lisibilité et la réutilisabilité du code

Tu peux développer stp, je ne comprends pas ce que tu veux dire par fonctions en mode "continuations" et ça m'intéresse.

en gros en important dans le C des concepts de langages plus évolués.

...nous sommes de la même école... Mais le seul concept "évolué" que j'utilise régulièrement en C est la POO, ce que j'ai essayé du reste (exceptions, ramasseur de miette) ne m'a pas convaincu pour mon "niveau" (embarqué type MSP430 ou linux).

Et pourtant. Pour la gestion de ressources, certains langages supportent une logique ARM (pas le proc, l'automatic ressource management) qui règle le problème. Le try avec resources de Java 7 est un exemple.
Et les langages fonctionnels évitent les exceptions pour garder l'intégrité référentielle.

J'ai presque envi de dire que les exceptions imposent du garbage collector (qui s'accompagne de ses propres problèmes, amha essentiellement côté perf / déterminisme). Mais ce que je critiquais des exceptions c'est plus pour la difficulté à raisonner sur le code... sachant que c'est _LE_ reproche qu'on fait au goto.

Perso, je code comme ça maintenant quand je fais du Scala.

c'est du fonctionnel c'est ça ? Va vraiment falloir que je m'y mette un jour à ce paradigme fonctionnel!

[pm42]

J'insiste, le goto est la meilleur solution pour le type de problème soulevé par Bobfuck (même si son exemple n'est pas bon)

Ok. J'ai bien entendu.

Tu peux développer stp, je ne comprends pas ce que tu veux dire par fonctions en mode "continuations" et ça m'intéresse.

L'idée derrière les continuations est que le code qui est exécuté après une instruction est une fonction passée en argument à l'instruction actuelle.
Donc tu écris ton code comme des fonctions et tu passes les pointeurs de celle de traitement d'erreur et de celle de "tout va bien on continue".
Je ne suis pas très clair mais dans les langages qui supportent, ca permet de faire pas mal de choses.

La page Wiki est super abstraite et je n'ai pas d'exemple clair sous la main donc je me rends compte que ma description n'est pas vendeuse mais c'est une approche intéressante pour gérer les entrées sorties avec cas d'erreur.
https://fr.wikipedia.org/wiki/Continuation

Ceci dit, je repense à ce que tu disais sur les garbage collector, etc et c'est vrai que quand je vois le code pour gérer 3 malloc et 1 fichier en C dont on parle ici, je ne regrette pas de coder au quotidien avec des langages de très haut niveau.

c'est du fonctionnel c'est ça ? Va vraiment falloir que je m'y mette un jour à ce paradigme fonctionnel!

Scala, c'est de l'hybride fonctionnel/objet. Le pure fonctionnel, c'est F# ou Haskell et c'est un plus gros saut conceptuel.

[invite5637435c]

(nous sommes bien d'accord que cette discussion n'est valide que pour les micro-contrôleur

Nous sommes bien d'accord là dessus, même si le soft embarqué s'est considérablement complexifié les 10 dernières années avec des µC très puissants utilisés dans des applications sensibles (automobile notamment).

pour le commun des développeurs "haut-niveau" l'assembleur a encore moins d'intérêt.

Moins là dessus mais tout dépend du projet, du temps alloué au projet, des contraintes matérielles et du niveau d'exigences de l'application ou du système, AMDEC ou autres procédures coercitives, redondances, etc.

[bobflux]

Oui, on peut nuancer en effet. Ma remarque portait sur les affirmations que je trouve très contestables de bobfuck parce qu'à l'emporte-pièce justement :
1) on ne peut pas se passer de goto
2) c'est équivalent aux exceptions

En effet, se passer de goto en C ajoute des bugs et de la complication dans le traitement des erreurs. Goto n'est pas équivalent aux exceptions, c'est un moyen un peu moche mais fonctionnel de contourner le fait que le C n'offre pas de traitement des exceptions propre et bien pensé dans le langage.

J'insiste, le goto est la meilleur solution pour le type de problème soulevé par Bobfuck (même si son exemple n'est pas bon)

C'est vrai que mon exemple était fait à l'arrache et pourri. J'aurais mieux fait de passer 10 secondes sur google
Voici un excellent exemple, difficile de faire plus clair !

http://git.kernel.org/cgit/linux/ker...89922b99#n2046

J'ai presque envi de dire que les exceptions imposent du garbage collector (qui s'accompagne de ses propres problèmes, amha essentiellement côté perf / déterminisme).

Non, pas forcément, les exceptions imposent simplement un mécanisme dans le langage pour exécuter un code de nettoyage en sortie de scope, quelle que soit la raison de la sortie. Une clause "finally", en quelque sorte.
C++ utilise l'idiome RAII (le nettoyage est fait dans le destructeur d'une variable locale), mais ce n'est pas le seul idiome, ni le meilleur. C'est très bien si on veut, en effet, détruire un objet. Mais le RAII oblige à créer une classe pour le moindre bout de code de nettoyage, ce qui est assez pénible.

On pourrait citer un mécanisme assez universel, inspiré (de mémoire) du D:

{
    truc a = acquiert_un_truc();
    scope(exit) { rend_le_truc(a); }
}

Ici le langage a un idiome qui permet d'indiquer qu'en sortie de scope {}, le bout de code { rend_le_truc(a); } doit être exécuté, qu'on sorte du scope par exception ou un simple return. C'est assez élégant, je trouve. C'est comme un finally, mais déporté juste en dessous de l'initialisation, comme ça les deux lignes de code liées sont juste à côté, c'est très clair. Il me semble que le C++11 a un truc du genre.

Enfin, la gestion des exceptions avec setjmp()/longjmp()....
Ahem. postgresql utilise ce principe, avec un grand succès. Il y a juste un hic, qui est que le handler n'a aucune idée des ressources qu'il doit libérer.
- Tout ce qui est alloué est noté méticuleusement de façon à pouvoir le libérer ensuite (locks, etc) ce qui suppose bien sûr qu'aucune fonction de la lib standard n'est utilisée sans wrapper. Le code de gestion d'exceptions nettoie tout ça.
- et ensuite... l'allocateur de mémoire est remis à zéro.

[invite352bbdac]

Ce que je souhaite faire en assembleur c’est :
1 - Surveiller un bit d’un port d’entrée de 8 bit. (On utilise INPUT & JUMP Z? car le bit ZERO est mis à jour avec l’INPUT).
2 - Si le bit est à 1, alors on change l’état des LEDS sur le port de 8 bit en sortie.

Ensuite, j’aimerais continuer d’observer le même bit du port d’entrée et recharger l’état des LEDS pour voir que mon aimer fonctionne.
Le timer est codé en VHDL à côté du processeur (picoblaze-3 softcore).

—————————————————————————————— —————

Autre chose évoqué, il faut que je révise l’architecture de style harvard ou von neuman.

Aussi, observer le picoblaze-3 au niveau de son architecture.

—————————————————————————————— ——————

J’ai programmé un moment sous le logiciel air-studio ou cvavr en langage assembleur ou en C sous ATMEGA8515 ou 8535.

—————————————————————————————— ——————

CHOSE IMPORTANTE : quand le processeur est allumée, l’architecture tourne sans cesse.
Ainsi, un programme de manière principale est-il forcement une boucle infinie? Il faut tout de même faire tourner son programme sinon si il s’arrête et s’il n’y a pas d’interruption, le processeur ne servira à rien.

Merci de vos remarques.

[bobflux]

Tu veux le faire en tant qu'exercice ?
Pourquoi ne pas utiliser une interruption pour surveiller ton pin ?