Krasse Dinger ... Obwohl (in meinem Fall STM32F429) "nur" 168MHz läuft da MP3+Dynamic-Compressor+10Band Equalizer (nebenbei noch lesen von SD-Karte) in wahnsinnig viel schneller als Echtzeit auf den Dingern ... Und das mit float-Genauigkeit (bis auf MP3 natürlich^^) FPU ist schon echt ein nettes Feature :) Respekt :) *edit*: Und an den GCC, der brav die FPU-Instruktionen generiert und auch MAC-Operationen erkennt und per Loop-Unrolling alle FPU-Register effizient verwendet :)
:
Bearbeitet durch User
Ja, die MCU ist ganz schön flott. Welchen Decoder hast Du denn verwendet?
Markus schrieb: > Welchen Decoder hast Du denn verwendet? Hatte den Standard-Helix-Decoder verwendet :)
Ich hatte damals meinen 386er PC mit einer i80387 FPU aufgerüstet. Für die benchmarks hat das einen Riesen Vorteil gebracht. Für die Praxis allerdings eher weniger, weil 90% meiner Programme nicht darauf vorbereitet waren. Wie dem auch sei, so eine FPU ist eine praktische Sache. Wenn man eine hat, kann man sich einige un-intuitive Ersatz-Konstrukte ersparen.
Dynamischer Compressor und 10 Band EQ wäre eher was für einen DSP als für die FPU ;) Da könnte die Taktrate noch viel geringer sein und alles würde passen.
Heinz schrieb: > Dynamischer Compressor und 10 Band EQ wäre eher was für einen DSP > als für die FPU ;) Da könnte die Taktrate noch viel geringer sein und > alles würde passen. Haha, jo.... Und dann müsste man sich nicht ständig fragen, wieso mab so ein board mit 32mb sdram selbstgebaut hat, anstatt einen raspberry pi zero zu verwenden xD ... Oder gleich ein fertiges android handy und nur die software zu bauen xD
Mampf unterwegs schrieb: > ein board mit 32mb sdram selbstgebaut hat, anstatt einen raspberry pi > zero zu verwenden xD Oder sowas: https://www.indiegogo.com/projects/licheepi-zero-6-extensible-linux-module-on-finger-wifi-diy/x/14929614#/ :D
Ivan Ivanovic Ivanovski schrieb: > Mampf unterwegs schrieb: >> ein board mit 32mb sdram selbstgebaut hat, anstatt einen raspberry pi >> zero zu verwenden xD > > Oder sowas: > https://www.indiegogo.com/projects/licheepi-zero-6-extensible-linux-module-on-finger-wifi-diy/x/14929614#/ > :D Respekt an den TO - der hat's erkannt wie der Hase läuft. Die Welt besteht eben nicht nur aus den fertig Dingern! Und ich wette, dass der TO auch sehr viel schneller seiner erste MP3 abspielen kann. Er muss nicht warten, bis sich erstmal ein Linux gebootet hat.
>Oder sowas: >https://www.indiegogo.com/projects/licheepi-zero-6... >:D Ein schönes Board. Allerdings bin auch ich der Meinung, dass nicht überall ein Betriebssystem laufen sollte, weil es so viel Nachteile hat: - Bootzeit - Stromverbrauch - Updates - Zerschießen der SD-Karte bei Power Down - Komplexität Ich bevorzuge eine Startzeit von 1ms bei meinen Applikationen, das fühlt sich sehr angenehm an.
dann jetzt auf einen M7 upgraden und freuen das der quatsch 3x laufen kann ^^ bin auch immer wieder erstaunt was die M4/M7 so können. Ich habs momentan eher mit Videostreaming( LAN) + USB und so ^^
tzhgfhgrhzfghz6453454353453534534533453453 schrieb: > bin auch immer wieder erstaunt was die M4/M7 so können. ... und ich jammer schon 'rum dass die FPU nur 32-bittig ist ...
tja schrieb: > Und ich wette, dass der > TO auch sehr viel schneller seiner erste MP3 abspielen kann. Er muss > nicht warten, bis sich erstmal ein Linux gebootet hat. Ja, und das geht sogar erstaunlich schnell ... Innerhalb 2 Sekunden ist das Ding up-and-running - inklusive vollgefülltem Audio-Puffer mit MP3-dekodieren, Dynamik-komprimierten und "equalisierter" Daten für rund 30 Sekunden Spielzeit! :) Kann man die Raspies nicht Bare-Metal programmieren?^^
:
Bearbeitet durch User
Mampf F. schrieb: > Krasse Dinger ... Obwohl (in meinem Fall STM32F429) "nur" 168MHz läuft > da MP3+Dynamic-Compressor+10Band Equalizer (nebenbei noch lesen von > SD-Karte) in wahnsinnig viel schneller als Echtzeit auf den Dingern ... naja 168MHz?? auf dem AVR32 mit DSP+FPU ging das auch bei relativ mageren 66MHz, schade dass atmel damals es vergeigt hatten diesen Core zu einem Standard zu etablieren...zu dem Zeitpunkt gab es noch nichtmal eine CortexM4 CPU auf dem Markt... da gab es nur ARM7 und erste Ansätze von Luminary, die ja regelrecht selbst nach TI Übernahme gescheitert ist. ist halt manchmal so, dass sich nicht unbedingt das bessere System durchsetzt, sondern da wo viel mehr Lobby und Marketing betrieben wird
Mampf F. schrieb: > Kann man die Raspies nicht Bare-Metal programmieren?^^ Klar - Kinderspiel ;) Falls Du es ernst meinst: https://www.gitbook.com/book/arobenko/bare_metal_cpp/details
>dann jetzt auf einen M7 upgraden und freuen das der quatsch 3x laufen >kann ^^ Falls Du damit meinst, dass ein F7 ca.3x schneller als ein F4 läuft, dann würde ich sagen: eher nein. Das Apfelmänchen lässt sich aber schon in ca. 1 Sekunde rechnen: Beitrag "Re: STM32F746 Discovery ARDUINO"
STM Apprentice schrieb: > tzhgfhgrhzfghz6453454353453534534533453453 schrieb: >> bin auch immer wieder erstaunt was die M4/M7 so können. > > ... und ich jammer schon 'rum dass die FPU nur 32-bittig ist ... Beim Cortex-M7 ist sie zum Teil 64-bittig.
>Beim Cortex-M7 ist sie zum Teil 64-bittig.
Was heißt "zum Teil" ?
Stefan schrieb: > ist halt manchmal so, dass sich nicht unbedingt das bessere System > durchsetzt In diesem Fall aber gottseidank schon ... :-) Gruß Jobst
Markus schrieb: >>Beim Cortex-M7 ist sie zum Teil 64-bittig. > > Was heißt "zum Teil" ? Karl schrieb: > AFAIK kann sich das der Hersteller raussuchen. Jo, selbst beim STM32F7 gibt es welche mit double-precision und welche mit single-precision FPU. Die dickeren Modelle mit 512K RAM haben alle eine double-precision FPU und die "kleineren" Modelle mit 320K RAM und weniger haben eine single-precision FPU. Markus schrieb: > Falls Du damit meinst, dass ein F7 ca.3x schneller als ein F4 läuft, > dann würde ich sagen: eher nein. Mit 64bit FPU und dem höheren Takt gegenüber den F4 kommt der Faktor drei durchaus hin, eventuell mehr und eventuell weniger, je nach Anwendungsfall natürlich.
Mampf F. schrieb: > Krasse Dinger ... Obwohl (in meinem Fall STM32F429) "nur" 168MHz läuft > da MP3+Dynamic-Compressor+10Band Equalizer (nebenbei noch lesen von > SD-Karte) in wahnsinnig viel schneller als Echtzeit auf den Dingern ... > Und das mit float-Genauigkeit (bis auf MP3 natürlich^^) FPU ist schon > echt ein nettes Feature :) > > Respekt :) > > *edit*: Und an den GCC, der brav die FPU-Instruktionen generiert und > auch MAC-Operationen erkennt und per Loop-Unrolling alle FPU-Register > effizient verwendet :) Das ist ein Microcontroller. Um mal einen Autovergleich zu bemühen: Unter der Klasse "Fahrzeuge" ist der F4 höchstens ein Bobbycar. Wenn man Performance braucht, sollte man einen richtigen Prozessor einsetzen. Da fang ich doch mal klein an, und schlag mal einen i.MX6 vor. Selbst gegen das allerkleinst Derivat muss ist der F4 so klein mit Hut, da bleibt nichts mehr ;-) https://cache.freescale.com/files/32bit/doc/fact_sheet/IMX6SRSFS.pdf Jetzt ist der i.MX6 selber aber auch nicht wirklich eine Rakete, aber das Verhältnis Elektrische Leistung <> Performance und Kosten <> Performance ist um Welten besser als beim F4. Merke: Die Kernkompetenz von Microcontrollern ist NICHT die Performance. Und zu Microcontrollern zählt auch der F4.
>Die Kernkompetenz von Microcontrollern ist NICHT die Performance. >Und zu Microcontrollern zählt auch der F4. Aber zum Beispiel auch der 8051 oder der ATtiny13a. Und im Vergleich dazu ist der STM32F4 ganz schön flott. Mit uCs der Cortex-M Serie ist heute einiges möglich, was vor einiger Zeit anderen Leistungsklassen vorbehalten war.
> Mit uCs der Cortex-M Serie ist heute einiges möglich, was vor einiger > Zeit anderen Leistungsklassen vorbehalten war. Sagen wir mal lieber damit ist heute das moeglich was vor 10Jahren schon mit den Renesas SHs moeglich war. Olaf
>Markus schrieb: >> Falls Du damit meinst, dass ein F7 ca.3x schneller als ein F4 läuft, >> dann würde ich sagen: eher nein. >Mit 64bit FPU und dem höheren Takt gegenüber den F4 kommt der Faktor >drei durchaus hin, eventuell mehr und eventuell weniger, je nach >Anwendungsfall natürlich. Der Test aus der Praxis ergibt knapp den Faktor 2: Single Precision Whetstones: STM32F4 Discovery@168Mhz ==> 109.05 MIPS STM32F746 Discovery@216Mhz ==> 202.84 MIPS von Beitrag "Re: Benchmark für Arduino-Boards?" Aber immerhin verwunderlich, dass der F7 Faktor 2 schafft, bei dem geringen MCLK Unterschied. Es kann ja eigentlich nur durch besseren Cash und Piplininig erreicht werden, oder?
> Es kann ja eigentlich nur durch besseren Cash und Piplininig erreicht > werden, oder? Renesas SH7750 430Mips bei 240Mhz und FPU 1.7 GFLOPS. Vorteilhaft duerfte da wohl das bessere Ram sein. Die ARM-Teile brauchen ja immer Waitstates ohne Ende. Ich verstehe garnicht das immer alle mit so langsamen Kisten rum machen wenn sie angeblich Speed brauchen. :-) Olaf
Mmhm schrieb: > Merke: > Die Kernkompetenz von Microcontrollern ist NICHT die Performance. Und zu > Microcontrollern zählt auch der F4. Oder Die STM32F0.. was da alles in einem TSSOP20 bei 48Mhz versteckt ist, kann man auch schon kaum glauben.. obwohl es natürlich teils normal ist. DMA,mehrere SPI,I2C,Usarts, USB(Opt.), 5 16bit Timer,9ADC Channels, RTC.........u.s.w
> DMA,mehrere SPI,I2C,Usarts, USB(Opt.), 5 16bit Timer,9ADC Channels, > RTC.........u.s.w Warum ist das unglaublich? Letztlich sind das auch nur ein paar geschickt verschaltete Register. Ausserdem hatten das die Japaner auch schon vor 15Jahren in ihren Controllern. Hat hier nur keiner wahrgenommen. Unglaublich wird es wenn man sieht wieviel Ram man heute in den Controllern bekommt. Das ist dann wohl die direkte Folge davon das man kleinere Prozesse anwendet. Dafuer geht dann aber auch kein 5V mehr. Oder schaut euch mal das Konzept der TPU bei den steinalten 68332 an. Da frag ich mich immer wieso sich das nicht mehr durchgesetzt hat. Hat vermutlich den durschnittlichen Entwickler ueberfordert. Olaf
olaf schrieb: > Warum ist das unglaublich? Unglaublich fantastisch sowas für 1 Euro als Hobbyist mit Minimalbeschaltung programmieren zu können. Was es gab und geben wird und wieso es so ist wie es ist weiß ich auch. Wenn ich hier eine 200mx100m große Maschine ansehe mit 8 großen reinen Serial Terminals und irgendwas Richtung Z80 als Rechenwerk, RS422 Convertern, einafchen IO Karten finde ich das heute auch noch ein große Leistung.. So einfach nachzubauen, aber heute würde ein riesen Aufriss mit einer SPS-Steuerung die bestimmt mehrere Schalträume ausfüllen würde gemacht werden, dazu noch die ganz wichtigen Entwicklungskosten für die tollen Monitorbildchen.
Mmhm schrieb: > Das ist ein Microcontroller. Ja, ein kleines Arbeitspferd, dass man unauffällig dort einbaut und rackern lässt, wo man es braucht. > Um mal einen Autovergleich zu bemühen: > Unter der Klasse "Fahrzeuge" ist der F4 höchstens ein Bobbycar. Nein, da ein Microcontroller weit über dem Niveau eines Spielzeugs liegt. > Wenn man Performance braucht, Performance ist nur ein Schlagwort. Ein Ingenieur quantifiziert was er braucht und nimmt das richtige Werkzeug für die Aufgabe. > sollte man einen richtigen Prozessor > einsetzen. Da fang ich doch mal klein an, und schlag mal einen i.MX6 > vor. > Selbst gegen das allerkleinst Derivat muss ist der F4 so klein mit Hut, > da bleibt nichts mehr ;-) Könntest du deinen Geschlechtsteilgrößenvergleich woander machen? Danke.
Markus schrieb: >>dann jetzt auf einen M7 upgraden und freuen das der quatsch 3x laufen >>kann ^^ > > Falls Du damit meinst, dass ein F7 ca.3x schneller als ein F4 läuft, > dann würde ich sagen: eher nein. hmm frage ist ja wie weit der M4 jetzt schon ausgelastet ist. mit RTOS kann man das ja fix anzeigen lassen Generell sind das aber schöne arbeitstierchen ... Und etwas reserve ist sicher nicht falsch!! denn auch ein "blinky" auf einem Linux raspi ist dolle daneben ^^
Markus schrieb: > > von > Beitrag "Re: Benchmark für Arduino-Boards?" > > Aber immerhin verwunderlich, dass der F7 Faktor 2 schafft, bei dem > geringen MCLK Unterschied. > Es kann ja eigentlich nur durch besseren Cash und Piplininig erreicht > werden, oder? Bingo. Die Hauptneuerung vom F7 gegenüber dem F4 ist eine 6 stage Pipeline, die recht finegetuned Parallelisierung auf Zyklenebene vornehmen kann. Hatten wir aber schon Mal...
Jack schrieb: > Mmhm schrieb: >> Das ist ein Microcontroller. > > Ja, ein kleines Arbeitspferd, dass man unauffällig dort einbaut und > rackern lässt, wo man es braucht. > >> Um mal einen Autovergleich zu bemühen: >> Unter der Klasse "Fahrzeuge" ist der F4 höchstens ein Bobbycar. > > Nein, da ein Microcontroller weit über dem Niveau eines Spielzeugs > liegt. > >> Wenn man Performance braucht, Sachen, wie sie hier genannt wurden (MP3, Audio Signal processing etc) macht ein richtiger Prozessor mit Betriebssystem besser. Warum? Weil man auf einem F4 alles in Firmware lösen muss. Auf einem richtigen System verwendet man dazu fertige Softwarepakete oder kann auf Libraries zurückgreifen. Man kann verbreitete Schnittstellen verwenden, ohne viel Implementierungsaufwand. Man hat ordentlich Speicher (GB stat kB) für Daten und auch die Leistung, damit etwas vernünftiges anzustellen. Man tut sich um Häuser leichter, Daten über Netzwerk oder auf Filesysteme zu speichern. Das ist dazu auch noch viel schneller. Es ist flexibler, weil man leichter Softwaremodule nachladen kann. Das macht den F4 jetzt weder überflüssig, noch schlecht. Er ist halt nur nicht für den Bereich gedacht, das ist alles. Aber mit Verlaub: Bei der FPU des F4 von "toller Leistung" zu spechen ist Käse, sorry. Überle dir mal, wieviele F4 nötig wären, um einem handelsüblichem PC an Leistung gleichzukommen. Und dann überlege, was die kosten, und was das Strom braucht.
Mmhm schrieb: > Auf einem richtigen > System verwendet man dazu fertige Softwarepakete oder kann auf Libraries > zurückgreifen. Was für ein Blödsinn. Deine Aussagen zeugen von absoluter Unkenntnis. Es gibt auch für Controller in C so viele fertige Softwarepakete / Libs, die man nur noch zusammen stöpseln muss um das zu erledigen. Das ist überhaupt der Grund, warum die meisten das hier schaffen. Gruß Jobst
Mmhm schrieb: > Auf einem richtigen > System verwendet man dazu fertige Softwarepakete oder kann auf Libraries > zurückgreifen. Das kann man ohne OS auch ... Zuletzt hatte ich spaßeshalber die libsidplay (im Prinzip ein (fast)kompletter C64-Emulator) von Linux ohne große Mühen für den ARM kompiliert und der hat funktioniert ... Und das ohne OS^^ Das einzige wo ich dir Recht geben müsste: Verwendet man ein OS wie Linux, dann hat man eine MMU und damit eine vernünftige Speicherverwaltung ... Das fehlt mir leider ... Ein haufen new und delete würden ratzefatz den Speicher fragmentieren und ihn auffressen.
>Überlege dir mal, wieviele F4 nötig wären, >um einem handelsüblichem PC an Leistung gleichzukommen. Und wie viele PCs braucht man, um so viele SPI und I2C Schnittstellen zu haben wie an einem F4 ? >Verwendet man ein OS wie Linux, dann hat man eine MMU >und damit eine vernünftige Speicherverwaltung ... War das nicht umgekehrt, man muss eine MMU haben, damit Linux überhaupt läuft ? >in C so viele fertige Softwarepakete / Libs aha, ist keine Frage der Hardware, sondern der Software >(MP3, Audio Signal processing etc) macht ein richtiger Prozessor >mit Betriebssystem besser. also MP3 Player mit Windows 10 und DVD/BluRay Player mit Linux ?? Warum ist da noch keiner drauf gekommen ? Oder ist der Kern der etwas abgeglittenen Diskussion, das kann ICH besser auf einem uC/PC, und nicht, der uC/PC ist besser ?
Äpfel und Birnen schrieb: >>Verwendet man ein OS wie Linux, dann hat man eine MMU >>und damit eine vernünftige Speicherverwaltung ... > War das nicht umgekehrt, man muss eine MMU haben, > damit Linux überhaupt läuft ? Exactly ... Trotzdem ist meine Aussage richtig (wenn man die ucLinux-Abart nicht betrachtet) ... Verwendet man ein OS wie Linux, dann hat man eine MMU und damit eine vernünftige Speicherverwaltung :)
Mampf F. schrieb: > > Das einzige wo ich dir Recht geben müsste: Verwendet man ein OS wie > Linux, dann hat man eine MMU und damit eine vernünftige > Speicherverwaltung ... > Mit solchen Aussagen wäre ich etwas vorsichtig. Der Hauptanwendungszweck von MMUs besteht darin, Speicherbereiche hardwareunterstützt logisch gegeneinander abzugrenzen, so dass fehlerhafte Speicherzugriffe eines Prozesses andere Prozesse nicht in Mitleidenschaft zieht. Jedenfalls nützen alle OS, die MMUs unterstützen bzw. voraussetzen, die MMUs für diese Anwendung. Das ist genau dann sinnvoll, wenn die Prozesse so unabhängig voneinander sind, dass ein Problem in einem Prozess diesen zwar lahmlegt, die anderen Prozesse aber trotzdem weiterarbeiten können, z.B: Mehrbenutzersysteme. Das ist in Embedded aber in der Regel nicht der Fall, weil alle Prozesse (dort normalerweise tasks genannt) als Ganzes zusammen arbeiten müssen. Wenn also z.B. in einem Zutrittskontrollsystem die Buchungstask "Mist baut," dafür aber die Ausweis- und Kommunikationstasks weiter laufen (weil eine MMU die Speicherbereiche gegeneinander abgrenzt), läuft das System als Ganzes trotzdem nicht richtig. Man könnte sogar argumentieren, dass in solchen Fällen eine MMU problematischer ist, weil das Gesamtsystem damit wahrscheinlicher in einen semistabilen Zustand gerät (also einen, bei dem das Fehlverhalten nicht erkannt und damit korrigiert werden kann). Semistabile Zustände sind in Embedded Systemen weitaus unangenehmer als Zustände, für die es Korrekturmöglichkeiten gibt (wenn auch wie bei Watchdogs mit dem Holzhammer). > Das fehlt mir leider ... Ein haufen new und delete würden ratzefatz den > Speicher fragmentieren und ihn auffressen. Pls explain. Warum hilft eine MMU gegen Speicherfragmentierung?
Mmhm schrieb: > Aber mit Verlaub: > Bei der FPU des F4 von "toller Leistung" zu spechen ist Käse, sorry. > Überle dir mal, wieviele F4 nötig wären, um einem handelsüblichem PC an > Leistung gleichzukommen. Und dann überlege, was die kosten, und was das > Strom braucht. Wenn ich einen F4 nehme, dann habe ich in einem Chip von 15x15mm alles, was ich brauche, zusammen um sehr viele Aufgaben zu erledigen. Und das bei einer Leistungsaufnahme, bei der beim PC vermutlich noch nicht einmal der Netzteillüfter anläuft :-} Davon ab: Wie groß war nochmal ein PC? Wie lange braucht er nach dem Einschalten, damit ich überhaupt mit ihm arbeiten kann? Was ist mit harter, schneller Echtzeit? Es ist ziemlich absurd, Äpfel mit Birnen zu vergleichen. Und: wer mit 8039 und 6502 angefangen hat, für den ist es schon beeindruckend, was diese kleinen Dinger heute alles können.
Äpfel und Birnen schrieb: > War das nicht umgekehrt, man muss eine MMU haben, > damit Linux überhaupt läuft ? Nö. https://www.mikrocontroller.net/articles/Linux_auf_STM32
:
Bearbeitet durch User
Äpfel und Birnen schrieb: >>Überlege dir mal, wieviele F4 nötig wären, >>um einem handelsüblichem PC an Leistung gleichzukommen. > Und wie viele PCs braucht man, um so viele SPI und I2C Schnittstellen > zu haben wie an einem F4 ? Vielleicht jetzt nicht bei einem handelsüblichen PC. Was aber Prozessoren angeht: Einen einzigen. Auch die üblichen Prozessoren haben SPI, I2C, UART und so weiter und so fort. Schneller und in größerer Zahl als auf einem µC. Noch nie hatte ich soviele freie Schnittstellen übrig, als bei meiner ersten i.MX6-Platine. Besser noch: Man will eine RTCC an I2C ansprechen? Ein Klax, verglichen mit dem STM32. Das ist ein einziger Eintrag in den Devicetree. Den Rest erledigt der Linux-Treiber. UART? Kein Problem. Macht der Linux-Treiber. Dito SPI. Dazu kommt, die Dinger haben Schnittstellen, die der STM32 nicht hat. SD-Karte mit DDR und >100MHz? Kann kein einziger STM32. EMMC? PCI-Express? SATA? MIPI?... Ein Blick über den Tellerrand könnte nicht schaden.
Ruediger A. schrieb: > Pls explain. Warum hilft eine MMU gegen Speicherfragmentierung? Da kanb ich leider nur auf die erfagrungen mit x86 zurück greifen... Virtueller speicher ist das stichwort... Physische 4k blöcke können von der speicherverwaltung so umgemappt werden, dass er für einen prozess linear aussieht, obwohl er es nicht ist. Hat man nur physischen speicher müsste man ständig alles umkopieren, damit neuer zusammenhängender speicher frei wird, den man wieder allozieren kann... Jedes free oder delete sorgt für eine größere fragmentierung, die man nicht so einfach beheben kann.
Mampf unterwegs schrieb: > Hat man nur physischen speicher müsste man ständig alles umkopieren, > damit neuer zusammenhängender speicher frei wird, den man wieder > allozieren kann... Jedes free oder delete sorgt für eine größere > fragmentierung, die man nicht so einfach beheben kann. Das was du beschreibst, ist eine Eigenschaft des Betriebssystems. Das hat mit einer MMU nichts zu tun. Eine MMU kümmer sich um die korrekte Ansteuerung der RAM-Bausteine und Refresh und diesen Impedanzkram, und all die anderen lästigen Dinge die DRAMs so mit sich bringen. Sie blendet den furchtbar umständlich zu verwendenden DRAM als simpler adressierbaren Bereich ein. Was der Prozessor damit tut, ist der MMU egal. Um die Allzierung von Blöcken da drin kümmert sich beim PC oder einem Prozessorsystem das OS. Dort wird fragmentiert, wenn das nicht sauber gelöst ist. µCs ohne OS haben damit sowieso so ihre Probleme. Ja, man kann einen Heap deklarieren und malloc verwendet. Da sollte man aber sehr sauber arbeiten. Noch ein Argument für Linux :-)
Mmhm schrieb: > Eine MMU kümmer sich um die korrekte Ansteuerung der RAM-Bausteine und > Refresh und diesen Impedanzkram, und all die anderen lästigen Dinge die > DRAMs so mit sich bringen. Sie blendet den furchtbar umständlich zu > verwendenden DRAM als simpler adressierbaren Bereich ein. Was der > Prozessor damit tut, ist der MMU egal. Facepalm
Mmhm schrieb: > Das was du beschreibst, ist eine Eigenschaft des Betriebssystems. > Das hat mit einer MMU nichts zu tun. Ähm, jein ... Ja, die Speicherverwaltung macht das OS ... Aber der "Virtual Memory" muss von der Hardware unterstützt sein. Das hangeln durch den TLB zB wäre softwaremäßig ein unzumutbarer Overhead ... Hier TLB: https://en.wikipedia.org/wiki/Translation_lookaside_buffer Hier MMU: https://en.wikipedia.org/wiki/Memory_management_unit Das Prinzip ist quasi gleich ... Von der VAX bis zum ARM gibt es nicht wesentliche Unterschiede. Um es nochmal auf den Punkt zu kriegen ... Auch mit MMU fragmentiert der physische Speicher, was aber nicht wirklich relevant ist, weil er durch die Virtuellen Adresse wieder linearisiert wird^^
Mmhm schrieb: > Eine MMU kümmer sich um die korrekte Ansteuerung der RAM-Bausteine und > Refresh und diesen Impedanzkram, und all die anderen lästigen Dinge die > DRAMs so mit sich bringen. Sie blendet den furchtbar umständlich zu > verwendenden DRAM als simpler adressierbaren Bereich ein. Was der > Prozessor damit tut, ist der MMU egal. Die Erklärung könnte aus Löwenzahn sein ... Fachlich nicht korrekt, aber nicht ganz falsch ;-) Damals zu C64 Zeiten war eine MMU tatsächlich sowas ... ^^
Mmhm schrieb: > Mampf unterwegs schrieb: >> Hat man nur physischen speicher müsste man ständig alles umkopieren, >> damit neuer zusammenhängender speicher frei wird, den man wieder >> allozieren kann... Jedes free oder delete sorgt für eine größere >> fragmentierung, die man nicht so einfach beheben kann. > > Das was du beschreibst, ist eine Eigenschaft des Betriebssystems. > Das hat mit einer MMU nichts zu tun. > > Eine MMU kümmer sich um die korrekte Ansteuerung der RAM-Bausteine und > Refresh und diesen Impedanzkram, und all die anderen lästigen Dinge die > DRAMs so mit sich bringen. Sie blendet den furchtbar umständlich zu > verwendenden DRAM als simpler adressierbaren Bereich ein. Was der > Prozessor damit tut, ist der MMU egal. > Genau. Was "Mampf" vermutlich MEINT, ist dass eine MMU den Working Set (also den tatsächlich gebrauchten Speicher) komprimieren kann (wobei er aber munter applikationsseitige Fragmentierung und OS seitiges Management in einen Topf wirft). Das geht aber nur dann, wenn die Applikation nur auf sehr wenige Blöcke des virtuellen Speichers faktisch zugreift. Der Swappingalgorithmus des OS kann dann den working set durch LRU etc. auf diese aktiven Seiten reduzieren. Das ist aber 1. für die Applikation komplett transparent, und 2. nur unter der Voraussetzung des kleinen Working sets ein Vorteil. Wenn die Prozesse ihren Speicher tatsächlich alle benutzen, dreht sich das Ganze ins Gegenteil um, und das OS swappt sich zu Tode. > Um die Allzierung von Blöcken da drin kümmert sich beim PC oder einem > Prozessorsystem das OS. > > Dort wird fragmentiert, wenn das nicht sauber gelöst ist. > Nein nein, die Fragmentierung ist einzig und Allein ein Problem der Applikation in ihrem virtuellen Adressbereich. Das Einzige hier zulässige Argument besteht darin, dass ein von Allen Prozessen geteilter Heap tendentiell eher fragmentiert wird als lokale Heaps (auch nicht immer, aber im Grossen und Ganzen stimmt das Argument schon). Für solche Sachen gibt es aber Heap Pools. > µCs ohne OS haben damit sowieso so ihre Probleme. Ja, man kann einen > Heap deklarieren und malloc verwendet. Da sollte man aber sehr sauber > arbeiten. > > Noch ein Argument für Linux :-) Nein, eher dagegen. Magst Du mal auf mein vorher angeführtes Argument bzgl. der starken Verzahnung der Tasks in einem Embedded System eingehen? Es ist z.B. in Embedded sehr häufig der Fall, dass Speicher von einer task angefordert, aber von einer Anderen task verarbeitet und wieder befreit wird. Man kann das als schlechtes Design ansehen, muss dann aber eine bessere Variante anbringen. Linux etc. sind halt dafür gedacht, dass unabhängig voneinander agierende tasks gegeneinander geschützt sind. Das macht auch Sinn, denn ich will NICHT, dass ein schlecht geschriebenes Mailfrontend mir auch noch meinen Texteditor zerschiesst, wenn es stirbt. Das ist aber eine völlig andere Problemstellung als ein autarkes Embedded System, indem alle Komponenten miteinander agieren müssen!
Mmhm schrieb: > Besser noch: Man will eine RTCC an I2C ansprechen? Ein Klax, verglichen > mit dem STM32. Das ist ein einziger Eintrag in den Devicetree. Den Rest > erledigt der Linux-Treiber. > > UART? Kein Problem. Macht der Linux-Treiber. Dito SPI. das setzt vorraus das du einen prozessor nutzt wo sich jemand schon die mühe gemacht hat und ein passendes BSP geschrieben und dafür passende peripherietreiber vorliegen schnapp dir mal einen china Cortex A8/A9 ... ^^ wenn du glück hast funktioniert das linux und kann sogar ein terminal wenn man dieses SW konstrukt so vorbereitet ... läuft das auch 0815 mit einem STM, ATMEL , NXP .... blah wenn man zB STMcube nutzt gibts RTOS , LwIP , TLS und FAT fix und foxi ebenso diverse USB device und Hostbeispiele 10x klicken und das läuft vom prinzip erstmal Mmhm schrieb: > EMMC? > PCI-Express? SATA? MIPI?... sind das schnittstellen die man auf kleinst embedded systemen brauch? wichtig ist hierbei immernoch ... die Anwendung!! wenn ich ein 10" TFT mit multitouch fullHD und H264 videos betreiben will kommt KEIN halbwegs inteligenter Mensch auf die idee einen 8bit ATMEL oder sogar einen M4/M7 zu nehmen. ich lasse einen M7 mit HTTP(s) + VoIP + Video laufen ... macht er , gut sogar Mmhm schrieb: > Eine MMU kümmer sich um die korrekte Ansteuerung der RAM-Bausteine und > Refresh und diesen Impedanzkram, und all die anderen lästigen Dinge die > DRAMs so mit sich bringen. Sie blendet den furchtbar umständlich zu > verwendenden DRAM als simpler adressierbaren Bereich ein. Was der > Prozessor damit tut, ist der MMU egal. das mit dem RAM macht NICHT die MMU ... https://de.wikipedia.org/wiki/Memory_Management_Unit
Mmhm schrieb: > Eine MMU kümmer sich um die korrekte Ansteuerung der RAM-Bausteine und > Refresh und diesen Impedanzkram, und all die anderen lästigen Dinge die > DRAMs so mit sich bringen. Du verwechselst "Memory Controller" und "Memory Management Unit".
Markus schrieb: > Hat das eigentlich ne MMU? Glaub nicht, das ist ucLinux ... Mittlerweile wird das STM32F429 Discovery Board sogar vom Main-Line-Kernel unterstützt! Theoretisch sollte das sogar auf meinem DIY-Board laufen ... Hatte extra obacht gegeben, dass das Ding dann Linux-kompatibel ist (=STM32F429-Discovery-kompatibel). Also kein Grund mehr, ein extra ucLinux sich zu besorgen, das seit Jahren nicht mehr gepflegt wurde.
:
Bearbeitet durch User
Mampf F. schrieb: > Markus schrieb: >> Hat das eigentlich ne MMU? > > Glaub nicht, das ist ucLinux ... > > Mittlerweile wird das STM32F429 Discovery Board sogar vom > Main-Line-Kernel unterstützt! > Quelle? Die M Cores haben per Definition keine MMU, aber Mainstream Linux setzt zwingend eine MMU voraus???
Ich muss mich hier kurz einklinken. Was soll diese ganze Diskussion eigentlich? Hier wird doch jetzt nicht wirklich von einigen Leuten diskutiert, ob eine CPU AUS EINEM PERSONAL COMPUTER bessere, schnellere und mehr Schnittstellen als ein ARM Cortex M4 hat???? Und dann noch das Argument bringen dass man viel teurer käme, wenn man so viele M4s kauft damit man auf die gleiche Leistung/Rechenpower kommt wie mit einer CPU. Ha! Mein Ferari ist viel schneller als dein Polo, und du bräuchtest mindestens 10 Stück von denen, damit du die gleiche Leistung hast wie ich... Das wäre ja viel teurer.... Du Idiot. Ihr solltet lieber über die Sinnhaftigkeit dieser Diskussion diskutieren.
>Bare Metal Raspi: >https://github.com/rsta2/circle Das Ding scheint super. So was suche ich schon länger. Könnte man glatt einen Arduino draus machen.
HÄ??? schrieb: > Die M Cores haben per Definition keine MMU, aber Mainstream Linux setzt > zwingend eine MMU voraus??? Das war mal so. Während Linux eine MMU voraussetzt, unterstützte ucLinux MMU-lose Systeme. Inzwischen ist diese Unterstützung als "CONFIG_MMU=n" in den Mainline-Kernel gewandert.
Mampf F. schrieb: > Ein haufen new und delete würden ratzefatz den Speicher fragmentieren > und ihn auffressen. Eine unsinnige Mär, die sich aber offensichtlich sehr hartnäckig hält. Gegenbeispiel: new/delete mit stets gleicher Objektgröße erzeugen gar keine Fragmentierung, da die freigegebenen Bereiche immer sofort wiederbenutzbar sind. Zwischen diesem Fall und dem pathologischen Fall, dass jede Allozierung so komplett anders ist, dass sie nicht von zuvor freigegebenen Stücken abgedeckt werden kann, sind alle Varianten möglich; das hängt einfach vom Anforderungsmuster der Anwendung ab. Ist das Anwendungsmuster hinreichend gut statistisch verteilt, dann kannst du davon ausgehen, dass sich das System auf Dauer auf einem bestimmten Maß an Speichernutzung „einschwingt“. Eine Applikation mit dynamischem Datenanfall (nur dort haben solche Sachen ja auch wirklich Sinn) muss natürlich immer mit dem Zustand irgendwie umgehen können, dass mehr Anforderung aufkommt, als an Ressourcen zur Verfügung stehen, und muss dann in ihrem Rahmen sinnvoll reagieren können. Dabei ist es völlig unerheblich, wie der Speicher nun aufgeteilt wird: ein festes, zur Compilezeit vorgegebenes Array für die Daten kann genauso gut nicht ausreichen wie der Speicher bei new/delete zu sehr fragmentiert sein kann, um die Anforderung zu erfüllen. Dass das alles mit einer MMU nur sehr bedingt was zu tun hat, haben ja andere schon geschrieben. Diese verwaltet den Speicher in so großen Blöcken, dass das allein keinen Algorithmus ähnlich malloc() ersetzen kann (nur ergänzen).
:
Bearbeitet durch Moderator
Mampf F. schrieb: > Ähm, jein ... Ja, die Speicherverwaltung macht das OS ... Aber der > "Virtual Memory" muss von der Hardware unterstützt sein. Das hangeln > durch den TLB zB wäre softwaremäßig ein unzumutbarer Overhead ... In der Anfangsphase der RISC Prozessoren gab es welche, die den Table Walk in Software durchführten. Nur der TLB war in Hardware vorhanden, gefüllt wurde er per Software. > Das Prinzip ist quasi gleich ... Von der VAX bis zum ARM gibt es nicht > wesentliche Unterschiede. Bei Segmentierung statt Paging schon, wie bei i286 oder Z8000.
Jörg W. schrieb: > Mampf F. schrieb: >> Ein haufen new und delete würden ratzefatz den Speicher fragmentieren >> und ihn auffressen. > > Eine unsinnige Mär, die sich aber offensichtlich sehr hartnäckig hält. > > Gegenbeispiel: new/delete mit stets gleicher Objektgröße erzeugen > gar keine Fragmentierung, da die freigegebenen Bereiche immer sofort > wiederbenutzbar sind. Das setzt voraus, dass du eine Funktion implementiert hast, die Speicherbereiche nach einem free/delete wiederverwendet ... Im Rahmen eines OS ist das eine Selbstverständlichkeit ... Aber bare-metal? Die "Standard"-Implementierungen von _sbrk machen das alle nicht ...
Mampf F. schrieb: > Das setzt voraus, dass du eine Funktion implementiert hast, die > Speicherbereiche nach einem free/delete wiederverwendet ... Habe ich: für die avr-libc. > Im Rahmen eines OS ist das eine Selbstverständlichkeit ... Aber > bare-metal? s.o. > Die "Standard"-Implementierungen von _sbrk machen das alle nicht ... Ist ja auch nicht die Aufgabe von sbrk(), sondern von malloc(). sbrk() wird von diesem nur gerufen, wenn es einen neuen Speicherblock vom Betriebssystem braucht. Der Rest war und ist ohnehin eine Angelegenheit der Bibliothek, egal, ob du da nun Linux oder was anderes hast. Klar könnte man mit sbrk() auch Speicher zurückgeben, aber das ist für die Fragmentierung erstmal eher unerheblich. Bei bare metal spielt das sowieso keine so große Geige, denn der damit freigegebene Speicher kann von niemandem anders genutzt werden. (Dafür bräuchte es mehrere Prozesse oder zumindest Threads.)
Jörg W. schrieb: > Bei bare metal spielt das sowieso keine so große Geige, denn der damit > freigegebene Speicher kann von niemandem anders genutzt werden. Ergänzung: der Stack kann ihn natürlich nutzen. Bei fehlender MMU macht er das aber sowieso, ganz ungefragt, egal ob sbrk() ihn nun „offiziell“ freigegeben hat oder nicht. ;-)
S. R. schrieb: > Das war mal so. Während Linux eine MMU voraussetzt, unterstützte ucLinux > MMU-lose Systeme. Inzwischen ist diese Unterstützung als "CONFIG_MMU=n" > in den Mainline-Kernel gewandert. ...und wird weiterhin von den Jungs gepflegt, die damals uCLinux entwickelt haben, in der Hauptsache Geert Uytterhoeven und Greg Ungerer. Nur Arcturus ist ziemlich raus.
:
Bearbeitet durch User
tzhgfhgrhzfghz6453454353453534534533453453 schrieb: > schnapp dir mal einen china Cortex A8/A9 ... ^^ wenn du glück hast > funktioniert das linux und kann sogar ein terminal Womit werden die denn üblicherweise genutzt, wenn nicht mit Linux? Sind alle Treiber für Windows CE? Die eigentliche Frage ist hier ja, ob es sich überhaupt lohnt sich noch mit Mikrocontroller und Low-Level Programmierung auseinander zu setzen, wenn die Cortex-A alles besser können und man mit Linux auch alles erreichen kann (insb. Echtzeit Fähigkeit).
RAc schrieb: > Es ist z.B. in Embedded sehr häufig der Fall, dass Speicher > von einer task angefordert, aber von einer Anderen task verarbeitet und > wieder befreit wird. > [...] > Linux etc. sind halt dafür gedacht, dass unabhängig voneinander > agierende tasks gegeneinander geschützt sind. Das was Du bei Embedded als "Tasks" beieichnest wäre unter Linux mehrere Threads eines einzigen Prozesses.
Dr. Sommer schrieb: > Die eigentliche Frage ist hier ja, ob es sich überhaupt lohnt sich noch > mit Mikrocontroller und Low-Level Programmierung auseinander zu setzen, > wenn die Cortex-A alles besser können und man mit Linux auch alles > erreichen kann (insb. Echtzeit Fähigkeit). Booten in 20ms (z.B. nach WD-Reset)? Speicherverbrauch? Lizenz? Und zur Echtzeitfähigkeit: für viele Anwendungen sind RTAI, RTLinux etc. mit ihren Taskwechseln bzw. Durchstechen von Interruptanfragen einfach viel zu langsam. Um nur einige Gründe zu nennen :-)
Chris D. schrieb: > Booten in 20ms (z.B. nach WD-Reset)? Eigentlich erstaunlich, dass es dafür noch keine Lösung gibt, so ala "fixes Layout in den RAM kopieren, Peripherie initialisieren und läuft". > Speicherverbrauch? Ist ja nicht mehr das große Problem bei den großen Cortex-A mit DDR-Speichercontroller. > Lizenz? Linux wird doch in vielen Closed-Source-Anwendungen genutzt... > Und zur Echtzeitfähigkeit: für viele Anwendungen sind RTAI, RTLinux etc. > mit ihren Taskwechseln bzw. Durchstechen von Interruptanfragen einfach > viel zu langsam. Nagut, immerhin ist man als uC-Experte noch nicht ganz abgeschafft ;-)
Chris D. schrieb: > Lizenz? Gibt ja noch mehr als Linux. ;-) Aber ich bin da ansonsten voll auf deiner (Argumentations-)Seite.
Hans im Glück schrieb: > Chris D. schrieb: >> Booten in 20ms (z.B. nach WD-Reset)? > Eigentlich erstaunlich, dass es dafür noch keine Lösung gibt, so ala > "fixes Layout in den RAM kopieren, Peripherie initialisieren und läuft". Ja, das wundert mich auch - sollte eigentlich recht einfach realisierbar sein. >> Speicherverbrauch? > Ist ja nicht mehr das große Problem bei den großen Cortex-A mit > DDR-Speichercontroller. Ja, aber wenn es bspw. zuverlässig und energiesparend sein soll, dann ist jeder externe Chip zu viel. Und wenn es dann in die Stückzahl geht, wird auch der Preis für Speicher interessant. >> Lizenz? > Linux wird doch in vielen Closed-Source-Anwendungen genutzt... Ja, wobei das im Zweifelsfall eben auch nach hinten losgehen kann, wenn bspw. im Kernel Anpassungen vorgenommen werden müssen. >> Und zur Echtzeitfähigkeit: für viele Anwendungen sind RTAI, RTLinux etc. >> mit ihren Taskwechseln bzw. Durchstechen von Interruptanfragen einfach >> viel zu langsam. > Nagut, immerhin ist man als uC-Experte noch nicht ganz abgeschafft ;-) ;-)
Hans im Glück schrieb: >> Booten in 20ms (z.B. nach WD-Reset)? > Eigentlich erstaunlich, dass es dafür noch keine Lösung gibt, so ala > "fixes Layout in den RAM kopieren, Peripherie initialisieren und läuft". Wäre ein Problem für ASLR.
In dem Kontext fällt mir noch was ein: Bernd K. schrieb: > Das was Du bei Embedded als "Tasks" beieichnest wäre unter Linux mehrere > Threads eines einzigen Prozesses. Warum eigentlich wird (im Kontext Linux/RTOS) so oft von Tasks/Threads geredet (und damit vermutlich auch gearbeitet)? Der Fall, dass man tatsächlich mehrere Rechenleistungs-Hungrige Aufgaben hat, ist doch im Embedded Bereich eher selten. Warum sich da die Mühe mit der Synchronisation mehrerer Threads machen, wenn man auch alle Ereignisse schön sequentiell abarbeiten könnte?
S. R. schrieb: > Hans im Glück schrieb: >>> Booten in 20ms (z.B. nach WD-Reset)? >> Eigentlich erstaunlich, dass es dafür noch keine Lösung gibt, so ala >> "fixes Layout in den RAM kopieren, Peripherie initialisieren und läuft". > > Wäre ein Problem für ASLR. Was einen zum nächsten Grund bringt, Linux (oder FreeBSD ;-) nicht zu verwenden: mit der Größe des Codes steigt einfach auch die Angreifbarkeit/Fehleranfälligkeit.
Chris D. schrieb: > Ja, das wundert mich auch - sollte eigentlich recht einfach realisierbar > sein Ein komplettes Linux System in den hybernate Modus legen ist nicht ohne, Timesys hat es geschafft zuerst auf dem sama5 Man kann.sich die boot Performance auf youtube anschauen einfach nach timesys sama5 fastboot suchen Übrigens die sama5 lassen sich super einfach zb in iar programmieren, auf der embedded wurde für juli ein SIP angekündigt der sogar ein 1Gbit Speicher im Package haben soll, damit wird auch das layout auf eine 4Layer pcb passen. Nur noch Flash Speicher soviel man will anschliessen und fertig, man hat eine neue Dimension an Performance sogar gegenüber einem same70 mit.300mhz.
Dr. Sommer schrieb: > In dem Kontext fällt mir noch was ein: > > Bernd K. schrieb: >> Das was Du bei Embedded als "Tasks" beieichnest wäre unter Linux mehrere >> Threads eines einzigen Prozesses. > > Warum eigentlich wird (im Kontext Linux/RTOS) so oft von Tasks/Threads > geredet (und damit vermutlich auch gearbeitet)? Der Fall, dass man > tatsächlich mehrere Rechenleistungs-Hungrige Aufgaben hat, ist doch im > Embedded Bereich eher selten. Warum sich da die Mühe mit der > Synchronisation mehrerer Threads machen, wenn man auch alle Ereignisse > schön sequentiell abarbeiten könnte? Es geht dabei nicht um die Rechenleistungshungrigkeit, sondern um die logische Trennung von nebenläufigen Tätigkeiten. Ich bin z.B. u.A. in der Zutrittskontrolle tätig und habe schon die Firmware für etliche Kartenleser entwickelt. Hier sind typischerweise folgende Aufgaben zu lösen: 1. Hostkommunikation (typischerweise über ein serielles Interface) 2. Karteninteraktion 3. Peripheriesteuerung (On Board LEDs, Relais etc) Sieht recht trivial aus, ist aber u.A. im hohen Masse asynchron. Glaub mir, zu versuchen all das in einer grossen Message Pump in main() zu lösen führt im Handumdrehen zu nicht mehr les- oder wartbarem Code. Hier tut man sich mit einem RTOS, das z.B. Intertaskkommunikation sowie ISR/Applikationskommunikation für Dich erledigt, um so viel leichter. Was nicht heissen soll, dass es nicht auch noch einen Platz für OS-lose Systeme gibt. Wo z.B. eine ziemlich pufferfreie 1:1 Pumpe zwischen Messfühlerdaten und einem Hostkomminterface zu realisieren ist, reicht eine ereignisgesteuerte main() message pump in der Regel aus. Allerdings wird es dort auch schon päp, wenn die Umlaufzeiten nicht genau synchron sind (also z.B. die Bestätigung seitens der Hostkommunikation mal so verzögert sein kann, dass zwischen zwei Kommunikationszyklen mehrere Messwerte anfallen, die gepuffert werden müssen). In Anbetracht der Tatsache, dass kleine RTOS sehr sehr wenig footprint- und Latenzkosten verursachen, kann man schon auf M0+ cores mit 128k Flash und 32K RAM komplette Leserfirmware einschliesslich RTOS implementieren. Ich diskutiere die Frage übrigens auch in meinem Buch (flöt träller).
RAc schrieb: > zu versuchen all das in einer grossen Message Pump in main() zu > lösen führt im Handumdrehen zu nicht mehr les- oder wartbarem Code. Das ist ja nicht die einzige Möglichkeit... Man kann die einzelnen Aufgaben ja z.B. in eigene Klassen schreiben, denen Member-Funktionen für die einzelnen Ereignisse verpassen, und diese von den Interrupts aus aufrufen. Die Klassen können dann untereinander Funktionen aufrufen und jeweils einen Completion-Handler übergeben (bzw. Observer-Pattern), der dann bei asynchroner Fertigstellung aufgerufen wird. So ist alles sauber getrennt und man braucht keine Threads und -Synchronisation.
Bernd K. schrieb: > RAc schrieb: >> Es ist z.B. in Embedded sehr häufig der Fall, dass Speicher >> von einer task angefordert, aber von einer Anderen task verarbeitet und >> wieder befreit wird. >> [...] >> Linux etc. sind halt dafür gedacht, dass unabhängig voneinander >> agierende tasks gegeneinander geschützt sind. > > Das was Du bei Embedded als "Tasks" beieichnest wäre unter Linux mehrere > Threads eines einzigen Prozesses. Richtig, aber der Auslöser war ja die Bemerkung, dass MMU und virtuelle Speicherbereiche einen Vorteil bei der Speicherverwaltung und Fragmentierungsproblemen bringen würden. Aber da ja virtuelle Speicherbereiche nur zwischen "echten" Prozessen realisiert sind, hatte ich den Faden einfach mal weitergesponnen. Rein logisch hast Du natürlich vollkommen recht; eine typische Embedded FW ist konzeptuell so wie eine Linux Applikation mit mehreren threads. Ich warte noch auf ein Embedded Linux, das das gesamte System auf eine einzige Applikation zusammenstreicht (in der dann natürlich mehrere threads erzeugt werden können). Damit würden footprint und Bootzeiten enorm reduziert werden... ;-)
Dr. Sommer schrieb: > RAc schrieb: >> zu versuchen all das in einer grossen Message Pump in main() zu >> lösen führt im Handumdrehen zu nicht mehr les- oder wartbarem Code. > > Das ist ja nicht die einzige Möglichkeit... Man kann die einzelnen > Aufgaben ja z.B. in eigene Klassen schreiben, denen Member-Funktionen > für die einzelnen Ereignisse verpassen, und diese von den Interrupts aus > aufrufen. Die Klassen können dann untereinander Funktionen aufrufen und > jeweils einen Completion-Handler übergeben (bzw. Observer-Pattern), der > dann bei asynchroner Fertigstellung aufgerufen wird. Ist ein interessanter Ansatz, müsste ich mir mal genauer ansehen, Danke. Allerdings stösst Du m.M. nach damit dann an Grenzen, wenn Ereignisse dazu kommen, die nicht mehr direkt von der HW aus gesteuert werden (wie würdest Du damit z.B. "Hintergrundtasks" abhandeln, die Messwerte von mehreren Fühlern aufbereiten und verknüpfen, bevor sie an die Kommunikation weitergereicht werden? Vor Allem wenn mehrere solcher Aktivitäten nebenläufig abgehandelt werden müssen, vielleicht sogar mit varaiblen Prioritäten?) > So ist alles sauber > getrennt und man braucht keine Threads und -Synchronisation. Uhm... Synchronisation brauchst Du immer, sobald nebenläufige Ereignisstränge existieren (und wenn es auch "nur" ISRs sind, die asynchron und nebenläufig mit der "main loop" ablaufen). Ein System, in dem ausschliesslich ISRs aktiv sind, ist schwer ohne Interruptverlust vorstellbar (davon mal abgesehen, dass viele Prozessoren nicht Alles in einem ISR erlauben, was im thread mode möglich ist), und selbst da kann es ja passieren, dass ein ISR durch einen Anderen einer höheren Priorität unterbrochen wird. Oder fehlt mir da etwas? Trotzdem eine sehr interessante und fruchtbare Diskussion! :-)
RAc schrieb: > wie > würdest Du damit z.B. "Hintergrundtasks" abhandeln, die Messwerte von > mehreren Fühlern aufbereiten und verknüpfen, bevor sie an die > Kommunikation weitergereicht werden? z.B. mit einem Timer, oder man baut eine Ebene über die Treiber für die einzelnen Sensoren (für I²C,SPI,...), die per Callback den Empfang der Sensorwerte mitbekommt, und beim letzten eben die Auswertung durchführt. RAc schrieb: > Vor Allem wenn mehrere solcher > Aktivitäten nebenläufig abgehandelt werden müssen, vielleicht sogar mit > varaiblen Prioritäten?) Man setzt dann entsprechend die Priorität des Timer/Sensor-Interrupts. RAc schrieb: > Uhm... Synchronisation brauchst Du immer, sobald nebenläufige > Ereignisstränge existieren (und wenn es auch "nur" ISRs sind, die > asynchron und nebenläufig mit der "main loop" ablaufen). Ja, aber die ist viel einfacher, weil die einzelnen Abläufe nicht einfach "irgendwo" unterbrochen werden können und man somit alle möglichen Fälle bei der Synchronisation mit Mutexen o.ä. abdecken muss, sondern man sich darauf verlassen kann dass die vorige Abarbeitung in der jeweiligen ISR vollständig abgeschlossen ist und die Daten somit in konsistentem Zustand sind. RAc schrieb: > Ein System, in > dem ausschliesslich ISRs aktiv sind, ist schwer ohne Interruptverlust > vorstellbar Ein System das so überlastet ist dass es nicht mehr alles beantworten kann, würde auch mit einem RTOS & Threads nicht mehr alles beantworten können... RAc schrieb: > und selbst da kann > es ja passieren, dass ein ISR durch einen Anderen einer höheren > Priorität unterbrochen wird. Ja, man muss die Prioritäten so einstellen dass sich nur ISR's gegenseitig unterbrechen können, welche nicht auf die gleichen Daten zugreifen. Ansonsten müsste man mit Interruptsperren arbeiten (hässlich)... RAc schrieb: > Trotzdem eine sehr interessante und fruchtbare Diskussion! :-) Tjo... Dass sich quasi die gesamte Betriebssystemtheorie und auch die meisten Embedded-Programme auf synchrone Programmierung (mit und ohne Threads) stützt irritiert mich etwas.
> Trotzdem eine sehr interessante und fruchtbare Diskussion! :-) ja, eine furchtbare Diskussion. Aus dem Loblied zu der Leistung des F4 mit FPU ist die nutzlose Diskussion über das beste OS für Embedded geworden. Anscheinend ist nur Linux ein richtiges OS, weswegen z.B. RTOS, das von allen embedded CPU Herstellern unterstützt wird nicht mal Erwähnung findet. ARM-A Serie und Linux und ARM-M und RTOS ist die OS-Hose, die passt. Aber um die Diskussion abzurunden, Raspi-3 + Windows10 IoT ist doch das einzig wahre, oder ? Der meist verkaufte Embedded Computer mit dem meist verkaufen OS. Wenn wir in diesem Thread die Lösung gefunden haben, dann sollten wir dringend anschliessend auch noch die anderen seit Jahren schwelenden Fragen lösen: Windows oder Linux ? Atari oder Amiga ? Z80 oder MOS6502 ? Gamepad oder Maus+Keyboard ? Atmel oder Microchip ? AMD oder Intel ? AMD oder NVidia ? XBox oder Playstation ? Welche CPU zum Einstieg in embedded ? Welche Programmiersprachen ist die Beste ? Nusspli oder Nutella ? Warum haben Themen wie diese so viele Teilnehmer und andere Fragen werden kaum beachtet ? Oder sind das nur Phrasendrescher-Bots, die Klicks generieren für die Werbebanner ?
Äpfel und Birnen schrieb: > Atmel oder Microchip ? Du musst mit der Zeit gehen! (Und Du plenkst) SCNR
Ein wichtiger Bestandteil der Ingenieursarbeit ist nunmal die Auswahl geeigneter Technologie. Und da die Lösung meistens keineswegs klar ist, kann man da schon mal drüber diskutieren.
Fachsimpeln ist nicht zielsuchend, sondern Reden des Selbstzwecks wegen.
Äpfel und Birnen schrieb: > Windows oder Linux ? Ich arbeite seit fast 20 Jahren mit Linux, nur beruflich mit Windows. Seit Windows 10 steht die Entscheidung: Linux :-) > Atari oder Amiga ? Keiner mehr. Auch wenn hier noch ein Amiga steht, welcher regelmäßig in Betrieb ist. (M68060, 50MHz, 160MB RAM, 2x SCSI, 1+2GB HDD, 2 CD-Brenner, Picasso 4MB Grafikkarte, A2232 7x RS232 Karte, Ariadne Netzwerk) > Z80 oder MOS6502 ? Vermutlich Z80 > Gamepad oder Maus+Keyboard ? Schnellschreiber werden mit einem Gamepad bestimmt nicht glücklich - die brauchen Klick. > Atmel oder Microchip ? 8051 vielleicht von ExAtmel und MIPS von Microchip. > AMD oder Intel ? Wenn ein Chipsatz von Intel dafür existiert, gerne auch AMD. > AMD oder NVidia ? Egal. > XBox oder Playstation ? Würfel. > Welche CPU zum Einstieg in embedded ? Bo8 **hust* > Welche Programmiersprachen ist die Beste ? Brainfuck > Nusspli oder Nutella ? Majonaise. Opel Manta oder Ford Capri? > Warum haben Themen wie diese so viele Teilnehmer und > andere Fragen werden kaum beachtet ? Es ist das Herz ... :-D Gruß Jobst
Lothar schrieb: > RiscOS pico für Pi bootet in <1sec und passt in 4MB Flash Das ist schön für RiscOS :-) NuttX bootet noch deutlich schneller. Aber es ging um Linux.
Dachte es geht um günstige FPU als uC Ersatz. RiscOS unterstützt sogar im BASIC Interpreter VFP und auch NEON die Demos sind auf einem 1 Core ARM11 wesentlich schneller als unter Raspbian mit 4 Core A53 mit C++ von Python gar nicht zu reden.
Ruediger A. schrieb: > Das ist in Embedded aber in der Regel nicht der Fall, weil alle Prozesse > (dort normalerweise tasks genannt) als Ganzes zusammen arbeiten müssen. > Wenn also z.B. in einem Zutrittskontrollsystem die Buchungstask "Mist > baut," dafür aber die Ausweis- und Kommunikationstasks weiter laufen > (weil eine MMU die Speicherbereiche gegeneinander abgrenzt), läuft das > System als Ganzes trotzdem nicht richtig. Ein Zutrittskontrollsystem ist eigentlich ein sehr gutes Beispiel dafür warum man gerne so eine Trennung haben möchte. Wenn ein böswilliger RFID-Transponder den Speicher des entsprechenden Tasks korrumpiert, dann sollte das möglichst keinen Einfluss auf den Task haben der die Tür aufschließt oder den der mit dem Firmennetzwerk kommuniziert. Ähnliches gilt für sämtliche IoT-Anwendungen und jede andere Anwendung die mit externen, potentiell böswilligen Geräten kommuniziert.
Da hast du Recht. freedom from interference kann man aber auch ohne ein os und ohne Prozessor mit mmu erreichen. Sinnvolles platzieren des stacks, Prüfung von stacküberlauf und nicht zuletzt eine MPU sind private Mittel.
> Embedded Bereich eher selten. Warum sich da die Mühe mit der > Synchronisation mehrerer Threads machen, wenn man auch alle Ereignisse > schön sequentiell abarbeiten könnte? Zusaetzlich zum schon genannten sei noch erwaehnten das an Embeddedsoftware heute durchaus Teams von 20-30Leuten arbeiten koennen. Ausserdem werden Teile der Software auch gerne in verschiedenen Geraeten verwendet. Da erleichtern Threads die Aufteilung der Arbeit und es bleibt fuer den einzelnen durchschaubarer. Olaf
wer einem Embedded System "Sicherheit" abspricht, der muss aber mir aber auch erklären, warum sowohl Win und Linux/Android auf einer ach so ausgefeilter Hardware wie einem PC so gut wie ungeschützt gegen die täglich auftretenden Sicherhitslücken sind. Admin/Root Rechte zu bekommen scheint so gut wie immer möglich, wenn der PC nur am I-Net hängt. Manchmal hege ich den Eindruck, die vernetzten Systeme hben zu viel RAM/CPU Leistung, so das immer noch Platz für eine Backdoor/Virus ist. Wer findet in den Terabyte Weiten der HDD noch den Schadcode von 2 kB oder den Task für den Keylogger auf einem 8-Core Handy ? In einem ATtiny13 oder PIC16F887 würde Schadcode auffallen wie ein bunter Hund, in den Codemonstern eines PCs/ARM-A nicht mal als Rauschen auffallen, wenn er denn keinen Schaden anrichten würde.
Äpfel und Birnen schrieb: > wer einem Embedded System "Sicherheit" abspricht, der muss aber mir aber > auch erklären, warum sowohl Win und Linux/Android auf einer ach so > ausgefeilter Hardware wie einem PC so gut wie ungeschützt gegen die > täglich auftretenden Sicherhitslücken sind. Bezogen auf vernetzte Geräte: Updates. Wie oft werden Embedded Systems gefixed? > Admin/Root Rechte zu > bekommen scheint so gut wie immer möglich, wenn der PC nur am I-Net > hängt. Es ist immer möglich, aber fast alle derartigen Löcher sind noch unbekannt, zumindest ausserhalb von NSA&Co. Sobald sie bekannt werden, werden aktuelle Win/Linux Distributionen recht schnell gefixed, zumindest was die von aussen angreifbaren Löcher angeht. Zum Problem werden hauptsächlich Geräte, die aus diversen Gründen nicht auf Stand gehalten werden. Ein ernstes Problem ist Android. Die Update-Zyklen von anderen Geräten als Googles Nexus/Pixel sind nach wie vor hundsmiserabel. > In einem ATtiny13 oder PIC16F887 würde Schadcode auffallen Ein ATtiny13 ist typischerweise nicht vernetzt.
:
Bearbeitet durch User
Es kann auch sinnvoll sein, vernetzte Geräte intern zu trennen. Also statt sich auf Betriebssysteme, getrennte Prozesse und MMUs zu verlassen, kann es empfehlenswert sein, die für den Betrieb kritischen Grundfunktionen in einen µC wie AVR/Cortex-M/... zu brennen und die Vernetzung in einem separaten System durchzuführen. Mit auf das minimal notwendige Mass reduzierten und inhaltlich wie funktionell kontrollierten Schnittstellen dazwischen. Das hat neben möglichen Löchern aufgrund komplexer Betriebssysteme auch den Vorteil, dass das äussere System wesentlich weniger stringent getestet werden muss und somit Updates davon einfacher und schneller möglich sind. So lange das Kernsystem unverändert bleibt. Für das äussere System kann man dann auf komplexe Systeme der RasPi-Klasse setzen und damit an Interface-Funktionalität gewinnen, ohne das Gesamtsystem zu riskieren.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.