Programm komplett im Interrupt ausführen?!

In den Interrupt gehören Codesegmente, die zeitkritisch sind und 
unmittelbar ausgeführt werden müssen und nicht unterbrochen werden 
dürfen. Alles andere findet im Hauptprogramm statt.

Thommy schrieb:
> Alle 100µS wird eine LED per Timerinterrupt weitergezählt und...

Thommy schrieb:
> Das Programm dürfte
> schätzungsweise maximal 100Befehle lang werden und der Controller läuft
> mit 20Mhz. Es bleibt also mehr als genug Zeit.

Und der Controller verbraucht mehr als genug Strom dafür. Nimm 1Mhz als 
Taktfrequenz und nutze den Sleep-Modus, aus dem der Controller alle 
100µs geweckt wird, wenn sonst nichts anliegt.

Wenn feststeht, dass der MC nichts weiter als das beschriebene zu tun 
hat, ist dein Ansatz völlig in Ordnung.

Pseudocode:

ISR: setze flag
     return

main: flag gesetzt?
      wenn ja, Programmteil ausführen
      goto main


oder (deine Variante)

ISR: Programmteil ausführen
     return

main: tue gar nichts


Jacke wie Hose. Problematisch kann das allenfalls werden, wenn andere 
Interrupts dazukommen

Ich schließe mich der Meinung von crazyhorse an: Wenn das Programm nur
aus einem zyklisch auszuführenden Teil (und sonst nichts) besteht, ist
es nicht nur möglich, sondern sogar sinnvoll, alles in einer
Timer-Interruptroutine auszuführen. Da dann im Main nichts getan werden
muss, kann man den Controller dort schlafenlegen, und Strom sparen.

Die Regel, dass der Interruptcode möglichst kurz sein soll, gilt nur
dann, wenn im Hauptprogramm tatsächlich etwas sinnvolles ausgeführt
wird, was hier aber nicht der Fall ist.

H.joachim Seifert schrieb:
> Wenn feststeht, dass der MC nichts weiter als das beschriebene zu tun
> hat, ist dein Ansatz völlig in Ordnung.

Das ist genau der Knackpunkt, so ein Programm ist schlecht erweiterbar.

Wenn Du nur eine Interruptquelle hast, dann kannst Du auf das 
Interruptflag einfach pollen. Spart schonmal 8 CPU-Zyklen und 2 Bytes 
SRAM für den Interruptcall ein.

1

main()

2

{

3

  for(;;){

4

    while( flag == 0 );

5

    flag = 1;      // die AVR-Fallgrube beachten!

6

    // tue was

7

  }

8

}

Peter

So sehen viele meiner main procedures aus:


  while (1)
  {
            // do nothing, just wait interrupts - I love it!

            ClrWdt();

        }; // while

Also kein Problem alles in ISR zu haben.
Es hängt aber auch von der Art des Programmes ab.
Aber, was du oben beschrieben hast funzt in ISRs.

Ich vermeide pollen so gut es eben geht!

Das hier ist ja auch nur ein einfaches Lauflicht:

Beitrag "Re: AVR Sleep Mode / Knight Rider"

Aber dann kommt noch eine Taste zum Bedienen hinzu und schon geht es 
nicht mehr nur mit Interrupt alleine.
Das Main muß auch was tun.


Peter

Yalu X. schrieb:
> Die Regel, dass der Interruptcode möglichst kurz sein soll, gilt nur
> dann, wenn im Hauptprogramm tatsächlich etwas sinnvolles ausgeführt
> wird, was hier aber nicht der Fall ist.

...oder wenn das Interrupt-Programm auch mal so lange dauert, dass ein 
Interrupt verloren gehen kann...

Gruß Dietrich

m.n. schrieb:
> Bei Assembler sind die Spielregeln etwas anders.
> Ich würde das gesamte Programm in den Reset-Interrupt packen
Das macht jedes Programm.

