Abo
  1. Foren
  2. Kommentare
  3. Wissenschaft
  4. Alle Kommentare zum Artikel
  5. › Udoo: Entwicklerboard mit…

Der Vergleich mit Arduino hinkt da dieser auf AVRs basiert und nicht auf ARM

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Der Vergleich mit Arduino hinkt da dieser auf AVRs basiert und nicht auf ARM

    Autor: rabatz 16.04.13 - 13:08

    Auf ARM Prozessoren wird meist mit irgendwelchen Linux-Distributionen gearbeitet, die zwar im Vergleich zu AVRs sehr viele Features mitbringen, aber eben den Nachteil einer erhöhten Latenz mit sich bringen. Wenn man keinen RT-Kernel einsetzt ist die Latenz dazu noch nicht deterministisch.
    Ich bin selbst gerade dabei einen Regler mit einem Beaglebone zu realisieren und habe leider bis dato noch kein RT-Betriebssystem gefunden, welches auch die Interfaces zumindest rudimentär bedient. Entweder also non-RT mit Interfaces oder RT ohne Interfaces. Beides nicht wirklich zufriedenstellend für Embedded Systeme.
    Wenn ich keine Floating-Point Operationen bräuchte hätte ich zu einem AVR-Board wie dem Arduino gegriffen.

  2. Re: Der Vergleich mit Arduino hinkt da dieser auf AVRs basiert und nicht auf ARM

    Autor: Xstream 16.04.13 - 13:22

    der arduino due hat einen arm prozessor und genau der gleiche chip steckt auch auf diesem board hier. im endeffekt ist das quasi ein raspberry und ein arduino due auf einem board.

    und floating point geht doch mit dem arduino ist halt nur langsam

  3. Re: Der Vergleich mit Arduino hinkt da dieser auf AVRs basiert und nicht auf ARM

    Autor: Little_Green_Bot 16.04.13 - 13:29

    Bin mal gespannt, ob und wann es ein RT-Android gibt. Damit wäre das Board RT-tauglich. Eigentlich muss das kommen, schon allein um im Bereich Musik-Produktion mit Apple gleich zu ziehen.

    Einigkeit und Recht und Freiheit für das deutsche Vaterland!

  4. Re: Der Vergleich mit Arduino hinkt da dieser auf AVRs basiert und nicht auf ARM

    Autor: rabatz 16.04.13 - 13:33

    Xstream schrieb:
    --------------------------------------------------------------------------------
    > und floating point geht doch mit dem arduino ist halt nur langsam

    Software-Floating-Point unterstützt so gut wie jeder Cross-Compiler, aber das ist für die meisten Regelschleifen einfach zu langsam und auch nicht-deterministisch, da die Rechenzeit einer FP-Operation oft sehr vom Wert abhängt.

  5. Re: Der Vergleich mit Arduino hinkt da dieser auf AVRs basiert und nicht auf ARM

    Autor: regiedie1. 16.04.13 - 13:47

    Little_Green_Bot schrieb:
    --------------------------------------------------------------------------------
    > Bin mal gespannt, ob und wann es ein RT-Android gibt. Damit wäre das Board
    > RT-tauglich. Eigentlich muss das kommen, schon allein um im Bereich
    > Musik-Produktion mit Apple gleich zu ziehen.

    Wie kommst Du darauf, dass iOS oder OS X realtime-fähig sind? Die sind das nicht mehr als Linux, eher weniger.

  6. Re: Der Vergleich mit Arduino hinkt da dieser auf AVRs basiert und nicht auf ARM

    Autor: Little_Green_Bot 16.04.13 - 13:51

    rabatz schrieb:
    --------------------------------------------------------------------------------
    > Software-Floating-Point unterstützt so gut wie jeder Cross-Compiler, aber
    > das ist für die meisten Regelschleifen einfach zu langsam und auch
    > nicht-deterministisch, da die Rechenzeit einer FP-Operation oft sehr vom
    > Wert abhängt.

    Meinst Du, das wird mit dem genannten 4-Kern-Board noch relevant sein?

    Einigkeit und Recht und Freiheit für das deutsche Vaterland!

  7. Re: Der Vergleich mit Arduino hinkt da dieser auf AVRs basiert und nicht auf ARM

    Autor: rabatz 16.04.13 - 13:56

    Die hier genannte CPU hat ohnehin eine FPU, die FP-Operationen in linearer Zeit erledigt.
    Ich habe eher CPUs ohne HW-FPU gemeint.

  8. Re: Der Vergleich mit Arduino hinkt da dieser auf AVRs basiert und nicht auf ARM

    Autor: Little_Green_Bot 16.04.13 - 14:02

    regiedie1. schrieb:
    --------------------------------------------------------------------------------
    > Wie kommst Du darauf, dass iOS oder OS X realtime-fähig sind? Die sind das
    > nicht mehr als Linux, eher weniger.

    Weil Musiker oft OSX verwenden. Ich glaube, die würden das ohne garantierte Latenz-Zeiten nicht tun. OSX ist ja auch fast Linux (Unix-Kernel).

    RT ist im x86-Linux vorhanden, also auf dem Desktop-PC kein Problem. Das Problem ist RT auf ARM-Linux.

    Bei iOS bin ich nicht sicher, ob es bessere Latenz-Zeiten als Android bietet. Ich tendiere aufgrund der Historie eher dazu, dass iOS reifer ist.

    Einigkeit und Recht und Freiheit für das deutsche Vaterland!

  9. Re: Der Vergleich mit Arduino hinkt da dieser auf AVRs basiert und nicht auf ARM

    Autor: Wary 16.04.13 - 14:48

    Was spricht gegen real-time Linux?

  10. Re: Der Vergleich mit Arduino hinkt da dieser auf AVRs basiert und nicht auf ARM

    Autor: bimini 16.04.13 - 14:59

    Wofür brauchst du überhaupt ein OS.
    Du kannst die ARM Prozessoren ja auch direkt programmieren. Musste in Assembler und mit ner passenden IDE auch in C gehen.

  11. Re: Der Vergleich mit Arduino hinkt da dieser auf AVRs basiert und nicht auf ARM

    Autor: rabatz 16.04.13 - 15:09

    Wie ich schon geschrieben hatte, habe ich bis dato noch kein Board gesehen, welches von einem Realtime-Linux so unterstützt wird, dass man die Hardware auch vernünftig ansprechen kann. Das alleine wäre noch nicht das Problem, wenn es ordentliche Dokumentationen zu den jeweiligen RT-Linux Distributionen/Kernels geben würde. Ich will nicht erst 10 Jahre lang Kernel Entwicklung betrieben haben müssen um die Dokumentation zu einem soclhen System zu verstehen. Es müsste so gemacht werden, dass jemand der Linux grundsätzlich kennt bzw. die Grundlagen der Systemprogrammierung unter Linux beherrscht und auch Ahnung von Embedded Systemen ohne OS hat einen Anschlusspunkt findet um das System vernünftig verwenden zu können.
    Ich bin hier wirklich für jeden Tipp dankbar, aber ich habe bis dato leider noch kein solches System gesehen.

  12. Re: Der Vergleich mit Arduino hinkt da dieser auf AVRs basiert und nicht auf ARM

    Autor: rabatz 16.04.13 - 15:13

    Naja ein OS macht dann sinn, wenn man auch über Standard-Interfaces mit der Außenwelt kommunizieren will (Bluetooth, Ethernet, WLAN,...). Für die Kernaufgaben einen Embedded Systems ist es meist nicht notwendig.

  13. Re: Der Vergleich mit Arduino hinkt da dieser auf AVRs basiert und nicht auf ARM

    Autor: Wary 16.04.13 - 15:15

    CONFIG_PREEMPT_RT ist IMO nicht so schwierig. Meistens kann man die Distribution seiner Wahl nehmen und nur den Kernel tauschen.
    Natürlich muss man sich damit beschäftigen und vor allem die Software speziell dafür Programmieren.
    Die Doku finde ich auch nicht so schlecht, aber schnell in zwei Stunden mal ein vernünftiges System aufsetzen und Programmieren is halt nicht! Das liegt aber nicht am Projekt.

    https://rt.wiki.kernel.org/index.php/Main_Page

  14. Re: Der Vergleich mit Arduino hinkt da dieser auf AVRs basiert und nicht auf ARM

    Autor: rabatz 16.04.13 - 15:24

    Niemand verlangt, dass man in zwei Stunden eine sinnvolle Applikation baut, aber es sollte eben machbar sein und nicht nach dem Motto "der Source ist die Dokumentation" sein. Ich habe jetzt schon mehrere male probiert micht mich Xenomai zu beschäftigen, aber die einzige Doku hierzu sind zwei eher schlechte Papers und die API-Doku. Das reicht für jemanden, der das System noch nicht kennt einfach nicht und schreckt eher ab als das es hilft.

  15. Re: Der Vergleich mit Arduino hinkt da dieser auf AVRs basiert und nicht auf ARM

    Autor: Little_Green_Bot 16.04.13 - 17:33

    @rabatz:
    Wenn Du ein Beaglebone mit RT-Linux und I2C-Bus hast, wäre ein selbst geschriebener I2C-Treiber für den Regler vielleicht eine Option. I2C ist nicht so schwer.

    Einigkeit und Recht und Freiheit für das deutsche Vaterland!

  16. Re: Der Vergleich mit Arduino hinkt da dieser auf AVRs basiert und nicht auf ARM

    Autor: Little_Green_Bot 16.04.13 - 18:04

    PS: Ich glaube, dass Du RT-Linux für's Beagleboard nie mit Interface-Treiber bekommst, hat System. Die Abfrage eines Interface beeinflusst das RT-System, so dass man wahrscheinlich davon ausgeht, dass der User sich den Treiber selbst schreibt.

    Einigkeit und Recht und Freiheit für das deutsche Vaterland!

  17. Re: Der Vergleich mit Arduino hinkt da dieser auf AVRs basiert und nicht auf ARM

    Autor: rabatz 16.04.13 - 18:26

    Das wird alles richtig sein.
    Ich verstehe aber trotzdem nicht, warum die Hersteller der Boards oder der SOCs nicht schon ein RT-Linux und eine entsprechende Dokumentation dazu anbieten. Gerade bei Embedded Systems muss der Hersteller damit rechnen, dass der Anwender RT-Fähigkeiten braucht, da dies in diesem Bereich ja wohl eher die Regel als die Ausnahme ist. Meiner Meinung tut sich da zu wenig in die Richtung.

  18. Re: Der Vergleich mit Arduino hinkt da dieser auf AVRs basiert und nicht auf ARM

    Autor: barforbarfoo 16.04.13 - 18:27

    rabatz schrieb:
    --------------------------------------------------------------------------------
    > Auf ARM Prozessoren wird meist mit irgendwelchen Linux-Distributionen
    > gearbeitet, die zwar im Vergleich zu AVRs sehr viele Features mitbringen,
    > aber eben den Nachteil einer erhöhten Latenz mit sich bringen. Wenn man
    > keinen RT-Kernel einsetzt ist die Latenz dazu noch nicht deterministisch.
    > Ich bin selbst gerade dabei einen Regler mit einem Beaglebone zu
    > realisieren und habe leider bis dato noch kein RT-Betriebssystem gefunden,
    > welches auch die Interfaces zumindest rudimentär bedient. Entweder also
    > non-RT mit Interfaces oder RT ohne Interfaces. Beides nicht wirklich
    > zufriedenstellend für Embedded Systeme.
    > Wenn ich keine Floating-Point Operationen bräuchte hätte ich zu einem
    > AVR-Board wie dem Arduino gegriffen.

    Evtl. hilft das weiter: http://elinux.org/ECE497_BeagleBone_PRU

    Kommt natürlich auf die Aufgabenstellung an.

    Oder war auf der Beaglebone CPU nicht noch ein DSP drauf ?



    1 mal bearbeitet, zuletzt am 16.04.13 18:35 durch barforbarfoo.

  19. Re: Der Vergleich mit Arduino hinkt da dieser auf AVRs basiert und nicht auf ARM

    Autor: rabatz 16.04.13 - 18:41

    Habe ich schon überflogen. Würde den Zweck auch nur teilweise erfüllen. Außerdem habe ich eigentlich keine Lust drauf habe extra Assembler-Code zu schreiben nur um Determinismus ins System zu bekommen. PRU kann gut für Treiber eingesetzt werden, aber wenn das Betriebsystem keine Echtzeitfähigkeit besitzt nützt der beste Treiber noch nichts. Einen gesamten Regler in die PRU auszulagern wäre schon ein sehr harter Job.

  20. Re: Der Vergleich mit Arduino hinkt da dieser auf AVRs basiert und nicht auf ARM

    Autor: Xstream 17.04.13 - 01:15

    es verwenden auch jede menge musiker windows, beide systeme sind keine realtime systeme

  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. SARSTEDT AG & Co. KG, Nümbrecht
  2. WERTGARANTIE Group, Hannover
  3. TÜV SÜD Gruppe, Leverkusen
  4. Amprion GmbH, Pulheim-Brauweiler

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 0,49€
  2. 3,99€
  3. (-0%) 9,99€
  4. 2,22€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Bethesda: Ich habe TES Blades für 5,50 Euro durchgespielt
