Medidor LC

[MOR_AL]

Recentemente precisei medir valor de capacitância de alguns capacitores.
Dei uma olhada na net e me deparei com muita literatura. Basicamente encontrei dois tipos de medidores. Os que medem o período da carga do capacitor e os que medem a frequência do oscilador LC formado por este capacitor.
Apesar de estar com diversos projetos em andamento, não gosto de copiar nada da net. Apenas estudo os artigos e procuro fazer do meu jeito e adaptado para as minhas necessidades.
Decidi investir no projeto do circuito que usa um oscilador LC para determinar o valor do capacitor. Este projeto também pode determinar o valor de indutor.
Minha diretiva é usar um simples PIC16F628(A) para fazer o circuito.
Cheguei às equações necessárias para tal e vi que seriam necessárias operações com ponto flutuante.
Decidi então usar o compilador mikroBasic.
Com apenas 2k de memória de programa, não deu nem para resolver a primeira das três equações do projeto.
Como vi que usaram um PIC16F84 no projeto, concluí que fizeram em linguagem assembler.
Devido a esse fato, parti para a tentativa de usar apenas números inteiros com 32 bits e as rotinas matemáticas da Microchip. Teoricamente, consegui que usando apenas inteiros devo chegar ao resultado com alguma precisão.
Não sei se vou conseguir imprensar todo o código nos 2k de memória de programa, mas vou tentar.
O circuito provisório se encontra a seguir:


O circuito oscilador usa um comparador LM311. Já vi circuitos que usam o comparador do PIC. Procurei fazer o mesmo. Por isso não aparece o comparador no diagrama.
Vou partir agora para resolver a terceira equação com inteiros.
Na medida do possível vou postando os resultados.
[]'s
MOR_AL

[pbernardi]

Po, se é um projeto caseiro, único, por que não usar um uC com mais memória? Você só vai ter um (ou poucos) protóptipos mesmo...

[MOR_AL]

Po, se é um projeto caseiro, único, por que não usar um uC com mais memória? Você só vai ter um (ou poucos) protóptipos mesmo...

Olá pbernardi!
É verdade, mas também vai um pouco de desafio aí.
Usando um uC com mais memória não haveria novidade para mim. Nesse caso seria mais interessante e barato, comprar o kit e montar.
Com 2k eu aproveito e aprendo a usar as rotinas matemáticas da uChip e consolidar o tratamento de equações com inteiro (já fiz isso de modo mais simples em outro projeto).
[]'s
MOR_AL

[pbernardi]

Bom, sé é pelo desafio, porque não coloca um uP 32 bits com um RTOS, uma FPGA ou um DSP no lugar?

Como diria o proex: sei lá, sou contra esse negócio de ficar achando desafio em assembly pra PIC.

[MOR_AL]

Bom, sé é pelo desafio, porque não coloca um uP 32 bits com um RTOS, uma FPGA ou um DSP no lugar?

Como diria o proex: sei lá, sou contra esse negócio de ficar achando desafio em assembly pra PIC.

Bom!
Seria outra opção ... para mais tarde!!!
Por ora estou assim.
De assembler também não tem desafio. A única novidade é usar rotinas matemáticas prontas da uChip.
No mais é hobby. É um passa-tempo, que a gente mantém lubrificados os neurônios.
Parafraseando nosso colega Proex:
"Sei lá! Sou contra esse negócio de ser contra ..."
MOR_AL

[Renato_mcl]

Mor_AL, você procurou por LC Meter no google?
Tem projetos prontos com hex e tudo o mais se for do seu interesse.
Eu tenho um LC meter do tamanho de um LCD com PIC16F628A, mas este eu comprei o kit em um mutirão.

Renato

[MOR_AL]

Mor_AL, você procurou por LC Meter no google?
Tem projetos prontos com hex e tudo o mais se for do seu interesse.
Eu tenho um LC meter do tamanho de um LCD com PIC16F628A, mas este eu comprei o kit em um mutirão.

Renato

Olá Renato! Tudo bem?!
Eu já dei uma lida no site desse medidor.
Inclusive, algumas informações básicas eu tirei de lá. Mas estou tentando desenvolver para entender de "cabo-a-rabo"!

Segue o link com as minhas deduções.

http://d01.megashares.com/dl/f88d821/Medidor LC_PDF.pdf
[]'s
MOR_AL

[MOR_AL]

Pô! Como as coisas são!
Como uma coisa leva à outra!

