Discussion :

[julien terrier]

Bonjour a tous,
me revoilà lol, je souhaiterais avoir une confirmation et par la suite une réponse a ma question sur le fonctionnement précis de cette variable.

Pouvez me confirmer si je suis ds le vrai ou pas du tout ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

__IO ITStatus UartReady = RESET;

On crée une variable qui prendra la valeur RESET.

Décomposition de cette déclaration:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

#define     __IO    volatile             /*!< Defines 'read / write' permissions

C'est un type qualifieur (ici volatile) qui indique au compilateur qu'une variable peut voir sa valeur évoluer, soit par une interruption soit par un périphérique.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
typedef enum
{
  RESET = 0,
  SET = !RESET
} FlagStatus, ITStatus;

Donc ITStatus est un typdef sur une énumération

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
//UartReady
 
 /*##-5- Wait for the end of the transfer ###################################*/  
  while (UartReady != SET)
  {
  }
   
  /* Reset transmission flag */
  UartReady = RESET;

UartReady est une variable qui indique si l'UART est pret a travailler ou si il est tjrs entrain de travailler!

Tant que UartReady est égal a 0 (==) on reste ds la boucle.



Question concernant la boucle while avec la variable UartReady:

Je n'arrive pas retrouver ds les fichiers sources un quelconque endroit ou la variable UartReady est mise a 1! Peut que cette variable est mise a 1 de manière HARDWARE (peut etre que je dis n'importe quoi) et ca peut expliquer la manière dont elle a était déclaré ?

J'ai bien ce typdef "HAL_UART_StateTypeDef" sur le status des transmissions mais je ne trouve ou je n'arrive pas a faire le lien avec ma variable UartReady!

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
typedef enum
{
  HAL_UART_STATE_RESET             = 0x00,    /*!< Peripheral is not yet Initialized                  */
  HAL_UART_STATE_READY             = 0x01,    /*!< Peripheral Initialized and ready for use           */
  HAL_UART_STATE_BUSY              = 0x02,    /*!< an internal process is ongoing                     */   
  HAL_UART_STATE_BUSY_TX           = 0x12,    /*!< Data Transmission process is ongoing               */ 
  HAL_UART_STATE_BUSY_RX           = 0x22,    /*!< Data Reception process is ongoing                  */
  HAL_UART_STATE_BUSY_TX_RX        = 0x32,    /*!< Data Transmission and Reception process is ongoing */  
  HAL_UART_STATE_TIMEOUT           = 0x03,    /*!< Timeout state                                      */
  HAL_UART_STATE_ERROR             = 0x04     /*!< Error                                              */      
}HAL_UART_StateTypeDef;

Ou encore ce typedef qui correspond au retour de la fonction HAL_StatusTypeDef HAL_UART_Receive_IT(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size) c'est après l'appel de cette fonction qu'on entre ds la boucle while (UartReady != SET)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
typedef enum 
{
  HAL_OK       = 0x00,
  HAL_ERROR    = 0x01,
  HAL_BUSY     = 0x02,
  HAL_TIMEOUT  = 0x03
} HAL_StatusTypeDef;

Si quelqu’un a une idée je le ou la remercie d'avance!

[Vincent PETIT]

Salut Julien,

Pouvez me confirmer si je suis ds le vrai ou pas du tout ?

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

__IO ITStatus UartReady = RESET;

On crée une variable qui prendra la valeur RESET.

Oui, UartReady est une variable de type enum dont tu donnes la descritpion plus bas.

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

#define     __IO    volatile             /*!< Defines 'read / write' permissions

C'est un type qualifieur (ici volatile) qui indique au compilateur qu'une variable peut voir sa valeur évoluer, soit par une interruption soit par un périphérique.

Exacte, le mot clef volatile permet au compilateur de ne pas supprimer cette variable qui change, non pas de manière logiciel mais de manière matérielle.

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
typedef enum
{
  RESET = 0,
  SET = !RESET
} FlagStatus, ITStatus;

Donc ITStatus est un typdef sur une énumération

Oui.

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
//UartReady
 
 /*##-5- Wait for the end of the transfer ###################################*/  
  while (UartReady != SET)
  {
  }
 
  /* Reset transmission flag */
  UartReady = RESET;

UartReady est une variable qui indique si l'UART est pret a travailler ou si il est tjrs entrain de travailler!
Tant que UartReady est égal a 0 (==) on reste ds la boucle.

Voilà, c'est bien ça. Tu remarqueras que ça ressemble fortement à ce dont nous avions parlé dans ton précédent post avec le bit TC (j'avais donné un exemple d'une boucle sur ce bit qui passe a 1 une fois que la donnée est partie de l'UART)

Question concernant la boucle while avec la variable UartReady:

