Sérgio Lembo

80W num ambiente pequeno? 15W já ilumina muito bem um ambiente inteiro de até 20m². Como o projeto se destina a fazer iluminação decorativa nas prateleiras e funcional na mesa inferior pense numa fita com menos potência por metro. Fita RGB é de decoração, para leitura a qualidade de cor é uma porcaria. Não a considero adequada para a mesa mas a maior parte das pessoas desconhece essa parte técnica, a possibilidade RGB é mais fácil de vender, admito.

A coisa ficou num nível onde se entrega mais processamento e recursos de periféricos pelo mesmo custo. Entre um AVR de 8 bits e um ARM 32 bits que custa até um pouco menos a escolha é simples. Faz lembrar o destino dos discos de DVD com o aparecimento dos pen drives e sua queda de preço.

Com certeza vai querer utilizar o STM na sua aplicação. Para as temporizações do programa tais como delay o compilador vai utilizar o Systick da CPU ARM. Todos os outros 5 timers de 16 bits ficam à sua disposição. TIM1 e TIM3 possuem um conjunto de registradores bem interessantes. Usando um único pino de entrada (vai ter 8 para escolher, 4 no TIM1 e 4 no TIM3) o hardware vai fazer a leitura de duração do pulso para ti sem interferência da CPU e toda vez que desejar saber a rotação bastará ler o capture utilizado. O código abaixo deve ser colocado na inicialização do programa, fora do loop de controle. Basicamente o que se faz é: a cada pulso o valor é capturado e o timer resetado. Desta forma a qualquer momento bastará ler o capture utilizado para saber a duração do período. No exemplo abaixo captura o período e o duty. PWM input configuration code example /* (1) Select the active input TI1 for TIMx_CCR1 (CC1S = 01), select the active input TI1 for TIMx_CCR2 (CC2S = 10) */ /* (2) Select TI1FP1 as valid trigger input (TS = 101) configure the slave mode in reset mode (SMS = 100) */ /* (3) Enable capture by setting CC1E and CC2E select the rising edge on CC1 and CC1N (CC1P = 0 and CC1NP = 0, reset value), select the falling edge on CC2 (CC2P = 1). */ /* (4) Enable interrupt on Capture/Compare 1 */ /* (5) Enable counter */ TIMx->CCMR1 |= TIM_CCMR1_CC1S_0 | TIM_CCMR1_CC2S_1; /* (1)*/ TIMx->SMCR |= TIM_SMCR_TS_2 | TIM_SMCR_TS_0 | TIM_SMCR_SMS_2; /* (2) */ TIMx->CCER |= TIM_CCER_CC1E | TIM_CCER_CC2E | TIM_CCER_CC2P; /* (3) */ TIMx->DIER |= TIM_DIER_CC1IE; /* (4) */ TIMx->CR1 |= TIM_CR1_CEN; /* (5) */ Uma correção: para ler o duty deverá configurar o canal 2 como capture, Tl1 como sinal de entrada e borda de descida para ativação. o duty fica assim: em pseudo código, verificar no manual as sintaxes corretas período = TIMx_capture1 duty = TIMx_capture2 duty = duty*100 duty = duty/período

Com uma relação Ic/Ib = 10 não é surpresa ter baixo Vce.

Vg mínimo para esse mosfet é 4V, 3.5V é buscar caca, a coisa vai cheirar mal. Como não é caro vale a pena ter como padrão. Só faz sentido a busca de algo mais específico em escala onde alguns cents de diferença dão um bom Natal.

Mesmo que o NE555 esteja com 5V de alimentação o mosfet IRLZ44N irá aquecer menos que 1ºC com 500mA. Um canhão para matar uma mosca. Se colocar dissipador vira uma fortaleza! kkk