Thommy schrieb:
> Alle 100µS wird eine LED per Timerinterrupt weitergezählt und nach 40
> Schritten soll einmal ausgesetzt werden und ein Reset durchgeführt
> werden. Ausserdem sollen im selben Takt mit dem die Leds durchgezählt
> werden noch diverse Eingänge eingelesen und je nachdem entsprechende
> Ausgänge geschaltet werden. Sonst eigentlich nichts.
Das sind aber schon zwei Programmteile, von denen das Einlesen der 
Klassiker fürs Hauptprogramm ist.

Thommy schrieb:
> Meine Frage ist nun ob man das so machen kann oder ob das
> programmiertechnisch eher ein absolutes No-Go ist?
Kann man so machen.

Thommy schrieb:
> (ein unerfahrener Programmierer)
Aber in deinem Fall würde ich dir raten, das Programm "normal" 
aufzubauen.

Peter Dannegger schrieb:
> Aber dann kommt noch eine Taste zum Bedienen hinzu
Das ist gerade bei so einem Progrämmchen das Problem. Ein einfaches 
Lauflicht wird schnell langweilig. Das schreit ganz schnell nach 
Erweiterung. Das ist eigentlch nie fertig. Und dann bekommst du 
irgendwann Probleme.
Denn so wenig
>Sonst eigentlich nichts.
ist das auch jetzt schon nicht.

Thommy schrieb:
> Das Programm dürfte schätzungsweise maximal 100Befehle
Daraus kann man auch nicht schliessen, daß die Routine besonders schnell 
fertig wird. 100 Befehle sind nicht nur 100 Takte.

label: jmp label

Das ist nur ein Befehl und läuft bis der Controller kaputt geht.

Carsten H. schrieb:
> Ich vermeide pollen so gut es eben geht!
Mache ich auch. Aber wenn man das Letzte aus dem Controller rauskitzeln 
will, ist das vozuziehen:

Peter Dannegger schrieb:
> Spart schonmal 8 CPU-Zyklen und 2 Bytes SRAM für den Interruptcall ein.

mfg.

xXx schrieb:
> Solche
> Standardregeln sind sinnvoll fuer Anfaenger

Nö, die Regeln sind auch für Profis.
Es bringt nichts, sich für kleine Programme einen extra Programmierstil 
anzugewöhnen. Das ist nur doppelt lernen.


Peter

Es gibt meiner Meinung nach nur eine wichtige Regel: Ich mache es mir so 
einfach wie möglich - und das gilt im Besonderen für Anfänger.

Wenn ich nur ein Ereignis habe, mit dem ich synchron bleiben muss, 
brauche ich auch keinen Interrupt. Wenn das Programm nachher um ein 
zeitkritisches Ereignis erweitert werden muss, dann habe ich am Anfang 
mies geplant. Also vorher überlegen, was nötig ist und den leichtesten 
Weg wählen. Der ist dann auch am einfachsten zu "entwanzen".

Eine Interruptroutine, die nur ein Flag setzt und nichts anderes tut, 
ist sinnlos. Die Hardware setzt bereits Flags für alle Ereignisse, die 
auch einen Interrupt auslösen können.

Interrupts werden erst interresant, wenn ich in der ISR tatsächlich 
etwas tue, z.B. einen Ringpuffer füllen oder leeren, um zeitkritische 
Abläufe vom Hauptprogramm abzukoppeln. Dafür muss es aber tatsächlich 
auch zeitkritische Abläufe geben, die das Hauptprogramm überfordern 
würden.

Aber, wer gern sinnloses tut - bitteschön, das funktioniert natürlich 
genauso gut.

Klaus hat schon Recht. Genauso arbeiten SPS.

