Felipe Electronic

@Felipe_zEr0, Sobre desempacotar os bits, não tenho nada a acrescentar, pois o amigo ai de cima ja mostrou um bom caminho para percorrer. Mas porque não utiliza a recepção pela UART do seu PIC, visto que esse modelo em específico possui uma por hardware, bastando configurar ela uma unica vez? Abs.

@aphawk e @Felipe Arcaro, Como ele vai mapear essa função seno, ou seja nao só a frequência, acho sua solução plausível, pode ser um simples passa baixas, e do lado do software pode se fazer um filtro digital de media móvel, só lembrarmos, que esse tipo de filtro tende a manter seu sinal dentro da janela de amostragem que está a usar. @, A sua ideia me parece ainda melhor do que sair colocando apenas o capacitor de bloqueio DC, pelo que entendi a ideia é adicionar um offste ao sinal de entrada de forma a "rebater" a parte negativa da senoide pra cima do 0V certo? A única coisa que se deve estar atento é se o produto ganho x faixa passante do operacional é adequado a banda do sinal que esta a receber, pelo que ele disse a coisa esta centrado em 50KHz, eu não usaria qualquer LM358 pra fazer isso ai, talvez um OPA350 ou 2350 em que esse parametro é de 38MHz (e fora que é baratin e da pra pedir amostra na TI). Observando o sistema, Felipe, isso é um modelo de sistema de controle? se for isso mesmo, as soluções apresentadas, podem ser fundamentais. Está a usar que tipo de compensador? PID, lead/lag? filtro_PI digital? Abs.