Je n'arrive pas retrouver ds les fichiers sources un quelconque endroit ou la variable UartReady est mise a 1! Peut que cette variable est mise a 1 de manière HARDWARE (peut etre que je dis n'importe quoi) et ca peut expliquer la manière dont elle a était déclaré ?

J'ai bien ce typdef "HAL_UART_StateTypeDef" sur le status des transmissions mais je ne trouve ou je n'arrive pas a faire le lien avec ma variable UartReady!

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
typedef enum
{
  HAL_UART_STATE_RESET             = 0x00,    /*!< Peripheral is not yet Initialized                  */
  HAL_UART_STATE_READY             = 0x01,    /*!< Peripheral Initialized and ready for use           */
  HAL_UART_STATE_BUSY              = 0x02,    /*!< an internal process is ongoing                     */   
  HAL_UART_STATE_BUSY_TX           = 0x12,    /*!< Data Transmission process is ongoing               */ 
  HAL_UART_STATE_BUSY_RX           = 0x22,    /*!< Data Reception process is ongoing                  */
  HAL_UART_STATE_BUSY_TX_RX        = 0x32,    /*!< Data Transmission and Reception process is ongoing */  
  HAL_UART_STATE_TIMEOUT           = 0x03,    /*!< Timeout state                                      */
  HAL_UART_STATE_ERROR             = 0x04     /*!< Error                                              */      
}HAL_UART_StateTypeDef;

Ou encore ce typedef qui correspond au retour de la fonction

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

HAL_StatusTypeDef HAL_UART_Receive_IT(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size)

c'est après l'appel de cette fonction qu'on entre ds la boucle while (UartReady != SET)

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
typedef enum 
{
  HAL_OK       = 0x00,
  HAL_ERROR    = 0x01,
  HAL_BUSY     = 0x02,
  HAL_TIMEOUT  = 0x03
} HAL_StatusTypeDef;

Si quelqu’un a une idée je le ou la remercie d'avance!

Ce que j'ai mis en rouge est probablement la bonne réponse à ta question .
Tu as un lien vers tout ce code ? Où alors le lien où je pourrai le télécharger ?
Il faut creuser un peu plus mais je suis sur que l'on va tomber dessus !!!!! A mon avis la solution est bien caché derrière un #define ou autres choses un peu comme dans ton premier post ! Un truc bien couillu.

Par contre, juste une remarque.... à mon avis on est partie pour détricoter tout le firmeware qui justement a été fait pour ne pas se prendre la tête avec ce qui se passe dans le micro Ca ne me gène pas du de faire cette démarche mais y a du boulot car il faut aller mettre le nez dans la couche d'abstraction pour voir ce comment le micro fonctionne et comment cette couche est faite ! Ca fait 2 choses à comprendre.

[julien terrier]

Bonjour l'ami,

en premier lieu je tiens vraiment a te remercier pour ton implication, tu prends sur ton temps pour répondre a mes messages et c'est vraiment appréciable!

Pour la variable UartReady j'ai posté sur le forum de ST et il m'ont répondu quelle était modifiée dans ces fonctions (ci-dessous) et ces fonctions se trouvent bien plus bas dans le "main.c" , mauvais élève que je suis, je n'ai pas lu ma copie avec attention!

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
/**
  * @brief  Tx Transfer completed callback
  * @param  UartHandle: UART handle. 
  * @note   This example shows a simple way to report end of IT Tx transfer, and 
  *         you can add your own implementation. 
  * @retval None
  */
void HAL_UART_TxCpltCallback(UART_HandleTypeDef *UartHandle)
{
  /* Set transmission flag: transfer complete*/
  UartReady = SET;

  /* Turn LED3 on: Transfer in transmission process is correct */
  BSP_LED_On(LED3);
}

/**
  * @brief  Rx Transfer completed callback
  * @param  UartHandle: UART handle
  * @note   This example shows a simple way to report end of IT Rx transfer, and 
  *         you can add your own implementation.
  * @retval None
  */
void HAL_UART_RxCpltCallback(UART_HandleTypeDef *UartHandle)
{
  /* Set transmission flag: transfer complete*/
  UartReady = SET;

  /* Turn LED3 on: Transfer in reception process is correct */
  BSP_LED_On(LED3);
}

Par contre maintenant je n'arrive pas a trouver l'appel de ces fonctions, je pensé les trouver ds les fonctions:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

HAL_StatusTypeDef HAL_UART_Transmit_IT(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size)

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

HAL_StatusTypeDef HAL_UART_Receive_IT(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size)

Je suis incapable de comprendre de quelle manière ces fonctions sont appelé (RxCpltCallback & TxCpltCallback) !

Nb: Je te fais parvenir le liens ou j'ai télechargé le firmware ==> http://www.st.com/web/en/catalog/tools/PF259243 dans l'item SAMPLE & BUY la ligne STM32cubeF4.

une fois le dossier compréssé téléchargé le chemin pour parvenir au programme que j'étudie est:

