test man*~

Típico "AVR Freak" HAHAHAHAHAHAHA... Você possui uma camisa desta: http://www.atmelbrandshop.com/ProductDetails.asp?ProductCode=0151-B HEHEHEHE Brincadeira... Eu até queria ter =) Estou indo com os projetos... No projeto 4 usei o DIDR0 para para desativar a entrada digital e assim consumir menos energia (característica bacana essa), no do relógio (Pj 5) achei interessante o esquema do 32,768KHz externo =D, ainda estou terminando ele falta programar o alarme! No fim vou fazer uma comunicação SPI entre um PIC e um AVR e uma I2C multimestre com dois PIC e dois AVR como mestres e escravos HAHAHAHAHAHAHHAHAHAHhUHAuhuahuhuaHUAH!!!!! Tutorial excelente... Uma coisa, eles pararam de atualizar o BASCOM?

Entendi @aphawk... É que tipo, Como entendo bem os PICs para entender os AVRs eu tento fazer um paralelo na minha mente HEHE... No PIC quando uma interrupção é gerada os registradores STATUS e W (WORD) também devem ser salvos (se alterados na ISR): ; Código ASM ISR PIC16F INTERRUPT movwf w_temp ; save off current W register contents movf status,w ; move status register into W register movwf status_temp ; save off contents of STATUS register movf pclath,w ; move pclath register into w register movwf pclath_temp ; save off contents of PCLATH register ; isr code can go here or be located as a call subroutine elsewhere movf pclath_temp,w ; retrieve copy of PCLATH register movwf pclath ; restore pre-isr PCLATH register contents movf status_temp,w ; retrieve copy of STATUS register movwf status ; restore pre-isr STATUS register contents swapf w_temp,f swapf w_temp,w ; restore pre-isr W register contents retfie ; return from interrupt Nos AVRs é a mesma coisa... Porém é possível salvar os 'WORKS' (R0 - R31) na pilha com as funções PUSH, nos PICs você salva em outro registrador. É claro... Se não houver alterações nos registradores durante o tratamento das interrupções, também não haverá necessidade de salvá-los... Um coisa muito interesante (tomara que eu esteja correto!! UHAuHAUhUah) é que não há limite para o tamanho da pilha dos AVRs, a única limitação é o tamanho da SRAM e o seu uso... Mesmo assim... Eu ainda amo os PICs !!! @alexandre.mbm, olha este link: https://www.youtube.com/watch?v=64vVI5kgbCo&list=PL4DE4A7AD9EE36E77 Não assisti aos vídeos mas pela quantidade de views eles devem ser bons... O cara usa o CCS nos tutoriais ele é extremamente simples, muito fácil... Ele possui um Project Wizard que te dá tudo na mão, você apenas escreve o código... Parece que o cara também ensina simular usando o Proteus... Quanto as bibliotecas, realmente são poucas se comparadas com a quantidade existente para o Arduíno, o CCS vem com várias mas mesmo assim são poucas... Mas ai que está o pulo do gato, é muito mais interessante você pegar o datasheet do componente, quebrar a cabeça e criar a sua própria biblioteca (que funcionará exatamente como você quer)... Dá uma olhada lá... Quem sabe você curti... Voltando para os projetos o Need For Speed Most Wanted 2005 me atrasou

Obrigado @aphawk e @Intrudera6... Agora estou entendendo, nos PICs no início da ISR é salvo o registrador WORK, dentre outros, porém, nos AVRs são vários 'WORKS' (R31 ao R0) daí é necessário salvar todos, não estou falando besteira né ? Ok Eu tenho que prestar mais atenção, antes de ontem olhei e não achei (apesar te ter passado pela informação)... Agora olhei e achei! Help > Index > Índice > ON INTERRUPT OBRIGADO!

