Medidor LC

[KrafT]

Isso é normal... (float)2+(float)2=3,999999999999

Não sei como as calculadoras fazem a correção. Deve ser alguma técnica de arredondamento mais sofisticada, pois uma arredondamento generalizado, iria introduzir outros erros.

Não é a toa que dizem que os sistemas financeiros (bancos e afins) só operam com numero inteiros.

Mas MOR_AL, considerando as limitações de hardware, esses pequenos erros não são problema, ou são?

[MOR_AL]

Isso é normal... (float)2+(float)2=3,999999999999

Não sei como as calculadoras fazem a correção. Deve ser alguma técnica de arredondamento mais sofisticada, pois uma arredondamento generalizado, iria introduzir outros erros.

Não é a toa que dizem que os sistemas financeiros (bancos e afins) só operam com numero inteiros.

Mas MOR_AL, considerando as limitações de hardware, esses pequenos erros não são problema, ou são?

Tenho quase certeza que não. Explico.
Todos estes medidores LC incluem um capacitor, que devido a vários fatores, possui um valor de 1000pF. Ocorre que este capacitor, se muito bom, possui precisão de 1%. Isso sem contar com a influência de variações de temperatura. Então, se uma operação fornece uma precisão de 0,01%, já dá pro gasto.
Há um detalhe, porém, nas equações do cálculo de L e de C. Tem uma parte que é a diferença entre dois números. Até aí tudo bem, mas na medida que o valor de C (ou de L) tendem para zero, ou o valor mínimo, essa diferença fica tendendo a zero, ou seja, o resultado começa a cair dentro da região de aproximação das operações.
Na prática é fácil de entender, o porquê.
Está se medindo um capacitor de baixo valor em paralelo com outro de uns 1000pF. A capacitância resultante é a soma das duas, logo para conhecer o valor do capacitor sob teste, tem-se que subtrair o valor maior, restando um valor menor.
O mesmo vale para o indutor, pois estão em série. Quando são comparados os dois valores. O conhecido L e o desconhecido L + Lzinho.
Fiz um programa que incluí apenas as rotinas de ponto flutuante (PF) com 32 bits e de conversão Inteiro24 para PF32 e de PF32 para Inteiro24. Contei cerca de 710 instruções.
MOR_AL

[eletroinf]

Só pra embaralhar um pouco ...
Eu tenho um LCF que montei, cujo projeto saiu numa revista EPE, de 2004.
Só alterei a entrada de frequência pra ficar mais sensível. Pra tudo que precisei, funcionou muy bien...
É com um PIC 628.

Abç

[MOR_AL]

Só pra embaralhar um pouco ...
Eu tenho um LCF que montei, cujo projeto saiu numa revista EPE, de 2004.
Só alterei a entrada de frequência pra ficar mais sensível. Pra tudo que precisei, funcionou muy bien...
É com um PIC 628.

Abç

A minha idéia é estudar e usar as quatro operações matemáticas com ponto flutuante, além da conversão Inteiro para Ponto Flutuante para Inteiro. As outras funções, mais complexas, podem ser obtidas das quatro básicas. Isso me permite usar PICs 16F com limitação de memória.
Tentei fazer o LC Meter em linguagem de mais alto nível, mas não deu nem para colocar a primeira equação na memória de programa.
Fiquei pu... err, chateado e encarei isso como um desafio.
Aos poucos vou subindo cada degrau da escada, um dia chego lá.
Tive oportunidade de comprar um kit, que o cara disse que era o original. Dele é que apareceram os outros. Isso não me interessou.
[]'s
MOR_AL

[eletroinf]

Penso, veja bem, opinião minha:
PIC é só pra brincar em asm, e coisa pequena.
Até porquê tem outros uC bem melhores e até mais baratos.
Ficar querendo enfiar coisa graúda em PIC chega a ser masoquismo.

[andre_luis]

MOR_AL,


Se possível, mostra a equação a ser usada, pois se o divisor for um valor constante, dá pra contornar o uso de um float, construindo um divisor apenas com * seguido de >>. Fiz isso com o MSP430F com ótimos resultado no desempenho, mas a resolução subiu para algo na ordem de 1,5%, que não era impactante para a aplicação envolvida, mas cada caso é diferente, podendo ser melhor ou pior que esse.

A propósito, já usei compilador que permitia o ajuste da resolução float em casas decimais, mas talvez isso não impacte no consumo de memória de programa, mas somente na quantidade de iterações envolvidas.

+++

[MOR_AL]

Penso, veja bem, opinião minha:
PIC é só pra brincar em asm, e coisa pequena.
Até porquê tem outros uC bem melhores e até mais baratos.
Ficar querendo enfiar coisa graúda em PIC chega a ser masoquismo.

Bom.
Não vou discutir.
Esta é sua opinião e eu a respeito, mesmo podendo discordar.
[]'s
MOR_AL

[MOR_AL]

MOR_AL,


Se possível, mostra a equação a ser usada, pois se o divisor for um valor constante, dá pra contornar o uso de um float, construindo um divisor apenas com * seguido de >>. Fiz isso com o MSP430F com ótimos resultado no desempenho, mas a resolução subiu para algo na ordem de 1,5%, que não era impactante para a aplicação envolvida, mas cada caso é diferente, podendo ser melhor ou pior que esse.

