Perguntinha básica de Iniciante...

[Guri]

Pessoal, me tirem uma dúvida.

O STM 103, tem diversos módulos internos, como uart, i2c, pwm, etc...

Eu posso utilizar esses módulos livremente, ou seja, em um PIC 877A, temos vários módulos também, porém tem módulos que ao serem habilitados, acabam por comprometer (outros pinos de I/Os)...isso também ocorre com o STM, ou ele apenas UTILIZA os pinos referentes ao módulo selecionado.

Obrigado

[Rodrigo_P_A]

Pessoal, me tirem uma dúvida.

O STM 103, tem diversos módulos internos, como uart, i2c, pwm, etc...

Eu posso utilizar esses módulos livremente, ou seja, em um PIC 877A, temos vários módulos também, porém tem módulos que ao serem habilitados, acabam por comprometer (outros pinos de I/Os)...isso também ocorre com o STM, ou ele apenas UTILIZA os pinos referentes ao módulo selecionado.

Obrigado

Olha no datasheet, à partir da página 28: https://www.st.com/resource/en/datashee ... f103c8.pdf

o REMAP

[tronico]

Os pinos possuem funções compartilhadas, habilitar um periférico pode impedir o uso de outro. Como citado o datasheet deve ser consultado.
Também pode instalar o STM32CubeMX ou STM32CubeIDE, nele você seleciona os periféricos e vê quais pinos serão ocupados.

[ze]

A leitura do manual sugerido pelo amigo Rodrigo tem algum valor. Mas a mais completa que te ajudará na programação é https://www.st.com/resource/en/referenc ... 171190.pdf
A propósito I está em um (01) dos meus alt-tabs neste exato momento
A propósito II... pegando carona e tentando somar + uns bits... (quasi literalmente) :
a função ADC1_Read() mastigadinha do mikcroc trava no proteus. Algo como não libera o bit da finalização da conversão. Já esta que criei na unha após ler o d.s. supramencionado...

Código: Selecionar todos

unsigned int read_adc(unsigned char channel)
{
#if defined f103proteus
ADC1_SQR3=channel;
ADC1_CR2bits.ADON=1;//liga conversor
ADC1_CR2bits.SWSTART=1;//inicia conversão
while(!ADC1_SRbits.EOC); //espera converter
return ADC1_DR;
#endif
#if defined f051
ADC_CHSELR=1<<channel;
ADC_CR.ADEN=1;//liga conversor
ADC_CR.ADSTART=1;//incia conversão
while(!ADC_ISRbits.EOC); //espera converter
return ADC_DR;
#endif
}

Funciona direitin. Perceba a intenção de fazê-la compatível com o stm32f103 e stm32f051 bastando chavear um #define.
A propósito III, o F051 é + barato que o F103 e se não me falha a memória, tem os mesmos ou um pouco + de recursos

E finalmente, me deu vontade registrar isso também...:
A simples adição das funções mastigadas ADC1_Init() e ADC1_Read() oriundas da lib do mikcroc, passou de 2994 para 3772 bytes de flash usados. Ou seja, otimização zero pras funções mastigadinhas do compilador. E provavelmente deve levar + tempo pra executar. No (meu) caso, isso é totalmente desinteressante pois planejo fazer um osciloscopinho com o mc pra uma jiga de testes. Ou seja, a leitura ad tem que ser o mais rápido possível mas prefiro ainda não apelar pro desconhecido assembly do mc.

tmj

[Guri]

A dica de analisar os pinos utilizados pelos módulos no CUBE é lega, não tinha pensado nisso.

AGORA ZÉ....OCÊ DEU UM SHOW...Obrigado.

Vou testar a sua rotina, pois eu até agora não consegui por para funcionar essa bagaça do AD, sempre dá um erro de conversão, como tenho mencionado em outro post...

[Guri]