Bethesda
Ich habe TES Blades für 5,50 Euro durchgespielt

Rund sechs Wochen lang hatte ich täglich viele spaßige und auch einige frustrierende Erlebnisse in Tamriel: Mittlerweile habe ich den Hexenkönig in TES Blades besiegt - ohne dafür teuer bezahlen zu müssen.
Ein Bericht von Marc Sauter

  1. Bethesda TES Blades ist für alle verfügbar
  2. TES Blades im Test Tolles Tamriel trollt
  3. Bethesda TES Blades startet in den Early Access

Zulassung autonomer Autos: Der Mensch fährt besser als gedacht
Zulassung autonomer Autos
Der Mensch fährt besser als gedacht

Mehrere Jahre haben Wissenschaftler und Autokonzerne an Testverfahren für einen Autobahnpiloten geforscht. Die Ergebnisse sprechen für den umfangreichen Einsatz von Simulation. Und gegen den schnellen Einsatz der Technik.
Von Friedhelm Greis

  1. Ingolstadt Audi vernetzt Autos mit Ampeln
  2. Wasserkühlung erforderlich Leistungshunger von Auto-Rechnern soll stark steigen
  3. Waymo One Lyft vermittelt Waymos autonome Taxis

Das andere How-to: Deutsch lernen für Programmierer
Das andere How-to
Deutsch lernen für Programmierer