STM32Cube_FW_F4_V1.7.0/Projects/STM32F429I-Discovery/Examples/UART/UART_TwoBoards_ComIT/ pour le dernier dossier ca depend de l'IDE que tu utilises, tu sais mieux que moi!

Tcho l'ami et bonne rentré des classes!

[Vincent PETIT]

Salut mon gars,
Ça va être du costaux....

Tout d'abord si je regarde ton exemple main.c :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 /* While the UART in reception process, user can transmit data through 
     "aTxBuffer" buffer */
  if(HAL_UART_Transmit_IT(&UartHandle, (uint8_t*)aTxBuffer, TXBUFFERSIZE)!= HAL_OK)
  {
    Error_Handler();
  }
 
 /*##-5- Wait for the end of the transfer ###################################*/   
  while (UartReady != SET)
  {
  } 
 
  /* Reset transmission flag */
  UartReady = RESET;

On voit l'appel de la fonction HAL_UART_Transmit_IT (voir ci dessous pour son implémentation)

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
static HAL_StatusTypeDef UART_Transmit_IT(UART_HandleTypeDef *huart)
{
  uint16_t* tmp;
  uint32_t tmp1 = 0;
 
  tmp1 = huart->State;
  if((tmp1 == HAL_UART_STATE_BUSY_TX) || (tmp1 == HAL_UART_STATE_BUSY_TX_RX))
  {
    if(huart->Init.WordLength == UART_WORDLENGTH_9B)
    {
      tmp = (uint16_t*) huart->pTxBuffPtr;
      huart->Instance->DR = (uint16_t)(*tmp & (uint16_t)0x01FF);
      if(huart->Init.Parity == UART_PARITY_NONE)
      {
        huart->pTxBuffPtr += 2;
      }
      else
      {
        huart->pTxBuffPtr += 1;
      }
    } 
    else
    {
      huart->Instance->DR = (uint8_t)(*huart->pTxBuffPtr++ & (uint8_t)0x00FF);
    }
 
    if(--huart->TxXferCount == 0)
    {
      /* Disable the UART Transmit Complete Interrupt */
      __HAL_UART_DISABLE_IT(huart, UART_IT_TXE);
 
      /* Enable the UART Transmit Complete Interrupt */    
      __HAL_UART_ENABLE_IT(huart, UART_IT_TC); 
    }
    return HAL_OK;
  }
  else
  {
    return HAL_BUSY;
  }
}

SI tu regardes bien en bas de la fonction, on remarquera 2 choses !
La première c'est les fameux bits TXE et TC dont on parlait et notre anglais était bon lorsqu'on a traduit la doc.
La seconde.... c'est que ça ne répond pas du tout à ta question bref ... passons


Maintenant voilà ma vision des choses.
Lorsque l'on configure une interruption dans un registre et lorsque celle ci se manifeste, le micro arrête son programme en cours et saute sur ce qu'on appel un vecteur d'interruption. C'est tout simplement l'emplacement mémoire où se trouve la fonction d'interruption a exécuter. En réalité ce n'est pas un appel de fonction comme tu le ferais dans un programme, là c'est le micro qui saute tout de suite à un emplacement mémoire bien précis.
Donc si tu configures ton UART pour qu'il déclenche une interruption lorsqu'une trame est partie alors une fois que c'est fait le compteur programme va sauter ici :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 __weak void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart)
{
  /* NOTE: This function Should not be modified, when the callback is needed,
           the HAL_UART_TxCpltCallback could be implemented in the user file
   */ 
}

