ComparaÇÃo em assembly do pic

[Pask]

Amigos, utilizando qualquer um dos canais A/D do PIC para fazer a conversão de um nível de tensão analógico para digital e usando a linguagem C para analisar o valor convertido, um fragmento do código poderia ser escrito assim (compilador PCWHD da CCS):

int16 x; / / declaro uma variável inteira x de 16 bits

x = read_adc( ); / / copio na variável o valor lido pelo canal AD do PIC

if (x < 983).... / / caso o valor de x seja menor do que 983, tomo a decisão e o programa continua daqui.

-----------------------------------------------------------------------

A minha pergunta é bem simples: usando o mesmo raciocínio para linguagem Assembly, como eu poderia escrever o mesmo fragmento de código nessa linguagem?

Em assembly, a ideia é usar a resolução máxima do AD (10 bits) e fazer exatamente a mesma comparação com o mesmo valor numérico do exemplo acima. Como fazer?

[Mulder_Fox]

Para qual modelo de PIC será o programa?

É que as instruções disponíveis variam conforme o modelo.

[Felipe Electronic]

Talvez assim:

CBLOCK 0X20 ; DECLARO VARIAVEIS
  XHIGH 
  XLOW
  ADHIGH
  ADLOW
ENDC     ;FIM DAS DECLARAÇÕES

.
.
.

;CONFIGURAÇÃO DO A/D

MOVLW B'11000001' ;CANAL 0, CLOCK INTERNO, ADLIGADO
MOVWF ADCON0
MOVLW B'10001110' ;RA0 COMO ENTRADA ANALÓGICA, RESULTADO A direita 
MOVWF ADCON1
CLRF    ADRESH
CLRF    ADRESL  ;LIMPA REGS DO A/D

.
.
.
LOOP:
   CALL LE_AD
   CALL COMPARA
.
.
.

LE_AD:
        BSF     ADCON,GO ;INICIA CONVERSÃO
        BTFSC  ADCON,GO ;TERMINOU?
        GOTO   $ -1     ;AGUARDA TERMINAR
        MOVFW  ADRESL
        MOVWF  ADLOW ;GUARDA PARTE BAIXA
        MOVFW  ADRESH 
        MOVWF  ADHIGH  ;GUARDA PARTE ALTA.
        RETURN


COMPARA:
       BCF       STATUS,C
       MOVLW  0X03  ;COLOCA PARTE ALTA DE 983 EM HIGH
       MOVWF  XHIGH
       MOVLW  0XD7 ; E A BAIXA EM LOW
       MOVWF  XLOW  
       MOVFW  XHIGH
       SUBWF   ADHIGH,W
       BTFSC    STATUS,C
       GOTO     Rotina_se_x_menor ; SE  PARTE ALTA DE X FOR MENOR DESVIA DIRETO
       BCF        STATUS,C
       MOVFW  XLOW   ;SENÃO VERIFICA APARTE BAIXA
       SUBWF   ADLOW,W
       BTFSC    STATUS,C
       GOTO     Rotina_se_x_menor
       RETURN   ; X É MAIOR QUE 983.

Ufa!

Veja ai!

Abs.

[Pask]

Valeu Felipe. Acredito que era exatamente isto que eu estava querendo mesmo...rsrsrsrs

Depois, vou criar o código fonte, simular e gravar no PIC 16F876 para testar se funciona. Depois te dou um retorno para confirmar se deu certo e, se tiver alguma modificação, passo para todos aqui.

Essa linguagem assembly é chatinha mesmo....!!! Viva a linguagem C!

Brigadão a todos.

Pask.

[Felipe Electronic]

Essa linguagem assembly é chatinha mesmo....!!! Viva a linguagem C!

Não fala assim, desse jeito nós do ASM ficamos magoados kkkk.

A vantagem dessa brincadeira em asm sem dúvida é a eficiência e o menor tempo de execução pra fazer a mesma brincaderia em C.

Infelizmente o C do CCS não é eficiente em termos de geração de código, e as poucas instruções do PIC16 também não ajuda, e acaba por não compensar usar um compilador C em um MCU com pouco poder, o que ja muda totalmente na familia pic24 e dsPIC30

Abs.

[Pask]

Eu considero a linguagem assembly a linguagem dos "masoquistas"....kkkkkk !!!

Apenas uma curiosidade: no PIC24 e nos dsPIC30, o que muda, basicamente, com relação à linha midi range de PIC's ?

[Felipe Electronic]

Tudo, em termos de programação.