Es gibt halt viele Wege und eingewöhnte Programmierstile. Z.B. kann man 
auch jedem Interrupt einen Counter beigeben und damit mehrere 
Interrupt-Ereignisse puffern: Der Interrupt zählt den Counter eins hoch, 
die Routine die das Ereignis bearbeitete, den Zähler wieder eins runter. 
Obendrauf läuft eine Routine, die periodische alle Counter auf einen 
Schwellwert überprüft. Ist einer der Counter zu hoch geworden, ist das 
Programm instabil und man kann das übergeordneten Kontrolleinheiten 
weitergeben <Mensch>.

Abdul K. schrieb:
> Genauso arbeiten SPS.
SPS ist keine Programmierung, sondern eine Anwendung, die parametriert 
wird. Ob und wieviel darin an Interrupts ablaufen, weiss der der 
SPS-Anwendungsprogrammierer doch gar nicht. Muß er auch nicht.
Das wissen nur die Leute, die das SPS-System programmiert haben. Und die 
befinden sich auf der Ebene des Mikrocontrollers.
Das Beispiel taugt leider überhaupt nichts. Da hättest du auch mit Excel 
kommen können.
Und deswegen kann man Oldmax nur Recht geben.
oldmax schrieb:
> Also, so blöd wie du meinst, sind die
> Kollegen nun auch nicht. Sorry, aber das musste bei diesem (gefühlt
> arroganten) Post sein.

mfg.

Peter Dannegger schrieb:
> Das ist genau der Knackpunkt, so ein Programm ist schlecht erweiterbar.

Da man aber nicht päpstlicher als der Papst sein muss, muss auch nicht 
jedes Programm erweiterbar sein. Er reicht, sich der "Verantwortung" 
bewusst zu sein, dass man sich im Falle einer Erweiterung mehr Arbeit 
einhandelt.

Wenn man sauberes und sicheres Programmieren mit "setze Flag in ISR und 
reagiere in Hauptprogrammschleife auf Flags" zusammenfassen könnte, gäbe 
es keine fehlerhaften Programme auf dieser Welt.

slow schrieb:
> Also an Thommy: ja, mach es. Software ist Software und jederzeit
> änderbar.
> Mach die ISR wie es Dir gefällt, Du wirst die Software schreiben und
> warten, Du lernst was dabei.

100% ACK

Lasst uns nun trauern!

Autor: Thommy (Gast)
Datum: 17.10.2011 01:35

hat sich in einer empfohlenen Reset Interuptschleife gefangen und
kommt nun nicht mehr heraus. Das ist schade.

Gruss Klaus

Klaus De lisson schrieb:
> Lasst uns nun trauern!
>
> Autor: Thommy (Gast)
> Datum: 17.10.2011 01:35
>
> hat sich in einer empfohlenen Reset Interuptschleife gefangen und
> kommt nun nicht mehr heraus. Das ist schade.
>
> Gruss Klaus

Nicht jeder hat tagsüber Zeit zu Antworten. Ich bin auch einer der 
Kandidaten, die nur Abends schreiben können, da ich tagsüber einer 
geregelten Arbeit nachgehe.

Drum Äschert Tommy nicht schon ein :)

Mir hat der Thread ein paar gute Erkenntnisse aus dem Programmier-Altag 
gegeben, wie Profis das handhaben.
Danke.

MFG
Stephan

Stephan ,
es war nicht bös gemeint. Nein wirklich nicht .
Ich hatte nur darüber nachgedacht was alles schon gepostet wurde
ohne das Thommy etwas davon hatte.


Thommy hat im Gedanken nämlich vollkommen Recht wenn da nicht die 
"wenns"
und "Abers" wären.

Da ich glaube, es erklären zu können, warte ich auf ihn.

Klaus

Ps.:

du schreibst: "wie Profis das handhaben."

Das gibt es nicht ! Alle kochen mit dem gleichen wasser.

Thomas Eckmann schrieb:
> Abdul K. schrieb:
>> Genauso arbeiten SPS.
> SPS ist keine Programmierung, sondern eine Anwendung, die parametriert
> wird. Ob und wieviel darin an Interrupts ablaufen, weiss der der
> SPS-Anwendungsprogrammierer doch gar nicht. Muß er auch nicht.
> Das wissen nur die Leute, die das SPS-System programmiert haben. Und die
> befinden sich auf der Ebene des Mikrocontrollers.

