Simulação MPLAB CCS e MikroBasic - Facilidades e dificuldase
Enviado: 18 Mar 2007 23:57Caros colegas do fórum.
Fiz um programa para identificar uma tecla pressionada em um teclado matricial com 4 linhas e 3 colunas, tentando retirar o “bouncing” das teclas. Fiz o mesmo programa em assembler, C e MikroBasic.
A programação em assembler (possuo bom conhecimento) levou 20 unidades de tempo (UT).
A programação em C (CCS) (possuo conhecimento um pouco além do trivial) levou 4 UT.
A programação em Basic (MikroBasic) (possuo conhecimento um pouco além do trivial) levou 2 UT.
O programa principal é simplesmente um loop aguardando uma interrupção (no caso da mudança de estado no portB). Quando tentei simular o programa (precisaria saber o que acontecia com algumas variáveis, tanto das GPR como das SFR) começaram os problemas:
1 – Com o programa em assembler, usei o MPLAB. Não sei como alterar algum bit durante o debugg (caso seja possível), dentre as entradas RB4 a RB7, para que a simulação “entre” na interrupção.
2 - Com o programa em C, acredito que somente com o ICD dedicado, seja possível verificar no CCS.
3 - Com o mesmo programa em C, usando o MPLAB, recaio na dúvida do item 1.
4 – Com o mesmo programa em C, usando o Proteus, não sei se é possível “observar as variáveis GPR e SFR”, nem se é possível gerar um “bouncing” nas teclas.
5 – Com o programa em MikroBasic foi possível simular a interrupção, porém não é possível introduzir o “bouncing”.
Em termos práticos, e dentro das minhas limitações, concluo:
1 – Programar em assembler somente em casos extremamente necessários, e mesmo assim deveriam se restringir a blocos dentro de programas escritos em C ou em MikroBasic.
2 – A linguagem C é poderosa, rica em possibilidades, porém exigente nos detalhes. Encontra-se dificuldades na simulação do programa.
3 – A linguagem MikroBasic (da Mikroelektronika) é bem fácil de aprender, não é tão exigente nos detalhes como a linguagem C, possui um debbuger dedicado excelente e imediato de manipular e possui acesso à interrupção.
No ponto em que me encontro, minha tendência seria migrar para o MikroBasic pelas facilidades encontradas no software, além de possuir rica biblioteca. O único detalhe é que não se tem acesso ao seu interior. São “caixas pretas”. Como meus conhecimentos em C e Basic são equivalentes (um pouco além do trivial), gostaria da opinião dos colegas, no sentido de acrescentar alguma informação, tanto corretiva em relação ao exposto, como sugestiva a respeito do assunto.
MOR_AL
Fiz um programa para identificar uma tecla pressionada em um teclado matricial com 4 linhas e 3 colunas, tentando retirar o “bouncing” das teclas. Fiz o mesmo programa em assembler, C e MikroBasic.
A programação em assembler (possuo bom conhecimento) levou 20 unidades de tempo (UT).
A programação em C (CCS) (possuo conhecimento um pouco além do trivial) levou 4 UT.
A programação em Basic (MikroBasic) (possuo conhecimento um pouco além do trivial) levou 2 UT.
O programa principal é simplesmente um loop aguardando uma interrupção (no caso da mudança de estado no portB). Quando tentei simular o programa (precisaria saber o que acontecia com algumas variáveis, tanto das GPR como das SFR) começaram os problemas:
1 – Com o programa em assembler, usei o MPLAB. Não sei como alterar algum bit durante o debugg (caso seja possível), dentre as entradas RB4 a RB7, para que a simulação “entre” na interrupção.
2 - Com o programa em C, acredito que somente com o ICD dedicado, seja possível verificar no CCS.
3 - Com o mesmo programa em C, usando o MPLAB, recaio na dúvida do item 1.
4 – Com o mesmo programa em C, usando o Proteus, não sei se é possível “observar as variáveis GPR e SFR”, nem se é possível gerar um “bouncing” nas teclas.
5 – Com o programa em MikroBasic foi possível simular a interrupção, porém não é possível introduzir o “bouncing”.
Em termos práticos, e dentro das minhas limitações, concluo:
1 – Programar em assembler somente em casos extremamente necessários, e mesmo assim deveriam se restringir a blocos dentro de programas escritos em C ou em MikroBasic.
2 – A linguagem C é poderosa, rica em possibilidades, porém exigente nos detalhes. Encontra-se dificuldades na simulação do programa.
3 – A linguagem MikroBasic (da Mikroelektronika) é bem fácil de aprender, não é tão exigente nos detalhes como a linguagem C, possui um debbuger dedicado excelente e imediato de manipular e possui acesso à interrupção.
No ponto em que me encontro, minha tendência seria migrar para o MikroBasic pelas facilidades encontradas no software, além de possuir rica biblioteca. O único detalhe é que não se tem acesso ao seu interior. São “caixas pretas”. Como meus conhecimentos em C e Basic são equivalentes (um pouco além do trivial), gostaria da opinião dos colegas, no sentido de acrescentar alguma informação, tanto corretiva em relação ao exposto, como sugestiva a respeito do assunto.
MOR_AL