- Akku Tests und Balkonkraftwerk Speicher         
Ergebnis 1 bis 10 von 45

Thema: Der Teensy 4.0 ist fertig

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    HaWe
    Gast
    Zitat Zitat von Holomino Beitrag anzeigen
    Ja, dann trau Dich.
    Du musst doch nur den Code kopieren und etwas abändern.
    poste am besten den vollständigen fertigen Code, dann kann ich sehen was man daraus machen kann.

    edit:
    ich sehe in dem Link nur die if-Abfrage in einer main() loop, ohne weitere zusätzliche Funktionsaufrufe (Rechenfunktionen, GPIO r/w, ...).
    Zusätzliche Funktionsaufrufe brauchen aber Rechenzeit, die dann nach if() auf diese weiteren Funktionen verteilt werden kann, bevor die if() Abfrage sich wiederholt.
    Wieviel Gesamt-Rechenzeit haben denn die anderen Funktionen zur Verfügung, zwischen 2 if() in aufeinanderfolgenden main() loops?
    Hier müsstest du ja dann auch fibonacci, GPIO r/w, sort, Blink und die alte 500ms-delay main loop bei dir mit rein kriegen.
    Bei MT müsste dann deine Timerfunktion diese dazwischenliegende Zeit reservieren - ich muss also wissen, wieviel.
    ggf 100us?
    Das könnte ich probieren...



    - - - Aktualisiert - - -

    deine Abfrage in loop() würde ich dann ZUSÄTZLICH zu meinen 5 Threads so formulieren:


    Code:
    volatile static int interruptCounter;
    volatile static int totalInterruptCounter;
     
    hw_timer_t * timer = NULL;
    portMUX_TYPE timerMux = portMUX_INITIALIZER_UNLOCKED;
     
    void IRAM_ATTR onTimer() {
      portENTER_CRITICAL_ISR(&timerMux);
      interruptCounter++;
      portEXIT_CRITICAL_ISR(&timerMux);
     
    }
    
    std::thread *thread_1;
    std::thread *thread_2;
    std::thread *thread_3;
    std::thread *thread_4;
    std::thread *thread_5;
    
    
    // meine threads und Hilfsfunktionen 1-4 wie bisher
    
    
    void timer_loop() {
         
      vTaskPrioritySet(NULL,4);//set Priority
      Serial.println((String)"\ntimer_loop Current priority :" + uxTaskPriorityGet(NULL)+"\n");
    
      while(true) {
     
         if (interruptCounter > 0) {
        
           portENTER_CRITICAL(&timerMux);
           interruptCounter--;
           portEXIT_CRITICAL(&timerMux);
        
           totalInterruptCounter++;
        
           Serial.println( (String)"\nAn interrupt as occurred. Total number: " + totalInterruptCounter +"\n");
        
         }
    
         std::this_thread::sleep_for(std::chrono::microseconds(100));
    
      }
    
    }
    
    void setup() {
       Serial.begin(115200);
       delay(1000);
    
       timer = timerBegin(0, 80, true);
       timerAttachInterrupt(timer, &onTimer, true);
       timerAlarmWrite(timer, 1000000, true);
       timerAlarmEnable(timer);
      
       thread_1 = new std::thread(blinker_loop);
       thread_2 = new std::thread(fibonacci_loop);
       thread_3 = new std::thread(sort_loop);
       thread_4 = new std::thread(GPIO_loop);
       thread_5 = new std::thread(timer_loop);
    
    }
    
    
    void loop() {
       // meine void loop wie bisher
    }
    Ich habe allerdings überhaupt keine Idee, was
    void IRAM_ATTR onTimer() {},
    hw_timer_t * timer = NULL;
    portMUX_TYPE timerMux = portMUX_INITIALIZER_UNLOCKED;
    machen und wie sie funktionieren, genausowenig, was die settings in setup dafür bedeuten - wie gesagt, IRQs habe ich bisher nie benutzt, kann sie also nur 1:1 übernehmen.


    Und wie sähe aber dann DEIN Gesamt-Programm aus, in dem du alle Funktionen (meine 5 threads + deinen Timer) gemeinsam unterbringst? Würdest du das überhaupt schaffen?
    Geändert von HaWe (11.08.2019 um 20:11 Uhr)

  2. #2
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    07.04.2015
    Beiträge
    903
    Oh, oh, da klaffen aber Lücken.

    Nö, ehrlich gesagt ist da meine Hilfsbereitschaft Dir gegenüber gerade etwas runter. Meinetwegen kannste dumm sterben. Erst dreist werden und dann betteln müssen kommt halt nicht gut.
    Geändert von Holomino (12.08.2019 um 06:32 Uhr)

  3. #3
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    18.03.2018
    Beiträge
    2.650
    Ihr scheint nicht wirklich irgendwann mal ein Multitaskingbetriebssystem erstellt und damit dann auch gearbeitet zu haben. Das ist jetzt nicht böse gemeint oder abwertig, aber die Argumente, die hier oft dafür genannt werden, sprechen eigentlich genau dagegen.

    In DEINEM Falle würde ich ZUSÄTZLICH zum MT einen festen Takt per ESP32-timer programmieren: der läuft dann fest per 50kHz (oder was auch immer), und der Rest läuft trotzdem per MT unabhängig, simultan + asynchron. Dies könnte u.U sowohl per IRQ als auch per high-prio-thread geschehen, wäre aber nicht unbedingt zwingend aufs eine oder andere festgelegt.
    Mit Timern alleine aber kriegt man langdauernde Threads per MT + asynchron nicht hin.
    Auf einem Single-CPU-System wird das über Timer gelöst, das ist Standardvorgehen, um dort die verschachtelte Ausführung zu erreichen. Einmal eine Codeumschaltung per Timer zu haben und noch eine oben drauf zu setzen, vernichtet noch mehr Rechenzeit.

    Ein kooperatives Multitasking ist für sehr rechenintensive Aufgaben eher das Mittel der Wahl.

    Programmabarbeitung im Multithreading bringt mit sich dass, ein Programm auf das andere warten muss. Je öfter eine zeitintensive Aufgabe unterbrochen wird, die erst erledigt sein muss, umso länger warten andere Programmteile. Nicht zwingend ist deswegen ein dauerndes Umschalten der Programmcodes sinnvoll, wo dann auch ständig Register gesichert und wieder hergestellt werden müssen. Solches auf Single-CPUs timergesteuertes Programmwechseln kann das Hauptprogramm daher wesentlich verlangsamen. Mit kooperativem Verhalten erreicht man auf Single-CPU-Systemen eigentlich genau das, was benötigt wird. Ein schnelles Abarbeiten der einzelnen Aufgaben nebeneinander, wobei das Ergebnis möglichst schnell zur Verfügung steht.

    Einen Punkt kann man gelten lassen:

    Wenn fest steht dass, dauernd Aufgaben nebeneinander her laufen, die keinen Leerlauf beinhalten. Also beispielsweise 5mal derselbe Programmcode nebeinander ausgeführt wird. Aber dafür ist die sequentielle Abarbeitung besser geeignet, da schneller, weil hier die eingestreuten Taktzyklen fehlen, die für Dinge benötigt werden, die nicht dem Hauptzweck entsprechen.

    Auf jeden Fall sollte man sich damit erst einmal im Detail grundlegend auseinandersetzen bevor man meint, man könnte auf etwas nicht verzichten. Sonst bleibt nur, die Nachteile mit noch mehr MHz zu erschlagen.



    MfG
    Geändert von Moppi (12.08.2019 um 06:54 Uhr)

  4. #4
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    13.01.2014
    Beiträge
    454
    Blog-Einträge
    3
    Zitat Zitat von Moppi Beitrag anzeigen
    Ihr scheint nicht wirklich irgendwann mal ein Multitaskingbetriebssystem erstellt und damit dann auch gearbeitet zu haben. Das ist jetzt nicht böse gemeint oder abwertig, aber die Argumente, die hier oft dafür genannt werden, sprechen eigentlich genau dagegen.
    ...
    Auf jeden Fall sollte man sich damit erst einmal im Detail grundlegend auseinandersetzen bevor man meint, man könnte auf etwas nicht verzichten. Sonst bleibt nur, die Nachteile mit noch mehr MHz zu erschlagen.
    Zwei Semester Betriebssysteme und ein Semester Echtzeitsysteme reichen nicht? Du vermutest hier ziemlich ins Blaue.

    Und was meinst du mit Hauptprogramm? Auf dem Esp32 'endet' die main() im Scheduler, loop() ist nur eine Task.

    [Im Folgenden beziehen sich die Aussagen Multitasking betreffend auf FreeRTOS]
    Der einzige Nachteil der Nutzung eines präemptiven Multitaskings, den ich sehe, ist, dass auch wenn nur eine Task mit der gerade höchsten aktiven Priorität läuft, sie trotzdem im Scheduler-Takt unterbrochen wird, um zu sehen, ob eine andere Task dran ist. Wenn einem diese kleine Unterbrechung nicht passt, kann man den Scheduler suspenden oder einen kritischen Bereich definieren.
    Wenn ich Nebenläufigkeit mit Zeitscheiben will, gebe ich den entprechenden Tasks eine gleiche Priorität, sonst nicht.

    Und ich behaupte nicht, nicht auf etwas verzichten zu KÖNNEN, sondern zu WOLLEN. Es ist am Ende eine Frage des Entwicklungszeit. Ich will das Rad nicht jedesmal neu erfinden. Oder mein Design umstellen, wenn ich merke, dass ich Nebenläufigkeit mit Zeitscheiben brauche. Ich will eine API, die ich kenne, und deren Funktionalität getestet und dokumentiert ist.

    Wie gesagt: Wenn ich das Multitasking nicht brauche, oder es stört, schalte ich sie aus.

    Und das Vorhandensein / die Nützlichkeit von Queues, Semaphoren, Software-Timern, Gruppenevents etc. in diesem Kontext habe ich noch nicht einmal erwähnt... Alles Dinge, die man für gutes Design von System mit Nebenläufigkeit braucht.
    Geändert von Sisor (12.08.2019 um 08:27 Uhr)

  5. #5
    HaWe
    Gast
    @Ceos:du kannst auch nur immer dieselben hohlen und bornierten Statements wiederholen - ich war nicht derjenige, der hier von vornherein beleidigend war - das war eindeutig Holomino.
    Mein Statement war lediglich: für MICH ist preemptives MT unverzichtbar.

    Zitat Zitat von Sisor
    Wie gesagt: Wenn ich das Multitasking nicht brauche, oder es stört, schalte ich sie aus.
    genau so sehe ich es auch.
    Viele meiner Programme laufen im single-task mode.
    Aber von einer leistungsfähigen cpu erwarte ich, dass sie AUCH eine API für preemptives MT bietet, und "leistungsfähig" beginnt für mich bei ARM Cortex (M0/M3, spätestens M4).

  6. #6
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.12.2007
    Ort
    weit weg von nahe Bonn
    Alter
    40
    Beiträge
    3.416
    Den Ansatz Threads zu nutzen ist Verschwendung von Controller Peripherie, da kann man auch einen ARM ohne großartig Peripehrie mit hoher Taktzahl nehmen.

    Eine Aufgabe für die man einen 100Mhz+ ARM braucht weil man mit Threads arbeitet um Peripherie damit zu emulieren kann man auch auf einem 32Mhz µC erledigen.

    Eine komplizierte Berechnung, welche fast garkeinen Input über Peripherie benötigt auf einem µC zu packen ist ein Layer 8 (erweitertes OSI) Problem.

    Die Darstellung von Inhalt auf einem Display und die gleichzeitige Berechnung von komplizierten Parallelen Aufgaben teilt man dann einfach am besten auf, ein 100+MHZ ARM mit Threads der einen ATTiny oder Mega oder XMega mit grafischen Befehlen versorgt der dann seine ganze reiche Peripherie dafür aufbringt und die begrenzte Rechenzeit der CPU zum organisieren und kommunizieren nutzt.

    die Eier legende Wollmilchsau ist der dritte Weg, aber nur wenn man beide Parts nutzen kann auch wirklich Sinnvoll. Das war zumindest der Kern meiner Aussagen.

    by the way
    ich sehe schon, ihr versteht teilw (?) nicht den Sinn und die Vorteile von preemptivem MT.
    war der Punkt an dem du deine Lösung mal wieder über die Lösung anderer gestellt hast was der Kern meines letzen Post war ...

    daraufhin habe ich deiner listenartigen typischen Ansprüche genüge getan und erklärt wie ich in meinem Fall damit umgehe und selber behauptet dass meine Lösung besser als deine ist (das war anmaßend, gebe ich zu, aber deine Art triggert mich immer so)

    Abschließend hatte ikch argumentiert dass es eine Frage der Problemstellung ist und jede Art ihre Vor- und Nachteile hat
    aber dich interssierte auch nach der Argumentation anderer nur dass deine Lösung überlegen wäre indem du Situationen kontruierst die es nur bei dir gibt. Ich muss keinen "hängenden Thread preemtiv verlassen" (wobei das mit der Timer Lösung eigentlich sehr eindeutig regelbar ist) weil es bei mir keine hängenden Prozesse gibt! Eine ordentlich geschriebene Statemachine ist DETERMINISTISCH, d.h. zu jedem Zeitpunkt stabil udn man weis immer wo man sich befindet und es gibt keine unerwarteten Situationen.

    Alles unerwartete ist ein Programmierfehler oder schlechtes Desgin. Wenn man per Design erwartet dass etwas unerwartetes passieren kann, muss man eben CPU Zeit und Deterministisches Verhalten opfern und Threads nutzen.
    Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
    nicht.

  7. #7
    HaWe
    Gast
    Zitat Zitat von Ceos Beitrag anzeigen
    Den Ansatz Threads zu nutzen ist Verschwendung von Controller Peripherie, da kann man auch einen ARM ohne großartig Peripehrie mit hoher Taktzahl nehmen.

    Eine Aufgabe für die man einen 100Mhz+ ARM braucht weil man mit Threads arbeitet um Peripherie damit zu emulieren kann man auch auf einem 32Mhz µC erledigen.

    Eine komplizierte Berechnung, welche fast garkeinen Input über Peripherie benötigt auf einem µC zu packen ist ein Layer 8 (erweitertes OSI) Problem.

    Die Darstellung von Inhalt auf einem Display und die gleichzeitige Berechnung von komplizierten Parallelen Aufgaben teilt man dann einfach am besten auf, ein 100+MHZ ARM mit Threads der einen ATTiny oder Mega oder XMega mit grafischen Befehlen versorgt der dann seine ganze reiche Peripherie dafür aufbringt und die begrenzte Rechenzeit der CPU zum organisieren und kommunizieren nutzt.

    die Eier legende Wollmilchsau ist der dritte Weg, aber nur wenn man beide Parts nutzen kann auch wirklich Sinnvoll. Das war zumindest der Kern meiner Aussagen.

    by the way

    war der Punkt an dem du deine Lösung mal wieder über die Lösung anderer gestellt hast was der Kern meines letzen Post war ...

    daraufhin habe ich deiner listenartigen typischen Ansprüche genüge getan und erklärt wie ich in meinem Fall damit umgehe und selber behauptet dass meine Lösung besser als deine ist (das war anmaßend, gebe ich zu, aber deine Art triggert mich immer so)

    Abschließend hatte ikch argumentiert dass es eine Frage der Problemstellung ist und jede Art ihre Vor- und Nachteile hat
    aber dich interssierte auch nach der Argumentation anderer nur dass deine Lösung überlegen wäre indem du Situationen kontruierst die es nur bei dir gibt. Ich muss keinen "hängenden Thread preemtiv verlassen" (wobei das mit der Timer Lösung eigentlich sehr eindeutig regelbar ist) weil es bei mir keine hängenden Prozesse gibt! Eine ordentlich geschriebene Statemachine ist DETERMINISTISCH, d.h. zu jedem Zeitpunkt stabil udn man weis immer wo man sich befindet und es gibt keine unerwarteten Situationen.

    Alles unerwartete ist ein Programmierfehler oder schlechtes Desgin. Wenn man per Design erwartet dass etwas unerwartetes passieren kann, muss man eben CPU Zeit und Deterministisches Verhalten opfern und Threads nutzen.
    Wieder nur hohles Gerede, ohne Nachweis durch Code und Fakten.
    mach doch einfach mal mein Programmbeispiel (eine Simulation), das ich oben gepostet habe, mit deinen Methoden nach.
    https://www.roboternetz.de/community...l=1#post654263
    Ich bin gespannt, wie weit du kommst.

    Statemachines aber sind das unterste Ende von Programmiersprachen-Grammatiken, für simpeltste Anwendungen. Wenn dir das reicht, ok, dann brauchst du keine höheren Grammatiken und/oder Architekturen.

  8. #8
    Super-Moderator Lebende Robotik Legende Avatar von Manf
    Registriert seit
    30.01.2004
    Ort
    München
    Alter
    72
    Beiträge
    13.139
    Ich habe schon mitgelesen und viele interessante technische Aspekte gesehen.

    Eigentlich ist es Energieverschwendung sich von anderen abheben zu wollen wenn man sich gleichzeitig mit ihnen austauschen möchte. Das ist wohl der interessante nichttechnische Aspekt an der Diskussion.
    Ich überlege, dass wenn ich über die Situation und die Beteiligten urteilen will, dann kann ich mich das nächste man nicht unbefangen an anderen Diskussion beteiligen.

    Deshalb sollten wir diese Diskussion zum Thema "Der Teensy 4.0 ist fertig" auch erst einmal abschließen.

    Vielleicht kann man ja bei Gelegenheit noch mehr praktische Einsatzmöglichkeiten für das System ansprechen.

  9. #9
    HaWe
    Gast
    @Moppi:
    du hast auch echt nicht verstanden, worum es eigentlich geht. Lies noch mal oben alles genau nach und versuche mal selber mit einem "hängenden Thread" bei einem kooperativen MT Programm heraus zu kommen. Was du schreibst, entbehrt wirklich jeglicher Grundlage.
    Ich arbeite seit 20 Jahren mit Multithreading-Programmen auf single- und multicore-cpus, auch mit kooperativen, danach aber überwiegend mit preemptiven und selbstverständlcih inzwischen auch mit Linux (multiuser-mulititasking OS). ich glaube, DU hast keine Ahnung von Multithreading-Programmierung, insbesondere nicht mit preemptiver.


    Holomino aber schießt mal wieder den Vogel ab:
    Zitat Zitat von Holomino Beitrag anzeigen
    Oh, oh, da klaffen aber Lücken.
    Nö, ehrlich gesagt ist da meine Hilfsbereitschaft Dir gegenüber gerade etwas runter. Meinetwegen kannste dumm sterben. Erst dreist werden und dann betteln müssen kommt halt nicht gut.
    Holomino, du bist doch echt ein A******ch - da kommt nun doch wieder deine bekannte beleidigende Trollnatur zum Vorschein.
    Ich habe nicht vor, dir deine Programme zu schreiben, ich hatte um nichts "gebettelt" und ich hatte nicht vor, dich um irgendeine "Hilfsbereitschaft" zu bitten
    DU warst es, der wollte, dass ich deinen Code in meinen integriere - ich hatte lediglich deinen von dir verlinkten Code portiert und in mein voriges MT-Programm integriert, um zu zeigen dass es grundsätzlich geht.
    Bei mir selber für meine Zwecke stehen keine Timer zur Debatte, sondern nur teilweise landauernde, asynchron parallel laufende Threads mit unterschiedlicher Priorität, das hatte ich bereits vorher eindeutig klargestellt.

    Du warst es andererseits, der behauptet hatte, er käme ganz ohne MT für das gesamte Programm aus - nur zeigen hast du es nicht können, hast wohl den Mund gehörig zu voll genommen.
    Geändert von HaWe (12.08.2019 um 08:30 Uhr) Grund: typo

  10. #10
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.12.2007
    Ort
    weit weg von nahe Bonn
    Alter
    40
    Beiträge
    3.416
    deine bekannte beleidigende Trollnatur zum Vorschein
    Du merkst nicht wie undankbar deine art zu schreiben ist ... jemand macht die einen Vorschlag für einen alternativen Weg und von dir kommt A) eine Abwertende Bemerkung dass deine Lösung soweiso besser ist oder B) sofort die Frage nach compile fertigem Code ... wenn das nicht Trollig ist, ist es mindestens Uneinsichtig

    Du provozierst mit deiner Art solche Reaktionen und bist dir dessen scheinbar noch nicht mal bewusst. Aber du nutzt die Reaktion um deinen Standpunkt zu verteidigen.

    Skank Hunt (Southpark) wäre echt stolz auf dich. Das wäre genau seine Methode, Leute mit abwertenden Komentaren in eine explodierende Diskussion locken und dann mit dem Finger auf sie zeigen.
    Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
    nicht.

