j'ai compris se que t'as écris comme programme ;mais j'aurai tjrs une erreur quand je compile !
"C:\Users\ADMINI~1\AppData\Local\Temp\arduino_build_354500\sketch\ouf.ino.cpp.o"
ouf:1: error: expected constructor, destructor, or type conversion before ';' token
main() {
^
exit status 1
expected constructor, destructor, or type conversion before ';' token
pour les résistance je les pas fait juste à la simulation mais en réalité on devrait avoir des résistance
effectivement il a marché , je veux vous dire si - on veut décalé une LED éteint et le reste allumé (au lieu de décalé une allumé et le reste éteints ),es-que on pourra le faire on gardant le même délai en changeant que les valeur misent aux registres .?
Si vous voulez juste un délai ponctuel de 2 µs, vous pouvez aussi insérer des NOP (instruction matérielle qui ne fait rien que manger un cycle d’horloge) en inline (pas d’appel de fonction), ce qui vous donne une granularité plus faible pour affiner l’attente (0,0625 µs par NOP)
Vous mettez un #define NOP __asm__ __volatile__ ("nop\n\t")en début de sketch et quand vous voulez griller 0,0625 µs vous mettez NOP;dans votre code. Ils vous en faudra 32 à la suite pour griller vos 2µs
Cela dit vous n’etes Pas à l’abri d’une interruption qui met à jour la valeur de la fonction millis() donc dans l’absolu il faudrait interrompre et réactiver les interruptions avant et après, ce qui bien sûr mange des cycles d’horloge...
Il y a la commande en assembleur [SEI (Set Global Interrupt Flag)](Microchip Docs SEI.html) et CLI (Clear Global Interrupt Flag) qui respectivement active et desactive les interruptions et qui prennent elles aussi 1 cycle. Donc pour vos 2µs il faut un CLI suivi de 30 NOP suivi d’un SEI (Il n’y a pas besoin de sauvegarder le registre SREG car vos NOP ne vont pas le toucher).
les macros cli() et sei() si je me souviens bien sont juste des define de __asm__ __volatile__ ("cli") et idem pour sei, donc devraient prendre juste 1 cycle.
pepe:
Mais comme je le suggérais au post #1, toute la difficulté consiste à tenir compte du temps pris par la réalisation des opérations dans le délai qui les sépare.
Par exemple, pour séparer de 2 µs, soit 32 cycles, la production de deux événements identiques, si la production d'un événement prend 1 cycle alors il faudra se limiter à un délai de 31 cycles (comme dans l'exemple du post #11) et si la production d'un événement prend 4 cycles alors il faudra se limiter à un délai de 28 cycles (comme dans les exemples des posts #3 et #9).
Tout à fait.
pepe:
Pour que les délais souhaités entre plusieurs opérations soient respectés, il faut empêcher la survenue des interruptions durant la période qui débute avant la première opération et qui se termine après la dernière. Le CLI doit donc être placé avant la première opération et le SEI après la dernière.
Oui c'est vrai aussi
pepe:
Dans les cas de figure où rien ne justifie la survenue d'interruptions (comme dans les programmes simples ci-dessus, qui n'utilisent pas les interfaces de communication ni les fonctions de délais d'Arduino), il est préférable de ne pas les activer (ce que font les programmes ci-dessus) ni les laisser activées inutilement, ou bien de les interdire définitivement en plaçant un CLI dès le départ.
c'est un choix un peu difficile pour un débutant qui ne sait pas si les librairies ou le code qu'il va utiliser a besoin d'interruptions.
Si on veut garder une led éteinte et les sept autres allumée, alors le code en assembleur est inchangé, mais l'état initial des leds doit être modifié.
En effet, comme à chaque pas l'opération consistait à changer l'état de deux leds en écrivant un 1 dans les bits correspondants des registres PINx (avec x=D ou B). Donc une simple inversion de ces changements nécessite exactement les mêmes opérations, mais avec un état différent des leds au départ.
Pour que le programme démarre avec toutes les leds allumées sauf la première (sortie #2), les deux premières lignes de code deviennent :
d'accord j'ai été pas loin j'ai initialisé les portes de sortie avec ces deux ligne mais j'ai pensé aussi a modifier les valeur qu'on misent au registre r16,17 a chaque fois et j'ai compris aussi mon erreur .
je vous remercie pour Mr.J-M-L pour votre idée.
autre chose si vous me permettez :
si je veux ajouter une sortie qui gère une impulsion chaque les 12 chenillard par exemple (c'est a dire il fait la boucle (12 fois) ==>impulsion de durée 2Us généré au Pind 10 ou autre) et refait la boucle :
comment je puisse déclarer une nouvelle sortie ,et compteur a l’intérieur de la boucle qui incrémente avec une une condition de if
ah comme même n'est pas facile de crée une boucle de if ! bonne explication, merci .
le problème ce que je cherche a réalisé l’impulsion a sortie de 10 apparaît au début de chaque (12 cycle), càd
impulsion à la sortie 10 =1 au même temps de l'allumage de LED de sortie 2 . peut etre avec ce graphe vous me comprenez ce que je veux dire.
Et les macros Atmel de l'avr-libc qui (à ce que j'ai compris) ne sont pas basées sur de la programation mais sur l'éxécution de tâches particulière par le matériel ?
Matériel qu'en tant que concepteur Atmel connaît mieux que personne.
ce qui concerne la précision du résultat et sa reproductibilité d'une plateforme de développement à l'autre.
Alors là vu qu'il s'agit d'une utilisation très particulière j'estime que le sujet se doit d'être résolu comme un cas particulier sur une plateforme précise. Il faut oublier les usines à gaz de l'universalité qui ne font que brider le matériel..
J'ai envie de faire une autre remarque.
Pousser un CI (et sa programmation) dans ses possibilités ultimes est un choix respectable, que j’apprécie personnellement, et qui peut apporter de la jouissance quand on fini par gagner.
Mais est-ce le souhait de l'auteur du sujet ?
Si ce n'est pas son souhait il faut qu'il change de plateforme. Il existe des cartes Nucleo avec des microcontrôleurs qui tournent entre 72 et 200 MHz qui sont me semble-t-il bien plus adaptées. Cerise sur le gâteau elles un prix équivalent à celui d'une MKR à 48 MHz, .
Bien sur il faut sortir d'Arduino pour entrer dans Mbed mais Mbed est plus puissant et mieux maintenu qu'Arduino donc aucune inquiètudes à avoir.
PS : le portage d'arduino par le groupe stmduino cherche trop a coller à arduino et gaspille les possibilités des STM32.
Une autre solution serait de faire une réalisation matérielle avec un CPLD (un FPGA serait démesuré pour l'application).
Coté coût et surface occupée ce n'est pas gagné mais coté plaisir du développement c'est top.
Mais un gros investissement intellectuel pour apprendre à programmer un CPLD est à prévoir.