Algumas vantagens:

- Ambos 16 bits contra 8 do PIC

- Velocidade de até 28MIPS com PIC24 e mais de 30MIPS com dsPIC30F

- Set de instruções mais poderoso com multiplicação e divisão.

- Familia dsPIC possui um núcleo DSP que alem de MCU ele consegue realizar funções complexas voltadas para processamento de sinais.

- Compilador C30 da própria microchip, que gera o código de C para máquina com muito mais eficiencia compensando assim o uso da linguagem C

- Bibliotecas prontas e programas utilitarios para as mais diversas aplicações.

Abs.

[Pask]

Realmente não resta dúvida que esses novos modelos de PIC são mais poderosos mesmo.

Mas, e esse compilador C30 da Microchip? Ele certamente não é gratuito.

[vtrx]

Eu considero a linguagem assembly a linguagem dos "masoquistas"....kkkkkk !!!

Um dos motivos que não programa µc em C é a 'limitação' de rotinas e algorítimo,voce tem que dar muitas voltas para chegar a um resultado, na maioria ,perto da lingaguem de máquina.

A vantagem do 'C' é digitar pouco e rezar para tudo dar certo,porque se voce tiver que 'debugar'...ferrou,heheh.

Mas, e esse compilador C30 da Microchip? Ele certamente não é gratuito.

Mais uma contra...

e acaba por não compensar usar um compilador C em um MCU com pouco poder

Sinceramente,acho que para microcontroladores,inclusive DSP,não compensa na maioria.

[Pask]

Eu acho que é exatamente o contrário: com linguagem C é que não precisamos dar voltas e sim com assembly. O assembly gera um código menor mas é uma linguagem mais voltada para a máquina; enquanto que o C é uma linguagem mais próxima do programador.

E, no fundo no fundo, o que o compilador C faz é converter o código escrito em C para assembly para depois gerar o arquivo executável a partir das instruções assembly já geradas, ou seja, o compilador C apenas tira o "trabalho pesado" das mãos do programador. Mas, no fim, vai tudo para o mesmo lugar...E isto é ótimo, porque num caso como uma simples comparação do valor de uma variável com uma constante, como no meu exemplo, em C limitamo-nos a digitar tão somente a expressão como ela é representada matematicamente mesmo (x < 983). Já, para fazer a mesma coisa em assembly, é preciso usar malabarismos com instruções SUBWF, SUBLW, BTFSC STATUS, C, ETC...

Para um outro programador que pegue um código em assembly pronto para ler, é quase impossível entender o que está acontecendo se o programa não for bem comentado.

Já em C, mesmo um código sem comentários do seu criador, pode ser lido sem muita dificuldade por outro conhecedor da linguagem!

Acho que é isso aí.

[Felipe Electronic]

E, no fundo no fundo, o que o compilador C faz é converter o código escrito em C para assembly para depois gerar o arquivo executável a partir das instruções assembly já geradas, ou seja, o compilador C apenas tira o "trabalho pesado" das mãos do programador.

Pask,

Concordaria comigo que se fosse exatamente assim, ninguem, afirmo ninguém mesmo programaria em assembly, o fato do compilador C gerar o código em assembly não significa que o código gerado está em sua otimização máxima e menor tempo de processamento, em muitos compiladores como o CCS o código ASM e depois o HEX gerado são ineficientes pois na passagem de um codigo C para ASM são geradas pelo compilador C instruções desnecessárias que acabam por comprometer o tempo de processamento de cada instrução.

Veja que para acessar uma memoria I2C em asm por exemplo você obtem controle total dos sinais envolvidos e dos seus tempos de execução, o que não acontece na linguagem C pois a maioria dos periféricos suas configurações são funções prontas que ao compilarmos o programa sabe se la que instruções em assembly o compilador vai gerar ja ouvi falar que para configurar o A/D por exemplo ele acerta bit a bit cada registrador ou seja um mar de tempo jogado fora.

por outro lado quanto a isso aqui:

Sinceramente,acho que para microcontroladores,inclusive DSP,não compensa na maioria

Discordo, pois uma coisa é programar em C com um MCU portador de apenas 35 instruções e com apenas um registrador que acessa diretamente a ULA no caso o WREG, para fazer um voltimetro digital com LCD.

