Felipe Electronic

@Matheus_LPS, Vou desmistificar mais uma coisa pra voce: Não é reduntante, inclusive é mais seguro, do que depender o valor "true" assumido pela LibC do CCS, além disso, profissionalmente eu faria assim: Porque? Por ser ainda mais seguro, pois alem da constante estar explicita se eu por um acaso errar e escrever = em vez de == o programa vai me gerar um erro de compilação, o que não ocorre no caso contrario em que o codigo compilaria e eu so iria descobrir o problema na hroa de testar o codigo, ja imaginou se fosse o if de um ABS por exemplo? Ou seja a recomendação é use sempre a constante explicita, nao custa mais código, e é sempre mais seguro. Isso é perigoso por exemplo, se o nivel de true ou false forem respectivamente 0xFF ou 0x00, não haverao problemas, agora se for o contrario, vale lembrar que o '!' funciona como negação, ira inverter o que não deveria ser invertido. Eu não arriscaria ficar na mão da LibC do CCS nem de compilador nenhum. @aphawk, por isso que C/C++ (Python também) é padrão da industria e da comunidade open source e Basic não é, pois existem dezenas de formas de se fazer a mesma coisa e com qualidade...a criatividade do projetista é que manda.

Usando um pouquinho de técnicas digitais, voce pode transformar seu sistema de botão numa maquinha de estados com duas sitações possiveis : Estado LIgado e Estado Desligado, a transição de um estado para o outro é feita no pressionamento do botao, veja; #INCLUDE <16f628A.h>#FUSES NOWDT#FUSES XT#FUSES NOPUT#FUSES NOLVP#FUSES NOCPD#FUSES NOMCLR#FUSES PROTECT#USE DELAY(clock=4000000)#USE FAST_IO(#define ESTADO_LIGADO 0x01#define ESTADO_DESLIGADO 0x02/*************************Todos os contadores**********************************//******************************************************************************/int32 cont_1;int32 cont_2;int32 cont_3;INT32 CONT_4;int8 bEstado = DESLIGADO;/****************************interrupção******************************//******************************************************************************/#INT_TIMER1VOID frequencias(void) { set_timer1(65500-get_timer1()); cont_1++; cont_2++; cont_3++; }VOID main(){ cont_1=0; cont_2=0; cont_3=0; set_tris_b(0b00100000); output_low(PIN_B3); setup_timer_1(T1_INTERNAL|T1_DIV_BY_2); set_timer1(65500); enable_interrupts(GLOBAL); disable_interrupts(INT_TIMER1); WHILE (true) { if(input(PIN_B5)==1) { //checa estado atual: if(bEstado == ESTADO_LIGADO) bEstado = ESTADO_DESLIGADO; else bEstado = ESTADO_LIGADO; } //nesse switch voce processa o estado: switch(bEstado) { case ESTADO_LIGADO: //faz alguma coisa break; case ESTADO_DESLIGADO: //faz outra coisa break; default: //trata valores errados break; } } } Veja se compreendeu bem a ideia. Abs.

@vtrx, Em termos de representação de endereços você está certissimo, não posso representar 65536 em 16bits, porém veja que na resolução eu me refiro em quantidade de endereços, veja que nao posso representar 65536 em 16bits mas em 16bits posso representar 65536 valores diferentes (lembrese que o valor 0x0000 tambem entra na conta). Portanto a quantidade de endereços que possuo será esse valor, que multiplicado pela quantidade de bytes que consigo armazenar em cada posição irá me fornecer o valor da capacidade total em bytes.\ Espero ter esclarecido. Abs, Felipe

