Hallo! Ich sah dass der STM32F7 einiges hat was ich bräuchte: viel und einiges davon schnelles internes Programm+Daten-RAM. LQFP-100 würde wohl noch lötbar sein irgendwie. Doch wie sieht es mit der Programmier-/Initialisierbarkeit aus ? Das Teil hat Cache und Zeugs ... Ist das vielleicht nur für Firmen mit hochentwickelter Entwicklungssoftware interessant und läuft da am besten nur ein Betriebssystem wie Linux etc. drauf ?
STM32CubeMX + SW4STM32 + 2 Zeilen Quelltext = Blinky ;) Gewisse Einarbeitung braucht es je nach Programmiererfahrung schon, aber dann macht es Spaß. Software ist kostenlos.
Nö. Das Teil ist im Prinzip auch nicht komplexer zu programmieren als ein STM32F3/STM32F4.
Von dem was ich bis jetzt gelesen habe (hab noch keinen in den Fingern gehabt) funktioniert die Initialisierung fast genauso wie beim F4 und auch die grundlegenden Dinge wie gpio und Timer sollen mehr oder weniger identisch sein. Also reicht im Prinzip eine gcc Toolchain und 20 Zeilen Code um die Takte zu initialisieren und nochmal ne Handvoll bis er Blinkzeichen von sich gibt. Und natürlich etwa 1 Woche harte Arbeit um sich obige 25 Zeilen selbst zu erarbeiten. Alternativ lädst Du Dir die auf Eclipse und gcc basierende Umgebung von ST samt zugehörigem Konfig-Tool (CubeMX) herunter und klickst es Dir mit der Maus zusammen. Je nachdem was Du willst (entweder den Controller und den Code der ihm Leben einhaucht im Detail verstehen lernen oder nur möglichst schnell was aus vorgefertigten Komponenten zusammenzustöpseln) macht die eine oder die andere der beiden Varianten mehr Spaß. Kostenlos sind beide.
Zum Einstieg ist das B(oard)S(upport)P(ackage) immer eine gute Wahl. Gibts hier für SW4STM32 vorkonfiguriert zum Download: http://www.dasrotemopped.de/index.php?var=cpp&nr=0 Wähle dein Disco Board weise ! Ich empfehle das STM32F746G-Disco http://www.dasrotemopped.de/index.php?var=projekte&nr=22 Und noch die "Installationsanleitung" http://www.dasrotemopped.de/index.php?var=projekte&nr=17 Musste noch so gut wie nie ein Register persönlich ansprechen. Und bis auf die Hardware ist alles kostenlos. Gruß, dasrotemopped.
Leider hat STM mit den F7 in die Kloschuessel gegriffen. Der Arm Core im F74 hat Probleme mit den Interrupts beim Debuggen und F76 in der ersten Version ein Problem mit dem Ethernet MAC. Die zweite F76 Revision soll das Problem behoben haben, aber bei Farnell war war das Nucleo144 immernoch mit der fehlerhaften Revision bestueckt.
da der ganze IoT Hype mich ziemlich kalt lässt ist mir ein fehlerhafter Ethernet MAC ziemlich egal. Und das Debuggen hat bis jetzt ganz gut geklappt. Ein Errata Sheet hat jeder Hersteller zu jedem Prozessor so wie jeder Software Hersteller Bugfixes zur Software anbieten muss. Da gleich den Weltuntergang auszurufen scheint mir übertrieben. Ich konzentriere mich lieber auf das was geht und das ist bei den STM32F7xx Discos noch eine ganze Menge. Gruß, dasrotemopped.
Ich stehe wirklich vor einem Problem: Ich möchte gerne ein kleines Computer/Spielkonsolen-System bauen und muss irgendwie die Grafik hinkriegen. Also Bildbuffer eines Grafikadapters füllen, Grafikdaten laden etc. Doch was ist das Beste: ein globales Bussystem oder alles drinnen im Mikrocontroller ? Wie lange ist so ein STM32F7 verfügbar (Jahre) ? Gibt es 8-Bitter die geeignet wären ? Was ist mit Hardware-Sprites die die CPU entlasten ? Braucht es FPGA ? Fragen über Fragen :-)
Du redest wirr. Fang erst einmal mit irgendwas an um zu erkennen was du wirklich willst. Oder kauf dir ne Sega oder wie die heute alle heissen. Sonst würde ich einfach mal nachforschen wie andere das gemacht haben um einen groben Überblick zu erlangen.
pegel schrieb: > Du redest wirr. Die Geschichte wiederholt sich. Irgendwie erinnert mich das ein bisschen an Stefan Hackbusch oder Holger Krähenbühl. Es gibt sicher noch weitere .....
>Ich stehe wirklich vor einem Problem: >ein kleines Computer/Spielkonsolen-System bauen irgendwo zwischen gebrauchter C64 und 5000€ Gaming PC liegt die Wahrheit. hat aber nichts mehr mit der Anfangsfrage zu tun. >Doch was ist das Beste: mit der Einstellung wirst du nicht ein Pixel auf den TFT bekommen. Du wirst alleine nur das nachbauen, was andere schon 1000x vor dir bereits nachgebaut haben. Das sollte man sich immer klar machen, wenn man nicht in der R+D Abteilung von S, M, oder N sitzt. Und auch die haben nur Komponenten zugekauft und nach Referenzdesign zusammengesteckt. Was Hänschen nicht anpackt, schafft Hans nimmermehr. ... passt wie Faust aufs Auge ... Gruß, dasrotemopped.
H-G S. schrieb: > Doch was ist das Beste: ein globales Bussystem oder alles drinnen im > Mikrocontroller? Du brauchst externes RAM. Das interne wird kaum reichen. > Wie lange ist so ein STM32F7 verfügbar (Jahre)? Keine Ahnung. > Gibt es 8-Bitter die geeignet wären? Besser als ein STM32F7? Wohl kaum. Nur mit Tricks über 64k. Ohne gute Grafik-Hardware (eben Sprites, Hardware scrolling) zu langsam. Als Alternative zum STM32F7 sehe ich eher einen RaspberryPi. Dort direkt in OpenGl programmieren. Da geht dann (viel) mehr. Der kann dann auch gleich alte 8-Bitter emulieren oder auch einen Amiga. > Was ist mit Hardware-Sprites die die CPU entlasten? Hat der STM32F7 nicht. Aber du kannst per DMA Grafikobjekte kopieren. So ähnlich wie früher die BOBs auf'm Amiga. https://de.wikipedia.org/wiki/BOB_(Computergrafik) > Braucht es ein FPGA? Wenn ein FPGA, dann kann man im Prinzip auch die CPU gleich mit ins FPGA packen. Vorteil: Du kannst dir die Grafik-Hardware selbst bauen, also z.B. beliebige Sprites (was halt der FPGA leistungsmäßig hergibt). Problem: Es wird teurer und aufwändiger. Goole mal: Es gibt diverse Projekte für (retro) Spielehardware, mit und ohne FPGAs.
Es wurden viele Tricks angewendet, um die lahmen Hardware von damals grafiktauglich zu machen ... Zum Beispiel das Hardware-Scrolling des C64, da verschob man mit wenigen Befehlen den Bildschirm um einen Pixel - der Grafikchip hat das dann irgendwie in den Speicher gemappt. Möglicherweise muss ich das Projekt abbrechen, da man ohne Grafikhardware nichts erreichen kann ... ausser natürlich Standbilder und Text :-)
http://www.syntiac.com/fpga64.html Da kannst du dich voll auf die Spieleentwicklung konzentrieren...
Also die STM32F4/7 sind mit Sicherheit Spieletauglich, siehe die Demos von ST/touchGFX: https://www.youtube.com/watch?v=kXfMrvpdp9M Die Disco-Boards mit Display sind ein guter Start, aber die grossen mit 769 oder 469 mit Display sind mit ca. 80€ nicht gerade billig. Von oben kommt da ja schon die Konkurrenz mit Cortex-A oder i.MX. Oder wenn es nur um Games geht dann hat man mit einem Gameboy doch schon alles, die alten konnte man doch auch selber programmieren?
H-G S. schrieb: > Möglicherweise muss ich das Projekt abbrechen, da man ohne > Grafikhardware nichts erreichen kann ... ausser natürlich Standbilder > und Text :-) Ja, Du wirst es abbrechen müssen, aber eher wegen fehlenden know-Hows bei gleichzeitiger Beratungsresistenz, siehe Dein letztes Projekt.
>nur Standbilder und Text selten so gelacht ! mit dem STM32F746G-disco https://youtu.be/GNKWmLiMpuk nur das STM32F4-disco OHNE TFT Controller: https://youtu.be/ymGCeG9_6c0 https://youtu.be/KsToQmFndpg Quellcode herunterladbar http://www.pouet.net/prod.php?which=61197 http://www.pouet.net/prod.php?which=59095 oder das STM32F429i-disco mit TFT Controller am VGA Monitor: https://youtu.be/VGMXHxBtGaE den Quellcode gibts auch zum Download http://www.dasrotemopped.de/dateien/STM32F429i-Disco_ILI9341_20170212_clean.zip Jetzt will ich die Ausreden hören. Gruß, dasrotemopped.
Hallo, der Cortex M7 Core hat gegenüber dem M4 core nur dort Vorteile, wo der Compiler sie umsetzen kann. Hauptneuerung: Der M7 unterstützt ein 6 stage pipelining, was bedeutet, dass Maschinenbefehle vom Kern so gut wie es geht parallelisiert werden (also wenn z.B. zwei aufeinanderfolgende Load Operationen nicht voneinander abhängig sind, wird der Kern sie innerhalb der Pipeline in einem Zyklus abarbeiten). Das hilft dem Normalprogrammierer aber nichts, weil er selber in seinem Code nichts direkt tun kann, was diese Architektur nutzt (ausser Inline Assembler schreiben). Wer wirklich noch die letzten Zyklen Performanz aus seinem Keks herausholen will, ist darauf angewiesen, dass der Compilerhersteller den Maschinencode optimal auf den Kern anpasst. Ich vermute mal, dass 99% aller Programmierer/Entwickler mit einem M4 basierten Controller genau so gut wenn nicht besser (weil länger im Feld) auskommen. Und was die Verfügbarkeit angeht, hat mir mal ein Product Manger von einem sehr relevanten Chiphersteller prophezeiht, dass es M3 (!) Controller noch geben wird, wenn wir alle längst Würmer füttern.
:
Bearbeitet durch User
Ruediger A. schrieb: > Hauptneuerung: Der M7 unterstützt ein 6 stage pipelining huch? Wenn ich das recht erinnere, dann ist die Hauptneuerung, daß der M7 jetzt Cache hat. Das hilft wirklich. Ich hatte das vor rund 15 Jahren bei denn Fujitsu FM gemerkt: Die sind damals jedem etwa gleichschnell getakteten Arm davongezogen. Und zwar nicht nur ein bißchen, sondern richtig. Aber wenn ich so die o.g. Demos sehe, frag ich mich, ob ihr denn nix anderes als Spiele im Kopf habt. Ich würde bei sowas zuerst an schnellere FIR-Routinen denken und an höhere Sampleraten bei SDR-Projekten. Allerdings sehe ich eines, nämlich daß die M7 noch immer recht dünn gesät sind, vornehmlich bei ST, dazu einer bei Freescale. Von jemandem von NXP auf der letzten Embedded war zu hören, daß man bei den LPC nicht plant, einen M7 herauszubringen. W.S.
W.S. schrieb: > Ruediger A. schrieb: >> Hauptneuerung: Der M7 unterstützt ein 6 stage pipelining > > huch? > Wenn ich das recht erinnere, dann ist die Hauptneuerung, daß der M7 > jetzt Cache hat. Das hilft wirklich. Ich hatte das vor rund 15 Jahren > bei denn Fujitsu FM gemerkt: Die sind damals jedem etwa gleichschnell > getakteten Arm davongezogen. Und zwar nicht nur ein bißchen, sondern > richtig. > neee, die cache ist und war optional: http://www.keil.com/appnotes/files/apnt_270.pdf Der STM32F4xx hat die Cache schon im 4er Kern über eine Kernelerweiterung namens ART implementiert. > Aber wenn ich so die o.g. Demos sehe, frag ich mich, ob ihr denn nix > anderes als Spiele im Kopf habt. Ich würde bei sowas zuerst an > schnellere FIR-Routinen denken und an höhere Sampleraten bei > SDR-Projekten. > ack. > Allerdings sehe ich eines, nämlich daß die M7 noch immer recht dünn > gesät sind, vornehmlich bei ST, dazu einer bei Freescale. Von jemandem > von NXP auf der letzten Embedded war zu hören, daß man bei den LPC nicht > plant, einen M7 herauszubringen. > > W.S. Ja, das Riesenproblem ist der Innovationsdruck. Niemand kann es sich heutzutage leisten, ein nicht wesentlich zu verbesserndes Produkt NICHT mit irgendetwas zu "verbessern" (praktisch: tendentiell eher zu verschlimmbessern). Wäre in unserer Branche vielleicht mal ganz wohltuend, etwas Dampf aus dem komplett überhitzten Versionsrauspresszyklus zu nehmen. Die allermeisten aktuellen Anforderungen liessen sich heute problemlos mit 5-10 Jahre alter Technologie erfüllen, aber die Erwartung ist eben, jedes Jahr mit etwas komplett neuem herauszukommen... ARM könnte problemlos mit ihren Lizenzeinnahmen von der M4 Familie leben (von den A und R Serien mal ganz abgesehen). Aber im Hintergrund steht immer irgendein Investor, der noch mehr Marktanteile, noch mehr Nischen, noch mehr return will. C'est la vie. Insofern ist die NXP Strategie erstmal nichts schlechtes oder unsweises, eher im Gegenteil (obwohl da natürlich auch ganz Andere politische Weichenstellungen dahinter stehen könnten).
W.S. schrieb: > Allerdings sehe ich eines, nämlich daß die M7 noch immer recht dünn > gesät sind, vornehmlich bei ST, dazu einer bei Freescale. Sieh Dir mal SAM S70 von Atmel/Mircochip an. Double-Berechnungen mit Hardware FPU z.B. und das bei 300 MHz.
der M7 fetzt schon im vergleich zum M4 ist der M7 ca 50-80% schneller Ich betreibe den mit einem FreeRTOS + lwIP und vielen vielen extras manchmal muss man etwas optimieren wenn man die eigenheiten des M7 kennt. der cache ist bei FSMC zugriffen nervig weil er befehle bündelt. der haut dann teilweise ohne sinn und verstand auf den datenleitungen die bits raus . aber auch bei unoptimierten Code ist er fast immer schneller gut sind auch die 16K Instruction RAM der rennt dann wirklich schnell für FIR oder encoder/decoder code-teile eine sehr gute wahl
wewqwdasa schrieb: > der M7 fetzt schon > > im vergleich zum M4 ist der M7 ca 50-80% schneller > Ich betreibe den mit einem FreeRTOS + lwIP und vielen vielen extras > > welche PODs genau? Danke!
Ausbrobiert habe ich es aber nicht. Es ist wahrscheinlich am werden. https://github.com/danieleff/STM32GENERIC
Bitte 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.