Outra coisa completamente diferente é construir em C uma interface com display colorido tipo QVGA, usando uma máquina RISC com elevado poder de processamento e mais instruções de base, fora o compilador para essas máquinas possuem a caracteristica de gerar o código em asm com extrema eficiencia, trabalho com processamento de sinais, e ja consegui conceber uma rotina de um Filtro Digital FIR usando calculos em ponto flutuante em C com EXATO tempo de execução do mesmo Filtro em ASM.

Porém mesmo nesses processadores mais avançados a necessidade de realizar funções complexas (transformadas de laplace, integrais, MACS,etC) para tratamento de um sinal de radar de aviões onde a precisao deve ser máximas necessitam de uma porção de código ASM em massa para garantir o menor tempo de execução possivel e hoje a maioria (senao todos) os compiladores C permitem que rodemos o assembly embarcado como subrotina, agora não viabiliza no caso da interface QVGA ou de uma compressão tipo G_711 para áudio, onde manipular bit-a-bit para gerar uma tela gráfica, tratamento de toque pelo usuário e gerencia de menus, ou para manipular buffers, executar um adaptador preditivo é completamente iniviável nenhuma empresa tem tanto tempo disponivel assim de desenvolvimento sem contar que um debug MACRO desse firmware iria ser um inferno.

Ufa acho que falei muito, mas ambos os conceitos tanto o do amigo VTRX e do amigo PASK tem seu fundo de razão, porém eles se completam, ambas as linguagens andam em conjunto cada qual com suas vantagens em cada momento do projeto.

Abs.

[Fervolt]

Boa noite,

Concordo plenamente com o Felipe e o vtrx, chegará o dia em que o amigo Pask precisará controlar o tempo das instruções onde cada microsegundo (ou nano) é importante e decisivo para o sucesso do programa ao todo, comigo foi assim, enquanto meus programinhas não requeriam precisão, fui fazendo em C e usando muitas vezes clock interno quando disponivel, então numa ocasião eu precisava de um pulso alto de 4,7us e tempo baixo de 52,6us e aí??, será que "delay_us(5)" e "delay_us(52)" deram certo?? É..., não deu nada certo, alias o resultado foi tão absurdo de ruim que desanimei com C. Me falta aprender muuuuito ainda sobre os PICs e outros uC, mas acho muito gratificante quando a gente escreve um código em assembly e pode ver esse código executando perfeitamente como desejado na tela de um osciloscópio, por exemplo.

Isso é só mais um "causo" para demonstrar que nem sempre a "lei do menor esforço" funciona.

A propósito, é linguagem Assembly ou Assembler?? tenho um livro que se refere à linguagem como Assembler, no meu entender e o que eu ja li sobre "computação antiga", Assembler era o compilador e a linguagem era Assembly.

Abç

Fernando Voltani

[vtrx]

Discordo, pois uma coisa é programar em C com um MCU portador de apenas 35 instruções

É que eu programo tambem,não na maioria das rotinas,em ASM pro PC então para mim DSP é normal.

Ja ví muito programador em C usando DSPIC ter problemas para trabalhar com audio em tempo real (rotinas lentas).

A maioria dos compiladores C para µcontroladores,tem bugs pois um compilador nunca pensará como um humano,veja o CCS,se voce criar varias rotinas de delay,ele gera uma rotina para cada delay,enquanto em ASM voce pode apenas trocar algumas variaveis e reutilizar a princiapal.

Agora depende de cada projeto,os meus são mais voltados a hardware e não podem depender de restrições de programação ou bibliotecas prontas.

[Felipe Electronic]

Para esclarecer as coisas:

Assembly = linguagem de programação;

Assembler = montador, refere -se a montar a linguagem assembly ou seja fazer a sua conversão para a linguagem de máquina, é ele que usamos quando selecionamos a opção build.

A maioria dos compiladores C para µcontroladores,tem bugs pois um compilador nunca pensará como um humano,veja o CCS,se voce criar varias rotinas de delay,ele gera uma rotina para cada delay,enquanto em ASM voce pode apenas trocar algumas variaveis e reutilizar a princiapal.

Foi uma desvantagem que acabei de citar, além do mais em C com um MCU de 8bits não tem muito o que fazer na hora de projetar um compilador C = > ASM => Hex sendo que o disposistivo tem os problemas que eu ja mencionei.

Agora com MCUS de 16bits para cima e maquinas ARM, a programação em C se torna vantajosa até porque compiladores como o IAR (blackfin, texas, NXP) foram mais precavidos ao projetar o compilador usando o máximo de otimização e aproveitando o set de instruções ao máximo dessas novas máquinas.

