Felipe Electronic

Experimente fazer hard real time em um desses e veja o resultado. Processadores de aplicação (os usados nessas placas) não são adequados a processamento de informação em tempo real. So mais uma coisa, vale lembrar que o Android em si nada mais é do que uma camada de software em cima de um sistema operacional linux, assim pra que programar em java usando aquela jvm horrivel se posso programar e compilar nativo em C/C++. Isso é uma coisa que me preocupa, depois do Boom do Arduino, estão desprezando as raizes de aprendizado em sistemas embarcados, essa placa Gallileo pode ser muito mais bem aproveitada sem o uso do interpretador de sketches, o sistema operacional pode ser windows ou linux, ja existe BSPs portadas para a placa, assim eu acredito que pode ser muito mais proveitoso aprender um pouco de codigo bare-metal e explorar o port de um RTOS, e avançar para aprender a programmar usando o windows embedded ou Linux embedded. Não se preocupe @MatheusLPS, esse argumento é mais que isso, é fato, tem muita gente achando que basta instalar o motodev studio e sair programando usando bulding blocks num tablet que ele vai conseguir efetuar em tempo real um controle digital do tipo espaço de estados em um modulo de injeção eletronica de carro. É cada coisa que já vi... Também acho, visto que uma placa baseada na SoC Zynq (processador arm dual core + FPGA) está em torno de $100. Mas para avaliação e melhor, estudo profundo da arquitetura x86 (tem muita gente que fala que sabe, mas na hora de fazer um simples printf em assembly chora para salvar os parametros na pilha) Isso Matheus, brinque com o Arduino, mas de a ele a atenção que merece, existe um mundo de ferramentas e tecnologias a serem exploradas fora da plataforma. É isso. Abs.

Provavelmente o código do @mister nintendo "matou" seu problema, veja que voce esta usando como saída parar piscar LED o pino GP0/AN0, esse pino possui função compartilhada com o conversor A/D e o comparador analógico, que por padrão vem habilitados e desativam a função de entrada e saída digital. Veja que no código ele desabilita o A/D e comparador escrevendo 0x00 no registro ANSEL e 0x07 no CMCON para desligar as funções analogicas no PIC. Veja se esse é o problema atual sim. Abs.

É... um legítimo off-topic. Abs.

@rodrigocirilo, Isso faz sentido, veja que com comando acima (se bem me lembro como funciona no CCS) voce coloca o terminal do PIC como saída e ele escreve 0 no drive e o fet interno (conectados em push-pull) low side do PIC é colocado em zero, é equivalente com "curto circuitar" a saída do teu sensor de pressão com o 0[V] daí a tensão dele cair a quase zero, e retornar ao valor correto quando voce desconecta do PIC. Se resolveu, pois bem. Abs,.

Que isso, @aphawk, nos do futuro ainda gostamos de filtros SAW, inclusive ainda é preferência para fazer o filtro de seletividade de modulos de RF que operam em frequências SUB-GHz, como é o caso dos NRF24Lxx da Nordic que o pessoal do Arduino adora. E que bela linha de atraso essa hein, hahahahaah! Abs.

Ué você pode fazer o seguinte, Toda funcionalidade do Matlab é um bloco daquele toolkit ou pode ser chamado via script, voce pode por exemplo escrever um script para chamar a comunicação serial e testar ate que esteja boa, a partir dai, voce pode transformar seus dois modelos (o boost e a fotocelula) em funçõees e chama - los pelo mesmo modo. Tem só um problema, diferente do Proteus ou Matlab não faz simulação de tempo real, mas sim de background onde voce da um tempo de simulação, ele roda e te entrega os resultados, do modo que o proteus opera, no MAt, sem condições. Uma alternativa, seria modelar a fotocélula como uma fonte de tensão controlada por alguma variável externa, para isso o proteus oferece fontes controláveis, com isso voce poderia exibir os resultados com a simulação de tempo real de todo mundo rodando (vais precisar de uma maquina boa para isso), so tome cuidado, pois além disso você precisa configurar alguns parametros de simulação do Proteus senão pode causar um belo erro de convergência. E então qual das duas formas acha melhor proceder? Abs.