Eu estou usando o stm103 por causa da velocidade maior, estou conversando com uma tela tft, mias 3 seriais e uma memoria i2c, lendo mais de 200 botões, acionando leds, comuncando com um PC e nem sei mais o quê...

Agora estou adotando o formato de utilizar chipsets separando as tarefas, fica mais elegante e menos congestionado o hardware...

Antes fazia ou tentava fazer tudo num chip só...doidera.

[Guri]

Então eu ví lá no CUBE e realmente ficou bem claro a distribuição dos pinos sobre os módulos, inclusive existem módulos que são utilizados em alguns casos com outros, limitando-os em alguns casos...

Puxa, eu nem tinha pensado nisso! Obrigado pela dica.

Viu, ZE... Vou testar sua rotina...HOJE AINDA

[pamv]

A dica de analisar os pinos utilizados pelos módulos no CUBE é lega, não tinha pensado nisso.

Foi a dica que eu lhe dei no outro tópico e o mesmo zé veio me empentelhar porque sugeri o Cube e pra ele então "macho que é macho" não o usava. Não perco mais tempo lendo suas dúvidas.

[vtrx]

Eu sou macho,só uso o Keil...

[ze]

"macho que é macho" não o usava. Não perco mais tempo lendo suas dúvidas.

Permita-me... Com todo o respeito, eu preferiria adotar uma postura mais madura algo como era 'uma exposição de um ponto de vista' e a não menos importante, 'uma alternativa pro guri'. Isso é muito comum em foruns mas infelizmente, sua postura também. Por sorte nossa, sou velho de guerra por aqui e claro, não discrimino dúvidas e perco tempo sim, como agora.
Ah sim quase ia esquecendo perdão. Perdão se ofendi seus princípios. Tente focar agora no supramencionado, ok? (a carinha é importante pra descontair)

Eu sou macho,só uso o Keil..

kk quanta evolução... me lembro quando vc era 'criança' e defendia o asm pic com unhas e dentes, te lembra disso .. kk
Ah sim... também usei o keyl noutros mcs. E no em questão, também o cube que apesar de frutinha é sim bem bacaninha (evolução, lembra?). Só não sei se ele gera fontes pro mikroc, keyl e IAR.
Guri, se achar que deve, nos mantenha informados sobre sua experiência com ele. Pode ser um baita adicional à qualidade do tópico e claro, pra posteridade (que também é a missão de foruns)

[Red Neck Guy]

Eu sou macho,só uso o Keil...

Macho que é macho usa o GCC com CMAKE e Vim pra editar.

[tcpipchip]

macho que é macho aguarda 40 minutos para compilar uma linguagem de programação para outra plataforma e ainda usando uma VM

[Guri]

Sím! Com o maior prazer, venho postar as experiências com o mikroc e outros, caro ZE.

Eu também sempre defendi muito a programação em ASM (comecei com z80, 8051 e depois com o PIC na década de 90, mais precisamente em 1995, fui dos primeiros a mexer com eles)...até um dia me deparar com uma situação, onde tinha que programar um glcd...e não tinha tempo para "pensar" com ASM

Aí comecei a olhar para "C" e fui mexer com o mikroc, pela facilidade da IDE e porque tinha muita coisa pronta "libs"...Mas nunca gostei de mexer com libs de terceiros, prefiro criar a própria lib, apesar de dar mais trabalho, mas esse trabalho é só uma vez, depois é só usar. O que conta é que você sabe o que acontece, como é o caso do ASM, agente tem mais intimidade com a CPU...

Eu gostei muito de mexer com C e graças a DEUS, minha curva de aprendizagem esta sendo linear, apesar de ser ainda um "guri" no assunto, e não desmerecer jamais o ASM...Lembrando que antes do mikroc, comecei a arranhar com a ide do coocox, até comprei um curso de um dos amigos do forum...

