Projetos com Avr : Design, Programação em Basic e Assembly

aphawk · 29 de julho de 2015

Opa, está ficando bom esse projeto !!!! Parabéns pela rapidez dos resultados ! Tá ficando cada vez mais fácil programar, não é ?

Sim, a estrutura de buffer circular ajuda uma barbaridade nos programas , eu fazia isso em ASM do Z-80 ..... legal que dá para acessar direto do Bascom dessa maneira, eu ainda não precisei fazer isso mas nunca se sabe né ?????

Eu sempre habilito as rotinas seriais com buffer e por interrupção, até no projetinho que eu ainda não terminei de postar sobre telemetria para rádio controle do padrão FRSKY fiz tudo em Bascom, sem precisar de Asm nenhum. Recebo e processo tudo a 9600 bauds em tempo real , e sobra tempo.

Eu tenho uns 10 desses circuitos matriciais montados com MAX7219 e com matriz cor vermelha, estou esperando você terminar e vou montar o meu kkkkk !

Paulo

test man*~ · 31 de julho de 2015

Sim =D o tutorial fez ficar fácil... O mais bacana foi que eu pude fazer "Dim mensagem(1265) as byte" 1265 NUSSSSSSSSSS...

Esses circuitos matriciais que você possui são assim:

Agora o painel já aceita envio de uma frase via serial mas ela ainda não fica rodando.

para mostrar algo escrever "1 + frase + 'APERTAR ENTER'"... Esse "1" é o comando pois estou pensando em outros 2

http://www.4shared.com/rar/-Sa1VTbgba/Recebendo_Dados_Serial.html?

aphawk · 31 de julho de 2015

@test man*~,

Sim, muito pareçido com esse seu.

Já usei 1,8 K em uma matriz bidimensional, e funcionou direitinho !

Isso de comandos seriais fica bem simples. Pode usar um para definir um texto, bem como já incluir a velocidade de visualização, e assim que receber já pode gravar na EEPROM e manter. Pode usar outros para selecionar qual a frase na EEPROM você quer mostrar, e outro para mudar a velocidade se quiser. A imaginação é o limite !

Paulo

test man*~ · 3 de agosto de 2015

Ai está o projeto. Poderia ter adiciomnado algus efeitos e mais comandos serial mas acho que já estou satisfeito...

Outra coisa, eu deveria ter usado variáveis locais pois ficaria bem mais organizado e talvez gastaria menos memória.

- Para funcionar os bytes das letras devem estar carregados na EEPROM (posição 1 até 570);

- Para alterar a quantidade de max7219 é só alterar a constante "qtde_max7219 = X" podem ser usados até 15;

- A resolução da velocidade de rolagem é de ~20mS se for enviado via serial "4" cada passo de rolagem terá 4*20=80mS, a resolução pode ser alterada para ~10mS comentando a linha 12 e tirando o comentário a 13;

- Tirar o SPI debugger faz a simulação rodar de forma mais rapida.

Comandos serial:



  .--------+------------------------------------+-------------.

  |Comando |             Dados                  |Fim do envio |

  |--------|------------------------------------|-------------|

  |   1    | Mensagem a ser mostrada no display | CR (ENTER)  | --> Máximo 200 Caractéres 

  |   2    |   Velocidade de rolagem (0-255)    | CR (ENTER)  | --> 0 = vel. máxima | 255 = Vel. mínima

  |   3    |    Intensidade dos Leds (0-15)     | CR (ENTER)  | --> 0 = mínimo      | 15 = máximo

  '--------+------------------------------------+-------------'

 

Ex: Enviar:

1Forum Clube do Hardware (ENTER) -> Esta mensagem será mostrada no display

23(ENTER)                        -> Com velocidade de 60mS por passo (3*20mS)

38(ENTER)                        -> Brilho dos leds mais ou menos 50%

As portas NOT são para deixar as matrizes como as que seriam usadas na montagem prática (que eu não realizei).

Sobrou uma eternidade de memória flash, dá para colocar muuuuuiiiiiitos efeitos hehe!!! Estava até pensando em fazer uma interface, usando o Visual Studio, para enviar frases, ajustar velocidade e intensidade... Mas vou ficar por aqui mesmo... Agora vou ver se uso o TWI (i2c).

Download programa (BASCOM) e simulação (Proteus 8.2), painel de leds final:

http://www.4shared.com/rar/3-qjEbHbce/Painel_de_Leds_Final.html?