Genausowenig weißt du über das Mikropogramm einer CPU. Die Ansicht ist 
also schlicht falsch.

Die klassische SPS lädt den momentanen Zustand als Vektor, ändert diesen 
und schreibt ihn dann zum nächsten Timestep wieder komplett als ganzes 
raus. Das geht dann so weiter...


Schönes Beispiel für effiziente und hochzuverlässige Programmierung ist 
was Meinzer sich für die Satelliten der Amateurfunker einfielen ließ. 
Eine Art SPS gekreuzt mit Forth.


> Das Beispiel taugt leider überhaupt nichts. Da hättest du auch mit Excel
> kommen können.

Keine schlechte Idee ansich, auch wenn ich Excel hasse.


> Und deswegen kann man Oldmax nur Recht geben.
> oldmax schrieb:
>> Also, so blöd wie du meinst, sind die
>> Kollegen nun auch nicht. Sorry, aber das musste bei diesem (gefühlt
>> arroganten) Post sein.
>

Und was das soll, das weiß niemand. Mit dem falschen Bein aufgestanden?

Hi tom,

ich hatte mich da mal reingehängt, da ich dachte dass du so ähnliche
Verständnisprobleme hattest wie ich damals mal.

Daher will ich dir gern erklären, was ein INT ist.

Ich fange aber oben and und sage mal dass ein Hauptprogramm mit
DO
LOOP
END
schon ganz toll ist.

Das teil läuft also immer im Kreis und es wird nichts getan.

Das Programm mit:
DO
GOSUB "etwas"
LOOP
END

SUB "etwas"
RETURN

Hier hast du dann ein Unterprogramm eingebaut und es wird immer noch
nichts getan.

Nun gibt es die sogennanten Störungen (Interrupts), die ein
spezielles Ereignis benötigen um ein GOSUB auszuführen.

Wenn ich nun einen Taster hätte und würde schreiben:

DO
IF "Taster gedrückt" dann GOSUB "etwas"
LOOP
END

SUB "etwas"
RETURN

Dann würde also immer noch nichts getan aber der Tastendruck
würde die Verzweigung in das Unterprogramm erzwingen.
Ich wäre dann der Erzwinger der Verzweigung. (der Interrupter ?)

Insofern macht es zunächst mal keinen Unterschied.
Wenn aber nun 2 verschiedene Leuts wie ich einen Taster haben
wird es ein Durcheinander sein.

Für dich macht es keinen Unterschied ob du nun die ganze
Prozedur in die Int-Routine packst oder nicht.
Sobald du z.B. den 2ten Timer benutzen willst geht alles den  Bach 
runter,
weil du nicht mehr weisst, wer wann was drückt.

Für dein Programm macht es jedoch keinen Unterschied wenn du dich
jetzt schon an die Zukunft gewöhnst.


Du machst halt dein Programm so:

DO
If Interrupt = 1 then
"nichts tuen oder doch ?" <- hier kannst du alles Programm reinhauen
Interrupt = 0
end if

LOOP
END

Dein Unterprogramm (Gosub) ist nun ein INT Prog
Also "On Interrupt Gosub xxx"

Im Unterprogramm sagst du dann..
i=1
Return

Ich hoffe, du verstehst dass es bis auf die paar
Extrasprünge für dich keinen Unterschied machen wird,
ob du den einen oder anderen Weg wählst.

Gruss Klaus

Abdul K. schrieb:
> Genausowenig weißt du über das Mikropogramm einer CPU.
Da sei dir man nicht so sicher. Zumal RISC-Prozessoren gar nicht über 
Mikrocode verfügen.

mfg.

