Welche Nachteile haben die großen STM32H Serien?

Itchi schrieb:
> oder Hobbybasteleien NICHT auf z.B. den STM32H750 zu setzen?
> Der Preis ist mit 8€ auch nicht höher als von vielen anderen F4 Serien.
> Viel Flash, Ram etc ist auch vorhanden.

128kByte Flash ist also sooo viel? Und noch wichtiger: Das ist nur 
ein(!) Sektor, kann also nur komplett gelöscht werden. Mit 
EEPROM-Emulation, Updates via zweiter Bank ist's also Essig.
Der restliche Flash (zum H743) dürfte zwar auch an Bord sein, aber 
nutzbar?

Komplexität?

Pin-Wackeln geht beim G0 deutlich schneller als beim H7.

Cache ist nett - aber hat softwareseitig so seine Tücken. Ebenso ITCM 
und DTCM.

Die momentanen Preise sind teilweise doch recht spekulationsgetrieben.

ab welcher Serie gibt es schnelles SPI?

Itchi schrieb:
> ab welcher Serie gibt es schnelles SPI?

Hm, ST hat so viele Datenblätter, die verschenken sie sogar online ;-)

ja, und? Was willst du mir damit sagen?
Da du es gerade nicht weißt? Schön , danke für deinen Beitrag?!
Ich hatte auch eher in die Runde gefragt...

Ein H743 hat genug internen Flash/Ram für vieles, gibt es auch auf 
Chinaboards.
Die H7 sind schon eine Spur komplexer: Clock mit mehreren PLL und viel 
Konfigurationsmöglichkeit, Power Domains, DMA mit Cachefallen, 
verschiedener Speicher an mehreren internen Bussen und sicher vieles 
mehr.
Dafür haben die auch ordentlich Wumms.

Itchi schrieb:
> ja, und? Was willst du mir damit sagen?

Dass die Frage so sinnlos ist. Denn "schnell" ist absolut nichtssagend.
Für den einen sind 50 MHz schnell, für den anderen 10 MHz. Und je nach 
Betriebsspannung, Master/Slave und auch je nach SPI-Interface (ja, die 
sind pro Chip keineswegs alle gleich "schnell") ist die max. Frequenz 
unterschiedlich. Also: Wer Datenblätter lesen kann (und will!), ist klar 
im Vorteil ;-) Wer nicht ... bleibt eben sitzen.

Ah ok, die Frage ist, wie hinderlich das in der Praxis ist.
Also ich bin ein schlechter programmierer und würde den Takt einfach für 
eine flüssige Darstellung auf dem TFT nutzen, die 16BIT ADC schaden 
nicht, auch wenn nur selten benötigt

Ich würde einfach meine schlechten Programmierkenntnisse mit hohem Takt 
erschlagen;-)
Obwohl es mir widerstrebt, aber ich werde nie gut programmieren können, 
dafür habe ich zu viel andere Interessen, daher muss ich da realistisch 
bleiben.

A.B. schau doch selber mal ins Datenblatt.
Mit schnellen SPI meine ich wohl um 133MHz also zumindest das was der H7 
hat.
Danke A.B: für deine Hilfe...habe ich notiert, du kannst jetzt 
Feierabend machen:-) ohne deine Hilfe hätte ich das nie gelöst

P.s. das war Itchi:-)
Bin gerade an einem anderen PC da war ich mit anderem namen angemeldet

Itchi schrieb:
> Gibt es Gründe außer Stromsparen und kleinere Bauform, bei Kleinserien
> oder Hobbybasteleien NICHT auf z.B. den STM32H750 zu setzen?

Nein ;)

Der übliche Arduino-Hobbybastler ist aber mit der Komplexität der H7 
aber vmtl gleich überfordert. Im Vergleich zum Arduino ist ein z.B. F4 
zwar auch noch komplexer, aber vllt noch eher überschauberer

Itchi schrieb:
> P.s. das war Itchi:-)
> Bin gerade an einem anderen PC da war ich mit anderem namen angemeldet