Valeu pelo Tutorial Paulo @aphawk!!!

aphawk · 3 de agosto de 2015

@test man*~,

Opa, belo projeto !

Vou colocar as minhas matrizes e implementar só prá ver o jeitão... e é o que você falou, tem como implementar um montão de efeito, sobra memória pacas !

Quanto aos NOT's que você usou no Proteus, eu tenho uma solução melhor :

Edite as propriedades da matrix no ISIS no formato TEXT, e inverta os sinais diretamente lá !

Aí, eu decompus a matriz editada e criei um novo componente, que chamei de MATRIZ REAL, e uso ela diretamente sem precisar inverter com esses Nots !

Vou baixar todo o pacote em casa e ver o jeitão do programa.

Agora, voce sabe, esse programa já é de uma execução relativamente complexa, certo ?

Em menos de um mês, olha o que voce conseguiu fazer, meu amigo !

Claro que conheçer como funcionam outros microcontroladores ajuda muito, pois no fundo quem sabe o hardware de um Pic pega na hora o hardware do AVR , e como voce já programava ficou bem mais fácil assimilar tudo.

De qualquer maneira, parabéns pelo empenho, e obrigado pelo projeto, sempre é mais uma contribuição ( e de qualidade ) ao Fórum !

Paulo

test man*~ · 4 de agosto de 2015

Quanto aos NOT's que você usou no Proteus, eu tenho uma solução melhor :

Edite as propriedades da matrix no ISIS no formato TEXT, e inverta os sinais diretamente lá !

Aí, eu decompus a matriz editada e criei um novo componente, que chamei de MATRIZ REAL, e uso ela diretamente sem precisar inverter com esses Nots !

@aphawk

Consegui fazer, muito bacana... Adicionei a linha:

{INVERT=1,2,3,4,5,6,7,8}

Daí pude tirar as NOTs... Simulação rodou mais limpa!

Show de bola... Eu acho que você deveria escrever um livro Paulo, não existe o "Desbravando o microcontrolador PIC16F628A"? Você deveria lançar o "Desbravando o microcontrolador ATmega32A" com dois volumes o primeiro em ASM e o segundo em BASIC... Aqui no Brasil faltam livros para os AVR's... Aliás você conhece um bom?

Valeu!

aphawk · 4 de agosto de 2015

@test man*~,

Isso mesmo ! Aliás isso eu já tinha falado em algum lugar no Tutorial....

Opa, escrever um livro até que não seria difícil... Pelo menos a parte 2 está feita, basta dar uma arranjada no Tutorial e pronto !

Agora, escrever sobre o Asm.... Hoje em dia é igual fazer livro em Braile, serão bem poucos os que iriam se interessar.

Embora eu não goste, estamos no mundo do C, do Arduíno com suas bibliotecas prontas disponíveis para tudo o que se imagina, então programar em ASM é pior do que reinventar a roda ! Da mesma maneira que eu, que sempre gostei do Basic, só uso o ASM se não tiver outro jeito, afinal é tão simples usar o Bascom....

Vou te deixar "ouriçado" : a Atmel lançou uma linha de ARMs bem potentes e de baixo custo, e o pessoal do Bascom está terminando um novo BASCOM para eles..... Já pensou que beleza ?

Sobre livros nacionais sobre Avr's ..... parece que os escritores brasileiros ainda não descobriram que os Avrs existem, são mais rápidos, tem mais recursos e são mais baratos do que os velhos Pics.....

Não conheço nenhum livro, infelizmente....

Paulo

Intrudera6 · 5 de agosto de 2015

Um Bascon para ARM ??? Muito interessante! Espero que eles não vendam muito caro ou pelo menos deem um bom desconto para quem tem o Bascon para AVR. Acho que talvez valha a pena comprar (se eles não exagerarem no preço). Neste caso pode ser bem interessante comprar um Arduino com um processador ARM, os preços deles na internet são interessantes.

Até agora eu não tinha me interessando (muito) num ARM porque eu não estou disposto a aprender C, mas ASM para mim não é um grande mistério, se necessário não seria tão difícil aprender o ASM dos AVRs e dos ARMs (parece ser muito mais simples que o ASM de um 8088 e parentes mais modernos), e no Bascon já quebro uns galhos.

aphawk · 5 de agosto de 2015

@Intrudera6,

