Projetos_afg

Quando eu tiver um tempo livre posso tentar montar um circuito modulador por fase com alguns amplificadores operacionais para RF, não me parece algo muito difícil, mas vai requerer alguns cuidados na montagem e seleção dos componentes. Em RF nunca se usa uma modulante que não seja senoidal! No caso da televisão estamos nos aproveitando do fato dela ter um filtro passa baixas e só usar uma banda para o sinal colorido, funciona mas não é o jeito certo. Utilizamos a onda senoidal como modulante pelo fato de ser uma onda "pura". Ondas quadradas, triangulares, dente-de-serra, etc, na verdade são compostas de uma soma infinita de ondas senoidais de frequências múltiplas da frequência fundamental: No caso do 4QAM digital (ou 16QAM, 64QAM ...) a fase e amplitude são alteradas em valores discretos, gerando um diagrama mais compreensível: Já o analógico a distribuição não é discreta mas uniforme:

O burst pode ser uma onda quadrada, a televisão tem um filtro passa baixas que vai atenuar bastante as harmônicas transformando a onda quadrada em senoidal. Você vai precisar basicamente de um conversor D/A (pode ser feito com resistores) para gerar o sinal e conseguir variar a amplitude do sinal das cores. Acredito que sua maior dificuldade é não ter um fundo em radio frequência para entender como funciona a modulação 4QAM analógica (o 4QAM digital é bem mais simples de visualizar).

Com um PIC18 isso não é possível. Nunca vi nenhum projeto utilizando PICs 18/16 gerando video colorido sem auxílio de algum hardware externo para isso. Encontrei um projeto fantástico que utiliza um AVR para gerar o sinal PAL colorido: http://www.linusakesson.net/scene/phasor/index.php O AVR tem uma grande vantagem por ter um set de instruções bem mais poderoso, 32 registradores de uso geral (o pic só tem o W) e acesso à memória de forma linear sem troca de bancos / páginas.

Isso você usa uma tabela pronta com as unidades adequadas. Calcular em tempo real seno e coseno com o PIC demoraria dezenas de milisegundos. Mas gerar um sinal de 3,58MHz mesmo sendo em onda quadrada para o 'color burst' já é complicado com o PIC. Você precisaria fazer um overclock de 14.328224 MIPS e mesmo assim não daria tempo para um loop: ;Cristal = 14.328224MHz;PLL = x4;Gera uma onda quadrada de 12 ciclos a 3,58MHzbsf PORTx, ynopbcf PORTx, ynopbsf PORTx, ynopbcf PORTx, ynopbsf PORTx, ynopbcf PORTx, ynopbsf PORTx, ynopbcf PORTx, ynopbsf PORTx, ynopbcf PORTx, ynopbsf PORTx, ynopbcf PORTx, ynopbsf PORTx, ynopbcf PORTx, ynopbsf PORTx, ynopbcf PORTx, ynopbsf PORTx, ynopbcf PORTx, ynopbsf PORTx, ynopbcf PORTx, ynopbsf PORTx, ynopbcf PORTx, ynopbsf PORTx, ynopbcf PORTx, ynop Esse sinal nunca foi visado para ser emulado por software. Use um dos CIs que sugeri e sua vida ficará bem mais fácil!

Sim, a unidade de tempo é a mesma de cada pixel da imagem e ela vai depender da resolução do sinal de vídeo.

Esse sinal indica a que em cada linha de varredura você deve defasar a componente "V" em 180º em relação á anterior. Isso é necessário no PAL para evitar que ocorra erros cumulativos na sincronia do sinal (o NTSC originalmente tinha esse problema, o PAL usou essa técnica para resolve-lo, nas televisões NTSC novas isso não acontece mais). Exemplo: 1ª linha: S(t) = Y + U*cos(2*π*FM*t) + V*sin(2*π*FM*t) 2ª linha: S(t) = Y + U*cos(2*π*FM*t) - V*sin(2*π*FM*t) O autor afirmou que não conseguiu encontrar uma forma elegante no software para gerar essa defasagem, já que o sinal Y também teria que estar em fase com as cores. Acabei encontrando 4 CIs que já codificam os sinais em PAL: http://www.cirrus.com/en/pubs/proDatasheet/CS4954-55_F6.pdf http://www.nxp.com/documents/data_sheet/SAA7108AE_SAA7109AE.pdf http://www.analog.com/static/imported-files/data_sheets/ADV7174_7179.pdf http://www.eecg.toronto.edu/~tm3/ad722.pdf