Thomas Eckmann schrieb:
> Abdul K. schrieb:
>> Genausowenig weißt du über das Mikropogramm einer CPU.
> Da sei dir man nicht so sicher. Zumal RISC-Prozessoren gar nicht über
> Mikrocode verfügen.
>

Oh ja. Das wußte ich ja noch gar nicht. Vielen Dank Thomas!

Abdul K. schrieb:
> Oh ja. Das wußte ich ja noch gar nicht. Vielen Dank Thomas!
Woher solltest du das auch wissen.

mfg.

Heutzutage sind es auch eher Nanoprogramme.

k.

Es ist natürlich vollkommen klar, Regeln wurden nur erfunden, um den 
Anfängern das Programmieren zu erschweren. Und wenn der Anfänger auf den 
Rat hört, lachen sich die Profis kaputt.

Es macht doch viel mehr Spaß, wenn man alle Programmiersünden und Fehler 
erstmal selber macht. Da hat man doch viel länger Freude daran, bis es 
endlich mal läuft. Und auch ein paar graue Haare und schlaflose Nächte 
mehr.

Auf die Tips von erfahrenen Programmierern hören ja nur Weicheier.

Echte Männer lernen Programmieren auf die harte Tour. Und wenn man dann 
seine früheren Programmierversuche Jahre später nochmal ansieht, möchte 
man am liebsten vor Scham in der Erde versinken.


Peter

Peter Dannegger schrieb:
>
> Echte Männer lernen Programmieren auf die harte Tour. Und wenn man dann
> seine früheren Programmierversuche Jahre später nochmal ansieht, möchte
> man am liebsten vor Scham in der Erde versinken.
>

True story :D

Man kann einfach nur aus Fehlern lernen. Was einem aber wirklich versaut 
ist frühe Assemblerprogrammierung. Vor allem wenn es nur Bitcodes waren, 
z.B. auf einem PET mit BASIC-Poke eingehakt. Danach ist man wirklich 
gezeichnet. Kämpft um jedes Bit und jeden Taktzyklus und versteht die 
Wartezeit auf den Compiler nicht.

Abdul K. schrieb:
> Man kann einfach nur aus Fehlern lernen.
Nein.
Man kann aus Fehlern lernen. Aber nur, wenn man diese auch erkennt. Aber 
nicht, wenn man auf Leute hört, die einem sagen, daß das schon so in 
Ordnung ist.
Aber man kann auch lernen, indem man vorher fragt, wie man es richtig 
macht.

mfg.

m.n. schrieb:
> Aber das WARUM wird einem dabei nicht klar :-)
Was ist denn das für ein Quatsch?
Man muß nur bereit das anzunehmen, was man gesagt bekommt. Auch wenn man 
meint, daß man eine tolle Idee hat. Das ist leider das Problem.

Daß man nicht in eine Kreissäge fassen darf, lernt man auch nicht nur 
dadurch, daß man einmal reingefasst hat.

mfg.

Peter Dannegger schrieb:
>
> Echte Männer lernen Programmieren auf die harte Tour. Und wenn man dann
> seine früheren Programmierversuche Jahre später nochmal ansieht, möchte
> man am liebsten vor Scham in der Erde versinken.
>

Nimms nicht so schwer, als Perfektionist wird man nie zufrieden. Andere 
wären einfach stolz darauf, dass sie sich verbessern konnten. ;)

Du hast schon recht mit den Regeln, die einem die Erfahrung lehrt, aber 
man muss sie selber verstehen und nachvollziehen können. Ich kann das, 
weis aber auch dass ich es irgendwann noch nicht konnte. Es ist doch so, 
dass Erfahrungen nicht ohne Umwege ins "Brain1.0 gemappt" werden können.

Gruß (vor allem an die "PET-Versauten" - hallo Abdul übrigens),
Edson

m.n. schrieb:
> Dann wird man um die wichtigsten Erfahrungen im Leben betrogen.
> Oder anders ausgedrückt: Du sagst und alle anderen machen es dann so?
> So funktioniert das nicht!

