Excellent !! Je rajeunis de presque 40 ans, époque où on associait le 8259 d'Intel aux µProcesseurs 8085 ou 8086 et où tout ça se programmait majoritairement en assembleur. Grand merci pour cette piqûre de rappel !
Quelques notions d'assembleur sont utiles pour comprendre ce que fait un compilateur. Le recours à l'assembleur n'est en revanche pas nécessaire la plupart du temps.
Excellent ! Je suis fan de l'assembleur. Il est indispensable pour moi lorsque la place mémoire est comptée ou que la vitesse d'exécution est primordiale. Et si je veux un circuit ultra fiable, avec zéro bug, c'est lui que j'utilise ; j'ai toujours peur que le langage C me génère des trucs bizarres et qui seraient passés inaperçus et qui risqueront de provoquer des bugs. J'utilise habituellement des PICs et je débute avec les cartes arduino car cela évite de graver un circuit imprimé et peut être directement utilisé dans une application. Encore merci.
bonjour, je n'ai pas bien compris pourquoi il stockait dans la RAM la moitié de l'adresse de la routine d'interruption utilisateur. Pourquoi pas l'adresse directement ?
Bonjour, merci pour vos cours très intéressants sur cette famille de micros ! à 16:40, le commentaire indique que compteurBP occupe 2 octets aux adresses hex 80011e et 80011f. le poids fort des adresses (80) qui n'apparait pas est bien implicite pour les instructions lds et sts avec la sram ? De même, r25 qui n'apparait pas pour l'incrémentation sur 16 bits (adiw r24,1) est aussi implicite c-à-d wL=r24 et wH=r25 ?
Oui. C'est tout à fait ça. Pour en savoir plus, vous pouvez consulter l'AVR Instruction Set Manual : ww1.microchip.com/downloads/en/devicedoc/atmel-0856-avr-instruction-set-manual.pdf
Bonjour et merci pour ces explications claires et détaillées. Pouvez-vous me dire s'il est possible, à la sortie de notre fonction d'interruption, de ne pas reprendre à la valeur du registre stockée (au moment de l’interruption) mais de relancer la fonction loop par exemple ?
Bonsoir. Je me permets ce copier coller d'une réponse déjà faite sur ce sujet : Je ne vois pas trop l'intérêt que cela pourrait avoir étant donné que les interruptions se déclenchent à des moments non prévisibles. Pour un traitement particulier lié à une IT, il suffit de positionner un indicateur et de le tester dans la boucle principale du programme. Au delà de cette remarque, un tel comportement pauserait plusieurs problèmes. D'abord, on peut avoir interrompu un calcul. Le non achèvement du calcul amenant tôt ou tard à des erreurs imprévisibles. Ensuite, l'interruption pouvant se produire également lors d'appels de fonctions/méthodes imbriquées, l'état de la pile n'est pas connu et le risque de pertes de données et évident. Donc ce n'est pas prévu/possible et dangereux.
@@EricPeronnin Merci d'avoir pris la peine de m'expliquer. Que faudrait-il alors utiliser pour interrompre une fonction sur un événement (BP ou autre) et revenir au début du loop par exemple ?
Repartir où on le souhaite à l'issue d'une IT n'est pas possible et n'a pas vraiment de sens. Si vous voulez pouvoir traiter ultérieurement le fait qu'une IT a eu lieu, il faut utiliser un indicateur que vous testerez à chaque tour de loop() pour avoir connaissance de l'existence récente d'une IT. Au moment du traitement, vous remettrez l'indicateur à false. Exemple : volatile bool indicateur = false; void ISR_BP() { indicateur = true; } void loop() { if (indicateur) { indicateur = false; // votre traitement suite à une IT } // reste de la loop }
Excellent !! Je rajeunis de presque 40 ans, époque où on associait le 8259 d'Intel aux µProcesseurs 8085 ou 8086 et où tout ça se programmait majoritairement en assembleur. Grand merci pour cette piqûre de rappel !
Quelques notions d'assembleur sont utiles pour comprendre ce que fait un compilateur. Le recours à l'assembleur n'est en revanche pas nécessaire la plupart du temps.
...Eh oui! J'ai connu ça!
Excellent ! Je suis fan de l'assembleur. Il est indispensable pour moi lorsque la place mémoire est comptée ou que la vitesse d'exécution est primordiale. Et si je veux un circuit ultra fiable, avec zéro bug, c'est lui que j'utilise ; j'ai toujours peur que le langage C me génère des trucs bizarres et qui seraient passés inaperçus et qui risqueront de provoquer des bugs.
J'utilise habituellement des PICs et je débute avec les cartes arduino car cela évite de graver un circuit imprimé et peut être directement utilisé dans une application.
Encore merci.
Merci pour cette vidéo extrêmement détaillée et claire. Ça me ramène avec délice à mon apprentissage de l’assembleur. Pour moi, Z80 et 6809.
Très bon rappel, tout ça me rappelle le temps où, à l'aide des cours de Bigonoff, je programmais des PIC's en "assembleur"
bonjour, excellente video, je m'abonne et consulte les autres videos, merci pour ce partage :)
Laurent
Cela se complique !! 🤔 On reste concentré jusqu'au bout 😄 superbe video 👏👍
Très riche et (suffisamment) bien détaillé pour voir tout ça de plus près !
Encore merci Eric et longue vie à la chaîne.
Bien des choses !!!
Super intéressant: comme d'habitude !
Merci 😁
Super explication
Merci 😊
Bonjour, excellente video, comme d'hab. bonne journée
Excellent, encore une fois!
bonjour, je n'ai pas bien compris pourquoi il stockait dans la RAM la moitié de l'adresse de la routine d'interruption utilisateur. Pourquoi pas l'adresse directement ?
Bonjour, merci pour vos cours très intéressants sur cette famille de micros ! à 16:40, le commentaire indique que compteurBP occupe 2 octets aux adresses hex 80011e et 80011f. le poids fort des adresses (80) qui n'apparait pas est bien implicite pour les instructions lds et sts avec la sram ? De même, r25 qui n'apparait pas pour l'incrémentation sur 16 bits (adiw r24,1) est aussi implicite c-à-d wL=r24 et wH=r25 ?
Oui. C'est tout à fait ça.
Pour en savoir plus, vous pouvez consulter l'AVR Instruction Set Manual : ww1.microchip.com/downloads/en/devicedoc/atmel-0856-avr-instruction-set-manual.pdf
Bonjour et merci pour ces explications claires et détaillées.
Pouvez-vous me dire s'il est possible, à la sortie de notre fonction d'interruption, de ne pas reprendre à la valeur du registre stockée (au moment de l’interruption) mais de relancer la fonction loop par exemple ?
Bonsoir. Je me permets ce copier coller d'une réponse déjà faite sur ce sujet :
Je ne vois pas trop l'intérêt que cela pourrait avoir étant donné que les interruptions se déclenchent à des moments non prévisibles.
Pour un traitement particulier lié à une IT, il suffit de positionner un indicateur et de le tester dans la boucle principale du programme.
Au delà de cette remarque, un tel comportement pauserait plusieurs problèmes.
D'abord, on peut avoir interrompu un calcul. Le non achèvement du calcul amenant tôt ou tard à des erreurs imprévisibles.
Ensuite, l'interruption pouvant se produire également lors d'appels de fonctions/méthodes imbriquées, l'état de la pile n'est pas connu et le risque de pertes de données et évident.
Donc ce n'est pas prévu/possible et dangereux.
@@EricPeronnin Merci d'avoir pris la peine de m'expliquer.
Que faudrait-il alors
utiliser pour interrompre une fonction sur un événement (BP ou autre) et revenir au début du loop par exemple ?
Repartir où on le souhaite à l'issue d'une IT n'est pas possible et n'a pas vraiment de sens.
Si vous voulez pouvoir traiter ultérieurement le fait qu'une IT a eu lieu, il faut utiliser un indicateur que vous testerez à chaque tour de loop() pour avoir connaissance de l'existence récente d'une IT. Au moment du traitement, vous remettrez l'indicateur à false.
Exemple :
volatile bool indicateur = false;
void ISR_BP() {
indicateur = true;
}
void loop() {
if (indicateur) {
indicateur = false;
// votre traitement suite à une IT
}
// reste de la loop
}