Je travaille avec STM32F427
UASRT1 par la classe suivante:USART1 de STM32F427 met parfois 8 bit de données comme si ce serait bit de parité
void DebugUartOperator::Init() {
// for USART1 and USART6
::RCC_APB2PeriphClockCmd(RCC_APB2Periph_USART1, ENABLE);
// USART1 via PORTA
::RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOA, ENABLE);
::GPIO_PinAFConfig(GPIOA, GPIO_PinSource9, GPIO_AF_USART1);
::GPIO_PinAFConfig(GPIOA, GPIO_PinSource10, GPIO_AF_USART1);
GPIO_InitTypeDef GPIO_InitStruct;
// fills the struct with the default vals:
// all pins, mode IN, 2MHz, PP, NOPULL
::GPIO_StructInit(&GPIO_InitStruct);
// mission-specific settings:
GPIO_InitStruct.GPIO_Pin = GPIO_Pin_9 | GPIO_Pin_10;
GPIO_InitStruct.GPIO_Mode = GPIO_Mode_AF;
::GPIO_Init (GPIOA, &GPIO_InitStruct);
USART_InitTypeDef USART_InitStruct;
// 9600/8/1/no parity/no HWCtrl/rx+tx
::USART_StructInit(&USART_InitStruct);
USART_InitStruct.USART_BaudRate = 921600;
USART_InitStruct.USART_WordLength = USART_WordLength_9b;
USART_InitStruct.USART_StopBits = USART_StopBits_1;
USART_InitStruct.USART_Parity = USART_Parity_Odd;
::USART_Init(USART1, &USART_InitStruct);
::USART_Cmd(USART1, ENABLE);
}
void DebugUartOperator::SendChar(char a) {
// wait for TX register to become empty
while(::USART_GetFlagStatus(USART1, USART_FLAG_TXE) != SET);
::USART_SendData(USART1, static_cast<uint8_t>(a));
}
Le problème est que chaque maintenant et puis USART commence en ignorant les données 8e réelles bit et en le définissant comme un bit de parité (parité impaire, pour être spécifique). Le plus étrange de tout cela arrive parfois même après un long coup de courant, sans reprogrammation préalable ou quelque chose. Par exemple, hier soir, tout s'est bien passé, puis le lendemain matin je suis venu travailler, allumer l'appareil et commencer à travailler de la manière décrite. Mais cela ne se limite pas à cela, il peut apparaître au hasard après un prochain redémarrage.
Cet effet est clairement visible avec l'oscilloscope et avec différents convertisseurs UART-USB utilisés avec différents programmes. Il est même possible, une fois cet effet apparu, de reprogrammer un microcontrôleur pour transmettre des jeux de données de test. Par exemple, 0x00 à 0xFF en cycle sans fin. Cela n'affecte pas le problème. Le changement de vitesse (jusqu'à 9600 bps), le nombre de bits par mot, le contrôle de parité n'aide pas - l'effet reste intact même après la reprographie (résultant par exemple en 2 bits de parité vraiment anormaux par octet). Ou, au moins, pendant que UASRT est initialisé et utilisé dans l'ordre habituel en fonction du flux de travail de mon programme.
La seule façon de résoudre ce problème est de rendre la fonction principale() procédez comme suit:
int main() {
DebugUartOperator dua;
dua.Init();
while(1) {
uint8_t i;
while(++i)
dua.SendChar(i);
dua.SendChar(i);
}
}
Avec cela, après la reprogrammation et le redémarrage, les premiers octets (jusqu'à 5) sont transmis pourris, mais alors tout fonctionne plutôt bien et continue de bien fonctionner grâce à d'autres redémarrages et reprogrammations.
Cet effet est observé sur 2 différents STM32F427
s sur 2 cartes physiquement différentes de la même mise en page. Aucune régularité n'est remarquée dans son apparence. La polarité du signal et les niveaux sont conformes aux exigences USART, aucun bruit ou mauvais contact ne sont détectés pendant l'investigation. Il semble y avoir aucune affection à UASRT1 de la direction d'un autre code utilisé dans mon programme (que ce soit le mien ou celui de la bibliothèque) ou il est enterré profondément. CMSIS-OS
est utilisé comme RTOS dans le projet, avec Keil
uVision 5.0.5
RTX OS
.
Besoin d'aide.
Salut Vasily, désolé, je ne vois pas votre vraie question ici. Vous dites que _USART commence à ignorer le 8ème bit de données réel et à le définir comme un bit de parité (parité impaire, pour être spécifique). Mais vous avez configuré 'USART_InitStruct.USART_Parity = USART_Parity_Odd;' Est-ce le problème? – EricPb
Malheureusement pas. J'ai mentionné plus tard que «changer ... le contrôle de parité n'aide pas»: j'ai essayé les deux modes impairs et pairs, ainsi que pas de mode de parité, 8 ou 9 bits de largeur - non, l'effet reste une fois arrivé . –
Intéressant cependant que, après avoir éliminé mon autre problème de fuite de ressources dans CMSIS-RTOS (http://stackoverflow.com/questions/32995099/cmsis-rtoss-osmailfree-returns-some-address-instead-of-osstatus-type -value) le problème discuté a également disparu. Ou, au moins, cet effet n'apparaît plus pendant un temps considérable. –