Token Pass é bem legal! Como na tua rede está bem definido que haverá um mestre e vários slaves, pensei em uma solução baseada em round - robin, ou seja um time slice para verificação do canal, o master pede o status e aguarda a resposta e inicia uma comunicação até o término da janela de tempo, se aainda houverem dados a transmitir, pode existir um comando de suspend para que aquele slave aguarda até o próximo scan do canal pelo master, assim todos os slaves poderiam ficar em modo low-power e so iniciariam a transmissão se fosse solicitados ao master. É simples porém robusta a solução, a desvantagem maior é que o tempo de resposta aumenta a medida que mais slaves são colocados na rede, obviamente otimizando bem a comunicação o aumento do tempo de resposta chega a ser imperceptíevel. PS.: Esses módulos da Nordic são demais, simples e com muitas funções legais por hardware. Abs.

Não sei se consideraram que a impedância de saída do sensor pode estar acima da impedância de entrada do canal de conversão A/D. Veja, que o pino de input analógico do PIC se bem me lembro possui uma impedância de entrada de 2.5KOhms, veja então que se a saída do teu sensor tiver uma impedância maior que ela a mesma vai se comportar como um divisor de tensão, onde quase todo sinal não é transferido a entrada analógica do PIC. Para verificar se o problema é esse e previnir caso não seja, sugiro que coloque um seguidor de tensão entre a saída do sensor e a entrada do PIC, tal circuito exige apenas um amplificador operacional e mais nada, modelos de uso de geral como LM358 e CA3140 servem perfeitamente para tal, aqui vai uma foto do circuito: Vin é onde deve ser conectada a saída do teu sensor e Vout é conectado a entrada do PIC. Faça o teste e veja se resolve sim. Abs.

Nunca vi nenhum bloco no simulink que permita o matlbar conversar com o Proteus. Se bem me lembro com o MPLAB você pode exportar alguns arquivos da biblioteca dsp.h do dsPIC e gerar modelos no MATLAB. Sei ainda que existe um bloco de comunicação com microcontroladores, inclusive ja fiz experiências com os DSP da Texas e funcionou legal, só não gosto do código final que ele gera. Opinião, se voce ja modelou o conversor boost e a fotocélula, não acha que ja tem material suficiente para montar algum circuito real e usar o matlab apenas para plotar os dados de funcionamento? Fiquei curioso sobre teum projeto, é algum tipo de carrregador solar com algoritmo de MPPT? Abs.

@cas888, a que nível de conhecimento precisa do livro? Se for curso técnico, o povão gosta muito do livro do CAPUANO: http://www.livrariasaraiva.com.br/produto/329320/elementos-de-eletronica-digital/ Se for engenharia, um bom livro de sistemas digitais: http://www.livrariasaraiva.com.br/produto/3534523?mi=VITRINECHAORDIC_ultimatebuy_product_3534523 Abs.