Dei uma lida no pdf que indiquei. Entendi que sobre o sinal de vídeo em preto e branco é adicionado mais um sinal com uma modulante de 4.43 MHz (no Brasil utilizamos o PAL-M que usa uma modulante de 3.58 MHz) que transporta a informação de cor utilizando o esquema de modulação 4QAM analógico. O 4QAM significa Quadrature Amplitude Modulation que utiliza a modulação por fase combinada com a modulação em amplitude para a transmissão de informações. O 4QAM permite transmitir permite transmitir 2 bits por Hz (digital) ou 2 sinais diferentes (analógico) conferindo assim uma boa eficiência espectral. No começo da varredura de cada linha do televisor é enviado um sinal de sincronia para que o oscilador interno da televisão esteja em fase com o oscilador do dispositivo que está gerando o vídeo: É dessa forma que o televisor consegue perceber a defasagem dos sinais. Com o sinal em preto e branco e as componentes R - Y (vermelho - luminância) [V] e B - Y (azul - luminância) é possível reconstruir as cores RGB. No sinal PAL a luminância (preto e branco) pode ser calculada por: Y = 0.222R + 0.707G + 0.071B Então para convertermos uma imagem RGB em suas componentes Y, U e V podemos utilizar a seguinte matriz: ┌ ┐ ┌ ┐ ┌ ┐│Y│ │ 0.299 0.587 0.114 │ │R││U│ = │-0.147 -0.289 0.436 │ * │G││V│ │ 0.615 -0.515 -0.100 │ │B│└ ┘ └ ┘ └ ┘ O sinal gerado pode de imagem para cada linha pode ser gerado com a seguinte função: S(t) = Y + U*cos(2*π*FM*t) ± V*sin(2*π*FM*t) Em que FM é a frequência da modulante e t é o sinal no domínio do tempo. Você pode observar nessa função o sinal ±, isso é devido ao PAL (Phase Alternating Line) precisar que um dos sinais seja defasado 180º (o color burst precisa ser defasado em 90º) em cada linha em relação à anterior. O autor utilizou o microcontrolador SX rodando a 50MIPS para gerar um sinal com cores somente por software. Acredito que nessa parte seja necessário fazer em hardware para ter uma boa resolução e não exigir um microcontrolador poderoso dedicado somente para essa tarefa.

@Vicente Cesar Consegui apenas desenhar uma linha na tela, mais nada! Você conseguiu muito mais do que eu. O que andei pesquisando recentemente foi o protocolo VGA que é muito mais fácil de se usar. Usei um FPGA como controlador de vídeo, mas o projeto está incompleto e estou cheio de coisas para se fazer nesse final de ano!

Por volta de 2010~2011 eu estive procurando como gerar sinais de vídeo composto com um PIC16. Lembro-me de ter encontrado um site muito bom sobre o assunto. Hoje não encontrei mais esse site, mas encontrei este PDF que foi escrito pelo mesmo autor: http://elinux.org/images/e/eb/Howtocolor.pdf Apesar do autor afirmar que não conseguiu gerar sinais no padrão PAL (só teve sucesso com o NTSC) ele explica muito bem como funciona a geração desses sinais. Edit: Encontrei o site no web archive: http://web.archive.org/web/20140209113630/http://www.rickard.gunee.com/projects/video/sx/gamesys.php