Je te traduis ce qu'il y a de noté dans cette fonction d'interruption (et en ch'ti en plus):

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
/* NOTE: Fou po tes pattes là d'un et surtout si tu n'a besoin ! vin d'y d'jus, 
           HAL_UART_TxCpltCallback peut être impléminté d'un l'fonction de ch'l'utilisateur. Hein !
   */

Et ce que cette fonction d'interruption dit, c'est que tu dois l'implémenter toi même dans ton programme principal (ou secondaire)

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
void HAL_UART_TxCpltCallback(UART_HandleTypeDef *UartHandle)
{
  /* Set transmission flag: transfer complete*/
  UartReady = SET;
 
  /* Turn LED3 on: Transfer in transmission process is correct */
  BSP_LED_On(LED3);
}

Et là c'est ce qui est fait ! Je suis sur à 98% que ce que tu vois juste au dessus c'est une fonction d'interruption.

Concernant UartReady, je pense que cette variable ne sert qu'au programme principal et à gérer les LED.
- J'ai l'impression qu'au démarrage du programme attend donc la LED est éteinte.
- Une fois qu'une interruption arrive UartReady passe a SET, on allume la LED et dans la foulée on casse la boucle while du programme principal
- Et cette LED se met a clignoter !

Voilà, voilà.
Il est assez dur le code de ST.

A+

[julien terrier]

Salut,
donc j'ai fait quelques recherches sur les docs et il semblerait que la méthode de fonctionnement que tu décris est la bonne.

Interrupt mode IO operation
 Send an amount of data in non blocking mode using HAL_UART_Transmit_IT()
At transmission end of transfer HAL_UART_TxCpltCallback is executed and user can
add his own code by customization of function pointer HAL_UART_TxCpltCallback

 Receive an amount of data in non blocking mode using HAL_UART_Receive_IT()
At reception end of transfer HAL_UART_RxCpltCallback is executed and user can
add his own code by customization of function pointer HAL_UART_RxCpltCallback

J'ai trouvé également ce petit paragraphe sur les callback functions (voir doc en attachée)

J'ai également posté un message sur le forum de ST pour demander des explications sur la méthode de fonctionnement de ces fonctions!

Difficile de trouver des infos!

Encore une fois merci pour ton aide !

[Vincent PETIT]

Salut,
donc j'ai fait quelques recherches sur les docs et il semblerait que la méthode de fonctionnement que tu décris est la bonne.

Interrupt mode IO operation
 Send an amount of data in non blocking mode using HAL_UART_Transmit_IT()
At transmission end of transfer HAL_UART_TxCpltCallback is executed and user can
add his own code by customization of function pointer HAL_UART_TxCpltCallback

 Receive an amount of data in non blocking mode using HAL_UART_Receive_IT()
At reception end of transfer HAL_UART_RxCpltCallback is executed and user can
add his own code by customization of function pointer HAL_UART_RxCpltCallback

J'ai également posté un message sur le forum de ST pour demander des explications sur la méthode de fonctionnement de ces fonctions!
Difficile de trouver des infos!

D'accord donc ça fonctionne bien comme la grande majorité des autres micro-contrôleurs.
Par contre, je ne comprends pas bien ce que tu as demandé comme explications sur le forum de ST ? Tu veux creuser, plus encore, sur ce qui se passe physiquement dans le micro ?

Si oui, alors tout est écrit dans la datasheet du micro (comme pour les autres fabricants) au pire si tu as le lien de celle-ci, je pense arriver a trouver rapidement le paragraphe où il en parle.


Petite question : Pourquoi décortiquer le Firmeware ? Qui justement a été fait pour faire abstraction de ce qu'il y a en dessous !
Si tu veux programmer en maîtrisant réellement ce qui se passe, tu peux le faire directement et sans passer par le Firmware de ST.
C'est un peu comme Atmel qui fourni aussi ce qu'ils appellent ASF (Atmel Software Framework) qui est une collection de fonctions/librairies prêtes à l'emploi permettant de te servir des périphériques sans s'occuper de rien. Mais d'expérience, je peux te dire que apprendre le fonctionnement du micro Atmel au travers de leur Framework est beaucoup plus difficile que de programmer le micro directement en C par exemple et avec l'aide de la datasheet et de la doc du compilateur.

A+

[julien terrier]

En faite je souhaites avoir plus de détails sur l'appel de ==>

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
void HAL_UART_TxCpltCallback(UART_HandleTypeDef *UartHandle)
__weak void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart)

meme si j'ai bien compris le principe de fonctionnement c'est juste par curiosité!

Je suis aussi entrain de creuser sur la signification de _weak j'ai trouvé cette explication http://infocenter.arm.com/help/index...s/ka14171.html mais bon il est presque minuit et mon cerveau fatigue je reprendrais demain lol

Si j'ai bien étudié les docs, en mode USART les données qui arrivent sur la PIN RX vont ds le "registre a décalage de réception" (RSR) puis dans le "registre de donnée de réception" (RDR) pour enfin être dispo sur les bus APB2, il y a juste une chose dont je ne suis pas sur et que je suis encore entrain de chercher.
Dans la section GPIO les données vont arrivées sur RX soit la pin PA10 de mon µcontroleur donc PA10 ne sera pas une General Purpose (GPIO) car elle sera configurée en USART1 via l'alternate fonction. Et c'est la que le doute m'habite car ds le manuel de reference (RM0090) ils indiquent quand mode "Alternate Function" les données présente sur l'I/O sont échantillonnées dans le registre de donnée d'entrée (Input Data Register) a chaque cycle d'horloge de AHB1 (Bus de données). Donc d'un coté si je regarde le cheminent de l'USART on utilise le bus APB2 par contre si je regarde le cheminent de GPIOA on utilise le bus AHB1! J'ai l'impression qu'il y a quelque chose qui m'échappe!

Sans transition lol par la suite je vais me pencher sur les fonctions qui utilisent le LCD sur ma carte STM32F429I DISCO-BOARD!

Ensuite voici le lien de la question que j'ai posé sur le forum de ST.com ==> https://my.st.com/public/STe2ecommun...urrentviews=79

