Zeitschleife Mikrocontroller

[sisi]

eitschleife Mikrocontroller
Hallo Forumnutzer,

ich habe folgende Code für eine Zeitschleife aus AVR: http://www.mikrocontroller.net/artic...-Tutorial:_LCD

Längere Pause für manche Befehle
delay5ms: ; 5ms Pause
ldi temp1, $21
WGLOOP0: ldi temp2, $C9
WGLOOP1: dec temp2
brne WGLOOP1
dec temp1
brne WGLOOP0
ret ; wieder zurück


Was hier vorgeht, habe ich soweit verstanden. Jetzt möchte ich auch eine Zeitschleife für 5ms Pause von 16 Mhz (Attiny 26). Das Problem liegt bei der Bestimmung der Durchläufe. Kann mir jemand erklären, wie ich diese bestimmen kann? T=((1)/!6Mhz)= 65,2 ns-->(5ms)/(65,2ns)= 80000 Taktzyklen notwendig...weiter weiß ich nicht


Mfg

[Holomino]

Im Datenblatt des Controllers (PDF) findest Du in der Tabelle "Instruction Set Summary" in der letzten Spalte die Angabe der "Clocks". Das sind die Prozessorzyklen, die jeder Assemblerbefehl für seine Ausführung braucht. Für "ldi" z.B. 1 Zyklus, für "ret" 4 Zyklen.

Wo mehrere Werte angegeben sind (z.B. "brne") befragst Du die Assemblerhilfe für den jeweiligen Befehl.
Der Rest ist "aufaddieren" und ggf. in den Loops multiplizieren.

Der schnellere Weg: Wenn Du die Frequenz weißt, die die Routine vor der Anpassung verwendete, rechnest Du einfach ( so Pi mal Daumen) $C9 * alte Frequenz / 16MHz. Das passt dann nicht auf die Nanosekunde, lässt sich aber z.B. im Simulator später durch Variieren der beiden Loop-Werte noch verbessern.

[sisi]

danke für die schnelle Antwort..Ich muss dazu sagen, dass ich erst seit einer Woche mich mit Mikrocontroller und assembler befasse.

Also die Tabelle habe ich bereits angeschaut..
delay5ms: ; 5ms Pause
ldi temp1, $21--------------------------------------------------> 1 Takt
WGLOOP0: ldi temp2, $C9-------------------------------------> 1 Takt
WGLOOP1: dec temp2------------------------------------------> 1 Takt
brne WGLOOP1--------------------------------------------------> Sprung 2 Takte, sonst 1 Takt
dec temp1-------------------------------------------------------> 1 Takt
brne WGLOOP0--------------------------------------------------> Sprung 2 Takte , sonst 1 Takt
ret----------------------------------------------------------------> 4 Takte
Innere Schleife ( dec + brne = 3 Takte) ..... Jedoch weiß ich nicht wie ich nicht wie ich die 80000 Takte auf die drei schleifen verteilen soll. Also ich weiß nicht wie ich die einzelnen Durchläufe nun berechnen soll.....

MFG

[Holomino]

Jo, eine Woche ist vielleicht etwas knapp.
Du weißt aber schon etwas über Hexadezimalcodes (z.B. dieses magische $C9 ist eine 201)?

Es sind zwei Schleifen. Die innere
WGLOOP1: dec temp2------------------------------------------> 1 Takt
brne WGLOOP1--------------------------------------------------> Sprung 2
wird $C9, also 201 mal ausgeführt

201* 3 Takte = 603 Takte


Die äußere Schleife
WGLOOP0: ldi temp2, $C9-------------------------------------> 1 Takt
.//Innere Loop mit 603 Takten
.
dec temp1-------------------------------------------------------> 1 Takt
brne WGLOOP0--------------------------------------------------> Sprung 2

wird durch das vorladen von $21 in temp1 33 mal ausgeführt.
Du kannst also rechnen 33 * (4 + 603) = 20031 Takte

Wenn wir es ganz genau nehmen, musst Du jetzt noch Einsprung (z.B. jmp) und Rücksprung (ret) und den Takt für das Vorinitialisieren des temp1-Registers dazuzählen, das sind aber nur Peanuts.

Ich sage Dir also auf den Kopf zu: Das sind etwa 20000 Takte, die Routine war ursprünglich für 4MHz gebaut. Der Autor war ein Elektrotechnikingenieur der alten Schule ("ohne besondere Anforderungen reichen zwei Stellen nach dem Komma").