Lembre-se que o clock do PIC sempre demora 4 ciclos de clock para executar a maioria das intruções. Se você têm um PIC16 com um cristal de 20MHz na verdade ele está executando 5 milhões de instruções por segundo. No caso do PIC18 a maioria dos modelos têm um PLL interno para multiplicar a frequência do cristal. No projeto que o @vtrx postou o cristal do microcontrolador é de 12MHz, mas o PLL interno multiplica por 4 e resulta em 48MHz, como o PIC precisa de 4 ciclos para cada instrução então nesse caso ele executa 12 milhões de instruções por segundo. Vi que o 6502 demora entre 2 e 7 ciclos de clock por instrução dependendo do endereçamento utilizado, o que parece dar uma boa margem de tempo para um PIC18 emular o binário, desde que você consiga ler rápido o suficiente da memória RAM externa (não encontrei nenhum PIC18 com mais de 4KB de RAM interna). Pelo que entendi esse atari tinha um processador de vídeo, acho difícil você decodificar as instruções e gerar um sinal de vídeo em tempo real somente com um PIC18. Volto a dizer que não dá para utilizar um pendrive com um PIC18. Nenhum modelo dessa família tem USB Host, somente USB Device. Use um cartão SD que é tranquilo de interfacear (utiliza o protocolo SPI).

Usar um pendrive!? Que eu saiba nenhum PIC18 tem USB Host para isso. Esqueça o pendrive, implementar a pilha USB host é muito complicada e consumiria muitos recursos do microcontrolador, duvido que conseguiria manter a taxa de transferência mínima para o jogo rodar na velocidade normal. Uma saída seria usar um cartão SD que é infinitamente mais fácil de se interfacear do que um pedrive, mas levando em conta que estará usando uma tabela de arquivos (FAT32), com um pic18 seria muito difícil conseguir velocidades de transferência maiores que 200Kbytes/s. Não sei quanto ocupa o binário desses jogos, se não for muito grande você pode transferir do cartão SD para uma memória RAM externa (existem umas memórias RAM seriais da microchip com até 1Mbit de armazenamento). Agora a emulação vai exigir um poder de processamento grande. Esse projeto que o @vtrx postou dei uma olhada no código fonte e descobri que o jogo não é emulado, todo o jogo está escrito no arquivo 'game.c'. Não sei qual era a velocidade que o processador 6502 do console atari (minhas pesquisas indicam algo entre 1 e 2MHz), mas você vai precisar de pelo menos 16 (chute meu) vezes essa velocidade para dar tempo de ler e executar o conjunto de instruções equivalente.

@misterjohn Para baixar o elementary de graça e so voce alterar o campo de 10.00$ para 0.00$, isso é apenas uma doação opcional.

Nunca vi esse problema e não sou usuário do Ubuntu. Mas você pode formatar o seu pendrive facilmente pela linha de comando: sudo mkfs.msdos -F 32 /dev/partição Nesse caso a formatação utilizada será a FAT32.

Tem uma distribuição relativamente nova bastante interessante chamada elementary OS, ela é bem fácil de utilizar e tem um visual bem legal! Somente não se esqueça: Linux não é baseado no Windows e não roda programas do Windows (até que roda com o wine, mas exige um conhecimento avançado para funcionar legal). Geralmente quase todo o software que você instala é proveniente do repositório oficial da distribuição, a instalação nesse caso é mais fácil que no windows (e não tem nenhum tipo de malware). Sobre a compatibilidade isso depende muito do seu hardware. Geralmente tudo funciona sem qualquer intervenção sua (não precisa ficar instalando os drivers, eles já vem junto com o kernel). De preferência evite placas de vídeo da AMD (o driver proprietário não funciona, apesar do driver de código aberto funcionar bem se você não se importar com a perda de performace).

Você pode postar mais detalhes do seu problema? Distribuição; Hardware; Dados SMART do SSD; Um "ls -la" nos arquivos que você não cosegue editar;