Au début je demande pourquoi dans le code on initialise le bit d'interruption de parité alors que dans l'initialisation de l'USART parité = NONE ( tu reconnaîtra ma patte de fouineur avec mes questions tordu lol) et ensuite je demande des explications sur la variable UartReady et les fonctions callback.

Je te mets les liens vers les documents relatifs au Micro:

Librairie:
http://www.st.com/st-web-ui/static/a...DM00105879.pdf

Reference Manuel:
http://www.st.com/st-web-ui/static/a...chtype=keyword

Datasheet:
http://www.st.com/st-web-ui/static/a...chtype=keyword

Programming Manuel (pas eu le temps de le regarder celui-ci):
http://www.st.com/st-web-ui/static/a...chtype=keyword

Par contre je veux surtout pas que tu gaspille ton temps pour moi, tu m'a déjà pas mal aidé, je sais qu'on a tous des obligations et des choses prioritaires a faire!


A+ et merci

[Vincent PETIT]

Si j'ai bien étudié les docs, en mode USART les données qui arrivent sur la PIN RX vont ds le "registre a décalage de réception" (RSR) puis dans le "registre de donnée de réception" (RDR) pour enfin être dispo sur les bus APB2

Je viens de regarder la doc RM0090 - page 960 (le schéma). On voit bien le registre RSR qui se déverse dans RDR qui se déverse dans DR (data register qui correspond au registre USART_DR contenant les données, voir page 1001) par contre je ne vois pas APB2 !?

Il y a juste une chose dont je ne suis pas sur et que je suis encore entrain de chercher.
Dans la section GPIO les données vont arrivées sur RX soit la pin PA10 de mon µcontroleur donc PA10 ne sera pas une General Purpose (GPIO) car elle sera configurée en USART1 via l'alternate fonction. Et c'est la que le doute m'habite car ds le manuel de reference (RM0090) ils indiquent quand mode "Alternate Function" les données présente sur l'I/O sont échantillonnées dans le registre de donnée d'entrée (Input Data Register) a chaque cycle d'horloge de AHB1 (Bus de données). Donc d'un coté si je regarde le cheminent de l'USART on utilise le bus APB2 par contre si je regarde le cheminent de GPIOA on utilise le bus AHB1! J'ai l'impression qu'il y a quelque chose qui m'échappe!

Hum hum... je ne sais pas vraiment ce que c'est cette histoire d'alternate fonction. Peut être que j'en ai entendu parler sous un autre nom sur un autre micro mais j'ai un peu de mal à comprendre ce que c'est.

[julien terrier]

SLt Vincent,

Je viens de regarder la doc RM0090 - page 960 (le schéma). On voit bien le registre RSR qui se déverse dans RDR qui se déverse dans DR (data register qui correspond au registre USART_DR contenant les données, voir page 1001) par contre je ne vois pas APB2 !?

Je suis arrivé a cette conclusion grace au datasheet du µcontroleur P18 figure6 il y a le block diagram et donc on voit bien que USART1 est en relation directe avec le bus APB2.
Pièce jointe 187182

Toujours ds le datasheet p36 Table 8 on peut voir les caractéristiques de l'USART1 et notamment l'APB mapping.
Pièce jointe 187183.

Hum hum... je ne sais pas vraiment ce que c'est cette histoire d'alternate fonction. Peut être que j'en ai entendu parler sous un autre nom sur un autre micro mais j'ai un peu de mal à comprendre ce que c'est.

Summary of alternate function:

8.3.7 I/O alternate function input/output
Deux registres sont fournis pour sélectionner une des 16 fonction alternée entrées/sorties
Disponible sur chaque I/O. Avec ces registres, tu peux connecter une fonction alternée a une
autre pin selon le besoin de ton application.
Cela signifie qu'un nombre de fonction périphérique est multiplexé sur chaque GPIO
utilisant GPIOx_AFRL et GPIOx_AFRH comme registre de fonction alternée. L'application peut
ainsi choisir une des fonctions possible pour chaque I/O. L' AF selection signal est
commun aux entrées et sorties des fonctions alternées, une seul voie est
selectionnée pour l'entrée/sortie des fonctions d'une I/O.
Pour savoir quelle fonctions sont multiplexées sur chaque GPIO pin, voir les datasheets.
Note: L'application peut choisir qu'une fonction périphérique par I/O à la fois.
(Traduit par moi so be carreful si tu veux voir l'original tu le trouvera sur le doc RM0090 p276.)

Nb: J'ai un décalage avec les pages que tu m'as donné P960 et 1001 moi c'est p955 par exemple?!?!

[julien terrier]

Bonsoir,
je suis de retour avec mon histoire d'interruption (il lâche pas l'affaire), je pense que la boucle est bouclé (enfin je pense).

