Attention ! Fermeture imminente du forum d’Elektor (pour en savoir plus, cliquer ici). À partir du vendredi 1er mars il ne sera plus possible de s’identifier sur ce forum, mais son contenu restera disponible en lecture seule jusqu’à la fin du mois. Le 1er avril, il sera fermé définitivement.

Configurer le module SSU

Postby cvillain » Wed May 30, 2007 12:00 am

Bonjour,

Je travaille sur R8C/25.
Je souhaite configurer le module SSU en "Clock Synchronous Communicatio Mode" en utilisant SSCK et SSI comme module esclave (sans SCS et SSO). Quand j'envoie la valeur 0x5A sur SSI, je peux lire la valeur recue via le registre SSRDR. Mais la valeur est differente de celle envoyee. J'ai remarqué que le registre SSMR changeait au niveau de "Bits counters" (BC0 à BC2) de la facon suivante :

- 1er envoi : 0x5A envoyé, 0xAD recu, SSMR = 0x7F (7 bits left)
- 2eme envoi : 0x5A envoyé, 0x96 recu, SSMR = 0x7E (6 bits left)
- 3eme envoi : 0x5A envoyé, 0xCB recu, SSMR = 0x7D (5 bits left)
- 4eme envoi : 0x5A envoyé, 0xA5 recu, SSMR = 0x7C (4 bits left)
- 5eme envoi : 0x5A envoyé, 0xD2 recu, SSMR = 0x7B (3 bits left)
- 6eme envoi : 0x5A envoyé, 0xE9 recu, SSMR = 0x7A (2 bits left)
- 7eme envoi : 0x5A envoyé, 0xB4 recu, SSMR = 0x79 (1 bit left)
- 8eme envoi : 0x5A envoyé, 0xAD recu, SSMR = 0x7F (7 bits left)
- etc.

J'ai vérifié que la valeur envoyee comportait le nombre correct de fronts. Je vois comme un décalage dans mes bits recus mais sans comprendre pourquoi. Pourquoi le registre SSRDR ne contient pas la valeur correspondant à 8 bits recus ?

Merci pour votre aide et vos commentaires.


PS : mail in english in Renesas forum (http://www.renesasrulz.com/index.php?name=PNphpBB2&file=viewtopic&t=126))
cvillain
 
Posts: 5
Joined: Fri Jan 17, 2014 4:38 pm

Postby sda » Wed May 30, 2007 12:00 am

Questions idiotes mais bon, il vaut mieux verifier et être sûr...
Pour être en "Clock synchronous communication mode" il faut initialiser :
IICSEL = 0
ICE = 0
SSUMS = 0
Tu veux recevoir donc MSS = 0 (slave device)
Attention au SRES (chip select) si il est a 1 tu peux risquer de perdre des bits.
Regarde le registre SSSR et donne nous sa valeur comme tu l'as fait lors de tes essais (les flags d'erreur peuvent être interressant ainsi que le RDRF).

Si tout ce qui est au dessus est ok, alors la cause est peut être dans le nombre de coup de clock que tu fourni à ton micro (tu dis l'avoir vérifier mais bon, on sait jamais si tu as une image d'oscillo à fournir on peut refaire la vérif).

++ SDA
sda
 
Posts: 24
Joined: Fri Jan 17, 2014 4:38 pm

Postby cvillain » Wed May 30, 2007 12:00 am

Merci SDA.

En effet, les bits que tu me cites sont bien aux bonnes valeurs.

Concernant le registre SSSR, il reste à 0x00 pendant la réception. Je joins deux images, correspondant respectivement à l'envoi des valeurs 0x5A et 0xFF. En voie 1, c'est SSCK. Sur l'autre, c'est SSI. La synchronisation des données se fait sur front descendant.
Attachments
fr_1516574950071.JPG
fr_1516574950071.JPG (25.47 KiB) Viewed 1673 times
fr_1516574960954.JPG
fr_1516574960954.JPG (26.59 KiB) Viewed 1673 times
cvillain
 
Posts: 5
Joined: Fri Jan 17, 2014 4:38 pm

Postby sda » Wed May 30, 2007 12:00 am

Le flag RDRF du registre SSRDR devrait être à 1 lorsque tu as reçu un octet complet... et tu dis que SSRDR est à 0 ! Ceci n'est pas logique.

Peux-tu joindre le bout de ton code qui traite de la communication pour une meilleur compréhension (init et reception)?

