Cortex-M4 + 2 * Cortex-A7 + Vivante GPU. Für die Vivante-GPUs gibt es Opensource Treiber. https://www.heise.de/newsticker/meldung/STM32MP1-ARM-Kombiprozessor-von-STMicroelectronics-4313997.html
Cortex schrieb: > https://www.heise.de/newsticker/meldung/STM32MP1-ARM-Kombiprozessor-von-STMicroelectronics-4313997.html Klingt für mich erstmal interessant aber ich mag schon den Namen OpenSTLinux nicht. Das hört sich für mich wieder sehr nach Vendor-Lockin an. Harry L. schrieb: >> Cortex schrieb: >> Für die Vivante-GPUs gibt es Opensource Treiber. > > Wo steht das? Vivante hat einen zweigeteilten Treiber. Der Teil im Kernel-Space ist Open-Source und der (größere bzw. wichtigere) Teil im User-Space ist Closed-Source: https://en.m.wikipedia.org/wiki/Free_and_open-source_graphics_device_driver Es gibt auch eine reverseengineerete Variante des User-Space Treibers, welche quelloffen ist: https://github.com/etnaviv/etna_viv
Harry L. schrieb: > Wo steht das? Das Librem 5 verwendet genau aus diesem Grund einen i.MX 8 als SOC weil dieser eine opensource fähige Vivante-GPU verbaut hat.
Christopher J. schrieb: > Klingt für mich erstmal interessant aber ich mag schon den Namen > OpenSTLinux nicht. Das hört sich für mich wieder sehr nach Vendor-Lockin > an. ST sagt mainline: "STM32CubeMP1 and full mainline open-source Linux® STM32 MPU OpenSTLinux Distribution (such as STM32MP1Starter) software and examples" -> https://www.st.com/en/evaluation-tools/stm32mp157a-dk1.html
Hmm, mal schauen ob ST mit dieser Serie Erfolg haben wird. Es ist die selbe Klasse, die NXP mit den i.MX-Serien und TI mit den Sitaras adressiert. Nachteil solche Dinger einzusetzen sehe ich vor allem in Kosten+Zeit+Risiko ein Layout in Finepitch-BGA mit DRAM-Anbindung zu erstellen und zu qualifizieren. ST hat es bei den STM32 im Griff hunderte verschiedene Varianten herzustellen. Da könnten die doch die SoCs gleich mit integriertem DRAM herstellen. Also ein Prozessor-Die und ein DRAM-Die, welche dann von denen zusammengebonded werden. Davon gibt es dann Varianten mit 256 MB RAM, 512 MB RAM, 1 GB RAM etc. Dann spart man sich den Aufwand das RAM auf der Platine anzubinden und das Layout wird gleich auch kompakter. Sowas gibt es in wenigen Ausführen schon bei NXP und bei TI (von Octavo Systems), aber da gibt es keine Flexibilität bei den RAM-Größen.
Gerd E. schrieb: > Nachteil solche Dinger einzusetzen sehe ich vor allem in > Kosten+Zeit+Risiko ein Layout in Finepitch-BGA mit DRAM-Anbindung zu > erstellen und zu qualifizieren. Sehe ich auch so aber es gibt ja mehr als genug Produzenten wie etwa Phytec oder Olimex für die BGA kein Problem ist und bei denen man sich dann ein SoM kaufen kann. Das ist ja bei TI und NXP auch nicht anders, von Octavo Systems mal abgesehen. Gerd E. schrieb: > ST hat es bei den STM32 im Griff hunderte verschiedene Varianten > herzustellen. Da könnten die doch die SoCs gleich mit integriertem DRAM > herstellen. Also ein Prozessor-Die und ein DRAM-Die, welche dann von > denen zusammengebonded werden. Das wäre für kleinere Stückzahlen sicher interessant aber die Frage ist ob ST das auch wirtschaftlich interessant findet.
Gerd E. schrieb: > Nachteil solche Dinger einzusetzen sehe ich vor allem in > Kosten+Zeit+Risiko ein Layout in Finepitch-BGA mit DRAM-Anbindung zu > erstellen und zu qualifizieren. Das ist aber bei allen Systemen dieser Art so. Wenn man die Leistung braucht, muss man da eben den Speicher unterbringen. Ob jetzt in Form eines Moduls wie bei Octavo oder auf einem Custom PCB. RAM und CPU auf einem Chip unterzubringen ist halt nicht so einfach.
Dr. Sommer schrieb: > Das ist aber bei allen Systemen dieser Art so. Das heißt aber nicht, daß man es nicht besser machen und damit einen Vorteil am Markt bekommen könnte. Vor allem wenn man wie ST neu in diesem Marktbereich ist. Ein müdes "mee too" mit einem zuerst mal überschaubarem Portfolio reißt da bekanntlich niemanden vom Hocker. > RAM und CPU auf > einem Chip unterzubringen ist halt nicht so einfach. Ich muß zugeben, daß ich mich im Bereich Chipfertigung nicht so gut auskenne. Wo ist da jetzt genau das Problem? Entweder packe ich die Dies nebeneinander, so wie es jetzt z.B. AMD bei den neuen Epycs macht oder ich glaube Mediatek schon länger bei Prozessoren und Mobilfunk-ICs macht, die so zusammen in ein Gehäuse gepackt werden. Nachteil ist, daß ich etwas mehr Fläche brauche um beides nebeneinander unterzubringen. Hätte aber gleich auch den Vorteil von etwas gröberem BGA-Pitch, was mir hinterher das Fanout vereinfacht und die Produktion verbilligt. Man darf es natürlich nicht übertreiben, größer als vielleicht 20x20 sollte es nicht werden. Oder ich packe die Dies übereinander. Broadcom hat z.B. bei den SoCs für den RasPi ja dieses Package-on-Package. Das braucht natürlich in der Fertigung der Platine spezielle Maschinen, das will man daher eigentlich nicht. Aber statt der Fläche für die Balls oben auf dem Gehäuse, könnte man da sicher auch gleich das RAM draufbonden. Das dürfte vermutlich nen Tick teurer in der Fertigung sein. Beide Varianten sparen mir als Gerätehersteller aber einiges bei den Entwicklungs- und vermutlich auch Fertigungskosten.
Gerd E. schrieb: > Vor allem wenn man wie ST neu in diesem Marktbereich ist. Ein müdes "mee > too" mit einem zuerst mal überschaubarem Portfolio reißt da bekanntlich > niemanden vom Hocker. Welche linuxtauglichen Chips mit einer GPU die mainline unterstützt wird und einem µc drin gibt es den noch? Mir ist da nichts bekannt.
Gerd E. schrieb: > Vor allem wenn man wie ST neu in diesem Marktbereich ist. Ein müdes "mee > too" mit einem zuerst mal überschaubarem Portfolio reißt da bekanntlich > niemanden vom Hocker. Ich vermute mal das sie den Markt schon gut abgeklopft haben und potentielle Kunden schon gesagt haben was sie gerne hätten. So wie das Ding aussieht könnte ich mir gut vorstellen, dass das zukünftig viel in weißer Ware zu finden sein wird, wo die Stückzahlen aber auch hoch genug sind, so dass die sich um ein komplexeres PCB-Design keine sorgen machen und lieber den Chip für 50 Cent weniger nehmen bzw. flexibler in der Ausstattung mit RAM sind. Mich würde (für persönliche Basteleien) mal interessieren in wie weit der Cortex-M Zugriff auf den DDR-RAM hat. Laut Busmatrix aus dem Datenblatt sollte es jedenfalls gehen. Gerade für messtechnische Anwendungen ist das genial wenn der (niedriglatente) uC Daten per DMA in einen großen Buffer schreiben kann und ein dickerer Applikationsprozessor diese dann weiterverarbeiten kann. Bei den Sitara von TI ist es jedenfalls möglich, was ja erst die Verwendung eines Beaglebone als Logic-Analyzer sinnvoll möglich macht aber ich habe mich mit den PRUs nicht so wirklich im Detail auseinandergesetzt, weil mir das alles etwas zu sehr TI-spezifisch ist. Da Begrüße ich es, dass als Coprozessor ein Cortex-M4 drin steckt. Von daher sehe ich das mit dem "me too" auch nicht so eng, weil der einzige mir bisher bekannte Hersteller solcher Cortex-M+Cortex-A Kombis bisher NXP ist (von Apple mal abgesehen). Masser schrieb: > Welche linuxtauglichen Chips mit einer GPU die mainline unterstützt wird > und einem µc drin gibt es den noch? Das sind die i.mx 7 von NXP Edit: Sorry, die haben keine GPU. i.mx8 sollte eine haben, ist aber mWn auch noch nicht verfügbar. Noch ein Nachtrag: TI hat mit den Sitara AM654 eine Combi aus Quad-Core Cortex-A53 und Cortex-R5F vorgestellt: https://www.cnx-software.com/2018/10/04/texas-instruments-am654-64-bit-arm-processor/ Ist aber auch noch nicht auf dem Markt und wohl eher was für Atom-U-Boote als für Waschmaschinen ;)
:
Bearbeitet durch User
Christopher J. schrieb: > Noch ein Nachtrag: TI hat mit den Sitara AM654 eine Combi aus Quad-Core > Cortex-A53 und Cortex-R5F vorgestellt: > https://www.cnx-software.com/2018/10/04/texas-instruments-am654-64-bit-arm-processor/ PowerVR hat nur Treiber Blobs.
Also Cortex-A mit RAM drauf gibts von ex Atmel: https://www.microchip.com/wwwproducts/en/ATSAMA5D27C-D1G Der STM klingt dank OpenSTLinux schonmal uninteressant. Entweder da läuft der Mainline Kernel drauf mit Debian/Arch rootFS oder GTFO!
Fürs Basteln vielleicht Debian/Arch rootfs. Für einen Serieneinsatz besser ein schlankes Yocto. Ti AM6 SOM gibt's anscheinend schon von Phytec. Mal schauen ob da auch der STM kommt...
Yocto ist doch keine Distri, sondern eine Toolsammlung um sich sein gewünschtes Linux zusammenzustöpseln?
Ja, hab ja nicht behauptet daß es eine Distribution ist. So wie du es geschrieben hattest, hatte ich gedacht du willst ein Debian wie beim RPi mit Paketmanager und allem auf dem Dingen haben. Interessant ist auch der Polarfire SOC von Microsemi. Bin mal gespannt was da so geht mit Microchip im Rücken...
:
Bearbeitet durch User
STM32CubeMX Version 5.1.0 unterstützt teilweise schon die Konfiguration des "Neuen". SW4STM32 compiliert das Ergebnis erfolgreich. Theoretisch blinkt schon eine imaginäre LED auf meinem imaginären $99 STM32MP157C-DK2 Board.
Auch sehr charmant: it is possible to map, at boot, almost all peripherals in the connectivity and analog units in the block diagram above to either the Cortex-M4 or the Cortex-A7 https://blog.st.com/stm32mp1-mpu-stm32mp157a-ev1-stm32mp157c-dk2/ Bleibt noch die Frage offen wie die verschiedenen Cortexe miteinander reden können.
Dirk schrieb: > Bleibt noch die Frage offen wie die verschiedenen Cortexe miteinander > reden können. Siehe Anhang; AHB-Bus und AXI-Interconnect sind asynchron miteinander verbunden.
Bevor auf Yocto und OpenSTLinux rumgehackt wird: Yocto ist ein "Distributionsbuilder" und eine Zusammenstellung aus OpenEmbedded, Bitbake und ein paar zusätzlichen Layern (Sammlungen von Programmrezepten). OpenEmbedded ist schon recht erwachsen, sehr gut dokumentiert (siehe Yocto Mega Manual), extrem aktiv (kommt aus der Richtung OpenZaurus, Dreambox, ...) und wird viel komerziell sowie auch im OpenSource bereich genutzt - bzw viel wichtiger, ist offiziell unter der Schirmherrschaft von der Linux Foundation. Es setzt sich langsam als Quasi-Standard für derartiges Gefrickel durch. Wir nutzen bei uns in der Firma Yocto mit Layern von Freescale/NXP MCUs. Distributionen bei Yocto sind eigentlich nur Konfigurationen, was aus Yocto (Versionen, ...) wie genutzt wird. Es ist relativ leicht, sich mit Yocto saubere, funktionierende Pakete und "Distributionen" für Hardware zu erstellen, für die es BSPs gibt. Das ist mir tatsächlich allemal lieber als der Distributionsbuilder von Debian oder Ubuntu. Yocto unterstützt ebenfalls Paketformate (RPM, opkg, ...), je nachdem, was man verwenden möchte. Und CrossCompiling möchte ich persönlich tatsächlich lieber in einem Yocto-Umfeld pflegen als mit Debian (ich maße mir mal an, das anzumerken, ich nutze Beides). Ich habe mir das OpenSTLinux am Freitag mal angeschaut und durchkompiliert. Auf den ersten Blick ist das sehr saubere Arbeit, was STM da veröffentlicht hat. Die genutzte Version von Yocto ist "thud", das ist die Aktuellste stable vom November (ca Halbjahres-Zyklus). Bis auf ein paar Custom-Scripte (um die Arbeit mit Yocto zu vereinfachen) ist das aber Alles nah am Yocto-Konzept. Die Integration des M4-Kerns über OpenAMP scheint auch recht sauber zu sein. Ich bastel mal eine Runde damit. Ich kenne natürlich nicht Alles auf dem Markt aber - bisher ist STM der erste Hersteller den ich kenne, der eine "Linux-MCU" auf den Markt bringt, wo die komplette Toolchain offen ist und ohne wildes Mainline-Vendor-Kernel forking auskommt. Und für mich als Frickler fühlt sich das STM32MP1 Kram sehr sehr gut an.
Bin eben über die EW gelaufen.. Und beim Phytec Stand hängt tatsächlich ein STM32MP1 Modul rum... Aber noch early Alpha..
Mw E. schrieb: > Der STM klingt dank OpenSTLinux schonmal uninteressant. > Entweder da läuft der Mainline Kernel drauf mit Debian/Arch rootFS oder > GTFO! Wenn ich nicht ganz irre, sind die ersten STM32MP157 Patches schon im März 2018 beim Linux Mainline sowie bei u-boot eingereicht worden und seitdem folgen stetig neue Patches. Laut Infos am Stand auf der EW2019 sind wohl bisher ca. 80% der Patches aufgenommen worden - ob das stimmt weiss ich nicht, da müsste ich mal schauen. Dass aber auf der LKML Patches dafür zu finden sind ist Fakt. Die Patches sind auch im Yocto-Layer zu finden. Es könnte also durchaus sein, dass der Mainline Kernel jetzt schon out of the Box laufen könnte. Die Frage ist - will man das, ergibt das Sinn? Womit vergleicht man das? Mit einem Raspberry? Äpfel und Birnen. Das ist die erste Generation von der Chipfamilie und auch kein Raspberry-PI Ersatz. Das Ding hat nen A7 + M4 in einem Gehäuse und bietet das, was der Raspberry z.B. nicht kann und was mir bisher gefehlt hat - echte uC-Fähigkeiten auf den GPIO's (wie z.B. Hardware-PWM etc). Spannend wird, was es neben dem offiziellen STM32MP157A-DK1 und STM32MP157C-DK2 längerfristig noch für Boards (für private Frickler/Maker) geben wird, die diese MCU nutzen. Das DK1 und DK2 wird vom Preis her schon für Maker eher uninteressant sein, da muss schon was von anderen Herstellern kommen. Beruflich finde ich das MP1-Konzept mit der Toolchain auf jeden Fall sehr spannend.
@Björn Kalkbrenner Danke fürs stöbern, das klingt ja dann doch echt vernünftig. Mit dem RasPI hab ich den STM jetzt aber nicht verglichen.
Johnny B. schrieb: > Siehe Anhang; AHB-Bus und AXI-Interconnect sind asynchron miteinander > verbunden. Bleibt die Frage wo sitzt die MMU die die Adressspaces der verschiedenen Cortexe voreinander schützt?
Die MMU sitzt zwischen Cortex-A und AXI. Der Cortex-M hat die bekannte MPU. Also voreinander schützen geht nur zweigeteilt in dem der Cortex-M4 per MPU gehindert wird in den Linuxadresspace reinzugrätschen. Zum Datenaustausch über Shared Memory gibts Hardware Semaphoren.
Mw E. schrieb: > Also voreinander schützen geht nur zweigeteilt in dem der Cortex-M4 per > MPU gehindert wird in den Linuxadresspace reinzugrätschen. Schön ist das nicht, wenn ein Bug in der Cortex-M Software die Cortex-A kompromittieren kann. Dann sich ST das ganze Trustfoo eigentlich komplett schenken.
Weiß jemand ab wann das STM32MP157C-DK2 vorraussichtlich bei den einschlägigen verdächtigen (RS, Farnell,...) verfügbar sein wird? Haben sie das auf der embedded World verraten?
STM32User schrieb: > einschlägigen verdächtigen (RS, Farnell,...) verfügbar sein wird? Haben > sie das auf der embedded World verraten? (Ende) April, dann allerdings Alles (Devkits, Eval-Kits und die MCUs) soll Alles bei den Distributoren erhältlich sein.
Borders schrieb: > Mw E. schrieb: >> Also voreinander schützen geht nur zweigeteilt in dem der Cortex-M4 per >> MPU gehindert wird in den Linuxadresspace reinzugrätschen. > > Schön ist das nicht, wenn ein Bug in der Cortex-M Software die Cortex-A > kompromittieren kann. Dann sich ST das ganze Trustfoo eigentlich > komplett schenken. So sehr hab ich mich mit Trustzone noch nicht auseinander gesetzt. Aber da es eh hackbar ist: https://blog.acolyer.org/2017/09/21/clkscrew-exposing-the-perils-of-security-oblivious-energy-management/ werd ichs in nächster Zeit wohl auch nicht.
Mw E. schrieb: > So sehr hab ich mich mit Trustzone noch nicht auseinander gesetzt. > Aber da es eh hackbar ist: TrustZone ist eh böse - das Absurde an diesen ganzen "Trust"-Technologien ist ja, dass es keineswegs um das Vertrauen des Nutzers in die Technik geht, sondern um das Misstrauen der Hersteller den Nutzern gegenüber. Dem Nutzer werden Zugriffe und Rechte entzogen unter dem Vorwand des Urheberrechts-Schutzes (DRM & Co). Praktisch jeder ARM-Anwendungsprozessor kommt ab Werk mit einer proprietären undurchsichtigen "Trusted"-Software, welche die eigene Anwendung beliebig überwachen, manipulieren und Daten abgreifen kann. Die Backdoor wird hier als Feature angepriesen. Von daher kann man TrustZone-Hacks nur begrüßen.
Mw E. schrieb: > Die MMU sitzt zwischen Cortex-A und AXI. > Der Cortex-M hat die bekannte MPU. > > Also voreinander schützen geht nur zweigeteilt in dem der Cortex-M4 per > MPU gehindert wird in den Linuxadresspace reinzugrätschen. > > Zum Datenaustausch über Shared Memory gibts Hardware Semaphoren. Diese Hoffnung hatte ich auch. Das Refman RM0436 Rev.2 (Seite 1040) interpretiere ich so, dass nur die A7-Kerne mit den HW-Semaphoren funktionieren. Das ist dann irgendwie ein Witz. Für die Synchronisation zwischen den A7 gibt es von ARM-Standards (SWP, LDREX/STREX), da brauche ich keine proprietäre ST-Peripherieeinheit. Ich habe noch keine Mögichkeit gefunden, wie die A7-Domäne mit dem M4 synchroniert werden kann. Vielleicht habe ich in den 4017 Seiten Doku noch etwas übersehen ;-)
STM32MP1 liebäugler schrieb: > Mw E. schrieb: >> Die MMU sitzt zwischen Cortex-A und AXI. >> Der Cortex-M hat die bekannte MPU. >> >> Also voreinander schützen geht nur zweigeteilt in dem der Cortex-M4 per >> MPU gehindert wird in den Linuxadresspace reinzugrätschen. Das ist doch nicht Sinn und Zweck der Trustzone. Das Linux soll im nicht sicheren Kontext auf dem A7 ausgeführt werden. Die (kritischen) Echtzeit-Prozesse dagegen auf dem M4. Daher die Trennung. Insbesondere, da ja da Linux üblicherweise über z.B. Ethernet vernetzt ist und somit Angriffsfläche bietet. Im Falle der Kompromittieruung ist dann das Kernsystem nicht betroffen und kann Schutzmassnahmen einleiten. >> Zum Datenaustausch über Shared Memory gibts Hardware Semaphoren. > > Diese Hoffnung hatte ich auch. Das Refman RM0436 Rev.2 (Seite 1040) > interpretiere ich so, dass nur die A7-Kerne mit den HW-Semaphoren > funktionieren. Das ist dann irgendwie ein Witz. Für die Synchronisation > zwischen den A7 gibt es von ARM-Standards (SWP, LDREX/STREX), da brauche > ich keine proprietäre ST-Peripherieeinheit. Ich habe noch keine > Mögichkeit gefunden, wie die A7-Domäne mit dem M4 synchroniert werden > kann. > Vielleicht habe ich in den 4017 Seiten Doku noch etwas übersehen ;-) Zur Kommunikation zwischen dem A7 und M4 Kontext ist der IPCC (inter process communication controller) da.
Bin ja mal gespannt, ob Sie damit einen Platz zwischen NXP i.MX, TI Sitara, und Renesas RZ finden. Ich glaube in den Bereichen wo ich hier den STM32MP1 sehe, würde ich eher zum RZ/A oder einem Sitara greifen. Naja, wenn ich an meinen früheren Chef denke … da war sehr strikt der gleiche Hersteller gesetzt -> STM32F irgendwas im Einsatz, … es soll irgendwas mit Linux gemacht werden -> es steht nur der STM32MP1 zur Auswahl :D. Allerdings war es bei ihm ATMEL ;), der wird dann wohl auch kein Kunde.
@LinuxMan lern mal zitieren im Zitat von mir gehts um Adresspaces und MMU, Trustzone kam erst später. @Topic. Der Vorteil besteht zumindest darin, dass man die Peripherie und deren Treiber schon kennt und jetzt gibts das auch mit "dicken" Cortex-A Kernen.
Angehängte Dateien:
Recht kleines (25.4 x 25.4mm) Modul damit: http://linuxgizmos.com/linux-driven-stm32mp1-module-measures-less-than-one-square-inch/ Da könnte sich ST glatt erbarmen einen STM32MP1 auf ein Nucleoboard zu setzen.
Ich hätte ja nicht erwartet, dass es sooo schnell geht mit den SOMs. Gibts da schon Infos zu den Preisen?
Hmm, auch da keine Preise. Naja, ist ja auch noch alles ganz frisch. Wenn ST es nicht komplett vermasselt dürfte das Teil schon gut ankommen, vor allem im Bereich HMI. Dank OpenGL ES ist das Teil eigentlich prädestiniert dafür, selbst wenn die eigentlichen Cortex-A Kerne nicht so üppig vom Takt sind.
Octavo Systems hat auch ein System-in-Package mit dem STM32MP1 angekündigt: https://octavosystems.com/octavo_products/osd32mp15x/ Aber auch da noch keine Preise oder Lieferzeiten verfügbar.
Malzeit, Es war schon erstaunlich was für einem Aufgebot an Partnern ST auf der EW2019 rund um den MP1 auf ihrem Stand versamellt hat. Von einer Firma aus Leipzig mit einem eigenen Board, Octova mit der angkündigung von System on chip, Software Firmen wie Tara, Ubuntu, ... Zum Thema Octavo: Hab mich auf der EW2019 gewundert wieso die mit auf dem ST stand stehen. Kenne die bisher nur vom Beaglebon / Sitara. Laut deren Aussage wird es erstmal nur eine Variante mit den ganz grossen MP1 geben mit 1GB Ram. Verfügbarkeit war so gegen Ende Q3 bzw Q4 2019 geplant. Preise wurden nicht genau genannt, aber gehen so gegen 20 - 30$. Laut Octavo soll es dann auch Beaglebone Variante mit MP1 geben. Verfübarkeit auch so gegen ende 2019. PS. Auf der EM2019 sind laut gut informierten quellen die ersten DK2 an interesierte Messebesucher verteilt worden.
123 schrieb: > PS. Auf der EM2019 sind laut gut informierten quellen die ersten DK2 an > interesierte Messebesucher verteilt worden. Falls Du statt "EM" "EW" gemeint hast, kann ich das aus erster Hand bestätigen. :) Falls es hier noch andere Mitleser gibt, die ein DK2 bekommen haben: Funktioniert bei Euch die Bluetooth-Demo? Ich bekomme schon beim Booten einen Timeout vom hci_uart-Treiber und beim Versuch, die Demo zu starten noch mal. Jetzt frage ich mich, ob es ein Software-Problem ist oder ob auf meinem Board der BT-Chip einen Hau hat.
123 schrieb: > Zum Thema Octavo: > Hab mich auf der EW2019 gewundert wieso die mit auf dem ST stand stehen. > Kenne die bisher nur vom Beaglebon / Sitara. Laut deren Aussage wird es > erstmal nur eine Variante mit den ganz grossen MP1 geben mit 1GB Ram. > Verfügbarkeit war so gegen Ende Q3 bzw Q4 2019 geplant. Preise wurden > nicht genau genannt, aber gehen so gegen 20 - 30$. Laut Octavo soll es > dann auch Beaglebone Variante mit MP1 geben. Verfübarkeit auch so gegen > ende 2019. Danke für die Infos. Hast Du zufällig von Octavo erfahren, ob die auch noch ein stärkeres System-in-Package als bisher bringen wollen? Also z.B. mit TI AM572x und PCIe-Bus. Die TI AM335x sind leistungsmäßig für manche Anwendungen einfach zu eng.
Hallo, Frag nach, die sind da offen was so was angeht, ... hängt natürlich auch immer von der Stückzahl ab. Wir hätten eher am kleinsten MP1 mit geringerem Speicherausbau interesse. Es war kein generelles nein, sondern eher wenn genug Stückzahl/nachfrage können Sie sich das durchaus vorstellen ... wobei 25k pro Jahr sich nach untere Mindestmenge angehört hat. Und ja natürlich meinte ich die EW2019 in Nürnberg.
Hallo, Ich war heute auf dem Hands On Workshop zum Stm32mp1 in Stuttgart. Sehr interessant! Dort lagen auch ein System on Module (SOM) von emtrion und eines von kontron aus. Es gibt wohl noch etlich weitere Anbieter solcher Module. Leider findet man nirgends eine Preisliste. Hat jemand schon Preise für solche Module? Mit freundlichen Grüßen Blume
Hallo Zusammen, ich arbeite bei Kontron und habe das MP1 SoM mit entwickelt. Leider kann ich es von der vertrieblichen Seite nicht voll abdecken und deswegen zu den Preisen (noch) recht wenig sagen. Aber zumindest für technische Fragen bin ich empfänglich ;-) Grüße, Simon
@dosenkohl Danke für das Angebot, da habe ich doch gleich ein/zwei Fragen. Wir haben eine kleine Inhouse Schaltung, die auf einem nativen Cortex-M4 STM32F407ZGT6 Board als Herzstück basiert. Darin läuft primär ein 1us Interrupt, der DAC Werte ausgibt und auf ein paar GPIOs reagiert. Im main loop wird noch auf RS232 Eingaben reagiert. Get gerade noch so, ist aber langsam eng mit den CPU-Cycles. Deshalb suchen wir ein Board, bei dem wir die langsameren Tasks vie RS232 auf eine weitere CPU auslagern könnten plus noch ein paar Wünsche wie TCP/IP Zugriffe und ev. ein kleiner Webserver. Fragen: - Welche GPIO's sind auf Eurem Base-Board herausgeführt ? - Wie schnell lässt sich so ein GPIO vom M4 aus hoch oder runternehmen ? - Wie schnell reagiert der DAC auf Aenderungen ? Beim DAC ist klar, dass er nicht in ein 1us von 0 auf 100% geht, wenn der etwas nachläuft ist kein Problem. Die Fragen nach dem GPIO Speed kommen von Tests mit einem anderen Board in der Vergangenheit, welches ebenfalls ein M4 Subprocessor hat (NXP i.MX7Dual). Und dort waren die Tests ernüchternd, auf dem nativen M4 ist der GPIO in etwas ~10ns oben, auf dem NXP Board 150-200ns. Danke und Gruss Daniel
Daniel B. schrieb: > Die Fragen nach dem GPIO Speed kommen von Tests mit einem anderen Board > in der Vergangenheit, welches ebenfalls ein M4 Subprocessor hat (NXP > i.MX7Dual). Und dort waren die Tests ernüchternd, auf dem nativen M4 ist > der GPIO in etwas ~10ns oben, auf dem NXP Board 150-200ns. Ja, genau dafür sind ARMs auch eher weniger geeignet. Das hhängt damit zusammen, dass die IO-Ports nicht wie bei AVR und PIC (bis PIC24 und dsPIC) quasi als Prozessorregister angebunden sind, sondern über einen IO-Bus müssen, und wenn das z.B. ein APB ist, ist das eben langsam. Speziell für solche Anwendungen sind andere Architekturen wie z.B. TI C28xx geeigneter. Die C28xx haben auch sehr gute Peripherieeinheiten, sie man so woanders nicht findet. Sind eben speziell für Steuerungsaufgaben designt. fchk PS: http://www.ti.com/tool/LAUNCHXL-F28379D
:
Bearbeitet durch User
Ihr seid also auch der Meinung, dass das hier wohl auch das Problem ist ? Ka...e, dann muss ich wohl oder übel eines der TI Boards anschauen (danke für den Link), oder ein Linux Board mit einem Cortex-M4/7 Board verheiraten. Eigentlich wollte ich: - den Cortex-M4 Code beibehalten - mich in keine neue CPU einarbeiten - Mit Linux die unkritischen (Zeit) Teile erledigen (Unix kenne ich) - Ein Board mit allem drauf (wir können kein eigenes Board designen) Danke erstmal für die Antworten. Werde trotzdem mal ein paar einfache Tests machen (das Board ist jetzt gekommen). Und ev. meldet sich der Simon noch mal. Cheers.
Man könnt auch einfach mal ins Datenblatt gucken? Im Blockdiagramm ist doch eindeutig zu sehen, dass der M4 sein eigenen AHB hat und an diesem hängen auch die GPIO. Also ändert sich in diesem belang garnichts zu einem STM32F4 zum MP1. Der AHb ist mit 209 statt 168MHz sogar noch schneller.
Frank K. schrieb: > Daniel B. schrieb: > >> Die Fragen nach dem GPIO Speed kommen von Tests mit einem anderen Board >> in der Vergangenheit, welches ebenfalls ein M4 Subprocessor hat (NXP >> i.MX7Dual). Und dort waren die Tests ernüchternd, auf dem nativen M4 ist >> der GPIO in etwas ~10ns oben, auf dem NXP Board 150-200ns. > > Ja, genau dafür sind ARMs auch eher weniger geeignet. Das hhängt damit > zusammen, dass die IO-Ports nicht wie bei AVR und PIC (bis PIC24 und > dsPIC) quasi als Prozessorregister angebunden sind, sondern über einen > IO-Bus müssen, und wenn das z.B. ein APB ist, ist das eben langsam. Das ist aber nicht generell für alle ARM-basierten Prozessoren so, sondern ist stark vom Design des jeweiligen Prozessors abhängig. Die STM32MP1 sehen für diesen Zweck gar nicht so schlecht aus: die GPIOs hängen lt. Datenblatt an einem AHB mit 209 MHz. Der Cortex-M4 hängt direkt am selben AHB. Außerdem haben die GPIO-Ports die von den anderen STM32 bekannten BSRR-Register, mit denen man in einem Zyklus und atomar bitweise schreiben kann. @Daniel: ich würd mir an Deiner Stelle also einfach mal das Demoboard von ST holen und es kurz ausprobieren.
:
Bearbeitet durch User
@fritzler: Man hat, aber man war sich nicht sicher, was man dort sieht, und vor allem ob man sich auch darauf verlassen kann. Du meinst sicher Page 19 mit dem Block Diagram ? Deshalb hier die Frage an den Spezialisten, der mit dem Ding schon gearbeitet hat. @robberknight: Das Board habe ich schon, bin nur noch nicht dazu gekommen, und wenn der Spezi gleich gesagt hätte, vergiss es, hätte ich mir die Zeit sparen können.
:
Bearbeitet durch User
Ich möchte kein yocto basiertes Bildsystem für den STM32MP1 verwenden, sondern ein System mit Debian auf Packetbasis. Wie kommt man am einfachsten dorthin ? Beispiel: i.mx8 Debian 10 hier sehr schön und einfach gemacht: http://variwiki.com/index.php?title=DART-MX8M
Daniel B. schrieb: > - Ein Board mit allem drauf (wir können kein eigenes Board designen) Warum nicht? Kein Geld? Kein Know-How? fchk
Frank K. schrieb: > Daniel B. schrieb: > >> - Ein Board mit allem drauf (wir können kein eigenes Board designen) > > Warum nicht? Kein Geld? Kein Know-How? > > fchk Sowohl als auch und eine Richtofferte bei einem Ingenieurbüro hier in der Schweiz hat unser Budget leicht gesprengt. Respektive ist für eine Stückzahl kleiner 20 in keinem Verhältnis.
Hat jemand schon mal ein makefile für den M4 des STM32MP1 für STM32CubeMX-Apps gesehen? Die fette AC6 IDE lädt nicht zum entwickeln ein.
Tester schrieb: > Die fette AC6 IDE lädt nicht zum entwickeln ein. Aber die erzeugt dir dein Makefile.
Man kann doch auch aus CubeMX ein Makefile erzeugen oder geht das etwa für den CM4 des MP1 nicht? pegel schrieb: > Tester schrieb: >> Die fette AC6 IDE lädt nicht zum entwickeln ein. > > Aber die erzeugt dir dein Makefile. Aber das ist doch totaler Käse.
Christopher J. schrieb: > Man kann doch auch aus CubeMX ein Makefile erzeugen oder geht das etwa > für den CM4 des MP1 nicht? nein kann man nicht, nur für Toolchain/IDE SW4STM32 (ac6). makefile ist ausgegraut.
Dann könntest du mal das CubeMX2Makefile-Skript ausprobieren, das frisst nämlich AC6-Projekte: https://github.com/baoshi/CubeMX2Makefile Ob es funktioniert weiß ich nicht, weil das zuletzt nur für CubeMX 4.x gedacht war, weil ja CubeMX seitdem eigentlich Makefiles generieren kann.
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.