Eben  genau das ist es.
Das ist oft das Problem bei Foren mit Spezialisten.
Ich meine nicht speziell dieses Forum, aber man wird als Fragesteller
dann oft um den Weg zur Erkenntnis betrogen.
(Ich lass mal die Leute mit den Schulaufgaben aussen vor).

Es ist fast wie die Bausätze von "woauchimmer"  .
Die kannst du zusammenlöten und es funktioniert einfach nicht.
Diesem problem muss man dann irgendwann mit geballter Erkenntnis
gegenüberstehen und erkennen, dass der Bausatz Müll ist.

Thats the way Love goes (Janet Jackson).

Klaus

m.n. schrieb:
> Dann wird man um die wichtigsten Erfahrungen im Leben betrogen.
Nun komm' mal wieder runter.
Es geht in diesem Thread um Programmierregeln. Und um Erfahrungen, die 
andere schon gemacht  oder in irgendwelchen Büchern gelesen oder in 
einer Vorlesung gehört haben.

> Oder anders ausgedrückt: Du sagst und alle anderen machen es dann so?
Ich schreibe niemandem etwas vor. Mach' doch, was du willst. Ist mir 
doch egal. Aber wenn jemand fragt, bekommt er eine Antwort. Und die 
heisst nicht "Probier' es selber aus". Denn darauf hätte er auch selber 
kommen können. Aber er hat gefragt.  Und dann lass' ich ihn nicht ins 
offene Messer laufen.

Und dementsprechend habe ich dem TO geantwortet.

> So funktioniert das nicht!
Trial and Error ist also die Lösung.

Um mal wieder zum eigentlichen Thema zu kommen:
Ein aktuelles Projekt von mir sieht übrigends so aus:

int main(void)
{
  Initialize();

  while(true)
  {
  }
}

Dazu 2 ISRs.

Eigentlich genau das, was der TO vorhat.
Aber:

Thommy schrieb:
> Thomas (ein unerfahrener Programmierer)

mfg.

Thomas Eckmann schrieb:
> m.n. schrieb:
>> Aber das WARUM wird einem dabei nicht klar :-)
> Was ist denn das für ein Quatsch?
> Man muß nur bereit das anzunehmen, was man gesagt bekommt. Auch wenn man
> meint, daß man eine tolle Idee hat. Das ist leider das Problem.
>
> Daß man nicht in eine Kreissäge fassen darf, lernt man auch nicht nur
> dadurch, daß man einmal reingefasst hat.
>

Du bist ziemlich hochnäsig. Ich wette mal, du weißt nicht wie Menschen 
lernen!
Daß ein Mensch nicht in eine Kreissäge greifen muß, hat er seinen 
Spiegelneuronen zu verdanken. Die sind so etwas wie Brain 2.0 ! Sie 
bieten tatsächlich eine Art Möglichkeit, ohne vorausgehender eigener 
Erfahrung Wissen anderer Menschen zu übernehmen. Alles andere muß jedoch 
gelernt werden. Nämlich all das, was nicht durch Gefühle wahrnehmbar 
ist. Also Faktenwissen! Die Spiegelneuronen funktionieren nur mit 
'Gefühlswissen'.

Für Faktenwissen greift wiederum die Erkenntnis, das man nur aus 
negativen Erlebnissen lernen kann. Es ist ein Irrtum zu glauben, man 
könne sich nicht an einer Herdplatte verbrennen, nur weil sie die 
allermeiste Zeit aus ist! Gefragt ist der Zustand HEISS, dann ist die 
negative Erfahrung rote schmerzende Hand. Danach muß der Herd nicht mehr 
warm sein, damit man trotzdem vorsichtig sein wird.

Bist du vorm Herd alleine, ist es ziemlich schlecht. Steht aber Mama 
dabei und tut so, als würde sie ihre Hand drauftun und macht dazu ein 
schmerzhaftes Gesicht, so kann jedes Kleinkind sofort lernen, das 
Draufgreifen keine gute Idee ist. DAS ist genau der Unterschied, den ich 
beschrieb.