Não conhecia esse Dip Trace, achei interessante por ter uma versão para Linux*, vou conferir! Atualmente estou aprendendo a usar o Kicad (software livre), antes eu usava o Proteus, mas estou migrando para plataformas mais profissionais para a confecção de PCI's. --EDIT-- *Não tem versão nativa para Linux, mas o site afirma que funciona sem problemas com o Wine.

Na verdade eu aplico sem a laminadora, aplicando o filme com a placa submergida em água e uso um rolo de macarrão para fazer o filme aderir bem. Só acho que uma laminadora iria facilitar o trabalho. Com a tinta fotossensível eu usava uma centrífuga improvisada, os resultados nem sempre eram bons, nunca cheguei a testar com a tela de silk.

Me parece bom, um dia tento aqui em casa! Desisti da tinta fotossensível pois é chato para aplicar, e precisa esperar secar. Com o dry film é só aplicar e passar por uma laminadora e pronto! Processo completo: http://youtu.be/-KT6AhOZCEM

Utiliza tinta pigmentada? Tinta corante não serve pois é pouco opaca. Você poderia postar uma foto de como ficou o seu fotolito? Estou pensando em migrar para uma impressora a jato de tinta, minha laser acaba deformando um pouco a transparência, ficando impossível de alinhar depois.

Essa webcam que você tem não será útil. Os terminais D+ e D- são para o barramento USB. O protocolo USB é bastante complexo e exige um microcontrolador bem poderoso que tenha um periférico USB Host para a comunicação. O módulo que você indicou nesse site utiliza comunicação serial assíncrona que é muito mais fácil de utilizar do que o protocolo USB.

Esqueça essa webcam. Você precisaria de um microcontrolador bem poderoso e com uma interface USB Host para conseguir se comunicar com essa câmera, além de o firmware ficar bastante complexo. Procurei aqui no mercado livre e encontrei algumas câmeras para arduino e encontrei algumas por um preço bem razoável: http://lista.mercadolivre.com.br/camera-arduino. Lembrando que a qualidade delas é bem baixa (640x480) então não espere uma imagem perfeita. Agora gravar vídeo com um arduino comum não tem como. Você precisará de um microcontrolador bem poderoso para comprimir video em tempo real. Acho que existem alguns CI's dedicados para compressão de vídeo em tempo real, mas ainda não procurei.

Já utilizei essas tintas. Acabei optando pelo Dry Film. Muito mais fácil de aplicar, tem uma vida útil maior que a tinta e é mais barato. Fora a aplicação, o processo é igual ao da tinta fotográfica. De uma procurada no mercado livre que você encontra por um bom preço. De qualquer forma, você garante que os seus fotolitos estão opacos o suficiente? Como imprime eles?

Minha experiência com os drivers proprietários da AMD foram frustantes. A instalação não é trivial, pois precisa modificar um trecho do código fonte do módulo do kernel (ele dá um erro na compilação). Depois de resolver esse problema o driver instala, mas quando você reinicia não apresenta mais vídeo (tentei usando GNOME e KDE no arch linux e Fedora, com os mesmos resultados). A única vez que deu certo foi com o Linux Mint Debian Edition com o kernel 3.11 (hoje estamos no 3.16), e toda vez que você atualizar o kernel vai ter que recompilar o driver. Acho que faz uns 8 meses que a AMD não atualiza o driver para Linux. Fiquei com os drivers open source mesmo, ainda não têm toda a performace do driver proprietário mas fora isso funcionam muito bem, sem dores de cabeça.

Bom, existem centenas de distribuições para você escolher, eu pessoalmente uso debian, mas para quem ainda não tem muita experiência eu recomendo o elementary OS. Se o seu hardware não suportar bem o pantheon tente o Linux Mint XFCE.

@MatheusLPS O CodeBlocks é uma excelente IDE, mas não sei como configurar ele para exibir os estados dos periféricos. Mas para o desenvolvimento de programas em C/C++ em um computador ele é bem satisfatório. O emIDE tem exatamente o que eu quero: Só falta um port para linux!