ASM51

Caros colegas, o velho vonnilmam, passou essa noite acordado tentando entender uma coisa "misteriosa"

Eu estou fazendo um projetinho para um cliente onde tenho os seguintes módulos ativados no STM32F103C8 "Mikroc arm vr 6.0 original":

- Uso das três Uarts "Uart1, 2 e 3", todas com interrupção ativada, para RX (Uso a mesma velocidade para todas elas ou seja 9600bps).
- Uso da i2c, apenas a 1 ativada a outra não esta em uso (não uso interrupção para esse módulo).

Vejam se conseguem me compreender Tudo funciona aparentemente direitinho como o previsto, porém quando em envio pela TX da uart 2 um dado simples do tipo char (ex. 10), a Uart1 TX fica doida e começa a enviar dados aleatóriamente, os buffers são isolados em variáveis globais (já tentei fazer LOCAL) mas a doidera continua, porém se eu simplesmente paro de enviar dados na TX2, fica tudo OK na TX1...

Eu depois de ficar acordado a noite toda até agora, 10 da manha Notei que no meu FW tenho ligadas a RX1 (que esta na interrupção), várias rotinas com chamadas (protótipos), no meu caso tenho até 4 chamadas uma dentro da outra (como se dizia em assembler, CALLs um dentro do outro chamando a próxima).

Aí quando eu retiro ou diminuo essas chamadas o problema também some.

Minha pergunta é e peço desculpas pelo texto tão grande!? O STM32F103 possúi limitação de stack pointer? Ou o compilador pode ter essas limitações ou talvez em linguagem C, existe alguma regra quanto a chamadas de protótipos, vou dar um exemplo abaixo para ficar mais claro


void TXSerialUart2(unsigned char x)
{
Uart2_write(x);
}

void TXSerialUart1(unsigned char x) // declarando essa variável "x", é LOCAL né?
{
Uart1_write(x);
TXSerialUart2(x);
}

...Chamada da rotina principal para TXSerialUart1(10); //

Se vocês puderem me ajudar fico muito agradecido, pois meus cabelos devem ter ficado uns 10 fios mais brancos

Não deve ser stack, o stack é alocado na ram, e a RAM do STM32F103 é grande, 64K se não me engano.

Não conheço mikroC.

Estranho você enviar dado em uma UART e a outra começar a enviar, será q num é erro de lógica no seu software?

Esse que eu tô usando tem 20k de ram e 128 de flash.

Então, eu também achei estranho, nebuloso.

Eu costumo sempre fazer o fw, aos poucos, passo a passo, justamente para ir isolando bem as tarefas...se alguém tiver uma sugestão fico grato...enquanto isso vou queimando os neuronios

Sugiro utilizar o depurador, e colocar breakpoints em locais estratégicos para caçar o bug...
Possivelmente tem erro no seu software.

Uart2_write(x) é a função mastigada do mikroc? Ela espera transmitir?
As que eu fazia na unha pra outros mc, me lembro que esperava o bit de tx algo como

Código: Selecionar todos

void txbyte(unsigned char dado)
{
while(BIT_TX); //consulte o d.s. sobre tal bit
BUFFER_TX=dado; //consulte o d.s. sobre o buffer
}


Sem esta espera, pode encavalar algo...
E+... sim a variável x é local mas o compilador no afã de otimizar pode estar usando a mesma posição de memória pra outra coisa na interrupt. A propósito, não vi a [necessidade de] interrupt no seu exemplo.

Sou grato pelas dicas a todos os colegas.

A int eu só uso nas RX 1, 2 e 3...TX sem int.

Então, eu no meu cozinhas de neuronios, pensei nessa possíbilidade de otimização do compilador, bom eu dei uma olhada e notei que o compilador estava para otimizar 5x o código (mikroc).

Simplesmente tirei essa otimização, passando para ZERO. Bom não sei ainda se foi isso, mas o problema sumiu, o fw ficou estável, já avancei 2k de programa e tudo funcionando sem interferencias malucas.

Notei realmente que ao otimizar o código, o compilador emite algumas mensagens meio que estranhas em relação aos registros.

A dica de usar o depurador é muito boa dica, obrigado.

Eu ainda sou novato em C, mas me lembro que no assembler com todas as incovenientes de paginação (PIC), sabia-se muito bem o que acontecia...já em C, percebo que a coisa é mais "oculta", mas acho que seja questão de prática.

Muito grato a todos.

Guri escreveu:Simplesmente tirei essa otimização, passando para ZERO. Bom não sei ainda se foi isso, mas o problema sumiu, o fw ficou estável, já avancei 2k de programa e tudo funcionando sem interferencias malucas.

Notei realmente que ao otimizar o código, o compilador emite algumas mensagens meio que estranhas em relação aos registros.

Comigo aconteceu com outras mas sim, isso acontece nas melhores famílias. Me lembro que na ápoca eu perdera um tempão pra analisar/corrigir até que tivera este insight. Talvez nem valha a pena, analise as mensagens. Talvez no seu compilador te direcionem à correção. Mas k entre nós, só vale a pena perder este tempo se espaço estiver ficando crítico.
abç e de nada.

Já apanhei pacas com esse negocio de otimização de código no keil. Não tentei usar mais pois vc nunca sabe o que "ele" esta otimizando e de que forma.

Não tem como dizer ao compilador coisa do tipo "olha, não tente otimizar essa função pois ela tem temporização critica". A coisa sai chutando o balde e otimizando tudo, inclusive as temporizações criticas. Temporizações criticas de acesso ao hardware externo, temporizações embutidas no protocolo TCP/IP e outros, vão todas pro saco.

Já apanhei pacas com esse negocio de otimização de código no keil.

No KEIL fiz vários testes e a otimização PADRÃO (acho que é a 3),não alterou nem 'bugou' nada.

Então amigos, eu estou quase tendo certeza que o "trem" era mesmo na otimização...

Jà estou chegando a 30 k de código e o problema desapareceu.

Aliás, andei lendo sobre a serial do STM103 e me surgiu uma dúvida quanto ao um detalhe que ví e não entendi, se alguém puder responder seria de grande valia para todos.

É o seguinte:

A UART do STM103 é MULTIBUFFER, o que quer dizer isso?

E se é o que estou pensando que seja, ou seja, ela tem um tipo de buffer rotativo ou pooling e se for isso, quantas variáveis existem nesse buffer. Pergunto, porque não consegui identificar no manual dele a quantidade.

QUANTO MAIS EU MEXO COM ARM, MAIS FICO MARABILHADO...O Chipzinho valente.

Muito obrigado

Só para constar,

Eu chutei 11 caracteres na Uart TX no pal (72mhz de clock) e a serial aguentou, não encavalou...

Utilize apenas a função nativa do mikroc:

UART2_Write(data);

Fiz uma atrás da outra na sequencia...

Achei interessante esse tal de MULTIBUFFER, só queria entender se é como eu entendi...