Thomas Eckmann schrieb:
> int main(void)
> {
>   Initialize();
>
>   while(true)
>   {
>   }
> }
>
> Dazu 2 ISRs.
>
> Eigentlich genau das, was der TO vorhat.

Er hat es einfacher, weil er nur 1 Interruptquelle verwendet.

> Aber:
>
> Thommy schrieb:
>> Thomas (ein unerfahrener Programmierer)

Dann ist die einfache Struktur mit der leeren while(1) doch das Richtige 
für ihn.

Gruß,
Edson

Abdul K. schrieb:
> Du bist ziemlich hochnäsig. Ich wette mal, du weißt nicht wie Menschen
> lernen!
Und du bist ziemlich unverschämt.

Und was soll dieser Text? Hast du immer noch nicht geschnallt, daß es 
hier lediglich eine Frage beantwortet wurde, die sich auf Programmierung 
bezog.
Und das hat mit dem Lernen fürs Leben überhaupt nichts zu tun.
Ausserdem habe ich nur in dem Punkt widersprochen, daß man NUR aus 
Fehlern lernen kann.
Woraufhin sich dann einer um seine Erfahrungen betrogen fühlte.
m.n. schrieb:
> Dann wird man um die wichtigsten Erfahrungen im Leben betrogen.
Das hat mit dem Thema doch überhaupt nichts zu tun.

Meister Eder schrieb:
> Dann ist die einfache Struktur mit der leeren while(1) doch das Richtige
> für ihn.
Das funktioniert auch, aber so macht man das einfach nicht.
Das ist eine ziemlich beschissene Art der Programmierung. Das ist 
einfach nur Quick and Dirty, weil im Moment andere Sachen auf der 
Prioritätenliste weiter oben stehen.


mfg.

Thomas Eckmann schrieb:
> so macht man das einfach nicht.
> Das ist eine ziemlich beschissene Art der Programmierung. Das ist
> einfach nur Quick and Dirty

Also ich sehe darin ein Grundgerüst auf dem man aufbauen kann. Nichts 
hindert einen daran, die ISR nach und nach zu entschärfen und mögliche 
Aufgaben in die Hauptschleife zu verlagern.

Man könnte ja auch behaupten, dass

1

int main(void)

2

{

3

    InitSomething();

4

    while(1)

5

    {

6

        DoSomething();

7

    }

8

}

an sich schon schlechter Stil ist. Ich sehe da einen Rückgabewert, der 
nie zurückgegeben wird, weil das Programm in einer Endlosschleife 
hängenbleibt. ;)

Gruß,
Edson

Thomas Eckmann schrieb:
> Abdul K. schrieb:
>> Du bist ziemlich hochnäsig. Ich wette mal, du weißt nicht wie Menschen
>> lernen!
> Und du bist ziemlich unverschämt.
>

Ist bei dir leider notwendig. Was soll man von einem halten, der seine 
'Regeln' der Programmierung als per se allgemeingültig definiert? Gar 
jegliche persönliche Lebenserfahrungen als überflüssig hinstellt, könne 
man doch einfach durch stumpfes Nachäffen allen Widrigkeiten trotzen.


> Und was soll dieser Text? Hast du immer noch nicht geschnallt, daß es
> hier lediglich eine Frage beantwortet wurde, die sich auf Programmierung
> bezog.

Das Thema Programmieren wurde doch beendet. Oder kamen neue Verfahren 
hinzu?
Also war das ein Sub-Thread.


> Und das hat mit dem Lernen fürs Leben überhaupt nichts zu tun.
> Ausserdem habe ich nur in dem Punkt widersprochen, daß man NUR aus
> Fehlern lernen kann.

Diesen Punkt habe ich danach extensiv ausgeführt, erklärt aus der Sicht 
der Wahrnehmungsmechanismen. Die sind bei jedem Menschen gleich.