int: significa que o valor é inteiro, sem casa decimal, podendo ser positivo ou negativo. É um recado ao compilador de como deve tratar a variável que está sendo declarada, não gera comando no assembler. const: significa que o valor é fixo. É um recado ao compilador de como deve tratar a variável que está sendo declarada, não gera comando no assembler. short: significa que a variável declarada ocupa apenas 1 byte. É um recado ao compilador de que deve reservar apenas 1 byte para armazenamento da variável, não gera comando no assembler. MOV: Este comando está presente em controladores que usam 2 ou mais bancos de endereçamento. Vai encontrar nos PICs da Microchip, por exemplo. Supondo que queira guardar um valor no endereço 000A F5C0. Se estiver se referindo à RAM Store Se estiver se referindo ao mapa de registradores (timers, portas e outros elementos de hardware) MOV Já nos processadores que utilizam endereçamento linear por não existir duplicidade de endereços também não há duplicidade de comandos. O STM8 ou o STM32 são exemplos disso, nesses para ler ou gravar só existem Load e Store. Não há necessidade de comandos distintos pois nessas implementações a RAM, FLASH e registradores estão na mesma régua de endereçamento, sem duplicidade.

Sério? Se conseguiste fazer um programa que controla algo e que tem um feedback então usaste uma ou mais variáveis mesmo sem saber. Um simples botão conectado a um pino é uma variável. Se houver leitura de tensão, idem.Para facilitar a programação damos nomes a tais leituras e por não terem um valor fixo são variáveis. Quando os valores são fixos os chamamos de constantes. Um exemplo de constantes e variáveis trabalhando juntas: existindo um sensor de rotação acoplado na roda de um veículo o seu RPM é uma variável. Desejando converter essa rotação em velocidade, a velocidade também é uma variável. A conversão de RPM para velocidade leva em consideração o diâmetro da roda (que é fixo) e a unidade a ser utilizada (metros por segundo, km/h). Feitas as contas isso gera um valor fixo de conversão (constante). Variável velocidade = variável RPM x constante de conversão. Simples assim. Um outro conceito de variável são as locais, públicas e privadas. São muito uteis quando se se tem mais de um programador trabalhando para evitar conflitos de nomes. São fundamentais na utilização de bibliotecas. As bibliotecas nada mais são do que programinhas prontos que te entregam um resultado mastigado. Elas também utilizam variáveis próprias além das que enviaste para processamento e para evitar que a coincidência de nomeamento bagunce o programa elas são privadas, isto é, só são reconhecidas dentro delas e não haverá conflito se o programador repetir o nome. No entanto, quando se estuda as instruções de uma CPU não encontramos as variáveis. Ao invés disso encontramos umas 20 formas de manipulação de endereços de memória, seja para leitura ou gravação de dados. Já pensou que doideira se a cada necessidade de gravar ou recuperar um valor tivéssemos que escrever o endereço de memória no programa? Utilizamos as variáveis e o compilador que se vire em determinar os endereços para cada variável ou constante que inventamos. Ou seja: é muito mais fácil dar nomes para os valores do que armazenar ou recuperar os valores pelos seus endereços. Exemplo numa CPU de 8 bits que permite o endereçamento direto no programa: No programa fica: intervalo = TIM1_CH1 // Lê o capture do canal 1 de TIM1 para a variável intervalo Na CPU fica: LD R1, TIM1_CH1 // carrega no registro R1 o valor do endereço TIM1_CH1, A expressão TIM1_CH1 é substituída pelo endereço físico do TIM1_CH1. Store R1, intervalo // Grava no endereço RAM intervalo o valor contido no registro R1. A expressão intervalo é substituída pelo endereço físico da memória RAM alocado para essa expressão. Caso o programador não faça alocação do endereço de memória para a variável o compilador inventa um no momento em que a variável é declarada.

Nos meus desenvolvimentos quando possível gosto de usar uma CPU cheia de pinos, memória, recursos e coisa e tal. Nesse primeiro momento é ter algo que funcione e talvez a ideia inicial necessite de recursos extras. Conseguido o intento vou para a minimização buscando a CPU mais barata e o clock mais baixo possível. Quando é algo que pareça ser muito simples começo com a CPU barata mas esta arrogância de achar que já tenho todo o projeto resolvido na cabeça já me custou muita perda de tempo.