O pessoal tá falando que vai ter uma licença de UPDATE que permitirá usar ambos, ARM e AVR . Seria muito legal mesmo ! Mas o Mark ainda não confirmou isso oficialmente, então vamos ver ....

Eu ainda não ví o ASM dessa linha nova de ARMs da Atmel, mas creio que será bem mais complicado que os do AVR. Se tiver poucas instruções, será inevitábel utilizar bancos diferentes , aí enche o saco......

De qualquer maneira, esses Arduinos em ARM são muito interessantes, poderemos fazer projetos em uma outro patamar de performance e claro de recursos de RAM, DMA e outras coisas legais !

Como você disse, para mim usar ASM nos AVR's é tão simples quanto nos 8080, e eu me sinto muito confortável dentro de um programa em Basic codificar trechos críticos como interrupção em alta velocidade ou captura de dados em ASM.

Legal que você também usa o Bascom, e agora o Testman também está usando ele para coisas mais sérias, vide o projeto dele acima, ainda não tinha visto alguém fazer o display com vários MAX7219, e expansível como ele fez.

Nessas horas que eu sinto que o que faço aqui fazem alguns anos vale a pena !

Paulo

Intrudera6 · 5 de agosto de 2015

Interessante.

Vou comprar uma.

E eu encontrei um Arduíno DUE no eBay por menos de 18 dólares. Vou comprar 1destes para mim.

test man*~ · 5 de agosto de 2015

Hmm ai seria massa em!? Há um tempo atrás quando vi a placa do Arduíno Due pensei em aprender a usar o Atmel Studio para mexer com o ARM mas ai vi que o USBASP não grava os ARMs.

Quais gravadores gravam os ARMs?

Uma outra dúvida, o Atmel Studio C é gratuito até para os ARMs não é?

Outra, é possível usar a interface do Arduíno para escrever um código (em C) igual ao que seria escrito no Atmel Studio?

aphawk · 6 de agosto de 2015

@test man*~,

Eu reparei que existe o conector ICSP, mas também não imagino como se grava isso diretamente.

Mas tenho uma observa'vão importante : esse ARM que está sendo usado não são os novos Arms que a Atmel lançou recentemente. Esse aí é de primeira geração e tem baixo clock e pouca performance, e para "desovar" a Atmel fez um preço bem agressivo.

Os novos são bem mais poderosos, e com bem mais recursos, inclusive alguns apresentam até instruções de ponto flutuante ..... vou ver se acho o email onde recebí isso e posto o link aqui.

Paulo

Intrudera6 · 6 de agosto de 2015

Comprei um Arduíno DUE pelo eBay por 16,99 USD, não resisti ao preço baixo, agora é só torcer para que não demore muito para ter um Bascom para ARM.

Atualmente estou sem tempo (e sem nada de novo que eu tenha interesse de fazer), estou praticamente parado no AVR, mas com um "brinquedo" novo acho que o interesse pode voltar. Mesmo que o ARM desde DUE seja bem limitado ainda será muito mais poderoso que o melhor dos AVRs de 8 bits, e deve ser possível fazer coisas bem interessantes com ele.

No momento estou meio que de longe só assistindo a discussão de vocês (que é bastante interessante), mais no momento não estou fazendo nada de novo por verdadeira falta de tempo. Voltei a fazer inglês (desta vez quero levar a sério) e estou praticamente sem tempo livre nas noites. As gambiarras feitas com Arduíno estão no momento na "geladeira", espero não desaprender muito durante este meu recesso, para que não seja tão difícil voltar as atividades no futuro.

aphawk · 6 de agosto de 2015

@Intrudera6,

Não espere muito. Esse é um Cortex-M3 rodando a 84 Mhz. Tudo bem que permite 32 bits, então se você reescrever alguns trechos de programa, ele pode rodar entre 6 e no máximo umas 8 vezes mais rápido que um Arduino Uno a 16 Mhz.... ou cerca de 3 a 5 vezes mais rápido que um simples Atmega328P overclockado a 32 Mhz. Lembre-se : ele não tem memória cache interna .... mas em termos de ARM, é algo obsoleto !

Já os novos ATSAMV7 são a família Cortex-M7, rodam a 300 Mhz, e possuem dois sistemas de cache independentes de 16K cada um, um para dados e outro para instruções..... isto sim deve dar um banho de verdade ! Aqui eu espero ganhos de desempenho acima de 30 vezes, talvez 40, 50 vezes se reescrever os programas pensando em aproveitar os dois caches !

