Forum: Mikrocontroller und Digitale Elektronik Multitasking bei ATmega8 ?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Kurt W. (surfer2000at)


Bewertung
0 lesenswert
nicht lesenswert
Mulitasking ist vielleicht nicht der richtige Ausdruck ...

Ich versuche schon seit Tagen eine einfache Schaltuhr auf einem ATmega8 
in C zu "programmieren". Dazu hab ich schon etliche Threads 
durchgeackert und jede Menge Codeschnipsel gelesen, schlauer bin ich 
dadurch nicht geworden. Dazu möchte ich bemerken, dass ich KEINE DCF-Uhr 
haben möchte, sondern einfach eine normale Quarzuhr - bei welcher dann 
ein Ausgang mehrmals (4x) pro Tag ein bzw. wieder ausschaltet.

Bei der ganzen Leserei ist mir jedoch eines aufgefallen:
Der Quarz liefert den Takt - die genaue Frequenz kann ich feststellen 
oder verwebde dann halt eine echten Uhrenquarz - die Genauigkeit ist 
nicht unbedingt das Problem. Die Impulse werden nun mit Prescaler 
geteilt und dann hochgezählt usw..... das ist mir klar.

Aber (Obwohl ich soweit noch lange nicht bin!):
jetzt kommt der Zähler resp. die Uhrzeit dann irgendwann, sagen wir um 
12:30, zu dem Punkt, wo geschaltet werden soll (okay, ich hoffe mal, 
irgendwann kriege ich das hin), jetzt wird doch ein Unterprogramm 
(Interrupt?) aufgerufen und abgearbeitet - werden da dann gleichzeitig 
auch die Impulse gezählt oder nicht ????

Wenn JA, wäre das ja im entferntesten Sinne Multitasking ...
Wenn NEIN, dann muss die Uhr ja zwangsläufig falsch gehen ...

von Thomas D. (thomasderbastler)


Bewertung
0 lesenswert
nicht lesenswert
Also in C kann ich nicht helfen, aber eine Uhr mit einer Zusatzfunktion, 
wo ein Relais geschaltet wird, ist in dem Sinne keine Multitasking.

If H=12 And M=30 then
 relais=1
End if

Die Uhr läuft ununterbrochen weiter...

von Max H. (hartl192)


Bewertung
0 lesenswert
nicht lesenswert
Kurt W. schrieb:
> werden da dann gleichzeitig
> auch die Impulse gezählt oder nicht ????
Wenn du die Impulse mit einem Timer zählst, dann schon.

Die übliche Vorgehensweise ist diese:
Uhrenquarz an einen 16bit Timer. Der Uhrenquarz hat 2^15Hz, ein 16bit 
Timer würde also alle zwei Sekunden überlaufen und ein Interrupt 
erzeugen. Wenn dir eine Auflösung von zwei sekunden genügt, kannst du 
das so lasse, wenn nicht musst du den Timer bei jedem Interrupt mit 2^15 
= 0x8000 vorladen.
In der ISR (Interrupt Service Routine) würde ich dann die 
Sekunden/Minute/Stunde hochzählen. In C könnte das so aussehen:
1
sek++;    //oder sek=sek+2; wenn du die Variante ohne vorladen wählst.
2
if(sek>59)
3
{
4
  sek=sek-59;
5
  min++;
6
}
7
if(min>59)
8
{
9
  min=min-59;
10
  stunde++;
11
}
12
if(stunde>23)
13
  stunde=0;

Und nachdem die die Zeit weitergezählt hast könntest du dann den 
Vergleich mit der Einschaltzeit machen:
1
if((stund==st_ein)&&(min==min_ein))
2
  PORTA |= (1<<PA0));

von mknoelke (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ja, wenn Du einen Hardwaretimer mit automatischer Rückladung verwendest.
Der triggert z.B. jede sek. den IRQ und fängt dann automatisch wieder 
von vorne an.
In der IRQ oder durch polling des Overflow Bits muß Du dann die Zeit 
hochzählen, schalten etc.
Wenn Du also nicht länger als eine Sekunde die Auswertung des Timer 
Überlaufs unterbrichst dann geht die Uhr korrekt.

Multitasking ist dann noch mal ein bisschen was anderes ...

von Karol B. (johnpatcher)


Bewertung
0 lesenswert
nicht lesenswert
Es scheint mir ja fast so, dass dir noch eine Menge Grundlagen fehlen. 
Multitasking ist ein relativ eng gefasster Begriff in der Informatik. 
Die Wikipedia definiert das z.B. so:

> Der Begriff Multitasking [ˌmʌltiˈtɑːskɪŋ] (engl.) bzw. Mehrprozessbetrieb
> bezeichnet die Fähigkeit eines Betriebssystems, mehrere Aufgaben (Tasks)
> (quasi-)nebenläufig auszuführen.

Da du auf deinem AVR wohl kein (echtes/brauchbares) Betriebssystem 
laufen lassen wirst, gibt es in diesem Sinne auch kein Multitasking.

Dein AVR besitzt auch nur eine CPU und kann demnach in jeder Zeiteinheit 
auch nur einen einzelnen Befehl ausführen.

So nun zur Praxis: Dein Fall entspricht eigentlich so ziemlich genau dem 
"Standardfall", welcher z.B. unter [1] beschrieben wird. In einem 
Timerinterrupt kannst du dich um die Inkrementierung der Zeit kümmern, 
da dies regelmäßig und zuverlässig zu bestimmten Zeiten geschehen muss. 
So könntest du z.B. mit den typischen 32.768 kHz eines Uhrenquarzes 
einen Zähler erhöhen und dich ggf. um den Overflow der Minuten bzw. 
Stunden kümmern. Das ist eine relativ kurze Aufgabe, die sich ideal 
dafür eignet von einem Interrupt erledigt zu werden.

Weniger zeitkritisch wäre dann die eigentliche Ansteuerung der Ausgänge. 
Daher würdest du dies in deiner "Hauptschleife" tun. Hier vergleichst du 
einfach immer wieder die aktuelle Zeit mit dem Zeitfenster, in dem 
irgend etwas passieren soll und führst ggf. die Aktion aus.

Je nach deinen Programmierkenntnissen würdest du die Zeiten und die 
dazugehörigen Aktionen in einer Tabelle vorhalten, um das Ganze so 
flexibel wie möglich zu halten.

Mit freundlichen Grüßen,
Karol Babioch

[1]: 
https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Interruptgesteuerter_Programmablauf

von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
Alles was man braucht ist ein Timer, den Rest kann man nahezu 
beliebig schlecht programmieren.

von Max H. (hartl192)


Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
> Alles was man braucht ist ein Timer, den Rest kann man nahezu
> beliebig schlecht programmieren.
Die ISR sollte halt nicht länger als eine Sekunde brauchen.

: Bearbeitet durch User
von Rudolph (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Karol Babioch schrieb:
> Dein AVR besitzt auch nur eine CPU und kann demnach in jeder Zeiteinheit
> auch nur einen einzelnen Befehl ausführen.

Nur ein Core ist kein Grund kein Multitasking zu machen.

von greg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hmm. Schafft es jemand das Inkrementieren einer Variable länger als eine 
Sekunde dauern zu lassen? :) Ohne Tricks wie Delayschleifen!

von Rudolph (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wird eng, aber man kann ja auch noch den Takt heftig runtersetzen. :-)

von Max H. (hartl192)


Bewertung
0 lesenswert
nicht lesenswert
greg schrieb:
> Hmm. Schafft es jemand das Inkrementieren einer Variable länger als eine
> Sekunde dauern zu lassen? :) Ohne Tricks wie Delayschleifen!