In der Praxis setz einfach ein $32 anstatt der $C9, dann klappst auch mit den 16MHz.

- - - Aktualisiert - - -

FALSCH FALSCH FALSCH: In der Praxis setze für die $21 eine $84 ein.
(ich hab's noch gemerkt)

[sisi]

Brauche ich da eigentlich nicht eine dritte schleife? Wie kommst du aus ($21= 33, $84=132 bzw $32=50)??

[Holomino]

Hatte ich ja fast geahnt, dass Du die Hexadezimalschreibweise nicht kennst.

Führende "$" oder "0x" vor Zahlen kennzeichnen im AVR Assembler die Hexadezimaldarstellung einer Zahl.

Statt der Zehnerbasis unseres herkömmlichen Zahlensystems verwendet diese die 16er-Basis. Mit der 16er-Basis stellst Du einen Bytewert mit 2 Stellen dar.
Die Praxis. Du zählst: 0,1,2,3,4,5,6,7,8,9, STOPP, jetzt kommt nicht 10, es geht weiter mit A,B,C,D,E,F, STOPP, jetzt kommt nicht G, weil mit "F" hast du eigentlich "15" gemeint, jetzt geht es weiter mit der nächsten Stelle, also 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 1A, 1B, 1C, 1D, 1E, 1F, 20,...
bei FF hast Du damit den höchstmöglichen Wert 255 für ein Byte erreicht.

Sinn dieses durchaus für Außenstehende völlig unverständlichen Machwerkes der Hexadezimalcodierung ist die Zusammenfassung eines Bytes (8 Bits) in zwei Zeichen. Du fasst dabei jeweils die unteren 4 und die oberen vier Bits zu einem Zeichen 0..F zusammen.

Witz des ganzen: Geübte rechnen Dir in Windeseile diese Hexadezimalzahlen in reale Zahlen um und auch wieder zurück, aber nicht nur dass: Am Zahlenwert 201 musst Du erst rechnen, ob das vierte Bit von unten gesetzt ist oder nicht. In der Hexadezimalschreibweise ist das ein Hingucken: 4tes Bit ist in der unteren Gruppe, also in der 9. 9 ist größer als 8, also ist die 8 gesetzt, also ist das vierte Bit von unten gesetzt.

Die Hexadezimalschreibweise ist also ein guter Kompromiss zwischen der normalen Ganzzahldarstellung (einzelne Bitwerte lassen sich nicht ablesen) und der Binärschreibweise (8 Stellen sind zu lang zum Schreiben)

Kleine Übung: Wenn Du's nicht verstanden hast (ich bin kein Lehrer), Google es woanders nach, aber spätestens dann müsstest Du mir sagen können, was die Zahl $AA in unserem Zahlensystem ist. Wenn Du das nicht drauf hast, brauchst Du mit Assembler nicht weiter zu machen. Das begegnet Dir so oft, da kann man sich kaum verweigern.

Die dritte Schleife brauchst Du nicht, weil du mit dem Zahlenbereich der äußeren Schleife hinkommst. Statt 20000 Takten willst Du 80000 Takte warten, daher kannst Du den Schleifenzähler $21 mit 4 multiplizieren, das macht dann $84.

[sisi]

oh, eigentlich weiß ich was die hexadezimaldarstellung ist und wie diese berechnet wird. $AA entspricht doch 170 (Dezimalzahl). Ich weiß dass bei 16 MHz und 5 ms 80000 Takte notwendig sind, dass was ich nicht weiß wie ich quasi die Durchläufe ( Hexazahlen) bestimmen soll....
Zum Beispiel wenn ich eine dritte Schleife dazufüge..

ldi R17, ?????
WGLOOP0: ldi R18, ?????
WGLOOP1: ldi R19, ?????
WGLOOP2: dec R19
brne WGLOOP2
dec R18
brne WGLOOP1
dec R17
brne WGLOOP0

Danke

[Holomino]

Die beiden inneren Loops durchlaufenen 20000 Takte. Du willst 80000 Takte haben? Dann musst Du wohl die inneren Loops vier mal durchlaufen. Dann nimm doch 4 als Startwert für die äußere Loop. Wo ist das Problem? Ob Du den Prozessor 100 mal bis zehn oder zehn mal bis hundert zählen lässt, ist dem ziemlich egal. Der merkt nicht, wenn er sich in der Nase bohrt.

Warum Du allerdings darauf bestehst, eine dritte Loop außen rum zu bauen, verstehe ich noch nicht. Das kostet Dich ein Register für den dritten Schleifenzähler. Assembler ist keine Hochsprache, Register werden nicht wie Variablen gescoped. Wenn Du also dieses dritte Register zufällig oder beabsichtigt vor dem Aufruf Deiner Wartefunktion verwendest, ist der Inhalt nach dem Durchlauf der Wartefunktion wech.
Allgemeine Maßnahmen dagegen sind:
- Verwende Register pragmatisch in einer Routine (so wenige wie möglich. So viele, wie nötig)
- verwende Push und Pop, damit Du im aufrufenden Programmteil nicht unbeabsichtigt etwas überschreibst. Erst wenn Du in Deinen Routinen zu Anfang die Inhalte aller verwendeten Register (die NICHT als Eingabeparameter oder Rückgabewerte verwendet werden) auf den Stack pushst, dann veränderst und am Ende in umgekehrter Reihenfolge wieder die Inhalte zurückpoppst, bist Du auf der sicheren Seite.

[sisi]

Es tut mir leid für die nervige Fragen.. also ein letztes mal . Ja ich will 80000 Takte. Wie meinst du mit ich muss die inneren loops vier mal durchlaufen bzw 4 als Startwert nehmen?



vielen vielen Dank

- - - Aktualisiert - - -

also warum ich eine dritte schleife noch mit einfügen möchte, weil die mir empfohlen wurde. Ich habe zusätzlich diesen Beitrag aus einem Forum gelesen und dachte es wäre notwendig.

Beitag aus Forum:

Also, gesetzt den Fall, ein djnz-Befehl bräuchte nur 1 Taktzyklus. Nehmen wir mal an, die CPU würde mit 4,772727 MHz betrieben (ich weiß gar nicht, wie ich jetzt auf so'n komischen Wert komme...) Dann bedeutet das, sie hat 4772727 Takte pro Sekunde und um 2 Sekunden zu überbrücken, muß man 2 x 4772727 = 9545454 Takte durchlaufen lassen - oder anders ausgedrückt: So oft muß die innere Schleife durchlaufen werden, wenn der Befehl nur 1 Takt verbraucht. Verbraucht er mehr Takte, muß man den Wert durch die Anzahl Takte teilen, wenn er z.B. 3 Takte verbraucht, wäre der "Ticker-Wert" = 3191919 (eben 9545454 / 3).

Von diesem Wert wird ja rückwärts nach 0 gezählt. Register sind ja immer binär, daher also z.B. 8 oder 16 oder 32 bit breit (ja, es gibt auch 4- oder 12-bit Register...), das heißt, der Wert ist im Falle von 8-Bit-Registern immer nach genau 8 bit zu teilen.
Wäre er also 9545454, wäre das binär (als 24-bit-Wert) :
100100011010011011101110, der ist also immer nach 8bit zu teilen:

10010001 10100110 11101110, oder 145, 166 und 238 - und genau das sind die Werte, die nach R2, R1 und R0 müssen (nach R0, weil das die innerste Schleife ist, muß der unterste Wert, also hier 238, nach R1 müßte 166 und nach R2 dann 145).

Einfachere Möglichkeit ist, einfach immer durch 256 zu teilen:
9545454 / 256 = 37286, Rest 238
32786 / 256 = 145, Rest 166
(145 / 256 = 0, Rest 145 - aber das braucht man ja nicht mehr zu "berechnen"...)
Diese Teilungsreste sind dann (sozusagen im Zahlensystem der 256) die einzutragenden Werte.
(Ja, oder man wandelt die Zahl einfach ins Hexadezimalsystem und nimmt immer 2 Ziffern... Leider gibts heutzutage Assembler-Programmierer, die noch nie was vom Hexadezimalsystem gehört haben, deswegen weiß ich da manchmal nicht, ob ich das wie früher einfach voraussetzen kann...)

.............

[Holomino]

Die Verwendung des dritten Registers ist eine Ressourcenverschwendung. Zu Anfang denkt man sich: "Ich hab doch 32 davon (R0..31)". Dann stellt man fest, man kann nur mit den oberen 16 alle Assemblerbefehle nutzen und eigentlich gehen davon auch noch die obersten 6 Register noch einmal ab, weil nur damit die 16-Bit-Adressierungen über X, Y und Z möglich sind.
Was bleibt, sind magere 10 Registerchen zur vollen Verwendung.

Zum Abschluss und zum Gedanken anregen:
Wenn es Dir gelingt, eine 1Mikrosekunde-Warteschleife zu verfassen
Wait1u:
//Einsprung 3 Takte über rcall
nop //10*1
nop
nop
nop
nop
nop
nop
nop
nop
nop
ret //Rücksprung 3 Takte
//16 Takte


Dann kannst Du doch auch eine Routine über 100 Mikrosekunden verfassen, in der Du die Wait1u-Routine wiederverwendest:
Wait100u:
//3 Takte Einsprung über rcall
push r16 //1
ldi r16, 84 //1
Wait100u_Loop:
rcall Wait1u //16 Takte
dec r16 //1
brne Wait100u_Loop //2
Wait100u_End:
pop r16 //1
ret //3
//19*84 + 9 = 1605


Dann kannst Du auch nach der gleichen Form eine Wait1m schreiben
Wait1m:
//3 Takte Einsprung über rcall
push r16 //1
ldi r16, 10 //1
Wait1m_Loop:
rcall Wait100u //1605 Takte
dec r16 //1
brne Wait1m_Loop //2
Wait1m_End:
pop r16 //1
ret //3
//1608*10 + 9 = 16089 Takte


Und ganz zum Schluss
Wait5m:
//3 Takte Einsprung über rcall
push r16 //1
ldi r16, 5 //1
Wait5m_Loop:
rcall Wait1m //16089 Takte
dec r16 //1
brne Wait5m_Loop //2
Wait5m_End:
pop r16 //1
ret //3
//16089*5 + 9 = 80454 Takte

Diese Routinen (ich hab's jetzt hier im Editor geschrieben, mag noch irgendwo ein Fehlerchen drin sein) sind erweiterbar (Du kannst Dich damit bis in den Stundenbereich hochkaskadieren), anpassbar (Du musst nur die unterste Funktion an die Frequenz anpassen) und einfach wartbar (die Wartefunktionen haben immer die gleiche Form).
Aber das Wichtigste: das einzige verwendete Register r16 ist in jedem Fall save, weil es in jeder Aufrufebene gepusht und gepoppt wird. Du kannst es also vor dem Aufruf einer der o.g. Wartefunktionen mit einem Wert beschreiben und nach dem Aufruf immer noch sicher sein, dass in r16 noch das steht, was Du dort hineingeschrieben hast.

[Hubert.G]

Dir ist aber schon klar das in der Wartezeit das komplette Programm steht. Es sind weder Eingaben noch Ausgaben möglich.
Für diese Aufgaben sind die Timer vorgesehen.

[Holomino]

Dir ist aber schon klar das in der Wartezeit das komplette Programm steht. Es sind weder Eingaben noch Ausgaben möglich.
Für diese Aufgaben sind die Timer vorgesehen.

Klares "Jein" dazu.
Das kommt auf den Anwendungsfall an. Ich persönlich finde es grausam, ein Konstrukt über einen Timer zu entwerfen, dass mir z.B. das Blinken einer einfachen Betriebs-LED im Sekundentakt erlaubt (am Blinken über die Wait-Routine siehst Du sogar, wie Deine IRQ-Auslastung ist).
Alles in IRQs auzulagern, während das Hauptprogramm sich bei
Main: jmp Main
in der Nase bohrt, ist auch Kappes.

Timer verwendest Du, wenn Du ein Timing (nach oben und nach unten, z.B. UART-Emulation) einhalten willst. Die Verwendung von einfachen Warteschleifen zur Einhaltung von Mindestzeiten (z.B. Tastenentprellen, I2C-Emulation,...) ist meiner Ansicht nach legal.

[Hubert.G]

Das ist wohl etwas Ansichtssache. Ich verwende wait-Routinen ausschließlich nur vor dem main um zu warten bis externe Geräte oder Bauteile Ready sind oder um auf dem Display Programmname und Versionsnummer anzuzeigen.
Innerhalb der main gibt es nur Timer, wenn es ein ernst gemeintes Programm ist. Ein "blinky" zählt nicht dazu.

[oberallgeier]

.. Klares "Jein" .. während das Hauptprogramm sich bei ... Main: jmp Main ... in der Nase bohrt, ist auch Kappes ...Ein klares, hartes, umfassendes Urteil! Nur, obs stimmt? Ich weiß nicht ob das nur Ansichtssache oder (auch) Programmierstil ist, aber ich kann Hubert.G nur uneingeschränkt beipflichten.

[Holomino]

Ein klares, hartes, umfassendes Urteil! Nur, obs stimmt? Ich weiß nicht ob das nur Ansichtssache oder (auch) Programmierstil ist, aber ich kann Hubert.G nur uneingeschränkt beipflichten.


Das ist weder ein klares noch ein hartes Urteil. Eher die Erfahrung aus der Praxis, die zeigt, dass auch von Anfängern zusammengefummelte Lösungen neben der Norm exzellent laufen können, dass man Anfängern ihre Lernkurve und die verbundenen Fehler zugestehen muss. Die Ansprüche steigen mit der Zeit automatisch, damit die Wissbegierde und der Kenntnisstand. Dazwischen aber müssen erst einmal spielerische Erfolgserlebnisse her.

Schau mal im AVR-Tutorial bei Mikrocontroller.net (oder in Dein altes AVR-Assembler-Buch im Regal), in welchem Kapitel Timer angesprochen werden. Über den didaktischen Sinn, diese Infos in die zweite Hälfte des Lehrinhaltes zu schieben, mag ich mich mit Dir nicht streiten (und Du sicherlich auch nicht mit den Autoren).

[Robobionic]

Das ist weder ein klares noch ein hartes Urteil. Eher die Erfahrung aus der Praxis, die zeigt, dass auch von Anfängern zusammengefummelte Lösungen neben der Norm exzellent laufen können, dass man Anfängern ihre Lernkurve und die verbundenen Fehler zugestehen muss. Die Ansprüche steigen mit der Zeit automatisch, damit die Wissbegierde und der Kenntnisstand. Dazwischen aber müssen erst einmal spielerische Erfolgserlebnisse her.


Einem Anfänger zu empfehlen er könnte sich zwecks schneller Teilerfolge einen schlechten Stil angewöhnen und davon auszugehen seine Ansprüche würden noch steigen halte ich für ein Gerücht.
Wie soll so jemand den Ansprüche entwickeln, wenn er bereits am Anfang keinen Wert auf Qualität und Normen legt?

[Holomino]

Kein Gerücht, siehe Hubert G.:
Noch 2014 hat Hubert G. bei einem LED-Problem geholfen, siehe https://www.roboternetz.de/community/threads/65673-Beginner-Problem-LED-steuern?highlight=Hubert+G.
Damals hielt er die Verwendung der _delay_ms-Funktion in der Main für legitim,
Heute schließt er dies quasi aus.
Der hat sich weiterentwickelt.;)


Übrigens: Lass mich bitte nicht dumm sterben: Wo steht diese Norm? Ist das schon ISO-zertifiziert? Ich lerne gern.

[Robobionic]

Kein Gerücht, siehe Hubert G.:
Noch 2014 hat Hubert G. bei einem LED-Problem geholfen, siehe https://www.roboternetz.de/community/threads/65673-Beginner-Problem-LED-steuern?highlight=Hubert+G.
Damals hielt er die Verwendung der _delay_ms-Funktion in der Main für legitim,
Heute schließt er dies quasi aus.
Der hat sich weiterentwickelt.;)

Ich wüsste nicht weshalb solche Beispiele der Maßstab für Anfänger sein sollten.



Übrigens: Lass mich bitte nicht dumm sterben: Wo steht diese Norm? Ist das schon ISO-zertifiziert? Ich lerne gern.

Ich bezweifle das Du gerne lernst, Du hast sie selbst erwähnt.



Eher die Erfahrung aus der Praxis, die zeigt, dass auch von Anfängern zusammengefummelte Lösungen neben der Norm exzellent laufen können

[Klebwax]

Alles in IRQs auzulagern, während das Hauptprogramm sich bei
Main: jmp Main
in der Nase bohrt, ist auch Kappes.

Ein bischen länger darfs schon sein:


while(1) {
sleep();
}

Bei den meisten Betriebssystemen sieht die Mainloop so aus.



Timer verwendest Du, wenn Du ein Timing (nach oben und nach unten, z.B. UART-Emulation) einhalten willst. Die Verwendung von einfachen Warteschleifen zur Einhaltung von Mindestzeiten (z.B. Tastenentprellen, I2C-Emulation,...) ist meiner Ansicht nach legal.
Alles, was der Compiler schluckt, ist legal, trotzdem gibt es einen Unterschied zwischen Lehrlingsarbeit und Meisterwerk. Die meisten Delays kann man in einem regelmäßigen Timertick abhandeln, insbesondere das Einhalten von Mindestzeiten und gerade das Entprellen von Tasten, auch mehreren gleichzeitig. Und wenn man sein System sauber analysiert und geplant hat, fällt möglicherweise das Timing für ein SW-UART for free ab.

MfG Klebwax

[White_Fox]

Einem Anfänger zu empfehlen er könnte sich zwecks schneller Teilerfolge einen schlechten Stil angewöhnen und davon auszugehen seine Ansprüche würden noch steigen halte ich für ein Gerücht.
Warum sollte das schlechter Stil sein? Weil es nicht dein Stil ist?
Schlechter Stil ist meiner Meinung nach eher herumzuprogrammieren, ohne sich vorher wenigstens mal ein paar Notizen zum Programmablauf zu machen...von einem sauberen Ablaufdiagramm ganz zu schweigen. Oder gar das Verzichten auf Kommentare.

Gegen sowas finde ich einfache Zählschleifen als Warteroutine gut verzeihlich...gerade für Anfänger. Ob eine Lösung gut ist oder nicht, richtet sich meiner Meinung nach eher nach dem Anwendungsfall. Die Pauschalaussage "Das ist schlechter Stil" ist allzu oft völlig unbegründet. Dies hier halte ich für so einen Fall.

[Robobionic]

Warum sollte das schlechter Stil sein? Weil es nicht dein Stil ist?


Ich würde Dir erstmal empfehlen alle Beiträge in diesem Thread zu lesen, dann müssen wir uns nicht im Kreis drehen.
Die Vorgehensweise und Begründungen von Holomino sind nicht professionell und sowas wie "Ich persönlich finde es grausam, ein Konstrukt über einen Timer zu entwerfen"
mag seine Grundhaltung zu dem Thema sein, kann aber kaum die Grundlage für einen Anfänger oder Lehrling sein.

[Hubert.G]

Kein Gerücht, siehe Hubert G.:
Noch 2014 hat Hubert G. bei einem LED-Problem geholfen, siehe https://www.roboternetz.de/community/threads/65673-Beginner-Problem-LED-steuern?highlight=Hubert+G.
Damals hielt er die Verwendung der _delay_ms-Funktion in der Main für legitim,
Heute schließt er dies quasi aus.
Der hat sich weiterentwickelt.;)