Claro que isso não leva em conta a imensa facilidade em recursos abundantes de RAM e Flash ! Aqui sim o céu é o limite !

http://www.atmel.com/products/microcontrollers/arm/sam-v-mcus.aspx#samv71

Paulo

alexandre.mbm · 6 de agosto de 2015

@Intrudera6, quais seriam as opções de linguagem/plataforma para programar esse Arduino com ARM? Pergunto assim: a API dele é basicamente a mesma de qualquer outro Arduino?

@aphawk, já que você fez comentários tão valiosos comparando hardware, quero lhe perguntar como você incluiria Raspberry Pi ou BeagleBoard nessas comparações. Para que elas servem e para que não servem? Por que você não as mencionou?

Intrudera6 · 7 de agosto de 2015

Eu não conheço o ARM, e estou tão curioso como você para explorar as possibilidades. Não vejo a hora de botar a mão num ,mesmo que limitado deve ter alguns recursos interessantes, por exemplo, imagino que ele tenha instruções de aritmética inteira, instruções de multiplicação e divisão inteira, o que deve fazer com ele seja muito mais interessante (e veloz) para fazer algumas coisas que exijam muito calculo do que com com um AVR, mas eu não conheço nada de ARM e eu posso estar totalmente enganado a respeito deles. O que o @aphawk diz a respeito ?

Peguei o Datasheet dele é o que encontrei foi:

O processador do Arduíno DUE (ATSAM3X8E) tem instruções de multiplicação e divisão em números inteiros (coloquei abaixo alguma coisa que encontrei no datasheet numa rápida pesquisa), coisa que os AVRs não tem, isto deve fazer com que seja muito mais fácil para o processador e de execução mais rápida para fazer cálculos mais pesados com ele, acho que vai ser bem interessante programar um bicho destes. Em cálculos ele parece ser muito superior aos AVRs, mas certamente necessita de vários ciclos de máquina para executar uma multiplicação e muitas vezes mais para uma divisão.

O datasheet tem 1499 páginas, acho que preciso ter coragem para dar uma boa olhada. Na página 81 eu já encontrei uma lista das instruções de linguagem de máquina (o que foi muito interessante para ver o que se pode fazer em baixo nível), mas ainda não encontrei nada a respeito dos ciclos de máquina necessários para a execução destas instruções (deve ter algo a respeito em algum lugar mas eu ainda não consegui achar).

10.14.3 SDIV and UDIVSigned Divide and Unsigned Divide.10.14.3.1 SyntaxSDIV{ cond} { Rd,} Rn, RmUDIV{ cond} { Rd,} Rn, Rmwhere:cond is an optional condition code, see “Conditional execution” on page 91 .Rd is the destination register. If Rd is omitted, the destination register is Rn.Rn is the register holding the value to be divided.Rm is a register holding the divisor.10.14.3.2 OperationSDIV performs a signed integer division of the value in Rn by the value in Rm.UDIV performs an unsigned integer division of the value in Rn by the value in Rm.For both instructions, if the value in Rn is not divisible by the value in Rm, the result is rounded towards zero.10.14.3.3 RestrictionsDo not use SP and do not use PC.10.14.3.4 Condition flagsThese instructions do not change the flags.10.14.3.5 ExamplesSDIV R0, R2, R4 ; Signed divide, R0 = R2/R4UDIV R8, R8, R1 ; Unsigned divide, R8 = R8/R110.14.2 UMULL, UMLAL, SMULL, and SMLALSigned and Unsigned Long Multiply, with optional Accumulate, using 32-bit operands and producing a 64-bitresult.10.14.2.1 Syntaxop{ cond} RdLo, RdHi, Rn, Rmwhere:op is one of:UMULL Unsigned Long Multiply.UMLAL Unsigned Long Multiply, with Accumulate.SMULL Signed Long Multiply.SMLAL Signed Long Multiply, with Accumulate.cond is an optional condition code, see “Conditional execution” on page 91 .RdHi, RdLo are the destination registers.For UMLAL and SMLAL they also hold the accumulating value.Rn, Rm are registers holding the operands.10.14.2.2 OperationThe UMULL instruction interprets the values from Rn and Rm as unsigned integers. It multiplies these integers andplaces the least significant 32 bits of the result in RdLo, and the most significant 32 bits of the result in RdHi.The UMLAL instruction interprets the values from Rn and Rm as unsigned integers. It multiplies these integers,adds the 64-bit result to the 64-bit unsigned integer contained in RdHi and RdLo, and writes the result back toRdHi and RdLo.The SMULL instruction interprets the values from Rn and Rm as two’s complement signed integers. It multipliesthese integers and places the least significant 32 bits of the result in RdLo, and the most significant 32 bits of theresult in RdHi.The SMLAL instruction interprets the values from Rn and Rm as two’s complement signed integers. It multipliesthese integers, adds the 64-bit result to the 64-bit signed integer contained in RdHi and RdLo, and writes the resultback to RdHi and RdLo.10.14.2.3 RestrictionsIn these instructions: do not use SP and do not use PC RdHi and RdLo must be different registers.10.14.2.4 Condition flagsThese instructions do not affect the condition code flags.10.14.2.5 ExamplesUMULL R0, R4, R5, R6 ; Unsigned (R4,R0) = R5 x R6SMLAL R4, R5, R3, R8 ; Signed (R5,R4) = (R5,R4) + R3 x R8