Anfänger schaffen es manchmal alles möglich in die ISR einzubauen, was 
darin nicht zu suchen hat...

: Bearbeitet durch User
von Kurt W. (surfer2000at)


Bewertung
0 lesenswert
nicht lesenswert
Danke erstmal für die Antworten.

@ Karol Babioch:

> Das ist eine relativ kurze Aufgabe ... Weniger zeitkritisch ...

Nochmals für mich:

1)

Der Quarz gibt einen Impuls ...
Der Timer zählt diesen Impuls
UND (!!!)
zur gleichen Zeit arbeitet die CPU ein bit aus irgendeinem
beliebigen Unterprogramm ab.

ODER 2)

Ein Unterprogramm wird aufgerufen und mit jedem Impuls des Quarzes wird 
ein bit des Progis abgearbeitet ....
während dieser Zeit werden vom Timer die Impulse nicht gezählt.

Oder liege ich da komplett falsch ???

von Max H. (hartl192)


Bewertung
0 lesenswert
nicht lesenswert
Der Timer arbeitet im Hintergrund unabhängig von der CPU.
Wenn der Timer überläuft kann (und soll er in diesem Fall) ein Interrupt 
auslösen.

Kurt W. schrieb:
> zur gleichen Zeit arbeitet die CPU ein bit aus irgendeinem
> beliebigen Unterprogramm ab.
Diese "bit" nennt man Befehl

@TO: Mal eine Frage: Weißt du was ein Interrupt ist?

: Bearbeitet durch User
von Karol B. (johnpatcher)


Bewertung
-1 lesenswert
nicht lesenswert
Hi,

Kurt W. schrieb:
> zur gleichen Zeit arbeitet die CPU ein bit aus irgendeinem
> beliebigen Unterprogramm ab.

Nein, zur "gleichen" Zeit kann die CPU nur eine Instruktion ausführen, 
s.o.

Kurt W. schrieb:
> Oder liege ich da komplett falsch ???

Ja.

Einen dedizierten Quarz, um die Impulse zu zählen brauchst du 
wahrscheinlich gar nicht. Die Verwendung eines Timers samt dazugehöriger 
ISR reicht schon.

Der Interrupt unterbricht dann in regelmäßigen Abständen (z.B. jede 
Sekunde) den "normalen" Programmfluss und erhöht den Zähler. In der 
Hauptschleife vergleichst du einfach stets die aktuelle Zeit mit den 
Vorgaben.

Du solltest dich tatsächlich nochmal mit den Grundlagen vertraut machen. 
Das ist hier schon ziemliches Standardrepertoire und mit ein wenig 
Einlesen sollten sich deine Fragen von selbst klären. Es mag durchaus 
sein, dass du mit der Implementierung im Speziellen Probleme bekommen 
wirst (je nach Programmiererfahrung), aber der Ablauf im Allgemeinen ist 
doch recht einfach zu durchschauen.

Mit freundlichen Grüßen,
Karol Babioch

von Max H. (hartl192)


Bewertung
0 lesenswert
nicht lesenswert
Ich weiß jetzt nich wie weit der TO ist, aber wenn er es noch nicht kann 
sollte er sich Timer und Interrupt ansehen.

Hier eine sehr kurze Erklärung:
>Ein Interrupt (Unterbrechung) unterbricht ein laufendes Programm, wenn ein
>bestimmtes Ereignis, auf das reagiert werden soll, stattgefunden hat. Die
>Reaktion wird in der sogenannten Interrupt Service Routine (kurz: ISR)
>definiert.
>Einfach gesagt, ein Interrupt stoppt ein laufendes Programm nach dem
>Ausführen der aktuellen Zeile, ruft die ISR auf und nach deren Ausführung
>startet das Programm wieder, ab der Zeile, vor der es durch Interrupt
>angehalten wurde.


>Ein Timer ist ganz einfach ein bestimmtes Register im µC, das völlig ohne
>Zutun des Programms, also per Hardware, hochgezählt wird. Das alleine
>wäre noch nicht allzu nützlich, wenn nicht dieses Hardwareregister bei
>bestimmten Zählerständen ein Interrupt auslösen könnte.
>Ein solches Ereignis ist der Overflow (Überlauf): Da die Bitbreite des
>Registers beschränkt ist, kommt es natürlich auch vor, dass der Zähler so
>hoch zählt, dass der nächste Zählerstand mit dieser Bitbreite nicht mehr
>darstellbar ist und der Zähler wieder auf 0 zurückgesetzt wird. Dieses
>Ereignis nennt man den Overflow und es ist möglich an dieses Ereignis ein
>Interrupt zu koppeln.
Der Timer kann Impulse zählen, die vom Oszillator kommen oder in einem 
Pin eingespeist werden.

Da de µC fast nichts zu tun hat, könntest du auch den gesamten µC mit 
einem Uhrenquarz betreiben.

: Bearbeitet durch User
von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
Siehe Timer, Interrupt und Multitasking.

Und auch DOS konnt schon Multitasking, wenn auch nicht auf 
Anwendungsebene und ohne GUI. Diverse Treiber un Hilfprogramme liefen 
dort auch quasiparallel. Multitasking gibt es nicht erst seit dem 
Multi-CPU-Core-Zeitalter.