Indirekt hat das was mit Effizienz beim Programmieren zu tun.


> Woraufhin sich dann einer um seine Erfahrungen betrogen fühlte.

Was ja auch stimmt. Ich erklärte es bereits.


Ich habe keinerlei Lust mehr auf dich einzugehen. Einem fast 50 Jährigen 
brauch keiner mehr vom Leben erzählen. Da habe ich genug hinter mir!

Abdul K. schrieb:
> Ist bei dir leider notwendig.
Aha.

Abdul K. schrieb:
> Ich habe keinerlei Lust mehr auf dich einzugehen. Einem fast 50 Jährigen
> brauch keiner mehr vom Leben erzählen. Da habe ich genug hinter mir!
Jungspund. Aber so wie du dich aufführst, eher Rotznase.

Abdul K. schrieb:
> Was soll man von einem halten, der seine
> 'Regeln' der Programmierung als per se allgemeingültig definiert? Gar
> jegliche persönliche Lebenserfahrungen als überflüssig hinstellt, könne
> man doch einfach durch stumpfes Nachäffen allen Widrigkeiten trotzen.
Wo hast du denn diesen Schwachsinn gelesen? Du hast dcch irgendwas 
genommen.

mfg.

Ihr benehmt euch ja fast so als hättet ihr keine Interuptroutine.

Vielleicht solltet Ihr mal ein SEI in euren Code einfügen.

Ich finde es köstlich aber nun ist doch auch gut .. oder ?

Gruss Klaus

Klaus De lisson schrieb:
> Ich finde es köstlich aber nun ist doch auch gut .. oder ?
Ist es doch auch. Schade, daß man den Leuten nicht gegenübersitzt.

Klaus De lisson schrieb:
> Vielleicht solltet Ihr mal ein SEI in euren Code einfügen.
Aber vielleicht wäre so langsam <Alles Markieren> Ctrl+X angebracht.

mfg.

Thomas Eckmann schrieb:
> Ist es doch auch. Schade, daß man den Leuten nicht gegenübersitzt.

Musst mal vorbeikommen wenn ich ne Bierprobe durchführe.
Am besten du bringst dann dein eigenes SEI gleich mit.

k.

Thommy schrieb:

> Nun dachte ich mir es würde sich ja anbieten quasi das komplette
> Programm in den Interrupt zu verlagern da ja sowieso alle Aktionen im
> Interrupt-Takt ausgeführt werden sollen und ich mir so das Abfragen von
> diversen Flags in der Hauptschleife sparen könnte.

Diese Grundsatzdiskussion hier ist ja der reinste Glaubenskrieg...

Der Ansatz, den Du verfolgst, entspricht einer (sehr einfachen) Variante 
eines Schedulers. Wenn Du sicher bist, dass Du keine wichtigeren 
Interrupts verdrängst (weil der µC diese blockiert, während Deine 
Timer-ISR abgearbeitet wird), ist Dein Ansatz absolut in Ordnung. Meine 
µC-Programme sind ganz ähnlich strukturiert.
Der Vorteil ist, dass Du genau weißt, wie viel Zeit seit dem letzten 
Aufruf der Routine vergangen ist; vor allem bei Regelalgorithmen ist das 
hilfreich. Ich finde es persönlich eleganter. Wenn die Timer-ISR zu 
lange braucht, ist m.E. die Zeit für einen Scheduler wie FreeRTOS 
gekommen.

Es gibt natürlich auch den Ansatz "jedes Programm ist eine große 
Main-Loop". Mich erinnert das immer an Polling und Spaghetti-Code, aber 
das ist sicher subjektiv. Die Diskussion oben klang eher so, als sei das 
die einzig wahre Profi-Lösung.

Meine Einschätzung: Es ist beides möglich, und es gibt keine falsche 
oder richtige Lösung.

Just my 2ct.

Max