ASM51

Tenho uma dúvida!

O STM32F103C8T6, possui 3 uarts, correto? Essas UARTs são completamente independentes, quanto ao baudrate gerado para cada uma delas?

Eu entendi que em UMA Uart, podemos configurar DOIS tipos de baudrate, por exemplo: RX=9600 e TX=115000, a dúvida é se as outras UARTs também são individuais os baudrates.

Afinal de contas, me surgiu outra dúvida, os timers responsáveis pelas temporização, são timers separados dos convencionais que no caso são os timers 1 até 7 no caso desse GPU, ou utilizam esses timers...

Eu agradeço a ajuda.

Guri
Instala o STMCubeMX e tenta configurar visualmente as 3 usarts

os 2 elevados ao CUBE

Tomar no CUBE com este CUBE. Mastiga d+ e engessa a mente. Me autodesafiei a fazer um pisca led sem ele...
[url=http://]https://www.asm51.com.br/phpbb/viewtopic.php?f=13&t=18500[/url] (resultado sinistro do botão url)
Ah sim.. tenho ciência que enquanto tento piscar o led, o concorrente já acendeu um display 7 segmentos com o CUBE ... tnc...

Calma Zé

Eu só falei pro Guri tentar configurar as 3 portas no Cube e ver que conflitos ele (o Cube) ele relata. O Guri usa um compilador mais mingau com canela que o CubeMX mas não está se entendendo com o datasheet do stm32f103, o cube é um ganha tempo.

Eu não concordo com você quando diz que usar o Cube engessa a mente e eu comecei nos anos 70 quando se codificava na mão usando a tabela de instruções da CPU e entrando uma por uma num teclado hexa e torcendo pra não travar e ter que desligar/ligar e digitar tudo de novo, O Cube ajuda a resolver um monte de conflitos que se vocẽ for exclusivamente pelo datasheet pode demorar um tempão para depurar. Se você quer acusar algo de engessador então agrida o STM32duino que transforma um "maquinão" como a blue pill num arduino uno tirando acesso a uma série de recursos em nome da simplicidade, nesse sim dá para acender 7 leds enquanto você briga para acender 1.

vIXXI

Eu falei borracha,

A serial, pode-se configurar apenas com uma velocidade x, para RX e TX mutuamente...

Já a seriais podem ser configuradas individualmente, estou testando a bagaça na prática, até agora 22:45...travou tudo... Tentei colocar 115kbps em uart2 e 9600 na uart1...quando juntei tudo travou...

Então, uso ainda o mikroc, afinal de contas paguei 700 pilas nele...porém não uso as libs dele, eu prefiro pegar o datasheet e fazer as libs...

Quanto ao truestudio, estou para começar as brincadeiras, mas estou com muito trabalho, gigante pela frente para terminar e vai de mikroc mesmo

Então palm, eu também programava num z80 da vida...na época era a maior emoção, vixxi, e quando dava certo, era show...olhando hoje para as ferramentas que existem como o CUBE, e os demais compiladores, realmente é algo astronomico.

Pensava nisso ontem, lembrando e comparando o z80 com o que há hoje em termos de programação...

Boa

pamv escreveu: o cube é um ganha tempo.
o STM32duino que transforma um "maquinão" como a blue pill num arduino uno tirando acesso a uma série de recursos em nome da simplicidade, nesse sim dá para acender 7 leds enquanto você briga para acender 1.

pamv escreveu: uso ainda o mikroc,

Faz um pisca led aí pra mim. O requisito é simples: Usar a interrupt timer2 onde led^⁼1 a cada segundo. E sem usar libs prontas e mastigadas. Apenas acessando/programando o hw do mc

pamv escreveu:pegar o datasheet e fazer as libs...

tmj. Veja a minha saga lá no tópico
viewtopic.php?f=13&t=18500
Compila pro stm32f051c8t6. Ou melhor... faça piscar todos os ports...

Código: Selecionar todos

GPIOA_ODR^=0xffff;
GPIOB_ODR^=0xffff;

ze, disculpa minha inocencia, mas não consegui entender o quer dizer em relação ao CUBE?

Qual foi o problema encontrado e o porque dos questionamentos e da treta com o palm.

Guri escreveu:vIXXI
porém não uso as libs dele, eu prefiro pegar o datasheet e fazer as libs...

Depois de ler isso achei que vc era o único que entenderia kk. Algo como... ao criar as inicializações do hw c meio que fica refém do sistema 'alto nível' e quase (ou nunca) não sabe o que ocorre nas entranhas do mc. Algo como o ccs e arduínos da vida. Vejamos o 'meu' (meu) caso quasisuperficialmente em termos de leitura de d.s.

inicie o sistema de clock

Código: Selecionar todos

RCC_CR_bit.HSION=1;// liga clock
//while(!RCC_CR_bit.HSIRDY); //espera estabilizar
RCC_CFGR_bit.MCO=0x07; //SYSCLK
RCC_APB2ENR=0xffffffff; //clock em tudo
RCC_APB1ENR_bit.TIM2EN=1; //clock no timer 2 ... quase tudo
RCC_APB1ENR=0xffffffff; //agora sim .. tudo mesmo

inicie os ports

Código: Selecionar todos

void setupports()
{
//stm051c8
#ifdef f051
GPIOA_MODER=0x55555555; //tudo
GPIOB_MODER=0x55555555; //saída
#endif

acione o sistema de interrupção do timer

Código: Selecionar todos

RCC_APB1ENR_bit.TIM2EN=1; //libera clock no timer 2
TIM2_CR1_bit.CEN=1;//aciona contador
TIM2_CR1_bit.ARPE=1;//off/on autoreload
TIM2_CNT=0x5;//teste
TIM2_PSC=0x01;//32; //prescaler
TIM2_ARR=0x10;//0xfff8; //auto reload
TIM2_CR1_bit.DIR=1;//down-up count
TIM2_DIER_bit.UIE=1;//hab interupt

crie a rotina da interrupt

Código: Selecionar todos

__irq void IRQHandler(void)
{
TIM2_SR_bit.TIF=0;//reset da interrupt
TIM2_SR_bit.UIF=0;//reset da interrupt 
led^=1;
}


no main()

Código: Selecionar todos

for(;;);

Viu que fofo? Isso, só isso, teoricamente era pra piscar o led. E teoricamente ocupar algumas míseras dezenas de bytes.
Tenta agora com o cube. Vc não sabe qual registros ou como é acessado o hw do mc e provavelmente deve ocupar milhares de bytes
Mas como disse, faço do jeito difícil + pela adrenalina de ter o controle absoluto do hw do mc. Não me preocupo com o tempo e 'concorrentes', entendes?

Por outro lado, recentemente fiz um led piscar em algumas horas com um esp32 que ganhei usando a interface do arduíno. Não conformado com a facilidade, fiz vários leds varrerem sob o comando do ad (algo como um barrgraph). Ainda sem conformar, foquei no wireless que é seu fote e pisquei um led com um aplicativo no celular. Detalhe, ocupa quase 400Kbytes só pra piscar o led. Mas como o treco tem vários MB... tô nem aí...

Guri escreveu:e da treta com o palm.

Acho que vc tá vendo coisa. Zero treta amigo. De fato até curti sua publicação, percebes? De fato tenho muita sintonia com os membros deste forum. E por este momento...,

Guri escreveu:porém não uso as libs dele, eu prefiro pegar o datasheet e fazer as libs...

... achei que tínhamos também

Se tiver a versão demo do seu compilador, talvez eu baixe e avalie. Se achar que deve/pode talvez te peça dicas de como acessar o hw do mc com ele, ok?

Então zé....eu entendi, ok

Eu sou do tempo que se programava em assembler, como muitos daqui do forum...vivi a época do z80 e 8051...

Foi meio complicado pra mim, aderir a programar em C...mas depois de apanhar para fazer um GLCD funcionar, resolvi por a mão na massa e aprender C.
Confesso que não me arrependi, tanto que hoje, penso muito pouco ou NADA em assembler, por diversos motivos e um deles é a versatilidade da linguagem C e sua transparência.

Eu nunca fui fã de utilizar libs prontas, acho mais "gostoso" olhar o manual e construir você mesmo, pois ninguém melhor do que você para saber os caminhos mais acertados dentro do seu fw.

Até o momento, não consegui sair fora do mikroc, pelo simples motivo que o utilizo como compilador e porque a interface dele é muito amigável e acho legal trabalhar com a IDE do mikroc. Como eu disse, fazer a libs, dá maior liberdade e visão do que esta acontecendo! Eu tinha feito uma rotina meia grande no ARM e precisei incluir uma eeprom externa, e como eu tava com pressa (tenho que fazer as coisas rápidas, se não fico no prejuizo) acabei usando a lib do mikroc à i2c...Puts, deu um pal no fw e eu não achava de jeito algum o culpado desse travamento...Resumindo, quebrei a cuca e comecei a elaborar o drive, e para minha surpresa quando coloquei no fw, o erro sumiu...mas é só colocar denovo a lib i2c no fw que trava tudo....eis aí uma das vantagens de se criar a sua lib com base no manual do gpu.

Ate o momento continuo no mikroc por dois motivos, o primeiro foi que paguei por ele, tenho que tirar o investimento antes de o deixar e o segundo motivo é que até agora não vi nada que me incentiva-se mudar de compilador (na minha humilde opnião todas as IDEs utilizam o mesmo compilador do fabricante do chip, o que muda é só a IDE, eu acho né)...
Agora cá entre nós arduino é muito chulo de mais...na minha percepção a impressão que se tem ao usar o arduino é que fizeram uma GAMBIARRA lascada, o bicho demora um tempão para compilar um pisca pisca...