Pour reprendre au début dans le main après les initialisations, déclarations etc.. Si on appuie sur le bouton USER on envoie un message de la carte 1 vers la carte 2 (et pendant ce tps la a Vera cruz):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
/* The board sends the message and expects to receive it back */
  
  /*##-2- Start the transmission process #####################################*/  
  /* While the UART in reception process, user can transmit data through 
     "aTxBuffer" buffer */

  if(HAL_UART_Transmit_IT(&UartHandle, (uint8_t*)aTxBuffer, TXBUFFERSIZE)!= HAL_OK)
  {
    Error_Handler();
  }

Je vais parler seulement de ce qui m’intéresse dans la fonction HAL_UART_Transmit_IT(&UartHandle, (uint8_t*)aTxBuffer, TXBUFFERSIZE)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
/**
  * @brief  Sends an amount of data in non blocking mode.
  * @param  huart: pointer to a UART_HandleTypeDef structure that contains
  *                the configuration information for the specified UART module.
  * @param  pData: Pointer to data buffer
  * @param  Size: Amount of data to be sent
  * @retval HAL status
  */
HAL_StatusTypeDef HAL_UART_Transmit_IT(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size)
{
  uint32_t tmp = 0;
  
  tmp = huart->State;
  if((tmp == HAL_UART_STATE_READY) || (tmp == HAL_UART_STATE_BUSY_RX))
  {
    if((pData == NULL ) || (Size == 0)) 
    {
      return HAL_ERROR;
    }
    
    /* Process Locked */
    __HAL_LOCK(huart);
    
    huart->pTxBuffPtr = pData;
    huart->TxXferSize = Size;
    huart->TxXferCount = Size;

    huart->ErrorCode = HAL_UART_ERROR_NONE;
    /* Check if a receive process is ongoing or not */
    if(huart->State == HAL_UART_STATE_BUSY_RX) 
    {
      huart->State = HAL_UART_STATE_BUSY_TX_RX;
    }
    else
    {
      huart->State = HAL_UART_STATE_BUSY_TX;
    }

    /* Enable the UART Parity Error Interrupt */
    __HAL_UART_ENABLE_IT(huart, UART_IT_PE);

    /* Enable the UART Error Interrupt: (Frame error, noise error, overrun error) */
    __HAL_UART_ENABLE_IT(huart, UART_IT_ERR);

    /* Process Unlocked */
    __HAL_UNLOCK(huart);

    /* Enable the UART Transmit data register empty Interrupt */
    __HAL_UART_ENABLE_IT(huart, UART_IT_TXE);
    
    return HAL_OK;
  }
  else
  {
    return HAL_BUSY;   
  }
}

Donc si l'UART est prêt ou si juste la réception est occupé on entre ds la condition, on récupère les données etc.., et on active 3 bits d'interruption.
le bit d'interruption qui m’intéresse c'est le bit TXEIE (du registre USART_CR1) et ce bit est mis a 1 avec la ligne:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 /* Enable the UART Transmit data register empty Interrupt */
    __HAL_UART_ENABLE_IT(huart, UART_IT_TXE);

Ensuite les données récupérés dans le registre des données de transmission (Transmitter Data Register) depuis le bus interne vont dans le registre a decalage de transmission (Transmitter Shift Register) ( ca nous fais une belle jambe)
Sauf que cette action de passage des données d'un registre a un autre déclenche le bit TXE de manière materiel, c'est ne pas moi qui le dit mais le manuel de référence (This bit is set by hardware when the content of the TDR register has been transferred into the shift register. An interrupt is generated if the TXEIE bit =1 in the USART_CR1 register.).