Ja fiz rotinas em assembly, para um controlador PID, que desenhava o processo controlado em uma tela gráfica, o desenvolvimento foi um inferno, perdi muito tempo. Tempos depois fiz a mesmo firmware só que usei a lei do menor esforço para fazer a interface, pois nao preciso de desempenho para interagir com um humano, agora o processo do PID (integração, derivação e o calculo do modelo matematico do processo) fiz em ASM, mas embarcado na linguagem C

Não sou a favor de um nem de outro, mas de ambos trabalhando em conjunto, pois todo mundo ganha, o desenvolvedor pela eficiência e a credibilidade, e o cliente pelo desempenho e pela aparencia final do projeto.

Abs.

[Pask]

Realmente, concordo com todos vocês em tudo que disseram. Eu não disse que não gosto do assembly. Apenas digo que ele dá mais trabalho para programar do que o C, devido aos "malabarismos" que exige do programador por ser uma linguagem mais voltada para a máquina. Porém, sem dúvida, o assembly é ótimo para quem está aprendendo e começando a conhecer um uC, pois obriga o programador a estudar seu datasheet para programá-lo, senão não vai mesmo! Portanto, assembly é uma linguagem educativa.

Com relação às rotinas de delay_us() do C, se você precisar de tempos bem pequenos, pode deixar de usá-las e habilitar uma interrupção de TIMER do PIC para gerar o tempo desejado ou mesmo usar uma diretiva do CCS que é delay_cicles(), que produz atrasos de tempo de n ciclos de máquina e, portanto, em curtíssimos espaços de tempo.

[vtrx]

dá mais trabalho para programar do que o C

Se for trabalhar com µcontroladores e não ter algum trabalho,seus projetos podem ficar 'genéricos'.

Portanto, assembly é uma linguagem educativa

Só discordo pois qualquer pessoa com mínimos conhecimentos de eletronica pode piscar leds,escrever em eeproms ou lcd etc apenas chamando bibliotecas prontas,típico de quem inicia.

Ja em ASM tem que ter conhecimento maior de Software/Hardware,aí está a diferença.

Com relação às rotinas de delay_us() do C, se você precisar de tempos bem pequenos, pode deixar de usá-las e habilitar uma interrupção de TIMER do PIC para gerar o tempo desejado ou mesmo usar uma diretiva do CCS que é delay_cicles(), que produz atrasos de tempo de n ciclos de máquina e, portanto, em curtíssimos espaços de tempo.

Veja por outro lado,voce tem que 'gastar' um timer só para isso,alem doque dentro desta rotina de tempo voce não tem controle.

Agora se uma pessoa tem dificuldade em trabalhar diretamento com o Hardware/Software,terá que utilizar o C ou 'subir' para o basic.

PS:Não estou desanimando ou condenando outros meios de programação,apenas observo que neste forum e muitos outros que conheço,existem muitas pessoas com deficuldades simples em terminar certas rotinas ou achar um erro justamente em C,e a solução é simples em ASM.

...agora o processo do PID (integração, derivação e o calculo do modelo matematico do processo) fiz em ASM, mas embarcado na linguagem C

Isso é o mínimo que se deve fazer.

[Felipe Electronic]

Isso é o mínimo que se deve fazer.

Depende, se o processo não exigir correção imediata e o tempo de desenvolvimento for curto, o que impede de usar uma linguagem de alto nível para elaborar uma malha de controle que possui a mesma eficiência e o resultado será o mesmo idependente do tempo levado para o processamento.

É isso que sempre levanto quando discuto qual linguagem, existem muitos fatores e variáveis não só do físicas de um projeto como fatores humanos, e administrativos que tem de ser levados em consideração, senão por melhor que seja o programador em assembly, ele vai ficar para trás e um cara não tão bom mas que tem razoavel dominio porém tem a mente aberta e um leque maior de ferramentas leva o projeto.

OBS.: Programo em assembly desde que PIC no Brasil era novidade, e 100% do que projeto tem nem que seja uma subrotina em ASM. claro que a familia PIC de 8bits é só assembly mesmo, assim como todos os 8bits que uso.

Abs.

Abs.

[vtrx]

ele vai ficar para trás

Se essa pessoa trabalha para uma empresa,tem que seguir as regras da empresa,mesmo que isso possa abrir brechas para concorrencia,tipo,com um produto novo que mal saiu e não tem bibliotecas específicas em C,terá que monta-las ou ja sair programando em ASM...

...o programador em assembly...

Como voce tambem programa em ASM,deve saber que quem programa em ASM,pode programar em qualquer linguagem.