von Kurt W. (surfer2000at)


Bewertung
0 lesenswert
nicht lesenswert
@ Karol Babioch


>> Kurt W. schrieb:
>> zur gleichen Zeit arbeitet die CPU ein bit aus irgendeinem
>> beliebigen Unterprogramm ab.
>
> Nein, zur "gleichen" Zeit kann die CPU nur eine Instruktion ausführen,


Okay, ich vergaß zu erwähnen, dass ich kein Programmierer bin und daher 
auch keine Grundlagen kenne, bis auf das bisserl, was ich hier im Forum 
gelesen UND verstanden habe (ich geb zu, das ist ziemlich wenig) Ich 
habe gerade erst mal vor 2 Wochen mit den µC´s angefangen. Der Sohn 
einer Bekannten, ein Informatik Student, hat mir am Anfang ein 
Grundgerüst zusammengebastelt, dass leider nicht funktionierte (wegen 
Kleingkeiten). Durch das Lesen hier im Forum habe ich es dann selbst 
nach ein paar Tagen zum Laufen gebracht. Leider hat der Mann im Moment 
so gut wie keine Zeit. Trotzdem möchte ich das mal begonnene Projekt 
fertig machen. Es ist ja nicht nur die Schaltuhr, es sollen da noch 
einige andere Funktionen dazu.

Also ich bitte um Nachsicht, und ich bin auch nicht mehr im Studienalter 
..

Zurück zu meiner Frage: Eigentlich hast Du mit der oben zitierten 
Aussage bestätigt, dass ich doch nicht ganz falsch liege. wenn die CPU 
zeitgleich immer nur eine Instruktion ausführt, dann fehlen dem Timer 
eben diese paar Nano- oder Microsekunden ...
(auch wenn es in der Praxis vielleicht keine Rolle spielt)

von Karol B. (johnpatcher)


Bewertung
0 lesenswert
nicht lesenswert
Kurt W. schrieb:
> Also ich bitte um Nachsicht, und ich bin auch nicht mehr im Studienalter
> ..

Das ist ja prinzipiell kein Problem. Aber es ist halt nicht 
empfehlenswert mittendrin anzufangen und die Grundlagen bzw. die 
dahinter stehenden Konzepte außen vor lassen. Damit machst du es dir 
selbst nur unnötig schwer.

Das zuvor bereits verlinkte AVR GCC Tutorial ist ein guter Punkt für den 
Einstieg und klärt alle deine bisher gestellten Fragen.

Kurt W. schrieb:
> Zurück zu meiner Frage: Eigentlich hast Du mit der oben zitierten
> Aussage bestätigt, dass ich doch nicht ganz falsch liege. wenn die CPU
> zeitgleich immer nur eine Instruktion ausführt, dann fehlen dem Timer
> eben diese paar Nano- oder Microsekunden ...

Nein, eine "ideale" Taktquelle vorausgesetzt fehlt gar nichts, solange 
kein Interrupt verloren geht.

Mit freundlichen Grüßen,
Karol Babioch

von Kurt W. (surfer2000at)


Bewertung
0 lesenswert
nicht lesenswert
@ Max H.

Wie weit ich bin, steht jetzt in meinem vorigen Posting.

Durch Deine Aussage wird mir (hoffentlich) einiges klarer:

>das völlig ohne Zutun des Programms, also per Hardware, hochgezählt wird.

D.h. im Klartext, dass der Timer konstant weiterzählt, egal ob jetzt die 
CPU zeitgleich irgendein Programm abarbeitet oder nicht.

sehe ich das so richtig ?

von Max H. (hartl192)


Bewertung
0 lesenswert
nicht lesenswert
Kurt W. schrieb:
> wenn die CPU
> zeitgleich immer nur eine Instruktion ausführt, dann fehlen dem Timer
> eben diese paar Nano- oder Microsekunden ...

Der Timer läuft immer noch unabhängig von der CPU.

