STMicro hat ein paar neue STM32H7 angekündigt mit einer Taktrate von 550MHz und internem Flash. Beworben wird das ganze natürlich schön mit „the fastest core speed in the market among MCUs that integrate flash storage on-chip“. Habe ich hier etwas verpasst? Der bereits erhältliche i.MX RT1064 hat doch schon 600MHz und integriertes Flash...
Der i.MX hat den Flash on-package, aber nicht on-chip. Habe den hier, der Flash ist per QSPI angebunden.
Hi. Der RT1064 hat laut Internetseite von NXP das Flash intern. Ist halt Marketing. Wann sagen die mal die Wahrheit ?
Xerxes schrieb: > Der RT1064 hat laut Internetseite von NXP das Flash intern. Ist ja auch intern - im Package :-P. Im Datenblatt ist sogar etwas versteckt ein Link zum Winbond W25Q32JV QSPI Flash...
Die entscheidende Frage ist: bei welchem der Controller kann man den Code direkt aus dem Flash ausführen?
Jim M. schrieb: > Der i.MX hat den Flash on-package, aber nicht on-chip. > > Habe den hier, der Flash ist per QSPI angebunden. Das könnte tatsächlich die Antwort sein, stellt sich mir nur die Frage, ob dies mit irgend einem Nachteil verbunden ist, dass das Flash auf dem gleichen Die sitzt. Für mich klingt das bisher sehr nach reinem Marketing-Geschwafel, ich muss aber auch zugeben, das mir hier die Erfahrung fehlt in dieser Mikrocontroller-Klasse, bisher habe ich nur mit PICs, AVRs und dem STM32F0 als MCU gearbeitet, alles was anspruchsvoller war, lief als Applikation auf Linux-SoCs. Für ein aktuelles Projekt, würde ein Mikrocontroller dieser Art ziemlich gut passen.
Aha schrieb: > Das geht mit QSPI Flash mit allen MCUs die XIP können. Wie ist die Performance dabei? Genauso wie direkte Flash-Ausführung?
Flash im gleichen Silizium ist deutlich performanter. Wenn man das Flash im gleichen Package hat, müssen die zwei Dies zusammen gebonded werden. Die Geschwindigkeit ist hier stark limitiert. Das müssen die Prozessoren dann durch entsprechende Cache-Strukturen ausgleichen. Zufällige Flash-Zugriffe können aber ganz schön Latenzen haben hier
Nop schrieb: > Aha schrieb: >> Das geht mit QSPI Flash mit allen MCUs die XIP können. > > Wie ist die Performance dabei? Genauso wie direkte Flash-Ausführung? Kommt schwerstens auf den µC an. Die o.g. dicken µCs haben Cache für Code und Datenpfade - da kommt es auf ein paar Taktzyken für den externen Flash nicht an. Und auch interner Flash braucht bei >25MHz Wartezyklen. Auf einem Cortex-M4 ohne viel Cache dürfte der Unterschied XIP/intern schon zu merken sein.
Jim M. schrieb: > Und auch interner Flash braucht bei >25MHz Wartezyklen. Auf einem > Cortex-M4 ohne viel Cache dürfte der Unterschied XIP/intern schon zu > merken sein. Deswegen verbauen die Hersteller meist Cache direkt am Flash. Der Flash wird mit 128/256Bit und mehr ausgelesen und die Thumb Instruktions werden dann häppchenweise an den Bus gereicht wenn benötigt. Ein Benchmark auf einem STM32H7 wäre da echt mal interessant. Der hat ja son internes FlashCache Kunstwerk und kann QSPI per CPU Cache verstecken. Die großen MCUs laden aber meist beim Startup was aus dem Flash in den DRAM und führen dann von dort den Coee aus. Jetzt hat DRAM höhere Frequenzen und Bitbreiten, aber braucht auch ein ganz schönes "vorgeplänkel" bis man da mal an ein paar Bytes kommt für die Cacheline.
Am 8.10. gibts ein Webinar zum H7: https://www.st.com/content/st_com/en/about/events/events.html/stm32h72x-h73x
Wenn der Flash auf dem Chip integriert ist, muss ich mich weniger darum kümmern oder damit befassen als wenn der extern ist, damit langsamer und gecached werden muss. Daher ist es für den Entwickler etwas einfacher von z.B. einem STM32 mit M3 oder M4 auf diesen neuen STM32H7 umzusteigen. Mit "kümmern" meine ich z.B. daß ich die Interrupts ins RAM kopieren muss um bei einem seltener aufgerufenen Interrupt nicht die Latenz massiv zu steigern. Aber längerfristiger skaliert das mit dem integrierten Flash natürlich lang nicht so gut wie der externe Flash. Die H7 kommen jetzt mit 1 MByte Flash, als externen QSPI gibt es momentan bis 256 MByte und da ist konzeptionell noch lange nicht Ende der Fahnenstange. Daher dürfte der Punkt mit integriertem/externen Flash in der Praxis nicht soo entscheidend für den einen oder anderen Controller sein. Viel wichtiger dürfte sein, ob man bisher eher mit den Controllern von ST oder denen von NXP Erfahrung gesammelt hat, die Peripherie kennt etc.
Gerd E. schrieb: > Aber längerfristiger skaliert das mit dem integrierten Flash natürlich > lang nicht so gut wie der externe Flash. Die H7 kommen jetzt mit 1 MByte > Flash, als externen QSPI gibt es momentan bis 256 MByte und da ist > konzeptionell noch lange nicht Ende der Fahnenstange. > > Daher dürfte der Punkt mit integriertem/externen Flash in der Praxis > nicht soo entscheidend für den einen oder anderen Controller sein. Viel > wichtiger dürfte sein, ob man bisher eher mit den Controllern von ST > oder denen von NXP Erfahrung gesammelt hat, die Peripherie kennt etc. Externer Flash hat den Vorteil (für den Hersteller), daß für die dann 2 Dies mit dem jeweils idealen Fertigungsverfahren hergestellt werden können. Das Problem stellt sich auch bei größeren Rechnemaschinen, wo man die großen Caches manchmal als getrennte Dies ausführt.
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.