Reprise du message précédent :

C'est ce que t'avais demandé non ? (flemme de relire l'histo )

48 oui. Après j'aurais pas dot non a la prime en plus

Mais entre temps y'a eu du mouvement ici... Demain je vais les rappeler pour avoir des détails sur le projet sur lequel ils veulent me mettre au depart .

bon j'ai des moteurs BLDC (avec et sans capteurs), des transistors, des drivers, des MCU avec leur toolchain, des datasheets et des AN, une alim de PC, un multimètre, une chiée de résistances et de condos, des comparateurs, un oscilo 2 voies, une piscine pleine de gelée de groseille et 2 catcheuses naines en bikini.
 
 Je me couche pas tant que j'ai pas un moteur qui tourne en boucle fermée.

Non mais je cherche plus bas qu'au niveau js et pas spécifiquement dans ce language, quelque part
dans la conversion decimal->binaire des flottants (quelque part au niveau des algos dragon4/grisu3).

Intuitivement je me dis que c'est pas possible (on fait juste un changement de base), mais
y'avait peut-être moyen d'exprimer un truc équivalent à 0*inf d'une manière que je voyais pas,
ou quelque chose dans cet esprit.

le pire truc du monde, c'est googler et tomber sur un serveur d'un ancien prof

'tain je suis paumé grave.

j'ai un registre mapé en mémoire, il est write only, quand j'écris dedans, un truc se passe. Je veux pas que le compilo optimise les write ou fasse le malin sur les sous-expressions. est-ce que volatile est vraiment le bon outil ? ça concerne pas plutôt la lecture ?

Si
 
Normalement t'as des pragmas pour ce genre de chose mais c'est compilo-dépendant

M'enfin si c'est write-only t'as pas de raison de manipuler ton registre plus que ça

Encore une fois, strictement rien compris à ton post.

Un registre "mappé en mémoire" ???
"write only" ? Ca veut dire quoi ? Qu'on ne peut pas le lire ? Si oui, à quoi ça sert ?
edit: "The most frequent occurrences of write-only memories are where the memory locations are registers or an integrated circuit being used to control, or pass information to, hardware outside the processor."

Moi je comprends volatile comme le fait que le compilo est obligé d'aller lire la variable en RAM avant de l'utiliser et de la mettre à jour aussitôt écrite. Autrement dit, toute modification du registre est aussitôt répercutée sur l'adresse de la variable en RAM alors qu'en temps normal, le compilo pourrait se contenter de mettre à jour cette dernière uniquement à la fin d'une boucle, par exemple. Donc ça désactive effectivement de nombreuses optimisations.

Si quelqu'un d'autre a une meilleure explication, je suis intéressé.

ben c'est un registre qui a une adresse dans la mémoire. pour écrire dedans, tu écris la mémoire à une adresse spéciale et ça écrit dedans (il hijack simplement le bus).
il est write only parce que quand tu écris, ça change un certain nombre de trucs au niveau du matériel, si tu le lis, tu recevra 0 (garanti). Y'a un autre registre pour voir l'état du matos.
 
 
dans mon cas, c'est le registre set/reset des GPIO. accroche-toi à ton slip.  
Y'a 16 pins dans le groupe. Y'a un registre normal qui reflète l'état des pins tu peux le lire ou l'écrire, mais t'est obligé d'écrire les 32bits d'un coup. Du coup il sert un peu à rien en écriture, si t'es en train de jouer avec 3 pins et que les pins d'à côté sont gérés par un autre sous-système tu vas tout foutre en l'air en écrasant tout d'un coup.
du coup y'a 2 autres mécanismes pour changer l'état des pins.
1) le bit-banding : t'as un endroit ailleurs en mémoire où chaque bit du registre est visible sous forme d'un mot de 32bits. du coup tu peux aller écrire là-dedans et ça va changer que ton bit. Le problème c'est qu'il faut aller changer les pins qui t'intéressent une par une, et du coup c'est pas très atomique et ça peut se voir de l'extérieur.
2) la feinte de l'ours rusé atomique. Y'a un deuxième registre de 32 bits: les 16 bits de poids fort sont les pins que tu veux passer à zéro (reset) et les 16 bits de poids faible sont les pins que tu veux passer à 1 (set). Du coup tous les pins qui n'apparaissent ni dans le demi-mot de reset, ni dans celui de set restent comme ils étaient, mais pour ceux que tu vas changer, c'est simultané. Mais quand tu vas lire là-dedans tu reçois zéro, pour voir l'état des pins il y a le registre normal. Évidemment, il faut surtout pas optimiser les write dans ce registre, écrire une valeur puis immédiatement en écrire une autre a un effet sur le matériel (style au premier write tu reset toute les pins qui t'intéressent et au deuxième coup tu mets ton bit pattern, si y'a un pont en H derrière, il va te dire merci).