@Xisconfro, Não acreditaria em 99,99% mas em cerca de 80% dos veículos estejam preparados para tal, vale lembrar que as montadoras (em geral as locais) estão com uma mania muito feia de esconder o CANBus não o deixando disponivel no conector OBD-II na cabine do motorista. Sobre o J1939 ele não tem nada de muito novo, já é utilizado em veículos de linha pesada e maquinário agrícola a anos, inclusive esse ultimo esta migrando para um novo protocolo em cima do CAN chamado de ISOBUS. Pode contrariar, é pra isso que estamos aqui . Porém sobre o fato de ter 1 CAN-BUs, isso vale para veículos mais baratos, a medida que a complexidade cresce o busload do CAN começa a ficar muito grande provocando jitter em mensagens críticas, daí a necessidade de se ter 2 ou mais redes no veículo com um gateway para que elas se falem, é comum também que essa rede de informações críticas seja implementada em FLexRay e não CAN, informações de status concordo contigo, elas poderão aparecer sempre nas redes de baixa velocidade, em carros com sistema de direção elétrica (high - end da vida) o controle dela é feito por duas redes CAN e uma redundancia mecânica em caso de falha do sistema. A arbitração de mensagens por hardware nao possui nenhum segredo, basta estudar o drive de saida CAN-H e CAN-L junto com a posse da maquina de estados do protocolo e verás que o can possui dois bits, recessivo e dominante, o legal do CAN é o fato dele escrever no bus e ler o que escreveu para saber se pode prosseguir, no caso um bit dominante sempre que escrito no bus sobrescrever bit recessivo, assim a arbitração funciona dessa forma, se escreveu dominante, provavelmente irá ler dominante assim continua pois todo e qualquer recessivo sera sobrescrito (se isso nao ocorrer indica erro no bus), se escrever recessivo o controlador obrigatoriamente tera de ler recessivo, se ler um dominante, significa que alguem de maior prioridade esta acessando o BUS e ele fica suspenso ate que o bus esteja novamente livre, facinho não? O Bus CAN da FIat é codificado até no UNO, alguns dados vem em formato RAW é so descpobrir o fator de conversao, agora outros vem em cima de um protocolo e mais um dicionario conhecido como .dcb que pode como voce disse sser comprado na montadora. Nos Arduinos acho que da pra fazer bastante coisa, sendo mais legarl de explorar do que usando um conversor OBD-II e usar a norma para decodificar os códigos de mensagem. Eu tenho uma ferramenta da Intrepid Control Systems, baratinha e vem com um software bem legal de monitoramento, alem disso eles te fornecem as APIs para voce desenvolver um programa usando C ou LabView por exemplo para executar algum script de ações no bus do carro. Aqui eu já discordo, tanto a norma 2.0A e 2.0B devem ser sempre bem estudadas, de forma a saber o que tem em cada frame, cálculo de bus load também é outra coisa que deve ser estudada, pois existem veículos que usam o CAN para tráfego de dados multimídia, ou seja qualquer equipamento que entrar que seja mal dimensionado, pode prejudicar o desempenho da linha, outra coisa importante a saber é forma de tratamento de erros, casos em que ele fica em alerta e quando entra em bus-off (isso são todas funções do hardware). Concordo que com a explosão do Arduinho e seus frameworks botar alguma coisa para falar e espiar o CAN ficou muito fácil, mas mais emocionante é poder controlar integralmente todos os tipos de frames e saber o que ue tem exatamente dentro dele. O meu ja voa, fiz o controle de motores e consegui estabilizar o voo, agora estou revendo alguns conceitos como filtros Kalmann para fazer um controle de posição, além de rever algumas coisas de algebra 3D para a parte de filmagens to vendo que logo logo terei que estudar um pouco sobre OpenGL. Se os vidros nao estiverem uma rede LIN é possivel sim, hahaahha! Abs.

Complementando as sugestões do mestre @aphawk, caso nao encontre os 5532 (eita opamp bom sô!) pense em utilizar o LM833, são tambem de baixo ruído e tem foco de aplicação em áudio achei mais fáceis de achar ate do que o 5532. Uma coisa que gosto bastante de amplificador a válvulas é a elevada impedância de entrada, o que permite trabalhar com sinais pequeninos sem muitos estágios de amplificação. O grande problema é a alta tensão de anodo que esses caras precisam que podem facilmente ultrapassar os 100V. Mas conte nos mais sobre seu projeto, que tipo de microfone vai na entrada, o que vai na saída, essas coisas. Abs

Ao autor do tópico, o que ocorre ou o que deveria ocorrer mas nao acontece na hora de testar? Culpar a biblioteca pode ser precipitado, uma vez que todo modulo de codigo precisa ser adaptado pro projeto. Abs.

