Dspic + UART + dma et décalage

[invite9426e977]

Salut, sur un projet je suis a la limite de la puissance des dspic,
J'ai besoin de recevoir des transmissions uart a haute vitesse, chaque paquets est compose de 3 octets : un header, et deux octets pour les donnes. Le dma est donc configure pour des buffer de 3 mots. Dans mon but le premier correspond au header, le reste aux donnees mais en cas de decalage, ça va merder,
Je sais detecter les decalages mais je ne sais pas comment les resoudre.

Est-il possible de faire croire qu'on a recu un octet sur l'uart ou de decaler le dma pour se recaler en cas de pb ?

Merci d'avance.
-----

[RISC]

Salut,

Quel dsPIC utilises-tu ?
Pouquoi n'utilises pas l'unité de CRC ?
Qu'est-ce qui te fait dire que tu es à la limite de la performance de ton dsPIC ?
Utilises-tu un quartz ?

a+

[vincent66]

Bonsoir,
As-tu déjà remarqué concrètement un décalage ou supputes tu qu'il puisse y en avoir un ..? Pour moi la question ne se pose pas, le dma bosse à son rythme à chaque réception de byte par l'uart, ça a d'ailleurs été créé pour ça...
Vincent

[invite9426e977]

salut,
je ne dit pas que l'UART ou le DMA peuvent causer un décalage, mais que la ligne peut etre débranché, branché pendant le fonctionnement du produit, avoir un mauvais contact ou quoi que ce soit.
donc il faut pouvoir gérer les imprévus.

le DSPIC que j'utilise est un dspic33ep256mu806,
actuellement il traite, 2 entrées audio avec traitement (détection de voix sur l'une des ligne, détection de signal sur la seconde), il gère 2 sorties (2* 48Khz 16bits), un autre module I2S (1*48Khz 16 bits), et le bus de donnée (48Khz 14 bits) et doit pouvoir lire des mots enregistrés dans la mémoire flash du dspic codé en 8Khz, 16 bits.


au début je gérais le bus de donnée en utilisant les interruptions, avec un code optimisé le plus possible, mais le bus allais trop vite, et j'ai été obligé de placer l'interruption du bus avec la plus haute priorité, résultat, celle qui génère les signaux du codec avait de gros ralentissements et faisait planter le codec...

je suis donc passé au DMA, la solution a l'air de bien fonctionner, mais faut pouvoir gérer les problèmes qui peuvent survenirs.

je n'utilise pas de quartz.

je vais voir du coté du module CRC, voir ce que je peux faire avec.
d'autre solutions ?
merci pour vos réponses.

[A voir en vidéo sur Futura]

[invite9426e977]

je ne pense pas que le module CRC puisse m'aider dans mon cas.

[RISC]

Salut,

Es-tu capable dans ton système de maitriser (fixer) le format des trames UARTs ?
Si c'est le cas le CRC peux t'aider.
Exemple : tu choisis des trames de 10 octets et tu utilises le CRC. L'emetteur envoie 10 octets + CRC émetteur. Le récepteur reçoit les 10 octets + CRC émetteur et recalcule le CRC (CRC récepteur).
Si le CRC récepteur = CRC émetteur pas de PB, sinon le récepteur demande le renvoi de la trame.

Avec ce système tu peux débrancher rebrancher à volonté ;=)

a+

PS : ne pas utiliser de quartz pour une liaison UART c'est prendre des risques importants, surtout si le host est un PC...

[invite9426e977]

salut,
merci pour les infos.
actuellement, le premier octet de chaque mots définit si c'est les données ou le header, donc si le premier mot stocké dans le buffer n'est pas le header, il y a eu décalage.
si je re-demmande a l’émetteur de recommencer l'envoi, il va renvoyer les 3 octets et donc on sera au meme point, un décalage dans la transmission.

mon but est vraiment de faire un décalage, pour justement récupérer un décalage, quitte a perdre 2 - 3 frames c'est pas grave.

l'ensemble le du bus est géré par des microcontroleurs programmé par moi même.
merci pour l'info du quartz, je vais modifier le design pour prendre en compte ce point.

ps: ce matin, un test a été effectué sur le matériel et on a déjà eu un décalage au démarrage, un module n'a pas la même fonction et démarre avant les autres.

[invite9426e977]

en regardant le datasheet du DMA, j'ai vu qu'il y avait la possibilité de forcer un transfer DMA (DMA1REQ.FORCE)
est-ce qu'il peut être utilisé pour décaler le buffer de recetion ?

[RISC]

Salut

actuellement, le premier octet de chaque mots définit si c'est les données ou le header, donc si le premier mot stocké dans le buffer n'est pas le header, il y a eu décalage.
si je re-demmande a l’émetteur de recommencer l'envoi, il va renvoyer les 3 octets et donc on sera au meme point, un décalage dans la transmission.

mon but est vraiment de faire un décalage, pour justement récupérer un décalage, quitte a perdre 2 - 3 frames c'est pas grave.

L'utilisation du CRC va régler automatiquement tous tes problèmes car il est systématiquement ajouté à ton message.
Prenons un exemple. Hypothèse : ton message doit toujours faire la même taille (dans l'exemple ci-dessous fait 10 octets).
Le CRC fait toujours 2 octets donc le message total = 10 + 2 octets = 12 octets. Tous les 12 octets le DMA s'arrête et le CRC local est calculé. si le CRC n'est pas correct c'est que les 10 octets sont faux (peu importe si c'est décalé manqué etc...)
NB : dans ton cas il faut à mon avis impérativement faire en plus un traitement d'erreur sur les flags de l'UART