J'ai un doute aux vues des tes images oscillo,
d'après la doc. P313(doc renesas) ou P330(acrobat) fig.16.10 tu es dans le 4ème cas. Ton SSUMS est à 0 mais cela ne change rien pour les graph, ton CPHS est à 1 (d'après ton SSMR dont la valeur est 0x7F), ton CPOS est à 1 (vue les graph, c'est ok). Donc d'après la figure tes bits sont validé sur front montant (et pas descendant comme tu le penses).
Creuse de ce côté là...

++ SDA
sda
 
Posts: 24
Joined: Fri Jan 17, 2014 4:38 pm

Postby cvillain » Wed May 30, 2007 12:00 am

Pour SSSR, c'est une erreur. Je le visualisais après avoir lu la donnée... Juste avant de lire la donnée, il vaut 0x20 (et donc RDRF vaut 1).

En pièce jointe : un extrait de mon code.

Je gère la réception par interruption et je stocke la donnée reçue dans un buffer tournant.

J'ai essayé rapidement l'histoire du CPHS. C'est en effet plus stable quand je le mets à 0 (front descendant) mais la valeur n'est toujours pas bonne. Je vais regarder pour rendre cohérent mes signaux d'entrée, CPHS et CPOS.
Attachments
fr_1516574192158.zip
(1.21 KiB) Downloaded 47 times
cvillain
 
Posts: 5
Joined: Fri Jan 17, 2014 4:38 pm

Postby cvillain » Wed May 30, 2007 12:00 am

Pour SSSR, c'est une erreur. Je le visualisais après avoir lu la donnée... Juste avant de lire la donnée, il vaut 0x20 (et donc RDRF vaut 1).

En pièce jointe : un extrait de mon code.

Je gère la réception par interruption et je stocke la donnée reçue dans un buffer tournant.

J'ai essayé rapidement l'histoire du CPHS. C'est en effet plus stable quand je le mets à 0 (front descendant) mais la valeur n'est toujours pas bonne. Je vais regarder pour rendre cohérent mes signaux d'entrée, CPHS et CPOS.

PS : ca fonctionne pas tres bien les pieces jointes !!!
Je le transmets dans ce texte, tant pis !
----------------------------------------------------------------------
#include

#define SIZE_BUFFER_SPI 20

ubyte Buffer_SPI[SIZE_BUFFER_SPI]; // Buffer SPI des donnees entrantes
ubyte Ind_Reception_Buffer_SPI; // Indice du buffer pour le placement des donnees
ubyte Ind_Lecture_Buffer_SPI; // Indice du buffer pour la lecture des donnees


void InitSPI(void)
{
ubyte i;

DisableInterrupts(); // Interrupts disabled
re_sser = 0; // Reception desactivee
te_sser = 0; // Transmission desactivee
iicsel = 0; // Selection de la fonction SSU
ssums_ssmr2 = 0; // Mode "Clock Synchronous communication"
cphs_ssmr = 1; // Lecture de la donnee sur front descendant
cpos_ssmr = 1; // SSCK a l'etat bas au repos
mls_ssmr = 0; // Transmission du MSB en premier
scks_ssmr2 = 1; // Configuration de p3_5 pour SSCK
soos_ssmr2 = 0; //
sscrh = 0x07; // pas d'horloge de transfert, mode escalve, reception continue
if(orer_sssr) orer_sssr = 0;
rie_sser = 1; // Reception par interruption
ssuaic = 0x04; // Configuration du niveau d'interruption

// Waiting for writing to registers
asm("nop");
asm("nop");
asm("nop");
asm("nop");

i = ssrdr; // Lecture du buffer pour valider la configuration
re_sser = 1; // Reception activee
EnableInterrupts(); // Interrupts enabled

for(i=0;i {
Buffer_SPI[i] = 0x00;
}
Ind_Reception_Buffer_SPI = 0;
Ind_Lecture_Buffer_SPI = 0;
}

void SPI_Lire_Bus(void)
{
if(rdrf_sssr) // Si une donnee est presente dans le buffer
{
re_sser = 0; // Reception desactivee

if(orer_sssr) // Erreur de la communication
{
while(1); // Déclenchement du watchdog
}

Buffer_SPI[Ind_Reception_Buffer_SPI++] = ssrdr; // RDEF remis a 0 automatiquement
if(Ind_Reception_Buffer_SPI == SIZE_BUFFER_SPI) // Gestion en buffer tournant
{
Ind_Reception_Buffer_SPI = 0;
}
re_sser = 1; // Reception re-activee
}
}

ubyte SPI_Lire_Buffer(void)
{
ubyte Valeur;

Valeur = Buffer_SPI[Ind_Lecture_Buffer_SPI++];
if(Ind_Lecture_Buffer_SPI == SIZE_BUFFER_SPI) // Gestion en buffer tournant
{
Ind_Lecture_Buffer_SPI = 0;
}
return Valeur;
}

tBool Est_SPI_Donnee_Arrivee(void)
{
return (Ind_Reception_Buffer_SPI != Ind_Lecture_Buffer_SPI);
}

#pragma INTERRUPT SPI_Interrupt // Vecteur 15
void SPI_Interrupt(void)
{
rie_sser = 0; // Reception par interruption desactivee
SPI_Lire_Bus();
rie_sser = 1; // Reception par interruption re-activee
}


void main (void)
{
ubyte Str[9];

HardwareSetup(); // Configuration du microcontroleur
InitialiseDisplay(); // Reset the LCD module
InitSPI(); // Initialisation des modules SPI

while(1)
{
RefreshWatchdog();

if(Est_SPI_Donnee_Arrivee())
{
strcpy(Str, "IN = ");
Convert_8BitNumber_ToString(SPI_Lire_Buffer(), Str + strlen(Str));
DisplayString(LCD_LINE2, Str);
}
}

}
----------------------------------------------------------------------
cvillain
 
Posts: 5
Joined: Fri Jan 17, 2014 4:38 pm

Postby cvillain » Wed May 30, 2007 12:00 am

J'ai enfin réussi à le faire fonctionner !!

La réception du module SPI était activée avant que l'initialisation des trames envoyées soit terminée. De ce fait, il y avait un décalage dans la réception des bits.

Merci SDA pour ton aide.
cvillain
 
Posts: 5
Joined: Fri Jan 17, 2014 4:38 pm


Return to R8C/13 (01-2006)

Who is online

Users browsing this forum: No registered users and 1 guest