[Felipe Electronic]

OFFTOPIC: Assim que gosto discussões, mas em alto nível por favor, assim ajudamos e esclarecemos muitos pontos mesmo com diferentes pontos de vista.

Mas voltando ao foco, vale lembrar que empresas são diferentes sim, porém uma regra é comum a todas, "resolver o problema de forma rápida" ou seja nesse contexto leva mais quem domina mais de uma ferramenta e as usa em conjunto e raramente o individuo que domina a melhor ferramenta (na minha humilde opinião ainda é o ASM kkkk).

Acho que ai repito a velha frase do amigo Paulo "nao importa a cor do gato desde que ele coma os ratos" e isso e verdade, uma coisa que mancha e muito o nome de linguagens de alto nivel para MCUs é o fato de muitos "programadores" abusarem apenas de bibliotecas prontas em vez de criarem suas próprias funções, ou seja querendo economizar onde não da, isso sou terminantemente contra.

Abs.

[Pask]

Amigos, me esclareçam uma dúvida sobre como o resultado de uma conversão AD é armazenada corretamente nos registradores de armazenamento do PIC16F876:

Suponhamos um valor analógico convertido para 615 decimal = 0x267 hexadecimal

Eu tenho o par de registradores ADRESH e ADRESL que tem, ambos, 8 bits de tamanho, totalizando um tamanho máximo de 16 bits para armazenar o resultado da conversão do AD. Evidentemente, vou precisar somente de 10 bits, pois o AD deste PIC é de 10 bits e 6 bits vão sobrar ou resultar em zero.

Se eu justificar o resultado da conversão à esquerda, eu vou preencher totalmente o reg. ADRESH e 2 bits de ADRESL.

Então, 0x267 = 1001100111 ADRESH = 01100111 e ADRESL = 10

Se eu justificar o resultado da conversão à direita, eu vou preencher totalmente o reg. ADRESL e 2 bits de ADRESH.

Então, 0x267 = 1001100111 ADRESL = 01100111 e ADRESH = 10

Seria isto?

Programando em C, a gente não precisa se preocupar com isto. Mas, já em assembly, temos que atentar para esses pequenos detalhes sim.

Alguém poderia confirmar ou elucidar essa minha dúvida?

Obrigado.

[vtrx]

Programando em C, a gente não precisa se preocupar com isto

Mais uma limitacão...

Se voce quiser trabalhar somente com 8 bits de conversão,voce pode justificar pela esquerda e acessar apenas a parte mais significativa através de ADRESH.Cria-se um filtro descartando 2 bits menos significativos de ADRESL.

Em ASM voce pode fazer tudo que o Hardware/Software permitir para otimizar o desempenho e código.Veja,quanto mais voce tiver opções,mais poderoso será seu Soft/Hard,além de algorítimos eficazes.

[Pask]

Amigos, não estou entendendo o seguinte. No fragmento de código abaixo, porque o resultado da operação dá positivo quando deveria se negativo?

MOVLW .2 ;w recebe 2

SUBWF ADHIGH,W ;o registrador ADHIGH já tem o valor 3 e o resultado da subtração vai para W

Por que W apresenta como resultado o valor 1 quando deveria ser negativo (2-3) ?

[vtrx]

Por que W apresenta como resultado o valor 1 quando deveria ser negativo (2-3) ?

Quando voce utiliza a instrução SUBWF,ela afeta tambem o Flag C,no registrador de status.

C=0 resultado negativo.

C=1 resultado positivo ou zero.

PS:Matérias relacionadas,subtração,divisão multiplicação Binária.

[Felipe Electronic]

para se fazer operações do tipo signed em assembly, é necessário "gastar" um bit dos oito que compoem o byte para que esse represente o sinal.

Porém para fazer operações de comparação com os oito bits basta fazer a conta e fazer polling(monitorar) o bit de carry presente no registrador STATUS, se você olha no meu codigo a cada subtração eu faço a seguinte linha:

BTFSC STATUS,C

Abs.

[Mulder_Fox]

Amigos, não estou entendendo o seguinte. No fragmento de código abaixo, porque o resultado da operação dá positivo quando deveria se negativo?

MOVLW .2 ;w recebe 2

SUBWF ADHIGH,W ;o registrador ADHIGH já tem o valor 3 e o resultado da subtração vai para W

Por que W apresenta como resultado o valor 1 quando deveria ser negativo (2-3) ?

Porque a instrução SUBWF faz f - W e não W - f