von halli (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Karol Babioch schrieb:
> Da du auf deinem AVR wohl kein (echtes/brauchbares) Betriebssystem
> laufen lassen wirst, gibt es in diesem Sinne auch kein Multitasking.
>
Absoluter Blödsinn.

> Dein AVR besitzt auch nur eine CPU und kann demnach in jeder Zeiteinheit
> auch nur einen einzelnen Befehl ausführen.

Absolut Falsch. Bitte verbreite hier doch keine gehobelte Entengrütze. 
So einen Quatsch kannst Du in Deinem Computerspiele-Forum los werden.

von Karol B. (johnpatcher)


Bewertung
0 lesenswert
nicht lesenswert
Kurt W. schrieb:
> .h. im Klartext, dass der Timer konstant weiterzählt, egal ob jetzt die
> CPU zeitgleich irgendein Programm abarbeitet oder nicht.

Ja, die Zähler wird von deinem Programm aus "konfiguriert" und läuft 
dann unabhängig davon weiter und löst ggf. Interrupts aus.

Mit freundlichen Grüßen,
Karol Babioch

von Kropf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Kurt W. schrieb:
> zeitgleich immer nur eine Instruktion ausführt, dann fehlen dem Timer
> eben diese paar Nano- oder Microsekunden ...
> (auch wenn es in der Praxis vielleicht keine Rolle spielt)

Kann man so nicht sagen. Der Timer ist eine HW Einheit im µC und zählt 
ein Register auf bzw ab, unabhängig von der der CPU. Dem fehlen keine 
Nanosekunden wenn die ein Programm abgearbeitet wird.

Hier mal meine Erklärung:

Der Quarz (bzw Oszillator) gibt Impulse
und taktet damit die CPU
und taktet damit gleichzeitig den Timer

Die CPU kann damit ein Programm abarbeiten, pro Impuls im Schnitt ca. 
1/2 Maschinenbefehle.
Erreicht der Timer einen vorherbestimmten Stand, kann die CPU "sofort" 
in ein anderes, möglicherweise unabhängiges Programm (Interrupt Service 
Routine) springen und dieses abarbeiten.
Ist die ISR abgearbeitet, nimmt die CPU das unterbrochene Programm an 
der unterbrochenen Stelle wieder auf. Der Timer wird unabhängig von der 
CPU weitergetaktet.

Liegt an der Fähikeit des Programmierers diese Möglichkeiten zu nutzen 
und/oder zu variieren. Die eine CPU in einem AVR kann zu einer Zeit nur 
das Hauptprogramm oder das Programm in einer ISR abarbeiten.

von Karol B. (johnpatcher)


Bewertung
-1 lesenswert
nicht lesenswert
halli schrieb:
> Absoluter Blödsinn.

Wieso? Ich habe mit dem Zitat von oben nahe gelegt, dass Multitasking 
zumindest ein Betriebssystem (und damit Prozesse) voraussetzt. Das ist 
bei AVRs nicht üblich und nur mit sehr viel Mühe überhaupt möglich. Die 
mir bekannten Projekte sind wohl eher als Proof-of-Concept zu verstehen. 
Wirklich benutzt tut das keiner.

halli schrieb:
> Absolut Falsch. Bitte verbreite hier doch keine gehobelte Entengrütze.

Was soll daran denn bitte falsch sein? Du scheint selbst nämlich nicht 
den Hauch einer Ahnung von der ganzen Thematik zu haben ...

Mit freundlichen Grüßen,
Karol Babioch

von Kurt W. (surfer2000at)


Bewertung
0 lesenswert
nicht lesenswert
@ Max H.

Danke für die Info, Genau das wollte ich wissen!

@ halli (Gast)

Bitte nicht unhöflich werden.

von Helmut S. (helmuts)


Bewertung
0 lesenswert
nicht lesenswert
> dann fehlen dem Timer eben diese paar Nano- oder Microsekunden

 Der Zähler zählt unabhängig von CPU weiter. Du musst den einfach so 
einstellen, dass er z. B. jede Sekunde die ISR aufruft. Dem Timer fehlt 
gar nichts, wenn der nur so schnell zählen darf, dass du genügend Zeit 
hast den mal kurz wieder auf den Startwert zu setzen bevor der Zähler 
den nächsten Takt erhält. (Dazu setzt du den Vorteiler des Zählers auf 
256.) In der ISR setzt du als erstes den Timer wieder auf den Startwert. 
Dann erhöhst du die Variable "Sekunde" um 1. Hier beendest du das ISR 
Programm. Den Rest erledigst du in deiner Endlosschleife im 
Hauptprogramm.

von Falk B. (falk)


Bewertung
2 lesenswert
nicht lesenswert
Bei uCs ist es fast wie im wahren Leben.

Mensch = CPU
Wecker = Timer

Den Wecker kann der Mensch einstellen, wann der klingeln so. Dann macht 
der Mensch was anderes, z.B. Schnee schippen. Wenn dann der Wecker 
klingelt, kann man das hören und den Kuchen aus dem Ofen nehmen. Egal 
wieviel Schnee man schippt, der Wecker geht gleich. Und wenn man das 
Klingeln überhört, selber schuld ;-)

von Max H. (hartl192)


Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
> Bei uCs ist es fast wie im wahren Leben.
>
> Mensch = CPU
> Wecker = Timer
>...
Der Vergleich gefällt mir. So habe ich das noch nie gesehen.

Ich würde dem Timer aber eher mit einer Eieruhr vergleiche.

: Bearbeitet durch User
von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
Ergänzung. Wenn man den Wecker hört, geht man rein und nimmt den Kuchen 
aus dem Ofen. Die Aufgabe Schnee schippen ist kurz unterbrochen wurden, 
geht aber gleich weiter. Die deutlich WICHTIGERE Aufgabe, Kuchen aus dem 
Ofen ist zeitnah erledigt worden, Wecker sei dank. Und wenn das Schee 
schippen beendet ist, kann man Kuchen essen. ;-)

von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
Und noch was zum Thema Multitasking. Der Wecker und Mensch können echt 
parallel arbeiten, weil es eigenständige physikalische Objekte sind. Der 
Mensch (CPU) kann immer nur eine Sache tun. Z.B. Holz hacken oder Zaun 
streichen. Nun kann er z.B. 2h Holz hacken und 2 Stunden Zaun streichen, 
dann wieder 2h Holz hacken und wieder Zaun streichen. Schaut man am 
Abend das Ergebnis an, hat der Mensch quasi parallel zwei Dinge 
erledigt. Real aber immer im Wechsel. Hier sieht man auch, wo eine 
Grenze liegt. Schaut man nun jede Stunde, macht er mal das eine, mal das 
andere. Er könnte nun im 5 Minuten Wechsel Holz hacken und Zaun 
streichen, aber dadurch würde er mehr rumlaufen als effektiv arbeiten.

Bei CPUs ist das ähnlich, nur in einem anderen Zeitmaßstab. Die können 
problemlos alle paar Millisekunden was vollkommen anderes machen, aber 
nicht unbedingt alle paar Mikrosekunden.

von Stephan B. (matrixstorm)


Bewertung
0 lesenswert
nicht lesenswert
Hi.

Fall es jemanden interessiert: AVR-threadlib.

Fuer tinyUSBboard als fertiges Beispiel erhaeltlich:

http://matrixstorm.com/avr/tinyusbboard/#examples


MfG

von mknoelke (Gast)


Bewertung
0 lesenswert
nicht lesenswert
greg schrieb:
> Hmm. Schafft es jemand das Inkrementieren einer Variable länger als eine
> Sekunde dauern zu lassen? :) Ohne Tricks wie Delayschleifen!

Sollten wir hier einen heißen Anwärter für einen Wettbewerb haben ?

von Jobst M. (jobstens-de)


Bewertung
0 lesenswert
nicht lesenswert
Helmut S. schrieb:
> In der ISR setzt du als erstes den Timer wieder auf den Startwert.

Das sollte der Timer eigentlich selbst machen.

> Dann erhöhst du die Variable "Sekunde" um 1. Hier beendest du das ISR
> Programm. Den Rest erledigst du in deiner Endlosschleife im
> Hauptprogramm.

Gerade bei IRQ-Aufrufen im ms- oder gar s-Bereich kann man auch gleich 
die restlichen Variablen hochzählen.
Also wenn Sekunde>59, dann Sekunde=0 und Minute++ .... etc.


Karol Babioch schrieb:
> Wieso? Ich habe mit dem Zitat von oben nahe gelegt, dass Multitasking
> zumindest ein Betriebssystem (und damit Prozesse) voraussetzt. Das ist
> bei AVRs nicht üblich und nur mit sehr viel Mühe überhaupt möglich.

Ich weiß nicht. Die Register in einem TimerIRQ auf den Stack schieben, 
den Stack wechseln, die Register von dem neuen Stack zurückschreiben und 
'zurückspringen' ist für mich weder ein Betriebssystem, noch viel Mühe.


