JCARVALHO escreveu:Entao ficaria assim
Provavelmente aqui
mov a, 45 ;38;23 ;
e aqui
mov a, 100 ;98;50 ;
?
Saudações JCARVALHO!
Já que está com a mão na massa, pq. não aproveita, documenta o código certinho e troca as "constantes mágicas" deixadas pelo outro desenvolvedor por labels os quais poderiam facilmente ajudá-lo tanto na documentação quanto para possíveis futuras alterações?
No caso da serial, no trecho do código da recepção bit-banging através de pooling, bastaria que logo no início da unidade de tradução (arquivo) inserisse uma definição (provavelmente um equate) para identificar a constante:
- Código: Selecionar todos
...
...
...
; Taxa de transmissão/recepção da serial emulada (bit-banging)
GPS_BAUDRATE_CONST EQU 45
...
...
...
mov a, GPS_BAUDRATE_CONST
Há uma nota de aplicação da Holtek (HT48 & HT46 MCU UART Software Implementation Method) com uma UART emulada prontinha em:
http://www.holtek.com/english/tech/appnote/appnote.htm
http://www.holtek.com/english/tech/appnote/uc/pdf/ha0004e.pdf
Aproveito ainda para mencionar que a Holtek tem um ambiente de desenvolvimento com um compilador C gratuito, então, dependendo do número de alterações que pretende fazer, talvez seria interessante a re-escrita da aplicação em C (ganharia muito em termos de portabilidade e manutenção de código).
Outra coisa interessante de implementar, seria uma serial half-duplex por bit-banging mas não por polling e sim através de um timer e de um pino de interrupção externa. A rotina de transmissão seria realizada através de uma função que teria como argumento o dado a transmitir e a partir de então, enviaria seqüencialmente os bits com a temporização dada pelo timer (no atendimento da ISR do timer, haveria uma rotina que testa cada bit do dado a ser transmitido, então o pino é levado a alto ou a baixo conforme o bit de dado testado for 1 ou 0), tendo ainda flags de controle para verificar início ou final da transmissão do dado (start-bit sempre em 0 e stop bit sempre em 1 - considerando uma serial 8:1NRZ) e modo (transmissão ou recepção). A recepção seria realizada de forma semelhante, porém, o pino de recepção teria que ser um do tipo de interrupção preferencialmente por borda. Logo antes do início do "laço infinito" do código, a interrupção por transição por borda de descida é habilitada (sempre a espera do start-bit). No atendimento da interrupção da borda de descida, o timer da serial é carregado com um valor correspondente a metade do tempo de um bit, a interrupção do timer é habilitada, a interrupção por transição é desabilitada e a variável que receberá os "bits" inicializada. Na próxima interrupção do timer, é conferido se o nível do pino de recepção está em 0 (bom indicativo de que realmente era um start-bit), o timer então é carregado com o valor correspondente a um bit (taxa da serial) e então nas subsequentes transições o pino de recepção é testado e assim o dado vai sendo "montado" na variável de recepção. Após os 8 bits de dados, espera-se ainda o stop-bit e o estado da "máquina" é posto sob forma de espera (re-habilitação da interrupção por transição de borda no pino de recepção).
No lado "background", há de se ter uma outra máquina de estados afim de evitar espera quando em estado de transmissão e recepção. Esse método funciona muito bem para taxas modestas taxas modestas (até 9600) de serial, uma vez que dependendo do uC utilizado, pode-se haver sobrecarga da CPU no atendimento das interrupções (não estou levando em consideração a implementação com neestings). Assim, o fluxo principal do programa nunca pára, roda continuamente, independente se está a receber ou a transmitir pacotes de dados (após a implementação básica da serial, uma estrutura como buffer circular seria ideal para a transmissão ou recepção de "streams").
chrdcv