A propósito, já usei compilador que permitia o ajuste da resolução float em casas decimais, mas talvez isso não impacte no consumo de memória de programa, mas somente na quantidade de iterações envolvidas.

+++

Olá André!
Segue o que eu fiz até agora.
1 - Parte teórica com determinação das equações com programas que plotam os gráficos da capacitância e sua derivada em função da frequência de oscilação.
2 - Procedimento a ser incluído no firmware. Vide item medições.
3 - Tentativa de resolver as equações usando MikroBasic. Nem deu para colocar uma das equações em Ponto Flutuante (PF).
4 - Tentativa de resolver as equações usando Inteiro com 32 bits. Mesmo escalando-se as equações, a precisão ficou muito baixa.
5 - Tentativa de resolver as equações usando PF com 32 bits.
5.1 - Conversão Inteiro24 para PF32 e de PF32 para Inteiro24. Teste ok. Fluxograma e MPLAB.
5.2 - Operação de soma com PF32. Teste ok. Fluxograma, MPLAB, MPLAB SIM (simulador), montagem e verificação.
5.3 - Operação de subtração com PF32. Teste ok. Fluxograma, MPLAB, MPLAB SIM (simulador), montagem e verificação.
5.4 - Operação de multiplicação e de divisão com PF32. Teste ok. Fluxograma, MPLAB e MPLAB SIM (simulador).
As equações são 1.3, 1.4, 1.5 e 4.1.
O arquivo do que foi feito até agora se encontra no endereço a seguir.

http://d01.megashares.com/dl/8nNJ2yG/Medidor LC_PDF.pdf

[]’s
MOR_AL

[andre_luis]

MOR_AL,


Bom, pelo visto, o buraco é mais embaixo, pois além da divisão com divisor variável, existe operação de radiciação também.

Dessa vez, sou forçado a concordar com aqueles que apenas criticam o uso do PIC sem antes apresentar alguma proposta de alternativa.



+++

[MOR_AL]

MOR_AL,


Bom, pelo visto, o buraco é mais embaixo ("Por maior que seja o buraco em que você se encontra, relaxe, porque ainda não há terra em cima."), pois além da divisão com divisor variável, existe operação de radiciação também.

Dessa vez, sou forçado a concordar com aqueles que apenas criticam o uso do PIC sem antes apresentar alguma proposta de alternativa.

+++

Apesar da frequência de oscilação ser função do inverso da raiz de LC, não será necessária operação de radiciação.
As equações necessárias usam quadrado (multiplicação), subtração e inverso (divisão). Estas já consegui que funcionassem.

Acho que agora é só manipulação matemática.

Em tempo: Está difícil abrir o site do ASM51. As respostas podem demorar um pouco.
[]'s
MOR_AL

[MOR_AL]

Pessoal!
Sempre que posso, apresento as novidades nesse projeto. Está demorando muito e ficando muito trabalhoso, mas acho que já fiz 90% da programação, faltando os outros 10% e a parte da placa de circuito impresso. O diagrama já foi completamente definido.
Avancei mais um pouco e com isso observei:
1 – A medida de uma indutância ou capacitância, por esse método, requer que se meça a frequência de oscilação. Por isso pensei em incluir um frequencímetro às funções do aparelho.
2 – O caso é que, após seguir essa linha de raciocínio e ter que refazer muita coisa, considerando essa modificação, estou chegando a um possível problema. Já consumi mil e tantos bytes de memória de programa, sobrando cerca de 300 bytes para calcular quatro equações em ponto flutuante (PF). As rotinas em PF já estão incluídas, mas tenho quase a certeza de que não conseguirei fazer caber tudo.
Há duas hipóteses:
a) Sacrificar algumas informações fornecidas através do LCD. Recuperaria ou 75 bytes de programa, ou 150 bytes, dependendo do grau de sacrifício.
b) Retirar a função do frequencímetro. Não observei a quantidade de memória de programa que poderia recuperar.
Talvez sejam necessárias as duas coisas. Ainda não sei.
MOR_AL

[MOR_AL]

Bom. Avancei mais um pouco. Sempre tendo que interromper para tocar outros projetos.
Concluí que para incluir um frequencímetro no medidor LC, teria que remanejar as pinagens no PIC e reestruturar o circuito.
Com isso, para que pudesse usar "apenas" todos os 18 pinos do PIC, teria que mexer no firmware.
Ainda não sei se vai dar para colocar tudo na memória de programa.
O que fiz foi definir todas as rotinas a serem utilizadas, sendo que umas 70% delas já estão prontas.
Falta fazer umas poucas rotinas simples e as que calculam as equações.
Como estou estudando C#, decidi fazer um programinha que calcula o valor dado em número real, para o valor em binário codificado em ponto flutuante, no formato Microchip.
É baseado na AN575.
Se alguém estiver interessado, segue o link do executável.
Tenho o anti-virus Kaspersky Pure (o mais completo). Ao tentar executar o arquivo aparece o alerta comum.
É para Windows. Precisa ter instalado o Microsoft.NET versão (?) para funcionar.
Se encontrarem algum bug, favor reportar.
É livre para distribuir. O preço pago é que consta o meu avatar e e-mail.
http://www.4shared.com/file/EBsPrvqC/Po ... uante.html
[]'s
MOR_AL]