1. Foren
  2. Kommentare
  3. Sonstiges-Forum
  4. Alle Kommentare zum Artikel
  5. › Ryzen-Generationen im Test…
  6. Thema

aber ARM ist der der zuletzt lacht

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema


  1. Re: aber ARM ist der der zuletzt lacht

    Autor: schnedan 17.12.20 - 21:36

    Für die Ansteuerung von BDLC brauchst mehr wie eine PWM, das sind nomalerweise spezielle Peripherien die mehrere PWM synchron! erzeugen können, die bereits die Totzeit in HW garantieren und die meist gekoppelt sind mit Capture/Compare Einheiten...

    das was der PI hat genügt zur Ausgabe von Audio auf einem Speaker oder zur Ansteuerung eines Vibrationsmotors...
    der PI hat einen Handy-SOC, das ist kein µC für Regelungstechnische Aufgaben...
    "...Software PWM, wobei ganz komische Dinge bei raus kommen. " Joa, sowas kenn ich, wir hatten auch mal einen Studenten der das in SW gemacht hat statt die HW Einheiten zu nutzen... Der Motor wurde etwas wärmer als normal

    Na ja, man kann mit dem PI viel machen und vieles kreativ missbrauchen, aber es gibt 30MHz µC die Regelungstechnisch mehr können.

  2. Re: aber ARM ist der der zuletzt lacht

    Autor: Trollversteher 18.12.20 - 07:53

    Multitasking darf es schon schon geben, aber in der Regel dann preemptives Multitasking und kein Kooperatives:

    https://www.razorrobotics.com/multitasking-real-time-operating-systems/#:~:text=In%20a%20multitasking%20RTOS%20the,achieving%20its%20real%2Dtime%20requirements.&text=In%20this%20type%20of%20multitasking,allowing%20another%20task%20to%20run.

  3. Re: aber ARM ist der der zuletzt lacht

    Autor: Ach 18.12.20 - 10:18

    schnedan schrieb:
    --------------------------------------------------------------------------------

    > Für die Ansteuerung von BDLC brauchst mehr wie eine PWM, das sind nomalerweise
    > spezielle Peripherien die mehrere PWM synchron! erzeugen können, die bereits die Totzeit
    > in HW garantieren und die meist gekoppelt sind mit Capture/Compare Einheiten.

    PVM genügt, wenn man mit der PI einen BLDC Treiberbaustein ansprichst, der wiederum den Motor steuert. Um dagegen direkt die Phasen Signale für einen BLDC Motors zu erzeugen, also um quasi den Motor Treiber zu imitieren, benötigt man eher einen Arduino o.ä.

    > Na ja, man kann mit dem PI viel machen und vieles kreativ missbrauchen, aber es gibt
    > 30MHz µC die Regelungstechnisch mehr können.

    Das reizvolle an der PI ist ihrer Fähigkeit mit hochfrequenten Signalen umzugehen, insbesondere als Smartphone CPU. Das gekoppelt mit einer relativ hohen Rechenleistung plus ihrer Unterstützung grafischer Interfaces machen sie interessant für jede Menge Bastellaufgaben.

    Was Realtime OS angeht, verstehe ich die Sorgen nicht so ganz. Ein kurzer Blick in die Wiki fördert gleich mal eine ganze Liste verschiedener RT Systeme hervor. Die vier wichtigsten Linux RT Ableger sind : RTLinux, RTAI, LibeRTOS und Xenomai.

  4. Re: aber ARM ist der der zuletzt lacht

    Autor: Trollversteher 18.12.20 - 10:23

    >Apple hat zuerst ARM gebaut und dann weiterentwickelt da werden Einheiten verdoppelt, Pfade verbreitert und sicher haben sie auch Teile neu nur sowas macht man in 5 Jahren nicht komplett neu.

    Sie haben zuerst

    >Da hätte man dann eher auf ARM komplett verzichtet, wie gesagt die müssen zu nichts kompatibel sein. Grad im Desktopbereich bräuchten sie keine ARM Kompatibilität, da es da keine VorCPUs gab.

    *Natürlich* mussten sie kompatibel sein, weil iOS und *sämtliche* Apps auf den alten ARM SoCs *vor* dem Beginn der Eigenentwicklung basierten, mein Gott, ist denn das wirklich so schwer zu verstehen? Das war ein *evolutionärer* Prozess, der mit einem ARM Referenzdesign begonnen hat, und sich dann Schritt für Schritt bis hin zur Entwicklung *komplett eigener* Kerne entwickelt hat. Und natürlich gibt es da nach wie vor Ähnlichkeiten zum Original Design, das liegt nun mal in der Natur der Sache, nur ist Apple eben jetzt *nicht* mehr auf das Referenzdesign angewiesen, und daher auch nicht von einem "Monopol" abhängig, wie von Dir im Ausgangskommentar unterstellt.

    >Bei den sogenannten "Analysen des inneren Aufbaus" darf man sich nicht so vorstellen das da der genaue Aufbau der einzelnen Gatter erkannt wird. Da kommt nicht der genaue Bauplan raus. Es sieht nicht 1:1 wie ARM aus dem Katalog aus, ok.

    Richtig. Und es sieht vor allem nicht 1:1 nach dem *aktuellen* ARM aus dem Katalog aus, weil Apple die Entwicklung der Kerne ab einem bestimmten Zeitpunkt auf eine *eigene* Plattform gehoben hat und nun nicht mehr von ARMs Referenz-Designs abhängig ist.

    >Man kann allerdings auch davon ausgehen, grad weil sie viel von ARM verwenden kaufen sie lieber die VollLizenz und sind damit frei von irgendwelchen nachträglichen Lizenzproblemen.

    Sie *haben* aber nicht die "Volllizenz" gekauft, sondern operieren auf Basis der Arcvhitektur Lizenz - siehe zB hier:

    https://www.macwelt.de/international/Was-die-ARM-Uebernahme-durch-Nvidia-fuer-Apple-bedeutet-10883006.html

    "Man kann auch den ARM-Code lizenzieren und eine kompatible CPU von Grund auf neu entwerfen. Apple macht das schon seit Jahren; der A6-Prozessor im iPhone 5 war der erste mit einer von Apple entworfenen CPU, und seitdem ist das Unternehmen nie wieder zu lizenzierten CPU-Designs zurückgekehrt."

    >Du hattest geschrieben das Apple nicht alles neu machen wollte. Dieses dein Argument habe ich auf die Architektur angewandt. An der Stelle müssen wir eh spekulieren.

    Apple hat ganz einfach kompatibel zu den ersten Generationen von iPhones bleiben wollen, und sie haben, statt 10 Jahre lang "im Kämmerlein" einen völlig neuen Prozessor aus dem Stand zu entwickeln, sich für einen evolutionären Weg entschieden, also mit dem ARM referenz Design zu beginnen, und sich mit jeder neuen Generation davon weg zu entwickeln.

    >er ist überlegen
    >der neueste Qualcom ist aber auch nicht langsam
    >würde sagen im Prinzip eine Generation später
    >also 1-2 jahre

    Was im schnelllebigen Mobile SoC Geschäft eine Ewihglkeit ist - und Qualcomm kommt ja nicht mal an Apples Smartphone SoCs heran, einen vollwertigen Desktop/Notebook Prozessor wie den M1 müssen die erst überhaupt mal entwickeln.



    1 mal bearbeitet, zuletzt am 18.12.20 10:24 durch Trollversteher.

  5. Re: aber ARM ist der der zuletzt lacht

    Autor: wurstdings 18.12.20 - 10:26

    Ach schrieb:
    --------------------------------------------------------------------------------
    > Das kann man so nicht behaupten, dass entsprechende Voraussetzungen nicht
    > von ARM Chips erfüllt werden könnten.
    Oh doch, wie garantierst du die Echtzeit, wenn jeder Zeit ein Interupt dein Programm unterbrechen kann?
    > Schon eine ganz normale PI verfügt
    > über GPIO Schnittstellen
    Und was hat das mit Echtzeit zu tun? Es gibt auch ATOM-Boards mit GPIO, sind die deshalb echtzeit fähig?
    > Distributionen auch definitiv in Echtzeit ansprechen.
    Definitiv nicht.
    > Hochfrequenzsteuerung ist eine Anwendung, Sounderzeugung
    > mit komplexesten Algorithmen ist ein andere. Oder Mehrspuraufnahmen. Da
    > kommt es nicht selten auf 1/1000 sec. an, und da arbeiten ARM Systeme
    > definitiv zuverlässiger.
    Kannst du diese Geschichten auch belegen (Link)? In der Realität sind so ziemlich alle Digital Audio Workstation x86 basiert.
    > Selbiges bei der Navigation von Autos.
    Dort wird ARM genutzt, weil man es einfacher (bzw überhaupt) mit den eigenen IP-Blöcken kombinieren kann.

    Trollversteher schrieb:
    --------------------------------------------------------------------------------
    > Multitasking darf es schon schon geben, aber in der Regel dann preemptives
    > Multitasking und kein Kooperatives:
    Das ist aber weiches RT und das geht auch mit jeder beliebigen x86 CPU.

    Reden wir eigentlich von weicher oder von harter Echtzeit? Ersteres kann jede CPU mit einem entsprechenden Betriebsystem (Linux + RT Kernel) letzteres können nur spezielle CPUs (µC) meist ohne Betriebsystem.

    Was soll denn der Unterschied zwischen x86 und ARM sein, weswegen das Eine kein RT kann? Und bitte nicht solche Lächerlichkeiten wie GPIO bringen.

  6. Re: aber ARM ist der der zuletzt lacht

    Autor: Ach 18.12.20 - 14:11

    wurstdings schrieb:
    --------------------------------------------------------------------------------

    > Oh doch, wie garantierst du die Echtzeit, wenn jeder Zeit ein Interupt dein Programm
    > unterbrechen kann?

    Eine RT Anwendung kann nur in einer kooperativen Multitaskingumgebung unbeabsichtigt unterbrochen werden, aber eben nicht in einer preemptiven Umgebung, in welcher besagte RT Anwendung die höchste Priorität genießt.

    > Und was hat das mit Echtzeit zu tun? Es gibt auch ATOM-Boards mit GPIO,
    > sind die deshalb echtzeit fähig?

    Mann sollte in einer Unterhaltung die Freundlichkeit bewahren, nicht die wesentlichen Punkte fremder Aussage unter den Teppich zu kehren. Die Aussage lautete ja nicht : "Schon eine ganz normale PI verfügt über GPIO Schnittstellen", vielmehr lautete sie : "Schon eine ganz normale PI verfügt über GPIO Schnittstellen, die direkt mit dem Zeitgeber der CPU gekoppelt sind",

    sprich : eine Hardware PWM. Bietet der von dir vorgeschlagene x86 Computer auch in dieser Form angebunden GPIO Ports? Das würde ich jedenfalls mal nachprüfen, denn ohne sieht es ziemlich schlecht aus mit die RT Fähigkeit. Bei einem PC sucht man solche Schnittstellen jedenfalls vergebens.

    > Kannst du diese Geschichten auch belegen (Link)? In der Realität sind so ziemlich
    > alle Digital Audio Workstation x86 basiert

    Oh je, dass war so eine umfassende und zeitintensive Recherche, ich weiß nicht wie ich die nochmal zusammen bekommen sollte. Ich erinnere mich noch an bestimmte Phyton Audiobibliotheken für die PI, die sehr geschickt deren Hardware ansprechen und mit denen man die komplexesten Soundoperationen durchführen kann. Zudem habe habe ich nie behauptet, dass ein Großteil produktiver Audioanwendungen auf ARM laufen würden, nur dass die Aufnahme- und Wiedergabeverzögerung immer wieder zum Thema auf dem PC werden, und das ARM Systeme genau hier mit ihrer RT Stärke punkten können. Davon abgesehen findet man Mehrspuraufnahmegeräte, Sampler und Soundgeneratoren auf Microcontrollerbasis. Da müsstest du dich mal über die "Teensy" Controlern informieren, die in diesem Bereich einen Schwerpunkt haben, aber das Thema ist dann wieder unabhängig von der ARM vs. X86 Diskussion.

    > Das ist aber weiches RT und das geht auch mit jeder beliebigen x86 CPU.

    Zwischen "weichem" und hartem" RT zu unterscheiden ist wie zwischen "ein bisschen" und "richtig" schwanger zu trennen, also Quatsch. Entweder kann man zu einem vorhergesagtem Zeitpunkt ein bestimmtes Ereignis garantieren oder man kann es nicht, dazwischen existiert nichts, egal mit welcher Hardware oder mit welchem OS.

  7. Re: aber ARM ist der der zuletzt lacht

    Autor: wurstdings 18.12.20 - 16:18

    Ach schrieb:
    --------------------------------------------------------------------------------
    > Eine RT Anwendung kann nur in einer kooperativen Multitaskingumgebung
    > unbeabsichtigt unterbrochen werden
    Schau dir doch mal an, was ein Interrupt ist und wie der funktioniert. Multitasking ist nochmal was völlig anderes.

    Aus Wikipedia:
    > Ein präemptives Verfahren dagegen kann dem Prozess Ressourcen bereits vor der Fertigstellung wieder entziehen, um sie zwischenzeitlich anderen Prozessen zuzuteilen. Der Prozess wird dabei in seiner Ausführung unterbrochen (er geht in den Zustand ‚bereit‘ über) und verharrt dort, bis ihm durch den Scheduler erneut Ressourcen zugeteilt werden.

    Das bedeutet auch, wenn zwischendurch nen Prozess eine Resource blockiert, hat auch der "Echtzeitprozess" keinen Zugriff darauf bis diese vom Originalprozess wieder freigegeben wurde.

    Genauso wenn durch Vollauslastung oder Überhitzung die CPU herunter taktet und dadurch weniger Leistung und längere Reaktionszeiten hat.
    > aber eben nicht in einer preemptiven
    > Umgebung, in welcher besagte RT Anwendung die höchste Priorität genießt.
    höchste Priorität hilft weder gegen Interrupts, noch blockierte Resourcen, noch gegen Taktschwankungen.
    > > Und was hat das mit Echtzeit zu tun? Es gibt auch ATOM-Boards mit GPIO,
    > > sind die deshalb echtzeit fähig?
    >
    > Mann sollte in einer Unterhaltung die Freundlichkeit bewahren, nicht die
    > wesentlichen Punkte fremder Aussage unter den Teppich zu kehren. Die
    > Aussage lautete ja nicht : "Schon eine ganz normale PI verfügt über GPIO
    > Schnittstellen", vielmehr lautete sie : "Schon eine ganz normale PI verfügt
    > über GPIO Schnittstellen, die direkt mit dem Zeitgeber der CPU gekoppelt
    > sind",
    Und was ist daran besonders? Bei nem x86-Board ist auch alles an den Taktgenerator vom Board gekoppelt, macht ja anders keinen Sinn?
    > sprich : eine Hardware PWM.
    Warum sollte x86 mit HardwarePWM nicht klar kommen? Schonmal von PWM-Lüftern gehört? Sind seit grob 20 Jahren Standard auf x86-Boards.
    > Bietet der von dir vorgeschlagene x86 Computer
    > auch in dieser Form angebunden GPIO Ports?
    Da ich nicht genau verstehe, was du für eine Besonderheit bei der GPIO Anbindung implizierst, schau einfach selbst, z.B. hier https://www.golem.de/news/intel-edison-ausprobiert-ich-seh-dich-das-mona-lisa-projekt-1411-110577.html oder mal Atomic Pi googeln.
    > Bei einem PC sucht man solche Schnittstellen jedenfalls vergebens.
    Ohne zu googeln gehe ich jede Wette ein, das es dafür PCI oder USB Erweiterungskarten gibt.
    > Zudem habe habe ich nie behauptet, dass ein Großteil
    > produktiver Audioanwendungen auf ARM laufen würden
    Das hast du impliziert, indem du behauptet hast, dass x86 kein RT kann (DAW ohne weiches RT wäre nicht möglich) und ARM dagegen schon und das Zitat:
    > Prinzipbedingt verbleibt X86 unbenutzbar für hochgradig zeitkritische Anwendungen wie Zünd-, Motorsteuerungen, und auch bei nicht ganz so kritischen Tasks wie Softwareinstrumenten und Musikaufnahmen spielen die Risc-basierten Platformen ihre Überlegenheit aus.
    Wenn ARM bei Echtzeit so dermaßen überlegen wäre, wie du behauptest, sollten dann nicht die meisten High-End Audioworkstations auf ARM basieren? 2 Sekunden Google und du hättest 1000 Beispiele für ARM-DAWs.
    > Davon abgesehen
    > findet man Mehrspuraufnahmegeräte, Sampler und Soundgeneratoren auf
    > Microcontrollerbasis.
    ... unterstützt von DSPs die ganz neben bei meist (hart) echtzeitfähig sind und die Hauptaufgaben übernehmen.
    > Zwischen "weichem" und hartem" RT zu unterscheiden ist wie zwischen "ein
    > bisschen" und "richtig" schwanger zu trennen
    Sehe ich ähnlich, zumindest die Bezeichnung RT ist dafür verwirrend.
    > also Quatsch.
    Nein ganz sicher nicht, denn darauf (weiches RT) basieren Computerspiele, DAWs, Audio/Video-Wiedergabe, Videotelefonie, ...
    > Entweder kann
    > man zu einem vorhergesagtem Zeitpunkt ein bestimmtes Ereignis garantieren
    > oder man kann es nicht, dazwischen existiert nichts, egal mit welcher
    > Hardware oder mit welchem OS.
    Oha, und du behauptest also, ARM könnte hartes RT. Irgend nen Beispiel dazu? Bisher hast du ja nur weiche RT Beispiele gegeben.

    Vorhin hattest du auch noch von Linux und RT gesprochen, das ist ja auch nur weiches RT, entscheide dich doch mal.

    Vor allem wäre mal interessant was an nem Motor so eine hohe Genauigkeit für den Zündzeitpunkt benötigt. High-End Motoren drehen mit knapp 20000 U/m -> 333 U/s ein lahmer Atom oder ARM mit 1GHz -> 1000000000 Takte/s kann da jegliche Anforderungen mit weichem RT im Schlaf erledigen.

  8. Re: aber ARM ist der der zuletzt lacht

    Autor: Ach 18.12.20 - 20:16

    wurstdings schrieb:
    --------------------------------------------------------------------------------

    > Das bedeutet auch, wenn zwischendurch nen Prozess eine Resource blockiert, hat auch der "Echtzeitprozess" keinen Zugriff darauf bis diese vom Originalprozess wieder freigegeben wurde.

    Du solltest deine Zitate besser durchdenken bevor du sie interpretierst. Das Wikizitat sagt also aus : "Ein präemptives Verfahren dagegen kann dem Prozess Ressourcen bereits vor der Fertigstellung wieder entziehen, um sie zwischenzeitlich anderen Prozessen zuzuteilen." Das bedeutet nichts anderes, als dass der Scheduler dem Task mit der höchsten Priorität eine Ressource auch dann zuteilen kann, wenn diese Ressource gerade von einem Task mit niedriger Priorität belegt ist. Dazu wird dem Task mit niedrigerer Priorität die Ressource ja eben noch vor der Fertigstellung wieder entzogen. Diese Fähigkeit macht ein RT OS aus, und dazu zählen noch eine Reihe weiterer Strategien der RT-OS, die ein paar noch deutlich vertracktere logische Blockiersituationen auflösen.

    > Genauso wenn durch Vollauslastung oder Überhitzung die CPU herunter taktet und dadurch weniger Leistung und längere Reaktionszeiten hat.

    Das ist doch Quatsch. Es gibt immer definierte Temperaturbereiche und andere physikalische Vorbedingungen, an welche ein Hersteller das einwandfreie Funktionieren seiner Hardware koppelt. Wenn der Anwender diese Bedingungen nicht erfüllt, etwa wenn er die Kühlung unterdimensioniert, dann liegt der Fehler bei ihm und nicht an der Hardware.

    > höchste Priorität hilft weder gegen Interrupts, ...

    Was hast du denn jetzt plötzlich für ein Problem mit Interrupts? Jeder Computer benutzt Interrupts bis hinunter zu den ohne Betriebssystem arbeitenden Microcontrollen(irgendwelche Sensorwerte gehen z.B. als Interrupts ein oder ein Zeitsignal). Interrupts blockieren aber keine Ressourcen so wie irgendein zeitintensiver Task.

    > Und was ist daran besonders? Bei nem x86-Board ist auch alles an den Taktgenerator
    > vom Board gekoppelt, macht ja anders keinen Sinn?

    Ein Software PWM Signal wird vom Prozessor erzeugt, macht also immer erst den Umweg über den Speicher und den Prozessor und belegt dort außerdem Ressourcen, was zu für manche zeitkritische Anwendungen zu ungenauen Ergebnissen führen kann. Ein Hardware PWM Signal ist dagegen als ein definierter Teiler des Zeitgebers definiert. Dieses Signal braucht nur gestartet zu werden und dann wird es vom Zeitgeber in der Präzision seines Quarzes geliefert ohne in irgendeiner Form den Prozessor zu beanspruchen.

    > Warum sollte x86 mit HardwarePWM nicht klar kommen?
    > Schonmal von PWM-Lüftern gehört? Sind seit grob 20 Jahren Standard auf x86-Boards.

    Diese PWM Lüfter steuern sich quasi selber, mit eigenem Treiberbaustein auf ihrer Platine. Das PWM Signal vom Board dient als eine Geschwindigkeitsanweisung, welche erst im Treiberbaustein in die eigentlichen Motorsignale übersetzt wird. Aber selbst das PWM Signal wird nicht vom OS gesteuert, sondern vom Rechner Bios. Deshalb kann man mit den Systemlüftern als Vergleich nicht so viel anfangen.

    > Da ich nicht genau verstehe, was du für eine Besonderheit bei der GPIO Anbindung
    > implizierst, schau einfach selbst, z.B. hier https://www.golem.de/news/intel-edison-
    > ausprobiert-ich-seh-dich-das-mona-lisa-projekt-1411-110577.html oder
    > mal Atomic Pi googeln.

    Sicher dass dieser kleine Controller überhaupt etwas mit x86 Architektur zu tun hat? Unabhängig davon braucht man für das wackeln lassen der Augen so oder so keine RT Hardware.

    > Das hast du impliziert, indem du behauptet hast, dass x86 kein RT kann

    Nein das habe ich nicht behauptet, du unterstellst mir das nur mal eben! Ich habe impliziert, dass ARM Systeme prinzipbedingte Vorteile in zeitkritischen Anwendungen bieten, zu welchen auch Mehrspuraufnahmeprogramme zählen. Dagegen habe ich nie behauptet, dass Mehrspuraufnahmen mehrheitlich auf ARM Systemen stattfinden würden.

    > Ohne zu googeln gehe ich jede Wette ein, das es dafür PCI oder USB Erweiterungskarten gibt.

    USB garantiert nicht, PCIe müsste ich nochmal nachschauen wie das genau war.

    > Wenn ARM bei Echtzeit so dermaßen überlegen wäre, wie du behauptest, sollten dann
    > nicht die meisten High-End Audioworkstations auf ARM basieren? 2 Sekunden Google
    > und du hättest 1000 Beispiele für ARM-DAWs.

    Die Vielseitigkeit und Leistungsfähigkeit des Desktops PCs und des Macs sind hier einfach ausschlaggebend. Die Timingschwierigkeiten hat man da einfach in Kauf genommen, bzw. ist sich der Problematik erst mit der Zeit bewusst geworden. Da muss man sich ja auch erst mal klar darüber werden, dass so ein paar vereinzelte Tausendstel Verzögerung so einen Unterschied machen. Als Musiker kann man ja erst mal nicht viel mehr als feststellen, dass sich das Aufnehmen "komisch" anfühlt gegenüber der Bandmaschine.

    > Nein ganz sicher nicht, denn darauf (weiches RT) basieren Computerspiele,
    > DAWs, Audio/Video-Wiedergabe, Videotelefonie, ...

    Das ist eine ganz andere Abteilung. RT Hardware und RT Betriebssysteme sind in diesem Sinne grundsätzlich und immer "hart".

    > Oha, und du behauptest also, ARM könnte hartes RT. Irgend nen Beispiel dazu?
    > Bisher hast du ja nur weiche RT Beispiele gegeben. Vorhin hattest du auch noch
    > von Linux und RT gesprochen, das ist ja auch nur weiches RT, entscheide dich doch mal.

    Die Linuxe die ich an anderer Stelle nannte (RTLinux, RTAI, LibeRTOS und Xenomai) sind alle samt RT tauglich, und in dem Sinne eines RT OS existiert wie gesagt kein "weich". Alle können sie Ereignisse zu bestimmten Zeitpunkten garantieren und alle bieten sie Strategien mit denen sie allen möglicherweise auftretenden Blockierungen eines RT Tasks auszuweichen in der Lage sind.


    > Vor allem wäre mal interessant was an nem Motor so eine hohe Genauigkeit für den
    > Zündzeitpunkt benötigt. High-End Motoren drehen mit knapp 20000 U/m -> 333 U/s ein
    > lahmer Atom oder ARM mit 1GHz -> 1000000000 Takte/s kann da jegliche Anforderungen
    > mit weichem RT im Schlaf erledigen.

    Ach so, du sprichst von Verbrennungsmotoren. Also erst mal drehen nicht mal die alten F1 Sauger Motoren mit 20.000 RPM und nur bis ca 14.000 RPM und zweitens geht es um die Steuerung von BLDC Motoren, sprich : Bürstenlosen Gleichstrommotoren,(BrushLess Direct Current) bzw. sogar um variable Drehstrommotoren. Wenn man dazu keine Treiberplatine benutzt sondern die PI selber als Treiber einsetzt um mit der die Steuersignale für den Motor zu erzeugen, dann muss man mit der PI Signale für drei verschiedenen Phasen eines BLDC Motors generieren. Das PWM Verfahren (Pulsweitenmodulation, muss, hoffe ich, hier nicht weiter erklärt werden) dient dabei der Spannungserzeugung, mit denen die Magnetspulen des Motors angesteuert werden. Dazu benötigte man sechs verschiedene GPIO Ports um die drei Phasen des Motors mit Strom in jeweils zwei Richtungen zu versorgen. Den Strom muss man dazu mit ziemlich hohen Frequenzen pulsen um ausreichend weiche Signale zu bekommen, und vielleicht kann man sich ja auch vorstellen, dass das eine ziemliche technische Herausforderung ist, die überhaupt erst in den späten neunzigern gemeistert wurde. Eine Stufe weiter befinden sich die sinodialen Motorsteuerungen. Quasi sind das Kreisstrommotoren, deren Signal digital aufbereitet wird, aber das ist wieder ne andere Geschichte...



    4 mal bearbeitet, zuletzt am 18.12.20 20:28 durch Ach.

  9. Re: aber ARM ist der der zuletzt lacht

    Autor: schnedan 18.12.20 - 22:20

    Viele Systeme an denen ein RT dransteht können nur Soft-Realtime, also keinen 100% nachweisbaren, inhärenten Determinismus

  10. Re: aber ARM ist der der zuletzt lacht

    Autor: Ach 20.12.20 - 11:00

    schnedan schrieb:
    --------------------------------------------------------------------------------
    > Viele Systeme an denen ein RT dransteht können nur Soft-Realtime, also
    > keinen 100% nachweisbaren, inhärenten Determinismus

    Ich würde dieses nicht mehr ganz aktuelle(2018) Video vorschlagen. Da werden einerseits die von dir angebrachten Probleme beschrieben und wie denen mit dem Preempt -RT Ansatz begegnet wird :

    => Jan Altenberg : "Realtime Linux uncovered"

  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Junior-Forschungsgruppenleit- er*in (m/w/d) für Deep Learning Image Analysen in der Neuroradiologie
    Universitätsmedizin der Johannes Gutenberg-Universität Mainz, Mainz
  2. Softwareentwickler - CAD/PLM (m/w/d)
    Hays AG, Esslingen
  3. Projektmanager MES in SAP (m/w/d)
    IGH Infotec AG, Langenfeld
  4. Systemadministrator (m/w/d) für UNIX / Oracle
    Bayerische Versorgungskammer, München

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 36,49€
  2. ab 69,99€ (inkl. digitaler Bonusinhalte + Lanyard im God of War-Design)
  3. 18,99€
  4. 3,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de