Os 2 modelos funcionam a contento e de forma idêntica nos pinos e forma de calcular mas nos modelos CMOS a corrente de saída é menor, esse mosfet consome muito no pico do gate. O modelo bipolar, NE555 fornece 200 mA tanto no nível alto como no baixo. Os modelos CMOS tais como LMC555, ICM7555, TLC555 possuem uma capacidade de corrente muito mais baixa. Vá de bipolar, deixe os CMOS para projetos de frequência elevada ou que drenem pouca corrente na saída.

Significa que o programador da IDE era muito melhor do que você. Estava no início, faz parte. Ninguém nasce experiente. Quando o programa se baseia em medições de tempo gosto de fazer a instrumentação na unha, me sinto mais seguro por saber exatamente como o hw irá se comportar. Nas tarefas mais administrativas do programa vou de C mesmo, mais simples.

Sobre o uso de relé: tá marcando bobeira. O mesmo circuito que habilita o relé pode ser utilizado para acionar o reset do 555. Sobre o fato da luminária realimentar seu sensor de luz (LDR). Vai ter que fazer leitura sincronizada com o PWM. São 2 as formas: 1 - desativar a leitura durante o ciclo de luz ligada e garantir que o pino de reset permaneça habilitado. A leitura de luz ambiente só será considerada durante o ciclo desligado. 2- enganar o leitor do LDR com excitação para manter o pino reset habilitado durante o ciclo ligado, uma realimentação positiva. Durante o ciclo desligado essa realimentação cai e a leitura passa a ser a real. Indo pela alternativa 2 um diodo 1N4148 com o anodo no pino 3 do 555 e seu catodo na entrada positiva do operacional. Quando o pino 3 ficar alto, ligando o led o diodo manterá o operacional com a saída alta mesmo que o LDR fique todo iluminado. Quando o pino 3 ficar baixo o led apaga, o LDR fica com seu valor dependente de outras fontes de luz, a excitação do diodo desaparece e a habilitação do pino de reset passa a ser dependente da luz ambiente. Simples assim. Só mais uma coisa: coloque um resistor de 68R entre o pino 3 e o gate desse mosfet ou o seu 555 poderá ter vida curta.

@alexandre.mbm É a diferença entre utilizar a confortável biblioteca fornecida e ter que ralar na escovação dos bits, estudando o ds de cada componente utilizado. A tendência é que na escovação se tenha maior eficiência. Essa tendência diminui de magnitude em função da sofisticação do compilador a ser utilizado. A IDE do Arduíno é boa e gratuita. Atolic e IAR são muito maiores para fazerem a mesma coisa e custam 1500 euros a cada 12 meses, se quiser.

Os problemas apontados me fez lembrar um defeito numa máquina de correção ferroviária. Equipamento grande (uns 20m) possuia 5 réguas de leitura analógica. Numa delas, onde a sensibilidade era de 17mV/mm estava dando erro. No procedimento de aferição/calibragem não apresentava problema, no campo fazia caca. O potenciômetro 360º era um luxo só, da Honeywell, 2 rolamentos, cursor banhado a ouro com ajuste de pressão e coisa e tal. Após muita dor de cabeça (2 dias) descobri que o conector DIN teve infiltração de água. A arruela mola que pressionava o miolo oxidou. A pasta de óxido de ferro contaminou o miolo que alojava os contatos. Formou um tipo de pilha, capacitor ou coisa parecida. Caso a degradação da placa ou de algum componente tenha tomado as mesmas características será um inferno permanente. Caso seu escorpião seja de estimação dê-lhe cachaça para distrair a atenção e substitua esse multímetro infiel. Se não for possível um Minipa ou Fluke até um amarelinho te atenderá melhor do que este aí.

A biblioteca ocupa espaço no seu PC mas não ocupa no microcontrolador. Quando é indicado no programa biblioteca.h isso é apenas uma referência ao compilador para pesquisar na referida biblioteca a sintaxe utilizada e ações associadas, nada mais. Somente os recursos utilizados serão incorporados e ocuparão espaço no seu programa e mesmo assim antes de serem incorporados terão que ser interpretados à luz do processador utilizado por estarem escritas em C e não em assembler. Assim sendo não faz sentido a faxina dos recursos que não serão utilizados.

