mister nintendo

@omiez e @circuit .... não percam esse tópico de vista, podemos fazer um debate mais quente nele la pra frente, eu comprei um raspberry pi faz 120 dias no dx.com e não chegou ainda :/ .... mas assim que chegar podemos debater mais e contar com mais colegas como a @chacalgbi que também tem um flowww

@MatheusLPSquanto tempo você demorou pra receber este e-mail pedindo seu endereço? eu me inscrevi faz 3 dias e não recebi nada ainda, pergunto só pra saber uma estimativa de tempo e saber quando desencanar desse Galileo hahaha floww

cara, compensa mais você colocar o seu código ai, para que possamos corrigir e você ver onde errou, pois passando um código vai servir apenas de teste pra você, mas ae vai um código sbit led at gp0_bit; void main(){ intcon=0x00; cmcon=0x07; ansel=0x00; adcon0=0x00; gpio=0b11111110; led=0; while(1) { led=1; delay_ms(1000); led=0; delay_ms(1000); }} poste ai seu código para nós. floww

pode fechar o tópico moderador.

Ohhhh cara, valeu! estes artigos ajudaram sim! muito obrigado @LNW ! se alguém tiver algum outro documento pode mandar também, ainda estou precisando, pois quando eu comparo o hexadecimal gerado, com o OPCODE que eu esperava pelo datasheet não vejo semelhança nenhuma flowwww, abrçs

Eae pessoal! Gostaria de saber se alguém conhece algum documento da microchip que mostra como interpretar o arquivo hexadecimal que é gerado para gravar no PIC. Queria saber onde fica as configurações, que parte do arquivo gerado se destina ao gravador e que parte efetivamente é gravada no PIC. Estou usando um método que não esta sendo muito rentável, estou tentando interpretar na raça o hexadecimal, pois não achei nenhum documento da microchip falando sobre este assunto vlew, abrçs!

então cara, creio que ninguém fara isso, te adicionar e ficar tirando suas dúvidas pelo facebook...... ninguém aqui curti muito isto, pois isso deixa de ajudar um monte de pessoas depois....... você tem que tirar a dúvida aqui, o pessoal sempre responde e ajuda...outra coisa é que você não tem nenhuma dúvida parece, sem dúvidas não tem como responder kkkkk abrçs

ahhh não cara, dessa eu não sabia.... não posso acreditar que o microC tem uma limitação dessa D: eu nunca percebi isso, quando comecei a fazer códigos grandes comecei a usar a família 18F.... abrçs

eu tenho aquele gravador, essas mensagens são padrões dele ..... ele sempre que se comunica com um pic e não reconhece o pic ou não tem nada la (que é o caso) ele fala que o pic 16F84 esta la, e a mensagem de apagar também é padrão, só significa que ele tentou apagar a memória antes de gravar não significa nem que ele conseguiu, pode perceber que nas caixinhas de seleção esta como 8/14/20 (que é a pinagem que ele espera que o pic tenha), ou seja ele esta esperando por um outro tipo de pic e mesmo assim fala que é o 16F84 (que tem 18 pinos) que esta la abrçs

cara, você colocou o pic errado no gravador, eu tenho esse gravador, o pino 1 de TODOS os pic's devem ser colocados no pino 1 do ZIF... ou seja, o pino 1 do pic tem que ser colocado no furinho que esta pintado, o mais próximo da alavanca do conector.... flowww

cuidado pra não queima-lo, ligações erradas podem dar nisso, experiencia própria hahahahaha abrçs

ter tem como, mas são processos muito doidos, que não conseguiremos fazer com nossos gravadores hahahaha.... não me arrisco a dizer como é realmente este processo pois eu nem entendi quando li, então não direi nada para não dizer mer***, mas fica sossegado, são processos industriais que ninguém vai fazer por um simples botão touch kkkkkkkk, compensa se for programas muito importantes etc.... floww

não tem como, o que acontece quando protegemos o código é que ha um rompimento nas vias de comunicação do gravador com o pic, e essas vias só voltam ao normal quando aplicamos 13V no pino do masterclear, mas quando aplicamos 13V nele a memória do pic é apagada, ou seja não da pra ler o que esta la, se forçar a leitura tentando recuperar as vias de comunicação o pic é apagado abrçs

é igual ao de um 16x2, as ligações são as mesmas, a diferença é no software, na forma de lidar com o display http://2.bp.blogspot.com/-P9QI8H3UA1A/T2OqpeDPM9I/AAAAAAAAAiY/jnsUCfDi9i0/s400/ScreenHunter_13.bmp obs: aconselho aterrar os pinos não usados do display (diferente do que o cara fez na imagem) abrçs

exatamente, o comando de "proteção de código" é uma coisa que vai junto com as configurações, logo no começo da gravação, e assim que termina a gravação o código já esta protegido e toda tentativa de leitura vai falhar, por isso ele não consegue mais ler..... abrçs

esse projeto era apenas uma brincadeira que fiz, então ele não é grande, apenas 8X8 e só passa frases, não tem horário data temperatura etc.... o hardware inteiro e completo é apenas aquilo que esta na foto flowwww

https://www.huinfinito.com.br/ alguém já comprou neste site? tem umas coisas até interessantes, mas não sei se é confiável flowwww

não não, esse método deve ser chato rsrsrs, eu pensei em uma bobina enrolada na parte que roda no propellerclock, e um imã fixo próximo a bobina, vai me dar uma tensão toda irregular, mas é só retificar e pronto flowwww

não. eles são simples motores DC, bem fortinhos, mas não fornecem a alimentação para o eixo do motor que fica rodando, eles são alimentados mas não repassam essa alimentação, para o propellerclock eu imaginei alguns métodos de alimentar, de outra forma, pois esses motores não repassam a alimentação. flowwww

É que depende muito da impressora. Todas as imprssoras HP deskjet da serie 600 eu seu que tem motores DC. E diga-se otimos motores. Porque são fortes. O unico ruim deles para o propeller clock é o comprimento. Mas mesmo assim creio que não seja impedimento para o utilizar Flowww

eu tinha conseguido um mas ele não estava mais funcionando , por isso resolvi fazer com um de impressora flowwww

kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk em questão de projetínhos que demoram demais para sair do papel acho que todo técnico tem um kkkkkkk, eu por exemplo tenho outra matriz de led que quero fazer, quadrada 35X35, mas toda hora penso em mudar alguma coisa e até agora não sai dp lugar kkkkkkkkk, mas o campeão de demora pra mim, é o meu propellerclock kkkk, ja faz muito tempo que estou comprando e armazenando as coisas pra poder fazer ele, e até agora não dei um passo kkkkk flowwww

aphawk, começarei meus estudos sobre os famigerados AVR's, baixei hoje sua apostila e exmplos. obrigado por disponibilizar um material assim para nós! vou comunicando a experiencia! flowwww

quem agradece realmente sou eu, o que você fez me ajudou muito ok então fico no aguardo! flowww

Muito legal MatheusLPS Eu vou dar uma fuçada também, porque muitas vezes não consigo ajudar aqui não porque eu não saiba programar e sim porque não conheço o CCS. Mas sempre continuarei com o meu MicroC. Em questão de sintaxe. Eu prefiro muito mais ele Flowww