Legal esse código, usa Quaternions, pra fazer rotação 3D ainda não inventaram coisa melhor e mais a prova de "Gimbal Lock". Enfim Mercia, não sou perito em Java (Eca!) mas olhando o código de rotação ele não me parece ter problemas. Você checou se a comunicação entre Arduino e Porta Serial esta ok? Se a comunicação com sua IMU (unidade de medida inercial, chamamos assim quando temos Gyro e acelerometro no mesmo chip) está ok? E mais importante, o formato dos dados que voce fornece a interface processing é o suportado por ela? Poste aqui sua sketch do Arduino pra gente ver. Abs.

Isso eu concordo. Mas... Ja tem no circuito, esta conectado ao anodo da string de leds.

@Gabrieldlm, vou na do mestre Paulo, veja que um PICKIT2 ou 3 custa quase a mesma coisa do que gravadores desenvolvidos por terceiros e ele tem suporte no MAC usando o MPLAB X. Fora isso, nao acho que valha a pena desenvolver um driver e um programa para falar com seu gravador de forma nativa no MAC. Usar o parallels pode ser uma opção, alguns dos programas em que preciso do windows eu uso através de uma maquina virtual com o parallels. Abs.

Que belo circuito PWM, aliás um dos mais "exóticos" que já vi. Sobre funcionar no Proteus, eu imagino o que seja, é o famoso erro de conversão, isso ocorre em quase qualquer circuito que contenha um oscilador no Proteus. A solução para você simular ele é simples com o botão direito clique sobre a linha que liga o capacitor de 1n a porta inversora, e escolha a opção Edit wire label, no campo para você digitar, coloque o seguinte: IC = 0. Isso resolve a maioria dos problemas de convergência em circuitos osciladores com o proteus. Faça o teste. Abs.

Um PLL resolveria fácil o problema programando o divisor para um fator de 2, e com o uso de um VCO com saída triangular, o VCO é fáctivel com amplificadores operacionais, para comparar as fases e acertar o filtro de loop é etapa que considero mais chatinha. Outra opção seria integrar o sinal triangular, obtendo uma senóide, assim projetar um PLL seria bem mais fácil, e o sinal de saida senoidal poderia ser submetido a um comparador para obtenção de um sinal quadrado e um posterior integrador obtendo o sinal triangular. Apesar do circuito talvez ficar um pouco menor, se pensarmos em blocos, cada bloco é bem mais simples de projetar certo? Abs.

Com toda certeza não acredito, em modelos mais recentes, não existe apenas uma rede CAN, mas várias, sendo pelo menos duas delas dedicadas a sistemas críticos como ABS e Powertrain...Lembro me quando vi CAN na faculdade me expuseram um cálculo interessantissimo sobre carga de barrramentos nessa rede e o quanto isso pode atrasar uma mensagem de maior prioridade no BUS (na norma CAN mensagens com o ID menor são mais prioritárias, por hardware). Obviamente em carros mais modernos como a tua Aircross existe uma rede CAN de baixa velocidade dedicado a multimidia e sensores menos críticos. De uma procurada e vais encontrar pelo menos mais umas 3. Em modelos mais povão existe uma rede também dedicada atráfego de dados menos urgentes, só que são baseados na interface LIN PS.: Eu tenho bastante medo de mexer em rede CAN de carro francês, dada as experiências que fiz no meu antigo 206 hahahaha. Abs. Felipe

Como diz o datasheet: http://www.nxp.com/documents/data_sheet/HEF4518B.pdf Essa criança ai só conta em BCD, ou seja voce nao conseguirá valor maior que 1001 (ou seja '9'). Talvez você deseje um 4511,mas ele apenas decodifica os 4 bits da contagem para exibição no display, ainda precisaria de um contador... Faça o teste, datasheet aqui: http://www.nxp.com/documents/data_sheet/HEF4511B.pdf Em tempo, para o contador, use um 4017, e manipule suas saidas de acordo com a sequencia desejada: http://www.ti.com/lit/ds/symlink/cd4017b.pdf Abs.