Já tive esse problema por conta do HD, velhinho. A saída foi outro HD, desta vez o SSD. Como o SSD é caro para elevado armazenamento e eu gosto de baixar uns filmes fiz o seguinte: Formatei o SSD com o Windows mas com o HD desligado. O problema de fazer a formatação com 2 discos é que o Windows coloca parte do SO no segundo disco. Depois do sistema instalado no SSD é que conectei o velho HD para usar como armazenamento de grandes arquivos, no meu caso filmes. Para mim deu certo. Não se esqueça de manter o HD velho desconectado caso queira ter os 2 discos. Só o reconecte depois de instalar o SO no SSD. Boa sorte.

Complementando o post do @aphawk , aprendi que 10 mA doem, 20 mA já pode ser fatal e 50 mA é saco preto garantido. A pilha de 1,5V pode ser sentida na ponta da língua. O grande perigo é que nossos músculos se contraem na presença de corrente e se a ordem cerebral tiver intensidade menor que a da corrente externa vai ficar sem reação e em sofrimento continuado. Não se deve utilizar o corpo para verificar a presença de eletricidade mas se a curiosidade for maior que a prudência ao menos utilize as costas da mão para evitar que os dedos fiquem travados no condutor.

Se é para simular, um zener de 1.8V é o adequado. O diodo começa a conduzir a partir de +- 0.5V. Com 2 em série começa a dar condução a 1V. O led a 1,5V só dá corrente de fuga. No início, capacitores descarregados e transistores cortados, R4 carrega C3, a tensão em VC2 é zero ou quase. Ao mesmo tempo R1 carrega C2 e deste RC tem-se a definição do intervalo de tempo. Quando Vb1 consegue excitar Q1 a mágica inicia com realimentação positiva pois basta uma faísca de excitação em Q1 para disparar o processo, tal qual uma espoleta na pólvora. Quando Q1 começa a excitar Q2 a tensão Vc2 começa a subir. Ao subir através de C2 aumenta a excitação sobre Q1, realimentando o circuito positivamente e levando ambos os transistores para a saturação onde até o minusculo C1 colabora para essa centelha inicial. Como consequência C3 age como dobrador de tensão sobre o led, este passa a conduzir enquanto houver carga em C3. Com a descarga de C2 através do emissor de Q1 a realimentação positiva é cortada e começa tudo de novo. O mais incrível e crítico é a influência de C1 sobre o comportamento do piscador. Se removido o tempo de piscada aumenta significativamente mas a corrente instantânea cai, fica limitada pela polarização de R2 x hfe de Q2. Se aumentado a corrente da piscada sobe de forma assustadora.

Cabo blindado é bom. Cabo trançado também é bom. As formas de operação são distintas. O cabo blindado oferece um escudo contra as induções mas achar que nada vaza é ser otimista demais. O cabo trançado oferece uma convivência pacífica com a existência das induções pois ao trançar os fios a soma vetorial tende a zero. Quando se consegue utilizar as 2 técnicas ao mesmo tempo melhor ainda. É o que temos nos cabos de rede, pares trançados envoltos por capa metálica. Já tive experiência de cabos de rede carregarem 100Mbps num lance de 80 metros em postes da via pública. Numa experiência recente com fiação de 1 metro eu estava tendo resultados confusos. Bastou que eu fizesse apenas 5 tranças de qualquer jeito para que os resultados melhorassem de forma significativa. Cabo de rede é barato, fácil de achar e te dá essa dupla solução. Pense nisso.

Altere o resistor de 100k. Para o dobro do tempo, 200k. Para metade, 47k. Alterando o resistor de 1k há uma discreta variação do intervalo, é necessário aumentar 10x o valor para se obter 2x o intervalo mas o brilho da piscada cai junto.. Diminuindo o valor aumenta o pico de corrente sobre o led e uma pequena diminuição do intervalo. Aumentando diminui o pico de corrente sobre o led (intensidade da piscada) e um discreto aumento do intervalo. Altere-o apenas para controlar a intensidade da piscada. Se muito forte pode queimar o led.