alexandre.mbm · 7 de agosto de 2015

O datasheet [do processador do Arduíno DUE (ATSAM3X8E)] tem 1499 páginas, acho que preciso ter coragem para dar uma boa olhada. Na página 81 eu já encontrei uma lista das instruções de linguagem de máquina [...]

Parece que vocês gostam de escovar bits e de muito assembly. Estou mais interessado em alto nível. No mínimo do mínimo, C. Talvez a principal pergunta que eu tenha, por ora, é se o DUE pode ser programado como se fosse um UNO, na Arduino IDE.

Intrudera6 · 7 de agosto de 2015

Encontrei um ARM A7 (dual core 1Ghz) por 80 USD no eBay, por este preço não acho que valha a pena se meter com ele, a não ser que precise de realmente algo bem poderoso ( http://www.ebay.com/itm/pcDuino3-1GB-ARM-Cortex-A7-Dual-Core-Allwinner-A20-Arduino-interface-Mini-PC-/301203428972?hash=item46211f966c )

aphawk · 7 de agosto de 2015

@Intrudera6,

Eu também penso que existem instruções de multiplicação e de divisão bem poderosas, com operandos tipo Long Signed, que são feitos em bem poucos ciclos de clock. Isso confere um grande poder em cálculos matemáticos, e nesse caso podemos obter performances superiores a mais de 10x se a rotina usar um monte de cálculos desse tipo.

Mas são poucos programas que se encaixam nesse tipo de desempenho. Para nós , que usamos em aplicações mais simples, eu vejo que o fator mais importante são o clock maior, pois os Avr's comuns tambem fazem a grande maioria de instruções em 1 ciclo de clock.

Um Cortex-M3 segue as instruções padronizadas para esse tipo, e voce pode dar uma olhada nesses instructions sets e tempos de execução neste site :

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0337h/CHDDIGAC.html

Mas se quiser se impressionar, veja as mesmas informações para os Cortex-M7 ....

Eu não vejo a hora de um Bascom para estas feras !!!!

Paulo

test man*~ · 7 de agosto de 2015

@aphawk 300MHz?!?! What the what? HAHAHAHA

Estou esperando um PIC32MX que opera a 50MHz e estou todo feliz HAHAHA...

O Bom mesmo seria se o pessoal do BASCOM adicionasse os ARM's, não curti o C do Atmel Studio... Além disso, o BASCOM explica até o que não precisa explicar no help, dá para saber exatamente o que o compilador está fazendo e isso é muito show!

@alexandre.mbm Eu creio que sim, neste vídeo o cara faz uma comparação de uma única sketch operando no mega2560 e no DUE:

Edit: É a mesma interface, no fim do vídeo dá para ver...

aphawk · 7 de agosto de 2015

@alexandre.mbm

Bom, eu não tenho experiência com esses produtos.... Eu acompanho um pouco sobre o hardware dos Arms, acho a ideia muito interessante, e é um padrão muito bem desenvolvido e sólido. Eu diria que apostaria as minhas fichas nos Arms para um futuro de uns 10 anos, devem dominar do mesmo jeito que os Avrs dominaram os últimos 10 anos e os Pics antes deles por uns 15 anos.

Mas eu não programaria esses Arms em Assembler .... Pode ser divertido ? Sim, mas deve ser algo terrivelmente improdutivo !

Já quando sair o Bascom para os Arms, aí a coisa se torna muito interessante, e vejo uma chance de fazer projetos muito mais ousados com eles.

Fico imaginando um clock de 300 Mhz, 256K de Ram, conversores A/d e D/A de 12 bits, coprocessador matemático interno, 32 bits de instrução e de dados, dois pipelines separados para dados e instruções com tamanho de 16K de cache, realmente é um parque de diversões de altíssimo desempenho.

Mas no momento ainda só posso imaginar, enquanto não sair esse Bascom novo....

Paulo

Intrudera6 · 7 de agosto de 2015

Site bem interessante.

Faz tempo que eu não programo em asm, mas nestas horas dá uma vontade de voltar a botar a mão na massa, era duro mas era muito divertido.

Lembro de uma época, no tempo da TK85, que eu fiz um programa em asm em Z80 para gravar em fita (tinha muita coragem naquele tempo), foi uma trabalheira calcular quantos ciclos de máquina gastava na execução para que a temporização ficasse exata, mas no final de muitas cabeçadas a rotina funcionou direito. Estes ARMs são muito mais poderosos que o velho e saudoso Z80.

Eu gosto de brincar com modelos matemáticos, acho que vou me divertir muito com um ARM, principalmente se não precisar aprender a programar em C.

aphawk · 7 de agosto de 2015

@test man*~,

Pois é.... 300 Mhz !!!!! Já pode ir sonhando viu, porque eles existem mesmo !

Agora, pelo vídeo, ví que meu chute sobre o desempenho está bem calibrado !!!! Essa rotina de calculo de Pi é um monte de calculo matemático, foi cerca de 7 vezes mais rápido.

Imagine isso rodando num Arm-M7, a 300 Mhz, com coprocessador matemático poderoso que faz calculos com ponto flutuante e ainda usa memória cache.... Quantas vezes mais rápido deve rodar ???????????? Nem consigo chutar com razoável acerto, mas acho que passa de 60 vezes ......

@alexandre.mbm,

Sim, mas tem de baixar a IDE do Arduíno especial para ele, ok ?

@Intrudera6,

Poxa, meus bons tempos de Sinclair ZX-81 .... Ganhei um dinheirinho implementando hardware neles.... Lembra da alta resolução ??? Eu implementava uma Eprom com vários programas especiais implementados, e uma Sram de 8k para fazer o vídeo em alta resolução com o truque de apontar o gerador de caracteres para a Sram heheheh !

Me lembro de uma revista famosa na época que criou um SO para programar em Assembler, cheio de funções, breakpoints, era muito legal usar, aprendí bastante com isso.

Segue uma curiosidade : já conseguiram emular um Apple ][ com um Arduíno Uno, mas até hoje ainda não ví emularem um simples Sinclair ..... Acho que a geração de vídeo que o Sir Clive Sinclair inventou complica muito isso, afinal o cara era um gênio mesmo, do tipo do Woszniak .....

Paulo

Intrudera6 · 7 de agosto de 2015

Esta revista não se chamava Microsistemas por um acaso ?

Aprendi muito com o debuger do Turbopascal (na era dos SOs de 16 bits e processadores de 32 bits), e era muito interessante ver a execução em ponto flutuante num coprocessador aritmético. A melhor coisa é um bom debuger para ver como a coisa realmente funcionava, ficava horas acompanhando a execução das rotinas vendo os registros mudarem e os flags sendo alterados para entender como funcionavam. Infelizmente me falta coragem para pagar o que cobram num Proteus. No Bascom valeu a pena e ainda pude instalar no desktop e no notebook sem problemas, a licença dele é bem descomplicada e sem frescura.

aphawk · 7 de agosto de 2015

@Intrudera6,

Sim, era ela mesma !!!! Boa memória ein !

Eu sempre gostei de debuggers. Aprendí bastante com eles. E sobre o Turbopascal, usei muito tempo o Tlink para compilar meus programas em MSDOS. Era muito rápido !

Olha, o Proteus é uma ferramenta fantástica, mas dói muito mesmo no bolso. Eu demorei muitos anos para ter essa coragem, mas agora ganho muito tempo simulando no Isis, o tempo gasto em um projeto diminui para cerca de 25% , pois testo todo o software antes de partir para o hardware real. Na verdade, estimo que só no tempo economizado ganhei mais do que me custou, então valeu a pena.

Tem muita gente que gosta do simulador do Bascom, experimente dar uma brincada com ele.

Paulo