O problema pode estar no monte de tensões de teste que você colocou no circuito, inclusive a C1, que está conectada ao 0V, o simulador de tempo real do Proteus possui alguns problemas de convergencia se não forem lhe dadas condiciones iniciais de funcionamento. O oscilador do seu circuito é um exemplo que pode causar tal erro. SUGESTÃO: Retire primeiro todas essas pontas de provas, teste com osciloscopio, no capacitor do oscilador (la perto da porta nand), clique no wire que que os conecta com o botao direito, e selecione a opção wire label( ou algo parecido com isso). Na caixa de texto que vai aparecer, coloque IC = 0. O que ocorre? usando essa string voce atribui que esse no do oscilador tem condição inicial com o capacitor descarregado, o que ja permite o simulador rodar sem problemas de convergencia. No caso do @Matheus_LPS o circuito pode ter funcionado pois como nao foram dadas condições iniciais, o SPICE do Proteus coloca o estado do circuito eletrônico numa condição aleatoria e essa pode estar ocorrendo justamente em condições nulas ou numericamente calculaveis, o que permite a simulação. Abs.

Veja que seu resistor está usando metade de sua capacidade MAXIMA de dissipação de potência, também conhecido como efeito Joule, fato é que a potência disspadado resisitor é feita na forma de calor, pra você ele pode estar superaquecendo, mas considerando que você beira a metdade da capacidade ele vai esquentar mesmo, em teoria, se ele for mesmo de 1W, mesmo aquecendo, não há com o que se preocupar (obviamente desprezando - se curtos e picos de corrente que possam vir a aparecer). Abs.

Deixa eu dar um pitaco: Eu iria de 3, por ser mais simples e atender de forma satisfatória, embora eficiente mesmo, seria o uso de retificação em ponte, tem até uns tópicos por aqui que explicam o porque (e ainda mostram as continhas, hahaha!). Porém o amigo já respondeu a sua pergunta: Resumindo com o material que você tem é pouco provável que consiga um bom resultado para alimentar o seu módulo, então votaria também pelo uso de uma fonte comutada, e aproveitaria esses seus capacitores gigantes os colocaria em paralelo com a alimentação do seu amp para ajudar na rejeição de ripple, e também de componentes espúrios provocados pelo chaveamento dos compoenentes internos dela. Só mais um detalhe: Todo e qualquer conversor AC-DC ou DC-DC possui ripple, por menor que ele seja ele existe e está somado com a componente contínua da fonte, ele pode ser multiplo da frequência da rede, ou multiplo da frequencia de chaveamento do comutador interno, e independente da amplitude se desprezado pode causar resultados horrendos na hora de por carga, o fato da fonte ser chaveada nao elimina a necessidade de um bom acomplamento na hora de alimentar qualquer coisa (ainda mais seu amplificador), por isso sugeri o uso dos seus capacitores grandoes ai bem pertinho da alimentação dos modulos para melhorar a rejeição a ripple e evitar os roncos. Qualquer coisa estamos ai. Abs.

Overclock no AVR é diversão gratuita, deem uma procurada no google de um cidadão que fez overclock de um Mega desses dentro de um tanque com nitrogenio liquido... 64MHz (e mais!) de pura diversão. Pelo datasheet, e olhando o modelo interno da criança, fique tranquilo, o capacitor interno é de 14 pf, fazendo porcamente a conta do tempo necessário para a carga do capacitor de amostragem (total cerca de 99%) da 1.67MHZ. Paulo, de um tempo pra cá você falando tanto de Assembly, quem te viu quem te ve Abs.

@Mercia Leite, fale nos a que nivel voce quer incluir esse CI na biblioteca do Proteus? É para simular ele? É para incluir em seu esquemático apenas? É para criar seu encapsulamento para layout? É possíven incluir sim, tal componente inclusive para simulação, nesse caso é bem trabalhoso e não creio se vale o esforço. Para as outras duas possibilidades dou ponto para o Proteus ante a outras ferramentas EDA, pois é muito fácil incluir mais componentes da biblioteca. Especifique melhor o que você quer ok? Abs.