Hallo zusammen, Ich habe mehr ein informtisches Problem mit Assembler und hoffe das dazu jemand eine Idee hat... Und zwar programmiere ich einen ATmega8 in Assembler (8mhz). Intention ist, einen Frequenzzähler (zum kontrollieren von Ventilatoren in hochspannungsschaltnetzteilen) zu entwickeln. Das Ding funktioniert soweit, die Frequenz wird im AVR berechnet, und soll jetzt auf einem LCD ausgegeben werden. Da der bereich von 110 - 1000 kHz geht sind die anzuzeigenden Zahlen 24 bittig!!! Die sind aufgeteilt in 3 Register, sagen wir r19:r17:r16. (Genaugenommen sind bei "1 000 000" nur 20 bit belegt, trotzdem muss ich natürlich mit 3 Registern rechnen (8bit pro reg) ) Ich bin nun soweit, dass ich weiss, wie es gehen könnte: von der Zahl erst 1000000 abziehen, solange wie ein neg.überlauf entsteht. --> das wäre die 1 000 000 -Stelle (als ASCII),dann die 1 000 000er Stelle von der zahl abziehn, so dann die 100 000er stelle ermitteln, abziehen, dann 10000er, usw... Dann hätte ich z.b von 490 386 die Ascii-zeichen: 0 4 9 0 3 8 6 das kann ich leicht am LCD ausgeben. NUR : wie subtrahiere ich in Assembler: 490386 - 100 000, beispielsweise? Das sind jeweils 3 Register, also 24bit - 24bit in Assembler? Oder hat jemand eine ganz andere Idee zu Ausgabe von 24bit zahlen als Dezimalzahl aufnem LCD??? Ich bin euch für jede Hilfe dankbar!!!, Moritz
Vielleicht hilft das hier: Beitrag "DIVISION 32 BIT / 32BIT Beispiel (Assembler) ATmega8" Beitrag "8Bit Division mit Rest (AVR,Assembler)"
Das machst Du genau wie bei 16 Bit: erst die eine, dann die andere mit Carry und hier eben noch die dritte mit Carry. Wo ist das Problem? Aber mal etwas ganz anderes: wen interessieren bei einer Frequenz über 100 kHz noch einzelne Hertz?
> Das sind jeweils 3 > Register, also 24bit - 24bit in Assembler? Genauso wie du es auch im 16 Bit Fall machen würdest, nur halt mit 3 Registern. Du rechnest dir das Bitmuster für 1000000 (0F4240) aus und dann nimmst du SUBI und SBCI SUBI R17, 40 ; niederwertigsten Bits SBCI R18, 42 ; SBCI R19, 0F ; höchstwertigen Bits
Karl heinz Buchegger wrote: > Du rechnest dir das Bitmuster für 1000000 (0F4240) aus > und dann nimmst du SUBI und SBCI > > SUBI R17, 40 ; niederwertigsten Bits > SBCI R18, 42 ; > SBCI R19, 0F ; höchstwertigen Bits Warum so umständlich ? Laß das Umrechnen doch den Assembler machen, dazu ist er ja da:
1 | SUBI R17, byte1(1000000) ; niederwertigsten Bits |
2 | SBCI R18, byte2(1000000) ; |
3 | SBCI R19, byte3(1000000) ; höchstwertigen Bits |
Peter
Peter Dannegger wrote: > Karl heinz Buchegger wrote: > >> Du rechnest dir das Bitmuster für 1000000 (0F4240) aus >> und dann nimmst du SUBI und SBCI >> >> SUBI R17, 40 ; niederwertigsten Bits >> SBCI R18, 42 ; >> SBCI R19, 0F ; höchstwertigen Bits > > Warum so umständlich ? Weil ich nicht wusste, ob der Assembler mit so grossen Zahlen zurecht kommt :-)
ok, erstmal vielen Dank für die vielen schnellen Antworten. In dem Link: Beitrag "DIVISION 32 BIT / 32BIT Beispiel (Assembler) ATmega8" ist eine Divisionsroutine drin 32bit durch 32bit. Das ist doch eigentlich dasselbe, wenn ichs dividiere, wie wenn ich so oft subtrahiere bis der Carry entsteht...? Also wenn ich beispielsweise die zahl habe: 2 345 678 Schritt1: 2 345 678 / 1 000 000 = 2 Schritt2: 2 345 678 - (2* 1 000 000) Schritt3: 0 345 678 / 100 000 = 3 Schritt4: 0 345 678 - (3* 100 000) Schritt5: 0 045 678 / 10 000 = 4 Schritt6: 0 045 678 - (4*10 000) Schritt7: 0 005 678 / 1 000 = 5 usw.... Die Ergebniss-Zahlen anzeigen ist ja kein Problem, dafür nehm ich die lcd_number.asm Routine von dem avr-tut von dieser Homepage. Aber so müsste es doch gehn, ich werde trotzdem mal die subtraktionsmethode testen, auch weil ich ja in dem oben genannten Algorithmus auch 24bit minus 24bit habe! ----------------------------------------------------------------- @ Karl Heinz & Peter: Vielen Dank, das war das was ich suchte, nur noch zum Verständnis, ist dieser Code der komplette Code um r18:r17:r16 - 0F4240 zu rechnen? : SUBI R17, 0x40 ; niederwertigsten Bits SBCI R18, 0x42 ; SBCI R19, 0x0F ; höchstwertigen Bits Das Ergebnis wird dann ja in r16-r18 sein, ich probiers jetzt sofort aus, dankeschön! ------------------------------------------------------------------------ @Philipp: die einzelnen Hertz sind mir egal, nur kann ich die untersten Bytes ja nicht einfach abschneiden, den Gedanken hatte ich auch schon, halt wie wenn man von 3456789 mit 3456 rechnen würde und am ende mit 1000 multiplizieren, das geht halt nur im dezimalsystem... --------------------------------------------------------------- Perfekt, Vielen Dank, Gruss Moritz p.s: Die GSI in Darmstadt wird bald einen schönen Frequenzzähler bekommen :-) !!!
Moritz wrote: > ok, erstmal vielen Dank für die vielen schnellen Antworten. > In dem Link: Beitrag "DIVISION 32 BIT / 32BIT Beispiel (Assembler) ATmega8" > ist eine Divisionsroutine drin 32bit durch 32bit. Das ist doch > eigentlich dasselbe, wenn ichs dividiere, wie wenn ich so oft > subtrahiere bis der Carry entsteht...? Das kommt drauf an. Die Division kriegst du auch nicht umsonst. Da Subtraktion aber für den µC simpler ist, wird das wohl schneller gehen. > Also wenn ich beispielsweise die zahl habe: 2 345 678 > > Schritt1: 2 345 678 / 1 000 000 = 2 > Schritt2: 2 345 678 - (2* 1 000 000) > Schritt3: 0 345 678 / 100 000 = 3 > Schritt4: 0 345 678 - (3* 100 000) > Schritt5: 0 045 678 / 10 000 = 4 > Schritt6: 0 045 678 - (4*10 000) > Schritt7: 0 005 678 / 1 000 = 5 > usw.... Ja. So würde man das machen. > @ Karl Heinz & Peter: > Vielen Dank, das war das was ich suchte, nur noch zum Verständnis, ist > dieser Code der komplette Code um r18:r17:r16 - 0F4240 zu rechnen? : > > SUBI R17, 0x40 ; niederwertigsten Bits > SBCI R18, 0x42 ; > SBCI R19, 0x0F ; höchstwertigen Bits > Ja, das ist alles. Jetzt vergleich mal mit der Division. Du kannst viele Subtraktionen machen in der Zeit die eine Division benötigt. Und da du weist, dass du für eine Ziffer nie mehr als 10 Subtraktionen benötigen wirst, ist die Subtraktionsmethode gar nicht so schlecht.
Moritz wrote: > @Philipp: die einzelnen Hertz sind mir egal, nur kann ich die untersten > Bytes ja nicht einfach abschneiden, den Gedanken hatte ich auch schon, > halt wie wenn man von 3456789 mit 3456 rechnen würde und am ende mit > 1000 multiplizieren, das geht halt nur im dezimalsystem... Nein, das geht nicht nur im Dezimalsystem. Du kannst alles wegschneiden, was keine relevante Information enthält. Wenn sowieso nur kHz angezeigt werden sollen, könnten fast 10 Bit hinten weggelassen werden. In der Praxis läßt man eher nur ein Byte weg. Für die oberste Stelle müssen dann statt 1000000 nur (1000000/256) abgezogen werden und schon stimmen die Dezimalen wieder: SUBI R24, byte1(1000000/256) ; niederwertiges Byte SBCI R25, byte2(1000000/256) ; höherwertiges Byte Spart einen Befehl pro Schleifendurchlauf, bei den 10er- und 1er-Stellen noch einen weiteren, weil man SBIW benutzen kann. Das ist nicht die Welt, klar. Und hier vielleicht auch gar kein Problem. Aber es ist nicht schlecht, sich daran zu gewöhnen, von Anfang an die Aufgabe zu vereinfachen. Das kann einem nicht nur irgendwann mal die Performance retten, wenn es um mehr geht, sondern hilft auch Fehler zu vermeiden.
Ok, ich hab das jetzt mal mit der Subtraktionsmethode hingekriegt, funktioniert perfekt: ;---Routine zum Ausgeben von 24 bit-zahlen am LCD ;(lcd_data gibts hier von mikrocontroller.net unter avr tutorial) ;--------------------------------------------------------------------- ausgabe: ; Eine Zahl aus dem Register r27:r26:r25 am lcd ausgeben ; ;temp1 benutzt ldi temp1, '0' ;Ascii-wert s1: subi r25, Byte1(100000) sbci r26, Byte2(100000) sbci r27, Byte3(100000) brcs s2 ; ist dadurch ein Unterlauf entstanden? inc temp1 rjmp s1 s2: rcall lcd_data ;bezieht sich ja auf temp1 subi r25, Byte1(-100000) sbci r26, Byte2(-100000) sbci r27, Byte3(-100000) ;wieder zurückaddieren ldi temp1,'0' s3: subi r25, Byte1(10000) sbci r26, Byte2(10000) sbci r27, Byte3(10000) brcs s4 inc temp1 rjmp s3 s4: rcall lcd_data ;bezieht sich ja auf temp1: temp1 am lcd ausgeben / 10000er stelle subi r25, Byte1(-10000) sbci r26, Byte2(-10000) sbci r27, Byte3(-10000) ;wieder zurückaddieren ldi temp1,'0' s5: subi r25, Byte1(1000) sbci r26, Byte2(1000) sbci r27, Byte3(1000) brcs s6 inc temp1 rjmp s5 s6: rcall lcd_data ;bezieht sich ja auf temp1 / 1000er stelle subi r25, Byte1(-1000) sbci r26, Byte2(-1000) sbci r27, Byte3(-1000) ;wieder zurückaddieren ldi temp1,'0' s7: subi r25, Byte1(100) sbci r26, Byte2(100) sbci r27, Byte3(100) brcs s8 inc temp1 rjmp s7 s8: rcall lcd_data ;bezieht sich ja auf temp1 / 100er stelle subi r25, Byte1(-100) sbci r26, Byte2(-100) sbci r27, Byte3(-100) ;wieder zurückaddieren ldi temp1,'0' s9: subi r25, Byte1(10) sbci r26, Byte2(10) sbci r27, Byte3(10) brcs s10 inc temp1 rjmp s9 s10: rcall lcd_data ;bezieht sich ja auf temp1 / 10er stelle subi r25, Byte1(-10) sbci r26, Byte2(-10) sbci r27, Byte3(-10) ;wieder zurückaddieren ldi temp1,'0' add temp1, r25 ; 0 bis 9. rcall lcd_data ret
Noch ein Tip. Wenn du bei den Tausendern angelangt bist, dann ist Register r27 schon sicher 0. Kein Grund das dann bei den kleineren Stellen noch mitzuschleppen. Selbiges für r26. Sobald du bei den Zehnern angelangt bist, ist dieses Register mit Sicherheit 0.
> Habe am WE mich noch mal intensiv mit der > Sub-Methode auseinandergesetzt... Löblich. Das ist die richtige Einstellung. Weiter so. > Hier das überraschende Ergebnis: man kann Gutes immer > noch optimieren. :-) Guckst du hier: http://www.mikrocontroller.net/articles/AVR-Tutorial:_ADC#Program Eigentlich warte ich schon die längste Zeit auf jemanden der mal nachfragt warum das so geht :-)
Hmm. Irgendwie hat das Forum jetzt einen Fehler. Es hat aus 2 Postings eines gemacht. Von mir die Antwort, vom Beitrag auf den ich geantwortet habe (der im Übrigen jetzt verschwunden ist), den Dateianhang.
Nur um das Thema abzuschliessen, Ich habe das Problem gelöst und das Projekt beendet, hier ist das Ergebnis. Vielen Dank an alle die dazu beigetragen haben!!! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Es handelt sich hier um einen Frequenzmesser mit dem Frequenzbereich von 40Hz bis 2-3 Mhz. Die Frequenz wird kontinuierlich gemessen und auf einem LCD-Display ausgegeben. Die Messgenauigkeit wurde mit einem proffessionellen Frequnzmesser bestätigt: sie ist im niedrigeren Bereich aufs Hertz genau und nimmt nach oben hin etwas ab, aber das beschränkt sich auf ein,zwei kilohertz im hundert-kilo-bis-Megahertz bereich. Man kann zwei Messbereiche auswählen, LOW, von 40Hz bis ca. 120 kHz und High , von 120kHz bis einigen Megahertz. Ich habe das Gerät im Rahmen eines Betriepspraktikums bei der GSI in Darmstadt entwickelt, es wird dort benutzt, um die Drehzahl von aktiv-überwachten Ventilatoren zu messen (Hochspannungsnetzgeräte). Anschlüsse: -->LCD (1x16 Zeilen) am PortC, sonst genau wie hier im AVR-Tutorial beschrieben --> Taster von PB0 und PB1 auf Null, Pins mit 1-10k Pullup-widerstand --> PD4 und PD5 verbunden (T0 und T1), und mit einem Eingangswiderstand auf null. (nach Spannungsteilerformel berechnen, so ~ 5-50kOhm..) -->Das ist dann auch der Signaleingang (PD4/5) --> 8Mhz Quarz Sonst normale ATMega8 beschaltung (geht auch im Prinzip mit ATmega16 od. 32...). In dem Ordner ist sowohl die .hex als auch der quellcode. Und ein Foto von dem fertigen Gerät, gerade im Menüpunkt "select range" Praktiksch ist es, ein 7805 Spannungsregler mit einer 9V-Batterie zu nehmen, als Messleitung eignet sich eine Oszilloskop-Prüfspitze. So und das wars auch schon! Bei Fragen, Kritik, Anregungen, Problemen & Co einfach ne mail an [m.greif@tiscali.de] oder wenn ihr was gar nicht kapiert, meine Tel.Nr.: 069/765831, oder ihr schreibt einfach hier ins Forum :-) Viel Spass damit! Gruss, Moritz ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@Moritz Greif >einem LCD-Display ausgegeben. Die Messgenauigkeit wurde mit einem >proffessionellen Frequnzmesser bestätigt: sie ist im niedrigeren Bereich >aufs Hertz genau und nimmt nach oben hin etwas ab, aber das beschränkt >sich auf ein,zwei kilohertz im hundert-kilo-bis-Megahertz bereich. Hmm, bei 100 kHz sind 2 kHz Abweichung 2%. Das ist grottenschlecht für einen Frequenzmesser. Selbst bei 1 MHz wären es noch 2 Promille, was um den Faktor 20! von der Genauigkeit einen unkalibrierten! Quarzes entfernt ist (~100ppm). >Ich habe das Gerät im Rahmen eines Betriepspraktikums bei der GSI in >Darmstadt entwickelt, es wird dort benutzt, um die Drehzahl von Naja, als Lehrlingsarbeit für den ersten Schuss brauchbar, aber noch mit deutlich Potential für Verbesserung. Aber für die Anwendung wahrscheinlich ausreichend, als Schätzeisen ;-). Lästerliche Grüsse zum Wochenende Falk
> Hmm, bei 100 kHz sind 2 kHz Abweichung 2%.
Aber dafür werden zum Ausgleich noch hinter der falschen Dezimale drei
weitere Stellen angezeigt. Das vermittelt dann wenigstens den Eindruck,
es würde sich um ein exaktes Ergebnis handeln. (-;
Aber der Vorschlag, das Problem zu vereinfachen, indem man sich auf eine
kHz-Anzeige und 16 Bit beschränkt, war ja offenbar nicht erwünscht.
Schließlich wurde das Ziel auch so erreicht -- minderwertig und absurd,
aber erreicht; da muß der alte Ingenieursgeist halt aufgeben ...
Nichts für ungut. Ich will das Erfolgserlebnis nicht trüben, aber das
nächste Mal ruig die Latte etwas höher hängen. Dann ist der Erfolg auch
befriedigender ...
Na also die Ungenauigkeit fängt noch nicht grad bei 100 kHz an, eher so zögerlich ab 500khz...soviel zum thema grottenschlecht... ausserdem, was willst du damit messen? Und mit einem ATmega8 und 8Mhz Quarz wird es schwierig, hohe frequenzen mit schneller messwiderholungsrate genau zu messen, allein weil fast jeder Assemblerbefehl 1/8000000 s lang ist. Natürlich kannst du 5Std. Zeitmessen und Impulse Zählen, dann haste (d)eine Messgenauigkeit zum ausflippen, aber das ist ja nicht der Sinn der Sache...!! ebenfalls ein schönes Wochenende, Moritz PS.: ich bin Schüler der 12.Klasse und kein Informatik-Student im 6.Semester...;-) PPS.: aber ich verzeih dir mal...
>minderwertig und absurd, Hallo! was geht n ab? Ich hab eine woche an dem Ding programmiert und getüftelt,machts halt besser! Ausserdem will ich ja auch noch dazulernen! Ihr sollts ja nicht nachbauen wenn Ihrs Schrott findet. > ...der alte Ingenieursgeist halt aufgeben ... bitte! >Nichts für ungut. Ich will das Erfolgserlebnis nicht trüben, aber das nächste Mal ruig die Latte etwas höher hängen. Dann ist der Erfolg auch befriedigender ... Wenn ich mein Informatik-Diplom und eine Stelle bei ATMEl in der RISC-Architectur-Entwicklung innehab, sprechen wir uns wieder, Meister! huhu, Moritz
>Wenn ich mein Informatik-Diplom und eine Stelle bei ATMEl in der >RISC-Architectur-Entwicklung innehab, sprechen wir uns wieder, Meister! Ja, genau...
>Nur um das Thema abzuschliessen, Ich habe das Problem gelöst und das >Projekt beendet, hier ist das Ergebnis. <snip> Ich sehe du bist noch nicht lang bei mikrocontroller.net. Da ist es üblich, dass Poster zerfleischt werden, sobald sie ihr Projekt abgeschlossen haben und es zur Schau stellen wollen. Grund ist, dass es für dich wohl was Besonderes ist, aber für viele hier als trivial angesehen wird. Sorry - nimms nicht persönlich, aber so sind hier halt die Umgangsformen. Mfg Gast (der sich hinter einem Gast-Account versteckt) PS: Bin ebenfalls Info-Student im 6ten und bin auch nicht wirklich beeindruckt ...
Wow ... sowas hat man ja auch noch nicht gesehen:
1 | ;Das abc zum einbinden!!!!! .include "abc0-9.asm" |
2 | a: |
3 | ldi temp1, 'a' |
4 | rcall lcd_data |
5 | ret |
6 | b: |
7 | ldi temp1, 'b' |
8 | rcall lcd_data |
9 | ret |
10 | c: |
11 | ldi temp1, 'c' |
12 | rcall lcd_data |
13 | ret |
14 | d: |
15 | ldi temp1, 'd' |
16 | rcall lcd_data |
17 | ret |
18 | e: |
19 | ldi temp1, 'e' |
20 | rcall lcd_data |
21 | ret |
22 | uswusf... |
23 | |
24 | und dann sowas: |
25 | rcall s |
26 | rcall e |
27 | rcall l |
28 | rcall e |
29 | rcall c |
30 | rcall t |
Auf sowas würde ich nicht stolz sein wollen ;-)
Seid doch nicht so dermassen kritisch. Immerhin hat ers hin gekriegt. Nicht optimal, aber es läuft. Eure ersten Programme waren auch nicht optimal. Und trotzdem wart ihr stolz drauf, dass es läuft. Wenn ich da mit so manchem BASCOM Fragesteller vergleiche, dann sind da Welten dazwischen.
Ich denke mal auch, wenn das Programm läuft und der Chef zufrieden ist und er auch versteht, was er da geschrieben hat, dann kann er auch ruhig stolz sein. Es gibt natürlich noch einiges, was man verbessern könnte. Man kann das aber auch sachlicher sagen. Zerfleischen kann man einen, der behauptet, das sei die super-duper Lösung und die isses dann aber nich. Peter
Da hams da doch einige verstanden, was los ist, zum Glück! ~~~~~~~~~ @ Autor: Gast (Gast) Datum: 09.02.2007 22:48: Das ABC zum einbinden ist ein standard-asm den ich mal gemacht hab um mir in vielen Projektchen die Sache zu vereinfachen, sowas benutzt doch jeder, nicht? Ich versteh nicht was daran so toll sein soll, oder wo ich behauptet hätte, dass das, der Hit in Dosen wäre, dass man das so runtermacht??!!. Das hat mit dem Programm, und mit den Problemen, an denen ich mich rumgeschlagen hab nicht das geringste zutun, was soll das? ~~~~~~~~~ Naja ich will hier die Diskussion nicht weiter anfachen, Schwamm drüber. Ich denke jeder kann sich seinen Teil denken. Grüsse an alle µC Fan's Moritz PS.: an alle immer noch unzufriedenen, ich nehme eure Kritik konstruktiv auf und ich versprech den Code aus Spass an der Freude nochmal zu überarbeiten, einfach weils mich selber interessiert.
@ Moritz Greif >Na also die Ungenauigkeit fängt noch nicht grad bei 100 kHz an, eher so >zögerlich ab 500khz...soviel zum thema grottenschlecht... Hast du anders geschrieben, aber auch bei 500 kHz isses nicht so dolle. >ausserdem, was willst du damit messen? ICH will gar nichts messeen, DU willst ja was messen. >Und mit einem ATmega8 und 8Mhz Quarz wird es schwierig, hohe frequenzen >mit schneller messwiderholungsrate genau zu messen, allein weil fast >jeder Assemblerbefehl 1/8000000 s lang ist. Natürlich kannst du 5Std. >Zeitmessen und Impulse Zählen, dann haste (d)eine Messgenauigkeit zum >ausflippen, aber das ist ja nicht der Sinn der Sache...!! Man(n) muss es nicht nur hier haben zeigaucf meinen linken Bizeps, sondern auch hier zeigaufmeinenKopf ;-) Schon mal was von Timern gehört? >PS.: ich bin Schüler der 12.Klasse und kein Informatik-Student im >6.Semester...;-) Die meisten Informatiker haben wenig Ahnung von uCs. >PPS.: aber ich verzeih dir mal... Wie großzügig von eurer Durchlaucht! ;-) @ Gast >Ich sehe du bist noch nicht lang bei mikrocontroller.net. Da ist es >üblich, dass Poster zerfleischt werden, sobald sie ihr Projekt >abgeschlossen haben und es zur Schau stellen wollen. Zerfleischt? Du hst mich noch nicht jemanden zerfleischen sehen, das würde ETWAS anders aussehen. >Grund ist, dass es für dich wohl was Besonderes ist, aber für viele hier >als trivial angesehen wird. Das ist richitg. Und dennoch will ich Anfänger nicht über Gebühr kritisieren, aber Lobhudelei und "Haste aber fein gemacht" gibts nur von Mutti. >Sorry - nimms nicht persönlich, aber so sind hier halt die >Umgangsformen. Noch so ein kritikunfähiger und humorloser Mitmensch. @ Moritz Greif >PS.: an alle immer noch unzufriedenen, ich nehme eure Kritik konstruktiv >auf und ich versprech den Code aus Spass an der Freude nochmal zu >überarbeiten, einfach weils mich selber interessiert. Na das ist doch mal ein sehr guter Ansatz. Weiter so! MfG Falk
Tatsächlich, Karl-Heinz, ich war auch sehr überrascht, meinen Beitrag in veränderter Form wiederzufinden. "Eigentlich warte ich schon die längste Zeit auf jemanden der mal nachfragt warum das so geht :-)" Ganz einfach, warum soll ich zuerst addieren und dann den durch 10 geteilten Wert wieder subtrahieren. Unser guter Peter D. hat schon vor Jahren fast aufs Byte den gleichen Code veröffentlicht: 8bis32bit binär in Dezimal ausgeben Beitrag "Re: 8bis32bit binär in Dezimal ausgeben" 26 bit umwandlung in ASCII Beitrag "Re: 26 bit umwandlung in ASCII" am besten die ganzen Threads lesen, da in dem File http://www.mikrocontroller.net/attachment/291/Bcd32b.asm kleine Fehler vorhanden sind, welche weiter unten besprochen werden. Sehe gerade, hier ist eine verbesserte Version: http://www.mikrocontroller.net/attachment/292/BCD32b.asm @Moritz: Ich finde, Du hast als 12.-Klässler das wirklich prima hinbekommen. Da können sich so manche eine Scheibe abschneiden bzw. die wenigsten würden sich so etwas zutrauen. Auch wenn sich das eine oder andere noch eleganter lösen läßt. Dazulernen ist alles. Bin schon auf Deine überarbeitete Version gespannt. PS: seid doch einfach nett zueinander.
@Moritz: >Das ABC zum einbinden ist ein standard-asm den ich mal gemacht hab um >mir in vielen Projektchen die Sache zu vereinfachen, sowas benutzt doch >jeder, nicht? Ich versteh nicht was daran so toll sein soll, oder wo ich >behauptet hätte, dass das, der Hit in Dosen wäre, dass man das so >runtermacht??!!. Das ist sehr ungewöhnlich - man könnte sagen sogar richtig kreativ. Die Standardmethode ist halt, dass man sich Strings im Speicher definiert mit:
1 | hw_label: |
2 | .db "Hallo Welt",0 |
und dann die Adresse mit
1 | mov zl, low(2*hw_label) |
2 | mov zh, high(2*hw_label) |
lädt und dann zB so eine Funktion aufruft die das zum display schaufelt:
1 | output_string: |
2 | lpm |
3 | and r0, r0 |
4 | jz output_ende |
5 | mov r16, r0 |
6 | rcall LCDOutput |
7 | adiw zl,1 |
8 | jmp output_string |
9 | output_ende: |
10 | ret |
Kannst du ja mal ausprobieren was dir zweckmäßiger erscheint. Aber die ABC-Lösung taugt aus mehreren Gründen nichts. 1. Langsam 2. Braucht viel Platz 3. Braucht nochmehr Platz Mfg Gast
ja, danke werd ich mal ausprobieren, bis jetzt hat mich das mit dem ABC nicht gross interessiert, aber wenn das mit Text ausgeben so kurz geht, umso besser.. Gruss Moritz
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.