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. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


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

Stellenmarkt
  1. ORBIT Gesellschaft für Applikations- und Informationssysteme mbH, Bonn
  2. Hays AG, Raum Nürnberg
  3. MAGELLAN Rechtsanwälte Säugling und Partner mbB, München
  4. novacare GmbH, Bad Dürkheim

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 69,99€ (Release am 25. Oktober)
  2. 12,99€
  3. (-50%) 2,50€
  4. 3,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


iPad 7 im Test: Nicht nur für Einsteiger lohnenswert
iPad 7 im Test
Nicht nur für Einsteiger lohnenswert

Auch mit der siebten Version des klassischen iPads richtet sich Apple wieder an Nutzer im Einsteigersegment. Dennoch ist das Tablet sehr leistungsfähig und kommt mit Smart-Keyboard-Unterstützung. Wer ein gutes, lange unterstütztes Tablet sucht, kann sich freuen - ärgerlich sind die Preise fürs Zubehör.
Ein Test von Tobias Költzsch

  1. iPad Einschränkungen für Apples Sidecar-Funktion
  2. Apple Microsoft Office auf neuem iPad nicht mehr kostenlos nutzbar
  3. Tablet Apple bringt die 7. Generation des iPads

Funkstandards: Womit funkt das smarte Heim?
Funkstandards
Womit funkt das smarte Heim?

Ob Wohnung oder Haus: Smart soll es bitte sein. Und wenn das nicht von Anfang an klappt, soll die Nachrüstung zum Smart Home so wenig aufwendig wie möglich sein. Dafür kommen vor allem Funklösungen infrage, wir stellen die gebräuchlichsten vor.
Von Jan Rähm

  1. Local Home SDK Google bietet SDK für Smarthomesteuerung im lokalen Netzwerk
  2. GE Smarte Lampe mit 11- bis 13-stufigem Resetverfahren
  3. IoT Smart Homes ohne Internet, geht das? Ja!

IT-Sicherheit: Auch kleine Netze brauchen eine Firewall
IT-Sicherheit
Auch kleine Netze brauchen eine Firewall

Unternehmen mit kleinem Geldbeutel verzichten häufig auf eine Firewall. Das sollten sie aber nicht tun, wenn ihnen die Sicherheit ihres Netzwerks wichtig ist.
Von Götz Güttich

  1. Anzeige Wo Daten wirklich sicher liegen
  2. Erasure Coding Das Ende von Raid kommt durch Mathematik
  3. Endpoint Security IT-Sicherheit ist ein Cocktail mit vielen Zutaten

  1. BDI: Industrie für schnelle 5G-Errichtung statt Vertrauensschwüre
    BDI
    Industrie für schnelle 5G-Errichtung statt Vertrauensschwüre

    Die deutsche Industrie will keine Vertrauenswürdigkeitserklärung von den 5G-Ausrüstern einholen müssen. Diese Erklärungen seien wirkungslos, gefragt sei dagegen Cyber-Resilienz.

  2. Watch Parties: Twitch ermöglicht Streamern Filmabende mit Followern
    Watch Parties
    Twitch ermöglicht Streamern Filmabende mit Followern

    Gemeinsam im kleinen oder großen Kreis einen Spiefilm oder eine TV-Serie per Streaming anschauen: Das können Influencer künftig auf Twitch - vorerst allerdings nur in den USA.

  3. Smartspeaker: Belauschen mit Alexa- und Google-Home-Apps
    Smartspeaker
    Belauschen mit Alexa- und Google-Home-Apps

    Mit verschiedenen Tricks gelang es Sicherheitsforschern, Apps für Google Home und Amazons Alexa zu erzeugen, die Nutzer belauschen oder Phishingangriffe durchführen. Die Apps überstanden den Review-Prozess von Google und Amazon.


  1. 18:53

  2. 17:38

  3. 17:23

  4. 16:54

  5. 16:39

  6. 15:47

  7. 15:00

  8. 13:27