Ainda estou tentando fazer o medidor LC.
Tentei fazer usando rotinas com inteiros. Algumas minhas e outras copiadas. Quase deu certo, porém algumas equações fazem subtrações de números grandes com resultados pequenos. Nesse ponto os resultados ficam na região de incerteza e até apresentam erros proibitivos. Por este motivo migrei para operações com ponto flutuante da Microchip.
Pensei.
A Microchip fez as rotinas, portanto devem estar certas. Ledo engano. Algumas rotinas não fecham. Observando mais atentamente, descobri que nas explicações iniciais, eles informam que os dados de saída estão nos registros tais, mas ocorre que estão em outros registros. Aí começa a confusão e não se tem mais confiança nelas.
Vivendo e aprendendo. Quis copiar as rotinas e me dei mal. O pior é que seu uso não é imediato. Tem que ler bastante a tal AN575 até tentar usa-las. Com isso se perde muito tempo.
Para tentar, ainda, acreditar na net, queria saber se algum de vocês já trabalhou com as rotinas de ponto flutuante, com 4 bytes da Microchip, e teve sucesso.
Estou usando assembler porque quero colocar o firmware dentro de 2k de memória. Já tentei fazer com linguagem com maior nível e não deu.
Sei que sou teimoso e que poderia fazer com outro PIC com mais memória, mas encaro isso como desafio (incluindo a teimosia).
Não é um projeto comercial, de modo que não tenho pressa e agindo assim, sempre aprendo alguma coisa a mais. Mesmo que seja para não copiar nada mais da net.
MOR_AL

[MTC]

Oi MOR_AL,

to acumpanhando o teu LC meter! Acho muito bacana a tua iniciativa, de partir do zero e desenvolver tudo!!!

Quando eu for gente grande quero ser igual voce!!! Se chegar a uns 10% do conhecimento e iniciativa ja to contente1!! RS......

[ ]´s

MTC

[MOR_AL]

Oi MOR_AL,

... RS......

[ ]´s

MTC

Grato por suas gentis palavras.
Cada um de nós possui boas qualidades e virtudes.
Considero que, na vida, dei sorte e tive boas oportunidades. Não tenho o que reclamar.
Desejo que todos saibamos aproveita-las.

Não atentei para um pequeno detalhe. Em determinado local, da AN575 aparece que EXP e AEXP possuem o mesmo endereço de RAM. Fiz isso e a operação de soma passou a funcionar para UMA soma que eu fiz (A=0x000000 + B=0x00FFFF). Ainda estou fazendo um loop para varrer os valores de A e B, de 59 em 59 (número primo). Varrendo todos os valores demoraria uns 35 dias rodando. Desse jeito dura cerca de 1 dia. Se não houver erro, terei que acreditar que esteja funcionando para todos os valores.
Desculpem a minha falha. Apesar disso, encontrei um cara na net que encontrou um erro e fez uma correção (que incluí na rotina). O pessoal da uChip não alterou ainda. Entrei no Fórum de lá e aparecem muitos caras com dúvidas e sugestões.

Código: Selecionar todos

Rotina                                Entrada                     Saída

FLO2432 - Int24 para Flo32         AARGB0,AARGB1,AARGB2      AEXP,AARGB0,AARGB1,AARGB2

FPA32   - Soma em Float32     AEXP,AARGB0,AARGB1,AARGB2      BEXP,BARGB0,BARGB1,BARGB2
                              AEXP,AARGB0,AARGB1,AARGB2     

INT3224 - Flo32 para Int24     AEXP,AARGB0,AARGB1,AARGB2          AARGB0,AARGB1,AARGB2

Abraço.
MOR_AL

[jorgeluiz]

nao e' dificil encontrar erros nessas ANs da Microchip. Pior que eles nao corrigem, mesmo que algumas pessoas indiquem os erros, elas permanecem la'. Ou lançam uma AN de erratas. Coisa de gringo.

[MOR_AL]

Atenção! Editei a postagem anterior!

nao e' dificil encontrar erros nessas ANs da Microchip. Pior que eles nao corrigem, mesmo que algumas pessoas indiquem os erros, elas permanecem la'. Ou lançam uma AN de erratas. Coisa de gringo.

É isso aí Jorge Luiz!
Vamos em frente. Estou testando, dentro do possível, cada uma das 4 operações em ponto flutuante, além da converção inteiro16 para float32 e para inteiro16.
Já testei de inteiro16 para float32 e para inteiro16, com todos os valores e deu certo. Agora vou testar para cerca de 1000 valores a operação de soma. Deve levar cerca de 1 dia rodando. O que acontece é que para cada operação, faço:
0 - Aint16 = 0x0000 e Bint16 = 0XFFFF
1 - Aint16 para Afloat32.
2 - Bint16 para Bfloat32.
3 - Cfloat32 = Afloat32 + Bfloat32. (faço a soma dar sempre 0x00FFFF. Vou incrementar 59 em Aint16 e decrementar 59 em Bint16).
4 - Cfloat32 para Cint24.
5 - Cint24 = 0x00FFFF? Se sim, some 59 a Aint16 e subtraia 59 de Bint16. Se não, é erro.
6 - Cint16 > 0x00FFFF (na realidade a variável inteira tem 24 bits). Se sim, então pare. Terminou.
Se não, vá para 1.
MOR_AL