Gosto de trabalhar com o mikroc, mesmo já tendo percebido que existem alguns "bugs" se assim posso dizer em relação ao interpretador dele, mas creio que seja a forma como o mesmo interpreta determinadas situações em relação ao formato das informações colocadas nele, por isso é bom você criar sua libs, acho isso muito importante.

Por exemplo, tenho tido uma briga com o AD dos arms (usando ainda a lib do mikroc, ainda não testei ou tentei fazer a minha, por falta de tempo), já testei as linhas m0 até m4 e todos dão o mesmo problema de estabilidade na conversão (por isso achei interessante a sua postagem "ZE", sobre aquela lib que você fez), por último utilizei um filtro por amostragem (que é bom diga-se de passagem, porém lerdeia o sistema por causa do seu tempo de execução), aí criei um filtro especial para eliminar os erros de +1 ou -1 em torno da leitura atual (Uso muito essa rotina com PICs com grande sucesso, não uso amostragens, uso apenas uma tabela de comparação para eliminar os erros mecânicos que induzem variações em torno de +1 ou -1 da leitura atual, essa rotina funciona no PAL da CPU, sem amostragens), percebi que o pot, varia normalmente essa grandeza, devido a sua composição mecânica, usando um pic fica show, super estável, mas se uso um arm, o treco fica doido e analisando notei que o AD faz a conversão (quanto maior a resolução pior fica, pulando até mais de 500 casas), porém fica como se estive-se instável...por isso ví sua sugestão de rotina (ZE) e vou testa-la e postarei os resultados...A coisa ficou tão crítica que estou usando um pic para fazer a conversão e entregar para o arm...coisa de guri Porém com classe, aproveitei não só o AD do pic, mas criei um chipset com ele, onde leio AD, botões, acende leds e manipulo um memo i2c, tudo com comunicação ASCII, aliás fica a qui a dica sobre comunicação em ASCII, utilizando buffer rotativo por interrupção na uart (RX)...Após criar um algoritmo de comunicação estruturado com uma tela nextion, ví quão interessante é esse método de comunicação via textos...fica aí a dica.

Keil, ainda não utilizei, mas ainda tenho interesse de mexer com ele, tenho visto muita gente falando bem no decorrer do anos sobre essa IDE...Fui ver o preço e é bem salgadinho, salvo engano era em torno de 10 mil pilas, isso a uns 3 anos atrás quando entrei em contato com o distribuidor...

GCC direto, eu ainda não mexi, achei muito complicado, pelo fato de eu ainda ser um "guri" na área do C...mas acho interessante mexer direto com o compilador,...Antigamente na era do MSX, os mais antigos sabem do que me refiro, eu programava nele, com linhas de comandos (DOS) e também no interpretador BASIC, quem se lembra, era uma febre na época...muito show, o meu primeiro synth foi feito no MSX...

Obrigadão ZE pelo apoio aos aprendizes, como eu...

[Red Neck Guy]

Guri, eu não gosto de polêmicas, porém não posso deixar passar uma situação como essa em que houve um estresse num tópico teu.
Vamos lá:
Você passa postando dúvidas e o pessoal se esforça pra ajudar. Muitas vezes o pessoal perde tempo escrevendo um textão pra te ajudar e no final tu dá uma volta na pergunta pra tentar justificar que já sabia e a dúvida não era bem isso.
Não saber algo não é motivo de vergonha, ainda mais para os participantes de um fórum.
Mas esse tipo de postura é algo que deixa muitos aqui chateados.
Eu sinceramente acho que o teu problema é culpa do efeito Dunning-Kruger: https://pt.wikipedia.org/wiki/Efeito_Dunning-Kruger

[Red Neck Guy]

Ao longo dos anos perdemos muitos participantes que acrescentavam muito ao fórum.
Muitos sumiram por coisas semelhantes ao ocorrido aqui.
Não precisa provar nada pra ninguém, se você tem uma dúvida apenas aceite as opiniões sem tentar ficar rebatendo depois dizendo que já sabia, ou que sabia fazer a conta com laranjas.