- LiFePO4 Speicher Test         
Seite 5 von 5 ErsteErste ... 345
Ergebnis 41 bis 45 von 45

Thema: Der Teensy 4.0 ist fertig

  1. #41
    HaWe
    Gast
    Anzeige

    LiFePo4 Akku selber bauen - Video
    @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).

  2. #42
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.12.2007
    Ort
    weit weg von nahe Bonn
    Alter
    39
    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.

  3. #43
    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.

  4. #44
    Super-Moderator Lebende Robotik Legende Avatar von Manf
    Registriert seit
    30.01.2004
    Ort
    München
    Alter
    71
    Beiträge
    13.048
    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.

  5. #45
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.12.2007
    Ort
    weit weg von nahe Bonn
    Alter
    39
    Beiträge
    3.416
    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.
    Machs dir selbst Herr Dr.

    https://www.roboternetz.de/community...l=1#post654263
    Ich bin gespannt, wie weit du kommst.
    Eine komplizierte Berechnung, welche fast garkeinen Input über Peripherie benötigt auf einem µC zu packen ist ein Layer 8 (erweitertes OSI) Problem.
    Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
    nicht.

Seite 5 von 5 ErsteErste ... 345

Ä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, 12: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, 16:09
  3. AU.ROB No2 ist fertig
    Von arnoa im Forum Vorstellungen+Bilder von fertigen Projekten/Bots
    Antworten: 7
    Letzter Beitrag: 01.01.2012, 19: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, 01:03
  5. Fertig machen oder fertig kaufen ?
    Von iBot im Forum Allgemeines zum Thema Roboter / Modellbau
    Antworten: 11
    Letzter Beitrag: 23.05.2008, 13:25

Berechtigungen

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

LiFePO4 Speicher Test