Metodologia de pensar em assembler para linguagem de mais alto nível

MOR_AL · 27 de fevereiro de 2016

Olá Pessoal!

Gostaria do auxílio de vocês. Explico.

Iniciei meus estudos com uC utilizando a linguagem Assembler. De tanto usar essa linguagem, acabei descobrindo um procedimento muito eficaz e direto, para passar da ideia do que o uC deve fazer até o correspondente Assembler.

Faço um fluxograma do firmware composto por blocos básicos, com relação quase direta com as instruções do uC. Cada bloco pode ser construído por uma ou duas instruções em Assembler. Na verdade crio um fluxograma complexo, formado por poucos blocos e vou desenvolvendo cada bloco em blocos mais simples, até chegar aos blocos em “quase Assembler”.

Isso me reduz enormemente o número de instruções em comparação com a linguagem C ou BASIC. Sendo assim, dedico essa linguagem a uC que possuem pouca memória flash.

O problema nasce à partir desta facilidade.

Quando o firmware exige matemática, ou precisa de muitas funções, o Assembler deixa de ser útil, sendo necessário enveredar para linguagem C ou BASIC. Até já fiz programas com estas duas linguagens, mas confesso que foram programas relativamente simples ou lineares.

Com o meu costume em usar Assembler, acaba ficando difícil “pensar” em linguagem de mais alto nível, que o Assembler.

Como exemplo, fiz um fluxograma de um trecho de programa (vide anexo), que dificilmente seria útil para servir de base para linguagens de maior nível que o Assembler.

Minha dúvida é a seguinte.

Pensando em fazer um programa em Basic ou C (estou mais acostumado com BASIC), como seria a metodologia para fazer um programa com a complexidade do fluxograma apresentado?

Em tempo:

1 - Blocos em negrito são rotinas.

2 - Blocos adoçados são endereços.

3 - Códigos como MW1 são endereços.

4 - Blocos condicionais possuem as respostas em suas saídas.

5 - Inclui algumas macros criadas por mim.

Em Assembler fica assim:

MW:
		btfss	Mo0
		goto	MW1
		call	EWdtEM
MW2:
		movlw	D'3'
		movwf	Partida
		bcf		LedTtotal
		call	T15us
		bcf		LedSobreCorr
		call	T15us
		bcf		LedSemAg
		movlw	D'80'
		movwf	Min
MW3:
		movlw	D'60'
		movwf	Seg
MW4:
		call	RSTCorr
		movlw	D'17'
		movwf	NumMedIBomba
MW5:
		call	T60ms
		call	IBomba
		decfsz	Partida,f
		goto	MW6
		movlw	D'1'
		movwf	Partida
		RMaIgV	SobreCorr, SobreCorrMa, MW7
		RMaIgV	SemAg, SemAgMa, MW8
		decfsz	NumMedIBomba,f
		goto	MW5
MW12:
		btfss	Wa0
		goto	MW9
		btfss	CxWChI
		goto	MW10
		bcf		EnW
		call	T15us
		bcf		EnM
		call	T15us
		bsf		LedCxWChO
		call	TLedW
MW11:
		bcf		Mo0
		bcf		Wa0
		clrf	TMR0
		bcf		INTCON,T0IF
		bsf		INTCON,T0IE
		bsf		INTCON,GIE
		goto	E1
MW1:
		btfss	Wa0
		goto	E1
		call	EMdtEW
		goto	MW2
MW6:
		call	T500ms
		call	T500ms
		goto	MW12
MW7:
		bcf		EnW
		call	T15us
		bcf		EnM
		call	T15us
		bsf		LedSobreCorr
MW13:
		goto	Erro1		
MW8:
		bcf		EnW
		call	T15us
		bcf		EnM
		call	T15us
		bsf		LedSemAg
		goto	MW13