Programmierer schlagen sich ständig mit der Syntax und Semantik von Programmiersprachen herum. Der US-Amerikaner Mike Stipicevic hat aus der Not eine Tugend gemacht und nutzt sein Wissen über obskure Grammatiken, um Deutsch zu lernen.
Von Mike Stipicevic

  1. Programmiersprachen, Pakete, IDEs So steigen Entwickler in Machine Learning ein
  2. Software-Entwickler Welche Programmiersprache soll ich lernen?

  1. Onlinehandel: Mehr Verbraucherbeschwerden im Paketgeschäft
    Onlinehandel
    Mehr Verbraucherbeschwerden im Paketgeschäft

    Im vergangenen Jahr haben sich deutlich mehr Kunden über Probleme bei Paketzustellungen beschwert als noch ein Jahr zuvor. Auch im laufenden Jahr hält der Trend durch das Wachstum des Onlinehandels an. Gemessen an der Zahl der gelieferten Pakete sind es aber wenige Beanstandungen.

  2. Premium Alexa Skills: Skills für Amazons Alexa mit Bezahlfunktion starten
    Premium Alexa Skills
    Skills für Amazons Alexa mit Bezahlfunktion starten

    Amazon hat erste Premium Alexa Skills für Deutschland veröffentlicht. Diese enthalten sogenannte In-Skill-Käufe, Kunden können gegen Bezahlung spezielle Funktionen aktivieren. Zum Start stehen insgesamt 14 Angebote zur Verfügung.

  3. Vodafone: Otelo-Vertragskunden erhalten Zugang zum LTE-Netz
    Vodafone
    Otelo-Vertragskunden erhalten Zugang zum LTE-Netz

    Die Vodafone-Marke Otelo bietet Kunden mit Laufzeitverträgen Zugang zum LTE-Netz. Bisher musste der LTE-Zugang extra bezahlt werden, nun ist er in allen Tarifen enthalten, auch für Bestandskunden. Prepaid-Kunden können das LTE-Netz weiterhin nicht nutzen.


  1. 12:12

  2. 11:53

  3. 11:35

  4. 14:56

  5. 13:54

  6. 12:41

  7. 16:15

  8. 15:45