Hi Achim, jetzt schafft Dein Programm das noch in 1ms rund zu laufen..
Aber sobald Du die aktuelle Spannung anzeigen willst, oder alle Analogwerte auf von den Sensoren ausgibst, ist es offensichtlich vorbei.
Probier' doch mal aus, wie lange es dauert das Display zu löschen, oder eine XBM Grafik auszugeben.

Ich bin gerade dabei mit ohne nibolib zu programmieren, und sitze gerade über "meiner" GFX - Lib:
Ich bekomme Textausgaben mit doppelter und dreifacher Fonthöhe und Fontbreite hin, Kreissegmente und Linien gehen auch schon. Und ich arbeite mit "Double Buffering", d.h. die Ausgaben werden in einen 1024 Byte großen RAM Buffer geschrieben, und wenn die Hauptschleife fertig ist, wird ala E-V-A der Bufferinhalt an Display ausgegeben. Erste Messungen haben ergeben, das Zeichnen eines Kreises mit Radius 20 dauert etwa 8ms, die Ausgabe des Buffers an das Display 1024x3us also etwas über 3ms.
Dann der Timer für die PWM löst alle 1ms einen Interrupt aus, weil ich ihn mit 999 lade und nicht mit 1023, kann ich daraus direkt die Sekunden, Minuten und Stunden ableiten. Die PWM Werte für die LEDs werden in Prozent angegeben, und 1x / Zyklus überprüft und mit 10 multipliziert (auf 999 begrenzt) ausgegeben.
Na ja, und dann kommt noch dazu, dass ich für eine Aufgabe/Funktion mehrere Varianten probiere und schaue was der Compiler daraus macht.
Zahlenwandlung nach ASCII - mit itoa ist es immer 1 Byte kürzer, als ich es hinbringe..und der Compiler optimiert schon recht gut, die Verwendung eines Zeigers anstelle von Array und Index bringt meist auch nichts mehr von der Codegröße, weil das Ergebnis gleich ist.

Aber das ist alles erst der Anfang - Dieter und Egon haben ja auch schon den CoPro programmiert - Der ist dann auch noch eine große Baustelle, und wahrscheinlich nicht ohne (Kollateralschaden).

Danke für Dein Hilfeangebot - eventuell beim Tutorial schreiben..

Hallo Birger
Warum nicht?
Es kommt doch nur darauf an, wie das Programm konstruiert ist. Baue ich von Anfang an Bremsen ein, kommt es nicht weit.
Display löschen, mach ich schon, kein Problem. Auch die Ausgabe von ana Werten habe ich in einem anderen Prg drin, kein Problem.
Sieh dir die grössten Bremsen genau an.
Es ist zu einem, die Darstellung auf dem display jede ms neu geschrieben wird, wozu? Dann das berechnen von ana Werten mit Fliesskomma, geht auch anders.
Baue dein Prg richtig auf, so nimm die Bremsen raus aus der schleife und rufe sie vorher auf. Vermeide Fliesskommarechnung und löse es auf. Die Könner mögen mich korrigieren. Habe es so in Erinnereung, das Nibo die Kommastellen weg bringt und nur mit vollen Stellen arbeitet, kannst du auch machen. Bloss wie macht es C? Solange bis die Zahl voll ist. Dann kannst du noch die Rechnung entschleunigen. Wozu muss ich die Akkuspannung jede ms berechnen ?! Es reicht doch alle 10 oder 50 ms. Dreh den Zähler rum und lasse es nur jede x machen. Auch innerhalb der Zeitschleife kannst du die Sachen machen, aber immer nur 1 mal, Wozu öfters. Bau Sperren ein. Es geht damit.
achim

Hallo achim S.

Hab' mir nun doch mal Deine "Multitasking Programme" angesehen - also für mich haben die Programme 1- 5 und 9 - 10 nix mit "Multitasking" zu tun, sind reine Ablaufsteuerungen, wo am Ende der while-schleife halt 1ms gewartet wird.

Programm 6 - 8 - das ist zwar eine Timersteuerung mit drin, aber "Multitasking" ist doch etwas anders...

Zudem hat BirgerT recht - der größte Zeitfresser ist die Displayausgabe...

Egon