Das hat für Gäste keinerlei Relevanz, da muß man den Namen selbst 
eintragen. Also schlechte Ausrede.

schon klar, alleine deshalb schon sind 16 Bit interessant..eben um 
stabile 12 oder mehr zu erreichen;-)

@Lutz
denk mal etwas nach doer versuche, dann siehst du weshalb so etwas beim 
Wechsel mehrerer Rechne passiert..ist heir aber nicht das 
Thema..nervötetend diese Nebendiskussionen in diesem Forum

Wie bereits geschrieben der 750er ist nicht die ideale wahl des H7 wegen 
dem Flash. besser den 743 oder noch besser einer der 550mhz kann (oder 
halt der h7 welcher irgendwie verfügbar ist).
Anyway grundsätzlich sehe ich den H7 als Einsteigerfreundlich. DMA etc. 
sind nicht Einsteigerfreundlich; dank der performance des H7 kann man 
für einfache projekte alles in der isr machen (und somit einfacher als 
kleine MCU).
Im cube ist die als komplex beschriebene clock einstellung schnell 
gmacht: einfach alles auf max schrauben - fertig.
Für bastelprojekte kann man ihn auch auf 600MHz übertakten, hab noch 
keine probleme gehabt.

I un D Cache aktivieren und auf DMA verzichten (oft bringt DMA ohnehin 
nicht so viel zb.: ADC DMA).

FPGA schrieb im Beitrag #6839822:
> Wie bereits geschrieben der 750er ist nicht die ideale wahl des H7 wegen
> dem Flash.

Den gab es zu "normalen" Zeiten für nen Fünfer. Das war schon eine gute 
Wahl, wenn man keine geschwätzigen Programme schreibt.

> I un D Cache aktivieren und auf DMA verzichten (oft bringt DMA ohnehin
> nicht so viel zb.: ADC DMA).

Besser ist es, DMA wie benötigt zu verwenden und ggf. Speicherbereiche 
vom Cache ausschließen. Stichwort MPU.

m.n. schrieb:
> Besser ist es, DMA wie benötigt zu verwenden und ggf. Speicherbereiche
> vom Cache ausschließen. Stichwort MPU.

Ja da hast du natürlich recht. Aber ist aufwand, fehleranfällig und 
kompliziert. (Habe ich selbst auch noch nie gemacht). Und obwohl DMA 
genial ist um einige kB+ an daten umherzuschieben, wird DMA im uC 
bereich oft sinnlos eingesetzt (zb ADC wert ins ram per DMA laden und 
dann interrupt - anstelle isr und den wert vom adc holen :P) DMA bringt 
hier den ultimativen performanceboost(!).

Ich gebe Dir ein Beispiel, bei dem der Bildspeicher für eine TFT-Anzeige 
im internen RAM liegt. Einmal gemacht, ist es nicht mehr kompliziert.

1

// Zugriffe FMS-Bank1 als "Device"    

2

#define MPU_DEFS_RASR_SIZE_1MB          (19<<MPU_RASR_SIZE_Pos)

3

#define MPU_DEFS_RASE_AP_FULL_ACCESS    (3 << MPU_RASR_AP_Pos)   

4

  MPU->CTRL = MPU_CTRL_PRIVDEFENA_Msk | // allow privileged code to use default memory map

5

              MPU_CTRL_ENABLE_Msk;

6

  MPU->RNR = 1;                             // Region 1 verwenden

7

  MPU->RBAR = TFT_ADR & MPU_RBAR_ADDR_Msk;  // Schutz ab TFT-Adresse

8

  MPU->RASR = MPU_RASR_XN_Msk |             // ausführbarer Code gesperrt

9

              MPU_DEFS_RASR_SIZE_1MB |      // 1 MB Bildspeicher

10

              MPU_RASR_B_Msk |              // pufferbar

11

              MPU_DEFS_RASE_AP_FULL_ACCESS |  //full read/write access for privileged and unprivileged code

12

              MPU_RASR_ENABLE_Msk;          // Region freigeben

m.n. schrieb:
> Ich gebe Dir ein Beispiel

