je crois que je fatigue... soucis de relation fréquence/période...

[minioim]

Salut à tous.

bon si vous êtes arrivé sur ce sujet c'est que déjà vous êtes un minimum charitable vu le titre ^^

je vous explique la situation: étant en école d'ingé je ne me considère pas comme un crack en maths mais les maths niveau 3ème ça va je gère. ^^

enfin.. je gérais... avant de me faire 48h d'affilée (à 5-6 heures de sommeil près) sur du code de microcontroleur...

et maintenant j'arrive plus à trouver la relation permettant de déterminer la période correspondant à une fréquence à laquelle on a ajouté une autre fréquence.

bon c'est pas clair... un petit exemple:

j'ai une fréquence 1000Hz (appelons la F). donc de période 1ms (P). je veux lui ajouter 500Hz. j'obtiens 1500Hz (F'), ça me fait une période de 0.66ms (P').

est ce qu'il y a une relation qui permet de passer de 1ms à 0.66ms sachant que les données de départ sont la période P et la constante de 500Hz à ajouter mais sans avoir à revenir en fréquence?

je demande tout ça pour simplifier au maximum le calcul du microcontroleur dans lequel j'ai besoin de ces relations.

la solution qui part de P pour arriver à P' en faisant F=1/P -> F'=F+500 -> P'=1/F' étant assez consommatrice, j'espérais en trouver une plus simpliste...

(je précise que je souhaite ajouter une constante à chaque fois, pas multiplier la fréquence par un rapport, auquel cas ça serait immédiat pour la période)

Bon si vraiment ya rien d'autre que repasser par les fréquences, bah qu'il en soit ainsi, mais ça me surprendrait quand même... je dois juste être fatigué... et un peu honteux de solliciter votre aide sur ce sujet...

merci
-----

[jiherve]

Bonsoir,
amha hormis le cas où la variation de fréquence est faible devant la fréquence d'origine et que l'on peut utiliser un truc type développement limité la réponse est : il faut faire le calcul.
Ceci dit une division ce n'est pas la mer à boire, voir Newton Raphson par exemple.
JR

[minioim]

j'aurais limite préféré que tu m'annonces que j'étais devenu mononeurone avec la fatigue... bon tant pis, j'optimiserais le calcul ailleurs ^^

[Zenertransil]

Donc tu veux les périodes T(n) associées aux fréquences f(n) avec une forme f(n)=f0+n.k, où k est une fréquence constante?

[A voir en vidéo sur Futura]

[Zenertransil]

En fait je pense être à côté de la plaque parce que ça me paraît très simple... Ca ne convient sûrement pas! Mais faire intervenir une variable entière supplémentaire permettrait peut-être de simplifier les choses

Si la fréquence de base vaut 1kHz et l'itération 500Hz, T(n) = 1/(1000+500n). Tu as une division au lieu de deux!


On trouve d'autres relations similaires en passant par les suites, mais on peut pas dire que ça simplifie le calcul...

[abracadabra75]

bonsoir.

Tu ne nous dis rien du µc que tu utilises, mais ce n'est pas important, ni du langage utilisé pour programmer.

Par contre, tu dis qu ' "il" est gourmand.... En place occupée, ou en temps d'exécution?

Ton application sera-t-elle vraiment pénalisée en utilisant une division? Combien de nanosecondes?

j'utilise certains µp qui ne sont pas nativement dotés d'instruction de base (assembleur) pour la division. Quand j'utilise un langage de haut niveau, C,Pascal,Basic,etc... je ne me préoccupe pas de savoir comment la division est réalisée. Si je suis en assembleur, je fais alors une boucle incrémentant un compteur avec le diviseur jusqu'à ce que j'arrive ou dépasse le dividende. Et ca prend... un certain temps!

Quant à vouloir passer d' un rapport F/F' à une addition F+k.... bon sang! mais, c'est...bien sûr (comme disait un acteur célèbre, mais que tu n'as pas du connaître), un outil existe.... peut-être: les logarithmes. Mais alors là, je crois que la solution sera plus lourde que le calcul direct de ta pôv' division!

A+

[minioim]

En fait je pense être à côté de la plaque parce que ça me paraît très simple... Ca ne convient sûrement pas! Mais faire intervenir une variable entière supplémentaire permettrait peut-être de simplifier les choses

Si la fréquence de base vaut 1kHz et l'itération 500Hz, T(n) = 1/(1000+500n). Tu as une division au lieu de deux!


On trouve d'autres relations similaires en passant par les suites, mais on peut pas dire que ça simplifie le calcul...

effectivement, c'est une solution "simple". mais comme je te l'ais dis, si j'avais le temps j'irais dormir 35h, puis je m'y remettrais... malheureusement je suis un peu pressé par le temps, du coup je me retrouve à buter sur des problèmes pourtant assez basiques...

merci pour ta solution, par contre effectivement, il est même légèrement plus consommateur que la double division (surement la faute de la multiplication sous la division?)

