Atmel assembler - konvertering fra hex til ASCII

Hej!

Jeg har lige et spørgsmål som jeg håber een eller flere kan svare på :)

Jeg har en hex-værdi i min AT90S8515 som jeg skal have smidt ud på et tilkoblet LCD display. Ergo skal jeg have konverteret tallet (f.eks. 192) så jeg kan få 1,

9 og 2 ud hver for sig.

Der findes dog ingen divisions-kommandoer i AVR assembler :(

Er der en snild metode til at klare ærterne? Nogen der vil ridse den op for mig?

--
Mvh, Kim Voss Schrader

OBS: Der kan max. attaches 30kb i e-mails til mig, ellers bouncer de.
Reply to
Kim Voss Schrader
Loading thread data ...

tilkoblet

få 1,

Men der findes en subtract og den klarer det fint.

for mig?

Sådan:

;Shows R16 as 0..255 string ;Uses R17 as workspace ;Uses 1 stack levels LCDPutNum: mov r17,r16 subi r16,10 ;Below 10 brcs putnum5 ;Only show last digit subi r16,90 ;Below 100 brcs putnum6 ;Only show two digits clr r16 putnum1: subi r17,100 brcs putnum2 inc r16 rjmp putnum1

putnum2:subi r17,-100 subi r16,-'0' rcall LCDWriteData putnum6: clr r16

putnum3: subi r17,10 brcs putnum4 inc r16 rjmp putnum3

putnum4:subi r17,-10 subi r16,-'0' rcall LCDWriteData putnum5:mov r16,r17 subi r16,-'0' rjmp LCDWriteData

Reply to
HKJ

Ja, selvfølgelig. Tak for hjælpen :)

--
Mvh, Kim Voss Schrader

OBS: Der kan max. attaches 30kb i e-mails til mig, ellers bouncer de.
Reply to
Kim Voss Schrader

Wow, ingen DIV-kommandoer i et assemblersprog? Jeg er på ingen måde bekendt med samtlige assemblersprog men det virker lidt overraskende at division ikke er implementeret på assemblerniveau. o_O

-- Mvh / Best regards, Jack, Copenhagen

The email address is for real. :)

Reply to
Jack L.

Tja, sådan er det altså :o(

Jeg burde have lavet hele koden i C istedet, men var ikke klar over den lækre AVR-GCC før sent i processen. Assembler er besværligt at skrive, sværere at debugge og endnu sværere at gennemskue hvis det er andres kode...

--
Mvh, Kim Voss Schrader

OBS: Der kan max. attaches 30kb i e-mails til mig, ellers bouncer de.
Reply to
Kim Voss Schrader

For et årstid siden var AVR-GCC ikke så lækkert... jeg røg ind i en masse compiler/linker problemer, men det lader til at der er styr på lortet nu, og ikke omvendt.

Mvh Kimjand

Reply to
Kim Johan Andersson

Hej jeg kender ikke AVR

Min foretrukne metode i 8051 er, at lave en eller flere tabeller i coden til den slags konverteringer og så bruge et register til indexering.

Så kan samme metode bruges i C og assembler. Den er samtidig lynhurtig, og nem at overskue i debugning.

mvh Ivan Toft

Kim Johan Anderss> Kim Voss Schrader wrote:

ikke

Reply to
Ivan Toft

bekendt

For små MPU'er er det ganske normalt at der mangler division, der kan også mangle multiply.

Begge dele kan forholdsvis nemt laves i assembler kode, men vil selvfølgelig være langsom, sammenlignet med en instruktion.

Forøvrigt er en god grund til IKKE at implementere en division, at den tager adskillige clockcycles at lave og derfor vil den kunne påvirke interrupt respons tiden.

Reply to
HKJ

Okay, så er det måske godt jeg ikke har skiftet tidligere :)

--
Mvh, Kim Voss Schrader

OBS: Der kan max. attaches 30kb i e-mails til mig, ellers bouncer de.
Reply to
Kim Voss Schrader

Interessant, det vidste jeg ikke. Men brrrrrr... >_<

Men vil man ikke kunne bruge det samme argument i det tilfælde man ønsker at implementere en multiplikation og/eller division? Jeg kan måske følge argumentet med for sådan en selv-implementeret instruktion er trods alt ikke atomisk, så ved et interrupt kan man afbryde divisionen eller multiplikationen (da de ikke er atomiske)... medmindre man har låst disse selv-implementerede instruktioner. Er jeg helt ude i hampen? :p

-- Mvh / Best regards, Jack, Copenhagen

The email address is for real. :)

Reply to
Jack L.

at

ikke

Helt korrekt, typisk har sådan en MPU instruktionstider på 1 til 2 clockcycles for ALLE instruktioner, så du får måske en interrupt response tid på 12 eller 13 clock cycles (inklusiv entry i interrupt rutinen), i tid vil det svare til omkring 1 uSec.

Reply to
HKJ

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.