.if

um off topic 1/2 on... a 2ª imagem traduz muito bem a situação. Quem só fica na "moleza" tem alguma dificuldade com a "dureza". sw!=hw ah.. acho que deu pra entender. Amigo @decones65, não se ofenda... nada pessoal!! Só me deu vontade "traduzir" sua (não 'tua') imagem. Ah sim... Amém! Amigo @Daniel Resende , se deparou agora, mesmo que virtualmente. É polarizado sim. Repare o "eletrolítico" (... talvez exista eletrolitico não polarizado... Vivendo&aprendendo)

Olha isso que bacana (via google imagens indutímetro para multímetro... 2º link) http://www.te1.com.br/2008/12/indutimetro-digital-para-multimetro/ Há alguns anos atrás me deu até vontade montar pra ver. A vontade passou quando compraram um indutímetro

ok -mplab -rode passo a passo inicialmente pra você sentir algo das entranhas do pic -ache a função _delay e coloque um break point no começo e final dela com 5 ms como argumento -mande rodar -verifique quantos ciclos de máquina ocorreram e calcule se o tempo foi 5ms -Também pode usar o logic analizer (ou algo assim) e verificar os pulsos do seu port Mais opções: -Crie seu próprio delay algo como void delay(unsigned int d) //coloque um valor qualquer... { while (d--); //e verifique o tempo desta iteração com a técnica citada acima } -Use os timer´s de nada... adicionado 12 minutos depois Ah sim, se for problema no hw, como pino de reset aberto, falha na alimentação, etc, receba um cascudo virtual. Também observe o watch dog

Este mc tem calibração de oscilador? Se sim veja esta trocadilha-temporal-local-cronologicamente vizinha coincidente inquietação

Uma falsificação com erro desta magnitude é realmente bem grave. Mas tem loco pra tudo. Me lembro que vi um modo de ajustar usando a rede ac como referência. Por muito tempo guardei o link. Devo ter apagado ontem a noite ou hoje de manhã antes de visitar tua pergunta. Já que programas em assembly (iéca) podes tentar adaptar o programa daqui http://blog.larios.tecnologia.ws/iBlog/archives/2881/ que é pro 12f pro teu 16f. Mas antes, permita-me observar: ao colocar cristal externo obviamente programou o fusível para ... cristal externo, né? E claro, seu código está isento de erros, né? Ah sim, não conheço este mc... abç

Qualquer material condutor serve. P.ex. folha de papel alumínio. Se preferir 'placa' mesmo, uma placa virgem de circuito impresso (de fato duas), folha de zinco, lata de óleo, latinha de cerveja (beba primeiro), etc. Só não espere grandes capacitâncias...

um dimmer comum vai haver perda de torque em baixa velocidade. Me lembro vagamente que (há muitos anos numa era sem internet) vi um circuito em que o controle era feito com ponte e scr e o motor era controlado pelo catodo. Na época quase me consegui autoexplicar mas me pareceu que havia alguma compensação quando se exigia mais torque. Tente isso http://www.feiradeciencias.com.br/sala03/03_13.asp E se achar que deve, faça com dimmer "normal", compare e publique o resultado. Também pode desmontar uma furadeira e levantar o circuito. Publique pra alguém ver se consegue desvendar

Pois eu vivo disso kk. Se couber num mc de menor capacidade custando algumas dezenas de centavos a menos... já sabe... Com relação ao tempo, basta seguir o cronograma que você mesmo cria. Em tempo... certa feita fiz um programinha pra um mc de 1K que ocupou... 1022 bytes. Sério. Isso meio que responde minha "paranóia" kk. Algo como um rato que ruge espantou um gato. Enfim, seus (válidos) argumentos no aspecto "é mole pro gato" esfriaram minhas intenções de publicar algum resultado vindo do c. (LINGUAGEM C!). Talvez eu o faça (já o fiz no passado - preguiça de procurar) pra alguma satisfação pessoal e se me der vontade, publico pra que os amigos leitores que não programam em bascom possam ver a alternativa. abç

ok amigo. Sim minimalismo é minha filosofia De cara só por esta descrição... The subroutine waits until the EEPROM is ready to be accessed by polling the EEWE bit in the EEPROM Control Register – EECR. When EEWE is zero, the subroutine and transfers the contents of EEardh:EEard to the EEPROM Address Register –EEARH:EEARL. It then sets the EEPROM Read Strobe – EERE. In the next instruction the content of the EEDR Register is tranferred to the register variable EEdrd. ...já dá pra perceber que, de novo, há um excesso de flatulência pra pouca..." " no assembly gerado pelo seu precioso. Parece que ele faz muito mais coisa além disso. Provavelmente o que grava-lê efetivamente são aqueles 2 call's que mencionei. Manipular tais registros diretamente é muito mais eficiente né? Este é um dos pontos que onde queremos chegar. De fato, o compilador já deve ter tal função - manipula diretamente os registros. O IAR c tem pro atmega, o hitech-c tem pro pic e etc O outro ponto é a manipulação da ram, mais especificamente os 4 bytes do float. Isto tem pra todos compiladores e mc pois é nativo do c. Portanto, o pulo do gato é juntar os dois...

é sim o problema meu amigo. Vou verificar. Apagar não precisa. Penso que ele grava por hw, portanto o asm pode ser bem otimizado pelo compilador A qualquer momento dou uma verificada...

kk a do outro membro foi boa kk. Mas dispenso.. é sério! Suspeitei desde o princípio que duas linhas em bascom provocariam tudo isso! É o preço da "moleza" soft. você só no "mole" hein. (kk 2x1... esquece piadinha com hard). Mas senti muita dor sim. Os 110.130 ciclos doeram d+ em mim! E olha que nem vi a função de gravar na eeprom. Penso que de gravar é á tal Call 00ec e a de ler a tal Call D2 que também devem ocupar uns 'baita bytes'. Ok não nos importemos com isso por hora. Me fale qual mc que é este. Vou cogitar mostrar o que saí do c dele. LINGUAGEM C!!