O PROTEUS 8 resolveu o problema!! Eita... O projeto 3 foi mais complicadinho HEHE, o bom que é complicado só na primeira vez. Fiquei com algumas dúvidas se você puder me responder... 1 - Fiz um teste (deu certo) mas quero confirmar... Para escrever diretamente em um registrador qualquer basta escrever o nome dele igual ao valor desejado? 'Ex:TCNT0 = 61OCR2B = 254 2 - Para o timer0 foi usado: On -->> Timer0 <<-- Timer0_isr Save Dei uma procurado no help e não encontrei o nome a ser usado para insterrupções do módulo TWI: Qual seria o nome? 3 - O que as funções PUSH e POP fazem dentro da ISR? Tim0_isr:push r23::pop r23Return Estou chutando que está relacionado com STACK mas tirei elas do meu programa e ele funcionou corretamente, eu até procurei no help mas não encontrei coisa alguma. Obrigado Paulo!

Eu baixei os esquemáticos (há um tempo atrás) dos Arduínos e vi que eles trocaram o FT232 pelo ATmega16U2... Acho que é foi pelo fato da FTDI ter usado uma atualização no driver para "brickar" os FT232 falsos (Product ID = 0). Pois é... Quando peguei os esquemáticos percebi que havia algo estranho pois o que ligava o PC (software do Arduíno) ao ATmega328P era uma comunicação serial (através do FT232, CH340 ou ATmega16U2), mas como o 328P era programado? Fui procurar e trombei com o bootloader... Assisti a um vídeo com um cara explicando como o bootloader funciona mas só para ter uma noção mesmo... Nesse momento entendi como um cara (em um outro vídeo que vi há uns anos atrás) programou um PIC com um par de XBEE... É... Às vezes dou uma navegada pelo site da Adafruit, lá aparece algumas coisas interessantes... Só que, mesmo que o cara usou um AVR, o mesmo projeto poderia ser feito com o PIC... Agora, isso dos professores ensinarem, na maioria das vezes, somente PIC16F eu não entendo o porquê... Tipo, na minha opinião, se o programa for feito em uma linguagem de alto nível o AVR e o PIC ficam empatados (projetos de hobby)... Em casos de projetos profissionais cada um se enquadrará melhor em uma determinada situação... Eu gosto de microcontrolador, qualquer um... PIC, AVR, motorola (nunca usei HAHHA)... Aliás, qualquer coisa que dê para quebrar a cabeça... Instrumentação, CLP, Redes industriais, Supervisório e por ai vai!!! Voltando ao BASCOM, estou achando estranho ontem fiz um contador 0-99 (Modificação do projeto 2 adicionando 2 CIs 4411) e o proteus não mostrou a variáveis, declaradas no programa, durante o debug... '------------------------------------- Descrição -------------------------------------'' Fazer dois leds piscarem a uma frequencia de 1Hz '------------------------ Modelo do AVR e velocidade de clock ------------------------'$regfile = "m48pdef.dat" ' ATmega48P$crystal = 8000000 ' Oscilador interno 8MHz (configurado nos Fuses) '------------------------- Configuração da direção dos pinos -------------------------'Config Portb = Output ' Poderia ser: ' Config Portb &B11111111 (1 = Saída | 0 = Entrada) ' Config Pinb.0 Input/Output '----------------------------------- Nomeando pinos ----------------------------------' '------------------------------ Declaração de variáveis ------------------------------'Dim Contador As ByteDim Aux1 As ByteDim Aux2 As Byte '---------------------------- Inicialização de variáveis -----------------------------'Contador = 0 '------------------------ Inicialização dos estados dos pinos ------------------------'Portb = &H00 ' inicializa os displays com zero (00) '----------------------------- Declaração de constantes ------------------------------' '--------------------------------- Código principal ----------------------------------'Do Aux1 = Contador / 10 ' EX: contador = 15 | Aux1=15/10=1 Aux2 = Aux1 * 10 ' Aux2=1*10=10 Aux2 = Contador - Aux2 ' Aux2=15-10=5 Shift Aux1 , Left , 4 ' Aux1=Aux1<<4 | Aux1<<=4 Aux1 = Aux1 Or Aux2 ' Aux1= DIGITO1 (4MSBits) DIGITO2(4LSBits) Portb = Aux1 Contador = Contador + 1 If Contador = 100 Then Contador = 0 End If Waitms 200Loop '-------------------------------------------------------------------------------------'End '------------------------------------ Sub-rotinas ------------------------------------' Faltou o VCC conectado ao AREF e AVCC Mas de boa! Agora vou para o 3. Uma coisa, aquela parte que você fala como debugar com o proteus, aqueles macetes... Ficou muito bacana, na época eu aprendi (mais ou menos) aos trancos e barrancos HEHE