Primeiramente CUIDADO! As bibliotecas desenvolvidas para Arduino são mais puxadas para C++, onde nem tudo é compatível com C, veja que eles aproveitam das capacidades de orientação a objeto oferecida pela linguagem onde até onde bem me lembro só pode ser conseguido usando um chipkit (fork do Arduino baseado em PIC) ou usando um compilador c++ para PIC32. Pelo que vi você não tem muita familiaridade com registradores (não gosta), aqui vai uma dica preciosa, comece a gostar, desprezaar a chamada programação bare metal (metal - nú) onde acessa - se diretamente memória, registradores e outras variaveis especiais diretamente, você está deixando de usar o melhor do seu processador, seja ela um PIC, seja ela um AVR, eu sei que facilidade para implementar as coisas motiva e muito, mas chega uma hora em que você terá que escrever algo seu, pois não haverão frameworks feitos para sua necessidade em específico. Agora que eu ja dei meu "mimimi" vamos ver como possso ajudar você. O sensor em questão usa protocolo I2C, esse protocolo nada tem de muito especial, veja que para começar a falar com o dispositivo voce tem que mandar apenas dois bytes de controle (comuns em qualquer tipo de comunicação I2C), dai pra frente basta enviar a lista de comandos do sensor para voce ler o que precisa. Fazer na mão evidentemente não é legal, mas sorria, o PIC em questão que você tem possui um controlador I2C por hardware, e para faze - lo funcionar basta configurar alguns registradores, vamos ao datasheet do microcontrolador para mais instruções: http://ww1.microchip.com/downloads/en/devicedoc/39631a.pdf Logo de cara vamos ao capítulo 17, no periférico MSSP, ele é quem faz o PIC se comportar como um transceiver I2C, agora vamos ler um pouco sobre o que precisamos para fazer um byte ser transmitido por essa interface, Os sinais, segundo a especificação I2C, são basicamente 2, SDA (Serial Data) e SCK (Serial Clock). Veja que logo no começo do capitulo do datasshet vemos que esses pinos sao RC3 e RC4. Logo de cara, configure esses dois pinos como entrada (exigido para a I2C funcionar). no seu codigo, inclua o arquivo de mapas dos registradores do pic: #include "p18fxxx.h" E para configurar os pinos RC3 e RC4 como entrada basta deixarmos seus bits em 1, no registrador TRISC, ainda com medo de escrever em registradores, veja que fácil é fazer isso no PIC: TRISC |= 0x18; //equivalente a 00011000 bits 3 e 4 setados Otimo, os pinos ja estão prontos para operar como I2C, agora so precisamos controlar seu dispositivo para trabalhar como I2C master, suportado por nosso PIC, veja o procedimento segundo o datasheet: precisammos alterar SSPCON e SSPSTAT vamos primeiro desligar o I2C para configurar, derrubando o bit SSPEN (pagina 174) SSPCON = 0; //é o bit numero 5, vamos desligar ele e todos os outros. Agora vamos acertar os parametros da nossa I2C: //Seta I2C para modo mestre: SSPCON |= 80 ; apenas precisamos setar o bit 3 do registrador //baud rate de teste, 100 KHZ @ 4MHz: SSPADD = 0x09; //a conta sugerida no datasshet para essa velocidade é 9. //I2C configurado zera status registter; SSPSTAT = 0; E finalmente escrevrmos 1 no bit 5 (SSPEN) e o I2C esta pronto para operar. SSPCON |= (1 << 5); Podemos transformar isso numa funcao certo? Que nem no Arduino, veja que legal: void I2C_vInicia(unsigned long clock){ //RC3 e 4 sao entradas TRISC |= 0x18; //Desliga I2C SSPCON = 0; //Configura para modo I2C mestre; SSPCON |= 0x80; //computa a taxa de comunicacao de acorcom o com clock em Hz SSPADD = (4000000 / (4 * clock)) - 1; //Zera registrador de status: SSPSTAT = 0; //Tudo pronto, podemos ativar a I2C SSPCON |= (1 << 5);} Simples não? ta mas agora voce deve estar se perguntando, como faz para transmitir? simples, basta colocar um dado em SSPBUF transmitir e checar por ACK e Erro no registrador SSPSTAT, veja a funcao: void I2C_vEnviaByte(unsigned char Byte){ //coloca o dado no buffer: SSPBUF = BYTE_CTL; //byte de controle definido por voce, deixo como exercicio // voce pesquisar //admitimos nesse ponto que a I2C nao tem mais nada a transmitir, gera start: //Usando o registrador SSPCON2: SSP2CON |= 0x01; //Aguarda o dado enviar: while(SSPSTAT & 0x01); //checa se houve ack: if((SSP2CON & (1 << 6)) > 0) return; //deu erro, trate se necessario //se recebeu ack, enviamos o nosso byte: SSPBUF = Byte; //Aguarda o dado enviar: while(SSPSTAT & 0x01); //checa se houve ack: if((SSP2CON & (1 << 6)) > 0) return; //deu erro, trate se necessario //Gera stop e libera o bus; SSP2CON |= (1 << 2);} O processo para leitura é similar e análogo... escrevi essas funcoes apenas com o intuito de te ajudar a mexer nos registradores lendo um pouco do datasheet... De resto, a leitura do protocolo I2C, veja esse artigo em portugues: http://www.eletronica.org/modules.php?name=News&file=print&sid=13 é bem simplorio, mas serve de base para leitura de artigos mais complexos Acha que consegue andar a partir daqui? Qualquer coisa grita. Abs.

Puxa, usar um AD9850 para gerar uma senoide de 50KHz máximos é quase como matar uma formiga com uma bazuca... o Próprio Arduino poderia fazer isso. Aqui vejo duas formas para voce resolver seu problema, de forma digital, basta passar essa senoide por um comparador de tensão (no caso um comparador de zero já resolve) e você obterá um sinal quadrado. Para ler a frequência dessa forma, você simplesmente mede o intervalo entre duas bordas de subida, a inversa desse periodo é a frequencia da tua senoide. Em termos de código vou deixar como exercicio e pros fans de arduino, como se usa timer nesse caso. De forma analógica, voce pode utilizar o conversor A/D do Arduino, usando a função AnalogRead(Canal), porém não faço ideia da taxa de amostragem usada no conversor, que teoricamente deveria ser de pelo menos 100 mil amostras por segundo, enfim se optar por essa abordagem basta implementar o comparador de zero por software e medir quanto tempo o sinal leva para passar por dois zeros consecutivos, novamente a inversa desse periodo é o valor da frequencia da senoide. Só Lembrando que: Frequencia(Inversa do Periodo) = 1 -------------------- Periodo Abs.