Ce qui a pour effet de déclencher une interruption sur le µcontroleur (c'est toujours pas moi qui le dit) cette interruption et gérer par un vecteur (une fois de plus Vincent avait raison) ou autrement appelé NVIC ( Nested Vector Interrupt Controller) qui ds mon programme sont définis comme cela:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
/* Definition for USARTx's NVIC */
#define USARTx_IRQn                      USART1_IRQn
#define USARTx_IRQHandler                USART1_IRQHandler

Je pense que cette interruption appel une fonction générique (je dis je pense parce que je ne suis pas sur du procédé sur la manière dont est appelée la fonction) qui ce trouve dans un fichier source attaché au projet (stm32f4xx_it.c):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
/**
  * @brief  This function handles UART interrupt request.  
  * @param  None
  * @retval None
  * @Note   This function is redefined in "main.h" and related to DMA stream 
  *         used for USART data transmission     
  */
void USARTx_IRQHandler(void)
{
  HAL_UART_IRQHandler(& UartHandle);
}

Une fois de plus cette fonction renvoi vers ce que ST appel les drivers:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
/**
  * @brief  This function handles UART interrupt request.
  * @param  huart: pointer to a UART_HandleTypeDef structure that contains
  *                the configuration information for the specified UART module.
  * @retval None
  */
void HAL_UART_IRQHandler(UART_HandleTypeDef *huart)
{
  uint32_t tmp1 = 0, tmp2 = 0;
tmp1 = __HAL_UART_GET_FLAG(huart, UART_FLAG_TXE);
  tmp2 = __HAL_UART_GET_IT_SOURCE(huart, UART_IT_TXE);
  /* UART in mode Transmitter ------------------------------------------------*/
  if((tmp1 != RESET) && (tmp2 != RESET))
  {
    UART_Transmit_IT(huart);
  }

Pour info j'ai mis que la gestion d'interruption qui m’intéresse pour le moment soit mode Transmitter. Donc a ce niveau tmp1&2 sont différent de 0 car TXEIE = 1 donc on exécute UART_Transmit_IT(huart);:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
/**
  * @brief  Sends an amount of data in non blocking mode.
  * @param  huart: Pointer to a UART_HandleTypeDef structure that contains
  *                the configuration information for the specified UART module.
  * @retval HAL status
  */
static HAL_StatusTypeDef UART_Transmit_IT(UART_HandleTypeDef *huart)
{
  uint16_t* tmp;
  uint32_t tmp1 = 0;
  
  tmp1 = huart->State;
  if((tmp1 == HAL_UART_STATE_BUSY_TX) || (tmp1 == HAL_UART_STATE_BUSY_TX_RX))
  {
    if(huart->Init.WordLength == UART_WORDLENGTH_9B)
    {
      tmp = (uint16_t*) huart->pTxBuffPtr;
      huart->Instance->DR = (uint16_t)(*tmp & (uint16_t)0x01FF);
      if(huart->Init.Parity == UART_PARITY_NONE)
      {
        huart->pTxBuffPtr += 2;
      }
      else
      {
        huart->pTxBuffPtr += 1;
      }
    } 
    else
    {
      huart->Instance->DR = (uint8_t)(*huart->pTxBuffPtr++ & (uint8_t)0x00FF);
    }

    if(--huart->TxXferCount == 0)
    {
      /* Disable the UART Transmit Complete Interrupt */
      __HAL_UART_DISABLE_IT(huart, UART_IT_TXE);

      /* Enable the UART Transmit Complete Interrupt */    
      __HAL_UART_ENABLE_IT(huart, UART_IT_TC);
    }
    return HAL_OK;
  }
  else
  {
    return HAL_BUSY;
  }
}

Idem je ne vais pas m'etendre sur tout ce qu'il se passe ds cette fonction, il y a une ligne ou je n'ai pas bien saisi ce que l'on fait avec les données (huart->Instance->DR = (uint8_t)(*huart->pTxBuffPtr++ & (uint8_t)0x00FF)
mais la ce qui m'interesse c'est que l'on met le bit TXEIE a 0 et que l'on met le bit TCIE a 1 grace a la ligne ==> __HAL_UART_ENABLE_IT(huart, UART_IT_TC);

Et le manuel de référence dit que quand TCIE = 1 il y aura une interruption a chaque fois que le bit TC = 1, et de quelle manière le bit TC est mis à 1 ?
Comme le dit encore une fois le manuel de référence ==> This bit is set by hardware if the transmission of a frame containing data is complete and if TXE is set. An interrupt is generated if TCIE=1 in the USART_CR1 register.
traduction ==> Ce bit est activé par le matériel si la transmission d'une trame contenant des données est terminée et si TXE est activé. Une interuption est générée si TCIE = 1.

Donc nous revoilà partie vers le vecteur d'interruption et le fameux appel de :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
/**
  * @brief  This function handles UART interrupt request.
  * @param  huart: pointer to a UART_HandleTypeDef structure that contains
  *                the configuration information for the specified UART module.
  * @retval None
  */
void HAL_UART_IRQHandler(UART_HandleTypeDef *huart)
{
  uint32_t tmp1 = 0, tmp2 = 0;
tmp1 = __HAL_UART_GET_FLAG(huart, UART_FLAG_TC);
  tmp2 = __HAL_UART_GET_IT_SOURCE(huart, UART_IT_TC);
  /* UART in mode Transmitter end --------------------------------------------*/
  if((tmp1 != RESET) && (tmp2 != RESET))
  {
    UART_EndTransmit_IT(huart);
  }

La encore les conditions sont respectées donc on execute:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
/**
  * @brief  Wraps up transmission in non blocking mode.
  * @param  huart: pointer to a UART_HandleTypeDef structure that contains
  *                the configuration information for the specified UART module.
  * @retval HAL status
  */
static HAL_StatusTypeDef UART_EndTransmit_IT(UART_HandleTypeDef *huart)
{
  /* Disable the UART Transmit Complete Interrupt */    
  __HAL_UART_DISABLE_IT(huart, UART_IT_TC);
  
  /* Check if a receive process is ongoing or not */
  if(huart->State == HAL_UART_STATE_BUSY_TX_RX) 
  {
    huart->State = HAL_UART_STATE_BUSY_RX;
  }
  else
  {
    /* Disable the UART Parity Error Interrupt */
    __HAL_UART_DISABLE_IT(huart, UART_IT_PE);

    /* Disable the UART Error Interrupt: (Frame error, noise error, overrun error) */
    __HAL_UART_DISABLE_IT(huart, UART_IT_ERR);

    huart->State = HAL_UART_STATE_READY;
  }
  
  HAL_UART_TxCpltCallback(huart);
  
  return HAL_OK;
}

En gros on désactive les différents bit d'interruption et surtout on appel le fameux callback que je cherche depuis plusieurs jour lol.
donc que ce passe t-il a l'appel de ==> HAL_UART_TxCpltCallback(huart);

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
/**
  * @brief  Tx Transfer completed callbacks.
  * @param  huart: pointer to a UART_HandleTypeDef structure that contains
  *                the configuration information for the specified UART module.
  * @retval None
  */
 __weak void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart)
{
  /* NOTE: This function Should not be modified, when the callback is needed,
           the HAL_UART_TxCpltCallback could be implemented in the user file
   */ 
}

Donc l'attribut _weak signifie que l'utilisateur peut encore la déclarée dans l'application sans que la fonction ne soit modifiée dans le driver. Autrement dit cela permet d'utiliser une fonction appartenant a une bibliothèque, de d'implémenter selon ses besoins et la ou normalement l'éditeur des liens devrait s'arrêter avec l'erreur "multiple defines", l'attribut permet a l'éditeur de lien de ne pas prendre en compte la fonction avec l'attribut _weak.

Et dans notre programme c'est exactement ce qu'il se passe puisque dans le main on retrouve notre fameuse fonction mais sans l'attribut _weak:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
/**
  * @brief  Tx Transfer completed callback
  * @param  UartHandle: UART handle. 
  * @note   This example shows a simple way to report end of IT Tx transfer, and 
  *         you can add your own implementation. 
  * @retval None
  */
void HAL_UART_TxCpltCallback(UART_HandleTypeDef *UartHandle)
{
  /* Set transmission flag: transfer complete*/
  UartReady = SET;

  /* Turn LED3 on: Transfer in transmission process is correct */
  BSP_LED_On(LED3);
}

et cette fonction nous permet de sortir de cette fichu boucle while (UartReady != SET):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 /* The board sends the message and expects to receive it back */
  
  /*##-2- Start the transmission process #####################################*/  
  /* While the UART in reception process, user can transmit data through 
     "aTxBuffer" buffer */
  if(HAL_UART_Transmit_IT(&UartHandle, (uint8_t*)aTxBuffer, TXBUFFERSIZE)!= HAL_OK)
  {
    Error_Handler();
  }
  
  /*##-3- Wait for the end of the transfer ###################################*/   
  while (UartReady != SET)
  {
  }
  
  /* Reset transmission flag */
  UartReady = RESET;
  
  /* Turn LED3 Off */
  BSP_LED_Off(LED3);

Vincent dis moi que la boucle est bouclée ?

[Vincent PETIT]

+1
Je fais la même analyse que toi. De plus, si on relis tous les postes (même le premier que tu as ouvert) tout semble très cohérent entre ce qu'on a écrit / la datasheet / les traductions / le fonctionnement avec le bit TC (qui est le même principe que les tous les micro que je connais) / le "__weak" et la fonction d'interruption a implémenter par l'utilisateur. Enfin UartReady sert bien au programme de démonstration pour casser la boucle while !

Là je crois que tu n'as plus besoin de moi
Pas simple quand même de décortiquer un Firmware !?

[julien terrier]

Back in the business, j’étais balade j'ai attrapé un gros rhume (merci ma fille) avec un petit pb de dos scanner et compagnie avec protrusion discale (l’étape juste avant l'hernie cool)...

Bon maintenant que j'ai bien fait ma victime, retournons aux choses sérieuse.

Là je crois que tu n'as plus besoin de moi
Pas simple quand même de décortiquer un Firmware !?

Pas si sur car la je vais décortiquer le firmware pour comprendre précisément comment il configure les GPIOs et surtout comment fonctionnent les fonctions alternées, j'ai commencé a mettre mon nez dedans des que j'ai un peu plus de bille j'ouvre un nouveau post et mon petit doigt me dit que tu vas certainement y participer !

Et puis une fois que j'aurai bien assimilé comment le tout fonctionne je passerai a la bibliothèque "STemWin library" disponible ds le package STM32CUBEF4 afin de pouvoir afficher des chaines de caractères en toute sérénité

Quel programme passionnant!

[Vincent PETIT]

Repose toi bien en tout cas ! Pour les rhums qui vienne des enfants, j'en sais quelques choses

Si le sujet te semble résolu, classe le comme tel.
A bientôt bétail.
Vincent