MW9:
		btfss	Mo0	
		goto	MW14
		btfss	CxMChI
		goto	MW10
		bcf		EnW
		call	T15us
		bcf		EnM
		call	T15us
		bsf		LedCxMChO
		call	TLedM
		goto	MW11
MW10:
		decf	Seg,f
		btfss	Stt,Z
		goto	MW4
		movf	Min,f
		btfss	Stt,Z
		goto	MW15
		bcf		EnW
		call	T15us
		bcf		EnM
		call	T15us
		bsf		LedTtotal
		call	TLedT
		goto	MW11
MW14:
		bcf		EnW
		call	T15us
		bcf		EnM
		call	T15us
		goto	E1		
MW15:
		decf	Min,f
		goto	MW3

Grato às sugestões.

MOR_AL

.if · 27 de fevereiro de 2016

moris não vou te ajudar muito pois fluxogramas não pertencem ao meu mundo da programação (mas me pretencem sim ao de documentações, iso's e tal.. iéccaaa!!)

A dica que dou é... você já fez um pisca led numa outra linguagem? Quer um de presente com zero (0.00) de uso de lib's mastigadas? Em c, la vai...

//depende do uC e compilador mas quase tudo é lesma lerda do que vc lê no datasheet
#define led PORT0.0 //8051
//#define led RB0 //pic16...18F
//#define led GPIO0//pic12f
//#define led PORTB_Pin0//atmega..attiny
//***********************************************
#include "o_include_do_se_uC.h" //onde estão definidos os registros e etc
void delay(unsigned int dl)
{
while(dl--);//aguarda zerar. @10Mhz ou (-) cada iteração deve dar alguns uS
}
//***********************************************
void main(void)
//inicialise o hw definindo o pino como saída p.ex.
{
for(;;)//eternamente
{
led^=1;//inverte o estado
delay(10000);//se uC trabalhando @menos que 10MHz deve ser suficiente
}
}

Acho que nem preciso dizer que se aplica em virtualmente qualquer mc e tal's...

ok.. não te agregou nada mas quiçá sim a algum incauto navegante

você pode não acreditar mas (dependendo do compilador) o código acima pode ficar tão pequeno como se fosse feito em asm puro. E +... um programa + complexo pode ficar ainda menor. Não acredita? Não te culpo.

Basic... Paulão ou Chicão pode te ajudar

aphawk · 28 de fevereiro de 2016

Bom, pelo seu fluxograma noto que voce foi um bom aluno de Fortran, certo ?

Infelizmente não entendo muito desse assembly de Pic, senão eu te faria um programa em Basic quase idêntico linha a linha !

O que eu penso : se você chegou a um fluxograma para o Assembly, a implementação do programa fica extremamente facilitada, pelo menos no Basic, pois estruturalmente um programa em Basic pode ter exatamente os mesmos Jumps , Goto, Call e Gosubs que "desestruturam" o programa, fazendo aquele ninho de minhocas, trechos de programa que saltam para um lugar e voltam para outro logo abaixo ou logo acima, que são o terror dos programadores em linguagens de alto nível.

Falo por mim : Mesmo sabendo que o Bascom tem todos os comandos para se fazer um programa de forma estruturada, os anos de Assembly me deixaram "cego" para isso, e acabo escrevendo o programa em Basic da mesma maneira que escreveria em Assembly.

Para piorar, hoje em dia costumo ir escrevendo o programa sem fazer nenhum fluxograma, pois tenho uma certa fartura de memória de programa e Ram. Sei que se eu ficasse um dia pensando em fluxograma, acabaria otimizando muito o programa, e claro que ficaria bem menor, mas se tenho essa fartura, acho que isso não compensa.

O que que eu faria em seu lugar :

Faria o programa em Bascom, mas logo após a inicialização do hardware e das variáveis, passaria para Assembly, e só quando precisasse de algo em alto nível, como cálculos em ponto flutuante, matrizes, e outras coisas que seriam extremamente complicadas em Assembly, eu passaria a usar os comando do Bascom, e armazenaria os resultados dos cálculos em variáveis compartilhadas pelo Assembly e pelo Bascom, e voltaria a escrever o resto em Assembly..... aliás, se você olhar o meu tópico do Bascom, vai ver que eu ando misturando bastante Basic e Assembly nos projetos.

voce também pode incluir arquivos com macros, e o Bascom também permite compilação condicional.

Paulo

BCP · 28 de fevereiro de 2016

Colegas, sei que é um Off-Topic, mas tirem-me uma dúvida!

Depois de "escrito" um programa, em C ou C++, Fortran, Cobol ou Basic e etc. .., (linguagens de programação), Tem que ter um programa "adaptador" ou "compilador" para que seja "convertido" para a linguagem de máquina, "uns e zeros" né?

Para que isso tudo funcione, tem que ter um programa que transforma a linguagem usada para uma linguagem de mais baixo nível, seria o assembler né?

Ai, cada linguagem dessas, tem que ter um "tradutor" diferente?!?!?!...

PS: O excesso de aspas no texto é por pura ignorância no assunto!...

Tentei pesquisar no google, mas fiquei mais confuso ainda!!!....

aphawk · 28 de fevereiro de 2016

@Bcpetronzio ,

Cada microcontrolador tem um conjunto de instruções que ele entende, e que o fabricante disponibiliza no datasheet dele, que são mnemônicos que facilitam o nosso entendimento. Na verdade, o microcontrolador só entende números hexadecimais ( alguns entendem apenas números binários de 4 bits, outros de 8 bits, outros de 16 bits, e assim vai .... no caso que falamos aqui no Fórum, quase sempre são números de 8 bits ).

Essas instruções em mnemônico são o que chamamos de linguagem Assembly, e que pode variar conforme a família a que o microcontrolador pertence. O uso dos mnemônicos facilita muito a programação, pois é mais fácil lembrarmos de LD R1, 25h do que algo tipo 011h 025h que é o código-objeto que o microcontrolador realmente entende.

A gente pode programar direto em Assembly, e que quase sempre ( 99,99 % ) significa o menor e o mais rápido programa para ser executado, mas se for um programa um pouco sofisticado, demora muito mais para escrevermos e fazermos o Debug ( que é ver se o programa faz o que deveria fazer ) .

Já as linguagens de programação possuem comandos prontos que serão convertidos em uma série de instruções em código-objeto.

Quem faz essa transformação é o COMPILADOR, que pega o nosso programa em uma outra linguagem qualquer e transforma em código - objeto, que no final das contas é o que o microcontrolador entende. Neste caso ele também faz a função de Assembler, veja mais abaixo.

Cada linguagem tem o seu próprio compilador.

Quando estamos programando direto em Assembly, não sabemos os endereços reais na memória que será ocupada, e o compilador faz a função de Assembler ( montador ) : calcular endereços de programa e endereços de memória de dados e gerar o código-objeto , prontinho para ser executado pelo microcontrolador !

Realmente, é um pouco confuso ! O que é muito legal é ver como cada compilador traduz um determinado comando em uma sequência de código-objeto, o que é sempre muito difícil de entender, e portanto preferimos ver em seus mnemônicos ( que é a tal linguagem Assembly) para facilitar nossa compreensão !

Alguns compiladores fazem isso melhor que outros.

No caso que eu utilizo muito, que é o Bascom, ele é considerado muito eficiente tanto em tamanho do código-objeto gerado como em velocidade de execução.

Mesmo assim, muitas vezes não conseguimos ter a velocidade que pretendemos, e nesse caso temos de programar em Assembly, para termos o total controle do que que o microcontrolador está fazendo.

A única linguagem que é transformada diretamente no código-objeto é o Assembly; todas as outras geram vários códigos-objetos diferentes para um único comando. Este é o motivo de se dizer que a única linguagem onde o programador realmente tem o controle de tudo o que acontece é o Assembly.

Paulo

BCP · 28 de fevereiro de 2016

Beleza Paulo!,

.if · 28 de fevereiro de 2016

@Bcpetronzio você até que traduziu direitinho o que ocorre nas entranhas da coisa.

Voltando a fluxogramas, até que pra um ambiente acadêmico eles têm sim seu valor. Mas (sempre tem um mas) aqui fora na vida real penso não ser totalmente útil. Pra um sistema complexo p.ex. haverão perdas preciosas de tempo fazendo sua composição pra depois fazer sua tradução pra linguagem e tal.

Devo sugerir o caminho do meio, de fato as duas coisas e o caminho inverso. Termine o projeto, apresente, venda e acalme o setor financeito. Depois com calma documente o projeto com fluxogramas pra facilitar a vida da manutençao e fazer alguma graça pra algum auditor chato.

Espero não precisar de dizer que é . de vista pessoal né...

MOR_AL · 28 de fevereiro de 2016

Apenas um detalhe Isa!

No meu caso, o fluxograma vem antes do Assembler.

Com o fluxograma eu faço um "quadro geral" do programa. Depois vou dissolvendo cada bloco do fluxograma em um grupo de blocos elementares, facilmente conversíveis em Assembler.

Segue um pequeno exemplo da sequência da metodologia.

MOR_AL

mario cesar berardo · 28 de fevereiro de 2016

Bacana essa maneira de montar a lógica, gostei. Vai montando a lógica em função dos requisitos.

aphawk · 28 de fevereiro de 2016

@MOR ,

Você está acostumado a quebrar o problema em partes pequenas, que é exatamente uma grande vantagem ao se fazer o fluxograma.

Da maneira detalhada que você faz, pode manter o mesmo método no Basic, que você vai se sentir "em casa".

Quando eu programava profissionalmente, também tinha de fazer os fluxogramas, que se tornavam grandes e acabava fazendo em folha A3. Demorava alguns dias para fazer, mas depois disso a programação era muito mais fácil, e permitia "modularizar" vários procedimentos, criando macros que depois eram usadas em outros programas.

Como eu programava para o Z80, logo começei a usar um Apple ][ com CP/M para rodar o L80, M80 e o Wordstar ....., e o Kermit para subir o programa ao hardware para rodar em Ram mesmo para debugar. E acabei usando a linguagem Basic do Apple para fazer o interfaceamento serial entre o hardware de controle de processos e a tela de visualização, colorida e de muito boa qualidade para a época.

Pouco tempo depois, começei a usar um IBM PC com processador Nec-V20, e assim pude manter o mesmo processo, rodava o CP/M no PC ( santo V-20 ! ) , usava as mesmas ferramentas, e usava o GWBasic para fazer a montagem das telas de visualização do controle de processos, baseado no MS-Dos. Resumindo : o Bascom é muito pareçido com o GWBasic, e continuo me sentindo à vontade até hoje !

Acredito que voce também vai se sentir assim...

Paulo

.if · 28 de fevereiro de 2016

ok môr. Isto estava claro sim amigo. 'Suspeitei desde o princípio' literalmente.

Fluxograma é uma linguagem universal que qualquer um (talvez exceto eu kk) entende com facilidade e fica + fácil pra mostrar em 'paralelo' com asm sendo portanto um adicional e tanto aos comentários. De novo, é uma excelente ferramenta pra mostrar pros 'alunos'. Mas como isso não me pertence, ainda penso que linguagem de nível médio sendo + intuitiva do que assembly pode-se portanto dispensar tal carga cronológica adicional. De novo, falando daqui de fora.

Sabia que existe programa pra você programar um mc apenas arrastando blocos? Tipo Programação Orientada a Objetos. poo.. que mrd kk. Só que esqueci o nome dele. Por enquanto veja o VDI da microchip

pra quem tem um pouco de 'preguiça' é um prato cheio ... de poo kk

MOR_AL · 29 de fevereiro de 2016

2 horas atrás, mario cesar berardo disse:

Bacana essa maneira de montar a lógica, gostei. Vai montando a lógica em função dos requisitos.

É isso aí. .. E tem dado certo.

Paulo.

Eu usava o QuikBasic e gostava muito. Apenas uma vez fiz um programa com o 8085, claro que em Assembler.

Isa!

Vou dar uma olhada no link, que você colocou.

Pessoal!

Valeu pelas dicas. Vou ter que me acostumar com as novas metodologias.

[]'s

MOR_AL

.if · 29 de fevereiro de 2016

Môr... me lembrei... flow code

https://www.matrixtsl.com/flowcode/

MOR_AL · 1 de março de 2016

Isa!

O link anterior é para PICs mais robustos e só funções iniciais.

O Flowcode custa cerca de mil Dilmas.

MOR_AL

aphawk · 1 de março de 2016

Isadora,

Dá uma olhada aqui :

http://listoffreeware.com/list-of-best-free-flowchart-software-for-windows/

Todos são freeware, e fazem bem o serviço.

Paulo

.if · 1 de março de 2016

Paulão, será que existe um fluxograma explicativo para criar fluxogramas? kk. Dei uma olhadela. Parece bacana.

Moris, apesar de fazer toda a diferença, o fator custo não estava em pauta até então. Mas aquilo tem versão trial 30 dias, e 2º ele, você cria em minutos seu programa. Portanto, dá pra fazer coisa paraca cete. E+: tem uma maneira legal de fazê-lo ficar trial por infinitas vezes sem precisar reformatar. E o + legal, legal. Mas este não é o foco do tópico

Sim o VDI não é qualquer um (mC) mas pensei erroneamente haver alguma ligeira conexão com seu tópico

Bons estudos!

MOR_AL · 1 de março de 2016

Vou pegar o fluxograma de minha postagem inicial e tentar transformá-lo em linguagem de mais alto nível que o Assembler.

Para isso vou considerar as sequências de blocos sem desvio como apenas um bloco, já que o ponto crítico está nos blocos condicionais.

Assim que eu tiver algo, postarei aqui.

MOR_AL

MOR_AL · 1 de março de 2016

Pessoal!

Fiz a passagem do fluxograma, pensado em Assembler, para o BASIC.

Parece que está certo, mas gostaria da avaliação dos entendidos.

Apesar de ser em BASIC, acredito que o pessoal da linguagem C também entenderia, já que é mais fácil. Portanto, aguardo o pitaco do pessoal do C também. (claro que é sobre a solução e não sobre as intermináveis discussões entre C e BASIC).

Como mencionei antes, cada conjunto de blocos lineares foi substituído por apenas um bloco.

Para facilitar o entendimento, substituí o interior dos blocos por letras do alfabeto. Fica mais simples.

Em anexo segue o fluxograma original (em preto) e os correspondentes blocos com letras (em vermelho).

O anexo seguinte já é a passagem do fluxograma total para o equivalente alfabético.

Depois, segue o trecho do programa correspondente ao fluxograma.

Espero que se divirtam.

MOR_AL

.if · 1 de março de 2016

Moris, + tarde dou uma olhadela menos superficial. Por hora, fique com esta crítica construtiva... Se achar que deve, prefira usar os simbolos padrão de fluxogramas. Penso ficar + simpático e... padrão

abç

MOR_AL · 1 de março de 2016

2 horas atrás, Isadora Ferraz disse:

Moris, + tarde dou uma olhadela menos superficial. Por hora, fique com esta crítica construtiva... Se achar que deve, prefira usar os simbolos padrão de fluxogramas. Penso ficar + simpático e... padrão

abç

Oi, Isa!

Eu até que usava estes símbolos, mas à medida que o número de blocos no fluxograma aumentava, os símbolos diferentes de simples retângulos, ocupavam mais espaço. Em outras palavras; a densidade de blocos por página diminuía. O tempo passou e acabei verificando que basta um bloco retangular, para conter todas as informações do fluxograma com blocos convencionais.

Você sabe, se puder colocar mais informação em uma imagem, ela fica mais rica.

Realmente o fluxograma com os blocos convencionais é muito mais bonito, porém o que uso é mais "geométrico".

MOR_AL

.if · 1 de março de 2016

ok moris. Só que neste caso acho que transcenderia a beleza, ficando de + fácil compreensão pra quem tem mínimas noções de fluxogramas. Mas se ficou bom pra você, então tudo bem.

Aceita mais uma? Então lá vai... que tal se descrevesses do que se trata este projeto? Me parece ser algo relacionado a controle de temperatura ou algo do gênero. Talvez ficasse + fácil acompanhar o fluxo das ideias. Bom, digo isso por mim e não pela maioria que deve ter compreendido sua proposta. Enfim...

O basic deve ter evoluído bastante. Na minha época a sintaxe era diferente. Também pudera... o último contato que tive com ele foi no século passado.... no milênio passado. Enfim...

aphawk · 2 de março de 2016

@MOR ,

Pelo que ví, está correta a sua implementação em Basic, e ainda por cima está estruturada !

Eu raramente uso essas estruturas DO WHILE , prefiro os velhos IF e Goto kkkk

Interessante que a indentação dos condicionais, no canto da esquerda, são quase identicas à que o Bascom cria no fonte.

Pode programar desse jeito que está perfeito.

8 horas atrás, Isadora Ferraz disse:

O basic deve ter evoluído bastante. Na minha época a sintaxe era diferente. Também pudera... o último contato que tive com ele foi no século passado.... no milênio passado. Enfim...

Isadora, uma dama nunca revela a sua idade ....!

Olha, a principal vantagem que vejo no Basic são os comandos específicos para tratar o hardware. Existem comandos para inicializar e configurar todos os módulos internos, sejam Timers, Adcs, Comparador Analógico, Counters, vários tipos de interfaces seriais como I2C, SPI, serial comum, Modos de baixa energia, Watchdogs.... Enfim, fica muito mais simples esse trabalho.

Experimente um desses modernos Basics, tem o Bascom para a linha AVR ( Atmega, Attiny e Xmega ), e tem o MikroBasic para os Pics. Ambos possuem versão demo que podem gerar objetos até 4K.

E lembro também que na linha AVR a memória é linear, igual a um 8080 ou 8085 ou Z80... não tem a encheção de saco de bancos dos Pics..... O Assembly é muito mais simples, e voce pode incluir tudo o que quiser de Assembly dentro dos programas em Basic.

Quem sabe ocorre um lampejo em sua memória e voce goste do sentimentalismo ?

Paulo

MOR_AL · 2 de março de 2016

8 horas atrás, Isadora Ferraz disse:

...

Aceita mais uma? Então lá vai... que tal se descrevesses do que se trata este projeto? Me parece ser algo relacionado a controle de temperatura ou algo do gênero. Talvez ficasse + fácil acompanhar o fluxo das ideias. Bom, digo isso por mim e não pela maioria que deve ter compreendido sua proposta. Enfim...

...

Isa!

Eu já postei este projeto em outro fórum, mas já faz algum tempo. Inclusive tinha um tal de James Brown. Cara legal.

O projeto é bem trabalhoso. Se houver interesse eu posto aqui.

@Aphawk

Eu até já fiz com if e goto, mas não gostei. Usar goto de dentro para fora do if geram dúvidas.

Legal que você analisou. Eu ainda tinha alguma dúvida.

Tem uma dica.

Se o bloco condicional tem um ramo de retorno para seu início, use o While, caso contrário, use o if.

MOR_AL