Für den TO ist jetzt aber wichtiger, dass der Timer unabhängig von der 
CPU Takte zählt und bei erreichen einer vorher definierten Marke der CPU 
ein Signal gibt, damit diese zwischendurch etwas Anderes erledigen kann 
und anschliessend wieder damit weiter macht, wobei sie unterbrochen 
wurde.

D.h. wenn Du den Timerinterrupt verstanden hast, zählt Deine Uhr quasi 
von ganz alleine und im Hauptprogramm kannst Du Dich dann um so Dinge 
wie Zeitvergleiche oder Uhr stellen kümmern. Es geht keine Sekunde 
verloren.



Gruß

Jobst

: Bearbeitet durch User
von B. G. (smarti)


Bewertung
0 lesenswert
nicht lesenswert
http://www.mikrocontroller.net/articles/Datei:Interrupt_Programme.gif

Dieses Bild sollte am besten darstellen wie das Programm abläuft!

Der Rest wurde oben schon erwähnt

von Karl H. (kbuchegg) (Moderator)


Bewertung
0 lesenswert
nicht lesenswert
Jobst M. schrieb:

>> Dann erhöhst du die Variable "Sekunde" um 1. Hier beendest du das ISR
>> Programm. Den Rest erledigst du in deiner Endlosschleife im
>> Hauptprogramm.
>
> Gerade bei IRQ-Aufrufen im ms- oder gar s-Bereich kann man auch gleich
> die restlichen Variablen hochzählen.
> Also wenn Sekunde>59, dann Sekunde=0 und Minute++ .... etc.

Nicht nur 'kann', sondern sogar 'soll' bzw. 'muss'.

Denn die Uhr muss korrekt zählen, auch wenn das Hauptprogramm 20 
Sekunden lang Däumchen dreht oder auf einen Tastendruck vom Benutzer 
wartet, der aber gerade am Klo ist. Erfolgt die Zeitweiterschaltung 
komplett in der ISR, dann ist das gewährleistet.
Eine Uhrzeit sieht man am besten als eine komplette Einheit ein, die 
eben aus 3 Teilen besteht. In der ISR wird die Uhrzeit als ganzes 
weitergestellt und nicht nur Teile davon. Sekunden, Minuten, Stunden, 
Tage, ... weiterzählen ist doch Pipifax für den AVR. Die paar 
Instruktionen hat man in der ISR praktisch immer, ohne dass gleich alles 
andere den Bach runter geht.

von Karol B. (johnpatcher)


Bewertung
0 lesenswert
nicht lesenswert
Jobst M. schrieb:
> Die Register in einem TimerIRQ auf den Stack schieben,
> den Stack wechseln, die Register von dem neuen Stack zurückschreiben und
> 'zurückspringen' ist für mich weder ein Betriebssystem, noch viel Mühe.

Und eben auch kein Multitasking nach obiger Definition von Wikipedia. 
Das erfordert nämlich ein Betriebssystem und damit die Prozesse bzw. 
Threads. Das was du beschreibst ist der "typische" Interrupt gesteuerte 
Ablauf auf einem Mikrocontroller.

Mit freundlichen Grüßen,
Karol Babioch

von Achim S. (achims)


Bewertung
0 lesenswert
nicht lesenswert
Hallo
Auch auf dem Atmega 8 ist was möglich. Falk hat ja die Richtung 
vorgegeben. Es kommt nur drauf, wie man es macht. Such doch mal nach 
Nibo2 und Multitasking. Habe es mit dem ATmega 128 gemacht. Es gibt aber 
ein sehr schönes Tut dazu. Alles erklärt. Kann es dir auch als pdf 
schicken.
achim

