Forum: Mikrocontroller und Digitale Elektronik STM32F7 für Hobby-Bastler machbar ?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von H-G S. (haenschen)


Bewertung
0 lesenswert
nicht lesenswert
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 ?

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
STM32CubeMX + SW4STM32 + 2 Zeilen Quelltext = Blinky ;)

Gewisse Einarbeitung braucht es je nach Programmiererfahrung schon,
aber dann macht es Spaß.
Software ist kostenlos.

von Thorsten (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nö.

Das Teil ist im Prinzip auch nicht komplexer zu programmieren als ein 
STM32F3/STM32F4.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Markus H. (dasrotemopped)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Uwe B. (Firma: TU Darmstadt) (uwebonnes)


Bewertung
0 lesenswert
nicht lesenswert
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.

von dasrotemopped (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von H-G S. (haenschen)


Bewertung
0 lesenswert
nicht lesenswert
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  :-)

von pegel (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Abge Klärter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 .....

von dasrotemopped (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>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.

von 2⁵ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von H-G S. (haenschen)


Bewertung
0 lesenswert
nicht lesenswert
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  :-)

von 1N 4. (1n4148)


Bewertung
0 lesenswert
nicht lesenswert
http://www.syntiac.com/fpga64.html

Da kannst du dich voll auf die Spieleentwicklung konzentrieren...

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Zweifler (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von dasrotemopped (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>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.

von dasrotemopped (Gast)


Bewertung
0 lesenswert
nicht lesenswert
vergessen:
https://youtu.be/bRNcfsDIc2A

Happy Gaming

von Ruediger A. (Firma: keine) (rac)


Bewertung
0 lesenswert
nicht lesenswert
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
von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Ruediger A. (Firma: keine) (rac)


Bewertung
0 lesenswert
nicht lesenswert
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).

von m.n. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von wewqwdasa (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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

von Ruediger A. (Firma: keine) (rac)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Markus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Im Arduino generic Repo gibt es sei 3 Tagen einen F746.

von Markus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ausbrobiert habe ich es aber nicht. Es ist wahrscheinlich am werden.
https://github.com/danieleff/STM32GENERIC

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.