Vou olhar os arquivos, e logo posto uma resposta. Abs.

Bem essa mensagem pelo menos indica que o boot não é tão "burro". Parece que caso o código fique na área do bootloader, ele simplesmente não grava este, bom sinal Essa é a parte mais bizarra, mas me deu uma ideia, como você está a usar o código do mikrobootloader, porque não experimente desenvolver esse mesmo pisca LED no mikroC, não estou sugerindo ele como ferramenta, mas apenas para eu ter certeza do problema. Isso, se possível zipar essa pasta de arquivos e postar aqui Abs.

Eu combinaria as duas técnicas para ter o melhor desempenho. Usando o Debounce por SW você tem repetibilidade da filtragem do sinal do botão. Usando o Debounce por HW (resistor + capacitor) você reduz o tempo de delay no Debounce por SW e deixa o PIC por menos tempo parado. Veja uma forma de fazer o debounce de um pino do PIC com botão ativo em 0[V] : Simples não? Abs.

Hummm complicado isso hein, eu pensei que essas soluções a base de HID bootloader tratassem esse problema para o usuário iniciante apenas se preocupar em primeiro aprender Enfim, antes de resolver esse problema talvez seja interessante ver onde o linker está alocando a área de código, para tal, que tal por aqui no forum TODOS os arquivos da pasta de projeto? Sabendo onde esta colocando talvez possamos resolver o problema simplesmente alterando algumas linhas no linker-script da ferramenta que está usando para desenvolver o código Ficamos no aguardo do seu retorno. Abs.

Esse electronica.pt é bem legal, é site quase do tipo : "Se não acha aqui é porque não existe." Ahahahhahahah! Abs.

@, sei que está iniciando nesse campo da eletrônica, e quando estamos nele, queremos aprender uma grande quantidade de coisas de uma vez, mas vá com calma relaxe, entenda uma coisa de cada vez. Falo isso pois ví alguns posts seus aqui no forum, e percebo que suas dúvidas ou estão muito vagas, ou estão muito amplas, seja um pouco mais específico no que quer entender, assim os veteranos aqui do site (incluindo uns amadores feito eu) irão lhe ajudar com o maior prazer e muito mais eficiência, ok? Abs.

Se o ganho entre os estágios do transistor não for um fator crítico de projeto, acredito que o uso de similares como o BC556, ou mesmo BC557 sirvam perfeitamente a aplicação, vou te deixar como exercício, compare por si próprio seus datasheets, seguem o link de datasheet da família: http://www.fairchildsemi.com/ds/BC/BC556.pdf Abs.

Depende muito do carro, mas no geral informações que o fabricante esconde e cobra carissimo por um acessorio (computador de bordo do Fox novo por exemplo) podem ser extraídas dai, o CAN em si é um senhor protocolo de comunicação, extremamente robusto, a parte chata é decodificar as mensagens e descobrir o fator de escala para dados analógicos ex.: Combustivel, velocidade. Pelo CAN? Difícil hein, esse tipo de dado geralmente não trafega pela rede CAN, muito menos se o carro só tiver uma, e outra, é pouco provável que voce consiga atuar sobre o veículo (acelerar o carro por ai com celular) além do CAN, os fabricantes implementam mais uma camada de protocolo por cima que eles nunca divulgam (nada que um sniffer e um pouco de paciencia nao resolvam), além do mais dados de segurança nessa rede costumam estar bem criptografádos. Se queres acionar alguma coisa no seu veículo terás que dar uma olhada e encontrar suporte do veículo a uma rede secundária para perifericos que geralmente roda em LIN (ela é bem menos complexa que o CAN, mas exige estudo). Curte um UAV? então acho que vai gostar disso: https://www.edx.org/course/tumx/tumx-autonavx-autonomous-navigation-1658 Mais um da FEI, ahahahahhaha, o forum ta ficando requisitado Fomento no Brasil é política...vejo isso todo dia na USP, minha morada atual...da desgosto ver tanto projeto bom acabar na gaveta, e um monte de besteira patrocinada porque tal aluno ou tal professor se dao bem com a reitoria. Esse projeto do CAN realmente me interessou Abs.

