Et pourquoi pas du C ?? L'environnement de développement est pensé pour ça. L'assembleur peut se révéler meilleur pour certaines choses mais reste bien moins maintenable. Par exemple, tu vas avoir besoin de recherches en cartos 2D avec interpolation. C'est plutôt fastidieux et non portable de rester sur l'assembleur. Par le passé j'ai écrit un contrôle moteur électrique (aimants permanents - contrôle vectoriel) en assembleur sur du PIC 16 bits, avec utilisation du coeur DSP. Le gain était pas mal (13 µs vs 250 !!). Mais pour le reste, je trouve que c'est de la surqualité. En général je me donne la règle suivante : C avec des règles d'écritures de base, assembleur (inline ou pas selon le cas), assembleur pour les routines critiques (par exemple sur le projet moteur élec, j'avais codé une "super division" en virgule fixe avec mise à l'échelle dynamique. Pas mal de taf mais très efficace). Pour le bit mapping en C, j'ai des astuces, trouvées dans une vieille note d'application de Renesas (à l'époque Hitachi coeur SH2). ça utilise des créations de type à base de typedef union ;)
Je ne programme pas en C car je suis tombé dans le langage machine quand j'étais petit. Plus tard, et encore maintenant, toutes les applications professionnelles que j'ai du faire ont été faites en assembleur pour des raisons de criticité de la gestion du temps. Question portabilité ce n'est pas critique. Mais on y viendra peut-être un jour bien que ce besoin ne sait jamais fait sentir.
@@Lino100 punaise, t'es plus un vieux de la vieille que moi ma parole. Il faut qu'on parle. j'ai travaillé aussi sur du armv7 nxp, les séries lpc xxxx vers 2005 par là. Pas mal mais pour le temps réel ça manque un peu de réactivité (réponse aux interruptions c'est pas top). On a un bon cpu mais l'architecture globale n'est pas top. Notamment les périphériques et la latence aux Interruptions. PSA demande un résolution de 0.1° d'angle à 6000 tours, ben on est à 2,7 us ...
@@yannickhildenbrand5848 mes débuts c'est Z80, 6502 et 6809 😊 et si je dis que dans mon école il y avait un Micral et que j'avais remis en fonction un Univac BC7 je vais passer pour un Zombie ! On a été les premiers à utiliser des Microchip en France au début des années 90. Fin des années 90 j'ai utilisé de l'Hitachi aussi...
Je me demande aussi quelle est la pertinence d'avoir 0.1° de résolution ? Amha 1° est bien suffisant. Le capteur de vilebrequin donne 120 périodes avec un timer en capture ça fait 83us @6000tr/mn de quoi avoir le temps de faire plein de choses. Ce n'est pas tant le temps de réponse le problème (tu gères avec l'avance) mais le jitter sur cette réponse 😉 Avec les nouveaux NXP Kinetis la réponse aux IT est assez stable. J'aimerais bien en discuter avec toi (par email) si tu le permets.
Et pourquoi pas du C ?? L'environnement de développement est pensé pour ça. L'assembleur peut se révéler meilleur pour certaines choses mais reste bien moins maintenable. Par exemple, tu vas avoir besoin de recherches en cartos 2D avec interpolation. C'est plutôt fastidieux et non portable de rester sur l'assembleur. Par le passé j'ai écrit un contrôle moteur électrique (aimants permanents - contrôle vectoriel) en assembleur sur du PIC 16 bits, avec utilisation du coeur DSP. Le gain était pas mal (13 µs vs 250 !!). Mais pour le reste, je trouve que c'est de la surqualité. En général je me donne la règle suivante : C avec des règles d'écritures de base, assembleur (inline ou pas selon le cas), assembleur pour les routines critiques (par exemple sur le projet moteur élec, j'avais codé une "super division" en virgule fixe avec mise à l'échelle dynamique. Pas mal de taf mais très efficace). Pour le bit mapping en C, j'ai des astuces, trouvées dans une vieille note d'application de Renesas (à l'époque Hitachi coeur SH2). ça utilise des créations de type à base de typedef union ;)
Je ne programme pas en C car je suis tombé dans le langage machine quand j'étais petit. Plus tard, et encore maintenant, toutes les applications professionnelles que j'ai du faire ont été faites en assembleur pour des raisons de criticité de la gestion du temps. Question portabilité ce n'est pas critique. Mais on y viendra peut-être un jour bien que ce besoin ne sait jamais fait sentir.
@@Lino100 punaise, t'es plus un vieux de la vieille que moi ma parole. Il faut qu'on parle. j'ai travaillé aussi sur du armv7 nxp, les séries lpc xxxx vers 2005 par là. Pas mal mais pour le temps réel ça manque un peu de réactivité (réponse aux interruptions c'est pas top). On a un bon cpu mais l'architecture globale n'est pas top. Notamment les périphériques et la latence aux Interruptions. PSA demande un résolution de 0.1° d'angle à 6000 tours, ben on est à 2,7 us ...
@@yannickhildenbrand5848 mes débuts c'est Z80, 6502 et 6809 😊 et si je dis que dans mon école il y avait un Micral et que j'avais remis en fonction un Univac BC7 je vais passer pour un Zombie ! On a été les premiers à utiliser des Microchip en France au début des années 90. Fin des années 90 j'ai utilisé de l'Hitachi aussi...
Je me demande aussi quelle est la pertinence d'avoir 0.1° de résolution ? Amha 1° est bien suffisant. Le capteur de vilebrequin donne 120 périodes avec un timer en capture ça fait 83us @6000tr/mn de quoi avoir le temps de faire plein de choses. Ce n'est pas tant le temps de réponse le problème (tu gères avec l'avance) mais le jitter sur cette réponse 😉 Avec les nouveaux NXP Kinetis la réponse aux IT est assez stable. J'aimerais bien en discuter avec toi (par email) si tu le permets.
@@Lino100 on peut discuter par mail, sans problème :)