Danke solche bsp. sind immer goldwert und eine zusammenfassung aus 100e 
seiten doku. Sollte jemand DMA bedarf haben wird er dir sehr dankbar 
sein.

Mw E. schrieb:
> 2MS/s kann mit ISRs den Kern schon gut auslasten.

2 mega isr/s schafft der H7, aber ja die auslastung ist relativ hoch. 
Anyway verwende hier nicht den begriff unnötig hoch: wenn es nötig ist 
daten mit der Bandbreite zu aquirieren, wird es zwangsläufig auch nötig 
sein diese direkt zu bearbeiten (zb FIR oder IIR). Da meines wissens der 
H7 keine im memory map liegenden DSP funktionalitäten hat müsste dies 
ohnehin vom CPU gemacht werden. War kürzlich vor einer ähnlichen 
aufgabenstellung gesucht: ADC werte aufsumieren und summe auf schwelle 
prüfen falls ja isr.
Nun habe dann alles in der ISR gemacht.

Itchi schrieb:
> Auf den ersten Blick hat er nur Vorteile,

Je mehr Funktionen der Chip hat, umso schwieriger ist der Umgang damit. 
Man muss viel mehr lesen und die Seiteneffekte der Komponenten 
aufeinander erkennen.

Das ist ein gewichtiger Grund, warum 8 Bit Controller sogar trotz 
höherem Preis immer noch beliebt sind.

Mw E. schrieb:
> Gibts eigentlich eine serielle FFT?

Ok alles klar jetzt vestehe ich die Motivation hinter ADC DMA - für FFT 
machts natürlich sinn. Anyway eigentlich schade dass sie nich im memory 
map ein paar DSP funktionen hart einbinden, dann könnte mit DMA lustige 
sachen gemacht werden :P.
Oder noch besser zusätzliche logik für Out of order execution nutzen und 
IPC hochtreiben. Moderne X86 sind zb so hochgezüchtet dass dieser wert 
aktuell bei ca. 17 liegt (und dies bei 5ghz+). Wenn dies der H7 
erreichen würde dann ist die ISR nur noch wenige clk :)

Stefan ⛄ F. schrieb:
> Das ist ein gewichtiger Grund, warum 8 Bit Controller sogar trotz
> höherem Preis immer noch beliebt sind.

8 bit empfehle ich jeden absolut beginner. Ist insbesondere akademisch 
hilfreich sich mit overflows etc zu beschäftigen und anschauliche zahlen 
zu haben

Und nebs dem wenn ein 8 biter einen IPC von 10 bei 1GHZ bringen würde 
ich auch jeden STM32 über den haufen werfen.

Wenn jetzt wirklich Audio Verarbeitung, FFT, DMA als Hardwarekomponenten 
auf dem Chip gefragt sind, dann würde doch der Kendryte K210 ins Fenster 
passen, auch was Preis und Leistung betrifft.
Dualcore 64Bit 600MHz(?)

Hier eine Übersicht:
Sorry, Datenblatt kann ich nicht verlinken da...
> Der Beitrag scheint Spam zu enthalten: "cn"
Natürlich darf ein Datenblatt eines CN Chips auch auf einem CN Server 
liegen.
Tipp: Nicht alles aus China ist gleich Spam.
(Diskriminierung in Reinform, das ist.)

Hans-Georg L. schrieb:
> DFSDM

Ja das mit dem DFSDM habe ich damals auch gefunden gehabt. Hat aber 
irgendwie auf anhieb nicht funktioniert.

Mw E. schrieb:
> Cortex-M7 hat erstmal Superskalarität eingeführt.
> Vllt kommt ja out of order beim M8 ;)?

Ja hoffentlich, naja der preis für ST ist leider hoch (benötigts sehr 
viel logik und macht den chip entsprechend grösser). Speculative 
execution etc. gehört beim M8 offentlich auch gleich dazu.
Naja Clk +IPC zu pushen ist mir wesentlich wichtiger als mehr cores 
welche ohnehin nicht sinnvoll genutzt werden können. Also single core 
IPS ist die wichtige kenngrösse.