[MOR_AL]

Terminei o programa anterior.
Ocorreram mil, cento e dez loops.
Todos os resultados foram corretos.
Próximo passo. Rotina Subtrair float.
MOR_AL

[MOR_AL]

Para quem estiver acompanhando...

Terminei um programa que usa a rotina de subtração em ponto flutuante.
O programa faz:
0 - A = 0x00.00.00 e B = 0x00.FF.FF. A rotina aceita inteiro com 24 bits, mas no meu caso, uso apenas 16 bits.
1 - Converte as variáveis A e B de inteiro16 para float32.
2 - Calcula a diferença ou Resultado (Res1 = A - B).
3 - Acrescenta B (Res2 = Res1 + B). Res2 = A - B + B = A
4 - Calcula Res3 = Res2 - A = A - A = 0
5 - Converte Res3 de float para inteiro.
5 - Verifica se o resultado Res3 é zero. Caso negativo, para com w = índice do erro. Caso afirmativo, continua.
6 - A = A + 59 e B = B - 59. O resultado Res3 dará sempre zero, independente dos valores de A e B. Só que procuro alterar para tentar varrer as variáveis A e B.
7 - O número de loops chegou a Mil e cento e dez (Loop = 0x0456, ou 1110 decimal)? Caso negativo, vá para 1. Caso afirmativo, termine com w = 0.

Há um detalhe na rotina de subtração FPS32. Se a mantissa for nula e seu sinal for negativo, então a conversão para inteiro, que deveria dar zero, dá 128, que é o valor do bit de sinal, que fica no bit7 do registro que contém a mantissa de mais alto fator (MSB).
Nesse caso, antes de se converter para inteiro, TEM que zerar o bit do sinal, caso a mantissa seja nula.
Próximo e último passo, antes de usar as rotinas no LCMeter.
Testar um programa com as rotinas de multiplicação e divisão em ponto flutuante.
MOR_AL

[MOR_AL]

Faz uns três dias resolvi rever o projeto do medidor LC. Como passou cerca de um ano e meio, tive que reler e estudar tudo que tinha feito, pois já tinha esquecido quase tudo.
Na postagem anterior informei que o passo seguinte seria aplicar as rotinas nas equações do medidor LC. Falha minha.
Falta verificar as rotinas de multiplicação e de divisão.
Depois de um dia consegui que as rotinas funcionassem.
Para simplificar fiz a equação:

A inteiro 24 bits --> A ponto flutuante 32 bits
B inteiro 24 bits --> A ponto flutuante 32 bits

Resultado = ((A * B) /A)/B), que tem que dar 1,0000....

Resultado em ponto flutuante 32 bits --> Resultado em inteiro 24 bits ( resultado = 1 inteiro).

Fiz cerca de 1110 variações de A e de B, de modo a varrer desde valores pequenos de A e de B até valores grandes. Na verdade comecei com valores pequenos de A e grandes de B. Depois incrementei A e decrementei B de 59, para pegar alguns números primos também.

Ocorre que após as 5 operações (incluindo as conversões de inteiro para ponto flutuante e vice-versa) que envolvem cada equação, alguns poucos resultados deram zero. Chabú total!!!

Descobri que os resultados das operações apresentam aproximações, uma vez que os números em ponto flutuante não são contínuos (conjunto dos reais), eles apresentam deslocamentos da ordem de 2 elevado a menos 23, aproximadamente. Isso implica em que o resultado, apesar de poder possuir diversas casas decimais de precisão, quando ocorre a conversão ponto flutuante para inteiro, acredito que o número seja simplesmente truncado. Deve ser isso, não tenho certeza.
Em função desta truncagem, possíveis resultados como 0,9... fornecem resultados em inteiro igual a zero.
Ao alterar a comparação ao final do resultado, de igual a 1 para menor ou igual a 1, todos os testes deram ok.
Para superar este imprevisto, vou incluir um fator de escala nas operações, digamos x 1000. Com isso, os resultados, apesar de inteiros, fornecerão 3 casas decimais. Na hora de mostrar o resultado, movo a vírgula 3 casas decimais para a esquerda, compensando tudo.
Bom.
Estou documentando tudo.
Até o momento, sem contar com as operações de multiplicação e de divisão, o arquivo possui cerca de 25 páginas. Por isso também que está demorando mais ainda.
Agora sim (será?).
O próximo passo é incluir as operações em ponto flutuante nas equações do medidor LC.
[]’s
MOR_AL