Ich habe allerdings auch geschrieben:
Innerhalb der main gibt es nur Timer, wenn es ein ernst gemeintes Programm ist. Ein "blinky" zählt nicht dazu.

[Holomino]

Zu diesen Diskussionen fällt mir immer nur auf (und das ist meine Erfahrung):
- "Ich finde...", "meiner Meinung nach ...", " Für mich"... sind Meinungsäußerungen.
- "...ist unprofessionell..", "..nimmt man.." sind dargestellte Fakten.
Bringt man Euch diese Art von Diskussionskultur gar nicht mehr bei?
Über Meinungen kann man sich nicht streiten. Fakten kann man widerlegen.

Ich für meinen Teil verwende Wait-Funktionen immer noch gerne, insbesondere zu Diagnosezwecken bei der Inbetriebnahme. Da kann man wunderschön schnell kleine Testroutine schreiben, die einzelnen Signale durchpingen. Wenn ich wissen will, ob der benachbarte I2C-Bus Transienten auf dem AD-Eingang erzeugt, gebe ich mit Waitern in drei Minuten proggen oszilloskoptaugliche Rechtecke auf dem zu testenden Port aus.

Und wenn ich ein Programm mit einfachem Ablauf schreibe (z.B. polle an I2C, sende als UART), hindert mich nichts, aber auch gar nichts daran, die ganze Sache sequenziell mit zwei emulierten Schnittstellen auf dem Tiny45 mit Wait-Routinen herunterzuproggen.
Solange ich da auf beiden Schnittstellen Master bin und nichts asynchrones zu befürchten habe, muss ich das für meinen Teil nicht haben. Es würde mit Timern nicht besser funktionieren.