Oui donc voilà, tu bufferises ta valeur, tu l'écris dans le registre, et basta

M'enfin si tu actives l'optimiseur sur des trucs aussi critiques t'as pas fini de criser

Old shit is old : http://cvsweb.openbsd.org/cgi-bin/ [...] web-markup
 
C'est le diff cvs en dessous ? Parce que si c'est le cas j'arrive pas à le lire

non le diff est là : http://cvsweb.openbsd.org/cgi-bin/ [...] 2=1.18&f=h

 
Merci.

Tu peux pas t'en sortir avec des barrières mémoires ?
Tu encapsules ton registre dans une classe qui fout des barrières autour des écritures pour toi et ca devrait être tout mignon tout propre

FUCK YEAH BIBLE !
 

ça fait 16h, j'arrive même pas à capter le comportement de la chose en boucle ouverte

Et d'un autre côté si tu actives pas un minimum d'optim dans gcc tu rates des warnings

Vu que dans ce cas le gcc est vieux (donc pas moyen de désactiver les optims localement),
je crois que je mettrais plutôt un petit bout d'assembleur dans une fonction dédiée,
au moins ça met en evidence qu'on est pas du tout entrain de spécifier un algorithme.

c'est en Ada

 
Ça tombe bien
 
https://gcc.gnu.org/onlinedocs/gnat [...] mbler.html

non les volatiles c'est dégueulasse et en plus ça peu être buggué sur certaines version de gcc
 
 
l'idéal c'est d'utiliser des fonctions d'écriture et de lecture,
par exemple le kernel linux utilise des fonctions de ce genre là:

 
ces fonctions sont écrites de telle sorte que on est sur que l'écriture se fait au moins une et une seule foi et de façon ordonnée (avec des barrières sur certaines architectures)
ça permet au passage d'avoir du code portable sans les risques de merde du volatile.

J'avais parlé d'encapsuler la lecture et les barrières en premier  

 
C'est pas plutôt que les volatiles c'est un truc qui concerne la lecture et pas l'écriture ?

non non, si on fait ça:
 

 
il est censé écrire 2 fois dans a, alors que sans le volatile il virera la première écriture "inutile"
 

 
sauf que c'est fragile et dangereux de base à cause de bugs ( http://www.cs.utah.edu/~regehr/pap [...] eprint.pdf ), et que sur certaine plateformes/bus c'est insuffisant pour ordonnancer correctement les accès.

Mais quel langage de merde :    
http://www.lua.org/pil/19.1.html

lolwut ?

C'est… original

FYP

 
Du coup si je comprends bien, sa réponse c'est :
 
 

 
Maiouais ! Et ils ont aussi de la doc officielle sur les listes : http://www.lua.org/pil/11.3.html
 

J'ai du mal a voir l'intérêt d'une page de doc là dessus, mais ça me choque pas plus que ça.

C'est moins choquant que pour l'array, oui, mais c'est vraiment lourd d'avoir un langage où même les structures de données les plus bateaux ne sont pas standardisées.

comme en C ?

Ouais enfin c'est une linked list là. Dans un langage haut niveau c'est une structure utile quand t'es basé immutabilité et récursion sinon bof.

task body PWM is
      onPeriod   : Time_Span;
      offPeriod  : Time_Span;
      period     : Time_Span;
      Next_Start : Time      := Clock;
      PWM_On     : Boolean   := True;
   begin
      loop
         period    := Microseconds (1_000_000) / PWMFrequency;
         onPeriod  := period /2;
         offPeriod := period /2;
         if (PWM_On) then
            Off (Pattern (Next_LED));
            PWM_On     := False;
            Next_Start := Next_Start + offPeriod;
         else
            On (Pattern (Next_LED));
            PWM_On     := True;
            Next_Start := Next_Start + onPeriod;
         end if;
         delay until Next_Start;
      end loop;
   end PWM;

vous voyez un bug évident là ? je deviens fou

ouai mets une balise code=ada

je savais pas que ça passait.
 
J'ai l'impression que c'est un truc d'attardé genre la granularité du scheduler, parce qu'à certaines fréquence j'ai une réponse parfaite et à d'autre c'est n'importe quoi , mais on voit bien que le n'importe quoi tombe sur sur des endroits privilégiés.
 
Et plus la fréquence baisse et plus il est capable de suivre ce que je lui dit. Reste à trouver une putain de doc ça fait une demi-heure que je google je trouve rien sur comment on règle le scheduler.

Est ce que c'est possible que le temps d'exécution de ton code soit supérieur  a offperiod ?

ça serait plus simple avec un oscilloscope

non, on parle d'un cortex-M3 à 148MHz, et ça marche bien qu'à des fréquences d'autour de 10Hz
 
sur ma fraiseuse j'ai des process qui tourne à 60kHz sans pb.
 
'tain je trouve pas la doc de ce putain de scheduler