Atividade #678
FechadaMeta #523: Ter novas placas mãe para RoboCup 2018
Fazer esquemático e pcb da placa mãe modelo 2018
Arquivos
Atualizado por Onias Castelo Branco há mais de 6 anos
Adicionados os periféricos no esquematico da placa mãe.
Prosseguindo com adicionando o step para novo formato de placa e posicionamento dos componentes.
Atualizado por Onias Castelo Branco há mais de 6 anos
.no pcb, feitos os roteamentos dos 8 leds (adicionei tambem leds para as cores laranja e verde para possiveis implementações futuras).
No sch, analisei a ordem dos leds no led7 segmentos, porém deixei como estavam. Adicionei o resistor de pull-up no extensor de porta.
no sch, estou tendo problemas em interligar as portas da nova folha de sch com as demais, mas ja separei os pinos responsaveis. pela minha analise, o spi2 podera ser usado sem perdas pro projeto.
na pcb, falta posicionar corretamente o mpu9250 e o extensor de porta+led+botão.
Atualizado por Onias Castelo Branco há mais de 6 anos
Avaliar os componentes INA169 e INA250 para substituir o ina220 usado atualmente na placa.
datasheets:
ina169: http://www.ti.com/lit/ds/symlink/ina169.pdf
ina250: http://www.ti.com/lit/ds/symlink/ina250-q1.pdf
recomendação sobre o pcb: refazer todo o routing. posicionando primeiro os grupos funcionais e depois fazendo o routing (uma layer na horizontal e outra na vertical para evitar isolamento de planos)
Atualizado por Onias Castelo Branco há mais de 6 anos
- Arquivo Mother_board_SSL2018.SchDoc Mother_board_SSL2018.SchDoc adicionado
- Arquivo Periféricos.SchDoc Periféricos.SchDoc adicionado
- Arquivo POWER.SchDoc POWER.SchDoc adicionado
- Arquivo INA220.SchDoc INA220.SchDoc adicionado
- Arquivo MOTORES.SchDoc MOTORES.SchDoc adicionado
Atualizado por Onias Castelo Branco há mais de 6 anos
- Arquivo pinagem discovery cube.JPG pinagem discovery cube.JPG adicionado
Coloquei todos os pinos que usamos no robo no cube com os devidos nomes.
Coloquei tambem alguns dos pinos usados por funcoes da discovery, como os pinos que vao na usb.
Atualizado por Onias Castelo Branco há mais de 6 anos
- Arquivo aumento no plano.JPG aumento no plano.JPG adicionado
- Arquivo posicionamento dos componentes alfa.JPG posicionamento dos componentes alfa.JPG adicionado
Estou trabalhando no posicionamento da placa. Enquanto isso, percebi que esqueci o resistor para o ina169 do drible.
Destacado tambem o aumento na largura do plano da tensao de bateria que vai para os motores.
Atualizado por Onias Castelo Branco há mais de 6 anos
os sensores e leds infravermelhos estao separados pois o cartão sd esta entre eles.
Atualizado por Onias Castelo Branco há mais de 6 anos
- Arquivo bottomlayer mother board 2018.JPG bottomlayer mother board 2018.JPG adicionado
- Arquivo toplayer mother board 2018.JPG toplayer mother board 2018.JPG adicionado
segue anexa minha proposta de posicionamento e planos para a placa. mantive os reguladores de tensao na mesma posição, e mantive o interruptor na face da frente do robo.
Posso seguir para o roteamento?
Atualizado por Onias Castelo Branco há mais de 6 anos
- Arquivo display-codigo.JPG display-codigo.JPG adicionado
- Arquivo display-expansor.JPG display-expansor.JPG adicionado
- Arquivo display-sch.JPG display-sch.JPG adicionado
Sobre o display 7 segmentos, estou com problemas em corrigir a pinagem dele. Pesquisei sobre como é a pinagem do display e encontrei a seguinte configuração:
Na placa, atualmente é assim que está setado o expansor de porta:
00- a
01- h
02- b
03- c
04- d
05- e
06- f
07- g
E coloquei no firmware os seguintes números para serem ligados e tive o seguinte resultado:
Percebi que tive um resultado errado porem inesperado. O pino superior a esquerda deveria ser o pino a, porém está no sch como G. Quanto eu aciono o g (valor lógico 0x80) o resultado que acende é o pino H (ou DP).
mandando o valor 0x01 eu aciono o pino a, fazendo acender o led inferior (correspondente ao valor D no sch usual) porém o a está ligado no E usual.
Atualizado por Onias Castelo Branco há mais de 6 anos
A imagem que eu coloquei está com resolução baixa.
Segue o resultado do que eu mandei por código:
valor - valor usual - valor esperado baseado no meu sch
0x01 - D - E
0x02 - F - B
0x04 - E - A
0x08 - G - H
0x10 - A - G
0x20 - B - F
0x40 - C - E
0x80 - H - C
Atualizado por Luiz Renault Leite Rodrigues há mais de 6 anos
- Arquivo picture124-1.png picture124-1.png adicionado
A pinagem do LCD, visto de cima, é:
Atualizado por Onias Castelo Branco há mais de 6 anos
mas o problema se mantem. inserindo 01 no codigo eu deveria ver acender o pino A e esta acendendo o pino D.
Mantenho pinagem e deixo anotado o padrao de anotação para resolver no firmware?
Atualizado por Onias Castelo Branco há mais de 6 anos
Luiz Renault Leite Rodrigues escreveu:
A pinagem do LCD, visto de cima, é:
está de acordo com o que eu fiz no esquemático do componente.
Atualizado por Luiz Renault Leite Rodrigues há mais de 6 anos
Com certeza esta é a pinagem do Display. Conferi com o multímetro.
Atualizado por Onias Castelo Branco há mais de 6 anos
Luiz Renault Leite Rodrigues escreveu:
Com certeza esta é a pinagem do Display. Conferi com o multímetro.
okay. Adapto a pinagem do expansor para ficar da maneira padrão (abcdefgh ou hgfedcba) então?
Atualizado por Onias Castelo Branco há mais de 6 anos
- Arquivo mother-board-pcb-2d-bot-0605.JPG mother-board-pcb-2d-bot-0605.JPG adicionado
- Arquivo mother-board-pcb-2d-top-0605.JPG mother-board-pcb-2d-top-0605.JPG adicionado
- Arquivo mother-board-pcb-3d-top-0605.JPG mother-board-pcb-3d-top-0605.JPG adicionado
Coloquei as mudancas mais recentes no meu repositorio do github:
https://github.com/OniasC/SSL_Mother_Board
Seguem abaixo os pcbs do bottom e do top. Para os stiches, segui a seguinte referencia do altium: https://www.altium.com/documentation/18.0/display/ADES/((Via+Stitching+and+Via+Shielding))_AD
Lá também contem o Step com a versão mais recente do projeto, que foi balizada com a mecanica para haver compatibilidade com o novo drible.
Atualizado por Luiz Renault Leite Rodrigues há mais de 6 anos
Muito bom trabalho.
Sugiro fazer simulação dos circuitos de potência. Estou liberando a licença do PDN.
Utilizar os circuitos da bateria até os módulos de motores. Fazer simulações considerando um motor de cada vez com corrente máxima, e depois com os 5 motores com corrente máxima, e por fim os 5 motores com corrente média.
Atualizado por Onias Castelo Branco há mais de 6 anos
Na revisão dos pinos, encontrei alguns conflitos entre pinos escolhidos por mim e usados por perifericos ja na discovery. Seguem eles abaixo:
pino - periferico discovery - meu uso
PA0 - user button - M2_ENCA
PA4 - LRCK/AIN1x (CS43L22) - D_CUR
PA5 - SCL/SPC (LIS302DL ou LIS3DSH) - SPI1_SCK
PA6 - SDO (LIS302DL ou LIS3DSH) - SPI1_MISO
PA7 - SDA/SDI/SDO (LIS302DL ou LIS3DSH) - SPI1_MOSI
PA10 - USB_ID - NRF_CS#
PA13 - SWDIO (SWD) - NRF_CE
PB3 - SWO (SWD) - M1_ENCB
PB6 - SCL (CS43L22) - M3_ENCA
PB9 - SDA (CS43L22) - I2C1_SDA
PB10 - CLK (MP45DT02) - SPI2_SCK
PC3 - DOUT/AIN4x (MP45DT02) - SPI2_MOSI
PC7 - MCLK (CS43L22) - M0_MBH
PC10 - SCLK (CS43L22) - MPU_CS
Destes, alguns já estavam na placa antiga, porém tive que mudar alguns pinos de posição. Haverá algum conflito em algum pino? Acredito que o unico que eu teria que mudar seria o PA10, pois usa features do USB. Há mais algum?
Atualizado por Onias Castelo Branco há mais de 6 anos
Luiz Renault Leite Rodrigues escreveu:
Muito bom trabalho.
Sugiro fazer simulação dos circuitos de potência. Estou liberando a licença do PDN.
Utilizar os circuitos da bateria até os módulos de motores. Fazer simulações considerando um motor de cada vez com corrente máxima, e depois com os 5 motores com corrente máxima, e por fim os 5 motores com corrente média.
Brasil. Vou tentar fazer hoje.
Atualizado por Luiz Renault Leite Rodrigues há mais de 6 anos
Onias Castelo Branco escreveu:
Na revisão dos pinos, encontrei alguns conflitos entre pinos escolhidos por mim e usados por perifericos ja na discovery. Seguem eles abaixo:
pino - periferico discovery - meu uso
PA0 - user button - M2_ENCA
PA4 - LRCK/AIN1x (CS43L22) - D_CUR
PA5 - SCL/SPC (LIS302DL ou LIS3DSH) - SPI1_SCK
PA6 - SDO (LIS302DL ou LIS3DSH) - SPI1_MISO
PA7 - SDA/SDI/SDO (LIS302DL ou LIS3DSH) - SPI1_MOSI
Para os 3 acima, basta colocar o LIS302DL ou LIS3DSH em modo SPI. Se não for acionado o CSN deles, não há interferência.
PA10 - USB_ID - NRF_CS#
Verificar se gera curto ao baixar o CSN
PA13 - SWDIO (SWD) - NRF_CE
Evitar utilizar este pino para manter possibilidade de debug.
PB3 - SWO (SWD) - M1_ENCB
Evitar utilizar este pino para manter possibilidade de trace/debug.
PB6 - SCL (CS43L22) - M3_ENCA
PB9 - SDA (CS43L22) - I2C1_SDA
Os dois sinais acima podem dar problema com o uso do M3_ENCA. Tentar manter os dois sianis como I2C.
PB10 - CLK (MP45DT02) - SPI2_SCK
PC3 - DOUT/AIN4x (MP45DT02) - SPI2_MOSI
Se você der CLK, ele te dá DOUT.
PC7 - MCLK (CS43L22) - M0_MBH
PC10 - SCLK (CS43L22) - MPU_CS
Verificar se pode desativar o CS43L22 através de algum sinal de reset.
Destes, alguns já estavam na placa antiga, porém tive que mudar alguns pinos de posição. Haverá algum conflito em algum pino? Acredito que o unico que eu teria que mudar seria o PA10, pois usa features do USB. Há mais algum?
Atualizado por Onias Castelo Branco há mais de 6 anos
Luiz Renault Leite Rodrigues escreveu:
Onias Castelo Branco escreveu:
PC7 - MCLK (CS43L22) - M0_MBH
PC10 - SCLK (CS43L22) - MPU_CS
Verificar se pode desativar o CS43L22 através de algum sinal de reset.
O pino PD4 é responsável pelo reset do CS43L22. Não estamos usando o PD4
Atualizado por Onias Castelo Branco há mais de 6 anos
Sobre os pinos que o sr avisou que poderia dar problema:
PA10 - NRF_CE#
Verificar se gera curto ao baixar o CSN
como é um pino digital, vou tentar mudar o pino de lugar.
PA13 - SWDIO (SWD) - NRF_CE
Evitar utilizar este pino para manter possibilidade de debug.
como é um pino digital, vou tentar mudar o pino de lugar.
PB6 - SCL (CS43L22) - M3_ENCA
PB9 - SDA (CS43L22) - I2C1_SDA
Os dois sinais acima podem dar problema com o uso do M3_ENCA. Tentar manter os dois sianis como I2C.
Dando reset no CS43L22 o problema é resolvido? Caso não, o unico pino que eu poderia usar para substituir o M3_ENCA é o PD12, que é um dos leds (o verde no caso).
PB10 - CLK (MP45DT02) - SPI2_SCK
PC3 - DOUT/AIN4x (MP45DT02) - SPI2_MOSI
Se você der CLK, ele te dá DOUT.
Não há problema então? no caso o dout eh um pino mosi do spi mesmo.
Atualizado por Onias Castelo Branco há mais de 6 anos
Quanto ao uso dos pinos destinados ao SWD. Já usamos o SWO para o encoder. Não tenho outro substituto para o M1_ENCB (o pino com a mesma funcionalidade é o PA2, ocupado pela M2_ENCB).
Quer dizer que nunca usamos a feature de debug?
Atualizado por Luiz Renault Leite Rodrigues há mais de 6 anos
Onias Castelo Branco escreveu:
Sobre os pinos que o sr avisou que poderia dar problema:
PA10 - NRF_CE#
Verificar se gera curto ao baixar o CSN
como é um pino digital, vou tentar mudar o pino de lugar.
Verifique no esquemático se há problema ao controlar este pino. Pode ser que não precise mudar.
PA13 - SWDIO (SWD) - NRF_CE
Evitar utilizar este pino para manter possibilidade de debug.
como é um pino digital, vou tentar mudar o pino de lugar.
PB6 - SCL (CS43L22) - M3_ENCA
PB9 - SDA (CS43L22) - I2C1_SDAOs dois sinais acima podem dar problema com o uso do M3_ENCA. Tentar manter os dois sianis como I2C.
Dando reset no CS43L22 o problema é resolvido? Caso não, o unico pino que eu poderia usar para substituir o M3_ENCA é o PD12, que é um dos leds (o verde no caso).
Provavelmente com o reset do CS43L22 não haverá problema.
PB10 - CLK (MP45DT02) - SPI2_SCK
PC3 - DOUT/AIN4x (MP45DT02) - SPI2_MOSISe você der CLK, ele te dá DOUT.
Não há problema então? no caso o dout eh um pino mosi do spi mesmo.
Pelo contrário. Irá interferir na sua comunicação SPI.
Atualizado por Luiz Renault Leite Rodrigues há mais de 6 anos
Onias Castelo Branco escreveu:
Quanto ao uso dos pinos destinados ao SWD. Já usamos o SWO para o encoder. Não tenho outro substituto para o M1_ENCB (o pino com a mesma funcionalidade é o PA2, ocupado pela M2_ENCB).
Quer dizer que nunca usamos a feature de debug?
SWO é utilizado para trace. Caso queira usar, deverá desativar o encoder.
O SWD deve ficar reservado para debug. Caso contrário não conseguirá fazê-lo ou com o debug não será possível testar o NRF.
Atualizado por Onias Castelo Branco há mais de 6 anos
Onias Castelo Branco escreveu:
Quanto ao uso dos pinos destinados ao SWD. Já usamos o SWO para o encoder. Não tenho outro substituto para o M1_ENCB (o pino com a mesma funcionalidade é o PA2, ocupado pela M2_ENCB).
Quer dizer que nunca usamos a feature de debug?
Posso não usar o timer2_ch2 (pino em conflito) e passar a usar o timer2_ch3? Se sim, posso realocar o pino do clk do spi2 para o pb13 que está vazio.
Atualizado por Luiz Renault Leite Rodrigues há mais de 6 anos
Onias Castelo Branco escreveu:
Posso não usar o timer2_ch2 (pino em conflito) e passar a usar o timer2_ch3? Se sim, posso realocar o pino do clk do spi2 para o pb13 que está vazio.
Mas para encoder, não tem que utilizar CH1 e CH2? Pelo menos no STM32F1 é assim.
Atualizado por Onias Castelo Branco há mais de 6 anos
- Arquivo pa10 discovery.JPG pa10 discovery.JPG adicionado
acredito que dê pra usar sim.
Atualizado por Onias Castelo Branco há mais de 6 anos
Luiz Renault Leite Rodrigues escreveu:
Onias Castelo Branco escreveu:
Posso não usar o timer2_ch2 (pino em conflito) e passar a usar o timer2_ch3? Se sim, posso realocar o pino do clk do spi2 para o pb13 que está vazio.
Mas para encoder, não tem que utilizar CH1 e CH2? Pelo menos no STM32F1 é assim.
Então barro. Existe solução por software?
Atualizado por Luiz Renault Leite Rodrigues há mais de 6 anos
Onias Castelo Branco escreveu:
Luiz Renault Leite Rodrigues escreveu:
Onias Castelo Branco escreveu:
Posso não usar o timer2_ch2 (pino em conflito) e passar a usar o timer2_ch3? Se sim, posso realocar o pino do clk do spi2 para o pb13 que está vazio.
Mas para encoder, não tem que utilizar CH1 e CH2? Pelo menos no STM32F1 é assim.
Então barro. Existe solução por software?
Verificou esta questão no RM, antes de desistir?
Atualizado por Luiz Renault Leite Rodrigues há mais de 6 anos
Onias Castelo Branco escreveu:
acredito que dê pra usar sim.
Exatamente.
Atualizado por Onias Castelo Branco há mais de 6 anos
Luiz Renault Leite Rodrigues escreveu:
PB10 - CLK (MP45DT02) - SPI2_SCK
PC3 - DOUT/AIN4x (MP45DT02) - SPI2_MOSISe você der CLK, ele te dá DOUT.
Não há problema então? no caso o dout eh um pino mosi do spi mesmo.
Pelo contrário. Irá interferir na sua comunicação SPI.
Trocando o pino PB10 (CLK) pelo pino PB13 (atualmente livre na placa mae e na discovery) resolvo o conflito desses dois pinos, correto?
Atualizado por Onias Castelo Branco há mais de 6 anos
Luiz Renault Leite Rodrigues escreveu:
Onias Castelo Branco escreveu:
Luiz Renault Leite Rodrigues escreveu:
Onias Castelo Branco escreveu:
Posso não usar o timer2_ch2 (pino em conflito) e passar a usar o timer2_ch3? Se sim, posso realocar o pino do clk do spi2 para o pb13 que está vazio.
Mas para encoder, não tem que utilizar CH1 e CH2? Pelo menos no STM32F1 é assim.
Então barro. Existe solução por software?
Verificou esta questão no RM, antes de desistir?
Abri ele agora a pouco e estou lendo a parte de leitura de encoder. Não achei nada que limitasse aos dois primeiros canais. Mas posso só não ter entendido também.
Atualizado por Luiz Renault Leite Rodrigues há mais de 6 anos
Onias Castelo Branco escreveu:
Abri ele agora a pouco e estou lendo a parte de leitura de encoder. Não achei nada que limitasse aos dois primeiros canais. Mas posso só não ter entendido também.
Coloque aqui o diagrama de blocos do TMR.
Atualizado por Luiz Renault Leite Rodrigues há mais de 6 anos
Onias Castelo Branco escreveu:
Trocando o pino PB10 (CLK) pelo pino PB13 (atualmente livre na placa mae e na discovery) resolvo o conflito desses dois pinos, correto?
Possivelmente não resolve. Tem que ver o datasheet do componente para checar o comportamento do DOUT. Não consegue trocar o PC3?
Atualizado por Onias Castelo Branco há mais de 6 anos
Luiz Renault Leite Rodrigues escreveu:
Onias Castelo Branco escreveu:
Trocando o pino PB10 (CLK) pelo pino PB13 (atualmente livre na placa mae e na discovery) resolvo o conflito desses dois pinos, correto?
Possivelmente não resolve. Tem que ver o datasheet do componente para checar o comportamento do DOUT. Não consegue trocar o PC3?
Pc3 é o spi2_mosi. Ele pode ir para o PB15 que atualmente é o DAH (TIM12_CH2). Posso ativar o pwm do drible em qualquer outro pino de timer (no caso, o pino PE5 - tim9_ch1 ocupado pela funcionalidade M0_MAL - pino digital de output, poderia ir para um pino não ocupado).
Atualizado por Onias Castelo Branco há mais de 6 anos
- Arquivo timer-diagrama-de-blocos.JPG timer-diagrama-de-blocos.JPG adicionado
Luiz Renault Leite Rodrigues escreveu:
Onias Castelo Branco escreveu:
Abri ele agora a pouco e estou lendo a parte de leitura de encoder. Não achei nada que limitasse aos dois primeiros canais. Mas posso só não ter entendido também.
Coloque aqui o diagrama de blocos do TMR.
Atualizado por Onias Castelo Branco há mais de 6 anos
Entendi. Realmente, são só os canais 1 e 2.
Atualizado por Onias Castelo Branco há mais de 6 anos
Os problemas que persistem são os pinos de SWD (PA13 e PB3). Consigo resolver o problema do pb10 e pc3 com a realocação dos pinos que eu mencionei acima.
PA13 é o nrf_ce que posso resolver escolhendo um pino digital diferente.
PB3 é o m1_encb e o unico substituto é o pa1 que é o m2_encb (que não tem substituto).
Atualizado por Onias Castelo Branco há mais de 6 anos
Luiz Renault Leite Rodrigues escreveu:
Muito bom trabalho.
Sugiro fazer simulação dos circuitos de potência. Estou liberando a licença do PDN.
Utilizar os circuitos da bateria até os módulos de motores. Fazer simulações considerando um motor de cada vez com corrente máxima, e depois com os 5 motores com corrente máxima, e por fim os 5 motores com corrente média.
fazendo o teste na fonte, a corrente de stall ficou 2.6A com o motor no encaixe mecânico. e a corrente com o motor fluindo a 8.1V ficou a 180mA.
link para tutorial do pdn: https://www.altium.com/documentation/1.0/display/NEXUS/((PDN+Analyzer))v2_AD
Atualizado por Onias Castelo Branco há mais de 6 anos
- Arquivo SSL-discoverystm32f407.ioc SSL-discoverystm32f407.ioc adicionado
- Arquivo cube_pinagem_new.JPG cube_pinagem_new.JPG adicionado
Antes de checar o PDN, corrigi no esquematico e no cube os pinos que determinamos serem necessarios trocar.
pb10 -> pb13 (spi2_sck)
pc3 -> pb15 (spi2_mosi)
pc15 -> pe5 (dah)
pe5 -> pc15 (m0_mal)
pa13 -> ~pa14 (nrf_ce)~ pc12 (nrf_ce)
Atualizado por Onias Castelo Branco há mais de 6 anos
- Arquivo current_calc.JPG current_calc.JPG adicionado
era esta a conta que eu deveria fazer?
achei nesta referencia: http://www.4pcb.com/trace-width-calculator.html
Atualizado por Onias Castelo Branco há mais de 6 anos
- Arquivo current_probe_motor0.JPG current_probe_motor0.JPG adicionado
- Arquivo current_probe_motor0_after.JPG current_probe_motor0_after.JPG adicionado
Após a explicação sobre o funcionamento do pdn, modifiquei algumas trilhas e então rodei a simulação para 4A com os planos antigos. Ficou da seguinte forma:
Modifiquei os planos do MA, MB, fusível e do ina169. Aumentei a corrente para 7A e segue o resultado da simulação:
Analisando os números, vi que nos pinos B e A passam uma corrente de 3.3 a 3.7A. (após segunda modificação) E chega ao motor uma potencia de 8.2V para uma entrada de 8.4V
Atualizado por Onias Castelo Branco há mais de 6 anos
- Arquivo current_probe_5motors_bottom.JPG current_probe_5motors_bottom.JPG adicionado
- Arquivo current_probe_5motors_top.JPG current_probe_5motors_top.JPG adicionado
Fazendo a simulação para os quatro motores das rodas (corrente de 7A) e o motor do drible (8A) inserindo uma potencia de 8.4V, temos que:
Alguns pinos tem uma corrente atravessando-os na ordem de 1.5A.
Os motores recebem os seguintes potenciais:
M0: 8.04V
M1: 8.022V
M2: 8.154V
M3: 8.137V
DRIBLE: 8.006V
Seguem as imagens dos heat maps das correntes.
O sr acha necessário realizar mais alguma modificação no layout?
Atualizado por Luiz Renault Leite Rodrigues há mais de 6 anos
Onias Castelo Branco escreveu:
era esta a conta que eu deveria fazer?
achei nesta referencia: http://www.4pcb.com/trace-width-calculator.html
Na verdade, a espessura é a do cobre, ou seja, 35 um ou 1oz/inch2
Atualizado por Luiz Renault Leite Rodrigues há mais de 6 anos
- Arquivo picture54-1.png picture54-1.png adicionado
O TOP está muito bom.
No bottom, tentar modificar as trilhas marcadas em verde, visando permitir um fluxo de corrente pelo caminho em magenta.
Atualizado por Luiz Renault Leite Rodrigues há mais de 6 anos
Onias, abri seu Cube Project e vi que os periféricos não estão configurados.
Sugiro que o faça, para verificar alguma incompatibilidade.
Atualizado por Onias Castelo Branco há mais de 6 anos
Luiz Renault Leite Rodrigues escreveu:
Onias, abri seu Cube Project e vi que os periféricos não estão configurados.
Sugiro que o faça, para verificar alguma incompatibilidade.
Não sabia que tinha como fazer isso. Vou me informar sobre o processo.
Atualizado por Onias Castelo Branco há mais de 6 anos
- Arquivo current_calc_update.JPG current_calc_update.JPG adicionado
Luiz Renault Leite Rodrigues escreveu:
Onias Castelo Branco escreveu:
era esta a conta que eu deveria fazer?
achei nesta referencia: http://www.4pcb.com/trace-width-calculator.html
Na verdade, a espessura é a do cobre, ou seja, 35 um ou 1oz/inch2
Refiz a conta. Aceitando um aumento de temperatura para 20C a espessura necessaria para o VBAT eh de 9mm (o plano atual tem 10mm)
Atualizado por Onias Castelo Branco há mais de 6 anos
- Arquivo current_probe_5motors_bottom_1005.JPG current_probe_5motors_bottom_1005.JPG adicionado
- Arquivo current_probe_5motors_top_1005.JPG current_probe_5motors_top_1005.JPG adicionado
- Arquivo mother-board-pcb-2d-bot-1005.JPG mother-board-pcb-2d-bot-1005.JPG adicionado
- Arquivo mother-board-pcb-2d-top-1005.JPG mother-board-pcb-2d-top-1005.JPG adicionado
Luiz Renault Leite Rodrigues escreveu:
O TOP está muito bom.
No bottom, tentar modificar as trilhas marcadas em verde, visando permitir um fluxo de corrente pelo caminho em magenta.
Fiz as devidas correções. Segue anexo o novo caminho das trilhas e nova simulação.
As correntes mais altas que entram nos pinos de ground são de 3,x A para os pinos de gnd dos modulos de motor, alguns pinos proximos destes são da ordem de 1A e dois de 2A (furo de 0.6 de diametro interno e 0.8 externo). E está entrando 36 A para a placa (= 7A*4 + 8A), fazendo sair 17A em dois pinos de gnd (os da bateria e do switch).
As voltagens que chegam para os motores são as seguintes:
m0-8.044V
m1-8.026V
m2-8.155V
m3-8.139V
drible-8.01V
Atualizado por Luiz Renault Leite Rodrigues há mais de 6 anos
Em termos de análise de potência, acho que é isso. Bom trabalho.
Só falta confirmar a configuração dos periféricos no Cube.
Atualizado por Onias Castelo Branco há mais de 6 anos
Luiz Renault Leite Rodrigues escreveu:
Em termos de análise de potência, acho que é isso. Bom trabalho.
Só falta confirmar a configuração dos periféricos no Cube.
Obrigado capitão. Estou fazendo isso agora.
Atualizado por Onias Castelo Branco há mais de 6 anos
- Arquivo SSL-discoverystm32f407.ioc SSL-discoverystm32f407.ioc adicionado
Não soube setar direito o clock (teria que checar os prescalers que estão atualmente no firmware), a configuração do ADC e os pinos GPIO acusaram o seguinte warning:
"some signals are not used in any IP's mode"
Não parece ser preocupante:
https://community.st.com/thread/40725-cubemx-for-f0-has-no-gpio-settings
Atualizado por Luiz Renault Leite Rodrigues há mais de 6 anos
Configure o RCC, habilite o Serial Wire Debug, Configure os timers, USB, etc.
Atualizado por Onias Castelo Branco há mais de 6 anos
- Arquivo SSL-discoverystm32f407.ioc SSL-discoverystm32f407.ioc adicionado
Atualizado por Onias Castelo Branco há mais de 6 anos
- Situação alterado de Em andamento para Resolvida
Atualizado por Onias Castelo Branco há quase 6 anos
- Situação alterado de Resolvida para Fechada