Ähnliche Themen

  1. STM32 contra ARM Cortex M3 (Arduino Due, Teensy): Performance per Arduino vs. nativ C
    Von HaWe im Forum ARM - 32-bit-Mikrocontroller-Architektur
    Antworten: 14
    Letzter Beitrag: 22.11.2017, 11:53
  2. Platinenlayout Problem mit Platinenlayout - Adapterplatine für den Teensy 3.1
    Von robonooby im Forum Konstruktion/CAD/3D-Druck/Sketchup und Platinenlayout Eagle & Fritzing u.a.
    Antworten: 9
    Letzter Beitrag: 29.06.2014, 15:09
  3. AU.ROB No2 ist fertig
    Von arnoa im Forum Vorstellungen+Bilder von fertigen Projekten/Bots
    Antworten: 7
    Letzter Beitrag: 01.01.2012, 18:35
  4. Hexapod aus Alu [fertig]
    Von yaro im Forum Vorstellung+Bilder+Ideen zu geplanten eigenen Projekten/Bots
    Antworten: 20
    Letzter Beitrag: 15.07.2010, 00:03
  5. Fertig machen oder fertig kaufen ?
    Von iBot im Forum Allgemeines zum Thema Roboter / Modellbau
    Antworten: 11
    Letzter Beitrag: 23.05.2008, 12:25

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

Solar Speicher und Akkus Tests