[Robobionic]

Über Meinungen kann man sich nicht streiten. Fakten kann man widerlegen.

Was gibt es denn an einem wahren Sachverhalt zu widerlegen?

[Holomino]

Deine zusammengebastelte Realität ist mir zu einfach:p

[Robobionic]

Kann es sein das Du Schwierigkeiten mit der deutschen Sprache hast? Ich habe Dir eine einfache Frage gestellt, weil Dir offensichtlich die Begriffsdefinition von "Fakten" nicht bekannt ist.

[Holomino]

Oh, jemand, der mit mir die Diskussionskultur fernab der Thematik bis zum Letzten ausleben möchte?!? Das kann ich gut.
Allerdings hab ich keinen Bock, wegen eines Trolls das Forum weiter vollzumüllen.

Trag Dich mal als Nutzer ein, dann machen wir das per PN aus.

[White_Fox]

Ich würde Dir erstmal empfehlen alle Beiträge in diesem Thread zu lesen, dann müssen wir uns nicht im Kreis drehen.
Die Vorgehensweise und Begründungen von Holomino sind nicht professionell und sowas wie "Ich persönlich finde es grausam, ein Konstrukt über einen Timer zu entwerfen"
Danke für den Tip...tat ich vorher schon.
Alles, was Holomino geschrieben hat, war, daß es auf den Einzelfall ankommt ob man Warteschleifen lieber so oder so realisiert bzw. sieht er die Sache nicht so dogmatisch. Und meiner Meinung nach haben Dogmen in technischen Belangen nichts verloren.