assim você mata sua vontade. E se arrependimento matasse, o suicida morreria duas vezes! (c). Seguinte digito on line mas veja uma maneira de se ler um teclado 4x4 com um port unsigned char tecla() { unsigned char tec; TRISB=0b00001111; PORTB=0b11110000; tec=PORTB; TRISB=0b11110000; PORTB=0b00001111; tec|=PORTB; return tec; } Ou algo do gênero. A ideia é fazer um nibble como saída e capturar no outro que é entrada e depois somar os dois Como disse digitei online. Se eu achar que devo , algum dia faço alguma simulação e corrijo se for o caso. Se você achar que deve, fique a vontade...

Comentário extremamente infeliz amigo. A ideia, como não poderia ser diferente em foruns, é apenas compartilhar algum conhecimento seja de que maneira for. Doamos tempo, recursos, gastamos teclado, clique de mouse, e até arriscamos nossos empregos pra vos iluminar um pouco (mesmo que com lamparina, no meu caso)..enfim, sua alma sua palma Não seria 3º? Até aí tudo bem. Dou o braço a torcer que é bem mais simples do que o c. Mas (sempre tem um) vamos complicar? se eu fizer teste=3.141592 Como será o assembly que o compilador gera? quanto de flash ele gasta? Quantos ciclos de máquina? Ou isso está sendo profundo demais? (doeu? kk) . Penso que gravar na eeprom não é algo direto. Há uma rotina que envolve um pouco de hw interno do mc. E, claro, depende do mc. De fato isso não deve agregar nenhum valor à nossa (sadia) discussão. É só curiosidade mesmo...

Penso que um nobreak quando alimentado pela rede nem está "funcionando" ou seja "passa batido". De fato ele pode ficar entre um pouco morno e morno pra carregar a bateria. Ele só deveria mornar mais se operando pela bateria, em sua capacidade máxima e por um bom tempo. A bateria deve ser bem boa. Meça a corrente de carga da bateria. Se alta, taí a pista. Meça a V da bateria. Se baixa, idem. Se ambas, seu norte.

eu poderia até te te explicar o lance do struct union mas pra quem tá ainda na 'mamadeira' penso que vamos ter dificuldades recíprocas. E trocar fraldas não me pertende mais kk. Mas o que posso comentar é o seguinte: aquilo é linguagem 'in natura' do C. Resumindo 'union' apenas "engloba" variáveis pequenas dentro de uma grande fazendo-as ocupar o mesmo espaço de memória. Isso significa que o compilador (de verdade) vai otimizar ao seu extremo - apenas manipulando os 4 bytes de ram pra eeprom(rotina a parte). Já as rotinas mastigadas que paulão sugeriu, fica-se na dúvida. Ou seja, o mc vai sim fazer o que tem que fazer mas pode dar muitas "voltas" pela memória e pelo tempo (minha teoria) Por curiosidade 1 do 6 2 me dá um exemplo de como é gravar float na eeprom em bascom o mais 'in natura' possível

quais são suas características principais tensão corrente e frequencia?? Sabendo disso basta localizar um outro. P.ex. no site digikey ponto com

o princípio é o mesmo só que com ele opera frequencia mais alta

bem.. pelo menos pra mim isso não faz sentido. Sem variáveis definidas não dá pra resolver uma equação.. e olha que não vou com a cara da matemática isso sim parece razoável isso me fez lembrar... Um cara em experiência numa empresa fazia o trabalho de 10 pessoas. O patrão percebeu isso e demitiu os 10 ficando só com ele. "ótima economia que eu fiz!". Tal cara ficou doente e teve que se afastar. .. conclua.

pra quê mesmo comprar o novo? e o usado?

baixe o d.s. dos drivers e use a placa. A faca.. o queijo .. já sabe

pra simular melhor a bateria sugiro colocar um (uns) baita capacitor bem na entrada do celular. Pode haver pico de corrente que derruba até fonte 5V 2A. Capacitor seguraria Pode não ser muito difícil alterar a fonte 5V pra 3.9. Algo como : trocar um resistor

Me lembrei disso pois na minha infância fiz um relé "vibrar" usando os contatos n.f. em série com a bobina. Foi (de vdd) uma descoberta pessoal e 100% original. Me lembro o quanto "vibrei"! você pode elaborar algo como o funcionamento de um buzina de carro ou minha infantil vibração do relé. 100% eletromecânico. você deve pensar algo para ajustar para freq menor. Talvez um contrapeso ou algo assim

tendi nada

Taí o problema. Terminal leia-se fio do centro do cabo blindado ou naquele "buraquinho rosqueável" algo como LNB IN Ah .... e quase me esqueci.... de nada

Numa análise superficial notei isso... Se (ss-ps)=0 vai cataclismar o universo. E se não for, o resultado de frequencia sempre vai ser 0 pois ela é unsigned int -float e mc 8 bits não se dão muito bem. Mc de 8 bits trabalha em seu âmago em binário. você já ouviu falar em lógica binária fracionária? pois é.. nem eu. -Não sei se %d é a correta formatação para float (mesmo sendo, a variável não é) -printf é bem guloso. Talvez você deva formatar com sprintf ou algo do gênero. Mas de novo, rotinas gulosas. Tente p.ex. fazer float frequencia; frequencia=(float)(1.000/((float)ss-(float)ps)); e depois formatar com sprintf ou colocar o argumento correto no printf do display Seu compilador deve xiar e deve ocupar quase a metade da memória do seu mc