Hallo Egon
einige Prg, besonders das 1 und 2, sind nur dazu da, zu zeigen wie es nicht geht. Danach folgen Prg die zeigen sollen, wie es möglich ist an Beispielen. Es steht jedem frei etwas eigenes zu machen. Entscheidend für mich ist, das man verschiedene Aufgaben in einem engen Zeitrahmen fast gleichzeitig ausführen kann. Ich habe mich während der Entstehung des Artikles mit einigen Leuten geschrieben und Ausgetauscht. Dazu KH Buchegger und Frank Brunner. Diese sind der Meinung, das es multitasking ist. Eine relativ schnelle Begründung habe ich auch dazu bekommen. LED hat eingeschaltet und leuchtet, Prz macht schon wieder was anderes. Windows und andere konnten mit einem Kern auch nichts anderes machen. Der Scheduler hat ihnen nur Zeit zugeteilt, in der sie etwas machen konnten. Da sie einen arbeitsspeicher haben und sehr schnell sind fällt es kaum auf, arbeiten aber fast gleich. Erschlag mich nicht gleich für den vergleich. Scheduler sind heute so komplex, das man die richtige Funktion kaum noch versteht. Mach mal den versuch in den Prg das delay (1) rauszunehmen und lass es laufen. Bei einer Takt von 16 MHz ergeben sich so was von 0,0000625 ms.Lass die Verarbeitung ca. 30 Takte laufen, sind das so um die 0,0019 ms. Sind das ca. 2 us ?? Alles gilt nur, falls ich mich nicht verrechnet habe. Bei dieser Zeit kannst du unheimlich viel anstellen. In der anderen Antwort habe ich ja gesagt, das das Prg entschleunigt werden muss. Ich brauche keine Berechnung des Akku jede ms. Da reichen auch 10 oder sogar 50 ms. Das mit der Graphik kannman auch ändern. Keine Berechnung sondern feststehende werte verwenden. Ich habe noch ein paar Prg mit Berechnung drin, such sie raus. Auch mit Display werde ich was zeigen. Noch was, ein Scheduler legt den Ablauf eines Prg fest, indem er festlegt wer in abhängigkeit der Dringlichkeit oder Notwendigkeit was brauch oder dran ist, dazu müssen die notwendigen Zeiten oder dringlichkeiten bekannt sein. Ist das nicht der Fall, bekommen alle das gleich an Zeit. Damit ist der Scheduler eigentlich auch nur eine Ablaufsteuerung. Ansonsten verweise ich auf den Ori Artikel. Dort steht sowas wie ... das ist Multitasking
achim

Hallo achim S
- tut mir leid, mein Freund, das hat mit Multitasking nix zu tun; die LED bleibt ein, weil der Port als Ausgang definiert ist und high -leg da mal den Prozessor schlafen (mit sleep und den entsprechenden cli() und sei()) und check dann, was die LED macht.

Und die Akku-Spg alle 1ms berechnen und ausgeben - das macht wohl keiner.
- bei Graphikausgaben ist der Proz NUR mit der Ausgabe beschäftigt (lies da mal die Doku der Funktionen).

Egon

Hallo Egon,

schade, dass Du Dir scheinbar nicht parallel das Tutorial von Achim angeschaut hast. In den Beispielen hat Achim Schritt für Schritt Verbesserungen hin zu "quasi-parallelen Prozessen" (also eine Art von Multitasking) beschrieben - als bessere Alternative zu rein sequentieller Programmierung bzw. Programmausführung (wenn im Programm auf Ereignisse reagiert werden soll/muss).

Multitasking ist - im Kern - eine Ablaufsteuerung, oder siehst Du das anders? Ich habe mir mifritschers Diplomarbeit mal angeschaut (Respekt!!) und sicher lange nicht alles (habe es auch nur überflogen ... )verstanden. Ist wirklich toll und andere Ansätze wie RTOS ("Lisbeths.." threat) sind sicher deutlich näher am "richtigen Multitasking" mit "prozesseigenen Umgebungen" etc. Aber - das ist für einige (aktuell auch für mich) auf dem Nibo2 zu hoch gegriffen.

Eine vernünftige Timer-Steuerung (die hat Achim in seinem Tutorial und mit Programmen in guten Ansätzen beschrieben) ist aus meiner Sicht schon der richtige Schritt in Richtung "quasi-paralleler Prozessse". Da gibt es sicher noch viel zu tun und zu optimieren (mifritscher "bastelt" ja bereits kräftig Patches für den Nibobee) - aber es muss auch getan werden. Und da nicht alle über die gleichen Grundlagen wie z.B. mifritscher verfügen ist ein solches Tutorial sicher eine prima Anregung, sich mit dem Thema zu beschäftigen.

Ja, die Display-Steuerung ist der grösste Zeitfresser auf dem Nibo2. Deshalb nutze ich diese z.B. auch nach Möglichkeit überhaupt nicht in "zeitkritischen Anwendungen". Hier wäre z.B. auch mal ein guter und anspruchsvoller Ansatzpunkt: Warum nicht auf ein I2C-gesteuertes Display umstellen? Ein kleiner eigener Prozessor ("Displayprozessor") an das Display angeklinkt (z.B. ATMEGA8) und den das Display parallel ansteuern lassen. Befehle per I2C (ist ja am Erweiterungsport verfügbar) dort hin schicken und den Displayprozessor arbeiten lassen. Da würde gleichzeitig jede Menge gut nutzbarer Ports auf dem Nibo2 frei. Muss sich halt nur jemand dransetzen ...

Beste Grüße
Dieter