Je te recommande d'ajouter rapidement un quartz pour ne pas gérer des problèmes additionnels qui sont potentiellement purement dus à une erreur sur le baud rate

a+

PS : sais tu que ton dsPIC peu tourner à 70 MIPS ?

[invite9426e977]

Merci pour l'explication.
Dans le cas d'une erreur crc, le paquet sera jette a ce que j'ai compris.
Mais le prochain le sera aussi car le probleme ne sera pas resolu.
Comment le resoudre quand on sais qu'il y a un decalage dans le buffer de reception ?


Normalement le micro tourne a 70 mips avec les param actuels.

[RISC]

Salut,

Je pars du principe que tu contrôles les trames émises, sous entendu l'émetteur envoies TOUJOURS des trames correctes.
Donc si une trame incorrecte arrive, l'émetteur renvoie TOUJOURS une trame correcte. si la liaison n'est pas débranchée, je ne vois pas pouquoi l'erreur continuerai ?

Explique dans le détail car je ne vois pas ou se situe le PB qui fait que l'erreur va perdurer.

a+

[invite9426e977]

euh tout d'abord je viens de voir que le titre est pas bon, c'est pas SPI mais UART.


voici le cas de ce matin :
j'ai 3 modules sur le bus de donnée : 1 2 et 3, le 2 fait la passerelle entre les autres modules (1 et 3) et peut ajouter des données.

au démarrage, l'initialisation du module 2 est plus rapide que le 1 et le 3.

il commence la transmission de donnée avant que le 1 et le 3 ait configuré et lancé le DMA, manque de bol, il se met a fonctionner au milieu d'une trame, donc il va remplir le buffer comme ça :
1.2 - 1.3 - 2.1 -> on a donc la fin de la trame 1 et le debut de la 2. le code detecte qu'il y a un décalage, il jette le contenu du buffer.
interruption DMA suivante :
2.2 - 2.3 - 3.1 -> on a le même problème.

mon but est alors de faire décaler le remplissage du buffer de 1 vers la droite pour revenir a la bonne situation.

1.2 - 1.3 - 2.1 -> on a donc la fin de la trame 1 et le debut de la 2. le code detecte qu'il y a un décalage, il jette le contenu du buffer et fait le décalage

interruption DMA suivante :
X - 2.2 - 2.3 -> on saute une reception.

interruption DMA suivante :
3.1 - 3.2 - 3.3 -> on saute une reception.

si tu as une autre solution je suis preneur.

[RISC]

Salut,

Je comprends mieux ton système qui possède plusieurs noeuds...
Il faut absolument prévoir un petit protocole entre tes noeuds et notamment une notion d'acknowkedge par les esclaves sans quoi cela est ingérable...
C'est ce que fait par exemple au niveau hardware l'I2C.

En utilisant un CRC e un paquet d'acknowledge à chaque trame ton problème se résoud rapidement.
Le maitre envoie une trame. L'esclave la reçoit décalée, il renvoie un NACK (not acknowledge) au maitre.
Le maitre voit que l'esclave n'a pas reçu correctement, il renvoie la trame et ceci jusqu'à ce que l'esclave renvoie un ACK (j'ai bien reçu). Dans ce cas le maitre continue avec la trame suivante.

Quand l'esclave 1 a reçu une trame correcte, il fait idem avec l'esclave 2

a+

[invite9426e977]

ah oui, pas con,<br>
merci pour ton aide, je vais tenter ça.

[invite46ab89bc]

Bonsoir,
Si votre système peut supporter une latence d'au moins une trame, une solution pour éviter d'avoir à gérer des handshake serait peut-être d'avoir une fifo intermédiaire et de travailler sur celle-ci plutôt que sur les trames DMA brutes.
Admettons que la fifo comprenne 2 trames et que le décalage soit d'un octet, il suffit de déplacer le pointeur de lecture d'un octet, et d'attendre la trame suivante pour lire les 3 octets corrects.
Pour éviter d'avoir à recopier les trames dma dans la fifo, on peut programmer le dma en ping pong et travailler sur les deux buffers, vus comme une fifo
-Trame 1-
octet 1
octet 2 <--- pointeur de lecture de la fifo
octet 3
-Trame 2-
octet 4
octet 5
octet 6

Le hic, c'est que si le décalage est de deux octets il faut attendre l'interruption DMA de la deuxième trame pour lire le paquet correct, ce qui ne laisse que le temps de réception d'un octet avant que le dma ne commence à re effacer la première trame, c'est pour cela qu'il serait préférable d'augmenter la taille des trames DMA (si c'est possible), ce qui par ailleurs diminuerait l'incidence du temps associé à l'entrée et à la sortie de l'interruption.

Une autre solution si le flux de donnée est régulier, serait de faire une pll avec un timer de manière à relancer le dma pile poil pour compenser le ou les octets décalés. J'ai déjà fait ce genre de manip sur des systèmes d'acquisition (pour commuter des antennes sur un système radio si une trame reçue est incorrecte, de manière à ce que la commutation des antennes se fasse juste avant la réception du nouveau paquet), ça fonctionne, mais c'est assez galère à mettre en place.

Cordialement
Jean-Louis

[invite9426e977]

merci pour cette solution.
effectivement ça a l'air assez compliqué.
je vais continuer sur cette voie, préciser a l'autre qu'il y a un décalage pour que ce soit l’émetteur qui corrige les erreurs et non le récepteur.

merci pour l'aide.
marc.