Wow, vamos com calma: Capacidade em bytes: Tamanho da palavra * Numero de Enderecos Tamanho da palavra de memoria: 5 algarismos hexadecimais, ou seja 5 nibbles, 2.5 bytes por endereços! Lembrando que 1byte = 2 nibbles. Numero de endereços: Maior valor 0xFFFF, 65535 , menor endereço = 0 .`. 65536 endereços, logo : 65536 * 2.5 = 163840 bytes, portanto 160KB, alternativa C (questao 31). A questao 32 está mal elaborada, o correto seria perguntar o numero máximo de estados corretos que esse decodificador poderia representara que são 64, assim a alternativa correta é a B.

Quando voce diz isso: Se refere a isso? Se sim, a colocação do amigo é correta, veja que não é porque você trabalha apenas com sinais em regime DC que o diodo retificador (e mais alguns tipos de outros diodos) perdem sua função, quero dizer que diodo retificador ou qualquer outro não tem apenas uma função, em muitos casos a função de um componente ou conjunto deles fica a cargo da criatividade do projetista, ja pensou por exemplo em usar um diodo como sensor de temperatura?. Mas mais uma vez, se quer alguma ajuda com propriedade, diga pelo menos o que quer transmitir, diga sobre seu circuito de radio como ele deve operar, enfim essas coisas. Abs.

Vamos com calma gente, eu mesmo já tive a empolgação do autor do tópico de querer sair projetando quando fiz meu primeiro amplificador de áudio funcionar. Só não concordo com esse tipo de coisa: O máximo de mérito possível pra quê? Se pretende realmente ficar rico projetando um circuito transceptor de rádio, sugiro começar primeiro deixando o ego de lado, e estudar, e muito, circuitos elétricos mas a nível teórico mesmo, saber o que tudo faz, e depois pensar em alguma inovação bombástica com envio de informação via ar, alem dos já complexos campos como Down e UpConverters, LNAs, Mixers, antenas, propagação de sinais, algoritmos de demodulação sejam em hardware ou em software. Bem agora passados os problemas com seus supostos direitos autorais, não há nada de errado em buscar referências para projetar seus circuitos, sendo seu projeto independente ou não, sabia que antes mesmo de Newton desenvolver toda a teoria de cálculo diferencial e integral, Arquimedes ja sabia calcular as equações básicas centenas de anos antes? Que tal agora você nos passa detalhes do que pretende fazer, pelo menos um diagrama de blocos, a banda que que voce quer transmitir, com que potência e o que tem em mente, com isso poderemos lhe ajudar e muito para construir um circuitinho de rádio bem supimpa Abs.

Explique melhor @cpexpert. Você quer captar como o comando de IR? Retransmitir ele é possível, até áudio digital por IR é possível desde que ninguém passe na frente do feixe, senão corrompe o pacote. Abs. Felipe

Nem precisei responder hahahahah! Mas o amigo autor do tópico ja percebeu que os inconvenientes são multiplos. Eu sei que vai parecer também um desincentivo, mas qual o mal de derivar a alimentação do seu sistema de catraca da alimentação do onibus (a famosa linha 30)? Ou mesmo utilizar outras formas de captação de energia elétrica (como uma fotocélula colocada do lado de fora do onibus, esta sim carregando uma bateria para manter teu sistema funcionando)? Abs. Felipe.

Hummmm, trabalho pesado hein...preciso tirar umas dúvidas, primeira de todas...como você sabe o alternador irá girar uma ou duas vezes em MÉDIA gerando dois ciclos senoidais e depois vai ficar parado, checou se a quantidade de energia gerada é o bastante para carregar o banco de baterias ou mesmo, manter o sistema ativo mesmo que em modo de baixo consumo? Apesar dos pesares catraca é um sistema de missão crítica e não pode falhar durante o trajeto do ônibus. Sobre o bilhete o trabalho é mais uma boa leitura sobre o protocolo Mifare, utilizado neles, em vez de você fazer um decodificador, e por o Arduino pra descriptografar o conteúdo do cartão, talves seja melhor você criar seu próprio protocolo de gravação e leitura de créditos num bilhete desses para fins de demonstração...dependendo da cripto usada você poderá levar semanas pra entender como funciona, mais algumas semanas para implementar num Arduino (acredite cripto consome memória de programa pra ca*ete!), então de sugestão opte pelo simples. Teria algum eesquema ou diagrama de blocos pra gente ver o que tá feito? Abs. (PS.: Excelente ideia de trabalho)

Ahahah, que beleza, bons tempos mesmo Falando ainda em bouncing, ultimamente tenho consumido uma entrada analógica do microcontrolador e implementado um teclado baseado em divisores resistivos, o resultado de pressionamento e feedback da tecla escolhida tem sido bem mais agradável uma vez que outras formas de filtragem sem uso de delays (eca!) podem ser usadas como o cálculo da média móvel do valor lido pelo A/D. Vejam ai se não ajuda: http://www.st.com/st-web-ui/static/active/en/resource/technical/document/application_note/CD00004024.pdf Ahh ST, sempre caprichando nos documentos (e nos microcontroladores também hahahah!). Abs.

entendi sei não hein, tem um loop dentro da ISR... O grande problema de fazer assim é o fato de parar o processador ate encher o buffer... a solução ganha em velocidade por um lado, porém você perde CPU para outras tarefas, isso pode causar outro problema, se antes tinhamos register pressure, agora teremos starvation desse processor até que a CPU seja liberada a ao final do evento. Vou olhar se ainda da pra otimizar mais sem parar a CPU... Em todo caso se funciona, vai dai que eu vou daqui. Abs.

Fuçando o set de instruções do AVR, deu pra dar mais uma otimizadinha, olha só que legal mestre @aphawk: ;Listagem para tratamento de interrupcao do analisador logico;agora o buffer tem 1024 posições: .DSEG abBuffer .BYTE 1024 bFlag .BYTE 1 wBaseEnd .BYTE 2 .CSEG ;esta funcao inicializa o sistema de captura:IniciaCaptura: ;salva argumentos: push r18 push r19 ;incializa buffer com endereco base: ldi r18, (low)abBuffer ldi r19, (high)abBuffer ;enderecamento direto: sts wBaseEnd, r18 sts wBaseEnd+1, r19 ;limpa flag de buffer cheio: clr r18 sts bFlag,r18 ;retoma contexto: pop r19 pop r18 ;encerra funcao ret ISR: in r0, SREG ;optei pelos high registers pois aceitam qualquer instrucao push r0 push r18 push r19 ;preciso do registo X para enderecamento indireto: push r26 push r27 ;preciso do Y tambem push r28 push r29;Inicia processo da ISR: ;carrega endereco mais baixo do register MAP, no caso PINC: ldi r28,(low)PINC ldi r29,(high)PINC ;carrega endereço do buffer: lds r26, wBaseEnd lds r27, wBaseEnd + 1 ;recupera PINC lds r18, Y ;salva no buffer: sts X+, r18 ;aponta a posicao de TCNT0 na RAM: adiw r28:r29, $20 ;pega timer 1: lds r18, Y ;salva no buffer: sts X+, r18 ;aponta a posição do timer 1: adiw r28:r29, $40 ;acessa lds r18, Y+ ;buffer: sts X+, r18 ;acessa parte alta: lds r18, Y ;buffer: sts X+ ;Aqui checamos se o buffer encheu: ;checa se zerou: cpi r26,(low)(abBuffer + 1024) brne NAO_ENCHEU ;checamos a parte alta: cpi r27,(high)(abBuffer + 1024) brne NAO_ENCHEU ;se encheu seta o flag de buffer cheio: ldi r19, $0FF sts bFlag, r19 ;recarrega endereço com valor inicial: ldi r18, (low)abBuffer ldi r19, (high)abBuffer ;enderecamento direto: sts wBaseEnd, r18 sts wBaseEnd+1, r19 ;PAULO POR FAVOR CHEQUE SE PRECISA: ;Derruba interrupcoes: cli jmp FIM_PROCESSO ;se nao encheu apenas salvamos o endereco de volta na RAM: NAO_ENCHEU: ;apenas guarda endereco na variavel destinada: sts wBaseEnd, r26 sts wBaseEnd+1, r27 FIM_PROCESSO: ;retoma contexto: pop r29 pop r28 pop r27 pop r26 pop r19 pop r18 pop r0 out SREG,r0 ;encerra ISR reti Deu pra ganhar mais 4 ciclos Abs.

mestre @aphwak, gostei da ideia de mexer com assembly de 8bits novamente, fiquei encucado, então me veio a ideia de usar X e Y como dois datapointers e com o auxilio do memory map deu pra dar uma enxugada boa no codigo, so vou te pedir para observar algumas coisas: - Fiz essa estrategia baseada no memory map do ATMEGA328, se o chip for diferente pode ser necessario recalcular alguns offsets; - Coloquei uma rotina extra para colocar o buffer de captura e o endereço em condições iniciais conhecidas, basta chamar uma vez no começo do programa que a propria ISR se encarrega de manter os valores dentro do range; - Infelizmente nao medi os tempos, mas funciona corrretamente, vale lembrar que usei o AVRASM para escrever e pode ser necessario alterar sintaxe e operandos no BASCOM dada as razoes que ja expliquei no post anterior. - Nao parei a contagem do timer0 e timer1 para economia de ciclos. A estratégia é bem mais simples no inicio da subrotina uso dois pares de datapointers, X e Y (AVR adoro você!), em um retiro o endereco de buffer corrente para qual devo apontar, no outro carrego o registrador que tenha o endereço mais proximo de 0 (PINC!)... ai fica fácil, carregao Y em r18, sem fazer postinc, e armazeno r18 em X com postinc (esse contem o endereço do buffer), após isso somo em r28:r29 um offset para o proximo registro no meu caso TCNT0 (! por isso nao uso postinc em Y pois calculo o offset na mao !), e repito o processo, de Y para r18, de r18 pra X, e e de novo ate salvar o timer 1, no fim da ISR uma simples comparação para checar se o buffer encheu, se nao apenas guardo o endereço corrente de volta na variavel se sim, recarrego a variavel com o endereço base do buffer, coloco 0xFF no flag e derrubo as interrupções (veja se acha uma solução melhor). Abaixo o código: ;Listagem para tratamento de interrupcao do analisador logico;agora o buffer tem 1024 posições: .DSEG abBuffer .BYTE 1024 bFlag .BYTE 1 wBaseEnd .BYTE 2 .CSEG ;esta funcao inicializa o sistema de captura:IniciaCaptura: ;salva argumentos: push r18 push r19 ;incializa buffer com endereco base: ldi r18, (low)abBuffer ldi r19, (high)abBuffer ;enderecamento direto: sts wBaseEnd, r18 sts wBaseEnd+1, r19 ;limpa flag de buffer cheio: clr r18 sts bFlag,r18 ;retoma contexto: pop r19 pop r18 ;encerra funcao ret ISR: in r0, SREG ;optei pelos high registers pois aceitam qualquer instrucao push r0 push r18 push r19 ;preciso do registo X para enderecamento indireto: push r26 push r27 ;preciso do Y tambem push r28 push r29;Inicia processo da ISR: ;carrega endereco mais baixo do register MAP, no caso PINC: ldi r28,(low)PINC ldi r29,(high)PINC ;carrega endereço do buffer: lds r26, wBaseEnd lds r27, wBaseEnd + 1 ;recupera PINC lds r18, Y ;salva no buffer: sts X+, r18 ;aponta a posicao de TCNT0 na RAM: adiw r28:r29, $20 ;pega timer 1: lds r18, Y ;salva no buffer: sts X+, r18 ;aponta a posição do timer 1: adiw r28:r29, $40 ;acessa lds r18, Y+ ;buffer: sts X+, r18 ;acessa parte alta: lds r18, Y ;buffer: sts X+ ;checa se encheu o buffer; ldi r18, (low)(abBuffer + 1024) ldi r19, (high)(abBuffer + 1024) ;checa se zerou: cmp r18, r26 brne NAO_ENCHEU ;checamos a parte alta: cmp r19, r27 brne NAO_ENCHEU ;se encheu seta o flag de buffer cheio: ldi r19, $0FF sts bFlag, r19 ;recarrega endereço com valor inicial: ldi r18, (low)abBuffer ldi r19, (high)abBuffer ;enderecamento direto: sts wBaseEnd, r18 sts wBaseEnd+1, r19 ;PAULO POR FAVOR CHEQUE SE PRECISA: ;Derruba interrupcoes: cli jmp FIM_PROCESSO ;se nao encheu apenas salvamos o endereco de volta na RAM: NAO_ENCHEU: ;apenas guarda endereco na variavel destinada: sts wBaseEnd, r26 sts wBaseEnd+1, r27 FIM_PROCESSO: ;retoma contexto: pop r29 pop r28 pop r27 pop r26 pop r19 pop r18 pop r0 out SREG,r0 ;encerra ISR reti Veja se ajuda, e vamos nos falando Abs.

porta paralela é o problema, check this: http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT245BL.pdf Abs.

É... vamos as possíveis causas. Existe algum qualificador tipo volatile como C para que o Bascom ignore qualquer tentativa de otimização? Falo isso pois desconfio de uma hipotese: Você está usando um tipo de assembly chamado inline assembly no qual integra - se diretamente linhas em asm no código Basic, o que me faz muitas vezes mixar codigo C e assembly em arquivos separados é porque esse tipo de asm o compilador durante a montagem da imagem binária pode "não gostar " do que você fez e mudar totalmente as linhas de código. Em C quando usamos inline e queremos que mesmo assim o compilador nao mexa usamos volatile asm () e ainda assim dependendo da otimização usada ele vai lá e mexe. Isso pode ser um dos problemas. Pensei essa noite em formas alternativas e mais rápidas de fazer o que voce precisa, @aphawk, ficaria muito difícil pra você trabalhar com buffers cujo o tamanho em bytes sao potencias de 2? por exemplo 2048 bytes em vez de 1800? e outra, porque parar a contagem dos timers se os mesmos estão com prescalers de 1:8 o que em tese me da 8 ciclos de máquina disponível para capturar o valor do registro e salvar na RAM. Medo! Ainda confio mais nas medidas reais que fiz com o STK500 no AVR Studio hahahaahahha! Enfim, por enquanto é isso. Abs!

é só ler os dados de desempenho iniciais que o próprio @aphwak disse: De resto só pegar a rotina, o manual do instruction set do AVR e contar os ciclos, resultados práticos, só no debbuger ou simulador do AVR studio. Não disse que não dá, mas sou contra a filosofia de: "tudo por velocidade de execução", como ja disse fazer o que voce está propondo pode exigir mais registros do scratchpad do AVR, e causar register pressure, pelo menos nos high registers (r16 em diante), e fazer com que sobre somente os low registers que nao suportam todas as operações do set de instruções do AVR, eu iria por outro caminho para otimização, minimzar por exemplo os acessos a memoria RAM e abusar do endereçamento memory - to - memory, além disso me permita uma sugestã mestre, utilize potencias de 2 para determinar os tamanhos de seus buffers, alem de melhorar o alinhamento a memória, ajuda bastante para operações de watermark(checar se preenchemos um buffer por exemplo) e ainda permite o uso de um buffer circular, que acho mais adequado para sua aplicação. Enfim, boa sorte, e qualquer coisa grita! Abs. Felipe

Matou a pau, a simulação SPICE do Proteus é muito boa, acho que a simulação em tempo real é muito útil para sinais de largura de banda pequena, ou para simulação de waveforms que servirão de dado bruto para o sistema em teste. @aphawk, quanto custou a licença do Proteus? (visto que desde que entrei para a filosofia open source, estou evitando cada vez mais o uso de software hackeado, até minhas atuais IDE são livres ou paguei pela licença). Abs. Felipe.

Normal, deixe - me apenas refrescar as mentes a respeito do processo de compilação (independente da linguagem), primeiramente o compilador gera a partir da linguagem de programação usada o arquivo correspondente em linguagem assembly, esse(s) arquivo(s) é enviado ao assembler (montador) que converte tudo em linguagem de máquina e em seguida envia ao linker, responsável por alocar os módulos de código na posição desejada de memoria do processador, seja ela de programa ou dados. Paulo, o problema da sintaxe em geral eu já esperava, mesmo que o Assembly(linguagem) seja igual por ser AVR, o assembler(montador) varia de fabricante a fabricante de ferramentas, ou seja o do Bascom funciona de um jeito, o do GCC funciona de outro, e o AVRASM de outro, cada um possui sua propria diretivas e formas de escrita das instruções...por isso é bom nunca confundir conceitos, programa - se em assembly, e a ferramenta que coverte é o assembler. Fico feliz que tenha ajudado, eu imagino que seja possivel otimizar ainda mais, só que faz muuuuuito tempo que nao coloco a mão no assembly do AVR, apesar de gostar muito do funcionamento dele, no XMEGA de 16bits esse set de instruções é melhor ainda, visto que nao preciso ficar fazendo de forma constante malabarismos com bytes (pra acesso ate 64KB de memoria de programa, usa - se endereçamento linear). Paulo, não acho que isso seja uma boa ideia, pois de qualquer forma voce precisaria configurar uma condição inicial e buscar o endereco base, além disso pode ser necessario usar mais registros o que poderia causar um fenomeno que pouca gente conhece mas muita gente despreza que é o register pressure, quando usamos mais registros que o necessario e a CPu quando retorna da ISR precisa usar muito mais pilha para preservar o contexto, além disso perderiamos mais ciclos pois seriam necessarios mais push e mais pops além disso vamos ganhar de um lado e perder do outro pois vamos ter que guardar o valor do offset na RAM o que implicaria em mais um acesso.Acha mesmo necessário isso? Qualquer coisa grita. Abs. Felipe

@aphawk, só pra tirar um sarro: C 1 x 0 Basic HAahhaahahahahhah! Abs. Felipe

Esse projeto tende a ser interessante, hehehehe! Abs. Felipe

Mestre @aphawk, veja se isso lhe atende: ;Listagem para tratamento de interrupcao do analisador logico.DSEG ORG 0x40 ;coloca no começo da area de ram por acesso diretobCounter .BYTE 2 ; aloca 2 bytes para o contador de memoriabFlag .BYTE 1.DSEG abBuffer .BYTE 1800 ; aloca 1800 bytes para o bufferISR:;Salva somente os ultimos argumentos:; 4 registros sao mais que suficientes: in r0, SREG;optei pelos high registers pois aceitam qualquer instrucao push r0 push r16 push r17 push r18 push r19 push r20 push r21;preciso do registo X para enderecamento indireto: push r26 push r27 ;para contagem do timer 1 colocando 0 no prescaler:;infelizmente ele nao possui acesso imediato entao ;terei que mapea - lo em memoria ld r16,TCCR1B andi r16,$F8 st TCCR1B, r16 ;leitura do portc: in r19, PINC ;leitura do timer 1: ld r16, TCNTL1 ld r17, TCNTH1 ;calcula o offset de memoria desejado;para acesso:;pega o valor do contador atual: ld r20, bCounter addi r20, (low)abBuffer;coloca lsB em XLOw: mov r26,r20;agora define a parte alta: ld r0,bCounter + 1 ldi r20,(high)abBuffer addc r20, r0;coloca MSB em XHIGH: mov r27,r0;salva TIMER1 na RAM st X+,r16 st X+,r17;acessa valor do timer0: in r16, TCNT0 st X+, r16 ;acessa timer 1 e recoloca o prescaler 1:8;agora voltou a funcionar ld r16, TCCR1B ori r16, $02 st TCCR1B, r16 ;guarda portc na RAM: st X+, r19 ;checa se o buffer ja foi preenchido: mov r20, r26;carrega tamanho maximo do buffer low: ldi r21, ((low) abBuffer + (low)1800) ;ccheca se atingiu o valor: cp r20, r21 brne FIM_ISR: ;se deu zero vejamos se a posicao final do buffer tbm foi atingida: mov r20, r27 ;carrrega parte alta do buffer: ldi r21,((high) abBuffer + (high)1800) ;checa por um zero aqui: cp r20, r21 brne FIM_ISR;se atingiu o buffer entao limpamos o contador: clr r0 st r0, bCounter st r0, bCounter + 1 ;marcamos buffer cheio no flag: ldi r21, $0FF st bFlag, r21 ;derruba timer 1 escrevendo 0 no prescaler ld r16,TCCR1B andi r16,$F8 st TCCR1B, r16 jmp FIM_PROCESSO FIM_ISR:;incrementa posicao na RAM ld r20,bCounter; a RAM avanca 4 posicoes a cada iteração addi r20, $04 st bCounter, r20;calcula deslocamento na parte alta clr r0 ld r20, bCounter + 1 addc r0, r20 st bCounter + 1, r20 FIM_PROCESSO: ;retoma contexto: pop r27 pop r26 pop r21 pop r20 pop r19 pop r18 pop r17 pop r16 pop r0 out SREG,r0;encerra ISR reti Ah! Desempenho medido no debbuger (STK500): Melhor caso: (buffer ainda nao encheU) 54 ciclos de maquina Pior caso (buffer cheio): 59 ciclos. Todo o desempenho medi incluindo o reti e todos os branches usados nesse codigo. Se tiver duvidas por favor me avise. PS: tive que fazer algumas brincadeiras na memoria RAM pra aumentar o desempenho, E antes que esqueça, que arquitetura do c*r*l*o! Abs. Felipe

É o caminho natural das coisas, apesar de ser chato ficar repetindo, antes de conhecer IDE, linguagem de programação, assembly que o compilador gera, programar em assembly, mememememememem, é preciso conhecer a máquina que você tem na mesa, microcontrolador nada mais é que um tópico avançado de circuitos digitais, ficar com medo de uma listagem em assembly é coisa de pessoa que nunca leu um datasheet ou mesmo um manual de referência do processor, e fica frustrado quando o led nao pisca usando um framework pronto (Arduinos e afins). Se é leigo, comece do começo, não pense em tentar conhecer seu micro se nao sabe o que é um registrador. Ta mas vai ter gente que vai me dizer que o cara quer ver funcionando pra se motivar, e eu concordo, ver a coisa acontecendo ajuda e muito, o grande problema é quando o cara avança desse ponto antes de ir pra trás buscar aos poucos o que motivou a coisa acontecer... e ai acontece o que vemos muito no forum, estudantes desesperados em fazer seu TCC funcionar querendo sempre tudo pronto, é mandar o cara ler um datasheet pra ele abandonar o tópico. Desabafos a parte, @aphawk, acabei de fazer uma listagem no papel de pao e vou simular quando sair do trabalho e posto o resultado aqui. (o Basic tem inline assembly?) Abs. Felipe

Vou ver no que posso ajudar. usando os registros X,Y,Z que funcionam como datapointers da pra fazer tranquilamente essa rotina... Abs. Felipe

Deixa eu dar meu pitaco, Écati! (hahahahahah!). Antes mesmo de pensar na linguagem que vai programar, o primeiro passo que costumo recomendar é conhecer um pouco da sua máquina, no caso seu PIC12 de uma lida, mesmo que pouco entenda de eletronica, no datasheet e no set de instruções pra ver o que ele pode executar (e Não, não estou falando para ele programar em Assembly). A partir daí é legal pensar o que usar para desenvolver com ele, se vai usar o MPLAB por exemplo, se vai programar em C,Basic, Assembly ou C++,quanto a isso nao me limito em dizer o que é melhor ou mais fácil, existe ótimo material aqui no forum escrito pelos colegas incluindo o saudoso @aphawk. Em alternativa ao Simulator IDE, use o Proteus para ver a execução do seu código ou mesmo o debugger do ambiente de programação (e aqui vai uma crítica, pessoal mais velho, vamos incentivar o uso do debug da ferramenta, é mais dolorido o caminho, mas ensina muito mais do que usar somente o proteus ou o "zoiometro" para achar erros no projeto). Concordo e discordo, isso vai depender da sua demanda de aprendizado, talvez com um PIC12 você consiga absorver mais conhecimento de microcontroladores tendo que fazer muito com pouco, do que partir para um "true RISC" como o AVR, a arquitetura dele é um pouco mais complexa, mas como ja disse depende mais da sua evolução. Sou fã da família Arduino, mas como dica de aprendizado, evite esses caras por enquanto, eles lhe vão lhe dar muito mais recursos que real aprendizado, diferente de pegar um micro e escrever o codigo de inicialização e operação sozinho... sou entusiasta do tipo: "primeiro morda o traseiro do boi, depois compre boi ralado". Boa sorte e se precisar estamos aqui. Abs. Felipe

@Projetos_afg, ta ficando bom esse tutorial hein Alguns comentários, Isso é uma coisa que acho ruim nos ARM, e em outros RISC com arquitetura Harvard, na verdade ai está a razão para compiladores C fazerem estripulias para manter uma boa relação densidade de código x velocidade de execução, como o ARM so possui dois tamanhos de instruções e alinhada a memória o compilador tem que se virar com isso. Essa é uma característica que falta a ele mas presente em outros micros de 32bits como o PIC32 (MIPS M4K) e RX600 que possuem VLE (Variable Code Length) em que uma instrução pode ter diferentes comprimentos, melhorando muito a densidade de código sem descuidar da velocidade. Outra grande coisa chata, que me faz sentir saudades até do lerdão ARM7TDMI, são essas interrupções vetoradas, o NVIC não, ele é sensacional, os vetores ficam estaticos, com uma tabela definida em um local, e cada ferramenta implementa essa tabela de uma forma diferente e vai la no linker e acerta as seções de memória como bem entende... o que dificulta por exemplo escrever um RTOS portável entre micros ARM - CortexM de diferentes fabricantes. Em micros como o dsPIC, os C2000 da TI e o ARM7TDMI a tabela ja era mapeada em memória bastando passar um ponteiro de função para o registrador correspondente o que facilitava e muito na hora de configurar uma interrupção. PS.: o NVIC é legal, só é chatinho de configurar no começo. Que venham as próximas partes Abs. Felipe