bonsoir.

Tu ne nous dis rien du µc que tu utilises, mais ce n'est pas important, ni du langage utilisé pour programmer.

Par contre, tu dis qu ' "il" est gourmand.... En place occupée, ou en temps d'exécution?

Ton application sera-t-elle vraiment pénalisée en utilisant une division? Combien de nanosecondes?

j'utilise certains µp qui ne sont pas nativement dotés d'instruction de base (assembleur) pour la division. Quand j'utilise un langage de haut niveau, C,Pascal,Basic,etc... je ne me préoccupe pas de savoir comment la division est réalisée. Si je suis en assembleur, je fais alors une boucle incrémentant un compteur avec le diviseur jusqu'à ce que j'arrive ou dépasse le dividende. Et ca prend... un certain temps!

Quant à vouloir passer d' un rapport F/F' à une addition F+k.... bon sang! mais, c'est...bien sûr (comme disait un acteur célèbre, mais que tu n'as pas du connaître), un outil existe.... peut-être: les logarithmes. Mais alors là, je crois que la solution sera plus lourde que le calcul direct de ta pôv' division!

A+

c'est en place occupée qu'il est gourmand... (j'utilise du C sur un 16f877 pour info)

pour le moment mon application ne sera pas plus pénalisée que ça, dans la mesure où j'utilise actuellement 20.9% de la mémoire programme et 30.4% de la RAM. c'est largement acceptable, seulement je suis loin d'avoir fini mon projet et je préfère prévoir et optimiser au fur et à mesure que me retrouver à essayer d'optimiser un programme complexe à la fin.

niveau temps d'exécution, ce n'est pas un soucis, lorsque j'ai besoin de ces calculs, le µc ne fait que ça... enfin il crée derrière un signal qui utilise les résultats des calculs comme paramètres, mais dans la mesure où c'est prévu pour du réglage, on a tout le temps... (en gros l'utilisateur appuie sur 2 boutons pour augmenter ou réduire une fréquence par pas de 17Hz, fréquence qui est envoyée à un compte tour (prévu pour recevoir un signal de ce type en entrée, et le convertir en tr/min) qui affiche du coup le régime correspondant à la fréquence. une fois que le régime affiché lui convient, il valide.

donc si il se passe 20µs ou même 20ms entre l'appuie sur le bouton et l'affichage du nouveau régime moteur artificiel, vous vous doutez bien que ça n'a rien de catastrophique...

ce que je veux surtout c'est réduire la place utilisée par le calcul dans le programme. et ces 2 malheureuses divisions me prennent 4% de RAM et 3% de mémoire programme... mais bon...

ps: et non je n'ai pas spécialement connu Raymond Souplex, mais l'ai déjà vu une fois avec son expression

[abracadabra75]

Tu utilises des poussoirs, donc tu as une routine antirebond de 100 à 200ms. Donc le temps... conclues toi-même.

Ta division en C... 3% et 4 % d'occupation!!! amazing!
Si la place te préoccupe autant alors adopte la méthode que je t'ai indiquée: un boucle d'incréméntation (ou de décrémentation suivant ce que tu préfères) qui en prime te donnera le reste.

Et si tu veux encore réduire occupation et temps d'exécution, emploie la méthode d'arrière-grand-papa à l'aide de laquelle les vieux ont envoyé et fait revenir (comme le disait un membre de ce forum) des hommes dans l'espace: l'assembleur!!!! Le C permet d'inclure de telles routines qui sont imbattables sur tous les plans, écrite par toi pour ton cas précis, sans avoir à se préoccuper, comme en C, de toutes les aberration qui passent par la ciboule de programmeurs dits géniaux!

[ftorama]

Comme d'habitude, le design a été fait à l'envers.

Le choix du micro doit dépendre des tâches qu'on va lui demander et ici un micro avec au moins l'instruction assembleur de multiplication t'aurait largement aidé, voire même permis de mener à bien ton projet. Un PIC16 (tout comme un Attiny pour couper court à toute polémique) n'est pas fait pour faire des calculs qui plus est sur des réels.

[minioim]

Comme d'habitude, le design a été fait à l'envers.

Le choix du micro doit dépendre des tâches qu'on va lui demander et ici un micro avec au moins l'instruction assembleur de multiplication t'aurait largement aidé, voire même permis de mener à bien ton projet. Un PIC16 (tout comme un Attiny pour couper court à toute polémique) n'est pas fait pour faire des calculs qui plus est sur des réels.

Comme souvent, certains membres pensant avoir la science infuse j'imagine, débarquent sur un sujet pour asséner une grande vérité.

Sauf que la science infuse n'existant pas, ça marche pas toujours...

Donc le choix du 16F877 étant imposé dans le cadre de mon projet, je suis navré de devoir t'annoncer que d'une part je vais devoir faire avec, d'autre part je vais le mener à bien.

ça va seulement demander un peu plus de recherche. mais il me semble que c'est une composante du métier d'ingénieur de faire avec les moyens du bord et de trouver des solutions même si on a pas la liberté d'action qu'on voudrait. Se contenter d'assembler des solutions existantes, c'est un peu limité.

pour info, mon projet est pratiquement terminé, donne des résultats parfaitement satisfaisant et fonctionne avec des réels, sur un 16F877. même si ça n'est pas toujours évident car il faut parfois ruser un peu pour contourner les limites de ce pic, ça marche.

Tu utilises des poussoirs, donc tu as une routine antirebond de 100 à 200ms. Donc le temps... conclues toi-même.

Ta division en C... 3% et 4 % d'occupation!!! amazing!
Si la place te préoccupe autant alors adopte la méthode que je t'ai indiquée: un boucle d'incréméntation (ou de décrémentation suivant ce que tu préfères) qui en prime te donnera le reste.

Et si tu veux encore réduire occupation et temps d'exécution, emploie la méthode d'arrière-grand-papa à l'aide de laquelle les vieux ont envoyé et fait revenir (comme le disait un membre de ce forum) des hommes dans l'espace: l'assembleur!!!! Le C permet d'inclure de telles routines qui sont imbattables sur tous les plans, écrite par toi pour ton cas précis, sans avoir à se préoccuper, comme en C, de toutes les aberration qui passent par la ciboule de programmeurs dits géniaux!

héhé je sais bien que 3 et 4%, dis comme ça c'est un peu rien... mais pour l'importance que ça a dans le programme, ça me semblait un peu lourd...
pour le temps, comme je t'ai dis, au final c'est pas ma préoccupation majeure... vu que le micro pourrait mettre 1 seconde à traiter le calcul, ça serait pas gênant non plus.

pour l'idée de l'assembleur, pour tout te dire c'est comme ça que je voulais commencer. avec de l'assembleur pur. malheureusement, le temps m'étant compté je passe par le C, tout de même un peu plus pratique et avec lequel je suis un peu (juste un peu) plus familier.

l'idée d'intégrer une routine en assembleur est très intéressante effectivement, je le savais possible, mais n'y avais juste pas pensé -_-. par contre je ne m'en suis encore jamais servi, donc va falloir trouver comment ça fonctionne tout ça

pour résumé, tant que j'atteints pas les limites en terme de mémoire de mon prog, je vais en rester au C pur avec tous les défauts qu'il peut avoir. si vraiment je me retrouve dans l'obligation d'optimiser, je passerais à cette méthode.

merci beaucoup en tout cas pour ton temps et ton aide

[erff]

Bonjour,

Je rejoins l'idée de abracadabra75 pour effectuer la division à moindre place qui consiste à utiliser un algo itératif. Cependant, un algorithme qui converge bcp plus vite qu'une boucle de décrémentation basique est l'algorithme de division euclidienne : cela requiert uniquement des soustractions et des décalages logiques. La place occupée par le code sera à peine supérieure (juste des décalage logiques à rajouter dans le code), mais le temps d'exécution bien moindre. Par exemple pour diviser 1024 par 2 on aura 512 itérations avec la première solution contre 10 itérations avec la division euclidienne.
http://www.acrypta.com/telechargemen...crypto_001.pdf
Bien évidement la multiplication par 2 donnée dans l'exemple est à remplacer par un décalage logique vers la gauche.

EDIT : je suis sur que tu trouveras des routines toutes faites et optimisées sur le net

[minioim]

Effectivement la division euclidienne est une bonne idée

Merci, je vais m'intéresser a tout ça soit si j'ai pas le choix soit quand j'aurais fini le projet et qu'il me restera du temps (soyons fous ^^) ou même après la date limite, par culture perso ^^

[abracadabra75]

Bonjour,

Je rejoins l'idée de abracadabra75 pour effectuer la division à moindre place qui consiste à utiliser un algo itératif. Cependant, un algorithme qui converge bcp plus vite qu'une boucle de décrémentation basique est l'algorithme de division euclidienne : cela requiert uniquement des soustractions et des décalages logiques. La place occupée par le code sera à peine supérieure (juste des décalage logiques à rajouter dans le code), mais le temps d'exécution bien moindre. Par exemple pour diviser 1024 par 2 on aura 512 itérations avec la première solution contre 10 itérations avec la division euclidienne.
http://www.acrypta.com/telechargemen...crypto_001.pdf
Bien évidement la multiplication par 2 donnée dans l'exemple est à remplacer par un décalage logique vers la gauche.

EDIT : je suis sur que tu trouveras des routines toutes faites et optimisées sur le net

Génial....
(et en même temps, ça me montre que je commence à perdre le mémoire).
Je vais modifier mes routines.

[minioim]

héhé bah ça aura servi à plus d'une personne ce sujet au moins

c'est vrai que ça fait longtemps les divisions euclidiennes...