Mir fällt auf daß du dich immer zu Wort meldest, um Streit zu suchen. Dann such mal schön weiter... :)

[Robobionic]

Mir fällt auf daß du dich immer zu Wort meldest, um Streit zu suchen. Dann such mal schön weiter...

Deine provokanten Behauptungen wie auch in anderen Threads, ziehen bei mir nicht.
Dir bleibt also nichts anderes übrig als beim Thema zu bleiben und sachlich zu argumentieren.

Da Ihr aber andere Meinungen nicht akzeptieren könnt, halte ich es für sinnvoller Euch alleine zu lassen.
Denn Euer Niveau passt in der Tat nicht zur jeder Diskussionskultur.


Danke für den Tip...tat ich vorher schon.
Alles, was Holomino geschrieben hat, war, daß es auf den Einzelfall ankommt ob man Warteschleifen lieber so oder so realisiert bzw. sieht er die Sache nicht so dogmatisch. Und meiner Meinung nach haben Dogmen in technischen Belangen nichts verloren.

Du kannst seine Aussagen komprimieren, verschönen und werten wie Du willst, es gibt dennoch andere Meinungen.

Holominos Grundhaltung zu Warteschleifen teilt nicht jeder und Anfänger können nicht abschätzen wann und ob
man sich dazu entscheiden sollte. Das hat übrigens auch etwas mit Berufs und Ausbildungserfahrung zutun.

Wenn sich also jemand wie sisi nach seiner Empfehlung einen solchen Stil angewöhnt und gar nicht versteht
was da passiert, ist das nunmal nicht sauber. Zumal Holomino nachdem ihn einige andere Leser darauf hingewiesen haben
auch noch wie folgt rechtfertigte.



Eher die Erfahrung aus der Praxis, die zeigt, dass auch von Anfängern zusammengefummelte Lösungen neben der Norm
exzellent laufen können, dass man Anfängern ihre Lernkurve und die verbundenen Fehler zugestehen muss. Die Ansprüche steigen mit der Zeit automatisch, damit die Wissbegierde und der Kenntnisstand.
Dazwischen aber müssen erst einmal spielerische Erfolgserlebnisse her.

Diese Praxis halte ich für sehr fragwürdig, denn wer so argumentiert dem fehlt es eindeutig an Qualitätsbewusstsein und verhält sich unprofessionell.

[Holomino]

Da Ihr aber andere Meinungen nicht akzeptieren könnt, halte ich es für sinnvoller Euch alleine zu lassen.


Ich glaube, da fehlt ein Komma.

Naja, nobodies perfect.