É daqui a pouco $asm$end asm Igual no C. @aphawk, eu estou pensando uma coisa... Se existisse um gravador barato e que permitisse a alteração dos FUSES facilmente (crystal externo/interno mesmo sem o crystal conectado, SPIEN abilitado/desabilitado, etc.), assim como existe o PICKIT 2 para os uc's da Microchip, os AVRs seriam mais famosos. Até existe o AVR Dragon (pelo que eu entendi) mas ele é bem carinho (pra mim) Enfim, estou indo com a programação, o BASIC é bem fácil de entender (mais fácil que o C) só gastei muiiiiiiiiiiiiiiiiiiiiiiiiiiiiittttttooooooooooo tempo para entender o funcionamento do gravador (sem/com crystal, SPIEN, clock da programação deve ser menor que o clock do chip a ser gravado, etc.)... Agora vou voltar para o tutorial PROJETO 2.

Isso que eu queria ... Mas pulei tudo e fui direto para o tutorial... Você diz no tutorial: "o que importa aos iniciantes é que conheçam muito bem o que que o hardware existente em um AVR pode fazer, apenas isto, não se preocupem em COMO FAZER ISTO, pois é justamente aí que entra o BASCOM e sua linguagem BASIC!" E é verdade... Fiz algumas coisas um pouco complicadas (usando o CCS) lendo quase que nada o Datasheet do PIC usado... Fui direto para o tutorial e se precisar leio o Datasheet! Mas aquela coisa dos 32 Working Registers conectados diretamente à ALU é muito massa Obrigado Paulo!

Um vendedor fez uma promoção e acabei comprando um UNO SMD (com o conversor USB<>SERIAL CH340), um UNO R3 (aquele que usa outro AVR para fazer a conversão USB<>SERIAL) e um DUEMILANOVE (FT232 para USB<>SERIAL com os pinos CTS DSR DCD e RI disponíveis)... Ficou em US $2.72 vai demorar para chegar... Mas uma dia chega HAHAHAHA, o Arduíno mega (ATmega2560) estava US $1.20 quando cliquei para comprar a oferta acabou =D... Perguntei do DATASHEET pois gosto de entender o que o compilador está fazendo. Depois de aprender assembly p/ o PIC a programação em C ficou mais eficiente, consigo fazer a mesma coisa gastando bem menos tempo e memória de programa... Mas vou seguir seu conselho. Vou direto para o BASIC... Depois dou uma espiada no datasheet (assim como foi com os PICs) Obrigado!

>>> Edit: Se o PIC fica enviando dados constantemente (sem o labVIEW pedir) daí você pode fazer um esquema para que o labVIEW saiba o eixo que pertence o dado recebido. PIC envia: X55.55XY44.44YZ11.11Z Entende? Daí o labVIEW saberá que o dado entre os "X" pertence ao eixo X

@aphawk vou começar a ler e estou com umas dúvidas... > Você usa a versão DEMO do BASCON AVR (com a limitação de 4KB)? > Você pode me indicar um Atmel bem simples (tipo o PIC16F628A) para eu ler o datasheet e me acostumar com os registradores básicos dos AVRs? > O PIC (16F, 18F) precisa de 4 ciclos de clock para executar uma instrução, os AVRs executam com apenas um único ciclo? Obrigado.

