Pourquoi certains de mes signaux tremblent-ils (tremblent-ils)?

J'ai un bus SPI à 2 MHz mais une chose que j'ai remarquée, c'est que certains de mes signaux «tremblent» souvent. Oui, mon déclencheur est correctement configuré, donc je ne pense pas que le problème soit là.

Vous pouvez voir ce que je veux dire ici: (c'est avec le mode persistance activé). Ceci est l'horloge de mon bus SPI.

Le SPI fonctionne bien. J'ai transféré des centaines de mégaoctets sur plusieurs cartes et je n'ai pas vu de problème jusqu'à présent. Mais je suis toujours intéressé à savoir quel pourrait être le problème ici. De plus, dois-je prendre la peine de le réparer même si cela fonctionne?

Les mesures ont été prises directement à la source avec une TRÈS petite pince de masse.

Ceci est un schéma simplifié de mon circuit. Bien sûr, la carte a plus de périphériques SPI, mais pour les besoins de cette question, c'est exact car la carte n'a encore rien soudé, à l'exception de l'UC et de la carte SD.

Le maître (AVR Mega 128) fonctionne sur son oscillateur RC interne - je ne sais pas si cela serait pertinent, mais comme les signaux changent dans le temps, il est possible que la gigue de l'oscillateur RC se retrouve également dans le bus SPI. Je pensais juste le mentionner. Il m'est également apparu que pendant ces mesures, j'ai fait fonctionner le contrôleur dans une boucle infinie. Voici le code:

while(1)
{
    setFirstBitOnDriver(driver); // this sends a 8-bit command on the SPI bus.
    GLCD_SetCursorAddress(40); // Change cursor position on the display.
    GLCD_WriteText("LED: "); 
    for(wire=0;wire<72;wire++)
    {
        itoa(wire+1,str,10);
        GLCD_WriteText(str);
        GLCD_SetCursorAddress(44);
        _delay_ms(10);
        shiftVectorOnDriver(driver); // another command on SPI. 8-bit wide.
    }
}

La gigue / frisson pourrait se produire lorsque l'interne fonctionne 72 fois puis se termine. Puisqu'il faut un temps supplémentaire pour exécuter les trois premières lignes, il se peut que chaque 73e forme d'onde arrive à un moment légèrement différent en raison du temps de traitement supplémentaire. Si je devais parier, je suppose que c'est la cause de mon problème (si je le pouvais, je le confirmerais cet instant mais mes planches au travail et la semaine prochaine est éteinte!) Mais j'aimerais quand même des opinions / réponses de SE à ce sujet.

Mais compte tenu du fait que l'UC fonctionne à 8 MHz, je ne tremble pas en raison du logiciel, car en nanosecondes, mais plutôt en microsecondes. Mais dans la 2ème figure, une ligne plate est visible. Cela se produit pendant une très brève seconde où la totalité des formes d'onde se décale dans le temps et est invisible à l'écran. Je suppose que cela est dû à la boucle et la gigue dans la première image est due à l'oscillateur RC.

Ce que montre votre oscilloscope est un exemple classique de gigue , ce qui signifie une erreur dans le timing d'un événement (front montant ou descendant), qu'il y ait ou non un bruit de tension sur le signal.

Mais qu'est-ce qui peut provoquer la gigue dans votre système?

• Comme vous le spéculez, si l'horloge principale uC est instable, cette instabilité sera très probablement transférée directement à la sortie d'horloge du périphérique SPI.

  Un contournement inadéquat (vous devriez avoir un contournement en vrac supplémentaire sur votre carte en plus des deux condensateurs de 100 nF que vous avez dessinés) pourrait entraîner une gigue dans le circuit d'horloge uC.

  Le bruit d'alimentation introduit par d'autres circuits sur votre carte pourrait également avoir cet effet (mais serait réduit par plus de contournement).

• La gigue pourrait être inhérente aux performances du périphérique SPI de l'UC. Il doit générer l'horloge SPI en référence à l'horloge système. S'il utilise un simple diviseur (4 contre 1 dans le cas d'une horloge système à 8 MHz et d'une horloge SPI à 2 MHz), vous ne vous attendez pas à voir beaucoup de gigue supplémentaire (bien que la gigue de l'horloge système passe directement). Mais s'il utilise un schéma plus complexe, comme une PLL, ce circuit pourrait faire varier les largeurs d'impulsion d'horloge SPI pour rester synchronisé avec l'horloge système, et vous verriez cela comme une gigue. Un circuit PLL pourrait également être particulièrement sensible au bruit de l'alimentation.

Si l'amplitude de la gigue est limitée à une petite fraction de la période d'horloge, comme elle semble être ici, il n'y a aucune raison que cette gigue provoque des erreurs sur le bus SPI (en accord avec votre observation que le bus SPI semble fonctionner comme prévu) .

Cela ressemble à une gigue de signal pour moi. La période d'horloge varie minutieusement, suffisamment pour que la persistance de la lunette donne l'impression que le bord est taché.

Je ne sais pas si votre oscilloscope Rigol a la capacité de calculer des statistiques lorsqu'il mesure. Si c'est le cas, vous pouvez ajuster votre point de déclenchement de sorte que votre bord de déclenchement apparaisse sur le bord gauche de l'écran, ajuster la base de temps pour afficher une période complète et mesurer la variation de fréquence dans le temps pour avoir une idée de la variation. (La gigue peut sembler pire qu'elle ne l'est lorsque le bord de déclenchement est hors écran.)

Si vous souhaitez réduire les sources de gigue, je commencerais par l'oscillateur RC. Voyez si vous avez la possibilité d'utiliser une méthode d'horloge différente (comme un cristal), implémentez-la et remesurez la gigue.

Les images de portée peuvent être trompeuses et vous devez examiner tous les paramètres pour interpréter correctement les données. La première image montre une gigue de 10 ns, et ce ne serait pas si agréable si le déclencheur était juste à gauche de l'écran. Mais en bas à droite, il indique déclencheur + 1,78 µs, de sorte que 10 ns ne représente en fait que 0,5% de l'intervalle de temps. Ce niveau de gigue pourrait bien être dû à l'oscillateur RC. Attendez-vous à ce que la gigue soit réduite d'au moins un ordre de grandeur avec un oscillateur à cristal.

Vous dites que vous n'avez encore rencontré aucun problème dans le transfert de données SPI. C'est grâce à la relativité de 0,5%. Si vous voulez MOSI 1 µs avant l'impulsion CLK, la gigue de 0,5% provoquera une gigue de 5 ns, cela ne va pas violer les temps de configuration et de maintien.

Si vous avez besoin d'être rassuré, définissez simplement la base de temps de sorte que vous puissiez voir un temps de bit complet, à la fois le canal MOSI et CLK. Vous remarquerez que la gigue sera à peine visible, et que les bords successifs restent bien séparés.

La gigue est une forme de bruit. Si vous considérez les temps d'arrivée entre les fronts d'impulsions comme une sorte de signal, alors si ces fronts ne tremblent pas du tout, cela signifie que votre système présente un signal sans bruit!

Les ondes carrées sont souvent générées par seuillage sur une onde plus continue, avec certains circuits de type déclencheur Schmidt qui ont un comportement d'hystérésis. Les oscillateurs à cristal ou RC n'émettent pas «nativement» des ondes carrées.

Donc, si cette onde d'entrée a un certain bruit de tension, ce bruit se traduira par de légers changements dans le déclenchement, car la tension atteint parfois l'un ou l'autre seuil plus tôt et parfois plus tard.

Et ainsi, le bruit d'un type (bruit de tension) se transforme en bruit d'un autre type (bruit de synchronisation).