É isso que desejas? http://www.americanas.com.br/produto/5971206/caixa-de-som-multimidia-usb-preto-bright Acho mais produtivo pagar R$24,00 em uma, pois o estudo envolvido para montar uma dessas do zero é extenso Abs.

Só um alerta, é interessante colocar em paralelo com a bobina do relé um diodo reversamente polarizado (ou seja catodo ligado a fonte e anodo ligado ao coletor do transistor. Essa precaução reduz a chance de destruição do transistor quando ocorrer a comutação do relé (momento em que é gerado força contra-eletromotriz). No mais o circuito é basicamente o apresentado. Segue abaixo uma versão mais completa que vi a muito tempo, mas funciona incrivelmente bem; http://www3.eletronica.org/projetos/interruptor-eletrônico-controlado-por-som Abs.

Existe um pequeno problema... o PIC em geral possui 1 canal de saida PWM, 3 no máximo, porém se bem me lembro não da pra utilizar os três módulos CCP ao mesmo tempo no mesmo modo (ou seja os três em PWM). Eu tenho uma nota de aplicação bem antiga da Microchip, que ensina a fazer PWM por software em PICs pequenos exclusivamente para Leds RGB, mas ja vou adiantando, terá que ler o documento de ponta a ponta, segue o link do PDF: https://drive.google.com/file/d/0ByfGO_ITCy2tVk1oODc0NHZvNTg/edit?usp=sharing Em caso de duvidas poste de volta. Abs.

Desculpe o flood, mas quase esqueci, @Projetos_afg , Compilar o Arm_gnu no Linux e integrar ele no eclipse não rola? É a solução mais sólida que conheço (e pessoalmente estou usando a alguns anos), da um pouco de trabalho, mas você faz somente uma vez? segue o link do arm_gnu: https://launchpad.net/gcc-arm-embedded Plugin para integrar ele com eclipse + suporte a micros da ST (acho que Freescale também): http://gnuarmeclipse.livius.net/blog/ E a ultima versado do Eclipse for C developers: http://www.eclipse.org/cdt/ Acho que vale a pena dar uma olhada Tem passo a passo aos baldes na net. Abs.

@Projetos_afg , Essa plaquinha é a discovery oficial da própria ST, eu tenho uma dessas, e o micro é fora de série, um M4F de 168MHz, porém vou encher ainda mais olhos de vocês com a minha mais recente (e barata!) aquisição, a discovery pro f429 (esse chega a impressionantes 184MHz!): http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF259090 Custa 24 dólares em quase qualquer lugar... estou rindo a toa com esse LCD e os 8MB de memória externa Sobre o OPenSDA no linux, ja tentou faze - lo funcionar como client gdb junto com o OpenOCD? Hoje tenho uma IDE baseada no Eclipse + GCC rodando no meu MAC de forma nativa, compilei o OpenOCD e ele comunicou sem problemas com os principais debuggers que tenho: TI_ICDI, STLink entre outros Segue o link, veja se o OpenSDA ja é suportado: http://openocd.sourceforge.net/ Abs.

@Projetos_afg, e demais, Eu particularmente gosto de outros micros da Freescale (S12X e os baseados na arquitetura power E200z), pois esses possuem notas de aplicações bem detalhadas, diagramas funcionais e o principal, software desenvolvido de forma bare metal, ou seja sem abstrações é atuação direta com hardware do microcontrolador, isso ensina muito mais do que forncer frameworks e apenas exemplos usando uma ferramente de confuguração gráfica (parece que o conceito de time to market esta tão forte que estão desconsiderando que conhecer sua máquina é essencial para manter esse "market"). O ecossistema de microcontroladores ARM da Freescale (familia Kinetis) deixa muito a desejar, eles possuem esse kit chamado de freedom board e se contentam com o fato da disposição dos pinos ser compatível com Arduino, ok, mas nem todo mundo quer ficar eternamente nos shields do Arduino...é diferente do ecossistema launchpad criado pela Texas, que fornece a placa com processador a um preço baixo, mas fornece diversas placas perifericas e preços excelentes, alem de um fork próprio do Arduino. http://www.ti.com/ww/en/launchpad/boosterpacks.html O link acima leva para uma pagina com todos launchpads e boosterpacks. Na mesma linha de raciocinio, a ST também está indo por esse caminho, fabrincando periféricos para sua stmdiscovery, afim do entusiasta nao ficar só nos leds. Ambas as fabricantes, ST e TI estão provendo muita documentação, seja pro kit ou prochip especifico que vai no kit, desde datasheet até manual de programação, isso acelera o que chamo de aprendizado com qualidade, não é muito melhor conhecer a arquitetura do chip e projetar tudo a seu gosto do que ficar contatando a fabricante para prover suporte quando o framework nao atende? Sobre o tutorial também estou doido pra ver os textos projetos, em especial a documentação que voce fez sobre a Freedom Board, aproveitando, voce teve algum problema para usar o OpenSDA? Abs.

Isso parece muito problema no PIC a ser gravado. Veja ele reconhece o micro, apaga a flash, mas na hora de escrever ocorre o erro...lembra problema de endurance (os blocos de memória estão quaaaase no fim de vida e ja nao gravam mais direito). Como teste, coloque o mesmo PIC, tente ler a memória flash e veja se ele conseguiu realizar a operação corretamente. Além disso faça mais dois testes, sem carregar o .hex, faça o apagamento da memória e use a opção blank check, veja se a operação também retorna sucesso. Abs.

Em geral, via de regra os pinos usado para gravação do microcontrolador devem ficar apenas com essa função, afim de não "bagunçar " os tempos de comunicação com a ferramenta de programação e o processador alvo (o que vai na placa). Entretanto, se precisas desses pinos e nao tem como fazer outra solução (expansor de I/Os, multiplexação de pinos), segue o link para o manual de programação ICSP da própria microchip, veja as páginas: 21 e a partir da página 198. http://www.elnec.com/sw/30277d.pdf Abs.

@ e @Matheus_LPS... Pra vocês que ja vem de brincadeira a fundo com micros de 8bits explorar o núcleo de 32bits não será de tão grande novidade. Sobre as placas, e opinião pessoal, eu não começaria pelos micros (ARM) da Freescale, documentação deixa muito a desejada, a fabricante só fornece device drivers e afins sob o uso do horrendo processor Expert, que era muito bom quando tinha o componente de inicialização de hardware para configurar fonte de clock e watchdog por exemplo, até ela remove - lo deixando aquele gerador de código inútil. O bom das Freedom realmente é o preço, apesar que kits de avaliação pra ARM está bem cheio, eu tenho preferência pelos micros da ST: http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF253215 Os chips são baratos, e vem com mais periféricos (úteis) que os Freescales baratinhos. Se forem usar o mbed para iniciar (só não gosto do codigo final que ele gera), vejam a stm núcleo (10 doletas!) http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/LN1847 Essa é nativamente compatível com o mbed (juntamente com as LPCExpresso). Divirtam - se, o mundo dos ARM é divertido, oferece um mundo de possibilidades, e formas de programar, hoje estou envolvido em dois projetos, bem legais, um sistema operacional de tempo real para microcontroladores (esse ja ta pronto!) e um quadcóptero, e ter uma máquina dessas ajuda bastante (embora o controle de motores eu use um DSP de 32bits para fazer o serviço sujo). Divirtam - se e contem comigo pro que precisar. Abs.

O compilador em C pra PC é o mesmo usado em arquitetura embedded, a unica grande diferença é que o resultado do código gerado é otimizado para x86 / x64 ou processadores usados em Desktop, não confie em mim, compile algo no GCC para PC e verás que o código objeto gerado não possui nada de especial. Essencialmente não existe diferença em desenvolver usando C (ou quaquer outra linguagem) entre embedded ou PC, a grande diferença no caso será a forma como o código será executado, seja bare metal ou com um operacional, veras que os códigos são o mesmo essencialmente mudando a forma de acesso, com um SO você costuma fazer o linker do codigo dinamicamente mas é perfeitamente possivel fazer de forma estática (ou seja um push dos principais registradores e contexto do sistema, seguido do branch da area de codigo onde esta localizado o codigo que voce compilou). E sistema operacional padrão, todo OS é padrão possuindo pelo menos kernel e alguns serviços de sincronização (Semaforos), compartilhamentos (Mutexes), e serviços de comunicação intertarefa como filas. No caso do windows a unica coisa especial é que seu sistema é baseado em orientação a eventos, método perfeitamente implementavel até em micros de 8bits. O problema não está na linguagem C em si, mas em como o compilador vai se virar para reproduzir o codigo escrito em C11 num microcontrolador, o assembly que ele gera nunca será padrão mesmo... até mesmo o linker nunca aloca as variaves da mesma forma apois dois builds sucessivos, no caso de CCS e mais alguns eles nao seguem ANSI justamente porque nao querem ou seus compiladores nao foram feitos pra isso. Infelizmente se isso fosse frase feita, não teríamos carros da Toyota por exemplo acelerando sozinhos... Codigo limpo e bem estruturado deveria ser unanimidade em qualquer lugar (inclusive o ensinado nas escolas)...desde o hobbysta até o estudante de doutorado, e veja quando falo em codigo bem estruturado não falo em técnicas de abstração, ou orientação a objeto, falo em iniciativas simples, funções pequenas, código modular, portável. Até mesmo um botão como o problema do autor do topico pode ser resolvido com uma solução bem feita, no caso uma maquina de estados, que o colega @Matheus_LPS entendeu o principio da coisa e fez algo simples, bem feito e agradavel aos olhos de quem vai pegar pra ver. O amigo @aphawk entendeu rápido o que fiz naquele código em Assembly, nao so isso como otimizou o codigo ao gosto dele e recuperou o prazer de fazer alguns trechos de código em assembly. Codigo comentado e modularizado é bom em qualquer lugar, codigo sujo é coisa de velho (sem generalizações) que não quer fazer algo visível aos olhos da equipe pois acha que sua ideia sera "roubada". Abs. Felipe

@vtrx Pegue a rotina de divisão gerada pelo IAR ou pelo Keil para PIC e compare com a gerada pelo C30, ou melhor pegue a mesma rotina de divisão gerada por um desses caras e a mesma gerada pelo code warrior, code composer studio para processadores ARM por exemplo e veja o quao são bizarros, veja o c[odigo bonito gerado por projetos baseados nos projeto LLVM. Esse negócio de o fabricante faz melhor nem sempre é verdade, uma boa industra de semicondutores pode não ser boa em algoritmos, analise léxica e sintaxe na hora de desenhar um compilador Outra frase feita, veja que existem soluções baseadas em GCC ou no projeto LLVM, ambos seguem a terceira revisão do padrão ANSI que é o C11, para a maioria dos núcleos, sejam eles 8 ou 32bits são justamente a a ferramenta adotada por fabricantes de chip, além disso as próprias ferrametas ja possuem checagem de código para verificar se além do padrão você codifica de forma limpa e segura segundo regras como o MISRA-C...então generalizar dizendo que compiladores são adaptações da linguagem C é no mínimo estar por fora do que está sendo feito. O grande e maior problema desses compiladores são na fase de desenvolvimento que é prover a LibC e a STD (alem da STL para C++) bem implementadas e otimizadas para o núcleo para seguir a revisão corrente da norma ANSI. Exemplo, tente fazer um strncpy, um memset, ou mesmo um memcpy usando a LibC em um micro, e tente escrever na mão e verá o trabalho que tera para obter desempenho similar. Fato não digo que não existam adaptações como o CCS e o MIkroC, fato elas existem nao respeitam a norma ANSI, mas daí dizer que todas as ferramentas para desenvolvimento embedded são assim também não da... Realmente o xC tem alguns erros nojentos! ja vi coisas grotescas que fazem ele parecer o CCS, simplesmente nao oferecia suporte a ponteros de função (no PIC24!) . Mas isso é como disse antes, fase de desenvolvimento o xC ainda não está maduro, fora que deve-se lembrar que ele é uma gambiarra entre o Hitech e o C30/C18. Em compensação eu adorei o desempenho do C32, ja programei em núcleos MIPS e sempre vi o GCC trabalhara muito bem na hora de gerar o código final (embora eu prefira fazer algumas coisas em assembly), mas com o MIPS do PIC32 junto com xc32 a coisa ficou legal, implementei um filtro digital FIR de 16 posições e ele fez um codigo limpo e enxuto de 6 linhas. Isso sempre vai ocorrer, faz parte de toda discussão, afinal em um desses debates é de onde brotam ideias para resolver seu problema de mais formas, em todo caso, qual foi o resultado do codigo proposto pelo colega @Matheus_LPS. Confesso que estava com saudades desses debatees no fórum. Abs.

nossa! Leitura de touch capacitivo usando I/O digital, essa técnica é bem versátil, é tanta solução pra touch-capacitivo hoje que fazia muito tempo que não via uma. A boa noticia funciona sim! Para qualquer microcontrolador, a má noticia você vai ter que ajustar os tempos que dependem inclusive da constante de tempo da placa capacitiva que servira de botão. E além das duas funções providas eu optaria de fazer o escaneamento da tecla de forma periódica (usando um bom timer com interrupção pra isso, inclusive para detectar o pressionamento) porque sinceramente delays estão bem fora de moda. Em vez de usar um I/O digital comum, você poderia fazer algo ainda mais elaborado e sem canal A/D, veja que esses modelos de PIC não possuem A/D mas pelo menos o 628A (quem usa pic16f84 atualmente?) possui um comparador analógico de tensão que é bem mais versátil pra essa aplicação, além disso a tensão de referencia do touch poderia ser ajustada para o valor que voce quisesse usando o PWM da saida com um filtro passa baixas conectada a entrada inversora dele. Enfim, são idéias e mais idéias Abs. Felipe

@aphawk Então você vai concordar comigo de novo, hahahaha! Sempre que me refiro a C me refiro a norma padrão ANSI, no caso a mais atual revisão que é o C11. Veja entendo sua posição não de ser contra C, mas sim contra implementações "estranhas" de C, esse é o mesmo motivo pelo qual abomino o CCS e até mesmo o mikroC, possuem implementações a sua maneira, com tudo que interessa sendo abstraído do usuário...Nem mesmo do Arduino eu gosto nesse ponto embora o padrão C++ dele esteja muito bom. Aqui eu já discordo em partes, veja que os formas diferentes de fazer as coisas eu defendo no ponto de implementação do usuário, e é isso que torna a linguagem C tão poderosa, é o fato dela te dar certo controle da tua máquina, e possuir várias formas de resolver um mesmo problema, posso acessar vetores por exemplo atraves de ponteiros, ou usando indexação.... A parte de estruturas de dados muito desprezados até por quem nao deveria (leigos e entusiastas) é facilmente implementavel em C, inclusive tópicos de orientação a objeto, pra que apenas desenvolver programa procedural para resolver um problema se posso trabalhar com objetos mais próximos a minha linguagem natural humana, ou mesmo trabalhar em modo multitarefa...veja que uma lista de tarefas de um sistema operacional como o Linux por exemplo nada mais é que uma estrutura hyper básica conhecida por lista ligada, onde em C é simples de fazer e intuitiva... Diante de tanta coisa bem feita que já vi em C eu não consigo concordar que C é difícil ou mesmo complicado, acho que como toda e qualquer ferramente tem uma curva de aprendizado que pode ser maior ou menor em função de quem quer aprender. Veja que no caso do ASM, tambem tenho certeza que os comentarios (adequados) ao código te ajudaram e muito a compreender o que estava a fazer sem ler a instrução antes. Como toda e qualquer linguagem, codigo bem escrito, limpo e comentado na medida ajuda e muito na hora da manutenção e na hora de entregar seu projeto a um terceiro, mais um motivo pra discordar a dificuldade. Sobre a duvida do autor do tópico, fico com o Matheus, reformula a pergunta ai...hahaha. Abs.