Ler sinais baixos é sempre complicado, principalmente quando se tem muitos cm de cabo, a tal da interferência ou indução. Trance o fio de saída com o GND entre o LM35 e o Arduíno. Outra coisa: no código é usado o A0 como entrada analógica mas nas fotos o A0 aparece vazio. Não entendi.

Um microcontrolador rodando a 16MHz faz umas 15 milhões de instruções por segundo. Apesar da CPU, AVR, ARM e outras modernas executarem 1 instrução por ciclo temos que considerar que as instruções condicionais gastam 2 ciclos quando positivas. Assim sendo em 1,67ms dá para rodar umas 25 mil instruções. ou se o motor estiver a 3000RPM umas 8 mil instruções para 10º de ignição. Entenda uma coisa: seu motor é lento quando comparado a capacidade de um microcontrolador mas tem a questão dos cálculos e é aí que o bicho pega. Numa CPU de 8 bits a manipulação de qualquer número que exceda a 255 é trabalhosa. Na programação em C ocupa apenas uma linha mas quando o compilador gera o assembler o buraco é mais embaixo. No último programa que fiz no Arduíno coloquei um cálculo com float. Por achar que estava lento demais adicionei 2 comandos no programa: o primeiro colocava em 1 uma porta que estava sobrando na hora de iniciar as contas. O segundo levava a zero quando terminava as contas. O programa ficava travado no loop no momento da aquisição de dados de tempo. Olhando no osciloscópio descobri que os cálculos com float (uso de decimal) ocupavam 80% do ciclo do programa. Arduíno usa CPU AVR, tem apenas 8 bits, só faz operação rápida para número <=255. O ARM tem 32 bits, só faz operação lenta para número > 4 bilhões. É o processador ideal pára quem tem que realizar cálculos. Por exemplo: se sua necessidade é de 2 casas decimais multiplique o valor inicial por 100 e passe a trabalhar com uma unidade valendo 1 centésimo, ou seja, se seu range de valores vai de zero a 220,00 ele passa a ser de zero a 22.000 ou se quiser de zero a 220.000. Pode parecer loucura mas os 32 bits vão até 4 bilhões numa só operação, num só clock. É muito mais simples do quer trabalhar com float para o processador.

Note que a configuração do Timer1 e a captura do período estão juntas, durante o tempo em que o Timer1 fica capturando o tempo o programa fica preso no loop. Habitualmente se costuma fazer a configuração do timer na inicialização do programa mas o Arduíno é pobre de timers, as bibliotecas de tempo também fazem uso dele. Assim sendo a configuração e a tomada de tempo tem que estar contínuas sem que o programa possa fazer outras funções onde existam delay, milis ou um display que não seja I2C pois todos estes fazem uso do Timer1 para funcionar e você perderia a configuração e uma leitura válida. Feita a tomada de tempo agora você pode fazer outras coisas que venham a utilizar o Timer1. Numa leitura rápida do seu código vi pausas (delay) de meio segundo. Não é tempo demais para deixar o motor sem controle? Volto a insistir: tem uns ARM da STMicroeletronics pelo mesmo custo do Arduíno e com muito mais timers. O STM32F030F4P6 é baratíssimo e outros modelos com mais recursos custam pouca coisa a mais. Além dos timers colocados pela ST também tem mais um timer dentro da CPU para essas temporizações. Sobre você ser iniciante a boa notícia: dá para programar usando a IDE do Arduíno, não vai ter que aprender nada de diferente.

A divisão não gera decimal exceto nas operações com float. O conceito básico de divisão é quantos divisores cabem dentro do número. Assim sendo 1/2 = 0 sobra 1

Infelizmente cometi um erro no post acima. Fiz a analise 2 a 2 e não percebi que com as 3 entradas de presença em 1 a resposta será positiva. O correto é usar uma porta xor com 3 entradas ou mais. As excedentes (se houver) no nível1. Esqueça a cascata, não funciona como foi proposta.