von Quack (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Karol Babioch schrieb:
> Und eben auch kein Multitasking nach obiger Definition von Wikipedia.

Das ist halt der Unterschied zwischen echtem und Wiki-Wissen. Was soll 
denn das von Jobst beschrieben Verfahren sein, wenn nicht Multitasking? 
Die Anwesenheit eines komplexen Betriebssystems zu fordern, damit aus 
dem beschriebenen Verfahren ein Multitasking wird, ist schlicht Quatsch.

Im Gegensatz zu Jobst bin ich uebrigens der Meinung, dass es sich auch 
bei einer einfachen MT-Implementation schon um ein Betriebssystem 
handelt. Aber auch das aendert nichts daran, dass die Wiki-Definition 
Quatsch ist - dann koennte man auch definieren, dass es sich nur um ein 
MT-System handelt, wenn ein Computer vorhanden ist.

von Karol B. (johnpatcher)


Bewertung
-1 lesenswert
nicht lesenswert
Quack schrieb:
> Das ist halt der Unterschied zwischen echtem und Wiki-Wissen.

Definitionen haben schon ihren Sinn. Ohne solche ist es nämlich 
schwierig sich über irgendetwas zu unterhalten und nicht völlig 
aneinander vorbei zu reden. Und dein "echtes" Wissen stellt nun mal auch 
kein halbes Jahrhundert Informatik auf den Kopf.

Quack schrieb:
> Was soll
> denn das von Jobst beschrieben Verfahren sein, wenn nicht Multitasking?

Das von Jobst beschriebene Verfahren ist auch dasjenige, das wir dem 
Threadersteller hier seit gestern versuchen nahe zu legen. Dabei handelt 
es sich aber nicht um Multitasking, sondern um die Abarbeitung eines 
Interrupts in Form einer Interrupt Service Routine. Diese wird aber im 
gleichen Kontext wie auch das restliche Programm ausgeführt. Demnach 
also kein Multitasking nach obiger Definition.

Quack schrieb:
> Die Anwesenheit eines komplexen Betriebssystems zu fordern, damit aus
> dem beschriebenen Verfahren ein Multitasking wird, ist schlicht Quatsch.

Die Anwesenheit eines Betriebssystem wird gefordert, damit es die 
Abstraktion "Prozess" (bzw. "Thread") gibt, die in sich gekapselt und 
unabhängig von anderen Prozessen sind und prinzipiell etwas völlig 
anderes tun - ohne zu wissen, dass sie nicht alleine ausgeführt werden. 
Demnach macht auch der Begriff eines Kontextwechsels keinen Sinn, weil 
nun einmal alles im gleichen Kontext ausgeführt wird.

Im Übrigen ist es zwar schön und gut sich darüber zu "streiten", dem 
Threadersteller bringt das aber herzlichst wenig. Überhaupt bin ich der 
Meinung, dass die letzten Einträge hier wohl mehr verwirren als 
weiterhelfen, auch wenn ich dabei eine nicht untergeordnete Rolle 
gespielt habe. Der Threadersteller sollte wohl eher einmal den typischen 
Ablauf eines Mikrocontroller-Programms begreifen, anstatt auf 
irgendwelche Bibliotheken hingewiesen zu werden, die Versuchen 
Multitasking auf AVRs zu implementieren.

Mit freundlichen Grüßen,
Karol Babioch

von Jobst M. (jobstens-de)


Bewertung
0 lesenswert
nicht lesenswert
> Definitionen haben schon ihren Sinn.

Wikipedia ist für mich allerdings keine Definitionsgrundlage. Hast Du 
Dir auch die Informationen zu dem Thema mal in der englischen Wiki 
angesehen?


> Das von Jobst beschriebene Verfahren ist auch dasjenige, das wir dem
> Threadersteller hier seit gestern versuchen nahe zu legen.

Nein, das stimmt nicht.

> Dabei handelt
> es sich aber nicht um Multitasking, sondern um die Abarbeitung eines
> Interrupts in Form einer Interrupt Service Routine. Diese wird aber im
> gleichen Kontext wie auch das restliche Programm ausgeführt. Demnach
> also kein Multitasking nach obiger Definition.

Du hast meine Beschreibung offensichtlich überhaupt nicht verstanden.


> Die Anwesenheit eines Betriebssystem wird gefordert, damit es die
> Abstraktion "Prozess" (bzw. "Thread") gibt, die in sich gekapselt und
> unabhängig von anderen Prozessen sind und prinzipiell etwas völlig
> anderes tun - ohne zu wissen, dass sie nicht alleine ausgeführt werden.

Und? Das tun die Prozesse in dem von mir beschriebenen Ablauf doch.


Gruß

Jobst

von Quack (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Karol Babioch schrieb:
> Und dein "echtes" Wissen stellt nun mal auch
> kein halbes Jahrhundert Informatik auf den Kopf.

Dann argumentiere auf dieser Basis, aber nicht auf der von zweifelhaften 
Wikipedia-Zitaten.

> Quack schrieb:
>> Was soll
>> denn das von Jobst beschrieben Verfahren sein, wenn nicht Multitasking?
> Das von Jobst beschriebene Verfahren ist auch dasjenige, das wir dem
> Threadersteller hier seit gestern versuchen nahe zu legen.

Nein, ganz sicher nicht. Lies das nochmal nach, Jobst beschreibt, wie 
man im Interrupt den Stack umlaedt um von einem Kontext zum anderen zu 
wechseln:

"Ich weiß nicht. Die Register in einem TimerIRQ auf den Stack schieben,
den Stack wechseln, die Register von dem neuen Stack zurückschreiben und
'zurückspringen' ist für mich weder ein Betriebssystem, noch viel Mühe."

Das ist preemptives MT, nicht das ordinaere Ausfuehren eines Interrupts.

Der TO muss nur im Interrupt seine Uhr weiter zaehlen und anderswo seine 
Aktion ausloesen, wenn ein bestimmter Zeitpunkt eingetroffen ist. Das 
ist ueblicherweise die Hauptschleife, kann aber natuerlich auch ein 
anderer Interrupthandler sein. Wenn es nicht lange dauert, muss es auch 
nicht anderswo sein.

>> Die Anwesenheit eines komplexen Betriebssystems zu fordern, damit aus
>> dem beschriebenen Verfahren ein Multitasking wird, ist schlicht Quatsch.
> Die Anwesenheit eines Betriebssystem wird gefordert, damit es die
> Abstraktion "Prozess" (bzw. "Thread") gibt,

Das sind keine unbedingt noetigen Eigenschaften eines Bestriebssystems. 
Andersrum wird auch hier wieder ein Schuh daraus: Implementiert ein 
System Prozesse und Threads, kann man davon ausgehen, dass es sich um 
ein Betriebssystem handelt.

> Im Übrigen ist es zwar schön und gut sich darüber zu "streiten", dem
> Threadersteller bringt das aber herzlichst wenig.

Das ist richtig, aber Falschaussagen im Thread stehen zu lassen, schadet 
noch mehr. Das haettest du also bedenken sollen, bevor du die Diskussion 
um losgetreten hast mit deinem Wiki-Zitat.

von Karol B. (johnpatcher)


Bewertung
0 lesenswert
nicht lesenswert
Jobst M. schrieb:
> Wikipedia ist für mich allerdings keine Definitionsgrundlage. Hast Du
> Dir auch die Informationen zu dem Thema mal in der englischen Wiki
> angesehen?

Ja, und das ist weitestgehend kohärent. Auch dort ist von Prozessen, 
Scheduling und Kontextwechseln die Rede. Alles klassische Aufgaben eines 
Betriebssystems.

Jobst M. schrieb:
> Nein, das stimmt nicht.

> Du hast meine Beschreibung offensichtlich überhaupt nicht verstanden.

Scheint wohl fast so.

Jobst M. schrieb:
> Ich weiß nicht. Die Register in einem TimerIRQ auf den Stack schieben,
> den Stack wechseln, die Register von dem neuen Stack zurückschreiben und
> 'zurückspringen' ist für mich weder ein Betriebssystem, noch viel Mühe.

Ich hatte wohl das "den Stack wechseln" überlesen. Ansonsten beschreibst 
du nämlich genau den Ablauf einer ISR. Zugegeben, damit kommt man dem 
Konzept des Multitaskings schon etwas näher, aber das Problem ist nach 
wie vor, dass du nur einen Adressraum hast, und sich die einzelnen 
Programmteile munter ihre Variablen überschreiben können. Eine Kapselung 
in Form von echten Prozessen sieht dein Konzept nämlich nicht vor.

Mit freundlichen Grüßen,
Karol Babioch

von Jobst M. (jobstens-de)


Bewertung
0 lesenswert
nicht lesenswert
Nur nochmal zur Verdeutlichung:

Prozess N läuft
TimerIRQ wird ausgelöst
Prozess N+1 läuft
TimerIRQ wird ausgelöst
Prozess N+2 läuft
TimerIRQ wird ausgelöst
:


TimerIRQ
 Rette Register (incl. Staturregister) auf aktuellem Stack.
 Speichere SP in Variable N
 Inkrementiere N bis zur Maximalanzahl an Tasks hoch und fange dann von 
vorne an
 Schreibe inhalt von Variable N in SP
 Hole Register vom Stack
RETI



Und es ist Prozess 1 völlig egal, was Prozess 4 macht, solange sie nicht 
gleichzeitig auf die selbe Peripherie oder RAM zugreifen.


Gruß

Jobst

von Jobst M. (jobstens-de)


Bewertung
0 lesenswert
nicht lesenswert
Karol Babioch schrieb:
> Ja, und das ist weitestgehend kohärent. Auch dort ist von Prozessen,
> Scheduling und Kontextwechseln die Rede.

Das passiert ja auch.

> Alles klassische Aufgaben eines Betriebssystems.

DOS -> kein OS


> aber das Problem ist nach
> wie vor, dass du nur einen Adressraum hast, und sich die einzelnen
> Programmteile munter ihre Variablen überschreiben können. Eine Kapselung
> in Form von echten Prozessen sieht dein Konzept nämlich nicht vor.

Windows98 -> kein OS
AmigaOS -> kein OS
...OS -> kein OS


Gruß

Jobst

von Karol B. (johnpatcher)


Bewertung
0 lesenswert
nicht lesenswert
Jobst M. schrieb:
> DOS -> kein OS
> Windows98 -> kein OS

Dann sind wir uns ja einig ;).

Spaß beiseite: Ich kenne die Details der Speicherverwaltung der von dir 
genannten Systeme nicht.

Aber gut, ich gebe dir recht. Mit diesen Ausführungen bzw. Beispielen im 
Hintergrund lässt sich das von dir beschriebene Konzept wohl auch als 
Multitasking bezeichnen, auch wenn es verglichen mit "modernen" 
Betriebssystemen äußerst primitiv ist. Ich habe Multitasking wohl etwas 
strikter ausgelegt.

Nichtsdestotrotz ist das natürlich nicht unbedingt der typische Ablauf 
auf einem Mikrocontroller und für das Vorhaben des Threaderstellers auch 
gar nicht nötig.

Mit freundlichen Grüßen,
Karol Babioch

: Bearbeitet durch User
von Quack (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Sorry, Karol - aber offensichtlich hast du ausser Wikipedia-Wissen nicht 
viel zum Thema MT zu bieten und versuchst gegenueber Leuten, die 
teilweise Dekaden Erfahrung damit haben irgendwie Recht zu behalten. :-(

von Jobst M. (jobstens-de)


Bewertung
0 lesenswert
nicht lesenswert
Karol Babioch schrieb:
> Nichtsdestotrotz ist das natürlich nicht unbedingt der typische Ablauf
> auf einem Mikrocontroller und für das Vorhaben des Threaderstellers auch
> gar nicht nötig.

Ohne Deine 'Hilfe' wäre ihm der ganze Rotz auch erspart geblieben.
Du liest Dir die Texte nicht richtig durch und schreibst irgendwas dazu, 
was aus irgendwelchen Halbwahrheiten besteht.

Bestes Beispiel (noch vor dem mit dem überlesenen Stackwechsel):

Kurt W. schrieb:
> Der Quarz gibt einen Impuls ...
> Der Timer zählt diesen Impuls
> UND (!!!)
> zur gleichen Zeit arbeitet die CPU ein bit aus irgendeinem
> beliebigen Unterprogramm ab.

Deine Antwort:

Karol Babioch schrieb:
> Kurt W. schrieb:
>> zur gleichen Zeit arbeitet die CPU ein bit aus irgendeinem
>> beliebigen Unterprogramm ab.
>
> Nein, zur "gleichen" Zeit kann die CPU nur eine Instruktion ausführen,
> s.o.
>
> Kurt W. schrieb:
>> Oder liege ich da komplett falsch ???
>
> Ja.

Bullshit! Kurt hat doch Recht. Genau so ist es. Auch wenn das 'Bit' ein 
Befehl ist.


Gruß

Jobst

: Bearbeitet durch User
von Karol B. (johnpatcher)


Bewertung
0 lesenswert
nicht lesenswert
Quack schrieb:
> Sorry, Karol - aber offensichtlich hast du ausser Wikipedia-Wissen nicht
> viel zum Thema MT zu bieten

Du bist natürlich frei dies so zu sehen.

Quack schrieb:
> versuchst gegenueber Leuten, die
> teilweise Dekaden Erfahrung damit haben irgendwie Recht zu behalten. :-(

In dem Beitrag über dir, habe ich doch das Zugeständnis gemacht, dass 
der von Jobst M. gemachte Ansatz wohl (oder übel) als Multitasking 
durchgeht und das meine anfängliche Auslegung tatsächlich etwas zu eng 
war.

Nichtsdestotrotz korreliert der Begriff "Multitasking" ganz stark mit 
dem Begriff "Betriebssystem" und es ist äußerst schwierig seriöse 
Quellen zu finden, die vom Einen, nicht aber vom Anderen, sprechen, weil 
das Multitasking typischerweise eine Eigenschaft des Betriebssystems 
ist.

Jobst M. schrieb:
> Du liest Dir die Texte nicht richtig durch und schreibst irgendwas dazu,
> was aus irgendwelchen Halbwahrheiten besteht.

Ich versuche in der Regel durchaus gewissenhafte und hoffentlich 
korrekte Antworten zu liefern. Dies ist mitunter ein Grund warum meine 
Antworten verhältnismäßig lang sind. Das mir dabei der ein oder andere 
Fehler unterläuft, ist natürlich auch klar und es ist doch schön, wenn 
andere, wie z.B. du, mich darauf aufmerksam machen. Ich empfinde die 
daraus entstandene Diskussion durchaus als lesenswert, auch wenn sie 
nicht unbedingt hilfreich für den eigentlichen Threadersteller ist.

Jobst M. schrieb:
> Bullshit! Kurt hat doch Recht. Genau so ist es. Auch wenn das 'Bit' ein
> Befehl ist.

Na, gut, dass kannst du jetzt natürlich so interpretieren. Das geht aber 
fast ein bisschen in die Richtung Bestätigungsfehler [1]. Ich (und wohl 
auch die anderen, die versucht haben zu helfen) hatte zum damaligen 
Zeitpunkt das Gefühl, dass der Threadersteller das Konzept noch nicht 
ganz verstanden hatte und habe seine Aussagen scheinbar anders 
interpretiert als du das jetzt - im Nachhinein - tust. Die Nachfragen 
des Threaderstellers bezüglich der "verloren" gegangen Zeit geben mir ja 
wohl zumindest insoweit recht, dass da in der Tat noch 
Verständnisprobleme vorlagen.

Mit freundlichen Grüßen,
Karol Babioch

[1]: https://de.wikipedia.org/wiki/Best%C3%A4tigungsfehler

: Bearbeitet durch User
von Rudolph (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Karol Babioch schrieb:
> Nichtsdestotrotz ist das natürlich nicht unbedingt der typische Ablauf
> auf einem Mikrocontroller

Nein, Kontext-Switching per Timer-Interrupt mit Stack-Swapping geht 
eigentlich schon wieder einen Schritt zu weit für das auf 
Mikrocontrollern "typische" Multitasking.

http://www.mikrocontroller.net/articles/Multitasking

Der Artikel ist doch ganz nett, das Stichwort ist kooperatives 
Multitasking.

Die drei "Tasks" "taste_lesen", "led_blinken" und "uart_lesen" sind 
nicht wirklich getrennt, im Beispiel sind das gerade mal 
Unter-Funktionen.

von Jobst M. (jobstens-de)


Bewertung
0 lesenswert
nicht lesenswert
Karol Babioch schrieb:
> das Multitasking typischerweise eine Eigenschaft des Betriebssystems
> ist.

Sinnvollerweise wird diese Eigenschaft wenn vorhanden von einem 
Betriebssystem übernommen. An anderer Stelle würde es keinen Sinn 
ergeben. Aber beides in Abhängigkeit ist kein muss und das wird von 
vielen Quellen tatsächlich unterschlagen.


Karol Babioch schrieb:
> Ich empfinde die
> daraus entstandene Diskussion durchaus als lesenswert

Ich nicht.

Karol Babioch schrieb:
> [1]

Ist schon klar, dass Du Dir schon die richtigen Begriffe zurechtgelegt 
hast, um eine Rechtfertigung dafür haben zu wollen, den Kopf aus der 
Schlinge zu ziehen, aber ich muss Dich enttäuschen:

Karol Babioch schrieb:
> als du das jetzt - im Nachhinein - tust.

Ich habe das nicht im Nachhinein so interpretiert, ich habe das das 
erste Mal gelesen und habe es so gesehen, wie ich es immer noch sehe. 
Nur war es zu dem Zeitpunkt nicht mehr notwendig einzugreifen, da dieser 
Punkt schon geklärt wurde:

Karol Babioch schrieb:
> Ja, die Zähler wird von deinem Programm aus "konfiguriert" und läuft
> dann unabhängig davon weiter und löst ggf. Interrupts aus.

Merkwürdiger Weise auch von Dir, was Deine Aussage

Karol Babioch schrieb:
> Ich (und wohl
> auch die anderen, die versucht haben zu helfen) hatte zum damaligen
> Zeitpunkt das Gefühl, dass der Threadersteller das Konzept noch nicht
> ganz verstanden hatte und habe seine Aussagen scheinbar anders
> interpretiert als du das jetzt - im Nachhinein - tust.

mehr wie eine Schutzbehauptung aussehen lässt ...


So, ich habe jetzt keinen Bock mehr hier ...

von Karol B. (johnpatcher)


Bewertung
-1 lesenswert
nicht lesenswert
Rudolph schrieb:
> Der Artikel ist doch ganz nett, das Stichwort ist kooperatives
> Multitasking.

Ok, danke für die Referenz. Die kannte ich in der Tat noch nicht. 
Kooperatives Multitasking an sich war mir natürlich bekannt, nicht aber 
im Zusammenhang mit Mikrocontrollern. Das trifft es aber tatsächlich 
ganz gut.

Jobst M. schrieb:
> Ich nicht.

Zumindest aber war es dir anscheinend wichtig genug mehrfach darauf 
einzugehen.

Jobst M. schrieb:
> Ist schon klar, dass Du Dir schon die richtigen Begriffe zurechtgelegt
> hast, um eine Rechtfertigung dafür haben zu wollen, den Kopf aus der
> Schlinge zu ziehen, aber ich muss Dich enttäuschen:

Ich will hier überhaupt nicht meinen Kopf aus irgendeiner Schlinge 
ziehen. Übrigens eine ganz interessante Terminologie, die du hier 
wählst, wohl auch, um subtil durchsickern zu lassen, dass du es hier auf 
mich als Person abgesehen hast.

Und ich hatte eben den Eindruck, dass du jetzt im Nachhinein alle 
Beiträge durchgehst und jedes meiner Worte umdrehst, um meine Kompetenz 
in Frage zu stellen. Und mit dem o.g. Link und den darin genannten 
Artikeln wollte ich dich nur darauf hinweisen, dass das menschliche 
Gehirn leider nicht objektiv arbeitet und oft dazu neigt, die 
Wahrnehmung dahingehend zu manipulieren, sodass das Beobachtete mit der 
Erwartung übereinstimmt.

Letztendlich wollen wir doch alle hier helfen. Mag sein, dass hier nicht 
alles ideal gelaufen ist bzw., dass man dem Threadersteller besser 
helfen hätte können. Ich denke aber, dass er im Großen und Ganzen eine 
Hilfestellung erhalten hat, die ihn definitiv weiterbringt.

Jobst M. schrieb:
> Ich habe das nicht im Nachhinein so interpretiert, ich habe das das
> erste Mal gelesen und habe es so gesehen, wie ich es immer noch sehe.
> Nur war es zu dem Zeitpunkt nicht mehr notwendig einzugreifen, da dieser
> Punkt schon geklärt wurde:

Dann ist es umso verwunderlicher, dass du dies nun, wo das eigentliche 
Problem geklärt zu sein scheint, mir zum persönlichen Vorwurf machen 
willst.

Jobst M. schrieb:
> mehr wie eine Schutzbehauptung aussehen lässt ...

Weniger eine Schutzbehauptung als eine Rechtfertigung für deinen zuvor 
gemachten Vorwurf.

Jobst M. schrieb:
> So, ich habe jetzt keinen Bock mehr hier ...

Es zeugt natürlich von unendlicher menschlicher Reife, wenn man Vorwürfe 
persönlicher Natur in den Raum stellt, und sich dann vom Acker macht.

Mit freundlichen Grüßen,
Karol Babioch

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.