Você pode usar um símbolo separando os dados por exemplo: xx.x-yy.y-zz.z Daí você configura o labVIEW para entender que o "-" (símbolo) separa as variáveis. Outra forma seria fazer o PIC enviar dados com um tamanho fixo tipo: printf("%02d.%02d"eixox_int,eixox_frac)... Daí o labVIEW sabe que ao receber os dados a variável correspondente ao eixo terá sempre X bytes (se considerar o exemplo acima 5 bytes XX.XX). Era mais ou menos isso que você procurava?

Qual microcontrolador e compilador você usará? Você pode usar interrupções externas, Timers e capture... õ/

Malditos bancos... Nem me fala!!! HAHAHAHAHAHAAHAHA agora até que estou achando bem tranquilo essa tranqueira toda mas quando passei do 16F628A para o PIC16F877A além dos bancos surgiu a paginação da memória de programa com a instrução goto/call não possuindo bits suficientes para ir para todos os endereços da memória de programa, WHAT THE F*** IS THIS!?!? Pensei na hora... Foi nesse momento que vi vários posts criticando a arquitetura dos PICs de 8 bits e elogiando a dos ucs ATMEL... Há um tempo atrás comecei a ler o datasheet de um ATMEL (8 bits) e de cara vi que parecia ser uma coisa mais organizada, sei lá... Não sei explicar... Até a distribuição dos pinos tipo TX pino Y, RX pino X, SDA PINO Z me pareceu mais organizada... Enfim, fui para o assembly para entender a operação do microcontrolador e assim saber o que está acontecendo quando escrevo um código em C (com o CCS)... Mas acabei achando muito interessante e resolvi aprofundar um pouco mais... Sim, no meio dos estudos eu pensei nisso, não vale a pena continuar com assembly apesar dele ser extremamente interessante e você saber exatamente o que está acontecendo. Quando eu terminar com o livro "Desbravando o mocrocontrolador PIC16F628A" vou voltar para o CCS mas não usarei algumas funções dele (como spi_write, i2c_write, setup_spi, #use i2c...), sempre que der criarei as minhas (para saber o que está acontecendo)... @aphawk Você me convenceu... Acabei de abrir o datasheet do ATmega328P e P%@& Q$@ P%#&$ (desculpe-me pela expressão) o vetor de interrupção dele é brilhante... É separadinho um endereço para cada interrupção... O PIC possui 1 endereço para todas as interrupções e quando uma ocorre você deve fazer um tratamento para ver qual foi (eu imagino que seja assim, ainda não cheguei nessa parte do livro). Bem... Vou terminar com o livro e ir para o seu tutorial (Basic) e dele vou para o assembly...

Verdade =D @aphawk... Eu estou aproveitando que estou com bastante tempo (daqui a pouco ele acaba) para entender como os microcontroladores funcionam. Para isso estou aprendendo assembly, estou no PIC16 vou passar pelo PIC18, PIC24 e dsPIC... Dai pretendo ir para os microcontroladores da ATMEL, vou começar pelo basic (usando o seu tutorial) e depois vou para o Assembly... Mas vai demorar um pouco, pois como eu disse, o tempo agora está extenso mas daqui a pouco vai ficar curtinho curtinho (tomara que não acabe) =D... Mas devagarzinho eu chego . "Melhor sobrar conhecimento do que faltar kkkkkk!" aphawk, 2015.

@aphawk me fazendo engolir conhecimento a força HAHAHA ... Eu li o que você disse e fui procurar na net para terminar de entender o funcionamento, agora sei como ele funciona HEHE

Não... Não desconsidere a resposta do @Isadora Ferraz... Eu só percebi esse errinho no uso da instrução mas não sei como um Encoder funciona... Se houver dúvida sobre o Encoder siga a resposta do @Isadora Ferraz... (Eu também não analisei o código) Meu @mention não funciona

Você usou o output_bit assim: OUTPUT_BIT (PIN_B1);OUTPUT_BIT (PIN_B0); E deveria ser assim: OUTPUT_BIT (PIN_B1, valor);OUTPUT_BIT (PIN_B0, valor); Sendo valor igual a zero (0) ou um (1) para saída em nível baixo ou alto. Você também pode fazer assim: #byte portb = 0x06 #bit pino_b0 = portb.0#bit pino_b1 = portb.1::pino_b0=valor;pino_b1=valor;

Não sei se é isso mas após quebrar a cabeça pensei em um possível porquê... Vamos supor que em um ponto do programa o usuário vai fazer uma chamada: pagesel rotina ; Ajusta os 2 bits (4:3) do PCLATH call rotina ; Vai para o endereço da rotina > 11 bits (10:0) do endereço ; vem do OPCODE e dois (12:11) do PCLATH (4:3) Porém se uma interrupção ocorre após o pagesel pagesel rotina ; Ajusta os 2 bits (4:3) do PCLATH ;**INTERRUPÇÃO** <<--------<<------- call rotina ; Vai para o endereço da rotina > 11 bits (10:0) do endereço ; vem do OPCODE e dois (12:11) do PCLATH (4:3) com ela contendo uma instrução para alterar os 2 bits (4:3) do PCLATH, quando o programa retornar (RETFIE) e for executar a instrução CALL o programa irá pular para um endereço errado (em outra página de memória)... Acho que é por isso que o datasheet sugere salvar e recuperar o PCLATH... Uma coisa interessante foi que, ao procurar o motivo pela internet, encontrei várias pessoas criticando a aquitetura dos PICs de 8 bits e dizendo que a dos microcontroladores da ATMEL é bem melhor UAHuHAuHUAhUhuHauhUAh

Pessoal estou com uma dúvida, o MPLAB (Template) e o datasheet sugerem o salvamento (quando uma interrupção ocorre) e a recuperação (antes do retorno) do PCLATH... ;------------------------------ Datasheet ------------------------------; MOVWF W_TEMP ; Copy W to TEMP registerSWAPF STATUS,W ; Swap status to be saved into W CLRF STATUS ; bank 0, regardless of current bank, Clears IRP,RP1,RP0MOVWF STATUS_TEMP ; Save status to bank zero STATUS_TEMP registerMOVF PCLATH, W ; Only required if using pages 1, 2 and/or 3 <<<------------<<<------------MOVWF PCLATH_TEMP ; Save PCLATH into W <<<------------<<<------------CLRF PCLATH ; Page zero, regardless of current page::(ISR) ; (Insert user code here):MOVF PCLATH_TEMP, W ; Restore PCLATH <<<------------<<<------------MOVWF PCLATH ; Move W into PCLATH <<<------------<<<------------SWAPF STATUS_TEMP,W ; Swap STATUS_TEMP register into W ; (sets bank to original state)MOVWF STATUS ; Move W into STATUS registerSWAPF W_TEMP,F ; Swap W_TEMPSWAPF W_TEMP,W ; Swap W_TEMP into W Quando uma interrupção ocorre o endereço completo do Program Counter (PC+1 > 13 bits) é salvo na pilha (Stack)... Então por que salvar o conteúdo do PCLATH? Mesmo que eu altere a página de memória dentro da ISR eu não estarei alterando o endereço salvo na pilha, por isso eu não entendo a necessidade de salvar o PCLATH... Dando uma lida eu percebi que mesmo eu escrevendo no PCLATH o PCH (Program Counter Bits mais significativos) só é atualizado quando a função GOTO ou CALL é executada e aparentemente RETFIE ignora o PCLATH (usa apenas o que está na pilha)... Whaa? Por que salvar o conteúdo do PCLATH?

Bob1 (os outros também) é apenas 1 bit. Use a função BSF em vez da MOVLW e MOVWF. Ou então use a MOVLW e MOVWF mas movendo o valor para a porta. movlw b'00001000' ; ou b'10000000'movwf portbcall delay ; Para controlar a velocidademovlw b'00000100' ; ou b'01000000'movwf portb::call delay movlw b'00000001' ; ou 'b00010000'movwf portb

Hmmmm... Entendi! É isso mesmo @vtrx... O interessante é que antes de ir para a programação eu li o datasheet inteiro e não vi essa informação, apesar de ela estar lá POR ISSO A PARADA É DIVIDIDA EM BANCOS (BANK0, BANK1...) CADA UM COM 127 POSIÇÕES HhuhUAHUhauha Show de bola... Obrigado @vtrx e @Isadora Ferraz pelas respostas!

Fiz alguns testes considerando o que você disse @Isadora Ferraz o byte, mesmo sendo maior que 127, é movido corretamente tanto para o WORK quanto para o F (variavel neste caso). MOVLW B'01010101' ; W='01010101' MOVWF variavel ; variavel=B'01010101' MOVLW B'11111111' ; W=B'11111111' XORWF variavel,0 ; (XOR entre var=01010101 e W=11111111 armazena resultado em W) ; variavel=B'01010101' e W=B'10101010' (>127) ----------------------------------------------------------------------------------------- MOVLW B'01010101' ; W=0 MOVWF variavel ; variavel=0 MOVLW B'11111111' ; W=B'11111111' XORWF variavel,1 ; (XOR entre var=01010101 e W=11111111 armazena resultado em var) ; variavel=B'10101010' (>127) e W=B'11111111' Também fiz testes para valores menores que 127 e todos os bits são movidos corretamente (o byte inteiro), tanto para W quanto para F. MOVLW B'01010101' ; W='01010101' MOVWF variavel ; variavel=B'01010101' MOVLW B'01111111' ; W=B'01111111' XORWF variavel,0 ; (XOR entre var=01010101 e W=01111111 armazena resultado em W) ; variavel=B'01010101' e W=B'00101010' (<127) ----------------------------------------------------------------------------------------- MOVLW B'01010101' ; W=0 MOVWF variavel ; variavel=0 MOVLW B'01111111' ; W=B'01111111' XORWF variavel,1 ; (XOR entre var=01010101 e W=01111111 armazena resultado em var) ; variavel=B'00101010' (<127) e W=B'01111111' Mudei de função para ficar mais fácil fazer os testes. A XORWF também possui o 'dezinho' d para destino... Do datasheet: Vou acabar aceitando e seguindo com a vida UAhuHauHauhUAhUHauHA...

O datasheet do 16F628A diz que ao usar a função MOVF o valor do operando pode ser de 0 a 127: Mas nos testes aqui o PIC está movendo valores maiores que 127, com a função MOVF, normalmente. MOVLW 0xFF ; W=255MOWF variavel ; variavel=255 MOVLW 0x00 ; w=0MOVF variavel,W ; w=255 Deveria bugar aqui, não? <<---------<<---------- Tipo, ainda bem que está atribuindo os 8 bits certinho (já estou doido para usar o 24F pois estou achando os 8 bits muito pouco xD), mas está estranho para mim... Alguém pode me explicar? Obrigado!

Achei, é isso mesmo =D http://www.ccsinfo.com/forum/viewtopic.php?p=138506 Assembly é bem interessante... Você constrói tudo! =D

Comecei a ler o datasheet do PIC16F628A para aprender assembly e dúvidas começaram a surgir... O CCS usa a função: #use delay(crystal=4000000) Estava tentando entendê-la (eu fico filosofando e tentando converter funções do CCS para assembly na minha mente)... O CCS usa essa função apenas para indicar ao compilador qual a velocidade de operação e assim ele poder contar tempo em funções de delay, configurar BRG e coisas do tipo?? A dúvida surgiu pois não vi algo parecido no datasheet e em assembly você apenas indica o modo do oscilador (LP, XT, HS...) Obrigado aos que responderem.