framboise314.fr

Pinhapple a écrit :Double conversion, je comprends le problème, mais pas pour la trame UDP. Au final, il faudra bien que j'en envoie des trames UDP, non ?

Oui, MAIS PAS DANS L'INTERRUPTION !
Plus le buffering.

Pinhapple a écrit :et je me rends compte que la bibliothèque que j'utilise comme "amélioration" de la fonction micros()

Il faut faire gaffe aussi à ne pas faire de sur qualité non plus : une interruption et son traitement prend eux-même du temps. Il faut faire gaffe que les améliorations ne dépassent pas les possibilités du montage (remarque comme ca, je n'ai pas regarder les timing de ton Arduino).

Pinhapple a écrit :sa fonction get_count() s'utilise soit avec un float (4 octets), soit avec un unsigned long (4 octets également), donc deux octets de plus que les 2 prévus avec un short. Reste la possibilité de convertir, mais dans ce cas il y aura autant de conversions que de valeurs ; dans les deux cas, ce n'est pas folichon pour la rapidité...

Il faut voir si le gain en vaut la chandelle (taille).
Pour les conversions : les flottant sont des tueurs de perfs, mais diminuer la précision d'un long vers un short est trivial et est négligeable niveau perf (non, pas en faisant une division).

destroyedlolo a écrit :Oui, MAIS PAS DANS L'INTERRUPTION !
Plus le buffering.

Rassure-toi, je suis passé à un autre système : l'envoi est dans le loop(), exécuté sous condition qu'un booléen soit à true, et c'est dans l'interruption que je change la valeur de ce booléen.

destroyedlolo a écrit :diminuer la précision d'un long vers un short est trivial et est négligeable niveau perf (non, pas en faisant une division).

J'ai fait un programme à part : je mesure 1 µs pour convertir un unsigned long en unsigned short avec un cast (unsShortValue = (unsigned short)unsLongValue;), mais je suis sûrement à moins étant donné que je mesure 1 µs également pour le cast de 100 valeurs.

J'ai quasiment terminé le soft final, reste "plus qu'à" m'occuper de l'envoi des buffers.

Pinhapple a écrit :J'ai fait un programme à part : je mesure 1 µs pour convertir un unsigned long en unsigned short avec un cast (unsShortValue = (unsigned short)unsLongValue;),

Ouai, mais c'est une mauvaise idée : c'est ce qu'il y a de plus rapide MAIS nécessiterait de faire un test préalable pour s'assurer que le compilo conserve bien les octets de poids le plus fort (ce qui est LLLLLOOOOIIIINNNN d'être gagné sur un compilo moderne).

La solution passe par le ... décalage.

Pinhapple a écrit :mais je suis sûrement à moins étant donné que je mesure 1 µs également pour le cast de 100 valeurs.

Ce que tu mesures, c'est ... la résolution de ton outils de mesure. Car caster 1 valeurs, 100 valeurs ou 1000000 valeurs devraient donner le même résultat vu qu'il ne s'agit que d'un mécanisme du compilo qui ne crée aucun code, ou au pire l'application d'un masque, donc pas grand chose.

destroyedlolo a écrit :pour s'assurer que le compilo conserve bien les octets de poids le plus fort (ce qui est LLLLLOOOOIIIINNNN d'être gagné sur un compilo moderne).

Mais si la valeur après conversion est la même qu'avant, c'est que l'octet/les bits de poids le plus fort est/sont conservé(s), non ?

destroyedlolo a écrit :Ce que tu mesures, c'est ... la résolution de ton outils de mesure. Car caster 1 valeurs, 100 valeurs ou 1000000 valeurs devraient donner le même résultat vu qu'il ne s'agit que d'un mécanisme du compilo qui ne crée aucun code, ou au pire l'application d'un masque, donc pas grand chose.

Merci pour l'explication technique, c'est bon à savoir !
Mais est-ce que du coup ces durées de conversion sont à prendre en compte dans un calcul de temps ? (Là c'est plus par curiosité que je pose la question...)

Pinhapple a écrit :Mais si la valeur après conversion est la même qu'avant, c'est que l'octet/les bits de poids le plus fort est/sont conservé(s), non ?

??? non ca ne veut rien dire du tout (c'était un test car pour info, hormis avec des compilo ante-diluvien et dans des cas particuliers, ce qui peut d'ailleurs etre considéré comme un bug, un cast ne gardera QUE la partie de poids faible ... je te laisse chercher pourquoi )

Il faut dans un premier temps voir ce qu'est censé retourner la fonction.
Ensuite, voir la précision qui est nécessaire à ton projet.
Ensuite, décaller pour que la précision de la valeur retournée par ta fonction correspond à la précision utile par ton projet
et finalement caster si la valeur maxi attendue ainsi converti rentre dans le type le plus court.
(si si, c'est compréhensible après 3 ou 4 relectures )

Il est possible qu'un simple cast soit suffisant, mais ca devrait être argumenté.

destroyedlolo a écrit :Mais est-ce que du coup ces durées de conversion sont à prendre en compte dans un calcul de temps ? (Là c'est plus par curiosité que je pose la question...)

Si tu voulais être puriste, il faudrait que tu prennes en compte le nombre de cycles de chacune des instructions exécutées entre le déclenchement physique de l'interruption et le stockage de la valeur (pour peu que ca reste compatible avec la précision de ta mesure : descendre au 100e de uS alors que ton compteur reste à la uS serait parfaitement abberant) : Donc, je pense que dans ton cas, la réponse est simplement non
J'ai compté les cycles dans ma jeunesse pour implémenter une RS-232 sur un proc n'ayant pas d'uart ni de timer. La seule solution était de mesurer les cycles de chaque instruction pour obtenir le timing attendu ... ça relèverait du pur masochisme sur les procs modernes qui ont en plus du cache voir des pipelines donc des cycles qui varient suivant le contexte et faudrait désactiver pleins de trucs parasites : vive les uart !

destroyedlolo a écrit :J'ai compté les cycles dans ma jeunesse pour implémenter une RS-232

(souvenirs, souvenirs... )

On m'a demandé de mettre l'Ethernet de côté pour le moment, afin d'essayer en SPI (lire les données du radar avec l'Arduino, puis transférer ces valeurs au RPi en SPI afin de les afficher en console en temps réel dans un premier temps). Stand-by donc pour l'Ethernet, je vous tiendrai au jus.

Vu les débits attendus, ce n'est pas forcement une mauvaise solution

destroyedlolo a écrit :Vu les débits attendus, ce n'est pas forcement une mauvaise solution

Ce qui m'inquiète plutôt, c'est la capacité du RPi et de Raspbian (OS non-temps réel) à choper toutes les informations envoyées. Ce qui m'est demandé, je l'ai déjà fait en I2C, et j'ai constaté que même si le Pi travaille à fond, il manquait certaines infos à l'arrivée ; donc même avec le meilleur débit du monde, si le processeur du Pi priorise d'autres tâches pendant même 1 ms, je loupe des données...

L'exemple tout bête d'il y a quelques semaines : le RPi seul branché sur le radar (avec les ponts diviseurs qui vont bien et le traitement du signal différentiel), avec pour objectif d'afficher en console le nombre de bips du tour écoulé. Je n'ai pas souvent eu 16 384, mais la plupart du temps des valeurs variant à la louche entre 16 200 et 16 350. Le même test avec l'Arduino me renvoyait lui un parfait 16 384 à chaque tour.

Je ne peux me prononcer pour l'I2C car je l'ai toujours utilisé pour communiquer depuis un PI (ou autre) vers des périphériques prévus pour l'I2C et jamais avec des timing serrés. Jamais eu le moindre problème cependant.
Mais ...

Pinhapple a écrit :L'exemple tout bête d'il y a quelques semaines : le RPi seul branché sur le radar (avec les ponts diviseurs qui vont bien et le traitement du signal différentiel), avec pour objectif d'afficher en console le nombre de bips du tour écoulé. Je n'ai pas souvent eu 16 384, mais la plupart du temps des valeurs variant à la louche entre 16 200 et 16 350. Le même test avec l'Arduino me renvoyait lui un parfait 16 384 à chaque tour.

Avec des interruptions ?
Il y a alors un pb avec ton code, car s'il n'est peut etre pas assez précis pour avoir les timing que tu souhaites (les interruptions ne sont pas top sur le uP de la framboise), j'ai du mal a envisager qu'il loupe un signal a 4khz (arg, ca me tarrode, faudrait que j'essaie sur ma banane).

Mais de toutes facons, tu ne peux pas comparer les 2 :

• dans le cas de l'arduino, c'est ce dernier qui mesure les durées et donc qui est le plus stressé par les interruptions
• dans le second, il reçoit les données pré-machées avec un debit plus lent (après, c'est sur que si tu envois des chaines plutot que les valeurs binaires, et qu'en plus tu fais des conversion, ca peut poser pb).